> SETH OFFERS > "So I think the best place to start would be to describe what you think is a > useful set of features in a gui that updates packages and start working on an > interface that implements that." > > At Terra Soft, we are receiving a lot of requests for a GUI for yum, mostly > from newbies who prefer to avoid the command line. We are wanting to make > this happen by the close of the summer and are eager/willing to put some > effort into this project. > > Based upon customer feedback, it seems the yum GUI should offer the level of > simplicity that OS X offers wherein: > > - A floating window enables a selection of available apps (read live from a > remote db), broken-down into the usual categories (devel, server, office, > games, etc.). > > - The size of each package and estimated download speed (if this can be > determined by a live query of the connection or the user's Preferences) > should be displayed. > > - A comparison of those apps installed for which there exists an available > update with the type of update (security, patch, or new release). > > - And of course, a failure/success designation for those apps installed. > > But ultimately, to be able to search for keywords, package names, even > categories (biology, chemistry, video editing) similar but in advance of what > we have here: http://www.yellowdoglinux.com/products/software/3rd_party/ ... > would be great. This could be a sep function built-into the local app ... > > Just my initial two-bits. Looking forward to this discussion. Two items: Some folks at cobind.com have implemented a yum gui based around 2.0.X. I've not used it, I've not tested it, I've not even seen the code but they claim it works. My goals are to do with beyond 2.0.X. As I've explained before the next version of yum redoes a significant amount of code. I did this with the intention of making it easier for a gui or other interfaces to be glommed onto yum. Right now that part is coming along. The new metadata needs some new work to meet up with some suggestions recommended by other package manager developers. After that I must finish the transaction work and bolt the kernel handling back in place. In terms of what I'd like to see in a specification for a gui. I think this specification is not unreasonable: http://fedora.redhat.com/projects/config-tools/specs/redhat-config-packages/ Additionally, I think spending time on a single interface that is GNOME or KDE HIG compliant and consistent on multiple distributions would be useful. I'd love for yum to be the backend used by this interface. So where do we go from here? Let's get the system-config-packages framework drawn up - this means glade mockups - and coming up with a set of requirements the backend must fulfill. -sv -- Fedora-config-list mailing list Fedora-config-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-config-list