GNOME Bugzilla – Bug 96675
drag and drop from the window list to the workspace switcher ???
Last modified: 2006-05-15 17:35:29 UTC
not actually sure if this is a good idea or not, but anyway the motivation for this bug is that currently its sort of hard to move windows in between workspaces. metacity context menu lets you move windows between workspaces but requires you to know the workspace number (not very intuitive). moving windows within the workspace switcher is sort of hard since you need pinpoint accuracy with the mouse. So anyway an idea i had was to give users the ability to drag the window list entry for a window to the workspace switcher, doing so would move the window to the selected workspace. Make sense? This gives you a much larger mouse target for the drag grab which is nice, and seems somewhat intuitive to me. Usability guys what do you think?
Hmm... not sure it's intuitive enough that it should be the primary way of moving windows between workspaces, but being able to drag windows from the window list onto other things could certainly open up some interesting possibilities in the future. E.g. drag a window button onto another to group/rearrange them, drag onto a printer icon to print a screenshot of the window (or print the document it contains? dunno, just throwing out ideas here).
Yeah this would just be another way to do it, not the way, ie you could still use the metacity context menu, or the workspace switcher itself.
Hi, hopefully I found this bug instead of opening a duplicate ;) I wanted to open a bug since *I tried* to drag a task list button to the desk guide applet, because I'm used to use the desk guide to move windows between desktops. Unfortunately it does not worked :( And as Dave pointed out, it is a lot easier to pick a task list button than picking the window in the desk guide. Calum: I really tried it without thinking on it, so it is really an usability bug. I just felt stupid because it don't worked ;)
I think this sounds like a great feature. I'd still allow dragging from within the workspace switcher for now (though I do think there are useful things we could do with clicks in the workspace switcher instead)
RE: > I'd still allow dragging > from within the workspace switcher for now (though I do think there > are useful things we could do with clicks in the workspace switcher > instead) One thing that comes to mind is that double clicking the current workspace could switch into show desktop mode, removing the need for a seperate panel button (or whatever they are called now).
Bug 302398 has patch that starts implementation of DnD from tasklist
I've updated patch to bug 302398, now it implements this feature also.
Created attachment 53553 [details] [review] Separated patch for the pager To function it requires patch from 302398, dragging from pager to tasklist is also implemented.
*** Bug 328073 has been marked as a duplicate of this bug. ***
this isn't always feasible, by the by. Do note that in my case I have a 24 pixel panel with a workspace switcher on it that's 4x4 pixels; the corner pointer on the drag icon is BIGGER than a workspace, it's HARD to drag onto a given workspace. #96473 should be considered IN ADDITION to this.
*** Bug 336429 has been marked as a duplicate of this bug. ***
> To function it requires patch from 302398, dragging from pager to tasklist is > also implemented. As per comments in bug 302398, could you post a self-contained version of the patch?
Created attachment 62424 [details] [review] Patch Thanks Elijah for looking at his problem, here is updated separate patch for this bug, it's doesn't depend on another patch. I think we'll handle this problem first, reordering problem will wait.
Some really quick comments: + this mostly looks okay :-) + you're declaring + static const GtkTargetEntry targets[] = { + { "application/x-window-id", 0, 0} + }; twice in pager.c. We can simply declare it once, can't we? + I'd go for a less generic target name: application/x-wnck-window-id + any reason to remove the "handled" in wnck_pager_button_release()? Or is it only because it was added after your first patch? :-) + I'm a bit lost between the in_dnd and dragging variables. We should rename the variables. I guess this is because there's no reason to not handle the intern-to-the-pager drag and drop the same way (with the real dnd signals, etc.). Do you think it would make sense to do it the same way? + dnd_window looks useless?
1) yeah, I should update patch to exclude second static const 2) The value that is passed is really X window id, not wnck id, so I suppose it might be reused in other pages or programs that operate with windows. From that point of view it's better to use generic name 3) handled variable was already present in libwnck and it's completely unused variable, this is just code cleanup 4) dnd_window is unused here, yeah, I'll remove it And the main question - if we'll cut internal drag and drop on pager, this patch will require more significant modification, do we really need it? I'd prefer drop it at all for consistensy, but probably someone will argue about this missing feature.
(In reply to comment #15) > 2) The value that is passed is really X window id, not wnck id, so I suppose it > might be reused in other pages or programs that operate with windows. From that > point of view it's better to use generic name The thing is that using "x-something" means it's something non-standard. And the "something" in "x-something" should start with the app prefix. For example, we use "application/x-panel-applet-iid" in the panel. I agree that it's the xid, and it could be used by others, but I don't know if this would be the correct name to use for this. > 3) handled variable was already present in libwnck and it's completely unused > variable, this is just code cleanup My bad :-) I read too quickly. > 4) dnd_window is unused here, yeah, I'll remove it > > And the main question - if we'll cut internal drag and drop on pager, this > patch will require more significant modification, do we really need it? I'd > prefer drop it at all for consistensy, but probably someone will argue about > this missing feature. Why drop it? We can leave the internal dnd as it is right now, but it would make sense to make it use the real dnd mechanism too. You'd be able to drag and drop a window from the pager to your window list too, eg. Or from the pager to the desktop, and nautilus would move the window to the current workspace.
Sorry, I was unclear Internal dnd is the code that doesn't use gtk dnd but instead handles motion events and draws window around pointer, it's the implementation that present now. I am wondering if we can replace it with gtk dnd or just add new dnd to old one. I was thinking that internal dnd allows user to move window on the screen, that isn't possible with external dnd, but now it seems that moving a window in screen doesn't affect anything - it just returns to original place. Probably I have just older gnome version.
Ah, so we're thinking the same thing :-) I'd say we should replace it. (IIRC, it used to move the windows, but it was probably removed because it wasn't easy to move a window where you wanted this way)
Created attachment 62478 [details] [review] Patch Updated to Vincent's comments, feel free to try and suggest future development.
So, patch from bug 339293 contained an improved version of the pager dnd code (and other things). Now, we only need to handle things in the window list.
I committed the end of the patch, after a few modifications. This is awesome. I don't understand how we could live without this!