GNOME Bugzilla – Bug 580658
Drag&Drop applications open in wrong workspace
Last modified: 2009-05-01 20:32:46 UTC
Steps to reproduce: 1. Enter the overlay mode 2. Add some workspaces 3. Drag&Drop an application to one workspace, choose an app that opens longer (e.g. evolution and then while the app is still loading "zoom in" on another workspace. Result: Application opens in our current workspace. Expected behaviour: Application gets launched on the workspace where it was dragged.
Created attachment 133751 [details] [review] Set the workspace when launching apps main.js: Add create_app_launch_context() with code from appDisplay; additionally set the workspace on the launch context to the current workspace so that the application launches on the right workspace even if the user switches before the app starts. appDisplay.js docDisplay.js: Use Main.create_app_launch_context() http://bugzilla.gnome.org/show_bug.cgi?id=580658 (Reported by Igor Vatavuk)
Ah, also, you may notice: - let icon = this._appInfo.get_icon(); - context.set_icon(icon); Went missing; I removed it because I read the code in GDK and it automatically got the icon from the AppInfo if the AppInfo had an icon.
+ context.set_timestamp(display.get_current_time()); I realize this is just copied from the current code, but wouldn't Clutter.get_current_event_time() be more correct? Otherwise looks good.
+ // The app launch context doesn't work as well as we might like because + // it doesn't get the right StartupNotify key from the application's + // desktop file. So, we don't get startup notification, the application + // doesn't stick to the current workspace, and so forth. + appInfo.launch([], Main.create_app_launch_context()); This comment is unclear to me. Are you talking about the default app launch context and explaining why we are passing in our own? Perhaps changing "The app launch context" to "The default app launch context" would clarify the situation. + // Make sure that the app is opened on the current workspace even if + // the user switches before it seetarts s/seetarts/starts Otherwise looks good.
Rewrote the comment to: // The point of passing an app launch context to launch() is mostly to get // startup notification and associated benefits like the app appearing // on the right desktop; but it doesn't really work for now because we aren't // reading the application's desktop file, and thus don't find the // StartupNotify=true in it. So, despite passing the app launch context, // no startup notification occurs. Hopefully that explains things better. Also fixed the typo.
(In reply to comment #3) > + context.set_timestamp(display.get_current_time()); > > I realize this is just copied from the current code, but wouldn't > Clutter.get_current_event_time() be more correct? First reply to this got lost due to a bugzilla timeout. display.get_current_time() gets you a timestamp that is updated every time an event is received on the Metacity display (including events processed by clutter rather than Metacity.) So I think it's appropriate to use, and would work better then Clutter.get_current_event_time() if you had a launch triggered off a global hotkey or something.