GNOME Bugzilla – Bug 302398
RFE: allow reordering of winlist buttons
Last modified: 2008-02-15 09:04:24 UTC
Distribution/Version: Ubuntu Breezy I'd like to be able to move buttons back and forth on the window list applet, just like tabs can be reordered in galeon for example.
Me too. Let's look if patch is possible.
Actually it's a problem of tasklist widget implemented in libwnck
Created attachment 50730 [details] [review] Proposed patch This is patch that implements reordering with DnD. This is not optimal, but I think it's the only possible solution in current architecture of tasklist widget. Of course, number of problems still stays, for example it's impossible to reorder groups. But this needs discussion, since they are ordered by utf8_collate. Probably switching to appearence order may help. Small advantage of this implementation is that in theory it allows drop from tasklist to pager applet in the future. I think it would be nice to use it to place window on specific workspace.
Created attachment 51628 [details] [review] Updated patch Also solves problem from bug 96675 (draw from window list to pager) thus allowing to move window between workplaces.
Would this make it easier to solve bug 143857 ?
Sorry Vidar, it's a bit different. The DnD idea is about some data that you can drag from one window to another. But in 143857 you have to drag window itself. It probably requires some patch to wm and not so easy. Btw, looking at pager widget I see that it implements internal DnD but it's a bit confusing. It either should allow to move window on desktop with DnD or should use real DnD to drag window icons between workspaces.
(cc'ing usability-maint due to point 3 and maybe also point 2 in my list below) The patch seems to work in my testing (since I have window grouping turned off). Some notes: - One issue per bug is best. Please separate the stuff for bug 96675 and attach it to that bug. Note that when you do, however, your patch doesn't allow dragging windows from the pager to the tasklist, which is the obvious thing the user will try once they learn tasklist->pager dragging works. - You just switch the positions of the two windows (the window being dragged and the window in the position where you are dragging to). I would have assumed that all the windows with a sorting order between new_order and old_order would have been shifted by 1 in the appropriate direction. - I WONTFIX'd the original bug report requesting this, bug 37787 -- partially because of bug 52225 comment 8 (but mostly because I was just too lazy to implement it). If we are going to allow it, I'd like to get feedback from the usability folk about it. - Your patch doesn't work with grouped windows (as you pointed out) because sorting is grouped windows first, then other windows according to sorting order (and then startup sequences). Although I think grouped windows are freakin' stupid, your patch should probably work even with those around (though yes, this will require a fair amount more work).
Created attachment 53554 [details] [review] Updated patch Patch is split on two, second part is attached to bug 96675 This new version allows drag from pager to tasklist, and implements proposed style of reodering. This patch doesn't work with groups, I think it's hard to implement groups now, and one issue per patch rule if you like it don't allow such implementation.
*** Bug 325667 has been marked as a duplicate of this bug. ***
*** Bug 328557 has been marked as a duplicate of this bug. ***
*** Bug 334862 has been marked as a duplicate of this bug. ***
Hey all, will this feature go in this cycle?
Sorry, I know we've been lame; I should have responded after your last comment. Anyway, you've made it so that this bug depends on the patch in bug 96675 and in that bug you claim that it depends on the patch in this bug. That makes it harder. ;-) I would like to get some usability feedback before committing to this feature, as well as Vincent's opinion. Anna seemed to be against it in bug 52225, though that was at least partially because the default ordering was totally busted. Anyway, if you want to get this pushed closer in the mean time: 1) Can you write a self-contained patch for bug 96675 that doesn't involve any unnecessary functionality from this bug? Then we can get that one reviewed and committed. 2) Update the patch here, if necessary for any changes in #96675. 3) Fix the patch to handle grouped windows. I don't even know if there's a way to get that to make sense UI-wise (yet another joy of the inherent brokenness of window grouping), but not doing it when other tasks can be manually sorted definitely does not make sense. If we could nuke window grouping (or maybe if it at least wasn't the default?) then we could ignore this. But otherwise, I don't think we can.
Ok, let's proceed with 96675 first, and after then return back to this problem.
I didn't try the patches, but I can't know if I like it without testing :-) Note that it'd be great to use a drag and drop icon when dragging a window. Or even use an image of the all button as icon...
*** Bug 350316 has been marked as a duplicate of this bug. ***
Automatic window grouping by application is evil. My proposed solution (including pictures!) can be found at http://live.gnome.org/DesktopInterface under "Window Grouping."
Nickolay indicated in Comment #14 that he would return back to this problem after bug 96675 was resolved. Bug 96675 was resolved back around May of 2006 (a little over 6 months ago). So, it appears this bug has grown stale. From what I gather in the above comments, Elijah had Nickolay split his patch into two patches so as to make the bug to patch relationship one-to-one. Is the portion of the old patch belonging to this bug even relevant anymore? I'm currently using GNOME version 2.16.1, which I assume includes the patch from bug 96675, since dragging and dropping tasklist buttons onto the workspace switcher (pager?) appears to work. However, the application icon that appears when dragging a button is a huge (50+ pixels in height) compared to my workspace switcher (my panel is only 24 pixels in height). Being so big makes it difficult to see what you're doing for selecting a drop target. I know it's more discoverable to show a huge icon like this, but this is at the expense of usability. Couldn't we just change the appearance of the pointer icon to indicate to the user that they are dragging something? This makes the most sense in the context of rearranging buttons.
Created attachment 79009 [details] [review] Updated patch Updated patch to implement reodering
*** Bug 383778 has been marked as a duplicate of this bug. ***
Sorry, we didn't review this in time for 2.18 :/
Really cool feature :-)
(In reply to comment #19) > Created an attachment (id=79009) [edit] > Updated patch > > Updated patch to implement reodering > Sorry for the dumb question, but how do you actually reorder them?
Thanks a lot Vincent. David: set_sort_order changes the order value used to sort buttons.
(In reply to comment #22) > Really cool feature :-) 1) This makes window grouping even more broken. If "even more broken" can be used as an additional reason for ripping window grouping out, then maybe this is a good thing. 2) The documenation for wnck_window_get_sort_order ought to be updated. It's no longer correct.
(In reply to comment #25) > (In reply to comment #22) > > Really cool feature :-) > > 1) This makes window grouping even more broken. If "even more broken" can be > used as an additional reason for ripping window grouping out, then maybe this > is a good thing. I'm not quite sure it makes window grouping more broken. Well, some people will probably argue that you can't move those buttons. So I guess you're right. > 2) The documenation for wnck_window_get_sort_order ought to be updated. It's > no longer correct. It was updated. I'm not good at documentation, though, so improving it is certainly possible.
(In reply to comment #26) > I'm not quite sure it makes window grouping more broken. Good point; something that is irreparably broken is hard to make "more broken". ;-) > It was updated. I'm not good at documentation, though, so improving it is > certainly possible. Oops, it looks like I was looking at an out-of-date version. Sorry about that. Thanks for taking care of these zillions of libwnck bugs by the way, Vincent; I got surprised by a huge inbox, but it's the nice kind of bugzilla spam. :-)
i have now gnome 2.20 running on my system and tried the reordering feature: GREAT!!! thank you for this!
*** Bug 504342 has been marked as a duplicate of this bug. ***
*** Bug 516626 has been marked as a duplicate of this bug. ***