On Tue, 2003-03-25 at 04:08, Duncan wrote: > On Tue 25 Mar 2003 03:05, Guillaume Rousse posted as excerpted below: > > Ainsi parlait eddie : > > > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> > > > <html> > > > > Please use standard text for email. > > No kidding! > > > > Then you should talk to Texstar @ Pclinuxonline. He had a great system > > > with apt-get and Synaptic that worked with a Gui and worked wonderful, > > > although he doesn't have the time to maintain two update mirrors. If > > > one guy can maintain a program like that, why can't Mandrake?<br> > > > > Nobody told this wasn't possible. Just that isn't a priority. Developping > > GUI is heavy and costly, especially compared to adding a switch in CLI. If > > you want advanced options, you're supposed to be an advanced user, meaning > > able to read the doc and a shell prompt... > > What I'd like to see is a solution I've seen elsewhere.. > > 1) After adding any usual GUI-ified options as thought appropriate, have a > text box (or a page of text boxes for a multi-function app that calls > multiple other tools and/or calls a single tool in multiple contexts) where > the user can add additional command line switches and params as so desired. > The only support needed is to provide the text boxes, one per context, and > ensure that their contents gets passed when the specified tool is called > within that specified context. > > One example of the above that I've been working with lately is K3B, the KDE > CD/DVD image burning software front-end to the various ripping/burning/isofs > tools. In it's prefs dialog, it has an entire page/tab listing the various > back end tools, with a text box beside each, in which you can add advanced > switches as appropriate. Those that don't know about the additional switches > and/or don't want/need to bother with them (like me, for the most part) can > just leave them blank, but the several of the back end tools it invokes have > all sorts of corner-case command line options unneeded by most folks, and > having those text boxes, for additional switches to be added at invocation, > means a lot of folks can use the GUI, that would otherwise have to use the > command line, or a different front end that provided such options. > > 2) A (perhaps optional) popup, that lists the progress details and any > errors, as the process progresses. One of the big reasons (besides the lack > of advanced options in the GUI) I use URPMI rather than the various GUI > utils, is that the command line version lists the stuff as it downloads, and > I can see where something stalls, if it does. When I'm updating multiple > source lists, and I see the internet activity stop for to long a time, > without returning a success or failure dialog, on the graphical tools, I have > no way of knowing where the hold-up is. With the command line, I can > immediately see what mirror isn't responding, or whatever other problem may > be occuring. In addition, I like seeing the scrolling status, as the > individual components are d/led. A popup window with the same info scrolled > in its display on the GUI version would be very nice... > > An example of this is what KPackage does, when installing an RPM. It pops up > a status window, with the various commands and results as they would normally > be output on the command line, if one were to invoke rpm from there. Now, in > KPackage, it isn't normally such a big deal, because the process isn't so > long, with so many steps, as a multi-mirror update, and then an urpmi > --auto-select is, but giving GURPMI or Software Installer or whatever the > graphical title of the month is now, the same sort of update progress window, > would be very useful. (The optional part of it could be handled with a > simple checkbox, either as a global option in some settings dialog, or on a > per-task basis, right before clicking the "go" button.) > > Of course, doing it all in a nicely scrolling Konsole window works fine for > me, here, but if we are going to have a GUI, we might as well make it a > decently functional one, usable by power users as well as newbies, and > continuing to support new back-end options, even without new versions of the > GUI every time the back-end changes.
One request for the gui here... a select all updates button. when doing a new install 3 months after release it can be real time consuming to check each and every update one by one by one by one .... (you get the idea) James
