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

List:       kde-core-devel
Subject:    Re: kicker applet move code
From:       "Wilco Greven" <j.w.greven () student ! utwente ! nl>
Date:       2000-04-28 13:42:37
[Download RAW message or body]

On Fri, Apr 28, 2000 at 02:53:07PM +0200, Matthias Elter wrote:
> On Fri, Apr 28, 2000 at 02:43:04PM +0200, Wilco Greven wrote:
> > Hi,
> > 
> > Let me say a couple of things about this. I have asked on this list two times 
> > about the original behaviour. Nobody answered to my messages. I sent a Cc of 
> > the second message to you Matthias, you haven't answered too. Now you talk
> > like you're surprised I implemented the new algorithm.
> 
> I was very busy with non-KDE stuff at that time and probably missed your mail. When \
> I'm busy I sometimes hit the delete key to fast when browsing new mail and do not \
> read mailling lists very carefully. 
> > I let two of my roommates compare try both the old behaviour and the new
> > behaviour simultaneously. It was the first time for them to use kicker and the
> > new behaviour felt better according to them. I didn't tell them which behaviour
> > I implemented so they were objective. If they had chosen the old behaviour I
> > wouldn't have commited my new code.
> 
> As I said in the reply to my original mail I like your code but was disapointed as \
> it was totally broken for tiny panels. Don't get me wrong, I don't complain about \
> small bugs, new code always has some but please check if your code works before you \
> replace working code. It definitely did not for tiny panels.

You are right about the tiny panels. I have to admit I didn't test it for them.
Sorry for that. I think it's broken for tiny panels because the applets are 
very small then ( < 2x the switchMargin ). I saw you disabled the 
switchMargins. That's a solution, but perhaps a better solution would be to 
make the switchMargin depend on the appletsizes. The idea behind the 
switchMargin was to create a buffer so that when two applets switch position 
you have some room to move the cursor before the applets switch back again. But
maybe the switchMargin isn't needed at all. I'll do some tests.

Now something else. Maybe it is better to determine the position of an applet by
the amount of empty (panel)space left of the applet. I think you could solve
some problems by this approach. For example the speeding bug (moving an applet
really fast). And this gives an opportunity to make the applet position
resolution independent (by scaling the empty space). Just some thoughts.

Nice work on the configuration menu, BTW :-)

Greetings,
Wilco

> 
> (...)
> 
> Cheers,
> Matthias
> 
> -- 
> Matthias Elter
> elter@kde.org
> me@caldera.de
> 


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