Re: Manual Hiding of Plasma Panel (desktop shell)
2010/3/4 Andrew Hunt andr...@ahunt.org: Progress has gone quite well, here are a few screens (cut and combined into one file): http://img697.imageshack.us/img697/5606/manualpanel2.png Must it look so similar to old look from KDE3? ;-) In comments to that bug I've written how it could work: https://bugs.kde.org/show_bug.cgi?id=158556#c33 Maybe at least these buttons could be shown when moving cursor to edge? Both, for hiding and at least showing panel (to not obscure windows). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
Hi, I'd like to step in to defend the interests of us KDE users who won't use this feature. I want to make sure that it can be configured to not interfere with my current workflow. My rational is that I've always found this KDE 3 panel feature a little bit annoying, and now the use case it provides (showing and hiding alternate panel configurations) is better supported by Activities in a more general way; so I won't have a need for manual hiding. When I'm low of screen space I've always used auto-hide anyway. One possibility is just having an option to disable it, and make disabled the default setting. Users who remember the 'hide' button from KDE 3 will know to turn it on, and those first introduced to KDE 4 won't find a feature that changes the previous behavior of hotspots like the panel edges and the screen border. But if the 'hide' buttons can be implemented so that they don't interfere with the current hot spots, I'm in to have them enabled by default. I liked the idea someone proposed to create those buttons as plasmoids so that each user can decide where to place them (either inside the panel or on the desktop). I'm concerned about the buttons taking the screen or panel edges, and/or displacing or overlapping the panel contents. If this is the behavior of this feature, I'd certainly ask to have an option to disable it completely. Thanks for your attention. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Plasma virus wallpaper no toolbutton
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/3143/ --- Review request for Plasma. Summary --- This patch replaces the QToolButton (to select a custom background image) in the virus wallpaper config dialog with a KPushbutton. This way the button label is shown and the dialog now looks more similar to the ones from the 'image' and 'slideshow' wallpapers. Diffs - trunk/KDE/kdeplasma-addons/wallpapers/virus/virusconfig.ui 1098825 Diff: http://reviewboard.kde.org/r/3143/diff Testing --- Thanks, Sascha ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
On 5 March 2010 12:12, Diego Moya wrote: I liked the idea someone proposed to create those buttons as plasmoids so that each user can decide where to place them (either inside the panel or on the desktop). Oh - I forgot: another really good option is having the hide button showing only under the cashew. This way it doesn't waste screen space so it could be always available (no configuration option needed), doesn't interfere with the panel contents, and is integrated with all the other panel configuration features instead of being just another new inconsistent way to handle the panel. The icon for the closed panel could be the cashew as well. The only drawback is that it will need two clicks to hide instead of one. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
On Friday 05 March 2010 09:44:33 Emdek wrote: there is a ToolButton class which is a subclass of QToolButton but which provides plasma stylings. i wonder if that might look nicer here? just #include toolbutton.h and then do new ToolButton. I've done that. Thanks for pointing it out. I was looking at the wrong toolbutton. Because the buttons have a different shape they don't quite fit in with the curved end of the panel, but that can still be worked out; otherwise I think they do look better. also, is it necessary to have a separate unhidebutton rather than just use the hide buttons themselves to both hide and unhide? The reasoning behind having them separate is that the hide buttons are part of the panel view, the unhide button is a separate item that appears on the desktop, similarly to the glowbar that has also been written as a separate object. I.e. I don't have to remove the hide button from the panelview and place it onto the main desktop, and vice versa if the buttons are separate. An alternative would be to simply move the panel sufficiently off screen so that only the hiding button is still on screen, but I'm not sure whether that's pos sible, and what workarounds that would need for multiple screens. the hide button names are a but unfortunate as well; perhaps m_hideLeftTopButton and m_hideRightBottomButton? a bit more self documenting. I'll do the names. I just wasn't sure which version would be better. instead of setting the margins on the containment, set the contents margins on the PanelView itself. then position the button inside of the PanelView itself. this is guaranteed not to break, regardless of what the containment tries to do. i'd also position the buttons so they overlap the border of the svg. e.g. for the right-hand button in a horizontal panel, something like: qreal left, top, right, bottom; containment()-getContentsMargins(left, top, right, bottom) setContentsMargins(0, 0, m_hideButton.width() - int(right), 0); m_hideButton-move(0, geometry().right() - m_hideButton.width()); (obviously would need to be generalized for vertical panels and top/left/right/bottom buttons) I'll try that once I have time to do some more real work on it. apart that ToolButton should be used instead, don't really like a fuction that does enabling -and- repositioning in one. positioning should be done by a layout, really If you're talking about the unhide button: the repositioning can't be done earlier though since we don't know where the panel is going to be hidden to. With the hiding buttons: I'll try get a layout ready for the hiding buttons (i.e. in the panel view) though, I hadn't really thought of that before. Must it look so similar to old look from KDE3? ;-) In comments to that bug I've written how it could work: https://bugs.kde.org/show_bug.cgi?id=158556#c33 Maybe at least these buttons could be shown when moving cursor to edge? Both, for hiding and at least showing panel (to not obscure windows). Actually, I was myself thinking of making the unhiding button behave somewhat the way you described, or possibly just slightly transparent as to provide some visibility below it. However this could cause some usability issues: when you can see the unhide button (as in kde3), you just have to move the mouse over to that panel corner, click, and you're done: one fluid motion that takes me half a second. With an autohiding unhide button some more thinking is required (Where did I put that panel again?), making it's use inefficient -- i.e. I think the unhide button always has to be, at least partly, visible. Having touch sensitive unhiding would be interesting to try out, I might do some experiments with it, but I think that should be a later option, since it is rather complicated (at least for me). I'm not sure about the hiding of the button lengthwise though, since then the unhiding button/area has to cover the whole width, takes up more space, or if it's completely invisible until you're close by then you're getting the same problems as with autohiding, where buttons/panels appear/get in your way when you don't need them, and are hard to use when you do need them. I might experiment with that once I've got spare time, but at the moment I'm just trying to get working manual panel hiding that looks nice and works like it has before, without expending too much effort on it. But if the 'hide' buttons can be implemented so that they don't interfere with the current hot spots, I'm in to have them enabled by default. I liked the idea someone proposed to create those buttons as plasmoids so that each user can decide where to place them (either inside the panel or on the desktop). I'm concerned about the buttons taking the screen or panel edges, and/or displacing or overlapping the panel contents. If this is the behavior of this feature, I'd certainly ask to have an option to disable it
Re: Manual Hiding of Plasma Panel (desktop shell)
2010/3/5 Andrzej JR Hunt andr...@ahunt.org: Must it look so similar to old look from KDE3? ;-) In comments to that bug I've written how it could work: https://bugs.kde.org/show_bug.cgi?id=158556#c33 Maybe at least these buttons could be shown when moving cursor to edge? Both, for hiding and at least showing panel (to not obscure windows). Actually, I was myself thinking of making the unhiding button behave somewhat the way you described, or possibly just slightly transparent as to provide some visibility below it. However this could cause some usability issues: when you can see the unhide button (as in kde3), you just have to move the mouse over to that panel corner, click, and you're done: one fluid motion that takes me half a second. With an autohiding unhide button some more thinking is required (Where did I put that panel again?), making it's use inefficient -- i.e. I think the unhide button always has to be, at least partly, visible. Having touch sensitive unhiding would be interesting to try out, I might do some experiments with it, but I think that should be a later option, since it is rather complicated (at least for me). That unhide could reuse unhide from autohiding, less code duplication, less things to learn for user. ;-) And if someone decides to use that option the should know how to use it properly. ;-) If it there could be added hidden option (to set in file) to switch between these two ways to unhide then it would be nice enough. ;-) I'm not sure about the hiding of the button lengthwise though, since then the unhiding button/area has to cover the whole width, takes up more space, or if it's completely invisible until you're close by then you're getting the same problems as with autohiding, where buttons/panels appear/get in your way when you don't need them, and are hard to use when you do need them. I might experiment with that once I've got spare time, but at the moment I'm just trying to get working manual panel hiding that looks nice and works like it has before, without expending too much effort on it. There was interesting idea to check when to unhide auto hidden panels (from GNOME :-D), to check cursor acceleration, but this probably needs many work, but is interesting and could help in avoiding accidentally showing panels. But if the 'hide' buttons can be implemented so that they don't interfere with the current hot spots, I'm in to have them enabled by default. I liked the idea someone proposed to create those buttons as plasmoids so that each user can decide where to place them (either inside the panel or on the desktop). I'm concerned about the buttons taking the screen or panel edges, and/or displacing or overlapping the panel contents. If this is the behavior of this feature, I'd certainly ask to have an option to disable it completely. Don't worry: the feature is completely optional: it is simply an additional panel visiblity mode, i.e. instead of selecting Always Visible, Windows Can Cover and the like, you select manually hideable, i.e. the feature only appears if the user specifically selects it, and the default panel visiblity modes, and their behaviousr, are still the same as ever. As far as I remember I've proposed that first, to make these button applets and then for example use DBus to sya: Plasma, please hide or unhide panel with is located here ... or has id Applet could read id from panel on which it sits or it could be set manually (imagine applet on desktop that can hide / unhide all panels with one click). I really don't like idea of adding fixed things to Plasma, even toolbox maybe should be available through special applet, then it would be easier and cleanr to add it anywhere or easy disable. Less complexity and less code, bigger flexibility. I guess that this is idea behind Plasma, right? ;-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
On March 5, 2010, Emdek wrote: 2010/3/5 Andrzej JR Hunt andr...@ahunt.org: I'm not sure about the hiding of the button lengthwise though, since then the unhiding button/area has to cover the whole width, takes up more space, or if it's completely invisible until you're close by then you're getting the same problems as with autohiding, where buttons/panels appear/get in your way when you don't need them, and are hard to use when you do need them. I might experiment with that once I've got spare time, but at the moment I'm just trying to get working manual panel hiding that looks nice and works like it has before, without expending too much effort on it. There was interesting idea to check when to unhide auto hidden panels (from GNOME :-D), to check cursor acceleration, but this probably needs many work, but is interesting and could help in avoiding accidentally showing panels. imho doing it on cursor accel is a poor idea given the nature of mice; it would still trigger accidentally too often (hitting screen edges is what mice are good at ;) and it would not trigger often to people's annoyance. Don't worry: the feature is completely optional: it is simply an additional panel visiblity mode, i.e. instead of selecting Always Visible, Windows Can Cover and the like, you select manually hideable, i.e. the feature only appears if the user specifically selects it, and the default panel visiblity modes, and their behaviousr, are still the same as ever. As far as I remember I've proposed that first, to make these button applets and then for example use DBus to sya: Plasma, please hide or unhide panel with is located here ... or has id Applet could read id from panel on which it sits or it could be set manually (imagine applet on desktop that can hide / unhide all panels with one click). if you imagine all the edge cases and the configuration it would take to make this happen vs the actual benefits of it, it becomes very apparent very fast that this is would be a pile of hacks with little hope of ever being able to feel really good. -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
On March 5, 2010, Emdek wrote: In comments to that bug I've written how it could work: https://bugs.kde.org/show_bug.cgi?id=158556#c33 a plasmoid is the wrong approach. this is about views, not the scene, and it should not require special set up by the user. not to mention a 'hide button on my desktop' is a bit nonsensical and a hide button in the middle of a panel isn't a compelling use case. -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
2010/3/5 Aaron J. Seigo ase...@kde.org: On March 5, 2010, Emdek wrote: In comments to that bug I've written how it could work: https://bugs.kde.org/show_bug.cgi?id=158556#c33 a plasmoid is the wrong approach. this is about views, not the scene, and it should not require special set up by the user. not to mention a 'hide button on my desktop' is a bit nonsensical and a hide button in the middle of a panel isn't a compelling use case. But why not? DBus call for toggling panel visibility would be nice addition anyway. Then there could be applet for people who want different (and more advanced) approach and current implementation built in. Isn't it good settlement? ;-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
On Friday 05 March 2010, Emdek wrote: 2010/3/5 Aaron J. Seigo ase...@kde.org: On March 5, 2010, Emdek wrote: In comments to that bug I've written how it could work: https://bugs.kde.org/show_bug.cgi?id=158556#c33 a plasmoid is the wrong approach. this is about views, not the scene, and it should not require special set up by the user. not to mention a 'hide button on my desktop' is a bit nonsensical and a hide button in the middle of a panel isn't a compelling use case. But why not? DBus call for toggling panel visibility would be nice addition anyway. Then there could be applet for people who want different (and more advanced) approach and current implementation built in. Isn't it good settlement? ;-) no, a plasmoid has exactly nothing to do with any panel behaviour whatsoever Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma geolocation dataengine, Debian patch fixing compile errors with gpsd 2.92
Hi Petri,
I'm in contact with the Debian Qt/KDE packagers team and they asked me to
commit attached patch. I committed a similar patch to marble trunk / 4.4
yesterday.
Can I commit the attached patch to trunk and 4.4?
Kind regards,
Jens-Michael
ps: these are the marble patches:
http://websvn.kde.org/?view=revrevision=1098876
http://websvn.kde.org/?view=revrevision=1098879
Author: Modestas Vainius mo...@debian.org
Description: fix geolocation dataengine build against gpsd 2.92
Even if API version is bumped, it does not mean that the code will cease to
build or work.
--- a/plasma/generic/dataengines/geolocation/location_gps.cpp
+++ b/plasma/generic/dataengines/geolocation/location_gps.cpp
@@ -41,7 +41,7 @@
void Gpsd::run()
{
-#if GPSD_API_MAJOR_VERSION == 3 defined( WATCH_ENABLE )
+#if defined( GPSD_API_MAJOR_VERSION ) ( GPSD_API_MAJOR_VERSION = 3 ) defined( WATCH_ENABLE )
gps_stream(m_gpsdata, WATCH_ENABLE, NULL);
#else
gps_query(m_gpsdata, w+x\n);
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma geolocation dataengine, Debian patch fixing compile errors with gpsd 2.92
On March 5, 2010, Jens-Michael Hoffmann wrote: Hi Petri, I'm in contact with the Debian Qt/KDE packagers team and they asked me to commit attached patch. I committed a similar patch to marble trunk / 4.4 yesterday. Can I commit the attached patch to trunk and 4.4? sure... :) -- 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma geolocation dataengine, Debian patch fixing compile errors with gpsd 2.92
Am Freitag, 5. März 2010 19:01:05 schrieb Aaron J. Seigo: On March 5, 2010, Jens-Michael Hoffmann wrote: Hi Petri, I'm in contact with the Debian Qt/KDE packagers team and they asked me to commit attached patch. I committed a similar patch to marble trunk / 4.4 yesterday. Can I commit the attached patch to trunk and 4.4? sure... :) done :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: feature plan
On Thursday 04 March 2010, 13:58 Aaron J. Seigo wrote: can everyone who wishes to please meet us in #plasma on irc at 16:00 UTC this saturday so we can go through our 4.5 plans? thanks, and see you there! I'll try but not sure how good will be the internet connection on the first day of a conference hehe. Anyway it would be good if someone could please save the log so the ones not present could know what happened :) Cheers, -- Artur Duque de Souza openBossa INdT - Instituto Nokia de Tecnologia -- Blog: http://blog.morpheuz.cc PGP: 0xDBEEAAC3 @ wwwkeys.pgp.net -- signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
2010/3/5 Marco Martin notm...@gmail.com: On Friday 05 March 2010, Emdek wrote: 2010/3/5 Aaron J. Seigo ase...@kde.org: On March 5, 2010, Emdek wrote: In comments to that bug I've written how it could work: https://bugs.kde.org/show_bug.cgi?id=158556#c33 a plasmoid is the wrong approach. this is about views, not the scene, and it should not require special set up by the user. not to mention a 'hide button on my desktop' is a bit nonsensical and a hide button in the middle of a panel isn't a compelling use case. But why not? DBus call for toggling panel visibility would be nice addition anyway. Then there could be applet for people who want different (and more advanced) approach and current implementation built in. Isn't it good settlement? ;-) no, a plasmoid has exactly nothing to do with any panel behaviour whatsoever But having DBus call for that purpose isn't something wrong, I think. And how it can be used is different story. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: On Plasmate's previewer
On March 5, 2010, Yuen Hoe Lim wrote: I forgot to raise this in the irc meeting earlier :( I think we should consider the possibility of having the previewer as its own separate process. it would be nice. i don't think it's critical for the first release, though. please add it to the wiki if you haven't already. This is good imo because 1) A crashing plasmoid won't bring Plasmate down with it. Currently if a plasmoid crashes on-load, every subsequent loading of the project will probably also result in a crash (because the previewer automatically loads the plasmoid). And that's pretty bad if Plasmate crashes along - the project will become unusable. of course, crashes in the plasmoid should only be coming from the c++ underneath ... which also shouldn't happen. still, it can happen. what i'd suggest for now is not showing the preview by default and leaving that up to the developer to start by pressing the preview button. 2) I think it would be very useful if we could eventually capture (and display in some way) the current plasmoid's console output messages, so that it's easier for users to debug runtime errors and such. Currently those output messages become Plasmate's console output, and I'm not sure if there is a way for Plasmate to grab them. this won't be solved by putting it out of process since it will then get all the debug output from all of libplasma when really we probably just want the widget output. instead, we should probably have a way to put a print/debug shim into the script environment that would get us what we need. given that plasmate attempts to support python and ruby as well as javascript, this is going to be much more difficult than necessary. *sigh* But then if the previewer becomes it's own separate process, will it still be possible for it to live in a dockwidget? we could xembed 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: On Plasmate's previewer
Also, if someone has a log of the meeting, or can reply back with the points discussed after the netsplit happened yesterday, please reply to this mail with it. On Fri, Mar 5, 2010 at 4:25 PM, Aaron J. Seigo ase...@kde.org wrote: On March 5, 2010, Yuen Hoe Lim wrote: I forgot to raise this in the irc meeting earlier :( I think we should consider the possibility of having the previewer as its own separate process. it would be nice. i don't think it's critical for the first release, though. please add it to the wiki if you haven't already. This is good imo because 1) A crashing plasmoid won't bring Plasmate down with it. Currently if a plasmoid crashes on-load, every subsequent loading of the project will probably also result in a crash (because the previewer automatically loads the plasmoid). And that's pretty bad if Plasmate crashes along - the project will become unusable. of course, crashes in the plasmoid should only be coming from the c++ underneath ... which also shouldn't happen. still, it can happen. what i'd suggest for now is not showing the preview by default and leaving that up to the developer to start by pressing the preview button. 2) I think it would be very useful if we could eventually capture (and display in some way) the current plasmoid's console output messages, so that it's easier for users to debug runtime errors and such. Currently those output messages become Plasmate's console output, and I'm not sure if there is a way for Plasmate to grab them. this won't be solved by putting it out of process since it will then get all the debug output from all of libplasma when really we probably just want the widget output. instead, we should probably have a way to put a print/debug shim into the script environment that would get us what we need. given that plasmate attempts to support python and ruby as well as javascript, this is going to be much more difficult than necessary. *sigh* But then if the previewer becomes it's own separate process, will it still be possible for it to live in a dockwidget? we could xembed 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 Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
