Re: Review Request 102350: Implement automatic scanning of source code for required data engines
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/102350/ --- (Updated Sept. 22, 2016, 8:34 p.m.) Status -- This change has been discarded. Review request for Plasma. Repository: kdelibs Description --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: https://git.reviewboard.kde.org/r/102350/diff/ Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin Kofler
Re: Review Request 102291: Trigger installation of missing components when installing a package
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/102291/ --- (Updated Sept. 22, 2016, 8:34 p.m.) Status -- This change has been discarded. Review request for Plasma. Repository: kdelibs Description --- This is another part of my GSoC 2011 work. For script engines, the existing metadata (X-Plasma-API) is sufficient. For data engines, we introduce a new metadata entry: X-Plasma-RequiredDataEngines. Third-party packages will have to add this entry to benefit from this feature at this time. Automatic support for scanning package source code on installation (at least for some languages) is planned, but the metadata entry is definitely the most efficient method. Diffs - plasma/package.cpp 4c00d36 plasma/packagemetadata.h b10f0e4 plasma/packagemetadata.cpp 59163b2 Diff: https://git.reviewboard.kde.org/r/102291/diff/ Testing --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine right after installing a Python widget (I used Veromix for my test) through KHNS (not only when actually using it) on Fedora 15. Also verified that there is no such prompt if plasma-scriptengine-python is already installed. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin Kofler
[Breeze] [Bug 347524] Qt Creator Options crashed in Breeze theme
https://bugs.kde.org/show_bug.cgi?id=347524 Kevin Kofler kevin.kof...@chello.at changed: What|Removed |Added CC||kevin.kof...@chello.at --- Comment #5 from Kevin Kofler kevin.kof...@chello.at --- This crashes on a call to free, a Valgrind log (output of running Qt Creator in Valgrind, with the default memcheck tool) would be helpful. -- You are receiving this mail because: You are the assignee for the bug. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: bluedevil and bluez5
Jonathan Riddell wrote: Ubuntu is wanting to move to bluez5, is bluedevil ready for this at all? Fedora has been shipping Bluedevil for BlueZ 5 for over a year. The old BlueZ 4 is long gone in Fedora. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Workspaces 4.11: the last feature release in the 4.xseries for kde-workspace
On Friday 03 May 2013 at 14:39:31, Aaron J. Seigo wrote: a completely workable approach was suggested. the work on ksecrets started and stopped a couple times. A complicated workaround for the freeze was suggested that would have been a lot of work when the existing much simpler approach already worked. The approach would have had no technical advantage other than working around the pointless freeze. (Quite the opposite, the plugin approach that was suggested would have introduced a circular dependency in distribution packages.) It's no wonder the KSecrets developer didn't have the time and/or motivation to rewrite all his code for that approach. at one point it was tested for inclusion and apparently it did not work in some configurations (i forget the exact issue; it was quite a while ago and the discussion iirc was on kde-packager?). but usefully, it progressed quite far. The version that got released didn't work at all: * replacing KWallet didn't work because the kdelibs patch was rejected and the suggested plugin-based solution was never implemented, * replacing gnome-keyring didn't actually work either, and the bug(s) which prevented that from working was/were never fixed because the project got abandoned due to the kdelibs freeze. We tried packaging it in Fedora. The above was what we found out. And we were not alone: In fact, KSecrets got removed from later coordinated KDE releases due to it not working at all. hopefully you can put it in a repository that can be used by kdelibs which would both get around the 4.x kdelibs freeze *and* prepare it for frameworks. I'm not the KSecrets developer. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Workspaces 4.11: the last feature release in the 4.xseries for kde-workspace
On Friday 03 May 2013 at 17:04:44, Matthias Klumpp wrote: @Kevin: I am only remotely following this issue, but as PackageKit developer, I would of course like to see our project in Plasma Workspaces as soon as possible. But I don't know the exact issues here. Also, having KSecrets merged would be a nice goal too. (The SecretService API is very stable, and has the potential to become a new de-facto XDG standard soon) The issues are the same in both cases: They're kdelibs features and kdelibs does not accept any features. By the time the first release of the Plasma Workspaces based on KF5 is planned, kdelibs will have been feature-frozen for THREE YEARS!!! (And I'm not even speaking of applications there!) This is a completely unacceptably long freeze period. It's time to reopen kdelibs for new features (though a lot of the damage has already been done! But still, it'd prevent any further damage) instead of freezing kde-workspace the same way. So, why not work on merging all this stuff into Workspaces 5 as early as possible, so it is present there? Because Workspaces 5 / 2 / whatever (versioning and naming have become a total mess ever since the rebranding fiasco) is not anywhere near testable. Not even Frameworks 5 is (but my feature is not really testable without a working plasma-desktop anyway). At best I could dump a completely untested and untestable code drop. In addition, even just compiling the change to verify that it even builds takes hours because there are no packages to work against. (We have Qt 5 packages now going through review in Fedora, which is a lengthy process; KF5 is not even started, and to be honest I'm not sure whether it even makes sense to start packaging it in its current stage.) Testing my kdelibs 4.x patch was easy: I backported it to the version of kdelibs that was stable in Fedora, rebuilt my kdelibs package with it, updated kdelibs on my notebook, restarted plasma-desktop and tested the feature that way. (With having WS 4.11 frozen, it IMHO does not make any sense at all to develop new features for it, unless the new feature works on both Workspaces versions with less modifications) The problem there is exactly that 4.x is frozen. It's not practical to develop features against 5 yet! Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Plasma Workspaces 4.11: the last feature release in the 4.xseries for kde-workspace
Martin Gräßlin mgraess...@kde.org schrieb: @Kevin: could you please stop this nonesense about your GSoC project. Yes we all got that you are frustrated two years ago. Enough is enough! I don't want to ever read about it any more! OK, so let's put aside *my* project and look at a more important one which got sabotaged even more by the kdelibs freeze: KSecrets! At least my project works (as a distro patch), KSecrets never got finished after the kdelibs patch was rejected. Really sad for a cross-desktop interoperability project all distros had been waiting for for ages! :-( Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma Workspaces 4.11: the last feature release in the 4.x series for kde-workspace
On Wednesday 01 May 2013 at 09:41:15, Andriy Rysin wrote: If the feature freeze for 4.11 is May 22 and there is no more feature releases for branch 4.x, where all those features from GSoC go? Probably the same as my libplasma PackageKit integration from GSoC 2011: in the digital nirvana and/or in distro patches. :-( Just as for kdelibs, I really don't understand the purpose of sabotaging the work of those people who want to implement features in 4.x. Doing this in parallel to Qt-5-based long-term development is exactly what git (or any half- decent SCM, really) has branches for. It would not be the same people working on the 2 branches. The kdelibs freeze has sabotaged several important features distributions have been waiting for for years, e.g. KSecrets (which was abandoned in non-working stage after the kdelibs patches were rejected). We should not repeat the same mistake for kde-workspace! Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 105139: Plasmate: Add tabbox previewer
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105139/#review29232 --- Unfortunately, the binary files (the .png images) are not contained in the diff, and were therefore created in the repository as 0-byte files! - Kevin Kofler On June 11, 2012, 4:15 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105139/ --- (Updated June 11, 2012, 4:15 p.m.) Review request for kwin, Plasma and Martin Gräßlin. Description --- Hello, This is the second task of my GSoC.Everything seems to work execpt from: 1)The icon of the refresh (in the tabbox previewer) is not visible. 2)I couldn't try if the refresh works... This addresses bug master. http://bugs.kde.org/show_bug.cgi?id=master Diffs - CMakeLists.txt 12f8a3a editors/metadata/metadataeditor.cpp afc6250 mainwindow.cpp 6f72624 previewer/windowswitcher/standalone/main.cpp PRE-CREATION previewer/windowswitcher/standalone/windowswitcherpreviewer.h PRE-CREATION previewer/windowswitcher/standalone/windowswitcherpreviewer.cpp PRE-CREATION previewer/windowswitcher/tabboxdelegate.qml PRE-CREATION previewer/windowswitcher/tabboxpreviewer.h PRE-CREATION previewer/windowswitcher/tabboxpreviewer.cpp PRE-CREATION previewer/windowswitcher/thumbnailitem.h PRE-CREATION previewer/windowswitcher/thumbnailitem.cpp PRE-CREATION previewer/windowswitcher/thumbnails/dolphin.png PRE-CREATION previewer/windowswitcher/thumbnails/kmail.png PRE-CREATION previewer/windowswitcher/thumbnails/konqueror.png PRE-CREATION previewer/windowswitcher/thumbnails/systemsettings.png PRE-CREATION previewer/windowswitcher/windowswitcher.h PRE-CREATION previewer/windowswitcher/windowswitcher.cpp PRE-CREATION startpage.cpp cb14f16 Diff: http://git.reviewboard.kde.org/r/105139/diff/ Testing --- Screenshots --- http://git.reviewboard.kde.org/r/105139/s/590/ Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 105139: Plasmate: Add tabbox previewer
On March 14, 2013, 9:14 p.m., Kevin Kofler wrote: Unfortunately, the binary files (the .png images) are not contained in the diff, and were therefore created in the repository as 0-byte files! Antonis Tsiapaliokas wrote: @kevin: Yes, that's correct, but i am using local branches for my patches. So i don't think that there is an issue with the plasmate. Did you find any bug about those images? Is there some issue? https://projects.kde.org/projects/extragear/sdk/plasmate/repository/revisions/master/show/plasmate/previewer/windowswitcher/thumbnails Everything is 0 bytes there (and thus also in the Plasmate 1.0 tarballs). - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105139/#review29232 --- On June 11, 2012, 4:15 p.m., Antonis Tsiapaliokas wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105139/ --- (Updated June 11, 2012, 4:15 p.m.) Review request for kwin, Plasma and Martin Gräßlin. Description --- Hello, This is the second task of my GSoC.Everything seems to work execpt from: 1)The icon of the refresh (in the tabbox previewer) is not visible. 2)I couldn't try if the refresh works... This addresses bug master. http://bugs.kde.org/show_bug.cgi?id=master Diffs - CMakeLists.txt 12f8a3a editors/metadata/metadataeditor.cpp afc6250 mainwindow.cpp 6f72624 previewer/windowswitcher/standalone/main.cpp PRE-CREATION previewer/windowswitcher/standalone/windowswitcherpreviewer.h PRE-CREATION previewer/windowswitcher/standalone/windowswitcherpreviewer.cpp PRE-CREATION previewer/windowswitcher/tabboxdelegate.qml PRE-CREATION previewer/windowswitcher/tabboxpreviewer.h PRE-CREATION previewer/windowswitcher/tabboxpreviewer.cpp PRE-CREATION previewer/windowswitcher/thumbnailitem.h PRE-CREATION previewer/windowswitcher/thumbnailitem.cpp PRE-CREATION previewer/windowswitcher/thumbnails/dolphin.png PRE-CREATION previewer/windowswitcher/thumbnails/kmail.png PRE-CREATION previewer/windowswitcher/thumbnails/konqueror.png PRE-CREATION previewer/windowswitcher/thumbnails/systemsettings.png PRE-CREATION previewer/windowswitcher/windowswitcher.h PRE-CREATION previewer/windowswitcher/windowswitcher.cpp PRE-CREATION startpage.cpp cb14f16 Diff: http://git.reviewboard.kde.org/r/105139/diff/ Testing --- Screenshots --- http://git.reviewboard.kde.org/r/105139/s/590/ Thanks, Antonis Tsiapaliokas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Breadcrumbs in Kickoff
Martin Gräßlin wrote: Which significant number of critical comments? How many users have commented here in the thread and reported bugs? 5? 10? 20? We are talking about a feature which will be used by millions of users. If we get to a thousand users complaining we can start to think about significant numbers. FYI, we've got a bunch of complaints on #fedora-kde about this. Not everyone affected goes post to plasma-devel. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kickoff-QML and classic launcher
Martin Graesslin wrote: * Would it be acceptable to drop the classic menu completely? This would be more consistent with the general concept of having only one applet per area. Optionally the classic menu could be re-added in Plasma-Addons just like Lancelot. You can pry my classic menu from my cold, dead hands! Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Kickoff-QML and classic launcher
Aaron J. Seigo wrote: it's really a horrible hack and i'd suggest getting rid of it. people can add the classic menu from the widget explorer like all the rest. This is just going to make it much harder to switch to a menu people like me can actually use. :-( Especially for people switching to Plasma from other environments still using old-school menus, this will make it harder for them to get started. And I'm not at all convinced that a UI which replaces the entire panel with a different template which happens to include a different menu is a good UI to replace that. I think it would be better to find a way to preserve the settings, such that switching and switching back doesn't lead to reset settings. Removing the UI is not a nice fix. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Breadcrumbs in Kickoff
Rick Stockton wrote: Alexey, you have two of KDE's smartest people (Aaron and Martin) in agreement that we probably want to provide this via the Back Button on the Mouse. (Less new code, less confusion, less maintenance headache.) That assumes that the mouse has such a nonstandard button in the first place. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtQuick 1.0 vs 1.1
Martin Gräßlin wrote: I am more for dependency on 4.7.4, but it has to be clarified with the release team and probably packagers. Till 4.8 is released all distros should ship it and all packaging systems should support it. So it's hopefully just a = 4.7.4 instead of =4.7.0 From the Fedora side, absolutely no objections to depending on = 4.7.4, in fact we'd appreciate it if it means fewer bugs. All our supported releases (i.e. Fedora 14 and newer) have at least 4.7.4 in updates already. In fact, as far as we're concerned, you could even require = 4.8.0. Fedora 16 ships Qt 4.8 RC and we aren't planning to ship KDE SC 4.8 to Fedora 15 (and Fedora 14 will be dead by that time). But 4.7.4 is definitely no problem. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: ScreenSaver and KDE Plasma 4.8?
Martin Gräßlin wrote: Well if they do I promise to ship an update to kwin to ensure that xscreensaver is stacked underneath the desktop shell ;-) They'll find a way around that too. If you make something idiot-proof, nature builds a better idiot. ;-) (And sorry, I don't remember who originally came up with that citation.) Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
Ivan Čukić wrote: Probably because the distros are not shipping 4.7 yet. (4.1 to 4.6 actually do show desktop icons by default, in a folder view widget which is set up by No plasma release had the folderview by default. Some of the distros had (have) the folder view as default containment, but that is NOT our default. The default containment was the plain/empty desktop (not the folder view), *but* 00-defaultLayout.js used to put a folder view widget showing the xdg-user-dir for Desktop (i.e. ~/Desktop or a translation of it) on that desktop containment for all new users. This got removed for 4.7 by the following commit: https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/70e746d3fae467c52ab91cb7e8b5b10f2519248b Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: ScreenSaver and KDE Plasma 4.8?
Martin Gräßlin wrote: What would you say if KDE Plasma would no longer support X Screensavers? * I would switch to another DE * I would complain * I would miss them but could live without them * Don't use screensavers, it doesn't affect me * Don't care You forgot option 6: * Come up with some buggy hack to use xscreensaver directly (maybe even with a custom idle detector which runs it in test mode, you never know what creative hacks people come up with), advertise it loudly as THE solution to fix screen savers in KDE Plasma, then rush the forums together with all the followers using that fix to complain loudly about everything that breaks due to the hack, blaming Plasma for it. (because that's exactly what I expect to happen). Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
Aaron J. Seigo wrote: unless we give them something better and communicate with understanding. Users will not accept your something better unless their favorite existing screensaver runs on it. No amount of communication can change that. (And please don't shoot the messenger! I don't even use a screensaver myself, so I personally couldn't care less about this change.) Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
Andras Mantia wrote: I don't like if software forces me to work in a certain way. And with activities I'm not alone. I'm happy without them, even if they are useful for others. Just as I'm mostly happy also without virtual desktops (which are a must for others). People are different, they have different workflows that they don't want to change if there is no *good* reason to do it. [snip] Please, keep this option. Having a way to control the power magament setting per activity is fine, but leave the possibility to change (and configure) the settings without having to use activities. +1 I personally also don't use custom power management profiles, but to me, tying this to Plasma activities (which I don't use and am certainly not alone in not using) sounds very wrong. Plasma activities affect many more things than just power management. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The future of Power Management - together with Activities
Dario Freddi wrote: we plan to remove the Warning step Uhm, wait a minute… Do you mean you will just suspend or shut down the machine with no warning whatsoever? If that's really what you mean, to me, this sounds incredibly rude and might lead to data loss – especially if shut down is the chosen option, but even suspending or hibernating can be fatal, e.g. for online games (and yes, there's now wireless Internet, whereas wireless power has yet to be invented, at least one which works at a distance of more than a couple cm ;-) ), or if a kernel bug is breaking the suspending. So far all the discussion has focused on the activities thing, but if you really mean what I think you mean, this issue is even more important. We MUST give the user a chance to save his/her work and/or to plug the power in before we trigger a shutdown or suspend. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
Luca Beltrame wrote: After all, in the KDE Forums we don't see anymore people lamenting the lack of icons on desktop by default... Probably because the distros are not shipping 4.7 yet. (4.1 to 4.6 actually do show desktop icons by default, in a folder view widget which is set up by default.) Or because users upgrading from a previous version of Plasma get to keep their folder view, and those are the ones already testing 4.7. Or maybe because the distros are now overriding this broken 4.7 default, as Fedora is now doing for Fedora 16 (as of kde-settings-4.7-7.fc16). (We restore the good old folder view widget, otherwise people won't even see an icon to install their live CD to the hard disk: https://bugzilla.redhat.com/show_bug.cgi?id=740676 . Note that this fix is actually not yet in F16 Beta, it will be in F16 Final. And any complaints about us actually using the JavaScript-based customization feature Plasma explicitly offers for distributions to use will be sent straight to /dev/null…) I'm fairly sure that when the first major distro starts shipping with 4.7 without a custom Plasma init script enabling the folder view of ~/Desktop one way or the other (either as a widget as in 4.6 or in Fedora 16, or the KDE-3-style folder view as desktop mode), complaints will start popping in in droves. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: The case for a kdelibs 4.8
On Thursday 29 September 2011, Heinz Wiesinger wrote: From what I remember from the desktop summit the picture you draw here is quite an exaggeration of what is actually happening. kdelibs 4.7 is meant to be frozen for new features, but not for bugfixes. Bugfix releases of kdelibs-4.7 happenend and I'm sure will continue on happening. As for the versioning I don't see why one of those bugfix releases couldn't be rebranded as 4.8.0 if that makes things easier (that was even briefly mentioned at the release team BoF). It does not solve feature backports of course. But one of my points is that we need features too, not just bugfixes. Continuing 4.7.x releases solves the problem of bugfixes just fine, but entirely fails to address the issue of features. The KDE Frameworks 5.0 development is not meant to take forever. In fact I think it's meant to be finished around early 2012, which would leave us with a frozen kdelibs for one KDE SC release, maximum two. It's also not a huge *we will break everything! Kittens will die!* release, but basically just a restructuration of the code, with little to no adjustments necessary for applications. (that was how it was marketed, anyway). The way I understood it was that there could very well be a KDE SC 4.9 release shipping a 4.9 workspace on top of 5.0 frameworks. I don't think a date of early 2012 is realistic at all. With upstream already working on Qt 5, I think it doesn't make any sense whatsoever to break everything twice, once for KDE Frameworks 5 and once for Qt 5. Yet I strongly doubt that Qt 5 will be out so soon. Even if the changes required for applications will be small, they will be needed (e.g. deprecated stuff will be dropped, and some applications are still using it), and I don't think it is friendly to application developers at all to have 2 flag days. Plus, it would mean that the KDE Frameworks and Qt major versions would get out of sync for the first time in KDE's history. We should also learn from the past: Things not meant to take forever end up taking longer than expected anyway, and each time, we're stuck with the temporary kludges for much longer than initially planned: * KDE 4 picked up delay after delay, and the long-lived 3.5 branch ended up becoming a mixed feature and bugfix branch (which IMHO is not necessarily a bad model, and which could even work for kdelibs 4.7, but it was still an exception). * The Akonadi-based kdepim picked up delay after delay as well, and so first its merge was postponed release after release, and only small pieces merged each time, and then we got stuck with a long-lived 4.4 branch, including a temporary and incomplete Akonadi-based KAddressBook for which we were initially promised that it'd be much better in 4.5. And now kdepim 4.4 is already discontinued and many users still consider 4.7 too unstable for their use. We must plan for major developments to take longer than the initial optimistic estimate. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: ScreenSaver and KDE Plasma 4.8?
Martin Gräßlin wrote: * drop screensaver support altogether, probably would create some troubles as evil KDE removed screensavers * add Plasma widget support to new screen locker implementation but drop screensaver support (same problems as first option) I don't think these are acceptable. Our users will complain loudly if their screensavers stop working. And then blogs and forum posts will pop up with various buggy hacks for how to use xscreensaver directly in KDE, with the resulting support nightmare. As useless as a screensaver is these days, users LOVE these things and will NOT put up with losing that feature. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Bugfix: Plasma::PackageMetadata::read: Match the behavior of KService
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102404/#review6930 --- Ping? Can I commit this bugfix to the KDE/4.7 branch? - Kevin Kofler On Aug. 22, 2011, 12:49 a.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102404/ --- (Updated Aug. 22, 2011, 12:49 a.m.) Review request for Plasma. Description --- Also delete the duplicate entries in PackageMetadata::write. This one is a bugfix, and so should be OK for 4.7. While testing my GSoC work, I noticed that Plasma::PackageMetadata::read only looks for X-KDE-ServiceTypes, whereas KService concatenates the contents of ServiceTypes and X-KDE-ServiceTypes. There are metadata.desktop files out there using ServiceTypes without the X-KDE prefix. I also fixed it to look for both Keywords and X-KDE-Keywords as KService does, not just Keywords. Diffs - plasma/packagemetadata.cpp 59163b2 Diff: http://git.reviewboard.kde.org/r/102404/diff/diff Testing --- Compiles on Fedora 15. Thanks, Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implement automatic scanning of source code for required data engines
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/ --- (Updated Sept. 27, 2011, 11:01 p.m.) Review request for Plasma. Changes --- * Added support for declarativeappletscript QML code (tested on telepathy-kde-presence-applet). * plasma-dataengine-depextractor: Make sure we pass an absolute path to KDesktopFile (use QDir::absoluteFilePath instead of QDir::filePath), because relative paths are interpreted as relative to applnk rather than to the current directory. Description --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs (updated) - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: http://git.reviewboard.kde.org/r/102350/diff/diff Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implement automatic scanning of source code for required data engines
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/ --- (Updated Sept. 27, 2011, 11:38 p.m.) Review request for Plasma. Changes --- plasma-dataengine-depextractor: * Autodetect the API/language used instead of requiring a command-line argument (and silently assuming C++ when it is not provided). * Dropped the now unnecessary --api flag. (I can't find anybody using the plasma-dataengine-depextractor yet, but if you do, please just remove the -a language or --api language parameter.) Description --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs (updated) - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: http://git.reviewboard.kde.org/r/102350/diff/diff Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implement automatic scanning of source code for required data engines
Sebastian Kügler wrote: On Monday, August 22, 2011 16:08:49 Marco Martin wrote: i personally wouldn't dislike a kdelibs 4.8 as well, seems the decision is taken tough :/ David said he didn't want three different branches (stable, unstable and ultra-unstable), so kdelibs has stable and frameworks branches, and I can actually understand that. I think it makes no sense at all. People clearly want to work on kdelibs 4.8 (at least I definitely do), why are we actively preventing them from doing that? Not doing a branch makes sense if we lack manpower, but here we're actively stopping the available manpower from doing their work! To be blunt, I'll start caring about 5.0 the day it (the workspace, not just the frameworks) hits Rawhide, and I suspect most other distro people feel the same. Right now, 4.x is what we ship in our stable releases (e.g. Fedora 15) and what we will ship in at least the next 2 releases (e.g. Fedora 16 and 17), so that's what we need working and well-maintained. Maybe it makes sense to relax the freeze for once or twice in the stable branch though, so we don't all have to run patched libs on our systems. That's something we can take up on k-c-d the release-team mailinglist, though. That could be agreeable, but I don't see the advantage over just doing 4.8.x releases, and keeping requiring kdelibs = 4.n.m in kde-workspace 4.n.m as we always did. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implement automatic scanning of source code for required data engines
On Aug. 21, 2011, 1:31 p.m., Marco Martin wrote: to me seems quite good. other opinions? the only problem as usual is that kdelibs master is frozen, so this should go in the frameworks branch The problem is that, as far as Fedora is concerned, we really need this (and the previous 2 patches) in 4.x, not 5.0… I have imported the backported patches into Fedora Rawhide (which is now at 4.7.0), but I think it'd really be a pity if Fedora were the only distribution to support this in the near future. Is this really the only kdelibs feature which would have been targeted at 4.8? I think we really really need a kdelibs 4.8 release, period. It just doesn't make any sense whatsoever to let the libraries rot while the rest of KDE's software gets released. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/#review5880 --- On Aug. 21, 2011, 1:47 a.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/ --- (Updated Aug. 21, 2011, 1:47 a.m.) Review request for Plasma. Summary --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: http://git.reviewboard.kde.org/r/102350/diff Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implement automatic scanning of source code for required data engines
On Aug. 21, 2011, 1:31 p.m., Marco Martin wrote: to me seems quite good. other opinions? the only problem as usual is that kdelibs master is frozen, so this should go in the frameworks branch Kevin Kofler wrote: The problem is that, as far as Fedora is concerned, we really need this (and the previous 2 patches) in 4.x, not 5.0… I have imported the backported patches into Fedora Rawhide (which is now at 4.7.0), but I think it'd really be a pity if Fedora were the only distribution to support this in the near future. Is this really the only kdelibs feature which would have been targeted at 4.8? I think we really really need a kdelibs 4.8 release, period. It just doesn't make any sense whatsoever to let the libraries rot while the rest of KDE's software gets released. As for making this work on the frameworks branch: When will libplasma2 be merged into frameworks? (Aaron asked me to wait for that, and I think it makes a lot of sense, otherwise I'll be porting the patch again at that point.) - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/#review5880 --- On Aug. 21, 2011, 1:47 a.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/ --- (Updated Aug. 21, 2011, 1:47 a.m.) Review request for Plasma. Summary --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: http://git.reviewboard.kde.org/r/102350/diff Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Bugfix: Plasma::PackageMetadata::read: Match the behavior of KService
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102404/ --- Review request for Plasma. Summary --- This one is a bugfix, and so should be OK for 4.7. While testing my GSoC work, I noticed that Plasma::PackageMetadata::read only looks for X-KDE-ServiceTypes, whereas KService concatenates the contents of ServiceTypes and X-KDE-ServiceTypes. There are metadata.desktop files out there using ServiceTypes without the X-KDE prefix. I also fixed it to look for both Keywords and X-KDE-Keywords as KService does, not just Keywords. Diffs - plasma/packagemetadata.cpp 59163b2 Diff: http://git.reviewboard.kde.org/r/102404/diff Testing --- Compiles on Fedora 15. Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Bugfix: Plasma::PackageMetadata::read: Match the behavior of KService
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102404/ --- (Updated Aug. 22, 2011, 12:49 a.m.) Review request for Plasma. Changes --- Also delete the duplicate entries in PackageMetadata::write. Summary (updated) --- Also delete the duplicate entries in PackageMetadata::write. This one is a bugfix, and so should be OK for 4.7. While testing my GSoC work, I noticed that Plasma::PackageMetadata::read only looks for X-KDE-ServiceTypes, whereas KService concatenates the contents of ServiceTypes and X-KDE-ServiceTypes. There are metadata.desktop files out there using ServiceTypes without the X-KDE prefix. I also fixed it to look for both Keywords and X-KDE-Keywords as KService does, not just Keywords. Diffs (updated) - plasma/packagemetadata.cpp 59163b2 Diff: http://git.reviewboard.kde.org/r/102404/diff Testing --- Compiles on Fedora 15. Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implement automatic scanning of source code for required data engines
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/ --- (Updated Aug. 21, 2011, 1:47 a.m.) Review request for Plasma. Changes --- The script engine API for Ruby is called ruby-script, not ruby (for whatever reason). (I also swapped the order of the Python and Ruby checks to put them into alphabetical order, which probably also happens to be the order of popularity.) Summary --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs (updated) - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: http://git.reviewboard.kde.org/r/102350/diff Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request:
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/ --- Review request for Plasma. Summary --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: http://git.reviewboard.kde.org/r/102350/diff Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request:
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/ --- (Updated Aug. 17, 2011, 4:54 a.m.) Review request for Plasma. Changes --- Readd the summary that didn't get saved properly. Summary --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: http://git.reviewboard.kde.org/r/102350/diff Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Implement automatic scanning of source code for required data engines
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102350/ --- (Updated Aug. 17, 2011, 4:55 a.m.) Review request for Plasma. Changes --- Another try at adding the missing summary. Summary (updated) --- For packages in scripting languages and distributed through OCS, this is fully automatic and triggered from Package::installPackage. If an X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead. For native distribution packages, we ship a tool called plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information to the relevant .desktop file. Authors of plasmoids are encouraged to run plasma-dataengine-depextractor and/or fill in X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.) This is the final portion of my GSoC 2011 project. Diffs - plasma/CMakeLists.txt f929967 plasma/depextractor/depextractor.cpp PRE-CREATION plasma/package.cpp 4c00d36 plasma/private/componentinstaller.cpp 870667f plasma/private/componentinstaller_p.h f85cbb6 Diff: http://git.reviewboard.kde.org/r/102350/diff Testing --- Compiles on Fedora 15. Tested plasma-dataengine-depextractor on the weather plasmoid, it detected the dependency on the weather dataengine correctly and wrote a valid X-Plasma-RequiredDataEngines entry into the .desktop file. Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Trigger installation of missing components when installing a package
On Aug. 11, 2011, 7:56 a.m., Aaron J. Seigo wrote: if i read this correctly, this means that the name of the package on the system needs to be the name of the dataengine. e.g. org.kde.foobar or whatever. is that going to be ok for packagers? also, this work needs to shift to being written against the frameworks branch, and then only after libplasma2 has been merged into it. note that in libplasma2, there is no PackageMetadata class and the install package routine has moved into PackageStructure as well. if i read this correctly, this means that the name of the package on the system needs to be the name of the dataengine. e.g. org.kde.foobar or whatever. That depends on how the PackageKit backend code is implemented. For RPM/Yum, we use virtual Provides of the plasma4(dataengine-org.kde.foobar) or plasma4(dataengine-foobar) (depending on what the data engine actually uses as its name) form. Looking up the correct package to provide a given data engine is PackageKit's job. also, this work needs to shift to being written against the frameworks branch, and then only after libplasma2 has been merged into it. note that in libplasma2, there is no PackageMetadata class and the install package routine has moved into PackageStructure as well. I can prepare a patch against libplasma2. I'm not sure I'll be able to test it at this time though. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/#review5618 --- On Aug. 10, 2011, 10:10 p.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/ --- (Updated Aug. 10, 2011, 10:10 p.m.) Review request for Plasma. Summary --- This is another part of my GSoC 2011 work. For script engines, the existing metadata (X-Plasma-API) is sufficient. For data engines, we introduce a new metadata entry: X-Plasma-RequiredDataEngines. Third-party packages will have to add this entry to benefit from this feature at this time. Automatic support for scanning package source code on installation (at least for some languages) is planned, but the metadata entry is definitely the most efficient method. Diffs - plasma/package.cpp 4c00d36 plasma/packagemetadata.h b10f0e4 plasma/packagemetadata.cpp 59163b2 Diff: http://git.reviewboard.kde.org/r/102291/diff Testing --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine right after installing a Python widget (I used Veromix for my test) through KHNS (not only when actually using it) on Fedora 15. Also verified that there is no such prompt if plasma-scriptengine-python is already installed. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Trigger installation of missing components when installing a package
On Aug. 11, 2011, 7:56 a.m., Aaron J. Seigo wrote: if i read this correctly, this means that the name of the package on the system needs to be the name of the dataengine. e.g. org.kde.foobar or whatever. is that going to be ok for packagers? also, this work needs to shift to being written against the frameworks branch, and then only after libplasma2 has been merged into it. note that in libplasma2, there is no PackageMetadata class and the install package routine has moved into PackageStructure as well. Kevin Kofler wrote: if i read this correctly, this means that the name of the package on the system needs to be the name of the dataengine. e.g. org.kde.foobar or whatever. That depends on how the PackageKit backend code is implemented. For RPM/Yum, we use virtual Provides of the plasma4(dataengine-org.kde.foobar) or plasma4(dataengine-foobar) (depending on what the data engine actually uses as its name) form. Looking up the correct package to provide a given data engine is PackageKit's job. also, this work needs to shift to being written against the frameworks branch, and then only after libplasma2 has been merged into it. note that in libplasma2, there is no PackageMetadata class and the install package routine has moved into PackageStructure as well. I can prepare a patch against libplasma2. I'm not sure I'll be able to test it at this time though. The libplasma2 branch doesn't even have my previous patch, on which this is based, yet. Should I: a) cherry-pick it? b) attempt to merge master into libplasma2 (as has been done several times before)? or c) wait? - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/#review5618 --- On Aug. 10, 2011, 10:10 p.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/ --- (Updated Aug. 10, 2011, 10:10 p.m.) Review request for Plasma. Summary --- This is another part of my GSoC 2011 work. For script engines, the existing metadata (X-Plasma-API) is sufficient. For data engines, we introduce a new metadata entry: X-Plasma-RequiredDataEngines. Third-party packages will have to add this entry to benefit from this feature at this time. Automatic support for scanning package source code on installation (at least for some languages) is planned, but the metadata entry is definitely the most efficient method. Diffs - plasma/package.cpp 4c00d36 plasma/packagemetadata.h b10f0e4 plasma/packagemetadata.cpp 59163b2 Diff: http://git.reviewboard.kde.org/r/102291/diff Testing --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine right after installing a Python widget (I used Veromix for my test) through KHNS (not only when actually using it) on Fedora 15. Also verified that there is no such prompt if plasma-scriptengine-python is already installed. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Trigger installation of missing components when installing a package
On Aug. 11, 2011, 7:56 a.m., Aaron J. Seigo wrote: if i read this correctly, this means that the name of the package on the system needs to be the name of the dataengine. e.g. org.kde.foobar or whatever. is that going to be ok for packagers? also, this work needs to shift to being written against the frameworks branch, and then only after libplasma2 has been merged into it. note that in libplasma2, there is no PackageMetadata class and the install package routine has moved into PackageStructure as well. Kevin Kofler wrote: if i read this correctly, this means that the name of the package on the system needs to be the name of the dataengine. e.g. org.kde.foobar or whatever. That depends on how the PackageKit backend code is implemented. For RPM/Yum, we use virtual Provides of the plasma4(dataengine-org.kde.foobar) or plasma4(dataengine-foobar) (depending on what the data engine actually uses as its name) form. Looking up the correct package to provide a given data engine is PackageKit's job. also, this work needs to shift to being written against the frameworks branch, and then only after libplasma2 has been merged into it. note that in libplasma2, there is no PackageMetadata class and the install package routine has moved into PackageStructure as well. I can prepare a patch against libplasma2. I'm not sure I'll be able to test it at this time though. Kevin Kofler wrote: The libplasma2 branch doesn't even have my previous patch, on which this is based, yet. Should I: a) cherry-pick it? b) attempt to merge master into libplasma2 (as has been done several times before)? or c) wait? FWIW, I think we really need to do a kdelibs 4.8 release, if only for this work alone. This is an important improvement and shouldn't have to wait for 5.0. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/#review5618 --- On Aug. 10, 2011, 10:10 p.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/ --- (Updated Aug. 10, 2011, 10:10 p.m.) Review request for Plasma. Summary --- This is another part of my GSoC 2011 work. For script engines, the existing metadata (X-Plasma-API) is sufficient. For data engines, we introduce a new metadata entry: X-Plasma-RequiredDataEngines. Third-party packages will have to add this entry to benefit from this feature at this time. Automatic support for scanning package source code on installation (at least for some languages) is planned, but the metadata entry is definitely the most efficient method. Diffs - plasma/package.cpp 4c00d36 plasma/packagemetadata.h b10f0e4 plasma/packagemetadata.cpp 59163b2 Diff: http://git.reviewboard.kde.org/r/102291/diff Testing --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine right after installing a Python widget (I used Veromix for my test) through KHNS (not only when actually using it) on Fedora 15. Also verified that there is no such prompt if plasma-scriptengine-python is already installed. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Trigger installation of missing components when installing a package
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/ --- Review request for Plasma. Summary --- This is another part of my GSoC 2011 work. For script engines, the existing metadata (X-Plasma-API) is sufficient. For data engines, we introduce a new metadata entry: X-Plasma-RequiredDataEngines. Third-party packages will have to add this entry to benefit from this feature at this time. Automatic support for scanning package source code on installation (at least for some languages) is planned, but the metadata entry is definitely the most efficient method. Diffs - plasma/package.cpp 4c00d36 plasma/packagemetadata.h b10f0e4 plasma/packagemetadata.cpp 59163b2 Diff: http://git.reviewboard.kde.org/r/102291/diff Testing --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine right after installing a Python widget (I used Veromix for my test) through KHNS (not only when actually using it) on Fedora 15. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Trigger installation of missing components when installing a package
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102291/ --- (Updated Aug. 10, 2011, 10:10 p.m.) Review request for Plasma. Changes --- Also verified that there is no such prompt if plasma-scriptengine-python is already installed. (I had forgotten to test this, but I've just tested it, and thankfully it works.) Summary --- This is another part of my GSoC 2011 work. For script engines, the existing metadata (X-Plasma-API) is sufficient. For data engines, we introduce a new metadata entry: X-Plasma-RequiredDataEngines. Third-party packages will have to add this entry to benefit from this feature at this time. Automatic support for scanning package source code on installation (at least for some languages) is planned, but the metadata entry is definitely the most efficient method. Diffs - plasma/package.cpp 4c00d36 plasma/packagemetadata.h b10f0e4 plasma/packagemetadata.cpp 59163b2 Diff: http://git.reviewboard.kde.org/r/102291/diff Testing (updated) --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine right after installing a Python widget (I used Veromix for my test) through KHNS (not only when actually using it) on Fedora 15. Also verified that there is no such prompt if plasma-scriptengine-python is already installed. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add an API for installing missing Plasma engines. Use it when a requested data or script engine is not found.
On Aug. 3, 2011, 8:13 a.m., Aaron J. Seigo wrote: plasma/dataenginemanager.cpp, line 134 http://git.reviewboard.kde.org/r/102175/diff/2/?file=30633#file30633line134 this failure case is going to be trickier to address than the scriptengine failure case below. one possibility would be to have a delayed load DataEngine that is returned which waits on the return from the ComponentInstaller. it could cache all requests made until the ComponentInstaller returns. on success, it would then load the actual DataEngine and forward all calls made thus far to it (object connection requests, etc; basically replaying its internal state). on failure, it would flush all of these cached requests and behave just like the NullEngine. A way to make things actually work without restarting everything would definitely help indeed. But it's not going to be easy to get working indeed. I'll see if I can improve this in a followup patch. - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102175/#review5334 --- On Aug. 2, 2011, 3:49 p.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102175/ --- (Updated Aug. 2, 2011, 3:49 p.m.) Review request for Plasma. Summary --- This is part of my GSoC 2011 work. Expect more Plasma patches related to this in the next few days. In particular, the currently unused force feature of the new API is intended to be used if the user just installed a widget which explicitly requires a given engine. (By default, prompts are not repeated within a session to prevent flooding the user.) The implementation is based on PackageKit. It requires PackageKit = 0.6.16 and either Apper trunk or the backported patch from http://pkgs.fedoraproject.org/gitweb/?p=kpackagekit.git;a=blob;f=kpackagekit06-plasma.patch;h=208427aa6cc072164b6a9ba48a30a954657ef892;hb=HEAD to have any effect. If the requirements are not met, no change will be noticeable at all, because the asynchronous call will simply fail and any errors are (intentionally) discarded. (We don't want to annoy the user with a pointless error dialog if he/she doesn't have PackageKit installed or his/her version is too old.) PackageKit will also only actually find the relevant packages if the distribution is using RPM and yum (at this time) and if the RPMs in the repository have been built with my Provides generator. But that shouldn't be Plasma's problem. Any work in that area needs to happen on the PackageKit or distro side. Support for GStreamer plugins has been implemented in other PackageKit backends too, so it should also be doable for Plasma engines. And if a distro wants to use something entirely different from PackageKit, that's also possible, this is what the abstract EngineInstaller API is for. The API is public because it might be useful outside of libplasma, and it is quite simple and generic, thus keeping BC should not be a problem. Diffs - plasma/CMakeLists.txt ef411df plasma/dataenginemanager.cpp 988fe76 plasma/private/componentinstaller.cpp PRE-CREATION plasma/private/componentinstaller_p.h PRE-CREATION plasma/scripting/scriptengine.cpp fb8cd1a Diff: http://git.reviewboard.kde.org/r/102175/diff Testing --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine on Fedora 15. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add an API for installing missing Plasma engines. Use it when a requested data or script engine is not found.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102175/ --- (Updated Aug. 2, 2011, 3:49 p.m.) Review request for Plasma. Changes --- * renamed EngineInstaller to ComponentInstaller and installMissingEngine to installMissingComponent * made ComponentInstaller private (at least for now) * fixed the endif command in CMakeLists.txt * insert requested components into alreadyPrompted independently of whether force was used Summary --- This is part of my GSoC 2011 work. Expect more Plasma patches related to this in the next few days. In particular, the currently unused force feature of the new API is intended to be used if the user just installed a widget which explicitly requires a given engine. (By default, prompts are not repeated within a session to prevent flooding the user.) The implementation is based on PackageKit. It requires PackageKit = 0.6.16 and either Apper trunk or the backported patch from http://pkgs.fedoraproject.org/gitweb/?p=kpackagekit.git;a=blob;f=kpackagekit06-plasma.patch;h=208427aa6cc072164b6a9ba48a30a954657ef892;hb=HEAD to have any effect. If the requirements are not met, no change will be noticeable at all, because the asynchronous call will simply fail and any errors are (intentionally) discarded. (We don't want to annoy the user with a pointless error dialog if he/she doesn't have PackageKit installed or his/her version is too old.) PackageKit will also only actually find the relevant packages if the distribution is using RPM and yum (at this time) and if the RPMs in the repository have been built with my Provides generator. But that shouldn't be Plasma's problem. Any work in that area needs to happen on the PackageKit or distro side. Support for GStreamer plugins has been implemented in other PackageKit backends too, so it should also be doable for Plasma engines. And if a distro wants to use something entirely different from PackageKit, that's also possible, this is what the abstract EngineInstaller API is for. The API is public because it might be useful outside of libplasma, and it is quite simple and generic, thus keeping BC should not be a problem. Diffs (updated) - plasma/CMakeLists.txt ef411df plasma/dataenginemanager.cpp 988fe76 plasma/private/componentinstaller.cpp PRE-CREATION plasma/private/componentinstaller_p.h PRE-CREATION plasma/scripting/scriptengine.cpp fb8cd1a Diff: http://git.reviewboard.kde.org/r/102175/diff Testing --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine on Fedora 15. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Review Request: Add an API for installing missing Plasma engines. Use it when a requested data or script engine is not found.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102175/ --- Review request for Plasma. Summary --- This is part of my GSoC 2011 work. Expect more Plasma patches related to this in the next few days. In particular, the currently unused force feature of the new API is intended to be used if the user just installed a widget which explicitly requires a given engine. (By default, prompts are not repeated within a session to prevent flooding the user.) The implementation is based on PackageKit. It requires PackageKit = 0.6.16 and either Apper trunk or the backported patch from http://pkgs.fedoraproject.org/gitweb/?p=kpackagekit.git;a=blob;f=kpackagekit06-plasma.patch;h=208427aa6cc072164b6a9ba48a30a954657ef892;hb=HEAD to have any effect. If the requirements are not met, no change will be noticeable at all, because the asynchronous call will simply fail and any errors are (intentionally) discarded. (We don't want to annoy the user with a pointless error dialog if he/she doesn't have PackageKit installed or his/her version is too old.) PackageKit will also only actually find the relevant packages if the distribution is using RPM and yum (at this time) and if the RPMs in the repository have been built with my Provides generator. But that shouldn't be Plasma's problem. Any work in that area needs to happen on the PackageKit or distro side. Support for GStreamer plugins has been implemented in other PackageKit backends too, so it should also be doable for Plasma engines. And if a distro wants to use something entirely different from PackageKit, that's also possible, this is what the abstract EngineInstaller API is for. The API is public because it might be useful outside of libplasma, and it is quite simple and generic, thus keeping BC should not be a problem. Diffs - includes/CMakeLists.txt a967a92 includes/Plasma/EngineInstaller PRE-CREATION plasma/CMakeLists.txt ef411df plasma/dataenginemanager.cpp 988fe76 plasma/engineinstaller.h PRE-CREATION plasma/engineinstaller.cpp PRE-CREATION plasma/scripting/scriptengine.cpp fb8cd1a Diff: http://git.reviewboard.kde.org/r/102175/diff Testing --- Verified that it compiles without errors and that it successfully prompts for a missing Python script engine on Fedora 15. (The patch is against master (4.8), but applies without changes to the kdelibs 4.6.5 in Fedora 15, which is how I tested it.) Thanks, Kevin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Add an API for installing missing Plasma engines. Use it when a requested data or script engine is not found.
On Aug. 2, 2011, 4:22 a.m., Aaron J. Seigo wrote: i don't like the idea of this being public API, at least not until we know we need it to be. i also recommend changing the name of the class from EngineInstaller to ComponentInstaller, since it seems more generic than just Engines (which itself is ambiguous due to ScriptEngines and DataEngines). Thanks for the review. i don't like the idea of this being public API, at least not until we know we need it to be. Well, I can make this a private class for now, but I might need it at least in kde-workspace eventually. I also think this would be a useful public API to have, but I don't feel strongly about that. i also recommend changing the name of the class from EngineInstaller to ComponentInstaller OK, I'll rename it (I don't care all that much about the name), but… since it seems more generic than just Engines (which itself is ambiguous due to ScriptEngines and DataEngines). … that's kinda the point, the EngineInstaller can install both data engines and script engines. :-) At this time, I'm not sure what other stuff it'd be useful for, but ComponentInstaller is probably more future-proof. I will update the patch based on your suggestions. On Aug. 2, 2011, 4:22 a.m., Aaron J. Seigo wrote: plasma/CMakeLists.txt, line 53 http://git.reviewboard.kde.org/r/102175/diff/1/?file=30596#file30596line53 mismatch with if Whoops, I renamed the variable and forgot the endif (and CMake really just ignores it, so it didn't complain). I'll fix that. On Aug. 2, 2011, 4:22 a.m., Aaron J. Seigo wrote: plasma/engineinstaller.cpp, line 78 http://git.reviewboard.kde.org/r/102175/diff/1/?file=30599#file30599line78 so if !force, it shouldn't be added to alreadyPrompted? it may also be worthwhile to remove items from alreadyPrompted once there is success (thus freeing up that memory), assuming packagekit returns this information. so if !force, it shouldn't be added to alreadyPrompted? The idea is that force will be false for requests triggered by use (on demand), and true for requests triggered by installation (metadata explicitly requesting a component, this is not part of this patch, but will be in a later patch). So they can be kept quite separate in principle. However, I'll add the force requests to alreadyPrompted too for consistency. it may also be worthwhile to remove items from alreadyPrompted once there is success (thus freeing up that memory), assuming packagekit returns this information. This should be possible in principle, but is the added code to handle the asynchronous replies really worth the few bytes of QSetQString entries it'll save? (I don't expect that small set of short strings to become a memory hog at all.) - Kevin --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102175/#review5307 --- On Aug. 2, 2011, 2:57 a.m., Kevin Kofler wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102175/ --- (Updated Aug. 2, 2011, 2:57 a.m.) Review request for Plasma. Summary --- This is part of my GSoC 2011 work. Expect more Plasma patches related to this in the next few days. In particular, the currently unused force feature of the new API is intended to be used if the user just installed a widget which explicitly requires a given engine. (By default, prompts are not repeated within a session to prevent flooding the user.) The implementation is based on PackageKit. It requires PackageKit = 0.6.16 and either Apper trunk or the backported patch from http://pkgs.fedoraproject.org/gitweb/?p=kpackagekit.git;a=blob;f=kpackagekit06-plasma.patch;h=208427aa6cc072164b6a9ba48a30a954657ef892;hb=HEAD to have any effect. If the requirements are not met, no change will be noticeable at all, because the asynchronous call will simply fail and any errors are (intentionally) discarded. (We don't want to annoy the user with a pointless error dialog if he/she doesn't have PackageKit installed or his/her version is too old.) PackageKit will also only actually find the relevant packages if the distribution is using RPM and yum (at this time) and if the RPMs in the repository have been built with my Provides generator. But that shouldn't be Plasma's problem. Any work in that area needs to happen on the PackageKit or distro side. Support for GStreamer plugins has been implemented in other PackageKit backends too, so it should also be doable for Plasma engines. And if a distro wants to use something entirely different from PackageKit, that's also possible, this is what the abstract EngineInstaller API
Re: Self-introduction: GSoC student (Fedora Project) working on Plasma PackageKit integration
Thomas Olsen wrote: This sounds great. Last year I wanted to make something like this myself [1] only just for scripted DataEngines via OCS, but due to personal circumstancies I was unable to procede with the project. To support fetching dependencies from OCS, we will need not only a way to handle dependencies (which I'm working on), but also some way to know what OCS entry provides the data engine foo. For distribution packages, PackageKit can do the lookup for us (with minor changes which I can base on already existing code), but for OCS packages, we probably also need some work done on the OCS side. We'd also have to try both OCS and PackageKit if we don't know where a dependency can be found. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Self-introduction: GSoC student (Fedora Project) working on Plasma PackageKit integration
Hi, let me briefly introduce myself: I am Kevin Kofler, I'll be 28 years old on July 1st, I'm studying for a PhD in Mathematics at the University of Vienna, Austria, and I'm an Italian citizen. I am a Fedora KDE packager and a KDE developer. This summer, I am working on a Google Summer of Code 2011 project with the Fedora Project, mentored by Rex Dieter. The main goal of my project is to enable Plasma to install required script engines and data engines for Plasma widgets downloaded through Open Collaboration Services (OCS) through PackageKit. (The script engines and data engines cannot be offered through OCS because they have to be compiled for the distribution.) Rex Dieter has been suggesting to use PackageKit for this purpose for a while: http://rdieter.livejournal.com/14707.html http://rdieter.livejournal.com/14897.html and his idea has been received positively by Plasma developers, so I am hoping for a successful cooperation with the Plasma project. (A positive side effect will be that Plasma-related dependencies between distribution packages can also be automatically generated.) On the PackageKit side, not much is needed, however we will need a new method in the org.freedesktop.PackageKit.Modify interface, similar to the existing InstallFontconfigResources, InstallGStreamerResources or InstallPrinterDrivers APIs. This is my next task in my project plan and will be required to implement the Plasma-side code, which is why I'm cross-posting this mail to the PackageKit list. Of course, some support for this feature is also needed on the package manager level. I am implementing automatic extraction of Provides and Requires for RPM. While I do not plan to work on other package managers myself at this time, I expect it to be relatively easy to add support for other packaging systems once the Plasma and PackageKit code is in place. I will be available for questions and guidance to anyone working on supporting this feature for other package managers. The plan for how I intend to implement the features can be found at: http://www.google-melange.com/gsoc/project/google/gsoc2011/kevinkofler/7001 I hope this makes sense to you (it definitely does make sense to Rex and me, but we aren't Plasma or PackageKit developers), otherwise please provide constructive feedback. Expect patches to be trickling in soon. So far, we have support for extracting RPM Provides information from Plasma .desktop file metadata: https://kevinkofler.wordpress.com/2011/06/05/automatic-plasma-rpm-provides/ The naming scheme plasma4(servicetype-name) was modeled after the GStreamer Provides, which are used in a similar way as these Plasma Provides will be used (automatic installation through PackageKit) and which use a gstreamer0.10(servicetype-mimetype) naming scheme. Here too, I hope this naming scheme makes sense to you, otherwise please speak up now, before we start generating these Provides in Fedora Rawhide packages. Similarly to how this works for GStreamer, I intend to use the same naming scheme in the org.freedesktop.PackageKit.Modify API, but as for GStreamer, backends can map this to whatever the underlying packaging system requires. I am looking forward to a productive summer working with the Plasma and PackageKit projects. Kevin Kofler ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
