*** Bug 325425 has been marked as a duplicate of this bug. ***

Ok guys!
We're right now trying to implement the following to increase the usability of the grouping. Please give feedback if you see major weaknesses of this idea.

--------------------------------------------------------

Here's our heuristic on how we calculate the priority with which an application is _not_ grouped. Meaning that applications with a lower score are more likely to be grouped.
This heuristic is rather complicated and still has to prove to work. It consists of three main elements.

1. How much has the application been used in the near past?
2. How many windows does the application have opened?
3. Is the application already grouped?

To get a nice number telling us, how much the application has been used in the near past, we first introduced an exponential smoothing over the time. Each time we switch applications we add the difference in time since the last switch to our old, exponentially smoothed factor. We further assume that the added time can not exceed 10 minutes (due to possible idle times) and our exponential smoothing should result in cutting the factor by half every 5 minutes. Making these assumptions we acted on gut level. However: This results in a very exponentially distributed range of numbers from 0 up to 800. We will deal with that problem afterward.

This results in the following formulas:

a) if the application has not been used in the previous period

x(T) = x(T-1) * 0.998997^(Δt)

b) if the application has just been used

x(T) = x(T-1) * 0.998997^(Δt) + min(Δt, 600)


The number of windows opened (n) is basically taken as a factor by itself. With not being able to group single windows and not wanting to group multiple windows, we decided to use n-1

Out of this we create the following score:

r = sqrt[ x(T)] / (n-1)

The square root is to smooth out the strong exponential nature of x(T).

Now we still didn't take into account whether or not our application is already grouped. This is rather important to prevent constant grouping and ungrouping. Therefore we decided to just subtract 1.5 from our score "r", if the window has been grouped before. The final score for grouped applications hence reads as:

s	= sqrt[ x(T)] / (n-1) -1.5

for ungrouped apps:

s = r

Hmm, except for the fact that it should read 0.9977 instead of 0.998997 it works just as expected :)
Now only using it will show, if it renders usefull.

Created attachment 56640 [details] [review]
patch implementing the suggested behaviour

I changed this bug to just deal with the grouping. Button size is discussed in Bug 310809.
However: Grouping is strongly related to button size, because grouping should only take place, when there's no more room left in the tasklist.

Ok, testing turns up, that the algorithm should also consider, the window, the user switches to and "not-group" it with a higher priority. As for now, we'll just add 1 to the overall score.

First of all, you'll need to note my bias that libwnck task grouping is very broken and that I am close to believing that it can't possibly be fixed.  That might not have any relevance here, but I'm just letting you know my biases.  I don't know what the other three co-maintainers think.  However, if you guys are really interested in grouping bugs though, I'd love for you to go through all the bugs being tracked under bug 155904.  (You may even be able to mark some of them as duplicate of this one, as I don't have the time to go back and check at the momemnt).

Anyway, is this patch just a complicated way of implementing group by LRU (least-recently-used)?  (Such as Windows XP does, as claimed by bug 
59692 anyway?)  If so, that seems more sane to me than any other way of grouping.

Your explanation touched briefly on some high level things you wanted to measure, then went into detail on the low level stuff (and the patch had no further comments on the topic).  I didn't catch the connection of exactly what was actually being measured and why you picked the formulas you did.  It'd be great if you could explain the behavior you're trying to achieve and how and where the formulas help you achieve that (e.g. why an exponential over other functions, why the constants you picked, etc.).

From a quick glance over the patch:
  - Please use the -p option when generating patches
  - I'm not a fan of the GTimer thing.  I'd much prefer that the scoring were updated in response to the active window changing rather than timeouts firing.

Thanks for working on libwnck.  :)

> - I'm not a fan of the GTimer thing.  I'd much prefer that the scoring were...

The GTimer just gives us the time for our algorithm. Scoring is only updated on changing either desktops or active windows.

So to answer you other questions:
I went through some of the bugs and noticed that most of them actually cannot be considered dups of this bug. Tthe only one that can is Bug 59692, in my opinion.
Afterall this patch does only change _what_ applications are being grouped.
Yes, it is a "complicated" way of LRU. Maybe we should call it 'smart LRU', because using the exponetial smoothing we add the component of time to the algorithm.
This smartness means that if I use an application for 10 minutes, and then switch between differen applications within the next 1 minute, the application I used 10 minutes long, will still be unlikely grouped, because I just recently used it for a long time.... after 5 minutes, the application I used for 10 min is a lot more likely to be grouped.
Furthermore we thought that the last used application should be rather unlikely to be grouped, unless there are good reasons to group it.
Both of these approaches brought us to the idea of using the exponential smoothing, because it allows us to give high priority to very recently used applications, while not neglecting the applications that have been used before.

We also figured, that we rather want to group applications with many windows than applications with only few windows. The reason behind this is, that grouping and regrouping is disturbing. Hence if we group many windows the first time, we group, we won't need to regroup too soon , if more windows are being opened.

To further prevent regrouping we made it harder for existing groups to be again broken apart.

As for the exact parameters: Well, they are chosen on gut level. We thought that it might be good to divide the importance of usage time by half every 5 minutes a program has not been used. This brought us to the number of 0.9977.
We felt that grouping rather many windows was quite important and hence are using a rather linar approach for this... with means dividing by the number of windows. Since a single window can't be grouped and it should happen rather seldom, that 2 windows are grouped, we decided to substrag 1 before the division. With this the theoretical score of one window being grouped (1/(score for not being grouped)) goes toward 0.

What we definitely need to add is that the application one switches to is less likely to be grouped. We'll do this by just adding 1 to the score of the active window.


Well, there is no "right" way of chosing the parameters. There can be a better way but one can only tell from usage. Also the algorithm itself can probably look different. But this one is rather simple and understandable.
We hope that with this (and fixed _start_ of grouping) the taskbar will flicker less and not be in the way of the user as much.

*** This bug has been marked as a duplicate of 77942 ***

(Accidentally resolved, reopening.)

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libwnck/issues/55.