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