Bjorn Andersen wrote:
Why not make an extension to Nautilus applications:/// so it can handle rpm installations? (like OS X)
Not sure if this is the best place for discussion on this feature...maybe there is a targeted gnome development list where the technical problems with this idea can be better flushed out....but that being said..here is my take on the issue:
Automated placement in the correct Menu category would mean autogenerating, or editting of the .desktop file associated with that package. Several possible gotchas here. What if the package has an already defined .desktop file...what if it has none...what if the package actually installs several binary files that should be accessible from the gnome menus...and how do you really decide if a specific binary that the package installs needs to have an entry in the gnome menus (surely a perl module package wouldn't get an entry in the gnome menus)
So I guess some of this logic would be solved for if there was a mechanism to see if the package included any .desktop files, so that any included .desktop files could be automatically editted to use the users preferred Category. And packages without included .desktop files...don't get entries in the gnome menu(the assumption here being the packager would have included a .desktop file if the package was enduser oriented and not something like a system library or a lowlevel commandline utility) But even this leads to problems i guess with something like the rpm -V command which would flag these editted .desktop files as not being stock. Not sure if the rpm -V issue is enough to say this feature isn't implementable.
But the real question is...what are you trying to solve with this extra gnome-vfs logic? Is the issue, how to add menu items to packages that don't have menu items packaged with them? If thats it..then I don't think this is a good solution...packagers need to included .desktop files for the applications they expect people to use as a desktop user. Trying to automate the creation of .desktop files if they aren't already there would be very hard to do right....but if you limit this feature to only packages that already have .desktop files as part of their payload, this might be doable with a edit of the Category inside those .desktop files...as a sort of post rpm install scriptlet.
And would this have applicability to only inside nautilus? I'd be more interested if other gnome applications could get access to this sort of thing via the gnome-vfs layer. Like when i'm downloading an rpm with epiphany...it would be nice to be able to use the same applications:// hooks as part of the download step...but this too is probably outside the scope of this beta list i think. I would encourage you to poke around on the gnome mailinglists and see if there is interested parties there in working out maybe how this would work best.
-jef"still trying to remember his bugzilla password so he can file his own RFE's"spaleta
tor, 2003-08-07 kl. 20:47 skrev Jef Spaleta:
But the real question is...what are you trying to solve with this extra gnome-vfs logic?
A simple and intuitive front end for YUM and rpm. Never mind about the icon in the GNOME-menu. But if the Nautilus applications:/// cold make a front end for YUM and rpm, the new user wold find installing rpms easily. And a YUM repository cold be made as an RHN subscription.
A simple and intuitive front end for YUM and rpm. Never mind about the icon in the GNOME-menu. But if the Nautilus applications:/// cold make a front end for YUM and rpm, the new user wold find installing rpms easily. And a YUM repository cold be made as an RHN subscription.
Actually, I think SuSE has their update/install tool (yast) organized in a menu fashion, so that you're able to "browse" uninstalled, available applications and select for installation.
This could be mimiced in gnome-vfs (or kde io-slaves) below an icon "Installable packages", "Available software" or something like that, with rpm organized by rpm groups (Applications/Multimedia and so forth).
A package would be prestented as Name (Description), and when double-clicked, a window showing the description and size would be showed. Two buttons, install and cancel, and an "advanced" tab showing file listing, dependencies etc.
Well?
/Peter
On Thu, 2003-08-07 at 13:09, Peter Backlund wrote:
A simple and intuitive front end for YUM and rpm. Never mind about the icon in the GNOME-menu. But if the Nautilus applications:/// cold make a front end for YUM and rpm, the new user wold find installing rpms easily. And a YUM repository cold be made as an RHN subscription.
Actually, I think SuSE has their update/install tool (yast) organized in a menu fashion, so that you're able to "browse" uninstalled, available applications and select for installation.
This could be mimiced in gnome-vfs (or kde io-slaves) below an icon "Installable packages", "Available software" or something like that, with rpm organized by rpm groups (Applications/Multimedia and so forth).
There's already a gnome-vfs module in development, nautilus-rpm, to do just this, using rpmdb:///.
A package would be prestented as Name (Description), and when double-clicked, a window showing the description and size would be showed. Two buttons, install and cancel, and an "advanced" tab showing file listing, dependencies etc.
Well?
/Peter
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
tor, 2003-08-07 kl. 22:38 skrev Michael Knepher:
There's already a gnome-vfs module in development, nautilus-rpm, to do just this, using rpmdb:///.
No Backend for YUM at the same time? I mean, it wold be easally to handle depencies that way, without any user interactions...
tor, 2003-08-07 kl. 22:09 skrev Peter Backlund:
A simple and intuitive front end for YUM and rpm. Never mind about the icon in the GNOME-menu. But if the Nautilus applications:/// cold make a front end for YUM and rpm, the new user wold find installing rpms easily. And a YUM repository cold be made as an RHN subscription.
Actually, I think SuSE has their update/install tool (yast) organized in a
SuSE's YAST is way to deficult and does not look good. It isent simple.
Bjorn Andersen wrote:
tor, 2003-08-07 kl. 22:38 skrev Michael Knepher:
/There's already a gnome-vfs module in development, nautilus-rpm, to do just this, using rpmdb:///. /
No Backend for YUM at the same time? I mean, it wold be easally to handle depencies that way, without any user interactions...
-- Bjorn Andersen <_ba@linuxin.dk_ mailto:ba@linuxin.dk>
I used Yum to get some multimedia items. They required a lot of additional libs and programs installed. Yum did a great om on solving the needs and "doing the right thing".
I think that keeping the program pretty much command line will keep their concentration on maintaining the programs reliability.
Adding a front-end might be ideal for program browsing. But I love the stand alone command line progam. Keep the command line and GUI a front-end, if programmers want to start developing one.
Jim
-
Bjorn Andersen -
Jef Spaleta -
Jim Cornette -
Michael Knepher -
Peter Backlund