[RFC] File ending for packaged KWin effects and where to put them
Hi workspace developers, my JavaScript bindings for KWin effects are nearly in place and that results in a few questions I wanted to discuss with the greater team. The scripted effects follow the Plasma Packages structure and I plan to have also normal KWin scripts use Plasma Package structure as well as window decorations and window switcher layouts. Should such files use the file ending plasmoid or should we introduce new names like kwineffect, kwinswitcher, kwinscript, kwindecoration? Could using plasmoid result in problems like the widgets explorer trying to install the kwineffect when dropped on the desktop? The second question I have is about the additional effects. Now that we have the scripted bindings I want to rewrite a few pure eye-candy effects with the bindings and move them out of the KWin source tree. Where should they go? I tend to plasma-addons. Last but not least: how does this synchrotron work and does it offer something which would be very useful to distribute our effects, scripts, etc? Cheers Martin 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: [RFC] File ending for packaged KWin effects and where to put them
On Thu, Feb 9, 2012 at 9:57 AM, Martin Gräßlin mgraess...@kde.org wrote: Hi workspace developers, my JavaScript bindings for KWin effects are nearly in place and that results in a few questions I wanted to discuss with the greater team. The scripted effects follow the Plasma Packages structure and I plan to have also normal KWin scripts use Plasma Package structure as well as window decorations and window switcher layouts. Should such files use the file ending plasmoid or should we introduce new names like kwineffect, kwinswitcher, kwinscript, kwindecoration? Could using plasmoid result in problems like the widgets explorer trying to install the kwineffect when dropped on the desktop? My opinion.. keep .plasmoid for the actual widgets that can be placed on the desktop. use the new names (kwineffect, kwinswitcher, kwinscript, kwindecoration) for kwin. Just my 2 cents. I can't comment on the other questions since I know to little about that. The second question I have is about the additional effects. Now that we have the scripted bindings I want to rewrite a few pure eye-candy effects with the bindings and move them out of the KWin source tree. Where should they go? I tend to plasma-addons. Last but not least: how does this synchrotron work and does it offer something which would be very useful to distribute our effects, scripts, etc? Cheers Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: [RFC] File ending for packaged KWin effects and where to put them
On Thursday 09 February 2012 17:45:03 Weng Xuetian wrote: On Thu, Feb 9, 2012 at 4:57 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi workspace developers, my JavaScript bindings for KWin effects are nearly in place and that results in a few questions I wanted to discuss with the greater team. The scripted effects follow the Plasma Packages structure and I plan to have also normal KWin scripts use Plasma Package structure as well as window decorations and window switcher layouts. Should such files use the file ending plasmoid or should we introduce new names like kwineffect, kwinswitcher, kwinscript, kwindecoration? Could using plasmoid result in problems like the widgets explorer trying to install the kwineffect when dropped on the desktop? plasmoid is just a zip rename into .plasmoid, and if .kwineffect will be used, you should add something similar to /usr/share/mime/application/x-plasma.xml. Add new mime-type for kwin effects have a benefit that they can be assigned to different installer easily, if user want to have a feature that double click on .kwineffect file and can have it installed. The second question I have is about the additional effects. Now that we have the scripted bindings I want to rewrite a few pure eye-candy effects with the bindings and move them out of the KWin source tree. Where should they go? I tend to plasma-addons. Last but not least: how does this synchrotron work and does it offer something which would be very useful to distribute our effects, scripts, etc? I think you can request a new category for kwin effect on kde-look.org, currently there is no separate kwin effect category and all existing third-party effect are seems to be in KDE Improvement. Something like KWin Effects Binary and KWin Effects Scripts should be added. yes of course, but this does not make sense before the code is written. In fact I want to have the new categories on kde-look hidden till our first 4.9 beta is released :-) Cheers Martin 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: [RFC] File ending for packaged KWin effects and where to put them
On Thursday, February 9, 2012 09:57:32 Martin Gräßlin wrote: Should such files use the file ending plasmoid or should we introduce new names like kwineffect, kwinswitcher, kwinscript, kwindecoration? Could using plasmoid result in problems like the widgets explorer trying to install the kwineffect when dropped on the desktop? it will be at the very least confusing for the user. i would recommend different suffixes. The second question I have is about the additional effects. Now that we have the scripted bindings I want to rewrite a few pure eye-candy effects with the bindings and move them out of the KWin source tree. Where should they go? I tend to plasma-addons. if you want them available by synchrotron, then in the synchrotron-sources repository. otherwise i think addons is a good target, yes. Last but not least: how does this synchrotron work and does it offer something which would be very useful to distribute our effects, scripts, etc? yes, it does. i need to complete the client-side integration to make it non- painful to use from such things (e.g. i don't want kwin, plasma-desktop, etc. etc. all implementing this on their own, which they would nominally have to at this point.) i'll rachet this up on my todo list since kwin would now be blocking on it. -- Aaron J. Seigo 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
FrameSVG manual reload on themeChanged()
Hello fellow plasma developers! I'm doing a fix for folderview, related to the theme changes. In particular, I need to relayout and repaint the items using the margins in the new viewitem.svgz in the new theme. To reload the FrameSVG object manually, I need to do an update() call in the applet, which will redraw everything, including the view, and load the correct SVG. But, after that, I will recalculate the correct margins and relayout the items (as they have different sizes now), and then repaint the view completely. So we have 2 complete repaints (and one more in AppletPrivate::themeChanged(), an unconditional one.) So, I'd like to avoid this second repaint (via update()), and reload the framesvg manually. How can I do that? Best regards, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: FrameSVG manual reload on themeChanged()
On Thursday, February 9, 2012 17:11:38 Ignat Semenov wrote: Hello fellow plasma developers! I'm doing a fix for folderview, related to the theme changes. In particular, I need to relayout and repaint the items using the margins in the new viewitem.svgz in the new theme. To reload the FrameSVG object manually, I need to do an update() call in the applet, which will redraw everything, including the view, and load the correct SVG. But, after that, I will recalculate the correct margins and relayout the items (as they have different sizes now), and then repaint the view completely. So we have 2 complete repaints (and one more in AppletPrivate::themeChanged(), an unconditional one.) So, I'd like to avoid this second repaint (via update()), and reload the framesvg manually. How can I do that? are you sure this results in 2 paint events? in theory, these signals should all happen at the same time and those two calls to update() should be compressed into a single paint event .. meaning that there is no point in trying to optimize that call out. that's the theory .. in practice that theory could be wrong (in which case we need to fix it in libplasma). if you could confirm the number of paint events that actually get triggered that would be excellent. -- Aaron J. Seigo 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
Integrate AppMenu into Workspace 4.9
Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Integrate AppMenu into Workspace 4.9
On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote: Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? I'm all for it and would even say we go for default menu in windeco. Cheers Martin 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: Integrate AppMenu into Workspace 4.9
On Thu, Feb 9, 2012 at 4:24 PM, Martin Gräßlin mgraess...@kde.org wrote: If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) Oh didn't know that, because the QML decoration thing? I'm all for it and would even say we go for default menu in windeco. In that case I would really love to see something like this: http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/ But in this case I'd put the textbox at the bottom, what do you think? I can take some time today to try to do a PoC if you like the idea. BTW remember to reply to all, I'm not sure if gnumdk is in plasma-devel. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Integrate AppMenu into Workspace 4.9
On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote: Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? I'm all for it and would even say we go for default menu in windeco. Cheers Martin I would say give it a blacklist for some special application, such as gimp / inkscape. Current win deco menu button is not a good solution for those. For other menu-is-rarely-used-application (Maybe that's the most case), my two cents for putting it in windeco. By the way, is there anyway for people to implement some special appmenu only case like compact menu of firefox? I currently don't see it is possible with dbus menu. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Integrate AppMenu into Workspace 4.9
On 09.02.2012 17:31, Alex Fiestas wrote: I'm all for it and would even say we go for default menu in windeco. In that case I would really love to see something like this: http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/ But in this case I'd put the textbox at the bottom, what do you think? I can take some time today to try to do a PoC if you like the idea. This looks a lot like Ubuntu's HUD [0]. I'd love to see that in KDE, maybe integrated with KRunner? [0] http://www.youtube.com/watch?v=w_WW-DHqR3c -- Andrei ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Integrate AppMenu into Workspace 4.9
On Thursday 09 February 2012 16:31:27 Alex Fiestas wrote: On Thu, Feb 9, 2012 at 4:24 PM, Martin Gräßlin mgraess...@kde.org wrote: If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) Oh didn't know that, because the QML decoration thing? no, because window tabbing is broken beyond any repair and Thomas is currently rewriting it and because of that we need adjustments to the API. We use this as an excuse to clean up a little bit and given that there are no 3rd party decorations except for skulpture, dekorator, bespin and QtCurve which are all developed by developers close to us it's not a big issue. I'm all for it and would even say we go for default menu in windeco. In that case I would really love to see something like this: http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/ But in this case I'd put the textbox at the bottom, what do you think? I can take some time today to try to do a PoC if you like the idea. sounds like an awesome idea. I had seen this today for the first time in your linked video and really liked it. BTW remember to reply to all, I'm not sure if gnumdk is in plasma-devel. ups, but even in your mail only agateau was included... Cheers Martin 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: Re: Integrate AppMenu into Workspace 4.9
On Thursday 09 February 2012 23:40:07 Weng Xuetian wrote: On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote: Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? I'm all for it and would even say we go for default menu in windeco. Cheers Martin I would say give it a blacklist for some special application, such as gimp / inkscape. Current win deco menu button is not a good solution for those. For other menu-is-rarely-used-application (Maybe that's the most case), my two cents for putting it in windeco. By the way, is there anyway for people to implement some special appmenu only case like compact menu of firefox? I currently don't see it is possible with dbus menu. No I think this is not yet possible. But it is something we should do in Frameworks 5. Just turning the menu from horizontal to vertical is not a perfect solution and I really like what Dolphin did to the collapsed menu. Firefox btw did a bad implementation: just try to navigate with keyboard only :-) Cheers Martin 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: Drop Xinerama related options in KWin
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103756/#review10459 --- This review has been submitted with commit 4a0369aae0ba4008c0fce7624b33af3c5794 by Martin Gräßlin to branch master. - Commit Hook On Jan. 26, 2012, 6:47 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103756/ --- (Updated Jan. 26, 2012, 6:47 a.m.) Review request for kwin and Plasma. Description --- As discussed on the mailinglist: drop of the xinerama related options and the kcm. Given that the show unmanaged windows on option is in fact not used, I dropped the complete KCM. Diffs - kcontrol/CMakeLists.txt 8cd9a46 kcontrol/xinerama/CMakeLists.txt fe332e5 kcontrol/xinerama/Messages.sh f4aa134 kcontrol/xinerama/interface_util.h 8a4fcd1 kcontrol/xinerama/kcmxinerama.h 18b9241 kcontrol/xinerama/kcmxinerama.cpp a456b2c kcontrol/xinerama/test_kcm_xinerama.cpp a358a2c kcontrol/xinerama/xinerama.desktop e8ce525 kcontrol/xinerama/xineramawidget.h 2c446a2 kcontrol/xinerama/xineramawidget.cpp df9cb2f kcontrol/xinerama/xineramawidget.ui 90ec4d4 kwin/geometry.cpp a414e26 kwin/manage.cpp c551eac kwin/options.h 9dc29cf kwin/options.cpp d496569 kwin/tabbox/tabbox.cpp 3051316 kwin/toplevel.cpp ffe7f0c kwin/workspace.cpp 69b4ecb Diff: http://git.reviewboard.kde.org/r/103756/diff/diff Testing --- Fullscreen: works Maximize: works Movment: works Placement: works Thanks, Martin Gräßlin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Integrate AppMenu into Workspace 4.9
On Thu, Feb 9, 2012 at 4:50 PM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 09 February 2012 23:40:07 Weng Xuetian wrote: On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote: Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? I'm all for it and would even say we go for default menu in windeco. Cheers Martin I would say give it a blacklist for some special application, such as gimp / inkscape. Current win deco menu button is not a good solution for those. For other menu-is-rarely-used-application (Maybe that's the most case), my two cents for putting it in windeco. By the way, is there anyway for people to implement some special appmenu only case like compact menu of firefox? I currently don't see it is possible with dbus menu. No I think this is not yet possible. But it is something we should do in Frameworks 5. Why not? The new decorations are going to be QML based anyway so why not make the menu button a qml element that gets filled from a model or something.. That way it's perfectly themable, right? Or am i missing a point here? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
R: Integrate AppMenu into Workspace 4.9
Hi, I really like this idea, expecially because I'm dreaming of a KRunner version that uses voice recognition, so the user could do the main operations (and have access to applications menus) using the voice. But I don't know if there are problems in integrating AppMenu in the next version of Plasma. Luca Tringali Messaggio originale Da: afies...@kde.org Data: 09/02/2012 16.07 A: plasma-devel@kde.org Cc: agat...@kde.org Ogg: Integrate AppMenu into Workspace 4.9 Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Integrate AppMenu into Workspace 4.9
On Thu, Feb 9, 2012 at 11:50 PM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 09 February 2012 23:40:07 Weng Xuetian wrote: On Thu, Feb 9, 2012 at 11:24 PM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 09 February 2012 16:07:13 Alex Fiestas wrote: Hey there! It seems that people really likes AppMenu, we have fans of everything we have done with it so far: -oxygen-appmenu -plasmoid -runner So it seems clear to me that we should integrate this technology into Workspace 4.9, but before we do it would be good to hear opinions about these questions: -Is there any way of integrating oxygen-appmenu without breaking api-abi? Maybe a second version of the API? If that refers to KWin decoration API: no problem as we are going to break deco API in 4.9 anyway :-) -How the KDED works? -Is there any plans to extend libdbusmenu-qt to make it export the menu as a model? -Do we need something else to complete our support? documentation maybe? -What is the status of it being merged into GTK ? Personally I think that AppMenu is a powerful technology that will allow us to decide how and when show the menubars which sure will be handy in the future. So, what do you think of AppMenu? I'm all for it and would even say we go for default menu in windeco. Cheers Martin I would say give it a blacklist for some special application, such as gimp / inkscape. Current win deco menu button is not a good solution for those. For other menu-is-rarely-used-application (Maybe that's the most case), my two cents for putting it in windeco. By the way, is there anyway for people to implement some special appmenu only case like compact menu of firefox? I currently don't see it is possible with dbus menu. No I think this is not yet possible. But it is something we should do in Frameworks 5. Just turning the menu from horizontal to vertical is not a perfect solution and I really like what Dolphin did to the collapsed menu. Firefox btw did a bad implementation: just try to navigate with keyboard only :-) Yes keyboard navigate is simply broken for firefox.. By the way, is it possible to make win deco use another menu right now? For example, can dolphin use its collapsed menu if windeco menu is used, or if it's not possible automatically, can dolphin manually do it? By the way GNOME is also doing something similar, though not knowing the implementation detail. http://live.gnome.org/ThreePointThree/Features/ApplicationMenu Seems they try to give application a global hint via a daemon for what kind of menu they can make use of, in order to choose different kinds of menu to meet the specific environment. Traditional menu is not a good idea for all application, but putting existing traditional menu directly into windeco is also not a good idea for me (this can be done later, but if windeco is pushed by default, might break some sort of user experience for specific application). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: Integrate AppMenu into Workspace 4.9
On Friday 10 February 2012 00:22:21 Weng Xuetian wrote: By the way, is it possible to make win deco use another menu right now? For example, can dolphin use its collapsed menu if windeco menu is used, or if it's not possible automatically, can dolphin manually do it? yes, that's what I meant with needs support in Frameworks 5. We need to add an API to allow applications to export a specific menu. By the way GNOME is also doing something similar, though not knowing the implementation detail. http://live.gnome.org/ThreePointThree/Features/ApplicationMenu Seems they try to give application a global hint via a daemon for what kind of menu they can make use of, in order to choose different kinds of menu to meet the specific environment. Traditional menu is not a good idea for all application, but putting existing traditional menu directly into windeco is also not a good idea for me (this can be done later, but if windeco is pushed by default, might break some sort of user experience for specific application). interesting, that sounds like a good opportunity to collaborate. 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: Data engine update issue in Javascript
https://www.dropbox.com/s/omnt27sor7d99zl/textmondebug.plasmoid ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Fix folderview sorting
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103895/#review10464 --- Ship it! Ship It! - Aaron J. Seigo On Feb. 9, 2012, 6:22 p.m., Ignat Semenov wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103895/ --- (Updated Feb. 9, 2012, 6:22 p.m.) Review request for Plasma, Aaron J. Seigo, Marco Martin, Peter Penz, and Fredrik Höglund. Description --- This patch fixes the inconsistent sorting issues in FolderView. 1)It introduces explicit support for sorting by size. Prior to the change, sorting by Size was done as follows:convert the size into a string and use KStringHandler::naturalCompare(). Of course, this is not the same as a proper int comparison - FW sorted incorrectly by size. 2)Introduce one important concept:fallback to comparing the name if the main sorting column is not enough to determine a sort order. This is especially important for sorting by type - sorting by size needs this as well, but different files are way less likely to have the same size compared to the possibility of them having similar types. 3)Intoduce full three-level fallback for ensuring file name uniqueness, taken from Dolphin code. Thanks a bunch goes to Peter Penz :) 4)And of course, sort folders by the child count if sorting by size. Again, Dolphin inspired. Diffs - plasma/applets/folderview/proxymodel.cpp 4b3340e Diff: http://git.reviewboard.kde.org/r/103895/diff/diff Testing --- Tested, yields results similar to Dolphin sorting of the same folder (surpise! :) ). Thanks, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: telling a data engine to reload a source
On Thu, Feb 9, 2012 at 8:48 AM, Aaron J. Seigo ase...@kde.org wrote: the plasmoid (almost) never tells the engine when to reload. how can it when it is simply a visualization of the data? if the visualization knows such things, it is not longer a visualization. if the dataengine does not know such things then it is no longer a true manager of data. no. the dataengine itself must know when and how to reload data. the only thing a visualization can do is request updates every N ms (time based updates). -- Aaron J. Seigo So what I really should do is set the plasmoid to request updates every 86,400,000 seconds (1 day) if I'd want the data to be fresh every day? Fair enough, -- Eric Mesa http://about.me/ericmesa http://www.ericsbinaryworld.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: telling a data engine to reload a source
On Fri, Feb 10, 2012 at 7:03 AM, Eric Mesa ericsbinarywo...@gmail.com wrote: On Thu, Feb 9, 2012 at 8:48 AM, Aaron J. Seigo ase...@kde.org wrote: the plasmoid (almost) never tells the engine when to reload. how can it when it is simply a visualization of the data? if the visualization knows such things, it is not longer a visualization. if the dataengine does not know such things then it is no longer a true manager of data. no. the dataengine itself must know when and how to reload data. the only thing a visualization can do is request updates every N ms (time based updates). -- Aaron J. Seigo So what I really should do is set the plasmoid to request updates every 86,400,000 seconds (1 day) if I'd want the data to be fresh every day? Well, yes. You could check the microblog plasmod: http://quickgit.kde.org/index.php?p=kdeplasma-addons.gita=blobhb=HEADf=applets%2Fmicroblog%2Fmicroblog.cpp It's using: m_engine-connectSource(profileQuery, this, m_historyRefresh * 60 * 1000); If you need some feature such as refresh manually, you could add a ServiceJob to the data engine. http://quickgit.kde.org/index.php?p=kdeplasma-addons.gita=treef=dataengines%2Fmicroblog Microblog dataengine also has a ServiceJob called refresh, in order to trigger refresh on the plasmoid side. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Improve the QML RunnerModel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103806/#review10471 --- components/runnermodel/runnermodel.cpp http://git.reviewboard.kde.org/r/103806/#comment8572 the Enabled role is missing now components/runnermodel/runnermodel.cpp http://git.reviewboard.kde.org/r/103806/#comment8573 what is access to the Runner pointer needed for? i'm very hesitant to expose those pointers. components/runnermodel/runnermodel.cpp http://git.reviewboard.kde.org/r/103806/#comment8575 what are the use cases for these methods? i'm undecided whether i agree with them being here, but that really depends on what you plan on using them for :) - Aaron J. Seigo On Feb. 7, 2012, 11:23 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103806/ --- (Updated Feb. 7, 2012, 11:23 p.m.) Review request for Plasma. Description --- Adds some features to the RunnerModel so that it can be used properly in the KRunner QML implementation I've been working on (see the testing section). Also it simplifies the code a bit by moving from QAbstractItemModel - QAbstractListModel. Diffs - components/runnermodel/runnermodel.h 899bf1f components/runnermodel/runnermodel.cpp a226f8e Diff: http://git.reviewboard.kde.org/r/103806/diff/diff Testing --- use it in kde:scratch/apol/krunner-qml (proof of concept for a KRunner implemented in QtQuick). here's a video, so that you know what's going on: http://www.proli.net/meu/netrunner/qmlrunner.ogv Thanks, Aleix Pol Gonzalez ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: make UNC path work in krunner by mapping it to smb:// path
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103826/#review10472 --- Ship it! nce :) - Aaron J. Seigo On Jan. 29, 2012, 10:15 p.m., Martin Koller wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103826/ --- (Updated Jan. 29, 2012, 10:15 p.m.) Review request for Plasma. Description --- revive the possibility to enter an UNC path e.g. \\hostname\some\path into krunner leading to an smb://hostname/some/path target as is done in konqueror's address bar. This addresses bug 211317. http://bugs.kde.org/show_bug.cgi?id=211317 Diffs - plasma/generic/runners/locations/locationrunner.cpp c8ec8ae Diff: http://git.reviewboard.kde.org/r/103826/diff/diff Testing --- Tested local paths, # and ## shortcuts (man and info), tar: zip: special protocols, \\ and \\host\path style URL, $HOME/bin Thanks, Martin Koller ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Allow to choose between ascending and descending icon sort order in folderview
On Monday, February 6, 2012 12:22:01 you wrote: Hello fellow plasma devs! This change, while trivial, contains 2 strings, Ascending and Desending. I've found out that the very same strings already exist in Dolphin, which lives in the same module as plasma-applet-folderview, kde- baseapps. Does that mean that this commit can be backported to 4.8? no; it's not a bug fix and it doesn introduce new strings to this translated item (which is not as bad as it could be as you note the strings exist in other translatable binaries in the same moulde .. still ..) cheers ... -- Aaron J. Seigo 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 to choose between ascending and descending icon sort order in folderview
On Monday, February 6, 2012 14:44:25 Ignat Semenov wrote: Marco Martin wrote: On Mon, Feb 6, 2012 at 9:22 AM, Ignat Semenov ragnarok...@gmail.com wrote: Hello fellow plasma devs! This change, while trivial, contains 2 strings, Ascending and Desending. I've found out that the very same strings already exist in Dolphin, which lives in the same module as plasma-applet-folderview, kde- baseapps. Does that mean that this commit can be backported to 4.8? well, regardless of the strings, that's a feature, so i would prefer it 4.9 only Hello Marco, In the case that I won't backport the change, will I be able to backport later commits using git cherry-pick correctly? Does Git use the diffs for cherry-picking? it uses the diff of the current change; it doesn't need to replay all changes in between. of course, if a change touches code that this commit changes, then that change will need to be manually merged back. but generally git makes this as easy as it can be. Another one is, of course, that this useful feature will have a longer lifetime and more users :) we could say that about every feature :) -- Aaron J. Seigo 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
