Transforming panels in fullscreen effects (was activities overview, take N)
cc-ing kwin list. I said it before, I say it again: we need a workspace mailinglist Am Dienstag 13 Oktober 2009 22:08:37 schrieb Aaron J. Seigo: On October 13, 2009, Martin Gräßlin wrote: Am Dienstag 13 Oktober 2009 20:19:44 schrieb Aaron J. Seigo: slightly off-topic: what would you think about making the show windows / desktops zoomed out in some presentation type effects not include the desktop panels? the reasons include: * the panel often has things like the tasks widget which shows all the windows but may also show only for the current desktop ... which doesn't work very nicely in overview modes * if the panels stayed un-transformed, it could give a really interesting visual effect where the desktop area gets transformed and the panel overlays remain as they are if you want to try it: the present windows effect has an option to not hide the panel and the cube desktop switch animation does not hide the panels by default and that one looks really slick. just tried both of these options, and i have to agree: it looks much slicker with the panels remaining where they are. i think the desktop cube would look nicer and more consistent with the switcher without the panels included as well. fixed the switcher :-) * it would make some of these effects more consistent with the alt-tab box which does not transform the panels either Box Switch keeps them untransformed and the more fancy effects fade them out. I think it would be possible to keep the panel in place instead of fading it out. could the kwin devs consider make it a design guideline to not include panels in such effects but instead leave them untransformed? it just looks/feels so much more ... nicer. yeah I think we could make that a design guideline. Just for the fun of it I tried it on two effects: * desktop grid: http://picasaweb.google.de/lh/photo/h0wjRlQ0m3SLQWlz8XYTHA?feat=directlink * flip switch: http://picasaweb.google.de/lh/photo/fUqlyPd2lg5XpUXFmZh3Tg?feat=directlink the only draw back would be if we ever make panels per-desktop. but then i guess the heuristic could be don't transform panel windows that are also on all desktops? That heuristic would break the desktop grid effect with the changes in the above screenshot. But as Plasma does not yet have that feature we don't have to worry about it. 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: Review Request: Kineticscrolling: a zero api approach
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/#review2646 --- /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp http://reviewboard.kde.org/r/1840/#comment1961 How expensive is to remove/set again the event filter? Is it just 2 function calls or it does some black and deep magic in qt event loop? My guess is that if it is cheap (not cpu bound), the advantages of the current implementation (i.e. easy of use for clients) outweigths its ugliness until we find a better way. /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp http://reviewboard.kde.org/r/1840/#comment1962 Maybe it pays up to inspect the return value? (from docs: Returns false if the event was filtered or if the item is disabled. Otherwise returns the value that was returned from the event handler.) /trunk/KDE/kdelibs/plasma/widgets/webview.cpp http://reviewboard.kde.org/r/1840/#comment1963 Is this still required? - Adenilson On 2009-10-14 09:23:44, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/ --- (Updated 2009-10-14 09:23:44) Review request for Plasma. Summary --- this is just an experiment that has perhaps a too big disadvantage to be practical... makes use of event filters instead of explicitly forwarding mouse events. the advantage is that it would be super easy to use and woouldn't be needed to export new classes in plasma, there could just be an Animator::registerScrollingManager(QGraphicsWidget *) function the big disadvantage is that is less controllable, so widgets can't decide to -not- make use of the kineticscrolling, thing that is quite needed in WebView. Diffs - /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 Diff: http://reviewboard.kde.org/r/1840/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Kineticscrolling: a zero api approach
On 2009-10-14 12:19:32, Adenilson Cavalcanti wrote: /trunk/KDE/kdelibs/plasma/widgets/webview.cpp, line 66 http://reviewboard.kde.org/r/1840/diff/3/?file=12657#file12657line66 Is this still required? nope On 2009-10-14 12:19:32, Adenilson Cavalcanti wrote: /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp, line 357 http://reviewboard.kde.org/r/1840/diff/3/?file=12653#file12653line357 Maybe it pays up to inspect the return value? (from docs: Returns false if the event was filtered or if the item is disabled. Otherwise returns the value that was returned from the event handler.) do we need to know if it was filtered? but yes, not scrolling if the widget is disabled is good On 2009-10-14 12:19:32, Adenilson Cavalcanti wrote: /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp, line 355 http://reviewboard.kde.org/r/1840/diff/3/?file=12653#file12653line355 How expensive is to remove/set again the event filter? Is it just 2 function calls or it does some black and deep magic in qt event loop? My guess is that if it is cheap (not cpu bound), the advantages of the current implementation (i.e. easy of use for clients) outweigths its ugliness until we find a better way. doesn't seem too heavy. however the same effect can be acieved with a bool state variable that acts like a semaphore - Marco --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/#review2646 --- On 2009-10-14 09:23:44, Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/ --- (Updated 2009-10-14 09:23:44) Review request for Plasma. Summary --- this is just an experiment that has perhaps a too big disadvantage to be practical... makes use of event filters instead of explicitly forwarding mouse events. the advantage is that it would be super easy to use and woouldn't be needed to export new classes in plasma, there could just be an Animator::registerScrollingManager(QGraphicsWidget *) function the big disadvantage is that is less controllable, so widgets can't decide to -not- make use of the kineticscrolling, thing that is quite needed in WebView. Diffs - /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 Diff: http://reviewboard.kde.org/r/1840/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Kineticscrolling: a zero api approach
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1840/ --- (Updated 2009-10-14 13:38:20.621815) Review request for Plasma. Changes --- no more removing and adding the filter every time Summary --- this is just an experiment that has perhaps a too big disadvantage to be practical... makes use of event filters instead of explicitly forwarding mouse events. the advantage is that it would be super easy to use and woouldn't be needed to export new classes in plasma, there could just be an Animator::registerScrollingManager(QGraphicsWidget *) function the big disadvantage is that is less controllable, so widgets can't decide to -not- make use of the kineticscrolling, thing that is quite needed in WebView. Diffs (updated) - /trunk/KDE/kdelibs/plasma/private/kineticscroll.cpp 1034839 /trunk/KDE/kdelibs/plasma/private/kineticscroll_p.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/scrollwidget.cpp 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.h 1034839 /trunk/KDE/kdelibs/plasma/widgets/webview.cpp 1034839 Diff: http://reviewboard.kde.org/r/1840/diff Testing --- Thanks, Marco ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Scripted Plasmoid icon
Hi I've been googling all day to find a way to use a custom icon for your Plasmoid. I found the following snippet in http://code.google.com/p/gmail- plasmoid/source/diff?spec=svn22r=22format=sidepath=/trunk/contents/code/main.py : # Install icon if required kdehome = str(KGlobal.dirs().localkdedir()) if not os.path.exists(kdehome+share/icons/gmail-plasmoid.svg): try: shutil.copy(self.package().path() + contents/icons/gmail-plasmoid.svg, kdehome+share/icons/gmail-plasmoid.svg) except: print Problem copying icon print Unexpected error:, sys.exc_info()[0] Is this really the best way to do it? I think that ideally you should just place your icon somewhere under contents/icons, put it in the metadata.desktop file under Icon and it should be recognized by Plasma. BTW: The file hierarchy of a Plasmoid isn't really well documented anywhere that I can find. If anyone can explain it to me I will be happy to document it on TechBase. -- Best Regards / Med venlig hilsen Thomas Olsen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scripted Plasmoid icon
On Wednesday 14 October 2009, Thomas Olsen wrote: Hi I've been googling all day to find a way to use a custom icon for your Plasmoid. I found the following snippet in http://code.google.com/p/gmail- plasmoid/source/diff?spec=svn22r=22format=sidepath=/trunk/contents/code/ main.py icon to be shown in the widgets explorer, icon of te popupapplet, or..? # Install icon if required kdehome = str(KGlobal.dirs().localkdedir()) if not os.path.exists(kdehome+share/icons/gmail-plasmoid.svg): try: shutil.copy(self.package().path() + contents/icons/gmail-plasmoid.svg, kdehome+share/icons/gmail-plasmoid.svg) except: print Problem copying icon print Unexpected error:, sys.exc_info()[0] Is this really the best way to do it? I think that ideally you should just place your icon somewhere under contents/icons, put it in the metadata.desktop file under Icon and it should be recognized by Plasma. BTW: The file hierarchy of a Plasmoid isn't really well documented anywhere that I can find. If anyone can explain it to me I will be happy to document it on TechBase. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities overview, take N
I have been reading or glancing this thread for a while (many longer posts are unreadable because of all the variations of included text being answered). If we are not talking about a one-to-one desktop-activity relationship which might be the most straightforward to understand, in other words an activity is a group of icons, windows, tasks and not a desktop per se The current zoom out, set up, zoom in, find them all different on next login...is hopelessly slow, incomplete and broken. I woud scrap it. Activities might be connected the current desktop from a right-click, from the panel, dashboard and/or from an appropriate previewing plasmoid. These activities could be containments based on the current folder view but could contain (additionally) plasmoids (?) and functioning .desktop files. If we want tasks running when the activity is brought up, we would probably want them started up where they left off the last session. More difficult if impossible for many apps. An activity and its data might be referenced or contained in one folder. A trivial example is the desktop folder containment itself or an appropriately filtered folder-view of the desktop folder. There could, of course, be more than one or none on any desktop, the same activity might be on several desktops. There would be no implicit relationship between activities and configured desktops. While a Rubic's cube of activities/desktops might be cool, I doubt it would really be useful. The fact the these hyper-space representations have not been widely adapted implies that they are not such wonderful tools. KISS. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scripted Plasmoid icon
On 14/10-2009 15:50 Marco Martin notm...@gmail.com wrote: On Wednesday 14 October 2009, Thomas Olsen wrote: Hi I've been googling all day to find a way to use a custom icon for your Plasmoid. I found the following snippet in http://code.google.com/p/gmail- plasmoid/source/diff?spec=svn22r=22format=sidepath=/trunk/contents/cod e/ main.py icon to be shown in the widgets explorer, icon of te popupapplet, or..? Actually both :-) I haven't gotten around to making it a popup applet since I ran into some problems. # Install icon if required kdehome = str(KGlobal.dirs().localkdedir()) if not os.path.exists(kdehome+share/icons/gmail-plasmoid.svg): try: shutil.copy(self.package().path() + contents/icons/gmail-plasmoid.svg, kdehome+share/icons/gmail-plasmoid.svg) except: print Problem copying icon print Unexpected error:, sys.exc_info()[0] Is this really the best way to do it? I think that ideally you should just place your icon somewhere under contents/icons, put it in the metadata.desktop file under Icon and it should be recognized by Plasma. BTW: The file hierarchy of a Plasmoid isn't really well documented anywhere that I can find. If anyone can explain it to me I will be happy to document it on TechBase. -- Best Regards / Med venlig hilsen Thomas Olsen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities overview, take N
On October 14, 2009 08:17:49 Chani wrote: On October 13, 2009 21:34:11 Matthew Dawson wrote: Thinking about the a-containment-per-virtual-desktop mode, I feel like I use that feature as a substitute for the missing ability of having nepomuk tied activities. I'd think once you have activities proper this feature will seem (and feel) redundant. Maybe the better option would be to simply remove the a-containment-per-virtual-desktop mode once activities are done? well, if we do try removing them, this would be the only chance at doing so without being burnt to a complete crisp. ;) shall we try it out when the activity-bar first lands, then? and come back to this before the final release to see whether it worked for the per-desktop people. another thought - if we do that we'll want global kbd shortcuts for switching activity, I guess. then there may be complaints from the handful of people using active borders (switching desktops by shoving the mouse off the edge) or those who want a pretty kwin effect to switch with. -- This message brought to you by eevil bananas and the number 3. www.chani3.com 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: activities overview, take N
On October 14, 2009 06:47:35 David Baron wrote: I have been reading or glancing this thread for a while (many longer posts are unreadable because of all the variations of included text being answered). If we are not talking about a one-to-one desktop-activity relationship which might be the most straightforward to understand, in other words an activity is a group of icons, windows, tasks and not a desktop per se no, that's not what an activity is. The current zoom out, set up, zoom in, find them all different on next login...is hopelessly slow, incomplete and broken. I woud scrap it. ummm... dude. we've been talking about scrapping the ZUI for a while now. maybe you haven't been glancing at this thread as much as you think you have. :P -- This message brought to you by eevil bananas and the number 3. www.chani3.com 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: Scripted Plasmoid icon
On October 14, 2009, Thomas Olsen wrote: Is this really the best way to do it? no. :) I think that ideally you should just place your icon somewhere under contents/icons, put it in the metadata.desktop file under Icon and it should be recognized by Plasma. in your metadata.desktop put an Icon= entry with the path to the icon.. e.g. myplasmoid.png or contents/myplasmoid.svg or wherever it is in the package and on installation it should magically work. -- 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 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: Transforming panels in fullscreen effects (was activities overview, take N)
On October 14, 2009 09:15:34 Aaron J. Seigo wrote: On October 14, 2009, Martin Gräßlin wrote: cc-ing kwin list. I said it before, I say it again: we need a workspace mailinglist it would be useful; the only challenge is knowing when to post here (because it's only about plasma or kwin) or on the workspace list if we keep plasma- devel@ and kwin@ and add a third one. i'd be happy with folding all the lists in together, assuming that the mixing of topics and increased volume wouldn't annoy people or decrease the usefulness of the lists for people. ehh... I already have to make myself ignore a lot of plasma threads. I unsubscribed from kwin to cut down on my mailing-list volume... we'd probably end up with a lot of [plasma] and [kwin] in subjects so that people could filter stuff they don't have time for (except review requests, they don't say what project htey're for). a separate mailing list would be easier. -- This message brought to you by eevil bananas and the number 3. www.chani3.com 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: Review Request: Allow user to select Calendar System to display in Calendar and Clock Applets
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard.kde.org/r/1378/ --- (Updated 2009-10-14 18:42:56.059625) Review request for Plasma. Changes --- Clean-up of code based on Aarons comments, including merge of Aarons changes to simplify config dialog. See responses to review comments for details, only one point outstanding. Summary --- [Requires kdelibs revision 1013825] Currently the Calendar and Clock applets can only display the global locale Calendar System, usually Gregorian. However it would be useful for users to be able to display Calendar applets with different Calendar Systems, for example Hebrew or Hijri, similar in concept to being able to have multiple Clock applets showing different Timezones. This change enables different applets to display different Calendar Systems and allows the user to configure each of these. See my blog post at http://www.layt.net/john/blog/odysseus/displacement_activity for screen shots. This is primarily achieved by moving most of the calendar configuration code from ClockApplet to CalendarTable from where it can be shared by any applet that embeds the CalendarTable. The Calendar applet has been modified to use the common configuration, as has the base ClockApplet class which ensures all Clock applets do as well. [I've had some thoughts to move the generic code from CalendarTable to a new non-gui helper class so different calendar layout widgets could share it, but that's not needed yet]. The major implementation issue I have to raise is in the ClockApplet class where I now create the CalendarTable in the init() instead of in initExtenderExtender(), and the extender item now gets passed the already existing CalendarTable which I believe it then manages. I _think_ this is safe to do as we will only ever have one calendar extender and it never appears to be deleted during the life of the applet, so I don't think the CalendarTable could be accidentally deleted. This means there is always a calendarWidget and calendar object so the code can be simplified in lots of places to remove checks to see if it exists first. This change does not yet address the issue in the Digital Clock applet that the displayed Date format is not correctly localised, but this involves a number of usability issues that I think are best addressed separately. Changes: ClockApplet: Remove all calendar configuration code and vars, call CalendarTable implementation instead Add convenience method calendar() for shortcut Clean-up clipboardMenu to only have localised date/time formats, add other calendar system options Remove unused method caseInsensitiveLessThan() CalendarTable Add all calendar configuration code and vars from ClockApplet Add ability to set and save calendarType, special type of locale means use global locale type Improved validation Calendar API to pass through calendar config calls to CalendarTable generalConfig.ui Removed all calendar configuration options to new calendarConfig.ui calendarConfig.ui New, has all calendar configuration options from generalConfig.ui Added combo box to select calendar system from. Clock (digital applet) Display date on clock face in correct calendar system CalendarApplet Add d- private class, use for variables Add new shared calendar config via CalendarTable Localise day number shown on Icon view [My apologies if my over-zealous clean-up of code layout and renaming makes the diff a little hard to read in places] Diffs (updated) - trunk/KDE/kdebase/workspace/libs/plasmaclock/CMakeLists.txt 1035179 trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.h 1035179 trunk/KDE/kdebase/workspace/libs/plasmaclock/calendar.cpp 1035179 trunk/KDE/kdebase/workspace/libs/plasmaclock/calendarConfig.ui PRE-CREATION trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.h 1035179 trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1035179 trunk/KDE/kdebase/workspace/libs/plasmaclock/clockapplet.h 1035179 trunk/KDE/kdebase/workspace/libs/plasmaclock/clockapplet.cpp 1035179 trunk/KDE/kdebase/workspace/libs/plasmaclock/generalConfig.ui 1035179 Diff: http://reviewboard.kde.org/r/1378/diff Testing --- Used plasmoidviewer to add/remove/play with lots of Calendar and Clock applets. Thanks, John ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Scripted Plasmoid icon
On 14/10-2009 18:00 Aaron J. Seigo ase...@kde.org wrote: On October 14, 2009, Thomas Olsen wrote: Is this really the best way to do it? no. :) No I didn't really think so... I think that ideally you should just place your icon somewhere under contents/icons, put it in the metadata.desktop file under Icon and it should be recognized by Plasma. in your metadata.desktop put an Icon= entry with the path to the icon.. e.g. myplasmoid.png or contents/myplasmoid.svg or wherever it is in the package and on installation it should magically work. And it does! Great! Now I just have to persuade some artist to make me a couple of SVG's :-) Later. -- Best Regards / Med venlig hilsen Thomas Olsen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
