> 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
|
