Here's my premise: the isolated BBS world cannot survive in the face of point-to-point IP. You'd think I would be in the right age group to play with BBSes. But I didn't (well, except to write one for pay once). How come? Because I was always on the Internet, so it seemed silly to BBS. Now that everyone is on the Internet, the same effect has occurred on a broader scale. No one bothers.
Not counting strange experiences of the PDP-11 and RSTS/E kind in the late 70s, by the time I hit the net in the early 80s, my peer group had already passed the BBS scene by light years. You see, we had the Internet. We had Usenet and Internet mailing lists, so we already had plenty of non-real-time discussion forums. For file exchange, we'd just compress, uuencode, shar, them and mail them to each other. For file archive repositories, we just used ftp. And for real-time, well, it started with talk, then moved on to ytalk, and some folks eventually got stuck in IRC, muds, and the like. I'd talk to friends around the country in real time, leave messages for them over night, all the things we do today. There was no cause for a BBS.
What I'm saying is that the reason you don't have garage-style BBSes much anymore is that the Internet renders them redundant. And I point out that for the community that was already on the Internet back in the 80s, we saw no reason to bother with the small and localized world. Now, not everyone was a major arpanet hub with its own imp, so the Internet came later to users than to us Unix programmers who were lucky enough to be on the real Internet back before it got invaded. But even after the invasion, one could always find one's own clique somewhere.
Look at what happened to "mass-market" BBS style access providers, like Prodigy and Compuserve. Once the real internet hit the masses, nobody wanted a closed world. You see, given a large and open world, you can create closed pockets. But you can't go the other way around. If you start out cut-off and closed, there you say.
2. There's a "search" under File, but then a "find" under Edit. Why is there even an Edit button? How can I edit anything in static documents?
Point 2 - Edit is there since thats what find comes under in most GUI's. It makes some sense, just not too much
Once again we see the problem of doing nothing more than trying to copy Microsoft. That does not make sense to me, and it doesn't seem to make much sense to you, either. But you're doing it anyway, just because Microsoft does, even though it's easy to come up with something more sensible. This stuff is not easier to use than what we already have. It's just different, assuming a different set of prior knowledge. This means that the learning curve is very steep for non-Microsoft people. That's why it's annoying.
3. Also under the File menu is some "Close" command. But when I used it,... You should choose a better word there.
Point 3 - You seem to confuse Window Manager and Application menues. Closing Windows does not Minimise them. Seems fair enough to me.
I don't know what this "minimize" jazz is. Sounds like xterm's mechanism for selecting either the "tiny" or the "unreadable" font. I can't see why close would ever mean something other than iconify. Please don't use this silly "close" word. Use "exit" when you mean exit, and use "iconify" when you mean iconify. Where is the configuration setting to fix this?
5. It appears that you use the same happy icon in the KDEhelp window to indicate "reload current document" as you use in another menu to "rearrange icons".
Point 5 - It means refresh / reload, not rearrange icons. Where you got that idea, I don't know. The tooltip tells you what it means
First of all, I got the idea from one of the random menus down in the left corner. It's got the happycon with the words "rearrange icons" next to it. It looks like a "recycle" glyph. If you simply used words right from the get-go, you'd never have the problem of someone having to look up the meaning of a happycon, because you'd have a word.
6. You can't use the regular keyboard for paging activity. I tried everything I knew. I used SPACE, BACKSPACE, ^F, ^D, ^B, ^U, B, F, b, f, ^J.
Point 6 - Configrable. Go configure it. Its set to page up/down by defualt. KDE Control Center or Settings-KeyBoard ShortCuts
Page up and page down are no more useful to the touch typist than a mouse is. They aren't where you can feel them, so you need to take your eyes from the screen. As soon as you do that, you've broken your concentration. You should make the default reasonable. Maybe you need to have a "Unix defaults" meta-setup option.
8. In KDEhelp, you make the user guess whether something is, whether it's in man, kde, or info format. How is the user supposed to know? That's not nice.
Point 8 - Use the search tool after ticking all types
But I'm not allowed to search the info stuff, which has always been my complain about it. And the searches that I can do don't bother to provide useful output.
9. The presentation of available man stuff is just nowhere near reasonable.
Point 9 - Again, an Xism, its just like Xman
That doesn't make it right. xman(1) sucks, too.
11. When it comes to choosing a section, you ignore both the users MANPATH setting and the operating system's default. That means you can't find, for example, ssh which is in/usr/local/man.
Point 11 - may be valid, works fine here though
First of all, it turns out that the program does correctly use my MANPATH if started from the command line. It does not do so when started from kdm(1). That's probably because my user environment wasn't loaded then.
I think what may be happening is that it doesn't understand the linking conventions in the man trees./usr/local/man/man1/ssh.1 is a symlink to/usr/local/man/man1/ssh1. It omits ssh, and shows only ssh1. But it does manage dlclose(3), which is symlinked to the dlopen(3) manpage, so many that's not it.
12. The output format is alphabetized on the X axis instead of on the Y axis
Point 12 - valid, but this is how Xman does it.
Then fix it. This is easy, and it's obviously the right thing to go the other way.
Point 13 - may be valid, I see no distinction between locally installed and OS Standard - its installed or its not.
You've never heard of "standard part of the operating system" versus "add-on stuff"? What are you, an rpm(1) victim?:-)
15. The "Keyword Search" takes forever (ok, a very long time) when specify KDE documentation. Once again, you make people know where things should be.
Point 15 - it takes time sure, but it works. I don't see your point
You should have a database. The only reason to grovel through everhyting is if your database can't understand regex queries. Try glimpse(1) or something.
Point 17 - Its a keyword search, like, just one word. Pattern matching regexps would seem to be excluded by definition.
This is exactly where you most want a pattern match! You're doing an exhaustive search, so you need all the power you can get. Otherwise, you get too many hits and can't weed anything out. And with the current program's output format, it's completely useless. All searches should be patterns. Again, I can only think of one valid excuse, and you're not doing it.
20. When you hit the left-arrow to return to your search, you have lost the string that you were searching for. It's gone from that window. In fact, so are the button settings.
Point 20 - Its assumed you have found what you wanted. Good enough assumption to make, else you'd complain about clearing it for a new search.
That doesn't make any sense. When I hit the back button, I expect to return whence I came. You aren't doing that. You're taking me to a page that doesn't have the same stuff on it as the one I left! There's no reason to lose my state.
Point 21 - Its a bug when you move focus around the elements in the window. Report it.
What address do I send bug reports to?
22. In the Search window, you're sitting there typing something, and you hit ^W to back up a word (those are in my stty settings). Guess what? IT DESTROYS THE WHOLE WINDOW! Did you hear what I just said!? You don't get asked permission. It just destroys it. You lose all your state, your forward-back list, and your sunny and pleasant disposition. This is completely evil.
Point 22 - ^W is a KDE standard binding for close. Change it.
No, no, no, no, no, no! This is what I mean about being disrespectful to Unix users. We have already specified our editing preferences, just as we've specified our manpath, bin path, etc. ^W is one of the most commonly typed editing characters for many of us. And you've made it into something that destroys a program! That's just plain suicidal. Horrible.
While I'm on the subject, you don't seem to pay attention to ^C to interrupt programs. Don't make me find stupid happicons. This is as bad as lynx. ^C means interrupt.
23. I've tried to mouse grab from the KDEhelp window and paste it into the Find window. But I can't do that. It seems to have its own separate buffer system. This is very confusing.
Point 23 - It works fine here, with Ctrl-c to copy
No, no, no. A THOUSAND TIMES, NO!. Control-C is interrupt current activity. Why would I ever use it be an alternative to the middle button? This is super nonintuitive. I know what ^C does, because I set it up with stty(1). This is so Unix-hostile!
24. There's no "Clear" on the Find window to help with cut and paste.
Point 24 - No need
Wrong. If you have something in the space already, and something in your cut buffer, you need to clear it first before you paste. Look at Netscape's ALT-F find command.
25. When you want to do a search, you have to hit ^F. How do I make that be a slash instead?
Point 25 - Configurable, though not a good idea. consider typing / anywhere in KDE ever again and getting a find dialog. Or do you mean Ctrl-/ ?
If the program isn't requiring keyboard input, it should use the regular keyboard for its actions, so a slash in kdehelp, etc. You could use Meta-/ or whatever if you were in keyboard input mode already.
26. When the find window pops up, it doesn't have the focus. Instead, you have to searching for it with the mouse. That's a waste.
Point 26 - Focus issues are configurable for KWM. See the control center. Focus can be shifted using the keyboard, with Alt-Tab or Shift-Alt-Tab
Where? Don't tell me "see the control center". I hate that. I have to search for everything. Why can't we be given a simple but discrete command to type in, or a discrete file name to edit? Why must we always poke around randomly till we find something?
27. You can't use your normal editing characters in that little box it gives you. I tried ^U (my kill character), but was ignored. I tried ^W (my werase character), but was also ignored.
Point 27 - Ctrl-a, Ctrl-e work. So does del and backspace, etc. So does Ctrl-H Some subset of Emacs bindings, by the look of it, plus some Windows ones.
This is completely Unix hostile. I've explained this to you before. I already told the system my preferences. Respect them.
28. If you already have a "Find" window up, but it's exposed, you don't realize this. You sit there in the KDEhelp window hitting ^F again and again, but absolutely nothing happens. There's no new find window that appears, no beeping, no flashing, and no raising of the existing window that you don't even know is open.
Point 28 - Their called application modal dialogs. Sort your WM config to put them over the window that creates them.
Where is that? PLEASE TELL ME THE COMMAND. I spent a long time searching through every fricking one of those blasted menus. I DID NOT FNID IT. Give me a discrete command, or a discrete filename. I did your search. I wasted 10 minutes of my life. This is worse than UUCP routing. This is random walking, hoping it will get there someday. Think how much better user@host is. It's discrete. I don't have to poke. Just tell me where something is. Why do you think I want to search? You just made me lose 10 minutes of my life because you can't specify how to do something in a precise, point-to-point fashion. At best you would say "first go here, then go there, then go there, then do this". That's crazy. Makes you want to kick the monitor. Is this Microsoft's fault, too?
29. The Find window is named "kdehelp". That's what shows up in the title bar and in the icon manager. That's not a good name, because it's not really the kdehelp window. It's a transient Find window managed by KDEhelp. Why is it even showing up there in the icon manager?
Point 29 - Its a Window, so its listed as such. Transients simply aren't excluded from the Window list - its a feature.
Then name it the right thing. It is not the kdehelp window. It's its find window. Different, you know.
Point 30 - See 28
Yes, please do see it. And see my response.
This is extremely Unix-hostile. Can you really not make your Windows rewrite without kicking sand in the faces of Unix programmers? This makes no sense.
I wondered whether my experiences with the asquerous kdehelp(1) program might have been a fluke, so I've tried to use assess some other tools. The next one I'm going to tell you about convers the bugs and confusions greeting a real Unix user in ktop(1).
When it starts up, it doesn't choose a large enough window to display all the columns, so you must immediately resize it.
It complete ignores attempts to divine its version number. ktop -v, ktop -h, ktop -version, and ktop --version all are completely ignored. That is, it just pretends you didn't give it any options, accepting those that it didn't understand. This is simply brain-damaged and wrong; call it a bug.
I did finally find something it paid a small about of attention to: ktop --help. But that wasn't very helpful:
What are "kdeopts"? Where am I supposed to learn about them?
The column for SHARE always has 0 in it. Regular top(1) produces correct output on the same system, so it's not as though that information were unavailable. This is obviously a bug.
The screen refresh is set to epileptic strobe mode. It clears the whole thing and rewrites everything, even though it doesn't have to. Just set it to fast update, and you'll feel start to get a really bad headache. This is not evolution; this devolution. Regular top(1) knows better than to do this to you. Only update the things that have changed! And don't clear it all first.
After running for a while, I got this:
X Error: BadGC (invalid GC parameter) 13 Major opcode: 56
And the program proceeded to die of a SIGABORT.
The thing would often splat a zillion copies of
QGDict::look: Attempt to insert null item
on the eterm(1) that launched it.
I couldn't find anyway to use the keyboard to get to the buttons at the buttom, like "show tree", "all processes", "refresh now", and "kill task".
In regular top(1), you can use the space bar for an immediate refresh; that is, to get the next screen as you would in more(1) or less(1). You can't do that here. Why did you omit this simple intuitive interface?
The default kill(2) signal down on the bottom is a SIGKILL. That's not a good idea! You should default to SIGTERM, just as kill(1) does. Save the big stick for a last resort.
The happy little icons next to the program name doesn't seem useful. The bitmaps must have made sense to someone, but by and large, most of them mean nothing to me. And they're too small to read in many cases. Plus you can't even sort on them. And the dumb program uses some little blue sunburst for anything it doesn't know about. That's useless eyecandy. How do you turn those silly things off?
Many of the commands had no string listed for their command line column. This is a bug.
I couldn't seem to manipulate the menus using the normal keyboard as promised. I can hit ALT-R to get the Refresh-Rate menu, but then it offers things I can't get at. It suggests "Manual Refresh", "Slow Refresh", "Medium Refresh", and "Fast Refresh". But there's no underlined letter to tell me what to type. I tried M, S, and F, but that did me no good. I could type ENTER, but not ^M or ^J. And I couldn't move up and down the menu using either vi(1) oremacs(1) navigation sequences: j and k were ignored, as were ^N and ^P.
You could only select one process at a time. This makes it impossible to send a signal to several processes at once.
If you turn on tree mode, you can collapse and expand hierarchies. If you selected the collapsed node, such as an entire process group, and send a signal, it still just uses a single kill(2) on the top process rather than a multicast kill(2) to all of them, or perhaps better, a killpg(2). I couldn't figure out how to get process groups to even display, let alone how to affect them.
You have to use ALT-P to get at the process killing list. A simple `k' would be much easier, and more intuitive. How do I create that shortcut?
After an ALT-R or ALT-P or whatever, my focus is held prisoner, locked to the menu selection. That's quite rude. Definitely a bug.
The signal list that ALT-P provides you is very limited. It only allows SIG{INT,QUIT,TERM,KILL,USR[12]}. Last I checked, there were plenty of other signals, including highly useful ones like SIGHUP. It doesn't allow you to type in a signal name or even signal number.
The signal list that ALT-P provides you has incorrect expanatory text.
It claims that SIGINT is a Control-C. Well, maybe. Actually, Control-C is going to do the whole process group, and this isn't. Also, it ignores my stty(1) settings again. I tested this like so: stty intr ^g; ktop But the message still said that SIGINT was Control-C. That would be wrong.
It claims a SIGQUIT is a "core". Huh? Do you really think that means something to people? Anyway, it's wrong. I always run setrlimit(2)ed to 0. So some things certainly wouldn't core. Also, setuid(2) programs wouldn't core, either, or that would be a security problem. In any event, it's hardly the only signal that normally generates a core dump. So do SIGILL, SIGTRAP, SIGABRT, SIGEMT, SIGFPE, SIGBUS, SIGSEGV, and SIGSYS--according to my signal(3) manpage.
The note for SIGTERM is "term."--how useful! Is that the best you can do?
The note for SIGKILL is "term."--hold on! That's the same as the previous note's. This is wrong.
You should use real signals with real explanations. Here's from the manpage:
Name : Default Action : Description
SIGHUP : terminate process : terminal line hangup SIGINT : terminate process : interrupt program SIGQUIT : create core image : quit program SIGILL : create core image : illegal instruction SIGTRAP : create core image : trace trap SIGABRT : create core image : abort SIGEMT : create core image : emulate instruction executed SIGFPE : create core image : floating-point exception SIGKILL : terminate process : kill program (cannot be caught or ignored) SIGBUS : create core image : bus error SIGSEGV : create core image : segmentation violation SIGSYS : create core image : system call given invalid argument SIGPIPE : terminate process : write on a pipe with no reader SIGALRM : terminate process : real-time timer expired SIGTERM : terminate process : software termination signal SIGURG : discard signal : urgent condition present on socket SIGSTOP : stop process : stop (cannot be caught or ignored) SIGTSTP : stop process : stop signal generated from keyboard SIGCONT : discard signal : continue after stop SIGCHLD : discard signal : child status has changed SIGTTIN : stop process : background read attempted from control terminal SIGTTOU : stop process : background write attempted to control terminal SIGIO : discard signal : I/O is possible on a descriptor SIGXCPU : terminate process : cpu time limit exceeded SIGXFSZ : terminate process : file size limit exceeded SIGVTALRM : terminate process : virtual time alarm SIGPROF : terminate process : profiling timer alarm SIGWINCH : discard signal : Window size change SIGINFO : discard signal : status request from keyboard SIGUSR1 : terminate process : User defined signal 1 SIGUSR2 : terminate process : User defined signal 2
Even if you were do that for only those four signals you permitted, it would still be better.
What about an option to kill insistently? You know, send a polite SIGTERM or SIGHUP, give it some time, and if that doesn't work, send it a SIGKILL.
There's no search mechansism. It would be nice to be able to apply a filter expression, like to select only certain command names. If you wanted to make it really useful, you'll permit a filter that took a real expression, such as:
ALT-H takes me to the misnamed "File" menu, not the "Help" menu that the display would lead you to believe.
What is "quit program" doing in the File menu? What does exiting a program have to do with accessing files? This makes no sense at all. Why isn't it just ALT-X for eXit, or ALT-Q for Quit? Why is it ALT for anything? The program isn't doing anything else with those keystrokes. Just skip the ALT entirely.
When you use Kill Task, it pops up an annoying confirmation window. That's bad enough, but it has the audacity to force you to drag your mouse up to the window, because it doesn't have the focus. You definitely have lots of incorrect focus problems in KDE, you know. And even once you're there, you have to use the mouse, because the keyboard is useless. You can't use C for continue or A for abort. You have to use the damned mouse. Put the thing in focus, and let me type. Sheesh!
These stupid confirmation windows are unESCable. At least the ALT-x menus pay attention to that. This is inconsistent. Screw the confirmation windows. If I wanted my hand held, I'd be on a date, not a computer.
As you see, ktop is not as useful as even good old top(1) is, and is much harder to work with. I think it's pretty obvious that this program, like kdehelp(1), isn't ready for prime time. I find that every one of these KDE GUI things are much better at impressing people who don't have to use them. And those that are copies of existing tools always seem prettier but less functional than the originals. Who cares about pretty if it doesn't get the job done? What I'm saying is that they've paid a lot more attention to chrome than to power. This is why you need usability testing.
Is there any technical treatise enumerating the relative merits (well, and demerits:-) of KDE versus Gnome? I don't want a flame fest where some advocate bashes the other group. I mean something reasonably neutral but highly technical.
You don't have to use negative flash words. They make your audience stop listening, because they trigger too much hostility. And if you make some irritable, it's difficult to discuss matters with them. Try talking to Microsoft employee and always use the word "legacy" or "primitive" in tandem with "Windows" and see how far it gets you.
Just because you can use keystrokes doesn't mean you can know where things are a priori, nor that you can search for them. Consider my example of "KDE Control Center"/"Windows"/"Mouse" versus "KDE Control Center"/"Input Devices"/"Mouse". You could say those aren't pop-up menus, but they're really effectively the same thing and suffer from the same problems.
After Roberto groused about non-specific complaints about KDE, I spent a couple hours this morning poking around kdehelp(1), running usability tests, and writing up a report of my findings. This should put an end to the complaints regarding lack of concrete criticisms. Here they are, all thirty of them. I won't give it a grade of A through F, but I will give it a U for "unsatisfactory". Read through the bug list and see whether you don't agree. Some are specific to kdehelp(1), but many are related to the general toolkit and window manager strategies.
Looks like I forgot one. Roberto kept asking where KDE cares about manual orientation in its messages to the user. Now, I'm not really sure whether you consider KDE the toolkit, the window manager, the programs, or what. But running a KDE desktop, the following situation arise.
The "left button" nomenclature is on the "KDE Control Center", then under the "Windows" submenu, then under the "Mouse" submenu. Even once you have gone to "KDE Control Center", then to the "Input Devices" submenu, then finally to the "Mouse" submenu underneath that, you'll find that switching between left and right handedness in no way alters what the other Mouse menu says. It's not immediately obvious why you have more than one Mouse menu. It certainly took a while to find that what button did what was on the "KDE Control Center"/"Windows"/"Mouse" menu, but that the manual orientation was controlled by the completely different and unconnected "KDE Control Center"/"Input Devices"/"Mouse" menu. And there's no way to find it other than slow, recursive, linear search. That's why you need to have some way to search a menu tree quickly and efficiently. If I could have just typed something like/handed and it had whisked me off to the right subsubmenu, this would have saved me a lot of time.
So, since you didn't like the silly accusations I did about your pet project, you won't substantiate the silly accusations you made about mine.
Ok, you asked for it, so now you get it. And it is not a pretty picture. The combination of outright bugs, clear design errors, and deficient functionality render this program tantamount to unusable. Read these over, and you'll see why.
The File/Edit/Goto/Bookmarks/Options menu bar doesn't make any sense. To make a new help window, you have to go to File. What does that have to do with a file? Likewise to search. I mean, honestly -- what are you thinking? This is a general problem in all the KDE stuff I looked at. You keep putting things in really non-intuitive categories. I mean, get serious: you've got "System", "Settings", and "KDE Control Center". Those make no sense to me. Why are some programs in one of those categories, but not another? What's the difference? "Applications", "Utilities", and "Internet". How am I supposed to look one place and not another? What's the difference between a program that's an "application" and a "utility"? And what about "Graphics", "Multimedia", and "Internet". Why aren't the graphical programs under Multimedia? Why is local user information (finger config) listed under "Internet"? Don't tell me "oh, you can edit those". The defaults should be sensible. These aren't.
There's a "search" under File, but then a "find" under Edit. Why is there even an Edit button? How can I edit anything in static documents?
Also under the File menu is some "Close" command. But when I used it, it didn't close the file I was viewing, which is what you expect a "File/Close" command to do. The other meaning of close, iconify, was actually what I was expecting. But guess what, the KDEhelp wasn't iconified. It was completely destroyed without warning or confirmation! You should choose a better word there. People who use the word "close" to mean iconify will keep killing things. On the other hand, "Destroy" (or perhaps better, "Exit") and "Iconify" aren't ambiguous.
The next line, the one with happy icons on it, is not intuitive. How do you disable the pictures and turn on just the words, the way you can in netscape?
It appears that you use the same happy icon in the KDEhelp window to indicate "reload current document" as you use in another menu to "rearrange icons". What the devil is this overloading about? This cryptohieroglyphic system doesn't help anyone at all. What does that bitmap mean? Why does it mean something totally different elsewhere? Why aren't there words?
You can't use the regular keyboard for paging activity. I tried everything I knew. I used SPACE, BACKSPACE, ^F, ^D, ^B, ^U, B, F, b, f, ^J. Nothing works. This is not intuitive. How do I make it follow the conventions of less(1)? Even netscape recognizes space and backspace for going back and forth by a screenfull. This is what I mean about discriminating against people who can actually touch type.
The cut-and-paste system doesn't by default work like xterm. How do I change that setting? The reason I need to do this is because your defaults are very week, but less powerful than I'm use to. It doesn't seem to follow the model of index-finger clicking once for a character, twice for a word, and thrice for a line. Even netscape can do this. Why can't you? And once you've grabbed a word (for example) you can't use the ring-finger click to delineate the word at the other end.
In KDEhelp, you make the user guess whether something is, whether it's in man, kde, or info format. How is the user supposed to know? That's not nice.
The presentation of available man stuff is just nowhere near reasonable. For example, choose section 1. You get a zillion names of commands. 964 of them, in fact. I can't visually search a thousand different things like that.
You don't provide the whatis description of each man entry in that listing. That means the user has no way to guess what the page is about. That information is important.
When it comes to choosing a section, you ignore both the users MANPATH setting and the operating system's default. That means you can't find, for example, ssh which is in/usr/local/man. settings from the/etc/man.config file. (Actually, that file's name and syntax varies depending on your operating system, even within the family of operating system. Redhat Linux puts it under name, SuSE Linux puts it another name, and Debian Linux puts it in a different name still. And these actually have different parses, too. E2MANYLINUCES. Sheesh. But they're not alone. FreeBSD has its own notion of where to put the config file and how it parses, and this is different OpenBSD's notion of the same. And please don't talk to me about Solaris.) But the point remains that you have to respect the local configuration, or else you aren't actually doing what you say you are.
The output format is alphabetized on the X axis instead of on the Y axis the way it should be for convenient reading. People want to read down columns, not across rows. Why? Because it's a lot faster. If you keep going across the rows, you have to do a carriage return with your eye constantly. It's all back and forth and back and forth and back and forth. But going down the columns, you don't have to do that.
So, your program doesn't understand man trees, whether in MANPATH or in the system config file. This is a problem, because you can't tell which mantree the hits came from. Also, you aren't able to limit you search to just locally installed stuff versus the standard operating system, etc.
On the "Keyword Search", on the other hand, it does seem to respect your local conventions. It's also quite fast. I'll bet that's because it's just running apropos directly, which is more clever by half.
The "Keyword Search" takes forever (ok, a very long time) when specify KDE documentation. Once again, you make people know where things should be.
The documentation search, when you specify manpages, doesn't distinguish between the whatis database and the raw data. How do I say which one I mean?
You do not provide a "word boundary only" search option. You don't tell people whether they can use a pattern match, but even if they can, would that be a \ or \bword\b?
The return list is not helpful. It is not sorted in any understandable fashion. It does not show any of the line or sentence that matched. It contains redundancies. For example, one set of returns looked like this:
Filters Filters The KWrite Handbook: Introduction The kppp Handbook: Modem Tricks & Hints KPilot v3.1 KPaint - Help Contents KPaint - Help Contents VT100
But those are not really to the same places. They just have the same title. It looks like they did a full body search, but I can't tell.
When you follow one of those links and return via the left arrow (hey, how does that play in right-to-left reading places?), it runs the whole damn slow search again! This is nutty. The KDEhelp window should cache those results. And why does it do a manual search anyway? Why don't you have a quickly searchable text corpus database index that's pre-generated by the system?
When you hit the left-arrow to return to your search, you have lost the string that you were searching for. It's gone from that window. In fact, so are the button settings.
I sometimes managed to get the Search window in some state where I couldn't just hit ENTER to launch the search, but had to use the silly mouse to push a button. I didn't figure out how to reproduce that consistently.
In the Search window, you're sitting there typing something, and you hit ^W to back up a word (those are in my stty settings). Guess what? IT DESTROYS THE WHOLE WINDOW! Did you hear what I just said!? You don't get asked permission. It just destroys it. You lose all your state, your forward-back list, and your sunny and pleasant disposition. This is completely evil.
I've tried to mouse grab from the KDEhelp window and paste it into the Find window. But I can't do that. It seems to have its own separate buffer system. This is very confusing.
There's no "Clear" on the Find window to help with cut and paste.
When you want to do a search, you have to hit ^F. How do I make that be a slash instead?
When the find window pops up, it doesn't have the focus. Instead, you have to searching for it with the mouse. That's a waste.
You can't use your normal editing characters in that little box it gives you. I tried ^U (my kill character), but was ignored. I tried ^W (my werase character), but was also ignored.
If you already have a "Find" window up, but it's exposed, you don't realize this. You sit there in the KDEhelp window hitting ^F again and again, but absolutely nothing happens. There's no new find window that appears, no beeping, no flashing, and no raising of the existing window that you don't even know is open.
The Find window is named "kdehelp". That's what shows up in the title bar and in the icon manager. That's not a good name, because it's not really the kdehelp window. It's a transient Find window managed by KDEhelp. Why is it even showing up there in the icon manager?
When a Find fails, it pops up a "Find Complete" confirmation window. And this one is also without the focus, so you have to go chase it down with the mouse. That's crazy. You have nothing else to do. It should have the focus. You can try scrolling the KDE help window on your own, but it completely ignores you. It refused to do anything until you take your mouse and attack the Find Complete window. With a vengeance.
Consider this a bug report. The operating system is Red Hat Linux release 6.0 (Hedwig) , standard installation. I couldn't figure out how to report KDE's version:
# running without a DISPLAY envariable set $ kdehelp -v [Exit 0] $ kdehelp -version [Exit 0] $ kdehelp --version [Exit 0] # look, no complaints, no answer, and confusing exit statuses
$ man -k kde kde: nothing appropriate
$ which kdehelp /usr/bin/kdehelp
$ strings/usr/bin/kdehelp | egrep -i 'version|release' copy__C24KCharsetConversionResult mouseReleaseEvent__7QWidgetP11QMouseEvent keyReleaseEvent__7QWidgetP9QKeyEvent mouseReleaseEvent__10KDNDWidgetP11QMouseEvent dndMouseReleaseEvent__11KHTMLWidgetP11QMouseEvent Version Version
But it was the standard Redhat OS from VA, so you should be able to guess.
While we're at it, what is that X11 stuff doing in/usr/bin? You aren't supposed to do that, you know. Otherwise you make non-X11 people suffer the search costs that they don't need. Help,/usr/bin has more than 1400 entries in it on this Redhat OS from VA. Somebody wasn't thinking: Linux is notoriously bad with large directories. Please don't contribute to this problem.
No, that's not enough. I regularly enable/disable and change proxies on the fly. It's a very common operation for me. There's no reason to reboot netscape just to do that. Nor should I be forced to navigate the same set of hand-holding menus every time. I know what I want, and it won't let me get there without negotiating its speedbump system.
The point is that if the documentation is not all in one place, and more importantly, not all in one form, it's hard to write one set of tools to manipulate them.
Note that I'm not saying which form it should be in. But the lack of consistency is what makes it hard on programmers to deal with.
On what terminal emulator did you find that bug, in Konsole or in Kvt? I can't reproduce it on Konsole.
It's not just there. It's anywhere that you can type something in. I've specified keyboard behavioural preferences, and they aren't universally accepted.
Uh oh. Looks like somebody's holy cow just got gored. I wonder which it was? I didn't even curse the wicked emaxen, and it still hates me forever. Precious.
The point remains that a hodgepodge system is not as amenable to uniform, tool-based manipulation as is an integrated, homogeneous system. You may call that flamebait if you will, but it does not alter this fact.
Surely you jest! I don't run with javascript, use a spamvert and brainfuzz filtering proxy, and don't even have images autoload. But I was interested in whether they'd cleaned up their HTML, so I looked at it manually (er, ocularly?). One can do that, you know.:-)
That's what happens when you speak to ignoramis... ahem, to ignorant people.
Hee. We should start a movement to conjugate that word as the verb it originally was. "You are such an ignoras. I am no ignoro, you know. We are such a bunch of ignoramus. You guys are such ignoratis."
Once we've done that, we start adding in mood. "If only he weren't so ignoraretur!":-)
Fetch the raw document with wget or lynx -source, or from netscape do a "view source" on that page. Now, look at the javascript gunkola at the top. They assume that if you're not running Linux, and you're not running Windows, then you must obviously be running a Mac! That's hilarious.
Converting the existing GUI OS userbase to UNIX and GNU/Linux.
...And that ultimately the dumbing down of UNIX and GNU/Linux will weaken the OSS effort...
Namely, where to take our UNIX world next, and how to include the majority of the world's PC userbase without crippling GNU/Linux so it's usable for them?
I'm sorry, but it's just very difficult to take seriously someone who keeps using the hackneyed old political saw from the FSF's kookbin, currently the leading contender for the OSS World's Most Devisive Crackpot Agenda. It's a negative flash word, plain and simple, one that brings to mind images of Rasputin preening himself in public. And this is not a pretty picture.
I'm sure you can talk about Linux-based operating systems without triggering the hostility inherent in that utterly ridiculous appelation you were using. It would really help a lot.
by Rilke on Friday November 26, @02:19PM MDT (User Info) The idea that unix users are left out in the cold is a bit overstated, but let's take the original questions you had. 2. (keyboard interface). The kde style guide requires keyboard interfaces to everything. This is pretty much handled in the motif/windows way, with Meta key access to the menus. 3. (scripting): python is establishing itself as the standard script language for kde. You can write kde apps in it, and the interoperability between scripting and the individual kde apps is growing every day. I'm honestly not sure where that's going to wind up, but this is the area that holds the most promise for the long-time unix user. 5. (usability tests). I find the question kinda backwards. As in most OS projects, the main usability tests were no doubt on the programmers themselves. The idea that there's no feedback from longtime unix programmers seems misplaced: the grand majority of the kde programmers and the kde beta testers presumably fit into this category.
And I'd disagree that the GUI-standard menu design is slow, stupid and repetitious. It's basically a way to arrange keystroke prefixes, with immediate visual feedback and help. That's pretty useful actually. It's just wrong to state that things in a nested menu are multiple mouse-clicks away; they're also just a few keystrokes away.
What you aren't realizing is that the keyboard is much easier to use than the mouse. It's incredibly faster. And it's also easier on the RSI front.
In case you missed here, here's an example of the problem. Consider how to disable the proxy for netscape. You have to click through a bunch of menus, each and every time. It drives you nuts when you realize if they had merely included a way to let you type something, you could have said "no proxy" or "set proxy=off" or whatever. But no, the keyboard is to be avoided and the mouse is to be worshipped. Of course, they lose there, too, because eventually they make you type the host and port for the proxy. It would have been a lot easier to type "set proxy=host:port" ab initio.
Here's an example of the problem. Consider how to disable the proxy for netscape. You have to click through a bunch of menus, each and every time. It drives you nuts when you realize if they had merely included a way to let you type something, you could have said "no proxy" or "set proxy=off" or whatever. But no, the keyboard is to be avoided and the mouse is to be worshipped. Of course, they lose there, too, because eventually they make you type the host and port for the proxy. It would have been a lot easier to type "set proxy=host:port" ab initio.
I will not answer the specifics in any note that mentions Perl gratuitously. It's a pure strawman, trying to divert attention from what matters. You know I use Perl, so people constantly bring it up in the most ludicrous of circumstances. That's bullshit.
Suppose you knew that I happen to eat [insert your most hated food], refuse to eat [insert your most beloved food], and consistently vote for [insert your most hated political party]. I would not deal with notes that brought these up, either.
One initial comment: I won't answer to generic anti-GUI rants. I will answer to any criticism as soon as it is applied to KDE.
Why? Isn't KDE a GUI?
Here's a specific one for you: have you fixed the KDE bug where you forget to look at the user's stty characteristics to determine editing keys? For example, if I have said stty erase ^H, you don't make me find a stupid DEL key anymore, do you? And what about my werase char? Have you fixed the KDE bug where it doesn't honor ^W correctly?
Don't hold against us creating a tool that's better than the ones you have.
You have a peculiar definition of "better". It seems to be connected to imperial fiat.
If your tool is so awesome, please tell me the correct value for HERE below:
$ find HERE -type f -print | xargs grep 'pattern'
And please assure me that its output is consistent and uniform in internal formatting. If you've got some in HTML, some in that info crap, some in troff, and some in text, you lose.
Still, the initial question of this thread is a good one: Who is still dual booting/using M$, and how often?
People who never bothered to learn how to get what they wanted to do done on their own. The only possible reason I can conceive of for using Microsoft is lack of personal programming prowess, inadequate imagination or TUITs, or unfamiliarity with existing alternatives. I really do not understand why a programmer would ever touch it. After all, programmers solve their own problems.
BTW Tom, when Larry Wall came through Chicago this summer, he was good enough to stop by the local Perl Mongers meeting and give us some tips. When can we expect you to grace us with your presence?
Gracefullness is probably not one of my primary Attributes.:-) The probable answer is when I'm in the area. Considering that I grew up in the Chicago area (well, loosely: Lake Geneva, just down the street from Gary Gygax (whom I worked for), if that means anything to anyone anymore) and necessarily return there several times a year puts your chances higher than other groups' chances of the same. Send mail if you'd like to hear me talk, and upon which topic.
Porting to a CLI is a very important issue. It allows someone to use this body of work in ways undreamt of by the author. This is something that GUI-laden are notably lacking in due to their standalone natures.
The "GUIs Considered Harmful" sketch from 1992 ran like this:
I am increasingly troubled by how many new applications are designed to work solely under a GUI. While this may make some amount of sense for people coming from the PC or Mac worlds, one of the strengths of Unix has always been the ability to use it from anywhere. These people don't seem to understand this.
Of how much ultimate utility is that nifty new spreadsheet, editor, or debugger if I can't dialup from the field and run it on my vt100? Too often a tool that "does windows" is little more than a marketing gimmick to dazzle impressionable users into not noticing that they don't have the real functionality they need.
GUI-minded programs seldom lend themselves to being used as components in larger tools. As such, they do not fit well into the UNIX tool-and-filter philosophy. Instead of each being a single program that modestly attempts to do one thing well, they are a throwback to the Bad Old Days when each program was a standalone, monolithic monster that didn't interface with anything else.
It's all well and good to place a GUI wrapper around an existing tool, but to design a new application with only a GUI interface in mind is to forever limit that tool's flexibility. After all, how to you write a shell script that drives an automated xrn session?
Providing programmability for the fancy graphics software remains an open problem. The most effective use of GUIs in UNIX environments is to design the nitty-gritty computational function as a "back end" that can be driven either manually or automatically.
The GUI wrapper should be a separable module. If they're plug-replaceable, the application isn't irretrievably wedded to any specific GUI technology, such as SunView, NeWS, or even X11 or its children, like Open Look or Motif. Sending standard commands down a pipe the way the STDWIN or wafe packages behave is also a reasonable approach.
This means your program should be runnable both with and without the GUI present, and accept input from a mouse or under programmed control. Preferably that means both a shell-level interface for convenience and a C-level interface for efficiency; Perl programmers could elect either method. That way, naive users can use push-button GUIs, blind users can use Braille terminals, and sophisticated users can program solutions to intricate problems.
It has been noted that GUIs make simple things simple, and complex ones impossible. Certainly it is worthwhile to make simple things simple. But too often software is geared to only one level of expertise. That which is novice-friendly is too frequently expert-hostile, and vice versa. Being needlessly forced to click the mouse over a menu will slow down the expert user who is more comfortable with a keyboard interface.
Gratuitous distractions from the keyboard only slow down the experienced user. A precision pointing device that didn't require taking your hands off the keyboard would help. There are cases where only a GUI makes sense, like a CAD system. Being able to delineate a region or draw a figure with a mouse is probably a reasonable use for it, but selection of a range of possibilities isn't, at least not after you've become familiar with the tool.
Those are general GUI issues, but I get the feeling that some of this persists in KDE--and specifically in its documetation system. In particular, you didn't start with a CLI substrate, which means you have failed to provide a tool that can be used as a component to create cool new toys with. Is this accurate?
The principal problem that I see with anything like "KDEhelp" is that it's domain-specific. Imagine if for each new software suite, which we'll call FOO, that you had to use FOOhelp to access. When the BAR suite is issued, you'll therefore have to use BARhelp to access. It's cerainly bad that FOOhelp doesn't find the BAR project's stuff and BARhelp can't access the FOO project's stuff. The offer of backwards compatibility would at first seem to less the blow. That is, if the newer BARhelp could access the older FOO system. But honestly, it's little consolation. Users still need to learn to type different commands. It's not a good strategy.
I hardly allege that the Unix documentation system is the answer to all man's problems. But inventing new documentation access mechanisms for each project is not something which scales. This is obvious. Why it not only exists but persists is unclear.
What about the Gnome project's documentation? Does KDEhelp find that? What about the Imlib functions? Does it find documentation for them, too?
I really do hope that the world begins to see that this is a severe problem.
Slashdot Mirror
Not counting strange experiences of the PDP-11 and RSTS/E kind in the late 70s, by the time I hit the net in the early 80s, my peer group had already passed the BBS scene by light years. You see, we had the Internet. We had Usenet and Internet mailing lists, so we already had plenty of non-real-time discussion forums. For file exchange, we'd just compress, uuencode, shar, them and mail them to each other. For file archive repositories, we just used ftp. And for real-time, well, it started with talk, then moved on to ytalk, and some folks eventually got stuck in IRC, muds, and the like. I'd talk to friends around the country in real time, leave messages for them over night, all the things we do today. There was no cause for a BBS.
What I'm saying is that the reason you don't have garage-style BBSes much anymore is that the Internet renders them redundant. And I point out that for the community that was already on the Internet back in the 80s, we saw no reason to bother with the small and localized world. Now, not everyone was a major arpanet hub with its own imp, so the Internet came later to users than to us Unix programmers who were lucky enough to be on the real Internet back before it got invaded. But even after the invasion, one could always find one's own clique somewhere.
Look at what happened to "mass-market" BBS style access providers, like Prodigy and Compuserve. Once the real internet hit the masses, nobody wanted a closed world. You see, given a large and open world, you can create closed pockets. But you can't go the other way around. If you start out cut-off and closed, there you say.
I think what may be happening is that it doesn't understand the linking conventions in the man trees. /usr/local/man/man1/ssh.1 is a symlink to /usr/local/man/man1/ssh1. It omits ssh, and shows only ssh1. But it does manage dlclose(3), which is symlinked to the dlopen(3) manpage, so many that's not it.
Then fix it. This is easy, and it's obviously the right thing to go the other way. You've never heard of "standard part of the operating system" versus "add-on stuff"? What are you, an rpm(1) victim?While I'm on the subject, you don't seem to pay attention to ^C to interrupt programs. Don't make me find stupid happicons. This is as bad as lynx. ^C means interrupt.
No, no, no. A THOUSAND TIMES, NO!. Control-C is interrupt current activity. Why would I ever use it be an alternative to the middle button? This is super nonintuitive. I know what ^C does, because I set it up with stty(1). This is so Unix-hostile! Wrong. If you have something in the space already, and something in your cut buffer, you need to clear it first before you paste. Look at Netscape's ALT-F find command. If the program isn't requiring keyboard input, it should use the regular keyboard for its actions, so a slash in kdehelp, etc. You could use Meta-/ or whatever if you were in keyboard input mode already. Where? Don't tell me "see the control center". I hate that. I have to search for everything. Why can't we be given a simple but discrete command to type in, or a discrete file name to edit? Why must we always poke around randomly till we find something? This is completely Unix hostile. I've explained this to you before. I already told the system my preferences. Respect them. Where is that? PLEASE TELL ME THE COMMAND. I spent a long time searching through every fricking one of those blasted menus. I DID NOT FNID IT. Give me a discrete command, or a discrete filename. I did your search. I wasted 10 minutes of my life. This is worse than UUCP routing. This is random walking, hoping it will get there someday. Think how much better user@host is. It's discrete. I don't have to poke. Just tell me where something is. Why do you think I want to search? You just made me lose 10 minutes of my life because you can't specify how to do something in a precise, point-to-point fashion. At best you would say "first go here, then go there, then go there, then do this". That's crazy. Makes you want to kick the monitor. Is this Microsoft's fault, too? Then name it the right thing. It is not the kdehelp window. It's its find window. Different, you know. Yes, please do see it. And see my response.This is extremely Unix-hostile. Can you really not make your Windows rewrite without kicking sand in the faces of Unix programmers? This makes no sense.
- When it starts up, it doesn't choose a large enough window to display all the columns, so you must immediately resize it.
- It complete ignores attempts to divine its version number. ktop -v, ktop -h, ktop -version, and ktop --version all are completely ignored. That is, it just pretends you didn't give it any options, accepting those that it didn't understand. This is simply brain-damaged and wrong; call it a bug.
- The column for SHARE always has 0 in it. Regular top(1) produces correct output on the same system, so it's not as though that information were unavailable. This is obviously a bug.
- The screen refresh is set to epileptic strobe mode. It clears the whole thing and rewrites everything, even though it doesn't have to. Just set it to fast update, and you'll feel start to get a really bad headache. This is not evolution; this devolution. Regular top(1) knows better than to do this to you. Only update the things that have changed! And don't clear it all first.
- After running for a while, I got this: And the program proceeded to die of a SIGABORT.
- The thing would often splat a zillion copies of on the eterm(1) that launched it.
- I couldn't find anyway to use the keyboard to get to the buttons at the buttom, like "show tree", "all processes", "refresh now", and "kill task".
- In regular top(1), you can use the space bar for an immediate refresh; that is, to get the next screen as you would in more(1) or less(1). You can't do that here. Why did you omit this simple intuitive interface?
- The default kill(2) signal down on the bottom is a SIGKILL. That's not a good idea! You should default to SIGTERM, just as kill(1) does. Save the big stick for a last resort.
- The happy little icons next to the program name doesn't seem useful. The bitmaps must have made sense to someone, but by and large, most of them mean nothing to me. And they're too small to read in many cases. Plus you can't even sort on them. And the dumb program uses some little blue sunburst for anything it doesn't know about. That's useless eyecandy. How do you turn those silly things off?
- Many of the commands had no string listed for their command line column. This is a bug.
- I couldn't seem to manipulate the menus using the normal keyboard as promised. I can hit ALT-R to get the Refresh-Rate menu, but then it offers things I can't get at. It suggests "Manual Refresh", "Slow Refresh", "Medium Refresh", and "Fast Refresh". But there's no underlined letter to tell me what to type. I tried M, S, and F, but that did me no good. I could type ENTER, but not ^M or ^J. And I couldn't move up and down the menu using either vi(1) or emacs(1) navigation sequences: j and k were ignored, as were ^N and ^P.
- You could only select one process at a time. This makes it impossible to send a signal to several processes at once.
- If you turn on tree mode, you can collapse and expand hierarchies. If you selected the collapsed node, such as an entire process group, and send a signal, it still just uses a single kill(2) on the top process rather than a multicast kill(2) to all of them, or perhaps better, a killpg(2). I couldn't figure out how to get process groups to even display, let alone how to affect them.
- You have to use ALT-P to get at the process killing list. A simple `k' would be much easier, and more intuitive. How do I create that shortcut?
- After an ALT-R or ALT-P or whatever, my focus is held prisoner, locked to the menu selection. That's quite rude. Definitely a bug.
- The signal list that ALT-P provides you is very limited. It only allows SIG{INT,QUIT,TERM,KILL,USR[12]}. Last I checked, there were plenty of other signals, including highly useful ones like SIGHUP. It doesn't allow you to type in a signal name or even signal number.
- The signal list that ALT-P provides you has incorrect expanatory text.
- It claims that SIGINT is a Control-C. Well, maybe. Actually, Control-C is going to do the whole process group, and this isn't. Also, it ignores my stty(1) settings again. I tested this like so: stty intr ^g; ktop But the message still said that SIGINT was Control-C. That would be wrong.
- It claims a SIGQUIT is a "core". Huh? Do you really think that means something to people? Anyway, it's wrong. I always run setrlimit(2)ed to 0. So some things certainly wouldn't core. Also, setuid(2) programs wouldn't core, either, or that would be a security problem. In any event, it's hardly the only signal that normally generates a core dump. So do SIGILL, SIGTRAP, SIGABRT, SIGEMT, SIGFPE, SIGBUS, SIGSEGV, and SIGSYS--according to my signal(3) manpage.
- The note for SIGTERM is "term."--how useful! Is that the best you can do?
- The note for SIGKILL is "term."--hold on! That's the same as the previous note's. This is wrong.
- You should use real signals with real explanations. Here's from the manpage:
- What about an option to kill insistently? You know, send a polite SIGTERM or SIGHUP, give it some time, and if that doesn't work, send it a SIGKILL.
- There's no search mechansism. It would be nice to be able to apply a filter expression, like to select only certain command names. If you wanted to make it really useful, you'll permit a filter that took a real expression, such as:
- ALT-H takes me to the misnamed "File" menu, not the "Help" menu that the display would lead you to believe.
- What is "quit program" doing in the File menu? What does exiting a program have to do with accessing files? This makes no sense at all. Why isn't it just ALT-X for eXit, or ALT-Q for Quit? Why is it ALT for anything? The program isn't doing anything else with those keystrokes. Just skip the ALT entirely.
- When you use Kill Task, it pops up an annoying confirmation window. That's bad enough, but it has the audacity to force you to drag your mouse up to the window, because it doesn't have the focus. You definitely have lots of incorrect focus problems in KDE, you know. And even once you're there, you have to use the mouse, because the keyboard is useless. You can't use C for continue or A for abort. You have to use the damned mouse. Put the thing in focus, and let me type. Sheesh!
- These stupid confirmation windows are unESCable. At least the ALT-x menus pay attention to that. This is inconsistent. Screw the confirmation windows. If I wanted my hand held, I'd be on a date, not a computer.
As you see, ktop is not as useful as even good old top(1) is, and is much harder to work with. I think it's pretty obvious that this program, like kdehelp(1), isn't ready for prime time. I find that every one of these KDE GUI things are much better at impressing people who don't have to use them. And those that are copies of existing tools always seem prettier but less functional than the originals. Who cares about pretty if it doesn't get the job done? What I'm saying is that they've paid a lot more attention to chrome than to power. This is why you need usability testing.I did finally find something it paid a small about of attention to: ktop --help. But that wasn't very helpful:
What are "kdeopts"? Where am I supposed to learn about them?Even if you were do that for only those four signals you permitted, it would still be better.
Is there any technical treatise enumerating the relative merits (well, and demerits :-) of KDE versus Gnome? I don't want a flame fest where some advocate bashes the other group. I mean something reasonably neutral but highly technical.
You don't have to use negative flash words. They make your audience stop listening, because they trigger too much hostility. And if you make some irritable, it's difficult to discuss matters with them. Try talking to Microsoft employee and always use the word "legacy" or "primitive" in tandem with "Windows" and see how far it gets you.
Just because you can use keystrokes doesn't mean you can know where things are a priori, nor that you can search for them. Consider my example of "KDE Control Center"/"Windows"/"Mouse" versus "KDE Control Center"/"Input Devices"/"Mouse". You could say those aren't pop-up menus, but they're really effectively the same thing and suffer from the same problems.
Looks like I forgot one. Roberto kept asking where KDE cares about manual orientation in its messages to the user. Now, I'm not really sure whether you consider KDE the toolkit, the window manager, the programs, or what. But running a KDE desktop, the following situation arise.
The "left button" nomenclature is on the "KDE Control Center", then under the "Windows" submenu, then under the "Mouse" submenu. Even once you have gone to "KDE Control Center", then to the "Input Devices" submenu, then finally to the "Mouse" submenu underneath that, you'll find that switching between left and right handedness in no way alters what the other Mouse menu says. It's not immediately obvious why you have more than one Mouse menu. It certainly took a while to find that what button did what was on the "KDE Control Center"/"Windows"/"Mouse" menu, but that the manual orientation was controlled by the completely different and unconnected "KDE Control Center"/"Input Devices"/"Mouse" menu. And there's no way to find it other than slow, recursive, linear search. That's why you need to have some way to search a menu tree quickly and efficiently. If I could have just typed something like /handed and it had whisked me off to the right subsubmenu, this would have saved me a lot of time.
- The File/Edit/Goto/Bookmarks/Options menu bar doesn't make any sense. To make a new help window, you have to go to File. What does that have to do with a file? Likewise to search. I mean, honestly -- what are you thinking? This is a general problem in all the KDE stuff I looked at. You keep putting things in really non-intuitive categories. I mean, get serious: you've got "System", "Settings", and "KDE Control Center". Those make no sense to me. Why are some programs in one of those categories, but not another? What's the difference? "Applications", "Utilities", and "Internet". How am I supposed to look one place and not another? What's the difference between a program that's an "application" and a "utility"? And what about "Graphics", "Multimedia", and "Internet". Why aren't the graphical programs under Multimedia? Why is local user information (finger config) listed under "Internet"? Don't tell me "oh, you can edit those". The defaults should be sensible. These aren't.
- There's a "search" under File, but then a "find" under Edit. Why is there even an Edit button? How can I edit anything in static documents?
- Also under the File menu is some "Close" command. But when I used it, it didn't close the file I was viewing, which is what you expect a "File/Close" command to do. The other meaning of close, iconify, was actually what I was expecting. But guess what, the KDEhelp wasn't iconified. It was completely destroyed without warning or confirmation! You should choose a better word there. People who use the word "close" to mean iconify will keep killing things. On the other hand, "Destroy" (or perhaps better, "Exit") and "Iconify" aren't ambiguous.
- The next line, the one with happy icons on it, is not intuitive. How do you disable the pictures and turn on just the words, the way you can in netscape?
- It appears that you use the same happy icon in the KDEhelp window to indicate "reload current document" as you use in another menu to "rearrange icons". What the devil is this overloading about? This cryptohieroglyphic system doesn't help anyone at all. What does that bitmap mean? Why does it mean something totally different elsewhere? Why aren't there words?
- You can't use the regular keyboard for paging activity. I tried everything I knew. I used SPACE, BACKSPACE, ^F, ^D, ^B, ^U, B, F, b, f, ^J. Nothing works. This is not intuitive. How do I make it follow the conventions of less(1)? Even netscape recognizes space and backspace for going back and forth by a screenfull. This is what I mean about discriminating against people who can actually touch type.
- The cut-and-paste system doesn't by default work like xterm. How do I change that setting? The reason I need to do this is because your defaults are very week, but less powerful than I'm use to. It doesn't seem to follow the model of index-finger clicking once for a character, twice for a word, and thrice for a line. Even netscape can do this. Why can't you? And once you've grabbed a word (for example) you can't use the ring-finger click to delineate the word at the other end.
- In KDEhelp, you make the user guess whether something is, whether it's in man, kde, or info format. How is the user supposed to know? That's not nice.
- The presentation of available man stuff is just nowhere near reasonable. For example, choose section 1. You get a zillion names of commands. 964 of them, in fact. I can't visually search a thousand different things like that.
- You don't provide the whatis description of each man entry in that listing. That means the user has no way to guess what the page is about. That information is important.
- When it comes to choosing a section, you ignore both the users MANPATH setting and the operating system's default. That means you can't find, for example, ssh which is in
/usr/local/man. settings from the /etc/man.config file. (Actually, that file's name and syntax varies depending on your operating system, even within the family of operating system. Redhat Linux puts it under name, SuSE Linux puts it another name, and Debian Linux puts it in a different name still. And these actually have different parses, too. E2MANYLINUCES. Sheesh. But they're not alone. FreeBSD has its own notion of where to put the config file and how it parses, and this is different OpenBSD's notion of the same. And please don't talk to me about Solaris.) But the point remains that you have to respect the local configuration, or else you aren't actually doing what you say you are. - The output format is alphabetized on the X axis instead of on the Y axis the way it should be for convenient reading. People want to read down columns, not across rows. Why? Because it's a lot faster. If you keep going across the rows, you have to do a carriage return with your eye constantly. It's all back and forth and back and forth and back and forth. But going down the columns, you don't have to do that.
- So, your program doesn't understand man trees, whether in MANPATH or in the system config file. This is a problem, because you can't tell which mantree the hits came from. Also, you aren't able to limit you search to just locally installed stuff versus the standard operating system, etc.
- On the "Keyword Search", on the other hand, it does seem to respect your local conventions. It's also quite fast. I'll bet that's because it's just running apropos directly, which is more clever by half.
- The "Keyword Search" takes forever (ok, a very long time) when specify KDE documentation. Once again, you make people know where things should be.
- The documentation search, when you specify manpages, doesn't distinguish between the whatis database and the raw data. How do I say which one I mean?
- You do not provide a "word boundary only" search option. You don't tell people whether they can use a pattern match, but even if they can, would that be a \ or \bword\b?
- The return list is not helpful. It is not sorted in any understandable fashion. It does not show any of the line or sentence that matched. It contains redundancies. For example, one set of returns looked like this: But those are not really to the same places. They just have the same title. It looks like they did a full body search, but I can't tell.
- When you follow one of those links and return via the left arrow (hey, how does that play in right-to-left reading places?), it runs the whole damn slow search again! This is nutty. The KDEhelp window should cache those results. And why does it do a manual search anyway? Why don't you have a quickly searchable text corpus database index that's pre-generated by the system?
- When you hit the left-arrow to return to your search, you have lost the string that you were searching for. It's gone from that window. In fact, so are the button settings.
- I sometimes managed to get the Search window in some state where I couldn't just hit ENTER to launch the search, but had to use the silly mouse to push a button. I didn't figure out how to reproduce that consistently.
- In the Search window, you're sitting there typing something, and you hit ^W to back up a word (those are in my stty settings). Guess what? IT DESTROYS THE WHOLE WINDOW! Did you hear what I just said!? You don't get asked permission. It just destroys it. You lose all your state, your forward-back list, and your sunny and pleasant disposition. This is completely evil.
- I've tried to mouse grab from the KDEhelp window and paste it into the Find window. But I can't do that. It seems to have its own separate buffer system. This is very confusing.
- There's no "Clear" on the Find window to help with cut and paste.
- When you want to do a search, you have to hit ^F. How do I make that be a slash instead?
- When the find window pops up, it doesn't have the focus. Instead, you have to searching for it with the mouse. That's a waste.
- You can't use your normal editing characters in that little box it gives you. I tried ^U (my kill character), but was ignored. I tried ^W (my werase character), but was also ignored.
- If you already have a "Find" window up, but it's exposed, you don't realize this. You sit there in the KDEhelp window hitting ^F again and again, but absolutely nothing happens. There's no new find window that appears, no beeping, no flashing, and no raising of the existing window that you don't even know is open.
- The Find window is named "kdehelp". That's what shows up in the title bar and in the icon manager. That's not a good name, because it's not really the kdehelp window. It's a transient Find window managed by KDEhelp. Why is it even showing up there in the icon manager?
- When a Find fails, it pops up a "Find Complete" confirmation window. And this one is also without the focus, so you have to go chase it down with the mouse. That's crazy. You have nothing else to do. It should have the focus. You can try scrolling the KDE help window on your own, but it completely ignores you. It refused to do anything until you take your mouse and attack the Find Complete window. With a vengeance.
Consider this a bug report. The operating system is Red Hat Linux release 6.0 (Hedwig) , standard installation. I couldn't figure out how to report KDE's version: But it was the standard Redhat OS from VA, so you should be able to guess.While we're at it, what is that X11 stuff doing in /usr/bin? You aren't supposed to do that, you know. Otherwise you make non-X11 people suffer the search costs that they don't need. Help, /usr/bin has more than 1400 entries in it on this Redhat OS from VA. Somebody wasn't thinking: Linux is notoriously bad with large directories. Please don't contribute to this problem.
No, that's not enough. I regularly enable/disable and change proxies on the fly. It's a very common operation for me. There's no reason to reboot netscape just to do that. Nor should I be forced to navigate the same set of hand-holding menus every time. I know what I want, and it won't let me get there without negotiating its speedbump system.
Note that I'm not saying which form it should be in. But the lack of consistency is what makes it hard on programmers to deal with.
The point remains that a hodgepodge system is not as amenable to uniform, tool-based manipulation as is an integrated, homogeneous system. You may call that flamebait if you will, but it does not alter this fact.
Once we've done that, we start adding in mood. "If only he weren't so ignoraretur!" :-)
Fetch the raw document with wget or lynx -source, or from netscape do a "view source" on that page. Now, look at the javascript gunkola at the top. They assume that if you're not running Linux, and you're not running Windows, then you must obviously be running a Mac! That's hilarious.
I'm sure you can talk about Linux-based operating systems without triggering the hostility inherent in that utterly ridiculous appelation you were using. It would really help a lot.
thanks,
In case you missed here, here's an example of the problem. Consider how to disable the proxy for netscape. You have to click through a bunch of menus, each and every time. It drives you nuts when you realize if they had merely included a way to let you type something, you could have said "no proxy" or "set proxy=off" or whatever. But no, the keyboard is to be avoided and the mouse is to be worshipped. Of course, they lose there, too, because eventually they make you type the host and port for the proxy. It would have been a lot easier to type "set proxy=host:port" ab initio.
Here's an example of the problem. Consider how to disable the proxy for netscape. You have to click through a bunch of menus, each and every time. It drives you nuts when you realize if they had merely included a way to let you type something, you could have said "no proxy" or "set proxy=off" or whatever. But no, the keyboard is to be avoided and the mouse is to be worshipped. Of course, they lose there, too, because eventually they make you type the host and port for the proxy. It would have been a lot easier to type "set proxy=host:port" ab initio.
Suppose you knew that I happen to eat [insert your most hated food], refuse to eat [insert your most beloved food], and consistently vote for [insert your most hated political party]. I would not deal with notes that brought these up, either.
Here's a specific one for you: have you fixed the KDE bug where you forget to look at the user's stty characteristics to determine editing keys? For example, if I have said stty erase ^H, you don't make me find a stupid DEL key anymore, do you? And what about my werase char? Have you fixed the KDE bug where it doesn't honor ^W correctly?
You have a peculiar definition of "better". It seems to be connected to imperial fiat.The "GUIs Considered Harmful" sketch from 1992 ran like this:
Those are general GUI issues, but I get the feeling that some of this persists in KDE--and specifically in its documetation system. In particular, you didn't start with a CLI substrate, which means you have failed to provide a tool that can be used as a component to create cool new toys with. Is this accurate?
The principal problem that I see with anything like "KDEhelp" is that it's domain-specific. Imagine if for each new software suite, which we'll call FOO, that you had to use FOOhelp to access. When the BAR suite is issued, you'll therefore have to use BARhelp to access. It's cerainly bad that FOOhelp doesn't find the BAR project's stuff and BARhelp can't access the FOO project's stuff. The offer of backwards compatibility would at first seem to less the blow. That is, if the newer BARhelp could access the older FOO system. But honestly, it's little consolation. Users still need to learn to type different commands. It's not a good strategy.
I hardly allege that the Unix documentation system is the answer to all man's problems. But inventing new documentation access mechanisms for each project is not something which scales. This is obvious. Why it not only exists but persists is unclear.
What about the Gnome project's documentation? Does KDEhelp find that? What about the Imlib functions? Does it find documentation for them, too?
I really do hope that the world begins to see that this is a severe problem.