On 5/24/05, Kyrre Ness Sjobak <kyrre@xxxxxxxxxxxxxxxxxx> wrote: > Well, no - it does not require network access. Part of it was to make > sure you could install an rpm from a local disk, and have a repo > configured to update this sofware. But.. in your scheme web portals are primary way to FIND packages.. you said so yourself. > > About web portals - some migth want to use this functionality, such as > happypenguin. And I'm not saying do away with web portals.. im saying do not make them the primary way by which users of the system are expected to find software. Make the primary way a client application.. re-using as much of the existing desktop ui conventions as is feasible. > Hmm.. maybe what i am really thinking of could be > "system-config-packages should use yum to resolve deps, instead of using > rpm directly, when installing an rpm from nautilus"? And I'm pretty sure there is a long term master plan to make both anaconda and whatever replaces system-config-packages yum aware. > The ".install" > thing could then be a wrapper (a tar.gz perhaps), containing rpms and an > xml file with metadata - so that a third party suplyer could avoid > special scripts etc. to setup a repo in yum + be able to pick "i want > this, this, but not that" without needing to more or less guess what is > within foo-bar-component-baz.rpm - and wich order they need to be > installed in (today, there are no option of specifying "rpm -ivh foo.rpm > bar.rpm" without using the command line). This is overkill re-invention. repo structures exist and can be used by any 3rd party who wants to provide a collection of packages. You can even drop a repo structure into a tarball. The only piece missing is a mechanism for getting a repo definition added/removed to a configuration, everything else is something ui experts need to mull over. > Interesting, but that removes the "browse" aspect. Fine... shall we add a browse softwarespace to the find dialog as well? Look at the find dialog in the gnome menu... it has a browse button. The menu layout still holds as a ui to shoot for. The idea isn't to prevent people from browsing the full space of software, the point is to make sure there are intuitive mechanisms that make it less likely for users to need to do a full browse. browsing the full space is never..ever...ever going to be intuitive nor efficient. Just like using your filebrowser to hunt for random executables on your filesystem is something that can be done..and will be done...must be done.. in some cases, its not what you want novice users to be doing most of the time. For installed applications you want users to be able to quickly navigate a menu and then falling back to a usable find dialog, before resorting to a brute force browse. And I say, if the ui works for the main menu.. it will work for an software installation app. > There should be a description of what each package do as well. And the > "yum groupinstall" thing should be closely mapped in the ui. There is no technical reason why the visible comps.xml definitions can't be re-worked to closely align with the categorization of applications in the main menu. In fact i find the dissimilarity between Core's user visible comps group definitions and the main menu layout to be a glaring usability problem when it comes to post install usage by novice users. A yum enabled version of system-config-packages will still confuse novice users simply because the comps defined groupings are not aligned well with the application categorizations they use every day in the system menu. How to categorize packages, is a complicated issue. We might end up needing to provide different comps.xml files for different purposes or intended audiences. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
