From kde-panel-devel Mon Nov 26 20:54:18 2007 From: "Aaron J. Seigo" Date: Mon, 26 Nov 2007 20:54:18 +0000 To: kde-panel-devel Subject: Re: [Panel-devel] [PATCH] Package and PackageStructure cleanup Message-Id: <200711261354.21929.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=119611090926990 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0437992467==" --===============0437992467== Content-Type: multipart/signed; boundary="nextPart5621251.kN4C1egQWG"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart5621251.kN4C1egQWG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 26 November 2007, Paolo Capriotti wrote: > 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 discovering the package exists and where the package actually are actually = two=20 separate steps with this approach. > 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? that's why the application using Package provides the root path. the reason= i=20 didn't just default this to the appdata dir is that this will break with=20 plugins that have their own KComponentData object. we could take a=20 KComponentData instead of a root path, but then that would make it harder t= o=20 access other app's/plugin's packages (since you'd need a KComponentData tha= t=20 represents that app/plugin). i suppose another way of going about it is installing *all* packages into t= he=20 plasmagik appdata directory and instead of taking a root path, taking a nam= e=20 (e.g. "plasma") which then gets passed like=20 KStandardDirs::locate("appdata", "plasmagic/" + name); > 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. yes, this should be fixed in package.cpp. putting things in a contents/ fol= der=20 is the right thing to do (prevents packages from getting messed up just=20 because they have a file named "metadata.desktop" or whatever =3D), so=20 Package::filePath ::entryList, etc need to be fixed. PackageStructure=20 shouldn't be touched though. > 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. perhaps these should be added to every PackageStructure object, e.g. have a= =20 set of addFile calls in the PackageStructure ctor. then they can be removed= =20 from the package metadata as well, with the exception of the Icon field whi= ch=20 is required (and can be filled in using the PackageStructure) > 3) Icon, screenshot and preview have fixed hardcoded paths (as in > createPackage), but PackageMetadata has fields to store them. yes, createPackage should be reading the values out of PackageMetadata or=20 PackageStructure (probably better) instead of hard coding them. sane defaul= ts =20 should be provided and createPackage should follow whatever those are. the big problem is that right now PackageMetadata is used to store the path= to=20 the icon on creation. this really is something that belongs in=20 PackageStructure. note that package metadata also has both screenshot() and preview().. it on= ly=20 needs one of those =3D) > 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. i wonder if the icon and preview shouldn't also go into contents/ to make i= t=20 easier from a package creator's POV: you simply put all your files into tha= t=20 one directory; the design studio would then have an "Icon" entry listed alo= ng=20 with things like (for plasmoids) "Main Script". should simplify things pret= ty=20 nicely. > > 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. great... =2D-=20 Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech --nextPart5621251.kN4C1egQWG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHSzJ91rcusafx20MRAmDOAKCNgGFBs+T354gUJLfHIWZGm/bklQCfdM1N opYzLMC5E9/wASOcyObdkIk= =uRsM -----END PGP SIGNATURE----- --nextPart5621251.kN4C1egQWG-- --===============0437992467== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Panel-devel mailing list Panel-devel@kde.org https://mail.kde.org/mailman/listinfo/panel-devel --===============0437992467==--