[Panel-devel] Allow TaskBar Context Menus

[Aaron J. Seigo]

On Saturday 20 October 2007, Robert Knight wrote:
> > the layout should try to push other things out of the way - and then let
> > them go back when it shrinks.
>
> In Qt, layouting is a top-down process.  I don't know exactly how
> Kicker operates, but following the Qt pattern the system tray applet
> would inform its managing layout that its size constraints have
> changed

correct. however, for panels there are some additional and rather unique 
requirements. namely, everything has to be visible and the panel itself can't 
change size (well, it can if the user says it can, but it also has to deal 
with hard constraints on the size as well). unlike in a dialog where every 
widget is allowed to simply do whatever it wants, the panel must handle it's 
space cooperatively so that all the applets get an optimal presentation. it's 
much easier when one can just expand infinitely, though that does lead to 
annoyances like dialogs resizing due to contents or needing scrollbars in the 
control panel to ensure a rational window size is maintained.

in kicker, this led to making it so that applets could advertise themselves as 
expanding to full width. this played really badly with 
expand-as-required-to-fit-contents panels: to expand and applet to "full 
width" requires knowing what "full width" means, but if you are trying to 
resize to the minimal size needed then you don't know yet what "full" means. 
it leads to a catch 22 that is not very pleasant to solve and leads to 
bizarre behaviour from the user's perspective.

there are other issues that come up, but that one is probably one of the 
better examples.

> > of course, there would be spaces between applets if layouts had been done
> > according to my original suggestions. instead here we are fighting with
> > the exact problems i said would come.
>
> I remain unconvinced that your suggestion will work.

can you please provide an explanation for this POV, as i have done so (a few 
times now) for the current layouting approach? i've given a concrete 
suggestion here, i'd appreciate a concrete response. this really isn't one of 
those things one has to see like artwork or visual effects to comment on.

> The normal thing 
> to do in this case would be for you to create a branch of plasma in
> branches/work, implement the panel as you think it should be done.
> The rest of us can then check it out and if it meets the requirements,
> merge it back.

maybe it's just me, but this really struck me the wrong way and i'm left with 
a bad taste in my mouth. i suppose it's because it feels like you're telling 
me that i can no longer commit to my own code base, and this is not the first 
time either. which is pretty ... unbelievable. i feel like there is a power 
struggle going on here and i'm not quite sure the reason for it, but this 
situation is having a negative impact on me, and i'd assume others. i'd like 
to find a way to resolve it.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071020/03aefcfb/attachment.pgp