I have installed Xfce 4.10 on a low end atom machine. It takes quite a time to start applications like firefox (~ 10sec). It would be great if the startup could be indicated by some kind of busy cursor.
Normally, if startup notification is enabled in the .desktop file you use to start the application, it works as expected and shows a busy cursor. Is startup notification enabled for those applications of yours?
Could you please point out how startup notification could be activated within a .desktop file?
First result of a search for "desktop file startup notification": StartupNotify=true
Thanks for pointing that out. Yes, it's set, but still no busy cursor is shown.
I get the busy cursor on the panel and on the desktop background but not on other applications (that way you can still use them fully while launching another application). Anything like that for you?
Does not work for my. But I have noticed that there is another .desktop file e.g. for Firefox: /usr/share/xfce4/helpers/firefox.desktop which comes from the exo package. This one has StartupNotify=false set. Could that cause the problem?
Yeah that could explain the problem if you use the default launchers on top of the menu or an exo-open command. Moving this to exo which provides those desktop files. Meanwhile changing false to true will solve your issue.
Nick, do you happen to know if there is any technical reason for having the startup notification set to false in some helpers (firefox, thunderbird...)?
I have set StartupNotify=true in all relevant desktop files in exo, but that does not change anything. Still no startup notification.
I can indeed confirm here that there are two issues: 1) Some helpers don't have StartupNotify=true 2) It doesn't work anyway for the top level items in the menu (Terminal, File Manager, Mail Reader, Web Browser) both in the panel plugin and in the desktop right click menu.
exo_helper_execute does not use the StartupNotify property, there is even a FIXME in the code about that. To fix this, the easiest way would be to replace the gdk_spawn_on_screen call on line 402 of exo-helper.c by a xfce_spawn_on_screen. However, we then lose the pid thing which allows us in the current code to check if the program is still running after 5 seconds. Two scenarios: - Use xfce_spawn_on_screen_with_child_watch to do the same check (still have to figure out how) - Just rely on the succeed result and show an error if it failed, then move to the next command. I don't really see why we need that 5 seconds call anyway, if the application helper is broken, it should be fixed, shouldn't it? Or I'm missing something else? Nick, any thoughts on this?
Just a side note: on my box startup notification does not work in all cases (openSUSE 12.2)
Ok, my problem seems to be related to: https://bugs.launchpad.net/lightdm/+bug/1024482
So, can we replace gdk_spawn_on_screen with xfce_spawn_on_screen and remove the process monitoring part (scenario 2)?
Created attachment 6027 use xfce_spawn_on_screen and drop process monitoring Note: The helper .desktop files for Firefox and Thunderbird (and some other applications) have StartupNotify set to 'false'. http://git.xfce.org/xfce/exo/tree/exo-helper/helpers
I've tested Thaddaeus' patch and noticed no regressions. I've applied it at http://git.xfce.org/xfce/exo/commit/?id=3a2c05bd68f924f5c8bd530a2fe8f4cc5b671b16 Please test and comment if it does not work for you, or introduces a new regression.
Hello Xfce developers, since exo 0.10.4 there is an issue where xfce4-terminal (and sometimes Thunar too) starts with the window unfocused (I can't type in terminal until I click on it) but only when I start it with "exo-open --launch TerminalEmulator" from a panel launcher. Downgrading to exo 0.10.3 "fixes" it. Maybe a regression caused by http://git.xfce.org/xfce/exo/commit/?id=3a2c05bd68f924f5c8bd530a2fe8f4cc5b671b16 ? Thanks.
Like the person above me said, applications launched by exo-helper using startup notification remain unfocused. (Make sure to kill any Thunar or xfce4-terminal daemons before testing as those will hide the problem.) The issue appears to be caused by the startup_timestamp parameter being passed to xfce_spawn_on_screen(). gtk_get_current_event_time() returns zero since there's no event, and a value of 0 apparently means that the application shouldn't receive focus.
Created attachment 6107 Use g_get_current_time instead of gtk_get_current_event_time Thanks to informations from Comment 18, I tried to fix the bug with the changes in the attached patch. I don't know if it is the correct way, but I tested it and it works for me.
(In reply to chrono from comment #19) > Created attachment 6107 > Use g_get_current_time instead of gtk_get_current_event_time > > Thanks to informations from Comment 18, I tried to fix the bug with the > changes in the attached patch. I don't know if it is the correct way, but I > tested it and it works for me. X server timestamps are not based on time since epoch so the patch is passing an incorrect value. To pass a correct timestamp we'd need to get the current X server time and I'm not sure how that is done.
It was just a lucky coincidence that it worked for my while running very specific test cases. So far, I was not able to find a proper way of querying/generating the correct timestamp. Passing a "random" value other than 0 will probably mess with the focus stealing mechanism.
I was going to revert these changes, but then I found this. https://developer.gnome.org/gdk3/stable/gdk3-X-Window-System-Interaction.html#gdk-x11-get-server-time Maybe we can create an offscreen window and utilize this to make it work... does somebody want to give it a shot? We might also be able to spin these together to solve that... https://developer.gnome.org/gdk3/stable/gdk3-X-Window-System-Interaction.html#gdk-x11-get-default-root-xwindow https://developer.gnome.org/gdk3/stable/gdk3-X-Window-System-Interaction.html#gdk-x11-window-lookup-for-display
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/exo/-/issues/3. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev