Interview: KDE Developers Answer Your Questions

Last week, Microsoft and antritrust. This week, thoughts on KDE's future from some of the people who work directly on it, specifically Kurt Granroth and Richard Moore. Instead of posting their e-mail addresses here and swamping them with messages, please see http://developer.kde.org, which will tell you not only how you can contact these gentlemen, but much more about KDE development.

Before we get down to business, we'd like to stress that these are the opinions of individual KDE developers. The answers below are not *necessarily* the same as the KDE Official Position on matters. If you wish to know THE official opinion on any of these, contact the KDE Core Team through any of the official representatives.

Now that's out of the way, so here we go:

1) by joshv
One of the biggest limiting factors that stops me from moving to Linux for 100% of my computer use is the poor support for MSOffice file formats in Linux Office apps.

What level of support will KOffice provide for MSOffice file formats?

Kurt Granroth answers:
The level of support is entirely dictated by how much support the filter authors are willing to do. I can guarantee that we won't have 100% compliance with Office97 formats if only because it's not possible to get the complete specs for all the formats. My personal feeling is that we will have support for the most common parts of Word97, Excel97, and Powerpoint97 for KOffice 1.0 (or soon after) but the more esoteric features will be lacking.

As I said, though, it's entirely up to those who are actually writing the filters. If somebody (or several somebodies) jump into filter writing fulltime, then it's entirely possible that we will have the best filters in the Unix world. We'll have to see what happens...

2) by jd
There are a number of competing environments in X, now, such as KDE and Gnome. In addition to that, there are emerging whole new windowing systems, such as Berlin. Add a sprinkling of GGI, KGI and EvStack for good measure, and you've a real gloopy mixture of ideas and strategies.

In light of this, where do you see the desktop in, say, 5 or 10 years time?

Richard Moore answers:
I think the X environments will become much more interoperable as standards are defined for functionality such as .desktop files, drag and drop and the capabilities of modern window managers. The standards around at the time the KDE project started (such as the ICCM standard) do not define these service. Now that there are some real standards being defined (and implemented) such as XDND and the new window manager specification the diversity of X can be made a strength rather than a weakness.

Developments such as Berlin and GGI are interesting, but they are not really much of a concern to KDE. As these projects become more mature it may be worth porting our code, but for now this is not a priority. One of the advantages of writing highly object oriented code (and using a cross-platform framework such as Qt) is that it is very easy to port, and should the need arise this would not be problem. However as X is improving anyway, especially with the current developments in XFree86 such as GLX support (hardware accelerated 3d) the arguments for a new windowing system are not very strong.

Over the next few years I expect to see evolutionary, rather than revolutionary changes to the desktop. As usual there will be lots of new ideas around, but only some of them will stand the test of time. I think there is likely to be much more emphasis on the 'look' of the desktop, and on improving the ways data is presented. Some trends such as greater use of multimedia, more 3d, more use of transparency are likely to continue, but it is hard to say what else will be around.

Kurt Granroth answers:
Personally? I don't think it will be significantly different. I know that there is a tempation to say that in 5 years, the desktop metaphor that we currently use will be dead and we'll have some radical new approach. Well, I don't believe it. "Normal" people really aren't very willing to change what they are comfortable with.. and they are now comfortable with the desktop approach. Any changes that happen will have to happen gradually over a period of time.

Now whatever happens, I'm sure KDE will roll with the change. With only a few exceptions, our API is pretty well abstracted from the graphics layer. Say the next big thing is an OpenGL 3-D graphics background (is that what Berlin is?) -- all KDE needs to do is convert a few parts of the base Qt library and we'd be good to go on the new backend.

3) by Jon Trowbridge
What are your thoughts on both the current status and the future of interoperability between KDE and Gnome in areas like components, CORBA, etc.

Do you see the two projects moving closer together, moving further apart, or staying about the same?

Richard Moore answers:
There are some areas where cooperation between KDE and Gnome is possible, and others where it is more trouble than it is worth. There has already been good progress to produce standards for .desktop files and window manager hints. The functionality needed for these is well understood making them relatively easy to standardise from a technical point of view. It is less obvious how more complex technologies such as component embedding and reuse can be defined in a usable standard. That said however several KDE apps have been ported to Gnome and when we release KOffice, KDE 2.0 etc. I imagine they will want to try to embed our components - if they can get it to work they are welcome to. I don't really see the projects moving closer together though as we have very different ideas about how the desktop should work.

Kurt Granroth answers:
Please see my answer to question #7.

4) by Zarniwoop
What do you plan to support in Konqueror, ie CSS, Java, HTML type, and will it function as a file manager or will KFM still have that function?

Richard Moore answers:
Konqueror is using Lars Knoll's new DOM based HTML component - it already supports almost all of HTML 4.0. Support for Javascript is progressing, though the DOM bindings are unfinished as is support for CSS, both of these are under active development and will probably be ready for KDE 2.0 (though not for the Krash release). Java support is partially complete - most simple applets now work, but there is currently no support for applets in JAR or ZIP files. In addition it is now possible to create plugins for Konqueror that can further extend its functionality - in future there may even be a bridge that allows the use of Netscape plugins!

In addition to being a web browser, Konqueror can do a lot more - it is able to embed different types of view using the new KParts framework (briefly known as Canossa). This means that it is possible to view any type of content (eg. text files, postscript, DVI files etc.) within Konqueror. The views are loaded and unloaded as needed which keeps the browser itself nice and lightweight. A view doesn't just embed the content - it also has access to the menu and status bars, drag and drop etc.

The file management component is embedded in Konqueror, so to a user it works in much the same as with the old KFM did, only better. The file view has been completely rewritten and now provides a much more polished user interface, for example you can have multiple views and you can load and save workspace layouts. As before the files are accessed using kioslaves allowing you to transparently access both local and remote files. The ioslave code has been rewritten to improve performance and to make it easy to add new protocols. There are a number of new protocols already implemented (such as SMB a.k.a. MS Windows shares) and also extensions to the existing protocols (such as SSL support).

Kurt Granroth answers:
Konqueror is a generic browser -- it has the capability to browse almost any medium that it has a component for. That is, with our treeview and iconview (and similar) parts, we can use Konqueror as a file manager. With the helpcenter component, we can browse help files (html, man, and info). With the kghostview component, we can "browse" postscript and PDF files.

And with the html part, we can browse the web. This component is clearly the one that gets the most attention -- and deservedly so! We (mostly Lars Knoll, though) are working on an HTML library that is fully HTML 4.0 compliant. It is already pretty darn close. We use DOM Level 1 as our document model and should have some parts of Level 2 in by KDE 2.0. We will surely have support for CSS1 and *maybe* support for parts of CSS2. We already have minimal support for Java applets and Javascript.. and the capabilities of both will increase by KDE 2.0. In the case of Javascript, we should be able to handle 90% of the most common pages on the web.

Hmm.. I think we'll have some support for parsing xhtml and embedded XML, also.

Konqueror is essentially the next generation KFM, BTW. It does everything KFM could do.. and tons more! Furthermore, it does it much faster and using much less memory.

5) by Kris Warkentin
I've heard that KDE 2.0 will be using a new window manager KWin rather than KWM. Now I know that KWM is a big fat hog but I haven't been able to find much info about KWin. What are the advantages to this new window manager? Is it an evolution from KWM or a completely new, from the ground up program?

Kurt Granroth answers:
KWin is a new, from the ground up, program. It is written to be more modular and extendible and to have theming and MDI capability built-in (kind of.. see below). It is also a tiny bit better with memory.

The 'theming', BTW, is pretty cool because, technically, KWin doesn't do theming at all! KWin is really just a window manager library that you can build a window manager on top of. When you write a 'theme' for it, you are (in ways) really creating your own window manager with that particular look. This means that you aren't limited at *all* to the inherent theming capabilities of the wm if you are willing to do a little programming. And I do mean "a little" programming -- the BeOS example style is less than 200 lines of very easy to understand code.

However, I take exception to calling kwm a "big fat hog". If you use kwm with KDE, then it is no more memory intensive then any other modern window manager. In my experience, kwm is as fast and light as any other full-featured window manager out there.

6) by Otter
When designing KDE, what is the minimal hardware quality you expect it to run comfortably on? Is it currently available low-end, one year old low-end, three year old low-end...?

Kurt Granroth answers:
Well, whenever I recommend computer systems these days, I always insist on at least 64M memory, a 6G hard drive, and a 366Mhz system. That said, we made sure that KDE will run on significantly less then that :-)

The consensus seems to be that 32M is the minimum that you could comfortably use. You could use less.. but then you'd have trouble with just bare X, much less KDE. Hard drive size and processor speed shouldn't be a major factor at all. Video cards shouldn't play a significant role, either. We now ship high color (24-bit) icons.. but we won't drop the 8-bit icons until we're sure that all 8-bit cards are gone.

Keep in mind that the above recommendations are for the x86 platform. You may need to adjust the numbers when referring to, say, SPARC or Alpha chips.

7) by TheGreek
Has the long-standing flamewar between KDE and GNOME helped to motivate development of a better product, or has it just made you annoyed at the community at large?

Richard Moore answers:
No.

Kurt Granroth answers:
(This is also my answer to question #3)

It may suprise some people, but most KDE developers don't wake up every morning thinking about GNOME -- I know that *I* don't! In fact, I very rarely think of them at all. I spend my time thinking of, and working on KDE.

Do I think that the KDE and GNOME "war" has motivated a better product? No! I think the whole "competition makes for better products" thing is bunk. KDE developers work to make KDE the best that they can -- and they would be doing so even if GNOME didn't exist! KDE would be exactly where it is right now regardless of the status of GNOME.

Has the "war" made me annoyed at "the community"? At times in the past, I did get annoyed at those participating in the flamewars. I think it's incorrect to say that they are "the community", though. The fact that KDE has an overwhelming majority of Linux desktops shows that "the community" (if there is one) has been behind KDE all along. Those flaming KDE are easily dismissed.

Now all that said, I'm a big supporter of working together with GNOME to standardize as much low level things as possible. Let's face it, there are some nice apps coming out of the GNOME/Gtk camp and it would be a shame if they couldn't be easily integrated into the KDE desktop. I want to be able to use, say, xchat, gvim, or gimp and have them look, feel, and act as much as possible like my other KDE apps.

This means that what needs to be standardized is things like drag 'n drop, window manager "hints", file associations, menu structure, key bindings, themes, and the like. Work is already done or in progress on the first three listed and the last bunch look promising. On the themes note, I seriously doubt that we will have 100% compatibility between GNOME and KDE themes.. but we should get pretty close by having theme

8) by twdorris
I believe that one of the MAJOR problems facing *any* UNIX system wishing to compete on the desktop fr level printer driver support. It's been a while since I've coded X-apps, but from what I recall, there was no way to "cleanly" handle print functionality. By that I mean, I always ended up with one routine to draw to the screen and a completely separate routine to write my PostScript output for printing. I believe this may still be the case give how many different print interfaces I see in various applications running under Linux. No two user interfaces are the same and no two produce similar results. To an end user (at least at the desktop level), this is extremely frustrating and it's one of the main reasons I *have* to keep Windows around. I need to print things reliably and with a high degree of quality and there's just no clean, easy way to do that under Linux or any other UNIX OS for that matter.

As for device driver support, I've used Ghostscript extensively in the past and while it's impressive, it's a FAR, FAR cry from being comparable to a vendor-supplied, Windoze-based driver equivalent with regard to quality of output and reliable printing. As an example, try printing a high resolution image to an Epson Photo 700 under Windows and then do the same under Linux using Ghostscript. The two are completely different and it's not in favor of Ghostscript.

All this leads me to my question for you guys. I use KDE along with KWM as my working environment at home. How do you see printing functionality being affected or enhanced by KDE and do you have any suggestions for how to improve upon the current state of things? Is there a huge re-write of printing support under *nix systems that I don't know about and that most applications these days are being coded to? I strongly suspect so, because there's no way in hell Linux will be able to compete in the desktop market if every application is required to write out postscript data manually and/or include printer drivers for every printer known to man. Both Windows and Java take an approach to printer support that ties printing code to display code and I believe something similar is *really* needed under Linux and/or X11. Do you guys have a feel for what the future holds with regards to printer support under *nix systems? Having coded a complete office package yourselves, I'm sure you have a pretty good idea... :-)

Kurt Granroth answers:
There are a number of parts to the printing problem... and only a few can be solved at the KDE level. We actually have a very nice printing mechanism in KDE using the Qt library to do all the real work. If you've done any Windows programming, you'd see that it is *similar* to the way that MFC handles printing. Basically, we 'draw' onto objects with QPrinter and QPainter.. and really don't care if the final output medium is paper or a screen. All of that work is handled at the Qt level.

Specifically, Qt will render it up into postscript if the code is intended for paper (e.g, a printer). It then uses whatever printer drivers are available to do the actual printing.

This is where the differences between printing in Windows and printing in Linux start shining through. You are correct that on most low-end printers (i.e., non-laser), the output in Windows is *much* nicer. This is out of the control of KDE, however. The drivers need to work at the OS level.. and it's there that they need to get a lot better.

I believe that there is some work to get vendors to ship official drivers for Linux. If/when that happens, then all output from KDE apps will immediately see the improvement. The actual code in the apps won't have to change at all.

09) by Ledge Kindred
I don't follow KDE development extremely closely, but it seemed to me that details about Magellan popped into sight very suddenly and vanished again nearly as quickly. Considering the power and capabilities detailed in the article linked above, this sounds like a major component to having a devastatingly powerful desktop based on KDE2, since an easy-to-use EMail client like Magellan would fulfill one of the two basic "killer apps" I imagine an average user would want from a desktop environment. (The other being a decent web browser, which KDE2 looks to also provide with Konqueror.) Is development of Magellan still on track? Can we reasonably expect it to live up to expectations? Or is this considered an "out provide and therefore outside of what you can comment on?

Kurt Granroth answers:
Magellan isn't part of the KDE project... but we're glad to see it coming along. Third-party apps like Magellan, QCad, KDevelop, and KDEStudio are very valuable even if they aren't provided with the KDE core packages.

Now personal opinion time on Magellan: the screen shots look *very* nice and if it has all the functionality it claims.. well, I think there will be a lot of ex-Outlook users that will be very happy. That said, I've never actually seen it working or seen one line of code from it. The author certainly has the right to keep it all hidden before release.. but until it is, it's just vaporware with very pretty screenshots.

10) by Tom Christiansen
What non-Windows systems have you evaluated in mining existing technology for ideas? How about XEROX Star or OS/2 or Amigas? Have you ever looked at AVS, the scientific visualization graphical shell? It has (or had, when I long ago looked at it) a very cool graphical representation in which datasets and filters get connected in by pipelines in a visual rather than a CLI way, which is sometimes easier to produce. IF you haven't seen it, think of what it might be to combine drag-and-drop with connect-the-dots...

Kurt Granroth answers:
The systems we mine are those that we've used. So you can see elements of Windows, MacOS, NeXT, and traditional Unix desktops like CDE. We do try to emphasize the visual elements from Windows and MacOS because, let's face it, that's where the newbies are coming from and we want to make sure that they have a comfortable, intuitive environment to work in. It should be possible for an ex-Windows or ex-Mac user to sit down in front of a KDE workstation and figure out how to use it very quickly and with little or no help. It's possible that there are some OS/2 inspired elements in KDE, too.. but I don't think I'd recognize them if they were there (I haven't used OS/2 in years).

As for the 'connect-the-dots' approach.. I believe that various KDE apps are doing something in that vein. aRts does (or did). I could have sworn that there were more. We currently have no plans of doing this in the core KDE stuff.. but who knows what will happen after KDE 2.0

Actually, it's interesting that you mention AVS because we *did* have a rather extensive discussion about treating everything as graphical pipes about a year ago (I think). If my memory holds true, we decided that it's a great idea but we probably couldn't pull it off by KDE 2.0 if we wanted it to be stable, usable, and intuitive. Like I said, we'll see what happens after 2.0

Comments

Theming

[crivens]

It really annoys me when people get all excited about the theming capabilities of their software. I wish they wouldn't put such an emphasis on theming! Give me a leaner, meaner system without theming anyday!

Re:Theming

[mong]

I agree totally, it's like "Oh, we can do all this theming stuff, it's really cool - oh by the way, you can't "quite" run this app yet, becuase X part of Y is pretty buggy and need 256mb to run".

We use Linux and BSD here for practically ever server, and have it on some desktops also. But we (for example) need browsers that support ALL of HTML4, ALL of JavaScript and run ALL(or at least most) Java Applets.

Oh, and the KDE-Gnome compatibility thing... you're running the SAME OS, okay your products are different in appearence, and to some (small IMHO) extent, in operation - but surely the same apps should run on either? It's not quite the same (I know) but using for example the Litestep shell instead of the standard Explorer shell on Windows DOESN'T mean you can't run certain apps.

Basically, I think the whole situation is still fairly amateurish, there's a lot of skilled and professional people involved right now (I know some of them), but something is not quite clicking.

I want Linux/KDE/Gnome to be the successes they deserve to be (they really do), but it's not really gonna happen if the present system isn't re-evaluated.

Hmm, wonder what the COREL release will be like? ;)

Mong.

* Paul Madley ...Student, Artist, Techie - Geek *

Re:Theming

[ajs]

Give me a leaner, meaner system without theming anyday!

But, the complexity is in the widget set functionality, not in the theming! GNOME (can't speak to KDE much) bloats when you use a huge theme that involves lots of pixmaps, but you could use a minimalist theme that takes memory and speed into account, and get a much faster desktop.

When you see a cool, glitzy desktop with chrome edging to everything and starscape backgrounds in all of the windows, yes that's going to be a pig, but that's the user's choice, as well it should be.

I actually want more theming. I want to be able to chuck whole gobs of functionality out of the widget set, because I'm never going to want it. This is a hard problem, but one that I think would make theming much more powerful.

Integrated Web Browser?

[retep]

From the sounds of it the way KDE is integrating Konqueror with the web isn't much different then the way Windows includes IE. If Konqueror got good enough new users might never download Netscape or Mozilla. Just like many Windows users never bother to get Netscape. The only difference is Microsoft used quite a few nasty tactics to promote IE.

Deeply worried

[innerFire]

Over the next few years I expect to see evolutionary, rather than revolutionary changes to the desktop. As usual there will be lots of new ideas around, but only some of them will stand the test of time. I think there is likely to be much more emphasis on the 'look' of the desktop, and on improving the ways data is presented. Some trends such as greater use of multimedia, more 3d, more use of transparency are likely to continue, but it is hard to say what else will be around.

Translation: 'We're making it look better, because we already think it works as well as it could. The Windows paradigm is good enough, no sense coming up with new ideas.'

This kind of attitude is deeply worrying. No, the desktop metaphor is not perfect, in fact it has many flaws and weaknesses. (Check out About Face: The Essentials of user interface design by Alan Cooper for hints.) Something new needs to come along! KDE (and GNOME) are just rehashes of Windows 95, the same way CDE was a rehash of Windows 3.1. Do we really want for free software to be chasing the coattails of the lowest common denominator? I think we can do better.

Re:Deeply worried

[FPhlyer]

I think you missed the point of Mr. Moore's comments concerning the future of user interfaces. Let's say that we had a "revolutionary" change that takes us away from the current "desktop" paradigm. You have issues of the new system not being compliant with current APIs. With this, and the fact that programs might be displayed differently, you are going to loose tons of applications that currently run under X, KDE and GNOME.

An evolutionary change allows everybody to gradually move their applications and interfaces to new standards.

I agree that the "desktop" leaves much to be desired, but I think that it will be several more years before the average computer user's hardware will be ready for the next standard (which will probably be three dimensional with integrated voice recognition and synthesis.)

Re:Deeply worried

[BabyJ]

Interesting post. I too don't like the riding of coat tails that KDE and GNOME seem to be doing. It reminds me of the Gates remark in which he says that those desktop groups cannot innovate because they only emulate Windows. Meanwhile, MS does have some rather intersting, non-3D desktop ideas, some of which should emerge in the interface for Windows 2000. It would be sad to see GNOME and KDE riding every twist and turn Windows takes instead of forging new ground in interface design.

As an aside: I feel that anyone with graphic arts talents should make some suggestions to the 2 projects. I will.

Re:Deeply worried

[MindStalker]

(Check out About Face: The Essentials of user interface design by Alan Cooper for hints.)

Where can I find this? Or is it only available in dead tree format?

Re:Deeply worried

[Surak]

As an aside: I feel that anyone with graphic arts talents should make some suggestions to the 2 projects. I will.

Hint, hint, Rob Malda... :)

The screenshots of KDE2 look really nice, speaking as someone who was employed professionally as a graphic designer...

You really cannot make too many big, sweeping changes and still be comfortable for Windoze and Mac users...

Theme named 'Annoying'

[jake_the_blue_spruce]

In order to seamlessly integrate Gnome and KDE apps, the KDE and Gnome themes of the apps have to match. His telling remark that the themes would probably never be compatible is annoying. It would be a pain to write a theme editor which saved everything as both formats, and a unified theme installer/selector. Especially if the each format is a moving target.


Linux developers constantly site the cross-pollination between BSD and Linux as an asset. The fact that the KDE-Gnome camps do not share this cooperative spirit of innovation is beyond annoying to users. Standard theme formats is just the tip of the iceberg.

Re:Theme named 'Annoying'

[sab39]

I was worried by that comment too. I think that there is no reason that it shouldn't be possible to get a "perfect" use of each other's themes.

Note that *both* KDE and GNOME use theme "engines" rather than just pixmap hacks; the common myth that GNOME uses pixmaps is based on the fact that it's a lot easier to make a pixmap theme than to code a real one. So most people use the pixmap engine.

So, my theory is, why not write a Qt theme for GTK, which actually *invokes the current default Qt theme engine* which does all the work of making sure everything is themed correctly. You could of course do exactly the same thing in reverse and write a GTK theme for Qt which invokes the current default GTK engine. Then you could use themes for either and all your applications would look the same, regardless of which toolkit they were using.

You'd just have to be careful to never configure your system so that both these engines were the default for their respective toolkits...!

Stuart.

fundamentals of KDE still worrisome

[jetson123]

KDE is a very useful desktop, and the development effort is impressive.

But, as far as I can tell, the fundamental legal situation around KDE's toolkit, Qt, hasn't changed: it's still proprietary, it still hasn't been ported to other platforms in a free form, and it will only be released under a true open source license if the "Free Qt Widget Foundation" decides to do so by unanimous vote, which seems unlikely to me given its probable membership.

I'll continue to use some KDE desktop components, but I will develop for GNOME myself. I hope other people in free software community will follow suit. For all the quality and enthusiasm that KDE brings to free software, I think KDE and Qt are setting a dangerous precedent.

Re:fundamentals of KDE still worrisome

[jetson123]

Even Bruce Perens considers Qt to be free software theese days.

I consider KDE "free software" as well (and high quality free software at that). That doesn't change my concerns about the license. Not all "free software" has licenses that work well for their intended purposes.

Read the QPL license and stop FUDding around.

I did read the QPL; that's why I'm concerned. I suggest you read it more carefully, too. I think you will find that it differs fundamentally from the LGPL. QPL is more of a GPL-style license, and that causes all sorts of problems for developers, even developers of software that may ultimately be released free.

Re:fundamentals of KDE still worrisome

[Roberto]

Considering I am one of the voting members of the KDE FreeQt Foundation (no Widget there), I'm amazed to discover that we need unanymous vote.

BTW: If you want free Qt working on win32, all you need to do is port the X version. Despite what misinformed people say, the QPL says nothing about platforms.

Pure FUD

[Anonymous Coward]

Qt 2.x (the basis for KDE 2.x) is Open Source Software. ESR says so; RMS says so.

Stop spreading FUD. It really makes the GNOME project look bad.

Re:Docking functionality in 2.0?

[whoop]

Yes. The new panel, kicker, lets you replace the pager, task list, and clock with whatever you want. As well, applets can be written to do just about anything in the panel. I've worked on a simple news ticker, I've seen others talk of things like process meters. With KDE2, we're going for as much configurability as insanely possible. :)

Unix users left out in the cold

[Tom Christiansen]

We do try to emphasize the visual elements from Windows and MacOS because, let's face it, that's where the newbies are coming from and we want to make sure that they have a comfortable, intuitive environment to work in. It should be possible for an ex-Windows or ex-Mac user to sit down in front of a KDE workstation and figure out how to use it very quickly and with little or no help.

I guess that means that the answer to my question about What's in it for the rest of us (including the Manual Orientation thread) is "Not much, and we don't care". The goal quoted above seems to be none other than to make something that is sensible to non-Unix people, rather than something that's sensible to Unix people.

How terribly, terribly disappointing!

Re:Unix users left out in the cold

[Brian Knotts]

How terribly, terribly disappointing!

Why is it disappointing? If you don't need/like/want the "user experience" of KDE or GNOME, wouldn't you just use one of the numerous other UIs out there (including the plain old console)?

That's the great thing about the Free Unix scene; we've got more UI choices than you can shake a stick at.

I'd guess that the KDE team is not targeting its interface at UNIX old-timers, because UNIX old-timers aren't really clamoring for anything resembling KDE, wouldn't you say? If you've followed the KDE project from the beginning, you know that the goal has *always* been to make UNIX useable as a desktop operating system for the masses. I think they're moving towards achieving that goal.

Still, I find KDE useful, and am really looking forward to KDE 2.0 with KOffice. It's quite flexible, so I can create pretty much just the kind of interface I prefer...now if I could just convince them to add a few more virtual desktops (8 is not enough)... :-)


Interested in XFMail? New XFMail home page.

Re:Unix users left out in the cold

[Tom Christiansen]

It's disappointing because it does not have to be this way! And making something that isn't annoying for Unix people in no way rules out anything else, like something to make Prisoner of Bill not pee in fear.

Maybe you should reread my original article. One place where the toolkit and/or window mangler people could really help is the slow, stupid, repetitious, non-searchable menu paradigm. If I were to pick one thing after proper documentation, it would be this. Maybe even before. You don't want each program to cope with it. That's the wrong layer.

Happicons are another issue (how do you sort pictures? How do you choose things that make sense everywhere?), but I'll leave that one for now.

Please don't come off with this "let them use a 24x80 vt100" noise for Unix users. That's not fair, and it's not what Unix is really about. At all.

I believe that if they think Unix at design stage, they'll make something that's both Unix-friendly and extensible even in the unforeseeable future. But I also believe that if they do not think with the Unix mindset during that design phase, they will never, ever produce something which isn't annoying as hell to us non-Winix types.

This whole issue of "there's more of them than you, so you don't count" is the same pain in the ass that got us into the situation of nobody writing shrink-wrapped software for Unix. This is just another way to tell us we don't matter, that it's ok to ignore us and piss us off, because it's cheaper to take the heat than to do it right. And if that doesn't dissappoint you, I don't know what does.

Re:Unix users left out in the cold

[edhall]

It's not just Unix users that are affected by this limited vision, but they are the ones most likely to be familiar with the pipes-and-filters methods that MS WIndows-like desktops are simply incapible of utilizing. So they're more keenly aware of What's Missing.

The fact is, the emerging free-software desktops might look better than MS Windows, be more configurable than MS Windows, and work better than MS Windows, but they don't break any new ground. Drag'n'drop gives no more functionality than the DOS 1.0 command line: feed filename A to application B. Component models make programming easier, but in themselves do nothing to improve desktop functionality. The fact that it is impossible to use the desktop to order a seqeunce of operations on one or more objects--something that should be absolutely basic--shows just how limited the desktop metaphor remains.

I'm sure some folks will say "just use a CLI," and that's certainly what I'd do. But there are natural ways to make a GUI do the same sort of thing, such as what Tom suggested in his question--from drag'n'drop to connect-the-dots. And this would just be the beginning of using hugely intuitive visual metaphors to allow everybody to do the things that only ksh/bash gurus can do now.

It's just a crying shame that the KDE folks are relegating themselves to improving the same tired and limited conceptual framework that MS Windows inhabits.

Free software has craftsmen a-plenty, and good ones. But where are the visionaries?

-Ed

Re:Unix users left out in the cold

[Tom Christiansen]

Tom, what I find "terribly, terribly disappointing" is the fact that you have very clearly never tried using KDE..

Your premise is false, which means your consequent is irrelevant.

Now, I've written at some length about what would be reasonable for a Unix user. Go see the thread I cited for some of that. Someday I'll write more.

To answer in broad, high-level terms your question about what might be "sensible to Unix people", I'd say that the biggest thing is to avoid optimizing for these incompetent, documentation-free, training-free, five-second users, expecially when that means screwing over the professional, long-time user who can actually remember something from one day to the next but who isn't allowed to make use of this experience. I don't see why both styles aren't possible. Allow people to learn, damn it!

The next thing is to stop discriminating against people who don't mind dealing with multiple layers of abstraction. Doug Gwyn said, "GUIs make easy things easy, and hard things impossible." That's because of the abstraction level and associated connectivities between those abstractions. You'll never do anything with a canned GUI that the author of that program didn't foresee. It doesn't let itself to that sort of power-user combinatorics. It's just a toy. GUIs don't have to be, but for some reason, that's all we have.

One should also stop discriminating against people who can actually touch type. The keyboard-mouse fight is self-defeating. Nothing could slow you down more. And the mouse is an RSI hazard. Use it for what's appropriate, not for everything. Going back to the pre-literate days of pointing and grunting rather than explaining what you're trying to do is hardly progress.

And finally, you should stop discrimating against people with non-Windows learning styles and and non-Western cultural backgrounds.

There's probably more, like not discrimating against left-handed people, but those are the big ones that came to mind.

Re:Unix users left out in the cold

[Tom Christiansen]

KDE's documentation, btw, is perfectly proper, and if you want man pages, you can generate them yourself from the SGML source. Everyone else can hapily [sic] use html, same as always.

I expect and demand a single, solitary, coherently and seemlessly integrated documentation system for the entire operating system. I expect and demand that every command be documented, and that every user-callable function be documented. I don't care what the hell that system is called, nor for the most part, how it works, provided it doesn't get any worse than man already is. But it must be ONE SINGLE SYSTEM.

I do not expect to go hunting through fricking alta vista to find something out. Documentation must be integrated. Don't make me hunt. Don't make me look one place for docs on this thing, and that place for docs on that thing. This hodgepodge scattering of documentation to random places on my system or the net all requiring distinct interfaces all ignorant of one another is a fundamentally brain-damaged Winix evil. You would never get away with this crap from a real vendor.

Just have make install generate and install proper manpages in proper. Anything else is wrong. If it's so damned easy, just shut up and do the right thing.

And remember, "elitist" is ignoramus-speak for "competent professional". I'll be happy to don that moniker and eschew its antonym. Anyone who touches a computer is severely handicapped if they can't type. Stop screwing over those of us who can by choosing a single-bit interface when there's a concerto just waiting to unfold beneath the expert's fingers.

You clearly lack the ability to understand why reliance on cascading and nested menus for command execution is fundamentally evil. You can't search them. You can't automate them. You can't ever get any better than the buffoon you were when you first got there. I could write an entire paper on why forcing this moronic model down all our throats is brain-numbing and counter-productive.

And please don't waste any more of my time trying to get me to tell the difference between whether you're a troll or whether you're a loon. Right now, you're batting 50-50, but guess what? I don't care which it is. I'm sure you'll have to bitch a little followup to everything I say, but go for it. I enjoying watching you waste your time flailing around like this, but as I've never seen anything particularly insighful from you (I've looked at your karma), and you never seem to actually learn from others, your rants will fall on deaf ears, and I shan't be responding to your trollings. Go ahead -- waste your life.

Re:Unix users left out in the cold

[Tom Christiansen]

You just haven't figured out this out yet, but slashdot is what you call a Winix place. Unix is dead. Nobody cares what you programmers want. It's all about money, and money means copying Microsoft.

Well, certainly that's how it seems here sometimes. But I just don't believe it. I refuse to believe it. I know, I know: reality is what remains after you're out of the universe.

It's disappointing that the movement to make a free Unix seems now to have turned into a movement to make a free Windows. The objective criteria and design goals are completely altered.

I don't know. Maybe you're right, and Winix mindlessness will crush the rest of us into the dirt. I just don't plan to go quietly. I shall squeak beneath your heel!

Re:Unix users left out in the cold

[Chandon Seldon]

So, Since it's pretty obvious that the goal of the KDE project is to make an evolutionary Windows-type desktop enviornment for computer-illiterate to semi-literate users - what would it take to start a project to make a desktop enviornment for mid to wizard level unix users? Would you want to run such a project?

I ask because your complaints sound a lot like design issues, not something that the KDE people would be willing to redo after spending a lot of time on that way of doing things, and because it doesn't look like anyone's working on making an advanced UI with a powerful interface.

Re:Unix users left out in the cold

[vilvoy]

"It's disappointing that the movement to make a free Unix seems now to have turned into a movement to make a free Windows."

If any of the underlying functionality were being removed, I might share your disappointment. But it isn't, so I don't. You don't have to use KDE if you don't want to. And if you do use it, it still does absolutely nothing to keep you from utilising the full capability of the OS that runs beneath it. The reality is that Windows, Mac, etc., while lacking some of Unix's capabilities, have done some things right, and have even done a few things better (the question about printing capability, being a good example). To acknowlege those successes and to bring equivalent capability to the Unix/Linux world is crucial to any future success of these powerful OS's. OS puritanism does absolutely nothing to benefit your favorite OS. Projects that strive to make Unix/Linux more usable to a wider audience are not taking away any of the capabilities that existing unix users know and love. They only add more capability. KDE, Gnome and Mandrake are all too often condemned for their efforts when they deserve to be applauded.

If it's the lack of pipes and sequential operations under the GUI that worries you, then perhaps you would do better to help implement these functions. If, like me, you don't have the programming skill and/or available time to implement this yourself, then at least offer it as a constructive suggestion for improvement instead of using it to bash the work that's already been done.

I would also like to point out that X itself already has some capabilities that Windows lacks. The free unix movement is certainly not turning into a free windows movement. But it would be truly sad if no effort were made to gain those capabilities in which we are clearly behind. We already have superiority in some areas, so if we can gain at least equality in all other areas, we will come out ahead.

--
Peace,
vilvoy

Re:Unix users left out in the cold

[Tom Christiansen]

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.

Re:Unix users left out in the cold

[Tom Christiansen]

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.

Re:Unix users left out in the cold

[Tom Christiansen]

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.

thanks,

Re:Unix users left out in the cold

[Tom Christiansen]

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.

Re:Unix users left out in the cold

[Tom Christiansen]

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.

Re:Unix users left out in the cold

[Tom Christiansen]

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 read the license (+some more analysis)

[jetson123]

I'm not associated with either GNOME or KDE; I'm simply a user and deveoper trying to decide for myself between GNOME and KDE. I'd love to develop KDE and Qt, because they seem somewhat more mature, but I don't see how I can, given the licenses. So, I do the next best thing: I develop for GNOME but use the good bits and pieces of KDE.

As for the license, this is not a question of "opinion" or "discussion" or "FUD"; just read the QPL yourself and understand it. You can find it at http://www.troll.no/qpl/.

There are many subtle differences between the QPL license and the GNOME/Gtk license, but there is also a big, fundamental difference: GNOME/Gtk is licensed under LGPL, while QPL is licensed under something resembling GPL. RMS and FSF got a lot of heat for GPL and the problems it caused, and LGPL was invented for that reason. I couldn't use Qt even if it came with a straight GPL license. Whether RMS calls QPL "open source" or not makes no difference to me; what matters is what the license itself requires.

Some other key items to notice with QPL are:

• The distinction between "free" and "professional" edition exists, as it always did.
• The intent behind QPL is stated as allowing the development of non-commercial software with it; for anything commercial, you have to pay. ("The QPL prohibits the development of proprietary software.")
• If you read the "Free Qt Foundation" document carefully, you will see that the foundation can only grant a BSD-style license on Qt by unanimous vote of its members; what kind of safety is that?

I suggest that if you are serious about QPL/Qt and have actually read the licenses, you contribute some facts and analysis instead of anonymously complaining of "FUD". I have no personal investment in either GNOME or KDE; I'm just looking at it as a CS researcher who need to build GUIs occasionally, and as such I look carefully at the licenses of the software I use. And I still think the QPL doesn't cut it, for all the reasons I mention above.

Re:just read the license (+some more analysis)

[jetson123]

Thanks for engaging in a discussion. Lots of other posters seem to consider any concerns about the Qt license to be merely flamebait without any basis in fact. I looked carefully at a number of toolkits and their licenses, and I simply cannot figure out how to commit to using Qt, even though it is the most mature of the bunch.

If an app you're developing is so great that you seriously believe people will send you money for it, $1500 is trivial.

I think that's a valid point, and I don't actually have a problem with paying $1500 for a toolkit that I'm going to use for a commercial application.

The problem I still have with QPL is that it means, effectively, that I'm committing to Troll Tech as a commercial vendor even when I start developing with their free version. Once I have invested in learning and tooling around a commercial system like that, I'm tied to them.

So, if I develop a mix of commercial and free software, my future options are greatly limited. And commitments to vendors are not one-time payments, they are an ongoing commitment to paying for maintenance, as well as confidence in the company's future.

If the situation came to this point, they will come to a conclusion that is in the best interest of the free software community.

I have no problem believing that the members of the Free Qt foundation have the best interests of the free software community at heart. But that still doesn't fill me with much confidence. If Troll Tech runs into trouble and push comes to shove, I can imagine many reasons why a unanimous vote may not be achievable; the Free Qt Foundation agreement simply looks to me like it's legally very vague, with lots of opportunities for problems.

While the Free Qt foundation is well-intentioned, it still doesn't fill me with any confidence that, should Troll Tech run into trouble, continued commercial support of Qt is assured. That's another reason why picking Troll Tech as a commercial vendor seems kind of iffy to me.

Re:just read the license (+some more analysis)

[jetson123]

I'm sorry, but I re-read the KDE Free Qt Foundation documents again, and I still don't get much reassurance.

The stated purpose of the Foundation is to "secure the availability and practicability of the Qt toolkit for developing free software for the X Window System". But what about "securing the availability" of the Qt toolkit for developing commercial software?

Also, the procedures for releasing Qt under a more liberal license look very vague to me. It talks about whether the Foundation 'regards the said edition for stopped or discontinued [sic]'. There are no definitions for when a majority vote is sufficient. Why is the KDE Qt Foundation agreement so vague?

In fact, I do pick any software that requires a significant investment in terms of time, training, and effort very carefully. While Troll Tech's technology may be good, Troll Tech wouldn't meet my criteria in terms of stability and long-term support for a commercial toolkit vendor (nor, in fact, the purchasing criteria of companies I have worked or consulted for). And if I invest time and effort in using Qt for free software, I'm implicitly choosing Troll Tech as a commercial vendor as well, since it would be a waste of time tooling up for one toolkit and then choosing a different vendor for commercial development.

In addition, I'm still unconvinced that the current agreements guarantee the continued viability even of the free edition of Qt because of the vagueness of the agreement between Troll Tech and the KDE Qt Foundation.

To me, both the free and the commercial Qt licenses are riddled with legal ambiguities, and I have decided that I can't live with those. I hope others will also look at the license and its implications in detail, rather than relying on vague reassurances. Nice as Qt may be, there are lots of alternatives available to it, under licenses that are much better defined.

Re:Question

[QuMa]

I think your refering to AAlib.. Very cool stuf, they even made quake (1) run in text mode. Someone has been out of his straightjacket too long :-).

Officialness

[Shaheen]

Before we get down to business, we'd like to stress that these are the opinions of individual KDE developers. The answers below are not *necessarily* the same as the KDE Official Position on matters. If you wish to know THE official opinion on any of these, contact the KDE Core Team through any of the official representatives.

This type of thing worries me. Part of open source's coolness is that, while we can edit the source, we can also go right to the author of the software and ask questions (and get correct answers). The above makes it sound as if KDE is just another corporation that may or may not think like its employees. I think it's particularly sad that a major center of open source development (the KDE project) is turning into this type of establishment.

Also, aren't these guys the developers of KDE? Doesn't that mean they *are* the official representatives of KDE? Who else is there to be a representative of what KDE stands for except for the people who make it and use it? To me, that just makes it all sound like KDE has a marketing department.

Re:Officialness

[Roberto]

The point is that these are the answers of two people out of hundreds.

If you ask through the official representatives, you will get the condensed opinion of about 30 people.

Of course for individual pieces of software, just ask the author. If you ask about KRN, ask me.

It gets tricky when you ask people about software they are NOT writing, though. If Richard answers about KRN, I'd like him to ask me first :-)

Microsoft File Formats

[hey!]

You have to hand them some slack on supporting Microsoft file formats. Not only are they undocumented, but Microsoft's own applications are very poor about rendering a given file exactly the same way twice, unless you are only using the most plain-vanilla of capabilities. Try making a document with pictures and wrapped text in word, saving it, and opening it again. What word does to the thing is unspeakable.

Re:Commercial Power

[extrasolar]

The reason that KDE is so vastly superior to Gnome is because it's commercially backed.

Then why is Linux, GIMP, and Emacs so vastly superior?

Because QT is controled and maintained by a real commercial enterprise. Free software is really good at making little hacks and apps, but fails almost completely when it comes to framework.

Free software is great at making large hack and apps and at making frameworks. GNOME is a good example. I use it daily. Red Hat does contribute to it though. KDE is arguably better and comercial corporations have had less direct intervention.

QT is superior to GTK simply because it's rigidly controled by a commercial enterprise rather then a bunch of weekend hackers.

The reason QT has theming is because they have let go of some of that rigid control. And who is to say that GTK is inferior. It has many many language bindings, had theming first, and is used in many advanced applications.

Since GTK is inferior to QT, Gnome is inferior to KDE and it will stay that way until the Gnome developers wise up, change the license of all their code to LGPL, and hookup with the only kind of group that can produce framework code of quality: A commercial group.

Gnome is somewhat inferior to KDE because it had a headstart and didn't let a thing like freedom get in its way (Note: KDE and Qt are free now). I have noticed it more and more that Gnome is introducing things about 6 months behind KDE. But I am confident they will catch up.

Thoughts

[Chris Johnson]

I wish my question had made the cut, upon reading this mess of answers and flames. I was the one who asked "In the ideal KDE environment, what percentage of user input is expected to be:

• Selecting menu entries, popup or root or Start
• Entering text in text entry areas
• Clicking a small button with an icon on it
• Clicking a larger button with text on it
• Radio buttons, checkboxes, listboxes
• Keyboard shortcuts (combinations like meta-*)
• Editing a dotfile

Which of these control types need to be made the sole control for a type of functionality? Which if any do you feel represents the preferred KDE method of doing things, and which if any are discouraged?"
This was a trick question. It didn't get an answer, either trick or otherwise, but I can guess at an answer. I'd say the KDE people like chiclet-button-bars best, like menus and radio buttons and checkboxes pretty well, consider keyboard shortcuts a low priority, deprecate entering text wherever possible, and wish editing of dotfiles would just die ;)
The reason it's a trick question is because all these things and their resulting priority levels are copied off Windows, expecially buttonbars. There is no evidence to suggest these are in fact any easier for newbies to cope with- instead of mysterious invisible incantations, they become mysterious _visible_ graphic pictures. This is thought to be an improvement.
The fact that this isn't significantly simpler doesn't make the mysterious invisible incantations any easier- it's true that the classic Unix approach isn't intuitive (whatever that means) all by itself. Once the various (and many) little tools all with different args are learned, _then_ the _building_ of larger tools out of the little tools _can_ be intuitive. People who have learned to do this tend to forget how tough the initial stages are- tough and tiresome.
On the other hand, and I now know two KDE developers with this point of view, the idea that making a Windows-like desktop magically makes things easy for newbies to use is rubbish! I would hope these people were asking 'OK, so HOW is this easier then?' and analysing their work and looking at their GUI vocabulary to see what parts can easily generalise across the whole system- unwritten 'rules' that hopefully are learned by experimentation and generalised across all GUI-using programs, successfully. I don't see any evidence of this. At best the KDE people are choosing to NOT FOLLOW some of the more ugly Windows GUI mistakes and will end up with a nice inoffensive vanilla GUI with themes to conceal its basic blandness. At worst, they could take even less effort than Microsoft and end up with even more twisted and unobvious GUIs, all the while angrily claiming any critics obviously have never TRIED their masterpieces and so can't possibly know a thing.
Because obviously you have to try a thing to know if it's good, right?
Because obviously there is no right or wrong other than what people are used to, right?
Because obviously if there ARE different sorts of people, then presumably 90% of them are all ONE sort, the consumer Windows-using plebian sort, and they couldn't possibly want other than the most obsequious handholding simplified GUI interface possible, right?
Because they all went out and CHOSE Windows, therefore proving that concept of GUI accurately represented what most people wanted, right?
...

I think there are some major holes in these quiet assumptions. I would really like to get a better technical summary of exactly where KDE thinks it is going. Not long geeky diatribes on object models: pretty much nobody cares about that unless they program and like OOP. Not "KDE will win the desktop!", that's empty hype. I'd be interested in things like the breakdown of graphic object usage, in terms of what % buttonbars, what % checkboxes etc is the goal. If they cannot answer this then they have nobody thinking about human interface at all- there's nobody at the wheel and a whole lot of engines and gears rushing frantically... where?
There are answers and answers, and some answers are copouts. Nobody asked the KDE people true human interface questions, except for Tom Christiansen- and his weren't used and were quite hostile anyway. As a result, the KDE people have said absolutely nothing about human interface with this exception: over and over again is the suggestion that usability is no more or less than familiarity with a set of rules- "learn KDE, use KDE, be happy, there is no rule 4".
Anyone with a background or even cursory familiarity to human interface design knows that's a crock. There are rules. It's as involved and pervasive as the 'rules' of traffic flow in a crowded building, and simple changes can have profound effects on smoothness of workflow. Tom Christiansen knows this because HIS rules just do not coincide with what KDE offers. My own experience with KDE (which was the means of my first linux dialup, no lie) was not much more encouraging- compared to MacOS (a tough competitor, to be sure) KDE didn't seem to have a focus. The only rule seemed to be 'click on stuff and do things!' and that's not enough. It was enough to get me online- I clicked on stuff and kept doing things enough to make PPP connect, but it was like learning disconnected tricks. The common points seemed to be the presence of buttonbars on things, and a strong emphasis on forcing mouse actions over keyboard actions.
I would like to see better thought taken, both in the KDE and for that matter the classic Unix CLI camp, on what the unspoken assumptions of interface design are. It's just not enough to merely soak these things up by osmosis- soak them up from Windows and you soak up a lot of chaos and lossage along with them. WHAT about a button bar is easy for a newbie? Going 'click' is relatively easy for a total newbie. What is easy about little pictures? They symbolise things, arguably pictures are more easily remembered than words (maybe). How to get a translation for the pictures? Experiment randomly or look for words (tooltips) that are not always present. What to do with the information gained? MEMORIZE it. Just like reading man pages and memorizing args, or referring back to the manpages habitually. This is NOT different from that old way of doing things. It's just as opaque, it's just in pictures this time! If serious thought isn't given to the underlying structure (quick, what order are paste copy and cut in KDE pulldown menus! Is it always the same? _Why_ was that order picked? How rigorous is the whole menu structure?) then the result is going to be a morass no matter if it's CLI or GUI. Unix CLI is already a morass- learnable, but a mess. KDE looks to be headed for a similar mess if the people involved don't quit with the kneejerk dismissals of criticism, and start listening. Normally I'd be more diplomatic, as I've usually considered the "It's your fault for being unwilling to learn KDE which is just as good as anything else, by definition" attitude as one person's opinion, and people have a right to their opinions. However, it's not just one person's opinion. It's heard from a fair number of KDE supporters and developers. It doesn't seem to be contradicted by anybody working on KDE- and this tends to minimize my desire to be diplomatic about it.
Hence this little diatribe: no sense in my not calling it a diatribe, as others will anyhow. I'm just not impressed with the KDE attitude towards human interface. It looks like the KDE attitude towards human interface is take whatever was there, add whatever you want, call it the interface and expect people to learn it and like it or lump it. If they don't like it, rather than try to fix it you make it more configurable so they can make random changes.
It's interesting to observe that this is EXACTLY what happened to create the very same classic Unix CLI that the KDE folks are horrified of. Both sides (i.e. KDE people + Tom Christiansen ;) ) should mark that well- Tom, to get some perspective and learn that the KDE people are simply creating a very different mess which people can learn the details of just like they learned classic Unix: and the KDE people, to remain aware that it still _sucks_ even if the same approach with classic Unix led to stuff some people really liked.
Now having offended everybody, I depart, chortling mischieviously ;)

Re:Thoughts

[Tom Christiansen]

Could you repost this with paragraphs shorter than 150 lines, so it can actually be read without getting a headache?

I see this a lot. It does seem to make it harder to read. I think what's up is that people are in HTML using BR tags where they want to use a proper P tag. Or in ASCII, they're using one ENTER key rather than two.

Re:Thoughts

[Chandon Seldon]

I agree with you that a little bit of planning a desktop enviornment probably helps, but I disagree that that planning should be specific % of specific widgets.

I think that the planning should be the developers asking themselves "How does this look and work for user X?". A particular way of doing something isn't good unless it looks/works good for everyone who will be using it. It shouldn't be designed so a new user won't be able to use it - but neither should it be designed so that it'll drive experianced users working with it for the 50th time that day insane.

Re:Integrated Web Browser? -- security issues!

[platypus]

Some points, at first the principal problem with security in ie isn't his integration with the os, it's the dumb activex-controls (sometimes by interacting with the os, here you are right).
But all in all it's not the integration from the outside (os) to the inside (like in kde) which is dangerous, but the other way round, controling the os from inside the browser.
Second, and related, frame-spoofing can happen in netscape too which isn't integrated at all,and the last flaw i've seen was in netscape (a bad one seemingly), reported to bugtraq on 24.11.
If they use java with a standart java-engine they should be relativly secure.

Please moderate on merits, not opinions

[Ethan]

It strikes me as mildly irritating that this message is presently a score of 4, 'Insightful', while the following post (which is basically the same as this one, only using a generic 'Gnome sucks' stereotype rather than a 'KDE sucks' stereotype), Commerical Powers (#24) is rated 0 for flamebait.

Come on, people. I'm personally a Gnome user, but I can see that the KDE people have done some great things. (KOffice, if nothing else... I personally think there's lots more) The QT license thing is annoying, but hardly a reason fora call-to-arms against KDE. I'm thrilled that you want to develop for Gnome, but lets not tell people that developing for KDE is evil.

And moderators, just because YOU like Gnome better than KDE is not a good reason to moderate this post up and the next post down. I'm very disappointed.
Ethan

My conspiration theory

[Le douanier]

Qt is done by TROLL Tech, the desktop competing with KDE is called GNOME.

Are north-european pseudo-mythological creatures fighting a war using the Free Software arena as their battling field???

;)

Re:My conspiration theory

[Tom Christiansen]

Are north-european pseudo-mythological creatures fighting a war using the Free Software arena as their battling field???

What do you mean, pseudo-mythological? :-)

Re:My conspiration theory

[Le douanier]

What do you mean, pseudo-mythological? :-)

Well, up to now we believed that they were mythological creatures, but if they really exist and do the fight I explained in my precedent post then they are not a myth, therefore they are a pseudo-mythological creatures, that is real creatures.

Add to the conspiracy the fact that TT is based in Norway and that Linus is Finnishm two north european countries.

What Are You Looking For?

[chromatic]

Tom, are you thinking of such things as graphical representation of pipes and redirecting input and output? For example, if I wanted to print my manuscript from LyX to my printer doing 2-up duplexing, I could drag the LyX document icon to a pipeline workspace, add a dvi2ps filter and the specific print filter to do the 2-up and duplexing and connect it to the appropriate printer -- all graphically.

That could be very nice. Imagine a desktop that worked like one of those nice Java Beans IDEs. While KDE is componentized and Python-scriptable, I'm thinking of something that end-users would be able to use *without* scripting.

Unix has a lot more power underneath a nice GUI than Windows does (especially with DOS). It would be nice to have a GUI or a Desktop Environment that gives people access to this power.

--

Re:What Are You Looking For?

[Tom Christiansen]

Goodness, I hope it's not only "python scriptable". It shouldn't be bound to one programming language. Sure, Python has a lot of nice features, but it's not for everybody. I have gotten the possibly mistaken idea that the scripting mechanism will be language-neutral. I don't know anyone who's working on Perl bindings for it, however.

And yes, I'm thinking of graphical in and out and error, etc, connections. The big problem with graphical mechanisms is that your ability to specify any abstract criteria is severely limited. It's hard to find the happycon that represents all python scripts recursively beneath the current working directory that are owned by you and which were modified over the last 19 hours.

Pianists got the right UI

[Tom Christiansen]

About the manual orientation thing: I'm sure you can sed the docs to replace all the references from "left button" to "right button" and vice versa. I'll be happy to distribute "kde docs for leftys" for you.

I think you're misconnecting here. I'll talk about the issue of manual orientation. It's not actually related to Microsoft at all, unless perhaps they actually do this right. They could hardly do it worse. It's just something that has always irritated, and I was hoping KDE would have the foresight to address this bug. Apparently, they don't care--just like so many others have historically not cared.

Here's the bottom line: Anything that says "left" or "right" button is already fundamentally misdesigned, or at least, misrepresented. It's inaccurate and wrong. Now, it's either that, or else you in KDE just outlaw the X11 facility to switch these around. And you can't do that. So now you have a bug as pervasive as Y2K is alleged to have been. Fix it at the start, or suffer forever.

It seems to me that this means that you need to do one of two things to cope with the manual-orientation bug. Either be able to build all your menus and explanations so that the proper (current applicable) word appears, or else you devise a way to express this without left and right. I gave one suggestions: using "index" finger for button one and "ring" finger for button three. There are certainly other ideas, and quite probably better ones than these. But you should get the idea. Don't build in bias.

If you look at the fingering notes on piano music, the index finger is not #2 on the right and #4 on the left hand. It's #2 in both cases, just as the thumb is #1 in both cases. So why do people who talk about computers and mice almost always do this wrong? Don't they understand that an index finger is still an index no matter which hand you find it on? It doesn't go from "button one" to being "button three" just because it's on a different hand. It's still button one, because it's the finger closest to your thumb.

Intentionally making life hard on 1/7 or 1/10 the population merely because there are fewer of them than you is unfortunate at best, wicked at worst. And the thing is, you don't have to. But right-handed people never think about this, so left-handed people get screwed completely unnecessarily.

Re:Pianists got the right UI

[Tom Christiansen]

How about buttons 1, 2 and 3 ? Works for me...

That seems adequate. Well, assuming that the target audience can count that high. :-)

Specifics.

[Roberto]

Tom: Unless you start making specific criticisms, all your writing is useless.

For example: "you should stop discrimating against people with non-Windows learning styles and and non-Western cultural backgrounds."

Ok. Where is KDE doing that?

Another: "here's probably more, like not discrimating against left-handed people, but those are the big ones that came to mind."

Where does KDE discriminate against left-handed people?

Another: "stop discriminating against people who don't mind dealing with multiple layers of abstraction"

Where does KDE do that?

"stop discriminating against people who can actually touch type"

Yet again: where does KDE do that?

"The keyboard-mouse fight is self-defeating"

Where in KDE do you find something that is only accessible through the mouse, and what keyboard access do you propose?

"Going back to the pre-literate days of pointing and grunting rather than explaining what you're trying to do is hardly progress."

Where is KDE doing that?

"Allow people to learn, damn it! "

Where does KDE prevent people from learning????

Can I suggest that perl stop discriminating against those who like to use the mouse, against those with RSI (perl makes you type!), against those with good taste in syntax, against those who dislike interpreted languages, against those who have short attention spans, against those who prefer non-procedural languages, against those who prefere there be one obvious way to do things, against people who has to maintain other's code, and against those who prefer ideograms?

See?

Re:Specifics.

[Tom Christiansen]

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.

all I'm saying: think about your choices

[jetson123]

I think I said pretty clearly what I want: I want people who choose a toolkit for building free software to read about and think about the license of that toolkit carefully. I'm not a commercial Troll Tech customer. I'm a CS researcher who prototypes a lot and occasionally releases software, some free, some not.

I looked at the Qt license, and I don't find it satisfactory. I think it is pretty clearly designed to create a potential market of future commercial software developers for Qt, and it funnels a lot of energy towards helping to improve a commercial toolkit. I also don't find the current QPL and KDE Qt Foundation sufficiently legally grounded to guarantee what it tries to guarantee.

People may have well have legitimate differences of opinion on whether that's a fair bargain. But I think anybody choosing Qt as a toolkit should at least carefully consider these issues and implications. In particular, I feel the KDE portrayal of Qt as just another open source GUI toolkit is misleading. For myself, I concluded that I couldn't live with the Qt license, that Tk and Gtk+ were good enough, and that I would better spend my time working with and on them.

Re:You got it!

[Tom Christiansen]

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.

Re:You got it!

[Roberto]

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.

"What about the Gnome project's documentation? Does KDEhelp find that?"

Sure.

"What about the Imlib functions? Does it find documentation for them, too? "

I have no idea. If they are man, info, or html, yes.

"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. "

You see, that's the problem. You got it completely backwards.

In the beginngin, there was a mess called "the unix and apps that run in it docs". They came in at least three formats.

Then someone who had his balls in the right place, created a tool that can access all those three formats, making the differences between them irrelevant.

That person was part of a group. That group chose one of those formats, the one they liked better, for their own docs. Specially considering that anyone that used their toosl could use their tool to read the docs, and that such tool has the distinct advantage given above, they did the right thing.

Now, if you or anyone else wants to use a similar tool in another environment: your task is easier. The hard part is already done.

Don't hold against us creating a tool that's better than the ones you have.

Re:Pretty clueless

[edhall]

KDE is shifting towards allowing components to be scripted together, giving pretty much what you asked for.

No, that's not really related. I can do all the scripting I want in TK/TCL already. If the desktop/WM helps in that, so much the better. But I can't even do simple combinations of files and processing like:

fgrep -f file1 file2 > file3

by using just the GUI. This, even though the idea of graphical metaphors for such things has existed for close to 30 years! And it's existed in ways (e.g. Tom's "connect the dots") that are intuitive even to children.

There are a number of applications that include such functionality, from database design tools, CAD systems, and CASE tools, to children's games. Why are desktop designers so focused on becoming a better MS Windows that they ignore just how antiquated the model is they are following? Trying to "fix" things with scripting is simply combining the worst of the textual and graphical worlds. It's a dead end.

-Ed

Re:your .sig

[extrasolar]

It is helpful when you are speaking of either the operating system (GNU/Linux) or the kernal (Linux). I know I have been confused a number of times when the difference wasn't made clear.

Re:It only affects proprietary software

[extrasolar]

Wow. That sounds like a reduced form of the copyleft. Hmm.

Re:You got it!

[Tom Christiansen]

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.

Engelbart's chord keyboard

[gargle]

I attended a presentation recently by Doug Engelbart (the inventor of the mouse, windowing, and other cool stuff). One of the things he did was to display his "chord keyboard" - similar to an actual keyboard, but you depress more than one key at once (hence Chord). He attacked the existing icon-based metaphor as being too limited, and what his chord keyboard provided was a more expressive way of describing what you wanted to do i.e. expressing your actions in terms of nouns and verbs, instead of syntatically limited mouse clicks. This may be something free software GUIs may want to experiment with - much better than going down the route of 3d windows which I don't really see the point of.

He also attacked the current obsession with making things "easy to learn". My intepretation of this is that if something lets us accomplish more than what we could without it, and if it really had to be that hard, then we should be prepared to learn it rather than complain and do without it.

(FYI, Engelbart was using Windows with Powerpoint :) And despite being the inventor of the mouse, he seemed very hesistant with it, probably due to his age. )

Re:Engelbart's chord keyboard

[el_chicano]

He also attacked the current obsession with making things "easy to learn". My intepretation of this is that if something lets us accomplish more than what we could without it, and if it really had to be that hard, then we should be prepared to learn it rather than complain and do without it.

Kind of like unix itself. A major learning curve is required, but once you learn the basics you can do quite a few things. The more you use it, the more you learn and the better you get at it.

Of course, one has to enjoy learning (i.e., learning != "too much work") so it never seems like a chore. I myself love learning new stuff and in a perverse way like having problems with my system. That gives me a chance to look for the relevant information, read it and apply it.

It is a wonderful feeling knowing that you know how to acquire the knowledge needed to solve your problems, which in turn helps build your confidence in your abilities. Also, it turns out that finding the answer to your problem often takes a lot less time than reinstalling and reconfiguring the operating system!
--

Pretty, clueless

[edhall]

Once again, I'm not talking about scripting. Scripting allows you to add new functionality, but it is quite limited as a way of increasing the richness of possible interactions with the desktop itself.

Let me give you a limited example of what I'm talking about, drawn from the world of signal-processing block languages. Suppose I want to represent my earlier example in a graphical way:

fgrep -f file1 file2 > file3

Now, suppose that the fgrep icon had little arrowheads on each side, one pointing in, the other pointing out. And it had a small rectangle along the bottom with the same "look" as the arrowheads. The arrowheads and rectangle represent input, output, and control, respectively.

Now, either by dragging or drawing a line, I connect file1 to the control rectangle. Then I connect file2 to the input arrow, and finally file3 to the output arrow. Finally, I click on the center of the fgrep icon (or hit a key, or otherwise signal GO). I've just used fgrep to apply the string list in file1 to file2 and put the result in file3.

This is pretty clunky as it stands (I'd much prefer typing), but consider how easy it is to extend. For example, draw a circle around some file icons and connect them all up instead of file2. Have the desktop create file3 automagically, to be named or anonymously reprocessed later. Link other processing elements in. And so on.

OK, now think of creating your own processing-block icons from combinations of other blocks, or from scripts, templates, or various tools. Use inheritance and polymorphism to leverage existing blocks. Add other routing elements, represented by new sub-icons (like the arrowheads). Associate other programming semantics (e.g. looping, branching) with other drawing actions and icons.

All this stuff has been done already within applications and simulation environments--literally decades ago. Microsoft has been so oblivious in this area that they took a term of art--Visual Programming and rendered it utterly meaningless with "visual" languages which were anything but. As a result, they've left the world of graphical desktop development at a stage that doesn't tax the cognitive development of a slightly slow 2-year-old.

Why is it so hard for us to improve on this?

-Ed

Re:You got it!

[Tom Christiansen]

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.

Re:You got it!

[Tom Christiansen]

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.

Re:You got it!

[Tom Christiansen]

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.

Dirty Laundry: What's Wrong with KDE Help

[Tom Christiansen]

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.

1. 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.

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?

3. 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.

4. 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?

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". 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?

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. 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.

7. 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.

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.

9. 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.

10. 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.

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. 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.

12. 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.

13. 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.

14. 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.

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.

16. 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?

17. 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?

18. 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.

19. 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?

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.

21. 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.

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.

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.

24. There's no "Clear" on the Find window to help with cut and paste.

25. When you want to do a search, you have to hit ^F. How do I make that be a slash instead?

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.

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.

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.

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?

30. 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.

Re:Dirty Laundry: What's Wrong with KDE Help

[grrussel]

Point 1 - is being rationalised and reorganised for KDE 2 and by Corel.

Point 2 - Edit is there since thats what find comes under in most GUI's. It makes some sense, just not too much

Point 3 - You seem to confuse Window Manager and Application menues. Closing Windows does not Minimise them. Seems fair enough to me.

Point 4 - In KDE 2

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

Point 6 - Configrable. Go configure it. Its set to page up/down by defualt. KDE Control Center or Settings-KeyBoard ShortCuts

Point 7 - may be valid.

Point 8 - Use the search tool after ticking all types

Point 9 - Again, an Xism, its just like Xman

Point 10 - may be valid

Point 11 - may be valid, works fine here though

Point 12 - valid, but this is how Xman does it.

Point 13 - may be valid, I see no distinction between locally installed and OS Standard - its installed or its not.

Point 14 - could be

Point 15 - it takes time sure, but it works. I don't see your point

Point 16 - may be valid

Point 17 - Its a keyword search, like, just one word. Pattern matching regexps would seem to be excluded by definition.

Point 18 - valid

Point 19 - valid (KDE 1.x doesn't support reight to left languages, maybe 2 will)

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.

Point 21 - Its a bug when you move focus around the elements in the window. Report it.

Point 22 - ^W is a KDE standard binding for close. Change it.

Point 23 - It works fine here, with Ctrl-c to copy

Point 24 - No need

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-/ ?

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

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.

Point 28 - Their called application modal dialogs. Sort your WM config to put them over the window that creates them.

Point 29 - Its a Window, so its listed as such. Transients simply aren't excluded from the Window list - its a feature.

Point 30 - See 28

KDE's version is prominently displayed in the KDE Control Center, which you may wish to visit to negate many of your above points.

Failing that, rpm -qa | grep kde -

Its probably 1.1 or 1.1.x

Your bitching about lack of man pages is duly noted and ignored.

to find a KDE programs version, go to Help-About. That is one thing common across nearly all GUI's.

Don't blame KDE for Redhats crappy packaging, KDE is by default in /opt/kde, self contained except for Qt.

George Russell

Re:Dirty Laundry: What's Wrong with KDE Help

[Tom Christiansen]

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.

report card for kdehelp(1) usability tests

[Tom Christiansen]

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.

IBM had some good ideas

[Brian Knotts]

In addition to the OS/2 Workplace Shell that is oustanding to this day, back in the mid '90s, IBM was doing some good interface work that has been abandoned. Maybe some of that could be a guide for the future development of these projects.

They wanted to use a human-looking "agent," basically a little head on your screen, that would listen for your commands, and provide you with information. The agent could assist you with tasks, and could take care of tasks at a given time which you assigned previously (y'know, like cron).

Also, the ideas they had about document display with Taligent/OpenDoc were of some value, I believe.


Interested in XFMail? New XFMail home page.

Re:Using their own experience as proof of truth

[Tom Christiansen]

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.

More Dirty Laundry: ktop(1) report card

[Tom Christiansen]

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).

1. When it starts up, it doesn't choose a large enough window to display all the columns, so you must immediately resize it.

2. 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:

   $ ktop --help
   ktop [kdeopts] [--help] [-p (list|perf)]
   [Exit 0]

   $ man ktop
   No manual entry for ktop
   [Exit 1]
   

   What are "kdeopts"? Where am I supposed to learn about them?

3. 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.

4. 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.

5. 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.

6. The thing would often splat a zillion copies of

   QGDict::look: Attempt to insert null item

   on the eterm(1) that launched it.

7. 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".

8. 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?

9. 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.

10. 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?

11. Many of the commands had no string listed for their command line column. This is a bug.

12. 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.

13. You could only select one process at a time. This makes it impossible to send a signal to several processes at once.

14. 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.

15. 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?

16. 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.

17. 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.

18. 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.

19. 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.

20. 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.

21. 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:

    uid < 10
    size > 10_000
    size > 10_000 && uid != 0
    command =~ /x/i'
    command !~ /^-/'
    tty =~ /^[p-t]/'
    

22. ALT-H takes me to the misnamed "File" menu, not the "Help" menu that the display would lead you to believe.

23. 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.

24. 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!

25. 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.

Re:More Dirty Laundry: ktop(1) report card

[Tom Christiansen]

Well, I went and found a newer version, and things are... different.

On the matter of flicker, there's this nifty new technology called "curses". You see, it knows better than to do work it doesn't need to do. You might check into this. It's much more clever than this flickering crud.

You're "long standing GUI precedent" of putting things in the wrong places is hardly reasonable to a Unix person. We have no such misdirected expectations. A file menu should manipulate files. That's what its name is, and that's what it should do. I couldn't care less if Microsoft likes to put things in stupid places. If 100 million Microsoft victims jumped off a bridge, I still wouldn't follow them.

As for using the tab key to move to buttons, what are you supposed to do get them to activate, like the show tree thingie? I tried carriage return, enter, asking nicely -- what do you have to do? This is not intuitive, or else it would have worked.

Don't be grabbing my focus and locking it in. I wanted a menu up so I could type the stuff in that was on it for my original note. You refuse to let me do this. That's cruel and unusual.

As for what regular top does or does not do, you're right that some of what I asked for was an enhancement request. That's because you're supposed to make something better when you rewrite it. So far, you still haven't managed to catch up to the standard version, which is far easier to navigate and use.

You ignored my point about the confirmation not being keyboard accessible. At least in this system, I can tab between fields, but I can't hit carriage return to make them select. And this "tab around" thing just isn't all it's cracked up to be. I don't want to have to tab over to the kill process button. I want a keystroke binding for that button. Different thing entirely. And that binding really should be k by default, but I should be able to change it. You keep telling me I can configure anything. Fine. How do I do configure ktop so that when I type 'k' it executes the kill button on the current selection? And how do I fix the borked up signal choice? Where's that configuration? Is there just a file I can edit somewhere, please? It would be so much easier.

Yes, it is very important not to do use SIGKILL as the default. Your point about "but it says kill, so it should do that". Apparently you don't understand the kill system call very well. It means to send a signal to a process or process group. What that signal does varies tremendously. I as a unix user know what kill(2) does, and it's not what that button says. You should call it annihilate or something. Where's the config file to change that? By making the default the only signal that irrevocably obliterates a process, you set up a really bad precedent. If I see a sysadmin who SIGKILLs nonchalantly, I knock him upside the head. Processes have things to clean up! You give it SIGINT, SIGTERM, or SIGHUP. You have to give it a chance to shut down properly! This is critical in any admin situation. If you don't understand this, you'd better find someone who does.

Finally, the cursor keys, like pageup and pagedown, are almost as bad as the mouse for acting like speedbumps. They are not close enough to be accessed without visual confirmation, which means you have broken the link of concentration between your brain and the screen. The price of the context switch times to flick your eyes bewteen screen and keyboard, and to move your fingers from the real keyboard to the fufi keys, is clearly non-zero. It's a bad design that disrupts the flow. I cannot find those keys without 1) looking and 2) moving my hands. That just kills it for any touch typist. This is why vi bindings are best, and even emacs bindings are better than the context switches that destroy your train of thought.

And don't start with your damned ad-hominem crud again like you've already begun. I can just hear you already replying with something about how I must be keyboard-challenged or something. To the contrary: I can play Bach fugues and Beethoven sonatas with my eyes closed even when there are fast, three-octave jumps, so I'm certainly capable of finding things without using my eyes -- on a well-designed keyboard. The issue is that these keyboards you cater to and expect me to use are not designed for that kind of ease of use the way a piano is.

These extraneous, off-the-keyboard "keys" just end up slowing you down. I use a Happy Hacker keyboard, because that's all you need. The fufi keys are more trouble than they're worth.

Again and again I tell you that this stuff is not designed for anyone but victims with a pre-existing condition: Microsoft brain-damage. I explain why if you don't try to kiss up to that, you arrive at different conclusions. I explain why making things that intentionally disrespect Unix standards just pisses us off.

By only making things easy for instant users and those contaminated by MS-brainrot, and by ignoring optimizations that help out long term and professional users, you guarantee that those who use this stuff the most (long term users) will be the ones who most get rubbed the wrong way. This is a strategic error that will come back to haunt you as you keep optimizing for idiots.

More dirty laundry: kfind(1)'s kretinism

[Tom Christiansen]

Well, we're on a roll. Here's dirty laundry report #3. It's for the kfind(1) utility. It claims to be a "front-end to the find utility". It shares many of the problems of the other two programs I reviewed, but has many of its own.

1. When it first starts up, you have three word based menus. One is "File", but has nothing to do with files. Another is "Edit", but it has nothing to do with editing. Whoever decided that this made any sense was obviously on drugs--and very bad drugs, at that.

2. There's a little checkbox at the bottom that says it will "include subfolders". Subfolders? SUBFOLDERS?? Here is a folder:

   $ folder +inbox/lists
   inbox/lists+ has 3264 messages (2-4217); cur=4216; (others).

   And here are subfolders:

   $ folder -r -f
   inbox/lists
   inbox/lists/ppt
   inbox/lists/training
   

   If you mean directories, say the word. This is just something that really rankles this Unix user. It seem baby talk.

3. Once again we have a row of random happy icons that fail to make this user happy. I'm still waiting for a way to say "just give me real words, damn it, not happicons". Allegedly this will some day be fixed. Right now, it's far too cutesy to live. There are all these silly things that I have no idea what mean. I feel like I've been given some child's toy, but the toy was designed for Japanese children, and I don't read Chinese. Give me words. Words, words, words, words, words, words, words!

4. The date modified menu is completely nutty. It reads "Find all files created or modified". CREATED? Since when does the inode contain the creation time? Answet: it doesn't. This is simply wrong. You lead people to believe they can ask about creation. They can't.

5. I wanted to use the mouse to get the string "Find all files created or modified" so I could punch it into this editor session. It wouldn't let me. It was unable to grab the text. That's wrong.

6. I clicked on a file in the output. Nothing happens. I double click. Still, nothing happens. So I go up to the edit menu to figure out how to edit the file, and of course, there is no editor listed under Edit. How sweet. But there is a Copy command. Now, in my book, there's a big difference between ed(1) and cp(1), but I go with the flow. So I try to do that copy thing, but nothing happens. No new file appears. No error message appears. Nothing changes. It's like my bits went to lala land.

7. This non-copying copy command is set to ^C. This is a madness that makes makes a Unix user want to roll over and die. I have already specified that ^C is to interrupt. Interrupt. Got that? Actually, it needn't be ^C. But for me, this time, it is. The program that isn't going to respect keyboard signals had bloody well inspect my tty chars and do what they say to do. This would explain why when I accidentally launched a big find on slash that even after about a dozen ^C's the idiot program refused to interrupt the find. Damn it, this is just wrong. Talk about violating the principle of least surprise!

8. There was no "ok fine, now run your find command" button. What could possibly be more important? It should be prominently placed, with a nice keyboard shortcut like "f" for find, or "r" for run.

9. The so-called "Advanced" menu is hardly advanced. And it has all kinds of nasty problems of its own. First, it repeats the "folders" heresy. Those are not folder, those are directories. Didn't anyone teach you that it's S_ISDIR not S_ISFOLDER? Sheesh.

10. When you use the oxymoronically named "Advanced Menu" to select "files", it seems to choose only S_ISREG files. Uh, guys, that's very non-intuitive. If you think that a device or a directory isn't a file, you need to spend more time programming. Go look at the stat(2) system call for an educative experience. Now, if you mean S_ISREG files only, do please say that. Sheesh.

11. A socket (S_IFSOCK) is not a "special" file. S_IFCHR is a character special, and S_IFBLK is a block special. And just what is this "etc" noise? Don't you et cetera me. I want the specifics. Do you mean anything that isn't S_ISREG or S_ISDIR? Then say that. I don't need fuzztalk.

12. I have discover that the "at least/most N kilobytes" has a serious and idiotic bug. It thinks a kilobyte is 10**3 bytes. It isn't. It's 2**10 bytes. And where's the megabyte option? Do I really have to say 1024 kilobytes instead of one megabyte? Oh wait. You still have that bug. You mean have have to say 1048.576 kilobytes to mean a megabyte? You've got a crackhead in your house. I suggest you find him.

13. The "containing text" string is wrong. First of all, it disrespects my editing characters. Again. What is with you folks? I've stty'd myself to have ^U kill the line and ^W kill the word. I have expressed myself quite clearly in establishing those system preferences. Kindly stop being so damned anti-Unix and pay attention to your settings.

14. The "containing text" is also wrong because it's not text you seem to be asking for. It's a regex. Now, which regex library is it using? What are the rules?

15. When you use the oxymoronically named "Advanced Menu", the list of "types" you can select on muddles the difference between real file types as defined in the st_mode field of the inode, and random other things. It doesn't tell me how it is going to guess the rest. Is it going to run file(1)? I certainly hope so. Anything else is going to get wrong answers. And the list is very weird. It's not sorted. And it is missing all kinds of things that file knows about. And how to I type in my own specification? For example,

    $ file /tmp/foo
    /tmp/foo: perl commands text

    Now, how do I ask for that kind of file? Huh? Please don't tell me I'm not allowed to ask for things that the author didn't foresee. That's very un-Unixy.

16. The list of types is too long to force me to use my eyes to find things with. I should be able to type /pat to quickly find something. As it is, I have to play that stupid trick where my fingers need to leave my hands (ie, leave my home row) and my eyes their sockets (ie, leave the screen). I really, really hate that. Just slows me down. And I don't know whether I just missed seeing what I want in that big list.

17. If this is supposed to be a front-end to find, where are all the options? Where do I specify -xdev or -follow? What about -user and -group and all that?

18. How do I get regular find -ls output in the return list? That would be very helpful.

So once again, we have another gratuitously GUIfied recreation of normal tools that manages to do far less yet still have gravely serious problems. I hope you now understand why Unix users are so underwhelmed by your flash and chrome. And, I hope, you now begin to understand how you can fix it.

Re:Voice interface needs AI

[FPhlyer]

You are all making this way more difficult then it needs be. If you tell the computer "Remind me to take out the trash" the computer just needs to parse the sentence. "Remind me" tells the computer ro open up your appointment schedule. When the computer parses "Take out the trash" it doesn't need a reference to anything at all, it simply has to query for additional variables:

"When would you like me to remind you to 'take out the trash' Dave?"

"On Trash day."

"When is 'trash day', Dave?"

"Wednesday."

"When on Wednesday would you like me to remind you to 'take out the trash', Dave?

"At 6:45 AM."

"Okay, Dave, I have scheduled myself to remind you to 'take out the trash' at 6:45 AM on wednesday."

"You know, it is really disturbs me when you say my name after every sentense like that."

"I'm sorry, there was no action verb in that sentence, Dave. Would you mind stating that more clearly, Dave?"

------------------------------------------------ -

The computer does not need to know what "trash" is to remind you to "Take it out".