On Mon, Dec 12, 2011 at 09:00:29PM +0100, Giovanni Campagna wrote: > (cumulative answer since I didn't have much time in the last few days) > > Il giorno lun, 12/12/2011 alle 18.21 +0100, Michael Vogt ha scritto: > > On Fri, Dec 02, 2011 at 08:52:43PM +0100, Giovanni Campagna wrote: > > > Hello everyone, > > Hi again, > > > > [...] > > > > The icon-names in historypane.py will need a bit of thought too to > > make it compatible on both PK and aptdaemon systems. > > I guess we should bring the issue at freedesktop, agree on a common set > of icon names, and then ping our respective icon theme authors.
Sounds good to me, in the meantime I will just make sure both are supported (based on if PK is availalbe or not). > > [..] > > > I would like to join this team because I'm interested in bringing the > > > software center to Fedora, as it was done for Debian and OpenSuse. > > > For this reason, I started patching upstream code, extending and > > > completing the PackageKit backend, and I have something that I consider > > > mostly working in a personal branch here at launchpad. > > > My interest would be in sharing this work, and thus I'd like to merge > > > most changes (including some that are not limited to the backends) to > > > the trunk line of development. > > [..] > > > > I picked up the work on this again this morning. Its progressing > > nicely, I noticed that installbackend_impl/packagekit_enums.py adds a > > bunch of translation strings that are also available in packagekit. So > > I send a patch to Richard (PK upstream) to make > > pk_status_enum_to_localised_text() (and friends) available via the > > library and he accepted adding it. It will be available in PK 0.7.2. I > > will update the branch accordingly. > > > > I put my progress into lp:~mvo/software-center/fedora. > > I saw your changes. It's cool we have pk_status_enum_to_localised_text() > (although, ghgh, localised...) in the library. I'm not quite sure I understand the "ghgh" :) ? is "localised" too long as a word? Or something else that I missed? > As for the changes you made to the distro class, I need to warn you that > at fedora-devel we are discussing a completely different backend for > screenshots, rating&reviews, and possibly even icons (for legal > reasons), based on the existing fedora package database. I still need to > start the client-side of this, though. Thats absolutely fine of course. Please note that both our screenshot server and the reviews backend are free software. So you may want to consider just hosting a instance of those. I'm keen to learn more about the work that fedora is planning here. Of course its fine to write a new one, we need to put a bit more abstraction into place in the client, but I don't think it will be a huge amount of work. > Finally, I'm not sure about runtime detection of PackageKit. While it > makes sense on rpm distros (where software-center package would Require > PackageKitGlib-1.0.gir, and never run without it), on apt distros it > would mean that even installing packagekit by chance changes the > behaviour of the software-center substantially. The code is generally > biased on the apt side, with PK hacking around apt concepts (for > example, the xapian databases generated by PK and apt-cache are not > compatible, because of the slightly different interpretation of > XOorigin), so in no case one should have the PK backend enabled in an > apt distro. Maybe we can make this configurable at buildtime? > (I don't know distutils enough, but it is possible with other build > systems...) Good catch! I agree that its currently not ideal. I will fix that. When it comes to differences (e.g. origin) I wonder if we can not fix this in a compatible way. I did a bit more tweaking on the branch now, could you please check it out and tell me your thoughts? If it looks good I will merge into trunk and we can push a new release out. >From memory there is one performance issue currently about PkgInfo "is_installed". This is called often from the listview code but iirc/afaik this generated a PK query every time. I wonder if instead we could make the code query PK for all installed pkgs at startup and cache the value (and keep it updated of course if PK sends change events). WDYT? Thanks! Michael _______________________________________________ Mailing list: https://launchpad.net/~software-store-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~software-store-developers More help : https://help.launchpad.net/ListHelp
