From kde-core-devel Fri Apr 28 16:19:35 2000 From: "Wilco Greven" Date: Fri, 28 Apr 2000 16:19:35 +0000 To: kde-core-devel Subject: Re: Kicker ideas X-MARC-Message: https://marc.info/?l=kde-core-devel&m=95693893629167 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 >