Themes Web Application Integrated with Awn Manager

While this is a nice-to-have feature, it's a monumental task (we'd have to find someone to write it, host it, and maintain it), so unless someone is willing to do any of these things, it's unlikely to happen any time soon. People who wish to work on this need to take into consideration both interface design and potential security problems. - malept (20080811)

(TD)Well, is Art Manager secure? How difficult would it be to simply port it over? They both connect (securely?) to GnomeLook, and download, then install/unzip a file. If it would be too difficult to build this into the AWN pref menu, what if it was simply added to Art Manager, where the foundation is already in place?

gnome-art is written in Ruby, gnomeartng is written in C# (mono). Awn Manager is written in Python. I think it would be non-trivial to port over. (I don't think we could add functionality to either art manager implementation, as there are no Awn bindings for either language currently.) Additionally, I don't think there's a viable API (if any) to use with the gnome-look website, so the developer willing to work on this would have to screen-scrape and/or parse HTML, and be prepared to fix it if the structure of the website changed. -malept (20080811)

Having a web-based backend to themes and applets would be very cool. For example, Gnome-do has this functionality. I don't mind paying for hosting etc, but I have no idea how the web side of this would work (together with updates etc) -- njpatel (20080813)

For the screenlets project, this idea was proposed. The basic plan was to set up a bzr repo and connect the manager to fetch the themes and screenlets in this tree. The only thing needed was the ability for bzr to refresh only 1 sub-directory instead of the all tree. Maybe a possible implementation. -- gilir (20080813)

I do not know how to help other than $$. I will offer 100$ towards hosting if the project is accomplished. -TrevorDuke

I like this idea - I'd have a separate directory for metadata which would be sensibly polled by the client. So, infrastructure-wise, we'd be blocking on the bazaar developers developing a stable format with subtree support (it's currently in an experimental state). --malept (20080813)

(re-added reporter's comment, sorry. -malept)

What about if we had a project, say awn-applets, which was structured like:
lp:~awn-applets/awn-applets/trunk (which houses metadata)
lp:~awn-applets/awn-applets/*-applet (which houses current stable of applet)

there are multiple branches (one for each applet) and one main branch containing the metadata. The clients job would be to clone the metadata branch (and keep it in sync), and when the user chooses an applet to install, the applet's branch is cloned (and kept up-to-date).

We could probably use the xml feeds to give the user up-do-date information too (like, "what's new").
--njpatel (20080815)

This would only work with Python applets. C/Vala applets need to be compiled - not exactly ideal for those pesky binary distribution users :) I'm not too keen on abusing bzr to version binaries, anyway. Also, it's getting slightly off-topic, given that this blueprint is regarding themes. -- malept (20080815)

Support available in the rewrite branch. The GUI side will follow the rewrite of awn-manager --gilir (20090125)

How about just using distribution-specific packages and putting each applet in it's own package? Using OpenSuse's build service, we can easily maintain repositories for multiple distributions and update them every time that an applet is added/updated. -- aantn

IMO, it'll bring more disavantages than advantages. With packages you need to deal with all format of packages (rpm, deb, gentoo etc ...), you need to deal with build process (useless for python and data stuff), and you need to support and build all differents version of distribution. With bzr branch, you need a branch to develop and distribute applets for all distributions. --gilir

I agree, but we've been waiting for bazaar to fully support subdirectory-downloads for a long time. Using OpenSuse's build service and SomeGuy's scripts, we can add on the features we want today. -- aantn

For what it's worth: <http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/51690> --malept (20090127)