- Drop cruft
- Smooth out API issues that have cropped up
- Separate QGraphicsView code out into a separate library, clearing the way for QML-only Plasma interfaces to not have to carry that weight
- Make parts of libplasma more QML-friendly than they are currently
The motivation for these changes is based on the history of the library, which grew over the last couple of years in response to changes in Qt (the biggest being the arrival of QGraphicsProxyWidget which was first used in the KDE Platform 4.2 release) and the needs of the increasingly sophisticated applications using libplasma.
One example: As activities shaped up and have become integrated with Nepomuk, KWin and other apps, the classes in libplasma meant to help track activities in relation to Containments simply stopped making sense.
Another example: the rise of QML has made QGraphicsView things optional rather than required. We don't want to do any massive porting or rewriting, so we'll be creating a new library with all those pieces in it. Components that use QGraphicsView things will need to link to that library, but otherwise little changes.
This will be our first big break in libplasma since the KDE Platform 4.2 release, but we're trying to keep it relatively tame. So far all deprecated methods have been removed, needlessly reimplemented methods (usually because the need for the reimplementation was lost over time) are all gone, unused classes have been removed, slots that were being used as a "poor man's" virtual method have been switched to actually being virtuals and some API blemishes have been cleared. The ability to verify signed packages using GPG has also been added.
Next up is a merge of Package, PackageStructure and PackageMetadata into one class, with most of PackageMetadata actually being discarded. Then the QGraphicsView separation will get underway.
Further on, there's hope that some refactoring of DataEngine will also happen to make them easier to use from QML as well as to make them safer to use from C++ (e.g. no pointers). More of the enumerations used in libplasma will probably move into a QObject, so that while little or nothing will change from C++ we can more easily import them into QML and Javascript.
Changes to the public API are being documented here as they happen. There are still several months of work to be done on this, and we're trying to keep the impact low with the mantra of "source compatible if at all possible" constantly on our lips. We don't wish to break plugins or have to touch code that is finally becoming mature in plasma-desktop, plasma-netbook, etc.
The development is happening in the libplasma2 branch in the kdelibs git repository with discussion happening on plasma-devel at kde.org and in #plasma-devel on irc as usual.
9 comments:
Nice to hear. Speaking of larger changes, might it be possible to splitting up the plasma config files? Putting each widget in its own file, probably with separate folders for each activity, would help in a bunch of ways.
For one, it would make it MUCH easier to remove a widget that is causing problems with plasma. It would also make it easier to copy widgets between activities or even computers just by moving a file.
There may be other issues that render this undesirable or outright impossible, though.
"Putting each widget in its own file,"
not only would this be slower and much more error prone, it would actually be far more difficult to manage for the user, not easier. this is how it was done with kicker and it was a PITA.
Actually I find much more painful to effectively manage my desktop.
It happens sometime, When I try to reorganize my desktop (adding or moving applets around, especially from a panel to the desktop or from an activity to another one), that plasma suddenly crashes because of some corrupted value being written in one of those plasma-desktop-appletsrc, plasma-desktoprc etc.
Finding the applet causing the crashes is sometime troublesome, and often the only solution is to wipe out those files, loosing all the the settings.
Maybe you're right, having too much files around would make it more difficult to manage, but please at least provide a simple graphical manager, minimalistic as you wish (like qdbus-viewer for example), but that can allow the user to visualize and possibly correct the structure of the file.
@Piero: so it would be easier to have to map between multiple files scattered around one or more directories (multiple, if we followed kicker's lead faithfully)? doubtful; that just becomes a maze in the filesystem instead of one in a single config file.
replicating a given layout, saving activities, etc. all becomes much harder with multiple files to manage.
"that plasma suddenly crashes because of some corrupted value being written in one of those plasma-desktop-appletsrc, plasma-desktoprc etc."
it will always in be -appletsrc, and that's a bit easier than "some corrupted value being written in one of those 20 files..."
"Finding the applet causing the crashes is sometime troublesome, and often the only solution is to wipe out those files, loosing all the the settings."
well, no, it isn't. it's the easy solution, a solution easily afforded by having one file. with dozens of files you have to hunt for the right one. or hunt for the right key in the main file (if there is one), which is identical hunting for "plugin=foo" in -appletsrc.
"please at least provide a simple graphical manager,"
it's a very simple format that is easy to read in using standard KConfig. i have no intention of spending my time writing a tool such as you describe, but i can imagine some (such as yourself) would appreciate it. so hopefully one of you will write it, just as the people working on plasma have written code for others to use.
I'm sorry if my post has sounded harsh, english is not my native language and a thanks at the bottom would have made it less rude.
I understand your point and agree with you that it would be more difficult, at least by a programming point of view (I don't understand the logic behind those configuration files so I cannot really tell what would be better), to manage a tree of tiny little config files scattered around the system and perhaps it may even not be a good idea to tight the config-file structure to a hierarchical-model futurewise, even if we, as linux users, are already used to this kind of situation (/etc).
But there are cases where the user really knows what he has done to make plasma crash and he (or another user remotely helping him) would like to correct the configuration file by himself, but the file is difficult to edit by hand, because it is difficult to grasp what section refers to what and the user has the sensation that's better not to touch anything (or simply delete it).
I understand that the file follows KConfig format,but it's not as easily human-readable as you may think, especially without any comment around.
(In my plasma-desktop-appletrc (cleaned up of personal stuff) for example I have multiple section with the same value for plugin key, why is it so? Is it a bug? Can you point me to the code in libplasma where the magic happens? Or a discussion thread about the format?
bigger question is, WHY do the files get corrupt ?! Hard system crashes have become rare these days in linux, and on laptops ( which I happen to use as main desktop), power failure is also not the case.
So it seems to me that this is die to lack of backward compatiblitiy between KDE 4.x versions. There should be some way to properly migrate users' configuration files when they upgrade KDE versions.
I agree that configuration editors are unnecessary ( they are already present in the form of "setting" or "preferences" menu items in each application) - why duplicate this ?
@Piero: "I have multiple section with the same value for plugin key, why is it so?"
there will be one section per instance of the plugin. so if you have, say, two launchers, there will be one entry for each with the same plugin= value.
@ncblogger118: "bigger question is, WHY do the files get corrupt"
they don't, not in the sense you are using the word. no, it isn't actual file corruption, but usually due to a person downloading a random 3rd party plugin and then ending up with it being buggy, even crashy.
sometimes there are bugs in the code we ship as well which has sometimes cause problems for people in specific use cases.
the config file remains accurate, but may not result in what someone (such as Piero here) may want, and so sometimes they go into the config files directly to change things.
I don't know, would it be possible to make Plasma detect which plasmoid has made it crash and offer to remove it before reloading itself?
I don't know if it's technically reasonable but I think it could solve those kind of problems.
meanwhile I took the advice and after a bit of study I came up with this:
https://github.com/pierigno/plasmaconfig2
It's just a dirty exercise to get a visual clue of the structure of those rc files in .kde4/share/config and at the same time learning a bit of Qt.
never though it could be that easy. Kde rock!
Post a Comment