Thats too much work, I would be happy if all the drake tools had a "tools" dropdown list in the corner.. that list should contain a list of all the installed tools, for rpmdrake...etc... so you can easily access any of the tools, from any of the tools.. (also a quick and easy way to see what tools are installed as well. since mandrake refuses to standardise on a naming convention for tools (apart from having drak in it somewhere.)
Its called integration, and mandrake is one of the very few who seem to think integration is bad from a GUI perspective but good from a programming perspective... Seriously, one little link menu in the corner of all the drake tools, most peoples complaints would fade away.. and newbies would ask less questions.) Other then that, nine appears to be a great release... regards Franki -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Sparenberg Sent: Wednesday, 9 October 2002 4:45 AM To: Expert List Subject: Re: [expert] rpmdrake 9.0, a step backwards :( On Tue, 2002-10-08 at 11:44, Todd Lyons wrote: > Dale Huckeby wrote on Tue, Oct 08, 2002 at 12:51:24AM -0500 : > > > > Is the end-user's convenience less important than the programmer's? > > The endu-user's convience IS first. Every step starts with "Open > Mandrake Control Center and..." > > Blue skies... Todd Ok now the discussion has gone on to the point of creating two equally problomatic camps. My question is there a middle gournd. Can the UI of old be merged with the codebase of new. The answer is yes. Much of the problem stems from a common concept of re-writting code, as apposed to re-editing code. A great example of what can be done by re-editing is OpenOffice.org. it's esenntially a re-edited and cleaned up version of star office. They didn't pull a mozilla and go back to square one. The end result is code that works vastly superior to the original (rember 5.2 taking over your desktop) loads cleaner etc. In Mozilla it took years to create a viable 1.0 release. My point is that we don't need to rewrite or go back to anything. Instead lets move forward What works better. What doesn't work as well. What doesn't work at all. Then once the baseline is established. Lets beat it up a bit and make it do what we wan't ... Saying if you don't like it maintain the old is as counter productive as saying the new is no good get rid of it. What is causing problems? Early in beta testing I submitted that the wording in the configuration tool of MCC was counter intuative, in that two of the links names sounded to me like they were the same thing..... pooof it got fixed.. because I was able to list the problem, list why it was a problem, and (even though mine wording wasn't used) suggest a possible fix. This fix doesn't have to be code. But a clear statement of when I do this I expect this but get that. Would be very helpful. Then they would know what the problem is exactly. Not a blanket statement like it's sucks the old was better. Why was it better what does the new one do or not do that you need. List it out for readablity and you might get a fix. In fact you very well could get a fix. (although I'd still love to have a way for MCC to list all of my X settings like it used to but I'm working on getting that one included *grin*) Again. remember the the repororters credo. What happended what was supposed to happen when did it happen why does it happen where does it happen who did it happen to How could it be better. + 1 more How do you repeat this event. Answer as many of those as you can and you'll find that a lot can get done to improve things. James
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
