>> - applet manages top level widget (for example to make menu button that >> partially obscures window - yes, I know, this is hack, but I know also >> that >> one of Plasma developers suggested this) and it should be hidden when >> panel >> is hidden and shown when shown; > > we manage to do this with the system tray just fine, and it's doing > exactly > this sort of hack. that said, these sorts of hacks should not be > designed for. > they are hacks, and not of the good sort. :)
Yes, hacks, especially dirty hacks, are bad thing, but in some cases they are needed... Currently personally I would need (as far as I know, maybe there is better solution) top level widgets managed by plasmoid in three cases: - 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); - in my task manager applet (MacOS X dock like) for icons moving outside panel in zoom animation; - I'm also thinking about working on next alternative menu, with this fancy button that moves outside panel (yes, I know, like in Vista, but many users love this... personally I don't like things that permanently obscures part of window). And there is problem when panel hides, is it currently possible to do something with these widgets visibility when it occurs, without having kind of notification mechanism (I don't how exactly it is done in systray, but there it works)? Anyway, I agree that this part of suggestion could be something that it is not required. By the way, I was also thinking about possible use of constraints but forget to write. :-D It could be clearer to find what it does when it would be well documented (one sentence is often not enough if you first use new API). >> Additionally there could be added slots (or signals emitted by applet, >> so >> only specialized containments could get and handle these request) to >> show >> and hide containment (panel), for example showContainment and >> hideContainment. > > i'm ok with the concept of this, but the API should describe what the > widget > needs, not what it results in because that's not something we can know > from > inside the plasmoid. I'm afraid that I'm better in suggesting than projecting API that must be good from start and be enough even some years later. ;-) 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 (for example show menu or something) it will be triggered when trying to unhide panel (I saw this in Tasks applet and I can't use it my plasmoid, Fancy Tasks, because I'm using shortcut for displaying menu). I've more suggestions about current status of keyboard shortcuts for applets, but these should be discussed separately. ;-) >> Hiding slot could be used to achieve manual hiding (click >> on plasmoid that invokes this slot, unhiding done like in autohide), > > forced hiding should probably be avoided, actually; but when needed then > probably a call to Applet::releaseVisualFocus should reset the count to > zero > (and all applets in the containment as well)... still, i think this > would make > more sense as part of the View itself rather than part of the > containment. I see this method as easiest possible way to reintroduce manual hiding of panel (lack of this is for me bigger problem that need of using Panel Spacer for applets positioning ;-)) by introducing simple plasmoid for triggering hiding. And I don't like autohiding, when everything moves to often (it would be useful for me for example only for hiding tasks list when I want to hide names of running apps when someone watches ;-)). _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
