thinkingrock-gtd
Context sensitive name of the application
When you run the application on Linux, GNOME, and switch between running applications usually the name of the application is displayed.
ThinkingRock is displaying "ThinkingRock /h...". My guess it is trying to display what is in the application Windows header. In my case, it is the application's name and currently opened trx file.
Today I noticed, that it is context-sensitive. It means the current header is displayed. Try open Context, open dialog "Add Context". Now, if you switch between running applications the name is "Add Context".
Or, open Notes in a task, and the application will be named "Notes Editor". etc.
Initially, I wanted to add this as a bug because my expectation is there will be simply "Thinking Rock". But eventually, it could be a good thing.
@degrown @ursjoss What do you think?
I had a quick check, using Plasma (KDE) on Linux. There we also see the window tile, potentially abbreviated if there is not enough space, which would truncate the path as you describe it for gnome:
I am not sure if I completely got your point but I would definitely prefer to keep the window title display the path of the current data file that is opened with ThinkingRock. And if the desktop manager chooses to simply show the window title, that's something that's out of scope for the application to choose. Unless there's a specific property to set for window managers, but I am rather sceptical if it is even worthwhile exploring that.
I am not sure if I completely got your point but I would definitely prefer to keep the window title displaying the path of the current data file that is opened with ThinkingRock. And if the desktop manager chooses to simply show the window title, that's something that's out of the scope of the application to choose.
It seems to me, that the window manager displays what is displayed in the title of the application. In your case, it is "ThinkingRock /urs/tr/gtd.txt".
My expectation is to display there "Thinking Rock".
The usage of the path isn't nice IMHO but the main issue I see here is displaying "Notes Editor", "Add Context" etc. The user is simply switching applications and suddenly there is "Notes Editor" app etc. This is weird or at least not common.
I have no strong opinion here, it's more or less cosmetic adjustment but I would fix it.
I see now what you mean with the "Add Context" example. ThinkingRock is opening a pop-up for adding context which is technically it's own window and can separately be switched to. We have two open windows, both with the ThinkingRock icon and both displaying the context of the title bar. The main window showing "ThinkingRock /home...", the pop up showing "Add Context". To me, that's not a bug or an issue, frankly. As we can choose those windows independently, they should appear in the window switcher. And showing the title bar seems to be the sensible thing to do...
Of course it would be nicer if the window switcher would be able to e.g. group Thinkingrock related windows into stacks, but that's out of control for ThinkingRock, it would be a feature of the window manager not the app.
ThinkingRock is opening a pop-up for adding context which is technically it's own window and can separately be switched to.
In GNOME there is just one switchable window. And this window is "Notes editor". The "ThinkingRock ..." simply "disappears" from the switcher and it is possible to switch just into "Notes editor" which means ThinkingRock.
That sounds very inconvenient indeed. Is this new behavior of TR? Or was it already the case with TR-3.7.0?
Unfortunately I can't run the original version, even with the latest java 8. I'm getting this error:
SEVERE: No way to find original stream handler for jar protocol java.lang.reflect.InaccessibleObjectException: Unable to make field transient java.net.URLStreamHandler java.net.URL.handler accessible: module java.base does not "opens java.net" to unnamed module @65e12b54 at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354) at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297) at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178) at java.base/java.lang.reflect.Field.setAccessible(Field.java:172) at org.netbeans.ProxyURLStreamHandlerFactory.register(ProxyURLStreamHandlerFactory.java:82) at org.netbeans.JarClassLoader.<clinit>(JarClassLoader.java:141) at org.netbeans.MainImpl.execute(MainImpl.java:178) at org.netbeans.MainImpl.main(MainImpl.java:85) at org.netbeans.Main.main(Main.java:83)
It'll need more time to explore it.
I suspect that you somehow try to launch TR 3.7.0 with Java9 or later instead of java 8 as you actually intend to do.