----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102175/#review5334 -----------------------------------------------------------
Ship it! looks like a good start to this feature. what would be Really Nice(tm) is to have a screencast of it in action so we can blog about it :) ultimately, it would also be very nice to have other sources in addition to the native package manager (fetching from an online store, e.g.?) but this is the necessary first steps indeed. plasma/dataenginemanager.cpp <http://git.reviewboard.kde.org/r/102175/#comment4823> 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. plasma/scripting/scriptengine.cpp <http://git.reviewboard.kde.org/r/102175/#comment4822> what we're going to need to do is find a way to delay initialization in this case. in a best case scenario, the component requiring the scriptengine would be created and wait on results from the installation process. and when the installation process is done, re-request the scriptengine. - Aaron J. 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
