Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
Hi all,
just a short reminder. When adjusting a CMakeLists.txt to Qt5 to enable e.g. a
dataengine please use the new namespace syntax in target_link_libraries. E.g:
target_link_libraries(plasma_engine_notifications
Qt5::DBus
KF5::KI18n
KF5::KIconThemes
KF5::KIOCore
KF5::KNotifications
KF5::plasma
KF5::KService
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
and not
target_link_libraries(plasma_engine_notifications
Qt5::DBus
${Plasma_LIBRARIES}
${KI18n_LIBRARIES}
${KIconThemes_LIBRARIES}
${KNotifications_LIBRARIES}
${KService_LIBRARIES}
${KDE4_KIO_LIBS}
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
I just spent the last half our fixing linker errors as ${KI18n_LIBRARIES}
didn't exist any more.
Thanks,
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
Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
CMake-gods, can you confirm the below? (It's inconsistent with my
understanding, and how we've done it in the past months, I'd like to have a
specialist opinion before going around and changing every single
CMakeLists.txt in Plasma.)
Thanks,
-- sebas
-- Forwarded Message --
Subject: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
Date: Wednesday, September 25, 2013, 10:36:46
From: Martin Gräßlin mgraess...@kde.org
To: plasma-devel@kde.org
Hi all,
just a short reminder. When adjusting a CMakeLists.txt to Qt5 to enable e.g. a
dataengine please use the new namespace syntax in target_link_libraries. E.g:
target_link_libraries(plasma_engine_notifications
Qt5::DBus
KF5::KI18n
KF5::KIconThemes
KF5::KIOCore
KF5::KNotifications
KF5::plasma
KF5::KService
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
and not
target_link_libraries(plasma_engine_notifications
Qt5::DBus
${Plasma_LIBRARIES}
${KI18n_LIBRARIES}
${KIconThemes_LIBRARIES}
${KNotifications_LIBRARIES}
${KService_LIBRARIES}
${KDE4_KIO_LIBS}
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
I just spent the last half our fixing linker errors as ${KI18n_LIBRARIES}
didn't exist any more.
Thanks,
Martin
-
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
private import names
Hey, Import names. As we can't use our setContextProperty tricks in subclassed Applets anymore, we'll have to resort more often to installing imports that are very specific (i.e. not libraries per se, but more like C++ portions needed for a certain applet). Examples are Kickoff, Icon, and the dreaded systray. I suggest to use org.kde.plasma.private.$widgetname for this, so we can filter for these imports later on, when our import security has been implemented. Objections? (No objections means that I'll change it.) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
plugin plans
Hey, As I've been working quite a lot on KService's plugin infra lately, I have some ideas about changes in Plasma. Background: KPluginTrader is new API in KService. It can replace KServiceTypeTrader, and thus the need to separately install .desktop files for plugins. Feature-wise, it's very similar, i.e. we can still query plugins using the constraint syntax. Plugin installation pathes I'd like to install our binary plugins into subdirectories. This is in line with how we'll do it across KF5. These plugins won't need .desktop files installed anymore. For dataengines, this is the most advanced right now. I have a branch which makes Plasma::PluginLoader use KPluginTrader. Before merging this, however, I'd want to update you on the overall strategy and give the opportunity to chime in. The first victim here will thus be dataengines. Packages The new API also allows us to use packages' metadata for querying. It means building up a KPluginInfo::List from metadata (so a bit of crawling through the filesystem, but probably not recursively, to list plugins. Looking at plasmapkg, the code to list packages is a bit convoluted right now, and I'd like to see that fixed. Plasma::PluginLoader should actually satisfy the needs of plasmapkg, without writing custom look for packages-code. This means, for packages and dataengines, KSycoca isn't needed anymore. With this in place, we can tackle more pieces of Plasma::PluginLoader to make it sycoca-free. Obviously, this is your chance to weigh in. :) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: private import names
Hello! On Wed, Sep 25, 2013 at 3:11 PM, Sebastian Kügler se...@kde.org wrote: I suggest to use org.kde.plasma.private.$widgetname If I remember notmart suggested me to use, private.$pluginname Log : * notmart would like private.org.kde.icon, and in general private.plasmoid plugin name Thanks! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: private import names
On Wednesday 25 September 2013 11:41:36 Sebastian Kügler wrote: Hey, Import names. As we can't use our setContextProperty tricks in subclassed Applets anymore, we'll have to resort more often to installing imports that are very specific (i.e. not libraries per se, but more like C++ portions needed for a certain applet). Examples are Kickoff, Icon, and the dreaded systray. I suggest to use org.kde.plasma.private.$widgetname for this, so we can filter for these imports later on, when our import security has been implemented. Objections? (No objections means that I'll change it.) first, get out of my mind :p I was thinking to something even more radical, that we can try to have consistent in whole kde (since i suspect a lot of other modules will have qml imports such as kdepim, or many other apps, such as games, kdeedu...) so something like private.org.kde.plasma.widgetname or .org.kde.private.plasma.widgetname the first would take a private at the first level, that maybe is not too nice, but the nice part is that it would always be private.$widgetpluginname that has some beauty (and easy filtering) in it -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: private import names
On Wednesday, September 25, 2013 12:07:55 Marco Martin wrote: On Wednesday 25 September 2013 11:41:36 Sebastian Kügler wrote: Import names. As we can't use our setContextProperty tricks in subclassed Applets anymore, we'll have to resort more often to installing imports that are very specific (i.e. not libraries per se, but more like C++ portions needed for a certain applet). Examples are Kickoff, Icon, and the dreaded systray. I suggest to use org.kde.plasma.private.$widgetname for this, so we can filter for these imports later on, when our import security has been implemented. Objections? (No objections means that I'll change it.) first, get out of my mind Never! :) I was thinking to something even more radical, that we can try to have consistent in whole kde (since i suspect a lot of other modules will have qml imports such as kdepim, or many other apps, such as games, kdeedu...) so something like private.org.kde.plasma.widgetname or .org.kde.private.plasma.widgetname The leading . is purposeful? the first would take a private at the first level, that maybe is not too nice, but the nice part is that it would always be private.$widgetpluginname that has some beauty (and easy filtering) in it I'm cool with private at the beginning, I actually don't care too much, as long as it's consistent. This has been spooking around my mind since I ship- it'ed Bhushan's Icon port, I just like to get rid of this nagging feeling that we have to change something there. And I'm running into the exact same in the systray port. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
On Wed, Sep 25, 2013 at 11:22 AM, Sebastian Kügler se...@kde.org wrote:
CMake-gods, can you confirm the below? (It's inconsistent with my
understanding, and how we've done it in the past months, I'd like to have a
specialist opinion before going around and changing every single
CMakeLists.txt in Plasma.)
Thanks,
-- sebas
-- Forwarded Message --
Subject: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
Date: Wednesday, September 25, 2013, 10:36:46
From: Martin Gräßlin mgraess...@kde.org
To: plasma-devel@kde.org
Hi all,
just a short reminder. When adjusting a CMakeLists.txt to Qt5 to enable
e.g. a
dataengine please use the new namespace syntax in target_link_libraries.
E.g:
target_link_libraries(plasma_engine_notifications
Qt5::DBus
KF5::KI18n
KF5::KIconThemes
KF5::KIOCore
KF5::KNotifications
KF5::plasma
KF5::KService
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
and not
target_link_libraries(plasma_engine_notifications
Qt5::DBus
${Plasma_LIBRARIES}
${KI18n_LIBRARIES}
${KIconThemes_LIBRARIES}
${KNotifications_LIBRARIES}
${KService_LIBRARIES}
${KDE4_KIO_LIBS}
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
I just spent the last half our fixing linker errors as ${KI18n_LIBRARIES}
didn't exist any more.
Thanks,
Martin
-
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
The *Config.cmake files should be defining both, if that's not the case
maybe we should be looking deeper at this issue.
Either way, what the definition is, it's (for example):
set(KCompletion_LIBRARIES KF5::KCompletion)
Personally, I prefer not using the variables, because a typo will make it
to run flawlessly but then not working without a warning (because a
nonexisting variable resolves to ).
Aleix
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: private import names
On Wednesday 25 September 2013 12:17:52 Sebastian Kügler wrote: so something like private.org.kde.plasma.widgetname or .org.kde.private.plasma.widgetname The leading . is purposeful? ah, no ;) the first would take a private at the first level, that maybe is not too nice, but the nice part is that it would always be private.$widgetpluginname that has some beauty (and easy filtering) in it I'm cool with private at the beginning, I actually don't care too much, as long as it's consistent. This has been spooking around my mind since I ship- it'ed Bhushan's Icon port, I just like to get rid of this nagging feeling that we have to change something there. And I'm running into the exact same in the systray port. maybe could make sense asking in kde-core-devel as well, since i would like having other kde apps, at leastthe main ones following the scheme as well.. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
Sebastian Kügler wrote: CMake-gods, can you confirm the below? (It's inconsistent with my understanding, and how we've done it in the past months, I'd like to have a specialist opinion before going around and changing every single CMakeLists.txt in Plasma.) Running git log -S KI18n_LIBRARIES shows that I made a mistake and redefined the variable. Fixed now. Thanks, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
On Wednesday, September 25, 2013 12:40:12 Stephen Kelly wrote: Sebastian Kügler wrote: CMake-gods, can you confirm the below? (It's inconsistent with my understanding, and how we've done it in the past months, I'd like to have a specialist opinion before going around and changing every single CMakeLists.txt in Plasma.) Running git log -S KI18n_LIBRARIES shows that I made a mistake and redefined the variable. Fixed now. That wasn't my question, however. :) So the verdict is to use variables? What's the advantage here, all I hear is complaints that errors are harder to find now. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
On Wednesday 25 September 2013 11:22:57 Sebastian Kügler wrote:
CMake-gods, can you confirm the below? (It's inconsistent with my
understanding, and how we've done it in the past months, I'd like to have a
specialist opinion before going around and changing every single
CMakeLists.txt in Plasma.)
My cmake-fu is far from god-level, but my experience is that for frameworks to
build standalone, they must link to other frameworks using ${foo_LIBRARIES}
rather than KF5::Foo.
I take it this is the reason kdelibs/CMakeLists.txt defines many
${foo_LIBRARIES} variables.
Aurélien
-- Forwarded Message --
Subject: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
Date: Wednesday, September 25, 2013, 10:36:46
From: Martin Gräßlin mgraess...@kde.org
To: plasma-devel@kde.org
Hi all,
just a short reminder. When adjusting a CMakeLists.txt to Qt5 to enable e.g.
a dataengine please use the new namespace syntax in target_link_libraries.
E.g:
target_link_libraries(plasma_engine_notifications
Qt5::DBus
KF5::KI18n
KF5::KIconThemes
KF5::KIOCore
KF5::KNotifications
KF5::plasma
KF5::KService
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
and not
target_link_libraries(plasma_engine_notifications
Qt5::DBus
${Plasma_LIBRARIES}
${KI18n_LIBRARIES}
${KIconThemes_LIBRARIES}
${KNotifications_LIBRARIES}
${KService_LIBRARIES}
${KDE4_KIO_LIBS}
${KDE4_KNOTIFYCONFIG_LIBRARY}
)
I just spent the last half our fixing linker errors as ${KI18n_LIBRARIES}
didn't exist any more.
Thanks,
Martin
-
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: private import names
On Wed, Sep 25, 2013 at 10:41 AM, Sebastian Kügler se...@kde.org wrote: Hey, Import names. As we can't use our setContextProperty tricks in subclassed Applets anymore, we'll have to resort more often to installing imports that are very specific (i.e. not libraries per se, but more like C++ portions needed for a certain applet). Examples are Kickoff, Icon, and the dreaded systray. I suggest to use org.kde.plasma.private.$widgetname for this, so we can filter for these imports later on, when our import security has been I already did this in kickoff. It seems a sensible approach. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
QML-using app developers: use private.* imports
Hey all, In Plasma, we've been looking into privatizing parts of the QML API we offer. With Qt5, we rely less on setContextProperty() and friends, and use imports more. That's a technical necessity that makes one problem more evident: It's unclear what QML-facing API is reliable and stable, and what is private and internal API. As there are no restrictions (right now) which imports may be loaded by a piece of QML, we need another solution. Our approach hooks into the import loader, and will disallow loading certain plugins. This is not implemented yet, but we would like to prepare this by having streamlined import names, which can eventually be enforced. We would like to introduce this as good practice for not-just-plasma, so it would be nice if applications could use the same patterns: Only install into org.kde.* what you consider stable API. For internal imports, use private.*, for example private.org.kde.yourapplication.module. Thanks, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Tuesday, September 24, 2013 10:46:24 Matthias Klumpp wrote: Sorry, I confused the naming here... And I am aware offen the previous discussion (followed it, but was not involved) I just think that it might make sense to start a New attempt on this, now that everyone is working towards wayland. Talking to Xfce is a good idea too, imho. I can ask around on this. The issue is not political. We have a fine replacement for the system tray, and we have (maybe) a technical problem supporting the old one. I'll give the QWindow solution a try, so we'll see how far we can get with that. We don't really need much of it, except painting its contents on a QQuickItem, and given we're not the only ones doing a desktop in Qt5, there's a chance we succeed with that. :) The system tray is quite a lot of work to port, so you'll hear from me again once I'm making progress in that specific area. For now, we'll not pour the baby out with the bathwater. Thanks for the valuable input, everybody. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML-using app developers: use private.* imports
On Wed, Sep 25, 2013 at 3:51 PM, Sebastian Kügler se...@kde.org wrote: Hey all, In Plasma, we've been looking into privatizing parts of the QML API we offer. With Qt5, we rely less on setContextProperty() and friends, and use imports more. That's a technical necessity that makes one problem more evident: It's unclear what QML-facing API is reliable and stable, and what is private and internal API. As there are no restrictions (right now) which imports may be loaded by a piece of QML, we need another solution. Our approach hooks into the import loader, and will disallow loading certain plugins. This is not implemented yet, but we would like to prepare this by having streamlined import names, which can eventually be enforced. We would like to introduce this as good practice for not-just-plasma, so it would be nice if applications could use the same patterns: Only install into org.kde.* what you consider stable API. For internal imports, use private.*, for example private.org.kde.yourapplication.module. Thanks, -- sebas Doesn't your naming proposal completely ruin the org.kde.* stuff? Up until now i could fairly safely assume that all QML KDE imports where hidden under org.kde.* but that isn't the case anymore if you introduce private.org.kde.* It looks like you miss a part in the url.. I would say something like this: org.kde.public.* = public imports org.kde.private.* = private imports But that would require changing all existing components to reflect this idea.. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML-using app developers: use private.* imports
hidden under org.kde.* but that isn't the case anymore if you introduce private.org.kde.* From my POV, Sebastian's proposal is spot-on for that reason alone - it is not a (public) 'qml kde import'. It is a private thing. Cheerio, Ivan p.s. and, in all honesty grepping for org.kde will return both, so I don't see it as a nuisance. -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
pot files not being generated anymore
Hi guys, please CC me on replies, I'm not subscribed With the new kde-workspace code, scripty says that all these .pot are not generated anymore +2013-05-08 templates/messages/kde-workspace/plasma_applet_clock.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_dig_clock.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_icon.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_panel.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_trash.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_windowlist.pot +2013-05-08 templates/messages/kde-workspace/plasma_containmentactions_switchdesktop.pot +2013-05-08 templates/messages/kde-workspace/plasma_toolbox_desktoptoolbox.pot +2013-05-08 templates/messages/kde-workspace/plasma_toolbox_paneltoolbox.pot +2013-05-08 templates/messages/kde-workspace/plasma_wallpaper_color.pot +2013-06-06 templates/messages/kde-workspace/plasma_applet_launcher.pot +2013-08-27 templates/messages/kde-workspace/plasma_applet_tasks.pot Shall I delete them or are they going to make a come back anytime soon? Cheers, Albert ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [PMC] Review of major refactoring around All Music mode
Hi Shantanu, Thank you so much for putting so much effort on re-factoring fabian's branch. I checked almost all major/minor features which i remember and all of them works absolutely fine. There are some UI issues which can be fixed later, but functionality wise most of the stuff works fine. If needed you can wait for getting feedback from other community people as well. From my side, you can merge into master :) Cheers! On Mon, Sep 23, 2013 at 9:27 PM, Shantanu Tushar Jha shant...@kde.orgwrote: Hi, * tl;dr * There is new refactored code in fabian-refactoring-shantanu which should be functionally same as master. Please take some time, test it and report if it works fine, or if a major feature is broken. * Long version * Thanks to Fabian, we had started refactoring Plasma Media Center's media browsing code so as to create more reusable components. Finally this is complete with all major functionality working. The code for this lies in the branch fabian-refactoring-shantanu . The salient features are- 1. Backends can now expose multiple models instead of just one. The media browser is smart enough to understand how to display these. See #2. There is 100% backwards compatibility in the sense that older backends with only one model will continue to work, internally stored as a list of just one model. 2. We now have the following reusable components throughout PMC- * GridBrowser - as the name says, give it a backend/model and it will show items in a grid * ListBrowser - same as above, but a list * SplitBrowser - can show two browsers side-by-side for two models * TabBrowser - takes a backend and list of models and shows a browser for each model in tabs * SmartBrowser - give it a model or a list of models, and it figures out which of the above browsers to use 3. Due to these changes, method calls like expand, search etc now take a parameter to the model on which they need to operate. There is 100% backwards compatibility where if the parameter is not present, the first model is picked up. 4. Search can now operate on individual models, giving you support to search any model in your backend. See #3 5. *Best of all* We can throw all the custom/duplicated code for All Music backend as generic browsers in #2 take care of that. (1006 less lines of code!) What do we need? Well if you get some time, please checkout the branch fabian-refactoring-shantanu , test it to make sure no major features are broken. Note, there are still few minor keyboard/UI issues which I will create bug reports for once merged to master. What next? I eagerly wait for comments on how the new browsers work, and unless some major feature is broken, I will go ahead and merge with master this weekend, or earlier if people try out and find no issues. Thanks! -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel -- http://www.sinny.in ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plugin plans
On Wednesday, September 25, 2013 11:48:50 Sebastian Kügler wrote: I'd like to install our binary plugins into subdirectories. This is in line +1 with how we'll do it across KF5. These plugins won't need .desktop files +10 The new API also allows us to use packages' metadata for querying. It means building up a KPluginInfo::List from metadata (so a bit of crawling through the filesystem, but probably not recursively, to list plugins. Looking at plasmapkg, the code to list packages is a bit convoluted right now, and I'd like to see that fixed. it is convoluted because *some* of our packages registered .desktop files with ksycoca, some didn’t. what i like about the new system is ksycoca dies as far as we’re concerned and all packages, binary or scripted or just plain data (e.g. wallpapers) can be treated identically. huzzah. With this in place, we can tackle more pieces of Plasma::PluginLoader to make it sycoca-free. Obviously, this is your chance to weigh in. :) i have nothing to say other than “fuck yeah -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plugin plans
On Wednesday, September 25, 2013 21:47:59 Aaron J. Seigo wrote: On Wednesday, September 25, 2013 11:48:50 Sebastian Kügler wrote: I'd like to install our binary plugins into subdirectories. This is in line +1 with how we'll do it across KF5. These plugins won't need .desktop files +10 The new API also allows us to use packages' metadata for querying. It means building up a KPluginInfo::List from metadata (so a bit of crawling through the filesystem, but probably not recursively, to list plugins. Looking at plasmapkg, the code to list packages is a bit convoluted right now, and I'd like to see that fixed. it is convoluted because *some* of our packages registered .desktop files with ksycoca, some didn’t. what i like about the new system is ksycoca dies as far as we’re concerned and all packages, binary or scripted or just plain data (e.g. wallpapers) can be treated identically. huzzah. It'll be a bit of work, but can be done somewhat gradually. First the dataengines, then different sorts of packages.means Ironically, I think during our last sprint, I made them all use .desktop files, now I'll make it so they won't. All in the name of progress. ;) With this in place, we can tackle more pieces of Plasma::PluginLoader to make it sycoca-free. Obviously, this is your chance to weigh in. :) i have nothing to say other than “fuck yeah Awesome. I have a branch doing this for all dataengines, and switching the dataengine loading to KPluginTrader. All my tests pass, and I'm ready to merge these bits. It should be backwards compatible (i.e. having plugins in the old path around won't matter much, they won't be found there). Changing the cmake installation path was rather straightforward (or so thought my perl script). Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: pot files not being generated anymore
Hey Albert, On Wednesday, September 25, 2013 19:48:36 Albert Astals Cid wrote: With the new kde-workspace code, scripty says that all these .pot are not generated anymore +2013-05-08 templates/messages/kde-workspace/plasma_applet_clock.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_dig_clock.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_icon.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_panel.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_trash.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_windowlist.pot +2013-05-08 templates/messages/kde-workspace/plasma_containmentactions_switchdesktop.po t +2013-05-08 templates/messages/kde-workspace/plasma_toolbox_desktoptoolbox.pot +2013-05-08 templates/messages/kde-workspace/plasma_toolbox_paneltoolbox.pot +2013-05-08 templates/messages/kde-workspace/plasma_wallpaper_color.pot +2013-06-06 templates/messages/kde-workspace/plasma_applet_launcher.pot +2013-08-27 templates/messages/kde-workspace/plasma_applet_tasks.pot Shall I delete them or are they going to make a come back anytime soon? They're all very much alive and kicking. Question: are those files not generated anymore because no i18n calls are found, or is the Messages.sh simply missing? In any case, it needs fixing, not deleting. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: kill the systray?
On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote: When I asked Martin if he knew a way to do the xembed, he replied (being Martin ;)) asking if we can just kill it and quoted starwars. I wonder: Can we kill it yet? I just had a discussion on G+ with a couple of our friends with GNOME about this matter[1]. Apparently they are thinking of just dropping support for system tray icons altogether, and deprecating the API in Gtk+. If that does indeed happen, then that is a major step towards being able to kill support for it. The only remaining problem then becomes Qt5. QSystemTrayIcon does not support the DBus protocol .. it should, really, since the two largest Linux desktop envs built on Qt use it ;) [1] https://plus.google.com/u/0/110564179941764460291/posts/GrfpS9GvLqX -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[plasma-framework] src/plasma: Look up dataengines in kf5/plasma/dataengines
Git commit 5b33844a0b9e49759289dc839a31c0bc8f417d37 by Sebastian Kügler.
Committed on 25/09/2013 at 23:34.
Pushed by sebas into branch 'master'.
Look up dataengines in kf5/plasma/dataengines
This changes the path where to find dataengines to the
subdirectory-per-servicetype setup.
Note: You'll need to update and reinstall kde-workspace/plasma, to
install the dataengines into the new path.
CCMAIL:plasma-devel@kde.org
M +1-1src/plasma/pluginloader.cpp
http://commits.kde.org/plasma-framework/5b33844a0b9e49759289dc839a31c0bc8f417d37
diff --git a/src/plasma/pluginloader.cpp b/src/plasma/pluginloader.cpp
index 20a89b4..4991492 100644
--- a/src/plasma/pluginloader.cpp
+++ b/src/plasma/pluginloader.cpp
@@ -117,7 +117,7 @@ QString PluginLoaderPrivate::parentAppConstraint(const
QString parentApp)
PluginLoader::PluginLoader()
: d(new PluginLoaderPrivate)
{
-d-pluginDir = kf5;
+d-pluginDir = kf5/plasma/dataengine;
d-isDefaultLoader = false;
}
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [plasma-framework] src/plasma: Look up dataengines in kf5/plasma/dataengines
On Wednesday, September 25, 2013 23:43:43 Sebastian Kügler wrote: This changes the path where to find dataengines to the subdirectory-per-servicetype setup. for shit’s ‘n giggles: has anyone done any performance profiling of this new system? -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: pot files not being generated anymore
El Dimecres, 25 de setembre de 2013, a les 23:32:18, Sebastian Kügler va escriure: Hey Albert, On Wednesday, September 25, 2013 19:48:36 Albert Astals Cid wrote: With the new kde-workspace code, scripty says that all these .pot are not generated anymore +2013-05-08 templates/messages/kde-workspace/plasma_applet_clock.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_dig_clock.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_icon.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_panel.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_trash.pot +2013-05-08 templates/messages/kde-workspace/plasma_applet_windowlist.pot +2013-05-08 templates/messages/kde-workspace/plasma_containmentactions_switchdesktop.p o t +2013-05-08 templates/messages/kde-workspace/plasma_toolbox_desktoptoolbox.pot +2013-05-08 templates/messages/kde-workspace/plasma_toolbox_paneltoolbox.pot +2013-05-08 templates/messages/kde-workspace/plasma_wallpaper_color.pot +2013-06-06 templates/messages/kde-workspace/plasma_applet_launcher.pot +2013-08-27 templates/messages/kde-workspace/plasma_applet_tasks.pot Shall I delete them or are they going to make a come back anytime soon? They're all very much alive and kicking. Question: are those files not generated anymore because no i18n calls are found, or is the Messages.sh simply missing? Either of the cases can be the reason, you'll have to look at why for each of them. Cheers, Albert In any case, it needs fixing, not deleting. Cheers, ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 112727: Shrink (fancy) unhide trigger when entered while FS window is active
On Sept. 24, 2013, 10:31 a.m., Martin Gräßlin wrote: no idea whether that's acceptable shouldn't be much of an issue. KWindowSystem is emitting a signal, isn't it? activeWindowChanged() There's been concerns about waking up when windows were moved and KWindowSystem has no disconnectNotify implementation, so once you hooked onto KWindowSystem signals, you're afair not easily getting rid of it's X11 event filtering. - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112727/#review40664 --- On Sept. 14, 2013, 2:36 p.m., Thomas Lübking wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112727/ --- (Updated Sept. 14, 2013, 2:36 p.m.) Review request for Plasma, Aaron J. Seigo and Martin Gräßlin. Description --- Drawback: the next trigger will go unfancied (would require listening to active window changes, no idea whether that's acceptable) but that's still much better than occluding 30 outer px of a window (see bug and http://forum.kde.org/viewtopic.php?f=111t=112163) Notice that a) nor auto unhiding neither hinting happens at all while there's a(n active) fullscreen window - this is unchanged (see early exit in patched branch) b) the patch does nothing if you don't attempt to enter the occluded area of a fullscreen window (so not even the next hinting will be affected) This addresses bug 217560. http://bugs.kde.org/show_bug.cgi?id=217560 Diffs - plasma/desktop/shell/panelview.cpp dcd051a Diff: http://git.reviewboard.kde.org/r/112727/diff/ Testing --- m_unhideTrigger shrinks and the next unhide is not indicated (but the panel appears), subsequent indication remains unaffected. Thanks, Thomas Lübking ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML-using app developers: use private.* imports
On Wed, Sep 25, 2013 at 3:51 PM, Sebastian Kügler se...@kde.org wrote: Hey all, In Plasma, we've been looking into privatizing parts of the QML API we offer. With Qt5, we rely less on setContextProperty() and friends, and use imports more. That's a technical necessity that makes one problem more evident: It's unclear what QML-facing API is reliable and stable, and what is private and internal API. As there are no restrictions (right now) which imports may be loaded by a piece of QML, we need another solution. Our approach hooks into the import loader, and will disallow loading certain plugins. This is not implemented yet, but we would like to prepare this by having streamlined import names, which can eventually be enforced. We would like to introduce this as good practice for not-just-plasma, so it would be nice if applications could use the same patterns: Only install into org.kde.* what you consider stable API. For internal imports, use private.*, for example private.org.kde.yourapplication.module. Thanks, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 Reducing API to maintain is a good thing, at least for complexity sake. But of course there will be always the case where somebody needs (part of) the private API. The question would be then, why is it that there's some API that's only needed for internal usage? If it's needed internally, it will be most likely needed externally, at some point. The fact that you decide to label it as private makes frustrated developers. Either way, I have no idea of what we're talking about here. :D Cheers! Aleix ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: pot files not being generated anymore
On Thursday, September 26, 2013 02:05:12 Albert Astals Cid wrote: They're all very much alive and kicking. Question: are those files not generated anymore because no i18n calls are found, or is the Messages.sh simply missing? Either of the cases can be the reason, you'll have to look at why for each of them. OK, thanks. I'll fix. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML-using app developers: use private.* imports
Hola, On Thursday, September 26, 2013 02:23:31 Aleix Pol wrote: Reducing API to maintain is a good thing, at least for complexity sake. But of course there will be always the case where somebody needs (part of) the private API. The question would be then, why is it that there's some API that's only needed for internal usage? If it's needed internally, it will be most likely needed externally, at some point. The fact that you decide to label it as private makes frustrated developers. Either way, I have no idea of what we're talking about here. :D It's not a question of usefulness, it's a question of maintainability. We offer some basic functionality If / when a private import is needed, there's a bunch of things to solve. Dependencies, documentation and very important API stability. For public APIs, we definitely want to offer API stability, but it doesn't make sense for everything, so by making these imports private, we keep the flexibility to develop them however we want, otherwise, we quickly end up with a huge bunch of code that we need to maintain backwards compatibility for, just in case someone else wants to use this, often highly specific, code. Also outside of the C++ world, you don't want to install all apps' internal bits and pieces as system-wide available libraries. We want to make it easy to extend QML apps, plasmoids, etc. using C++, but without the costs of public libraries. This isn't to say that these things will not ever be shared, if something turns out to be very useful for more than one Plasmoid, for example, we can still promote it to public API, with all the costs that incurs. They just need to weigh up against the work we need to put into it, and someone actually has to do the effort, bring it up to library quality and maintain it. Another very important aspect is security. We eventually want to arrive in a world, where QML apps can only use imports they are allowed to. You most definitely don't want a random piece of QML to access models of your Akonadi db, Nepomuk, do random file-system stuff, etc.. Using the new-in-Qt5.2 QUrlInterceptor in the scriptengine allows us to control what's accessed from within the QML runtime. This is described in detail on http://community.kde.org/Plasma/conditionalQMLImports and the result of design done during Akademy / QtCS in Bilbao. Pretty cool stuff, actually. :) Examples for private imports are Kickoff-internal models, sytemtray models and items, KIO and mimetype tricks for showing icons on the desktop. Apply the same idea to Kontact Touch's QML imports, to Telepathy's, etc. It all makes sense! Lastly, we are responsible for our APIs not becoming a random mess. This is one measure to prevent that from happening. Focus and quality usually trumps size. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [plasma-framework] src/plasma: Look up dataengines in kf5/plasma/dataengines
On Thursday, September 26, 2013 01:50:54 Aaron J. Seigo wrote: On Wednesday, September 25, 2013 23:43:43 Sebastian Kügler wrote: This changes the path where to find dataengines to the subdirectory-per-servicetype setup. for shit’s ‘n giggles: has anyone done any performance profiling of this new system? Yes: It's slower. I've run some tests on both, SSD and rotating rust with small, large, and huge plugin directories. In the best case (warm caches, reasonable directory size), we're within an order of magnitude of ksycoca (800%). Obviously, keeping the number of plugins per directory small makes it faster. You can find numbers of the SSD runs in my email Plugin locator performance ballpark to kde-frameworks-devel from September, 5. I haven't cleaned up my measurements on rotating metal. Especially on startup of Plasma, we'll get quite a performance hit. I think we can avoid that in part by caching the KPluginInfo::Lists for maybe just a few seconds in Plasma::PluginLoader. That means that most of our consecutive queries run over cached lists, making them orders of magnitude faster. That should save a hell of a lot of IO during start-up, while keeping memory usage in check. Bottom line, if we're still not happy with the performance, we might need an on-disk cache in KPluginTrader, but the complexity of keeping that up to date with a system as flexible, dynamic and component-driven as Plasma, is something, say, worth avoiding. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [plasma-framework] src/plasma: Look up dataengines in kf5/plasma/dataengines
On Thursday, September 26, 2013 04:21:21 Sebastian Kügler wrote: You can find numbers of the SSD runs in my email Plugin locator performance ballpark to kde-frameworks-devel from September, 5. I haven't cleaned up my measurements on rotating metal. oh wow, that is not encouraging. :/ i’m suddenly less enthused by this idea. Bottom line, if we're still not happy with the performance, we might need an on-disk cache in KPluginTrader, but the complexity of keeping that up to date with a system as flexible, dynamic and component-driven as Plasma, is something, say, worth avoiding. problem is that 100-300ms on a high end machine is not acceptable. given that we load plugins at various times during execution based on user interaction, this will not just impact on startup, but during runtime. without a cache we’d end up having to do something truly fun like put the lookups in a thread, keeping an in-memory cache ... not something i expect we can ask of every application developer, either. basically what dfaure said in the kf5-devel thread. he also noted that it would be possible to use a cache that is updated when the item gets put on disk. e.g. as part of “make install”. that would be rather fantastic and probably resolve the issue entirely. -- Aaron J. Seigo ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: kill the systray?
On Thursday 26 September 2013 01:27:54 Aaron J. Seigo wrote: On Tuesday, September 24, 2013 17:06:14 Sebastian Kügler wrote: When I asked Martin if he knew a way to do the xembed, he replied (being Martin ;)) asking if we can just kill it and quoted starwars. I wonder: Can we kill it yet? I just had a discussion on G+ with a couple of our friends with GNOME about this matter[1]. Apparently they are thinking of just dropping support for system tray icons altogether, and deprecating the API in Gtk+. If that does indeed happen, then that is a major step towards being able to kill support for it. the bad part of the discussion is that it looks like they want to reinvent the wheel and given some statements lately (e.g. GTK+ is just for developing for GNOME Shell) I'm not every optimistic that they will even hardly think about anything than their system. The only remaining problem then becomes Qt5. QSystemTrayIcon does not support the DBus protocol .. it should, really, since the two largest Linux desktop envs built on Qt use it ;) looks like we need to fix that for 5.3 :-) 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
