On Tue, Nov 17, 2009 at 5:26 PM, Anthony Petrov <[email protected]> wrote: > On 11/17/2009 06:11 PM, Damjan Jovanovic wrote: >> >> On Wed, Nov 11, 2009 at 11:31 AM, Dmitry Cherepanov >> <[email protected]> wrote: >>> >>> Just a small suggestion. >>> >>> It might make sense to clarify whether this fix covers the UI tools (like >>> jconsole) or not. So far, the report says that >>> >>> >>> ----------------------------------------------------------------------------------------- >>> Copy this text into a .desktop file in your ~/Desktop directory: >>> >>> [Desktop Entry] >>> Name=Startup notification test >>> Type=Application >>> Exec=jconsole >>> StartupNotify=true >>> >>> jconsole can be replaced by any Java application that opens a window. >>> >>> ----------------------------------------------------------------------------------------- >>> >>> According this description, the fix is supposed to work OK with the UI >>> tools. >>> >>> At the same time, the java process doesn't inherit the env variable >>> (DESKTOP_STARTUP_ID) of the UI process. As a result, the newly introduced >>> method will not remove the startup notification. So, my suggestion is to >>> explicitly clarify this behaviour in the bug report. >>> >>> The fix itself looks fine for me. >> >> Startup notifications have to start and stop. They don't automatically >> start when you double-click on an executable file from your file >> manager or run an executable from a terminal. They can only start when >> you run a .desktop file that has the "StartupNotify=true" line. >> >> If startup notifications don't start, then there is no real problem - >> it just looks bad because you know you started the application but you >> aren't getting any feedback that it's starting (busy mouse cursor, >> "Starting ..." on the task bar). >> >> If startup notifications do start, then it looks really bad if they >> don't stop - the application starts in a separate task bar tab, while >> the "Starting..." tab and the busy mouse cursor continue for quite >> some time. My patch addresses this case, by stopping them when the >> first window shows. >> >> The .desktop files for tools like jconsole currently have no >> "StartupNotify=..." line, so startup notifications are disabled even >> with my patch. I asked we add "StartupNotify=true" to those files and >> provided a patch, but my request was denied, see the OpenJDK bug >> (https://bugs.openjdk.java.net/show_bug.cgi?id=100094) for details. > > I think Dmitry means that even if you add the "StartupNotify=..." to the > .desktop file for jconsole, it won't end the startap notification with your > current fix. That is because the .desktop file actually starts the jconsole > launcher, which subsequently starts the java process of the jconsole w/o > inheriting the environment. Therefore, the java process of the jconsole does > not end the startup notification. > > AFAIR, your then-proposed fix only added the "StartupNotify=..." to some > java and java-ws.desktop files. But it didn't address the issues in the > native launcher for jconsole. > > However, the description of the bug in the Bugzilla states that with your > fix the .desktop file of the jconsole may be modified, and the jconsole will > work correctly: the startup notification will be ended as soon as jconsole > starts. Dmitry is pointing out that this is not true.
I see. How can I edit the OpenJDK bugzilla comment? > -- > best regards, > Anthony > Thank you Damjan
