[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]