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

List:       kde-core-devel
Subject:    Re: Kicker ideas
From:       "Wilco Greven" <j.w.greven () student ! utwente ! nl>
Date:       2000-04-28 16:19:35
[Download RAW message or body]

On Fri, Apr 28, 2000 at 06:07:59PM +0200, Matthias Elter wrote:
> On Fri, Apr 28, 2000 at 05:41:03PM +0200, Wilco Greven wrote:
> > On Fri, Apr 28, 2000 at 05:23:33PM +0200, Matthias Elter wrote:
> > > On Thu, Apr 20, 2000 at 01:50:01PM +0200, Wilco Greven wrote:
> > > (...)
> > > > While looking at how the appletpositions are stored I got the \
> > > > following idea. At the moment the relative position of an applet \
> > > > with respect to the applet to the right is stored. I think a better \
> > > > solution would be the following. The 
> 
> On the left! Is this a typo or are we talking about different things?

Oops, a slip of my brain.
 
> > > > space on the panel can be divided in space occupied by applets and \
> > > > empty space.  You could calculate the position of an applet if you \
> > > > know the percentage of  the empty space which is on the left/upper \
> > > > side of the applet.  
> > > > It is shown in the following example. A, B, C,.... are applets, and \
> > > > a dash is  a unit of whitespace. There are 10 dashes, So one dash \
> > > > makes 10%. 
> > > > A---B-C-----D-E
> > > > 
> > > > In that case the value for A would be 0, for B 30 and for C 40.
> 
> Hmn. From your explanation above I would say:
> 
> A : 0
> B : 30%
> C : 10%
> D : 50%
> E : 10%
> 
> Makes a total of 100%. Right?

It doesn't matter how you represent the values. I did it cummulative, but \
it all means the same.
 
> 
> > > > This approach has the following advantages:
> > > > 
> > > > - When you work with different screen resolutions, your panel would \
> > > > always look the same.
> 
> Yep!
> 
> > > > - Implementation of moving of applets would be easier. When you \
> > > > move an applet really fast over some other applet, the positions of \
> > > > the applets won't be switched.
> 
> I consider the position switching a feature as moving an applet does not \
> mess with the rest of your layout. If you do not switch positions you \
> might have to move the other applets/buttons. The GNOME panel has a \
> secound move-mode so that applet positions are fixed ... I'm perhaps \
> going to implement this, too.  
> 
> > > > Of course there will be disadvantages, but I can't think of one \
> > > > right now.
> > > 
> > > Thanks for the suggestion. While I like the idea after thinking about \
> > > it I can see serveral problems. All of which can be solved but this \
> > > needs quite some work. It's on my todo but way down as there are more \
> > > important things to implement and the current layout code works.
> > 
> > Yes, you're right. One of the problems would be what to do when all the \
> > applets don't fit on the panel. Furthermore I didn't consider different \
> > panelsizes when when I got the idea.
> 
> I see no problem with different panel sizes as we are talking about \
> percentual values but perhaps I miss something? In case there are more \
> applets than panel space there is no free space to divide. So 50% of \
> nothing would simply be zero. I might try to implement the proposed \
> layout mechanism tonight.  
> > What's your opinion about the scrollable appletarea. Do you think is \
> > useful? Or should it be avoided when possible?
> 
> IMHO it's a must have feature! (but currently is buggy)
> When I change my screen resolution or move the panel from bottom to left \
> my applets/buttons might not fit on the new panel size. The scroll \
> feature should be avoided in normal use, placing more applets on the \
> panel than there is space does not make much sence but it gives the user \
> a chance to access their applets if the panel size for some reason \
> changed.  

Ok, that's what I meant by avoided when possible. This solution certainly
is a lot better than the solution of the GNOME panel, which doesn't show 
the applets that don't fit on the panel. 


> Again, thanks for your suggestions!
> 
> -- 
> Matthias Elter
> elter@kde.org
> me@caldera.de
> 


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