From: Herbert Kleebauer on 26 Aug 2007 11:14 Betov wrote: > There are still Command Lines - which is utterly un-acceptable, > in an OS, on the user side -, but user-interfaces are progressing. > Still dramaticaly counter-intuitive, but better than before. The only justification for a graphical desktop is the ability to have many command windows displayed simultaneously. If you communicate with a human, do you point on graphical pictograms or do you speak (write) to him. Why don't you use the same method when communicating with a piece of software? Don't forget to install the Midnight Commander, it's the most essential program on a Linux system.
From: Betov on 26 Aug 2007 11:33 Herbert Kleebauer <klee(a)unibwm.de> �crivait news:46D198E3.D80EAFC5 @unibwm.de: > The only justification for a graphical desktop is the ability to > have many command windows displayed simultaneously. If you > communicate with a human, do you point on graphical pictograms > or do you speak (write) to him. Why don't you use the same method > when communicating with a piece of software? Communicating with words (Command-Lines) implies a *Language*. A user does not have to _learn_ any Language. Mind you, when facing the Linux password bug, i had to re-boot in "rescue Mode", first. Do you want a user to even *know* what a "rescue mod" is, and how to access this?! No. this is not his job. Then, after the "rescue mode", i had to type in, a "bash" Command. How do you want a *user* to know what command to type in?! Well, fact is that i knew what to type in. Then, i had... to exit from there. How do you want a user to know how to do that?! Your question is so absurd that i can't believe it. A user does not even have to *know* that "bash" _exists_. This is utterly unacceptable to have to use it. What would have been acceptable, when facing the bug, would have been a Dialog, with a title saying: "Change PassWord:", an Edit- control, and the required "Abort" and "OK" buttons. Period. There is absolutely nothing intelligent with knowing the tips&tricks, which are nothing but reflects of the programmers failure. OK, i cannot shout at volunteers free works, but, saying that the actual mess is "intelligent" is the reverse of truth. Betov. < http://rosasm.org >
From: Betov on 26 Aug 2007 11:37 "rhyde(a)cs.ucr.edu" <rhyde(a)cs.ucr.edu> �crivait news:1188141084.393714.74240 @m37g2000prh.googlegroups.com: > Wow Hi, clown! Still there? Wow. :) Betov. < http://rosasm.org >
From: CodeMonk on 26 Aug 2007 12:17 Betov wrote: > of a user to *learn* anything at all. The job of a user is, as its name > says, to *use* a Software, and if a Software's final user has anything > to *learn*, before usign the Soft, the programmer has failed. Careful !!! :) Even RosAsm's interface is less than intuitive, and that's from a "final user" assembler programmer's perspective. - Scott
From: santosh on 26 Aug 2007 12:22
Jim Carlock wrote: > Just some curious questions, as I don't have a working Linux system > anywhere near me. > > Most apps inside Linux are console apps, right? Numerically yes, for an average Linux installation. > And for the apps that draw their own dialogs and forms, what would > you say those run as? Are they ALL pretty much X-Windows? Or is > it all up in the air depending pretty much upon what the programmer > wants? Is there a particular technology that applies moreso than any > other technology? The X server merely provides the ability to write pixels to the video buffer and receive input from input devices. Hardly more than that. Various GUI toolkits, like GTK+, QT, Xt, wxWidgets, etc., provide premade GUI controls. At a higher level, desktop systems like KDE, GNOME, Xfce, etc., provide interoperability between separate GUI programs. So the hierarchy can be viewed like this: Your App -> Desktop system -> GUI Toolkit -> Xlib -> X server -> Linux kernel/video driver. This is not a strict hierarchy. Your application can bypass one or more of the intermediate levels, except the X server. Actually you can bypass that too, but not in a practical sense. Generally, you can start by learning to use a toolkit like GTK+ or QT and from there, work in both directions, one towards integrating into a desktop environment, the other, towards lower level interaction with Xlib and the X server itself. Most programmers only bother with the higher level progression. Generally GTK+ is favoured over QT, because it's more universally available, but these days, the differences are more aesthetics. |