After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 302398 - RFE: allow reordering of winlist buttons
RFE: allow reordering of winlist buttons
Status: RESOLVED FIXED
Product: libwnck
Classification: Core
Component: tasklist
git master
Other Linux
: Normal enhancement
: future
Assigned To: libwnck maintainers
libwnck maintainers
: 325667 328557 334862 350316 383778 504342 516626 (view as bug list)
Depends on:
Blocks: 155908
 
 
Reported: 2005-04-29 08:36 UTC by kimiko
Modified: 2008-02-15 09:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Proposed patch (6.73 KB, patch)
2005-08-15 16:28 UTC, Nickolay V. Shmyrev
none Details | Review
Updated patch (11.72 KB, patch)
2005-08-31 18:36 UTC, Nickolay V. Shmyrev
none Details | Review
Updated patch (7.69 KB, patch)
2005-10-16 19:37 UTC, Nickolay V. Shmyrev
none Details | Review
Updated patch (7.30 KB, patch)
2006-12-28 22:45 UTC, Nickolay V. Shmyrev
committed Details | Review

Description kimiko 2005-04-29 08:36:51 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.
Comment 1 Nickolay V. Shmyrev 2005-08-11 15:11:38 UTC
Me too. Let's look if patch is possible.
Comment 2 Nickolay V. Shmyrev 2005-08-11 15:36:18 UTC
Actually it's a problem of tasklist widget implemented in libwnck
Comment 3 Nickolay V. Shmyrev 2005-08-15 16:28:47 UTC
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.
Comment 4 Nickolay V. Shmyrev 2005-08-31 18:36:13 UTC
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.
Comment 5 Vidar Braut Haarr 2005-08-31 18:41:50 UTC
Would this make it easier to solve bug 143857 ?
Comment 6 Nickolay V. Shmyrev 2005-08-31 18:47:37 UTC
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.
Comment 7 Elijah Newren 2005-10-08 22:21:24 UTC
(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).
Comment 8 Nickolay V. Shmyrev 2005-10-16 19:37:32 UTC
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.
Comment 9 Vincent Untz 2006-01-03 22:14:17 UTC
*** Bug 325667 has been marked as a duplicate of this bug. ***
Comment 10 Vincent Untz 2006-01-25 17:47:12 UTC
*** Bug 328557 has been marked as a duplicate of this bug. ***
Comment 11 Vincent Untz 2006-03-25 08:33:21 UTC
*** Bug 334862 has been marked as a duplicate of this bug. ***
Comment 12 Nickolay V. Shmyrev 2006-03-28 00:34:36 UTC
Hey all, will this feature go in this cycle?
Comment 13 Elijah Newren 2006-03-30 20:30:31 UTC
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.
Comment 14 Nickolay V. Shmyrev 2006-03-30 21:36:52 UTC
Ok, let's proceed with 96675 first, and after then return back to this problem.
Comment 15 Vincent Untz 2006-03-31 07:02:32 UTC
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...
Comment 16 Vincent Untz 2006-08-08 19:27:26 UTC
*** Bug 350316 has been marked as a duplicate of this bug. ***
Comment 17 John Peterson 2006-11-11 17:13:55 UTC
Automatic window grouping by application is evil. My proposed solution (including pictures!) can be found at http://live.gnome.org/DesktopInterface under "Window Grouping."
Comment 18 John Peterson 2006-12-26 16:24:35 UTC
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.
Comment 19 Nickolay V. Shmyrev 2006-12-28 22:45:27 UTC
Created attachment 79009 [details] [review]
Updated patch

Updated patch to implement reodering
Comment 20 Vincent Untz 2007-01-15 10:54:10 UTC
*** Bug 383778 has been marked as a duplicate of this bug. ***
Comment 21 Vincent Untz 2007-02-09 16:58:56 UTC
Sorry, we didn't review this in time for 2.18 :/
Comment 22 Vincent Untz 2007-04-29 12:03:41 UTC
Really cool feature :-)
Comment 23 David Prieto 2007-04-29 12:14:48 UTC
(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?
Comment 24 Nickolay V. Shmyrev 2007-04-29 12:18:23 UTC
Thanks a lot Vincent. 

David: set_sort_order changes the order value used to sort buttons.
Comment 25 Elijah Newren 2007-04-29 22:11:10 UTC
(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.
Comment 26 Vincent Untz 2007-04-29 22:24:27 UTC
(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.
Comment 27 Elijah Newren 2007-04-29 22:35:33 UTC
(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.  :-)
Comment 28 johannes raggam 2007-09-19 17:24:37 UTC
i have now gnome 2.20 running on my system and tried the reordering feature: GREAT!!! thank you for this!
Comment 29 Teppo Turtiainen 2007-12-26 13:57:10 UTC
*** Bug 504342 has been marked as a duplicate of this bug. ***
Comment 30 Philip Withnall 2008-02-15 09:04:24 UTC
*** Bug 516626 has been marked as a duplicate of this bug. ***