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

List:       kde-devel
Subject:    Re: Kicker patches (was Patches and enhancements for KDE 3.5)
From:       Benoit Minisini <gambas () users ! sourceforge ! net>
Date:       2008-07-24 20:31:17
Message-ID: 200807242231.17095.gambas () users ! sourceforge ! net
[Download RAW message or body]

On jeudi 24 juillet 2008, Aaron J. Seigo wrote:
> On Thursday 24 July 2008, Benoit Minisini wrote:
> > I continued on fixing kicker transparency, and many other problems. Where
> > should I submit my patches? I think the kicker mailing-list is
> > deprecated,
>
> there never was a kicker maling list. there were never more than 2 people
> working on things, usually just one. makes a mailing list useless ;)
>
> > and I don't think I should put them on the plasma mailing-list.
>
> probably not.
>
> > - I added a SimpleArrowButton class and used it to replace many arrow
>
> added where? 

There is a SimpleButton class in libkicker, the shared library used by every 
applet. I added SimpleArrowButton in that library.

> and what does it look like? perhaps you can upload your 
> patches somewhere and then post links to them here.
>

I will show a diff of my patch as soon as possible. I must do some cleanup 
before.

> > - I used SimpleButton in the launcher and in the weather applet, so that
> > their buttons look the same as panel buttons. It allowed me to remove
> > duplicated code from the launcher applet.
>
> i assume by "used SimpleButton" you mean you copied the file over to these
> applets? weather applet didn't live in kdebase...
>

I was not clear. I didn't copy the code, I just reimplemented the weather 
button class the same way as SimpleButton.

> > - I fixed the ContainerArea and taskbar transparency background when they
> > are scrollable. To do that, I used 'setBackgroundOrigin(WindowOrigin)'.
> >
> > - By using WindowOrigin, I didn't need to duplicate pieces of the
> > ContainerArea background pixmap in each applet anymore.
>
> i doubt this will actually work in all cases. i don't remember exactly
> which situations that i ran into with this approach, but i didn't go
> through all that work just because i liked writing more code. at one point
> i was setting the background origin everywhere, but it would fail rather
> annoyingly at times (perhaps certain configurations? hrm.. i really can't
> remember)
>

AFAIK, almost all transparency algorithms in all the places I looked duplicate 
what Qt does with WindowOrigin. Some widgets that redraw their background 
because they need (for example the clock applet with anti-aliasing) are often 
buggy because they don't take into account the backgroundOrigin() property.

At the moment, I have just problems with the system tray and with applets I 
didn't look into.

> > - I removed the one pixel border when kicker has a background image. (Why
> > a border in that specific case?)
>
> because not all kicker wallpapers have a defined edge and relied on that
> one pixel. i removed it at one point and it broke many wallpapers visually.
> so it remained for compatibility. it should not be removed for that reason.
> no, it's not great, but there it is.

Argh. I will put it back so.

>
> > - I removed the useless margin around applet handlers.
>
> useless except to provide some whitespace when shown. probably makes quite
> a difference when they are set to always be visible (as they once were). i
> personally wouldn't suggest this change.

I really never noticed this space until I deep into the code and start fixing 
the transparency. It is two pixels wide, and brings nothing visually, whether 
the applet handler is always visible or not.

>
> > - I wanted that coverable panels stays on the background, even if you
> > click on it, but I didn't succeed. I think that the "show desktop" button
> > is enough to access this kind of panels. After all, if you allow windows
> > to cover them, it should mean that you want the panel to stay in the
> > background, no?
>
> no. it just means "let windows cover it as i use it". if you change this
> behaviour, you'll annoy people who are used to and like the current
> behaviour.
>

OK, I will put it back. But I don't see the logical of the current behaviour.

> > - I made kicker automatically restart when the KDE widget style change.
>
> that sounds very unusually and really not good.

This is what happens already when you change the configuration of application 
starting visual feedback.

>
> > Otherwise, many widget layouts become invalid.
>
> in what way?

Because the ContainerArea class caches its layout, and many applets do their 
own layout calculation too, by caching some information that depends on the 
style. And when the style changes, they don't recalculate it. 

I don't think I can fix every piece of code that needs relayouting when the 
style changes, so I chose this simple solution. I admit it is not clean, but 
it works. 

Normally, the user does not change his KDE widget style every minute normally, 
and I think he will prefer that kicker is restarted automatically instead of 
having to logout and login again.

>
> > - I have problems with the system tray applet transparency yet.
>
> and you probably always will. the systray spec is not designed for
> transparency and it's all a bunch of hacks.
>
> > Well, please tell me which fixes and changes could go in the KDE code.
>
> for the ones i didn't comment on above, it's impossible to say without
> seeing the actual patches.

OK, I will show them soon.

Regards,

-- 
Benoit Minisini
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]