Signals and slots for containment show and hide actions (mainly for panels)

[Emdek]

>> - in my Run Command plasmoid that uses KHistoryComboBox to make it
>> work in panels (I've created report about problems with them and others  
>> on
>> GraphicsView);
>
> this is working around a problem in QGraphicsScene/View, really; it will  
> get
> fixed (it's being worked on) so there's no reason to hack around it  
> today.
> there may even be other ways to do it nicely with the combo being  
> "manually"
> shown as the popup for the applet, which would also keep the panel from
> hiding.

They are working on this bug? Finally, thanks for information. :-)
But I hoped that this will be fixed for Qt 4.5...
I'm not sure if Qt 4.6 will be released in this year, so it could be possible that users (including myself ;-)) would need to wait probably for KDE 4.5 in mid 2010. But what can I do now with this?
I was already thinking about "own" list emulating that from combo, but there is still problem with not working context menu and no way to get focus on field when in panel (or probably when there are windows on the desktop).
I was thinking also about turning combobox into lineedit for panels but then it would be less usable and there are still chances that context menu would not work...
So maybe temporary hack could be best and easiest solution before it would be fixed upstream?
I want to update this applet during this or next weekend to make it usable for panels (I think that it is most typical place to put this kind of applet).
Small off topic, I'm interested in moving my applets to KDE SVN playground. I've already requested and get SVN account and I've stupid question, do I need do something before try to commit them there? ;-)



> again, compositing and input masks.

Thanks, but I still don't know what to do. ;-)
I think that there could be added page on techbase or somewhere with collections of this kind of tips and tricks (not only tutorials, these things are probably too small to make own tutorial for each). For example I've earlier working on media player applet and I couldn't find (and still don't know, after some months) how to make it play file when created by dropping supported MIME on desktop (I've found this part, how to add it to menu) but I couldn't find which API part (or maybe something else) must be added to make applet open that file on init.



> the tray tracks the location of the QGraphicsWidget and manually  
> positions the
> items. this is fraught with problems, though, such as not being able to  
> be
> visible in more than one view at a time, not working when zoomed out ...  
> same
> kinds of problems any "manage a top level QWidget" approach will face  
> actually
> (c.f. the "embed an application window" plasmoid)

But sadly not everything could be done clean now, but for temporary solutions kinds of these hacks could be used, but not forever and only if it is not possible to do it better.



> if you have specific questions, we can certainly answer them (and add it  
> to
> the apidox as well)

The problem was in KDE 4.1 docs (there was no description for this enumerator), now I see that for KDE 4.2 this is fixed, but I see that descriptions are probably in wrong lines in source:
http://api.kde.org/4.2-api/kdelibs-apidocs/plasma/html/namespacePlasma.html#a48d70b0c4dcabb6dfbd8dfedb964eea



>> But your example
>> with widgets and containment is very interesting. One thing is clear (at
>> least for me ;-)), that using applet's activate signal for unhiding
>> autohidden panels should be separated from activation that comes from
>> activation of applet's keyboard shortcut, because when you want also to  
>> use
>> it to perform action
>
> yes, that's a good point. so we could use this same thing in that case as
> well.
>
> so now we just need some sort of name for this :) we have  
> releaseVisualFocus()
> ... so .. requestVisualFocus(bool)? releaseVisualFocus would remain a  
> heavy
> handed "hide things!" signal, and requestVisualFocus would allow one to  
> ask
> for visual focus or to notify it isn't needed anymore.
>
> maybe it should be two method? i just can't think of two good names for  
> it :)
> anyone else?

I've seen similar names in Tasks applet. ;-)
requestVisualFocus(bool) seems to be good name for it.



>> I've more suggestions about current status of keyboard
>> shortcuts for applets, but these should be discussed separately. ;-)
>
> sure thing (and yes, there's more work to be done there, indeed!)

Ok, so probably I'll start new thread later today, now I'm tired (when I was answering to your message it was 2 AM in my time zone, and yes, I'm saying to myself that I should go sleep earlier but this usually doesn't help when I'm working on something :-D).



> thing is that hiding is an attribute of the View, not the Containment.
> plasmoids that only work on some views (PanelView) but not others
> (DesktopView, DashboardView, MIDView, etc) are no-nos. so i think this is
> something that should go directly into PanelView itself.

I'm not familiar with this part of Plasma internals currently, so I simply don't know, I've read in SVN that there is something like this, but I didn't need to know how it works thanks to abstraction. ;-)
By the way, is there possibility to restrict (disallow placing or show warning) usage of applet to given type of containment / view?
For example this "manual hiding plasmoid" would make sense only for "hideable" containments / views. But maybe there is, or could be in future, way to query Plasma for existing containments of given type and offer to user list of them - when more than one - when for example on desktop. This could be used also for "quick unhide all panels" button for example.
Anyway I'm still looking for way to achieve manual hiding, and I think that it should be don as flexible as possible (possibility to create plasmoid for this task gives very big possibilities), not as specific part of containment / view like these ugly buttons with arrows for hiding (I didn't like that they stay on screen after hiding but also know that it is for most of users easiest way to find way to show them again). So maybe this could be achieved by giving user possibility to decide (by options) what should containment / view do when hiding is requested - hide completely and unhide when requested by kind of signal or moving to edge like with autohide or show kind of indicator all the time when hidden (maybe constant glowing? rectangle buttons really looks ugly, rounded and partially transparent thing would look better than them). I'm also not a fan "configure everything what possible and even more" (but also like some advanced options, on special page for example - not hiding options after selecting kind of "newbie" profile) so I think that if something would be done there should be decided which behavior should be used.