[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gnome-devel-list
Subject:    Re: window list applet
From:       Denis Yeldandi <del () delsite ! ru>
Date:       2003-10-27 19:43:52
Message-ID: 3F9D7578.9030305 () delsite ! ru
[Download RAW message or body]

Havoc Pennington wrote:

>On Sun, 2003-10-26 at 12:28, Kjartan Maraas wrote:
>  
>
>>Please put the patches in bugzilla.gnome.org. The window list lives in
>>the gnome-panel product under the component "Window List Applet"
>>
>>    
>>
>
>Ideally attach the patches in bugzilla in plain text, uncompressed.
>  
>
Done.

>                                          
>          If we add more toggle buttons to the prefs, so we have N toggle
>          buttons, then we have 2^N or something combinations of settings.
>  
>
Well, I do not really think we should treat that as N-dimensional 
space.  Lets say, you have to answer N questions. If i-th answer is 
"negative" for you, it is negative disregarding other questions or 
answers. Sort of... :)

>                                                                             
>                                          
>          What I want to know is, which of those combinations are useful.
>  
>
As I said before, we should not think about combinations.

>                                                                             
>                                          
>          In other words, how many big picture different "usage modes"
>          are there for the task list.
>  
>
In my experience, one can answer about 5-7 questions before he gets 
annoyed :)

>                                                                             
>                                          
>          This is an essential step to understanding how we could simplify or
>          make more useful the settings, and to understanding why each usage
>          mode is useful and whether we could create a usage mode combining
>          the best of all worlds.
>  
>
I don't think we can create one mode, combining all the best. Some 
person may like minimized windows from other workspaces, but I hate it. 
One of us would be unhappy.

>                                                                             
>                                          
>          It also allows us to understand whether the usage modes have
>          interactions with other desktop GUI decisions (if so, then
>          the usage modes are potentially going to cause problems,
>          because then you have to make those other GUI decisions configurable
>          also, and you get cascading combinatoric preferences hell).
>  
>
What kind of interaction do you mean? And what other GUI decisions?

>                                                                             
>                                          
>          So basically, I would like someone to list:
>            - all the settings that exist now
>  
>
Ok, I would mark out 3 groups of settings.
- Workspaces content. That is which windows from which workspaces to 
reflect in the list and what to do with them when restoring. I do not 
make the list show all workspaces, so I do not care about restoring. But 
that's me, and it doesn't mean this setting is useless.
- Grouping. When to group. Pretty nice and clear, except we cannot 
control when the grouping starts, in case of autogroup.
- Size policy. That's what I found the worst thing. I had always wanted 
the list to be at the maximum size it can be, showing the buttons not 
too large, let's say not bigger than a given size. But what I had was 
very odd buttons behavior, the list could change its size when I focus 
other window, with 2 buttons it could be longer than with 3, and 
changing minimum and maximum size of the applet didn't really help. 
That's why I made another parameter, maximum button size. When you set 
that, the applet shoud get as big as possible, but the buttons should 
not get bigger than this size. Well, you may call it a different mode, 
or different settings, but it *is* a size policy.

>            - the various settings that have been proposed
>  
>
What else I'd like to propose is the sorting policy. Right now buttons 
in the list are sorted by window class and application, what I find not 
really handy. If I open mozilla, terminal and another mozilla, I expect 
the second mozilla to be at the end of the list, that is at the 
rightmost position, but it appears in the middle.

>            - enumerate each combination of those (possibly lumping
>              some combinations together)
>            - write down which combinations are useful "modes," and why,
>              and which combinations are useless
>  
>
For me, only the content of other workspaces is useless, everything else 
is fine, and sometimes I'd like to change that on the fly.

>            - from this see which settings are "standalone" and which
>              interact to create "modes" of tasklist usage
>        
>        If we do this, I think we will understand the problem a bit better,
>        and be in a position to guess at the pros and cons of adding each
>        setting. I would not be surprised if it turns out that some of the
>        settings we don't have are more useful than some of the ones we do
>        have.
>                                                                           
>        
>I think doing this homework is a prerequisite to applying patches to add
>more behavior modes to the window list.
>
>Havoc
>
>
>  
>



[prev in list] [next in list] [prev in thread] [next in thread]