[Panel-devel] [PATCH] Package and PackageStructure cleanup

Paolo Capriotti p.capriotti at gmail.com
Mon Nov 26 20:22:52 CET 2007


Aaron J. Seigo wrote:
> On Sunday 25 November 2007, Paolo Capriotti wrote:
> 
> my original idea was to exract the .desktop file on installation and put it in 
> the services directory (after giving the file a proper name, of course, to 
> prevent collisions with other files) so that ksycoca would pick it up. 
> eliminates the whole problem, really.

Yes, that's the best option (it allows you to perform complex queries),
but there is a subtle problem: once you get a service (or a service
list), how do you discover the path to the associated package? If you
search it with KStandardDirs, you're back where you started... well, not
really, but you have a list of names, when you actually want a list of
paths. And I don't think that hardcoding the path in the .desktop file
is sensible, is it?

>> which at the moment requires you to know a base path.
> 
> well, yes, that's obviously a prerequisite to loading the packages unless we 
> put all the packages for all apps and of all types into some well known 
> hierarchy on disk. that said, the base path argument should probably be more 
> KStandardDirs friendly; e.g. if it is given as a relative path it should be 
> assumed to be in appdata.

Ok, added to my TODO ;)
But maybe we first need to clarify the issues I raised above.

>>> * to install packages from archives
>> Would it be useful to have a variation of this, where you pass a zipped
>> package to the Package constructor, and it transparently handles it as
>> if it were installed (probably unzipping it in a temporary location)?
> 
> or using the zip filter support in kio to just read directly out of the 
> file ... and yes, that would be very cool. =)

Ok, then, another TODO item.

Btw, yesterday ruphy and I had a chance to discuss about the packaging
thing, and (surprisingly enough :) something productive came out of the
discussion.
Main points:
1) The layout of files in a package is not consistently defined in the
code: for example Package::createPackage puts all files in a 'contents'
directory, which is not taken into account by all the functions
returning a path.
2) There's no API to access the icon, screenshot, preview and metadata
of a package. You can access them, of course, but you have to do it
manually with path manipulations.
3) Icon, screenshot and preview have fixed hardcoded paths (as in
createPackage), but PackageMetadata has fields to store them.

So, I think we have to decide a file layout and use it consistently (and
document it somewhere), then add the missing API and tests.
Our proposal is to stick with what createPackage currently assumes
(metadata, icon, preview and screenshot on the root directory, all the
other files in a directory named 'contents') and adapt the rest.
If there are no objections, I'm going to do the necessary changes this week.

 > the patch looks good, btw. pls apply

Done. I've also merged your patch (const char* -> QByteArray) and added 
a test that was previously failing with const char* keys.

Paolo Capriotti



More information about the Panel-devel mailing list