Positional icon ordering

[GoogleCodeExporter]

This is not an issue but a wishlist (or feature request).

I use to use a lot of different windows of the same application (like many 
terminals) simultaneously.  Frequently I find myself re-positioning the icons 
in the workspace representations in tint2 so that I can know which one to click 
when moving to a different workspace.

It would be nice that tint2 do this automatically when we move windows acros 
the workspace, i.e., windows that are physically in the left of another get 
represented also in the left in tint2.

Some cases are simple ('[' represents the left edge of a window and ']' 
represents its right edge):

[A   A]  [B   B] -->  A Window should be represented in the left of B Window;
[A   [B  A]   B] -->  A Window should be represented in the left of B Window;

Others are not that obvious:

[A [B   B]    A] -->  Maybe A and B could be considered "equally" positioned, 
but since B's "center of gravity" is more to the left of A it could be 
considered to be in the left of A for the purposes of this representation OR, 
even better, the algorithm could use the vertical positioning as a secondary 
criteria of sorting.

Of course there will be cases which even using vertical positioning as a second 
criteria it will not possible to determine which window will come first (more 
to the left) because both windows have the same "center of gravity".  in this 
cases, the algorithm could consider both as equivalent in position (that is: 
their relative positions are irrelevant when sorting).

Thanks

Original issue reported on code.google.com by marcelof...@gmail.com on 21 Mar 2015 at 1:39

[GoogleCodeExporter]

Just an additional note, maybe it is not clearly described above.  Using the 
vertical position as the secondary criteria should only be used when the 
horizontal center of gravity are identical as the it should be considered more 
important than the vertical position.

Original comment by marcelof...@gmail.com on 21 Mar 2015 at 1:43

[GoogleCodeExporter]

Related: issue 170.

Original comment by mrovi9...@gmail.com on 21 Mar 2015 at 3:52

• Changed state: Wishlist
• Added labels: Component-Taskbar, Type-Enhancement

[GoogleCodeExporter]

Isn't this essentially dock mode? Meaning that the launcher and the taskbar are 
merged into a single component, and launcher icons turn into taskbar buttons 
when applications are started. Applications that do not correspond to a 
launcher icon are added to the right.

The order of the launcher icons thus gives the order of the taskbar buttons.

Original comment by mrovi9...@gmail.com on 22 Mar 2015 at 9:31

[GoogleCodeExporter]

Dock mode is discussed a bit more in issue 356.

Original comment by mrovi9...@gmail.com on 22 Mar 2015 at 9:34

[GoogleCodeExporter]

Hi, I checked issue 356 and there the proposal is to make tint2 to behave like 
windows 7, this is a completely different request.

My wishlist feature refers to ordering the items in the taskbar according to 
their respective application windows in the X desktop, not to their position in 
the launchers.  This will make the icons to reorder automatically when I grab a 
terminal window around the screen and put it to the right of another window 
which it was relatively to the left, for example.

Just for reference, although this is not exactly the same thing, you probably 
remember gnome2 's workspace switcher.  It used to have miniature rectangles 
representing each window in the desktop.  These rectangles moved when the 
windows moved in the desktop.  The idea is similar, but uni-dimensional (gnome2 
workspace switcher was bi-dimensional).

Original comment by marcelof...@gmail.com on 22 Mar 2015 at 12:06

[GoogleCodeExporter]

I'm adding two screenshots:

- In the first, I have a terminal in the left relative to the calculator
- In the second, I have this terminal in the right relative to the calculator

The idea is that tint2 automatically reorder the icons in the taskbar as in the 
screenshots (which I did manually).

Original comment by marcelof...@gmail.com on 22 Mar 2015 at 12:21

Attachments:

• TerminalLeft.jpg
• TerminalRight.jpg

[GoogleCodeExporter]

In the above example, the two icons are intentionally different, but this 
feature becomes especially useful when we have multiple instances (or windows) 
of the same application, so, when we are in a different workspace and move to 
it, we can click in the intended one to have the focus, although all icons are 
the same.

Note that even if we have a configuration with the labels and not just the 
icons, many times the labels will also be the same, so the same benefit applies.

Original comment by marcelof...@gmail.com on 22 Mar 2015 at 12:27

[GoogleCodeExporter]

s/all icons are the same/all icons have the same picture/

Original comment by marcelof...@gmail.com on 22 Mar 2015 at 12:36

[GoogleCodeExporter]

Thanks. Now I understand what you mean.

I'm not sure I will manage to do this soon. It is complicated because of how it 
would interact with manual drag-and-drop of tasks (maybe the easiest thing to 
do is to disable that one when this is enabled), and also the code handling the 
taskbar is quite complex and was not designed with any sorting in mind. It 
might make sense to implement this together with issue 170.

Original comment by mrovi9...@gmail.com on 22 Mar 2015 at 2:41

[GoogleCodeExporter]

Yep, I also have the understanding that the proposed automatic rearranging and 
the manual drag-and-drop are kind of mutually exclusive.

I also don't have much free time for this, but if you can indicate where in the 
source files window changes notification (from X) and the drag-and-drop 
repositioning are managed, maybe I can give it a try and submit for your 
analysis.  (Note: I didn't examine the source yet, so this indication could 
save some time and avoid me to touch unnecessary parts due to misinterpretation 
of the code).

My approach would be: on the event handling of X clients repositioning 
notification (like it certainly already exists in tint2 for windows opening and 
closing), act as the user rearranging the icons manually in the task bar using 
a sort algorithm based on the virtual center of gravity of the clients.

Original comment by marcelof...@gmail.com on 22 Mar 2015 at 3:20

[GoogleCodeExporter]

Nevermind, I did it, the taskbar code is quite convoluted.

Check the latest commit, r738.

On line 64 in taskbar/taskbar.c you need to change

sort_tasks_method = TASKBAR_NOSORT;

to:

sort_tasks_method = TASKBAR_SORT_POSITION;

(because I don't want it enabled by default in the repo) and it *should* work.

But it will need testing to hit the next release. What comes to mind is having 
tasks pinned to multiple desktops, single desktop mode, multiple monitors...

If everything is OK I will add the option to the config.

Original comment by mrovi9...@gmail.com on 22 Mar 2015 at 4:13

[GoogleCodeExporter]

You can change compare_tasks() if you need a different ordering.

Original comment by mrovi9...@gmail.com on 22 Mar 2015 at 4:14

[GoogleCodeExporter]

Hey! That was fast!

Will give it a try, test and possibly play with compare_tasks.

Thanks!

Original comment by marcelof...@gmail.com on 22 Mar 2015 at 5:17

[GoogleCodeExporter]

This is pretty much the idea and the results are very good.

I explored the diffs a bit (hey you code quickly!) in an attempt to improve the 
compare_tasks(), but in order to accomplish some of improvements I would need 
extend my changes way too much beyond my compare_tasks() "sandbox" :)  (what I 
really needed is task->win_w and task->win_h for width and height...)

OBS: maybe the drag_and_drop should be disabled when this sort method is 
chosen.  I noticed it still works.

Some considerations about the expressed concerns:

* tasks pinned to multiple desktops are not really an issue if sorting gets 
implemented as the first action right after switching to a new desktop.  (This 
immediate sorting on switching is actually something that I think is already 
missing in my understanding);

* single desktop mode: I think this is not something to be concerned about.  It 
should just work the very same way.  Maybe it is not as much useful as for 
multiple desktops, but the sort method will be configurable anyway and manual 
sort will probably be the best option in this case;

* multiple monitors: Have tho think about that.  Unfortunately I cannot test 
this right now;

Original comment by marcelof...@gmail.com on 22 Mar 2015 at 6:00

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Modify it as much as you want :) I can check afterwards if your changes need 
refactoring.

You are right in your comments. But I did not give this problem a lot of 
thought.

And you don't have to test scenarios you do not use. Just let me know if you 
see strange behavior or crashes.

Original comment by mrovi9...@gmail.com on 22 Mar 2015 at 6:13

[GoogleCodeExporter]

additional note: may be the drag_and_drop -- for reordering the icons -- should 
be disabled with this sort method.  Of course dragging and dropping to a 
different desktop should still work ;)

An easy way to implement that would be to sort right after the dropping.

Original comment by marcelof...@gmail.com on 22 Mar 2015 at 6:13

[GoogleCodeExporter]

That sounds right. But I was afraid to change the drag and drop code in a hurry.

I hope we manage to move the repository to git soon so that I can create 
branches for this kind of thing.

Original comment by mrovi9...@gmail.com on 22 Mar 2015 at 6:16

[GoogleCodeExporter]

Ok, here it goes a patch (on top of r738) with some improvements in this 
feature.

I intend to make further improvements in the compare_tasks() algorithm so that 
it handles horizontal and vertical ordering more intuitively depending on 
windows overlapping or not.  Currently it only sorts the icons according to the 
horizontal component of the windows' virtual centers of gravity.

Most importantly, this patch fixes the drag and drop behavior (when positional 
sort is on) so that it works correctly for moving windows across desktops while 
not messing the with automatic sorting of icons.  In fact, the icon already 
goes to the correct position in the destination desktop when dragged.

I found a bug that I didn't try to fix because it would require a better 
knowledge of the code: the win_x, win_y, etc. don't get initialized for the 
existing windows (i.e. already running applications) when tint2 is executed, 
so, the sorting only works correctly after you move the windows a bit to make 
tint2 realize the actual position of each window.  I think there should be a 
loop to be executed as soon as possible when tint2 gets launched to initiate 
the values, but I don't know where exactly to put it.

Note: Working with windows that are pinned to all desktops will require more 
analysis because there is an if clause that makes event_button_motion_notify to 
return as soon as it realizes the window being dragged has this flag on.

The only structural change I did was to add win_w and win_h to the Task struct 
type.

I would like you to confirm the commit of these changes before moving on with 
further improvements in this feature.

Thank you very much for making the first (and most important) changes and also 
for being willing to accept contributions.

Original comment by marcelof...@gmail.com on 23 Mar 2015 at 1:50

Attachments:

• r738sort_improvements.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Note: I accidentally left a "printf" debug code in taskbar_compare(), sorry.
Anyway, this is the very only spot where I used a debug "printf".

BTW, this "printf" reveal the BUG I describe in #19.

Original comment by marcelof...@gmail.com on 23 Mar 2015 at 2:25

[GoogleCodeExporter]

Follows a new patch.  This time the initialization bug is fixed.  No need for 
initialization loop, actually the add_task() function was already initializing 
it, but not completely.

The instrumentation "printf"s in the compare_tasks() have also been commented 
out.

This patch applies on top of r738.  Please let me know what you think about the 
changes.  So far, in my tests, everything is ok.  Working with desktop pinned 
windows still require treatment.

Thanks

Original comment by marcelof...@gmail.com on 23 Mar 2015 at 10:12

Attachments:

• r738-sort_improvements2.diff

[GoogleCodeExporter]

Nice! I will take a look in a couple of days.

Original comment by mrovi9...@gmail.com on 23 Mar 2015 at 10:51

[GoogleCodeExporter]

Merged in r745.

Changes:
* Sorts vertically first for vertical panels.
* Can also sort in case-insensitive, natural order by title.

Add to your config:

taskbar_sort_order = center (possible values are none, center, title)

Still needs integration in tint2conf and some time to make sure everything is 
OK.

Original comment by mrovi9...@gmail.com on 28 Mar 2015 at 10:58

• Added labels: Component-Docs

[GoogleCodeExporter]

Great!  Will try this.

I making some experiments in a more complex sort algorithm going beyond 
coordinates comparison and at the same time being intuitive..

One thing that I'm considering is making children window to always go after 
their parents (horizontally meaning to the parent's right) regardless of their 
relative centers.  The ordering based on center will continue to rule when 
windows have no parental relation.

I don't have material to share yet and need some research so that I can 
correctly determine when a task is a child of another.

Will work on top of r745 from now.  Thanks.

Original comment by marcelof...@gmail.com on 28 Mar 2015 at 11:25

[GoogleCodeExporter]

BTW, I'll separate this other algorithm I thinking of from the "pure" center 
oriented sort.  Don't know a good name for it yet.

It just doesn't seem right to me that an e-mail window, for example, open from 
a maximized Evolution e-mail client show in the left of the parent window.

Other unrelated windows, though, should respect the center only ordering under 
the same conditions in my opinion...

(I actually didn't have the time to work on it this weekend yet.  Will try 
tomorrow).

Original comment by marcelof...@gmail.com on 28 Mar 2015 at 11:33

[GoogleCodeExporter]

All right. No hurry, I don't have much free time either these days.

However I don't think you will get anywhere with parent-child sorting, usually 
programs make their windows independent.

See:
xwininfo -tree -root

Maybe you can sort by the top-left corner first, and in case of tie sort by the 
center?

But IMHO your problem is that you do not have titles on the windows in the 
panel, which is why you cannot identify them correctly. This looks nice but is 
not very productive. If you do not like how titles take so much space in 
horizontal panels, you might find vertical panels more appealing. Maybe add to 
your tint2rc:

panel_position = bottom left vertical
panel_size = 100% 152
task_text = 1

and move the launcher at the bottom? Just a suggestion.

Original comment by mrovi9...@gmail.com on 29 Mar 2015 at 10:05

• Added labels: Component-Tint2conf

[GoogleCodeExporter]

Ok, thank you for the tips regarding parent-child sorting.

I think the icon identification is already solved (at least for my use), the 
child-parent sorting will/would be just some fine tuning seeking perfection for 
additional aesthetic value when the icons are different actually, as in the 
case of Evolution and its e-mail windows that I mentioned.

Anyway, thank you for the tip on adding the task titles back and using a 
vertical taskbar (the second would require some training of an old brain used 
to something, but I shall try :) ).

I'll continue with some experiments and if it comes to something useful I'll 
update it here.  Thank you for accepting this feature, my friend.

Original comment by marcelof...@gmail.com on 29 Mar 2015 at 11:27