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

List:       kde-panel-devel
Subject:    Re: Signals and slots for containment show and hide actions (mainly
From:       Emdek <emdeck () gmail ! com>
Date:       2009-03-31 10:25:16
Message-ID: op.urni8eq2e84fud () michal
[Download RAW message or body]

> > - 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.


_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


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