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

List:       kde-core-devel
Subject:    Re: Kicker ideas
From:       m_elter () t-online ! de (Matthias Elter)
Date:       2000-04-28 16:07:59
[Download RAW message or body]

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?

> > > 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?

 
> > > 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.  

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]