Slashdot Mirror
Interview: KDE Developers Answer Your Questions
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
three in one day? three in a row? damn i'm good!
Riddle Me this
huh?
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!
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.
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.
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.
"There's so much left to know/ and I'm on the road to find out." -Cat Stevens
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.
Stop spreading FUD. It really makes the GNOME project look bad.
You are not helping. Stop FUDing GNOME. You are hurting the KDE project when you do so.
The reason that KDE is so vastly superior to Gnome is because it's commercially backed.
You see the KDE developers admit that QT is their life-line, and it's obvious that gnome is lacking.
Why?
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.
QT is superior to GTK simply because it's rigidly controled by a commercial enterprise rather then a bunch of weekend hackers.
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.
What is GGI?
I'm concerend about the integrated web browser from a security standpoint, just as I'm concerned about IE being seamless with local files and remote files. Now, adding active content like java and javascript to the same application that is going to be your graphical file manager sounds like the same recipe for disaster...
IE tries to use "zones" to prevent content in one arena from compromising security in other areas. Of course, this is a flawed concept as the end user cannot decide the best settings and the default settings are too lenient. How will Konqueror keep users any more secure than IE from active content, frame spoofing, etc? I sure hope that, unlike MS, KDE folks have learned from past mistakes in design. What is Konquerer's security model? Can active content be easily disabled/controlled?
-core
Thanks, oh spineless coward, for finally explaining why Windows is superior to Linux...
not.
For example, I want to drag that CDE-ripoff of a desktop changer out of the panel and replace it with kpager. It is really annoying to have kpager hidden underneath windows on the desktop so having it dock into kpanel in lieu of the desktop changer would be way cool.
-core
Read the moderation guidelines. You should not be moderating stuff up because you like the guy's point of view, when his content is factually incorrect.
How terribly, terribly disappointing!
Some people just shouldn't be moderating. The above post was not 'Insightful', and was quite possibly a troll. Most likely, it should have just been left alone at (Score: 0).
I think it's interesting that there is no main lead programmer in the KDE project whereas there is a figure head for say GNOME (Miguel) or Linux (Linus).
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:
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.
You (Anonymous Coward-LiNuX MaN) wrote:
"SGI IRIX, solaris, hpux, and all those are just simply not scalable, reliable, and arent secure at all compared to a red hat distro."
You are clearly wrong here, just take for example the issue which is least subjective and easiest to demonstrate; scalability, the SGI systems running IRIX scale to hundreds of processors on a single image system with realizable performance and they scale to thousands on clustered solutions. Support for 64 bit addressing and file systems allow massive memory capacity and huge high performance file systems.
With RH Linux you can just about benefit from two CPU's if you patch with the latest kernel. Forget big memory addressing, forget massive high performance file systems and massive single files. If you have a specific class of problem you might be able to cobble a beowulf cluster together with relatively low bandwidth, high latency interconnect and allow custom application software to benefit. This is hardly great scalability and doesn't even compare well with Solaris or HP-UX.
I don't doubt things will improve but for goodness sake, be realistic about the work involved to get there. Even against NT there's a lot of work to be done on Linux scalability issues. Linux has a long way to go before it matches the performance of an O.S. like IRIX.
Overselling Linux like this does not help your credibility or the Linux cause and your fantastic claims of problems with other more mature operating systems are counterproductive.
Wow..that thing looks sweet according to http://www.kdeforum.org/news/936620559/index_html it will be out in November... we can only hope. Mutt is pretty nice, but this thing would completely rock.
SGI IRIX, solaris, hpux, and all those are just simply not scalable, reliable, and arent secure at all compared to a red hat distro.
I'm not sure here (perhaps someone could help me out here), but i think solaris is considered to be pretty damn secure.
sun hardware cant compete and is way overpriced. a quad xeon with linux could blow a sun e10000 out of the water. its time to get the future now... linux+intel
Now I know your on crack here. Currently linux does not scale well above 2 processors. This will probably change in the future.
you really should think a little harder befor you dish out such moronic criticism. what do you expect from an AC get an account its free
john
john
-- john
I recently was pissed off at a certain decision to use a certain Windowism in KDE. Do I bitch and moan like you seem to do incessantly?
No. I sat down a few hours and implemented a scheme that makes it easy for Unix users to get their way and those who prefer windows to get their's as well as making it easy to add new schemes. (in fact, it already was configurable, I just made it easier to provide different standards, i expect the default to remain the same)
Not approved or committed yet, but you do get the idea. It's Open Source, dude.
Is it just me, or is just a little cheesy that 90% of the KDE apps start with the letter K? I mean, I can understand Konqueror, at least it makes sense, but KPacman? KWord? Hasn't this gone far enough? Have I asked enough questions in a row? It just gives me flashbacks of the original Batman series, especially in the movie, where Adam West actually said the words "Robin, hand me the shark-repellant Bat Spray!"
I admit my post may not have been a wellspring of knoweldge. But I think I should have the ability to state my thoughts in the forum with equal footing with the people who support gnome.
I think it's unfair that slashdot lets this kind of moderation go rampant. It's unfair that I get censored because I realize that, for me (and probably everyone else) KDE is much better then gnome.
This is completely crazy. IT seems that slashdot moderators are slap-happy to censor any post telling you the bad things about gnome.
KDE is the future, censoring my slashdot post can't change that.
The desktop metaphor is familiar and "good enough" for a 2D workspace, and so I suspect that it will be the primary metaphor until such time as 3D is as cheap (in both dollars and system resources) as 2D is today. Alternate 2D metaphors may be better, but it will be hard to overcome the weight of usage enjoyed by the desktop.
Now when 3D gains primacy in a year or two, all bets are off. All it will take is a radical new input device (the mouse is inherently 2D), and a stunning new metaphor (you are in a maze of twisting passages, all alike? maybe not) and we'll be off on an entirely new paradigm.
We'll still have to do all the 2D things we do now, such as writing and drawing and calculating, but even something as two dimensional as a written document could have very interesting enhancements when presented in a 3D space.
Information is not Knowledge
How come windows has so many more users?
KDE is superior to gnome, for the same reason windows IS superior to Linux. They both have commercial backing.
I think that SUSE Linux (which is commercially controled and enhanced) combined with KDE (also commercially powered) will eventually win out over Windows and the lame hacker version of Linux.
Sometimes the truth is hard to deal with, but that doesn't make it untrue. Gnome is a doomed piece of crap, and it is inferior to KDE in every aspect.
I'm sorry that it makes you unhappy. But it's the truth.
Slashdot's moderation system is nuts!
Microsoft spends billions on R&D a year, it's obvious that integrating the w3 browser into the OS is the right thing to do.
Thats why Suse is coming out with a new Linux kernel module that accelerates X and Konqueror. Unfortunatly it's under a QT 1.x style license, that only permits it's free use with SuSE.
i don't agree with censorship, but when i want to read only the good posts because there are so damn many, i get to ignore mindless crap from people like you.
This practice is not new, it started with X programs. Really, what easier way to distinguish between various Notepad clones than xnotepad, knotepad, gnotepad, xfnotemad... etc?
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.
You should never take life too seriously - You'll never get out of it alive.
Finally someone states the emporer has no clothes. The visual shell thing sounds like a great idea. It's almost hard to believe that the STDIN/OUT/ERR paradigm has made no headway in the world of GUI's. It could be taken much farther in a graphical environment! For example, one could map individual output fields from program 1 to individual input fields of program 2. Does anyone know if there are any such visual shells available for Linux? I've glanced at some AVS pages but they only talk about commercial products for IRIX.
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Gtk+ is covered by the LGPL while Qt is covered by QPL, which is more like GPL than LGPL.
> I'm not sure here (perhaps someone could help me out here), but i think solaris is considered to be pretty damn secure.
Well, if you browse Solaris' known security vulnerabilities on (for example) securityfocus, you will see there are plenty of them. You can find 3 times as much known holes in Solaris 7 (2.7 renumbered) as, for example, in Linux Redhat 6.1 - not to mention Debian Potato. Not that this is a good way to evaluate a system's level of security, though, but that shows that assertions about Solaris being a "pretty damn secure" OS should be taken with a pich of salt...
And, yeah, despite Sunsolve, our Solaris servers were cracked a few times, using buffer overflows problems (rpc.ttserverdb) or bad security checks (ff.core) from the system.
anyway, the above post was clearly a troll.
GUI frameworks are no different. In fact, there are several high quality, truly free frameworks out there already; they simply aren't used by GNOME or KDE.
Yeah, I know. Just like I couldn't possibly be running a non-commercial kernel, a non-commercial POSIX environment, a non-commercial compiler, and a non-commercial browser, I couldn't possibly ever hope to use a non-commercial desktop.
But who, for Heaven, told you that Windoze UI is :)
good? Pick any ergonomic research out there and
you'll find M$ stuff among examples of how things
shouldn't look and feel.
On the other hand, KDE is an excellent effort to
attract current Windoze users to Linux. J. Luser
just needs time to grow and mature, to feel the Freedom,
and, trust me, if KDE is designed as good as they say,
current KDE users will transform it dramatically.
So, T.C. is right- there's nothing for UNIXoids in KDE. I'm happy with OpenLook. But that's just me
KuroiNeko
I disagree. MS Excel file formats are fairly well documented, their MS Excel Developers guide has the details for most of it.
...
Kurt Granroth's response neatly avoided answering the question. What he said boils down to :
Eventually all code will be written.
Currently the Office import capabilities of koffice are somewhere between non-existent and irrelevant. I've evaluated kspread and gnumeric as replacements for Applix & StarOffice. While kspread had several nice features (a embedable object framework that is not in alpha testing) the XL import capabilities were embryonic. At last check (2 weeks ago) it could not import formulas
gnumeric was much further along. It's XL import capabilities where rough around the edges (no GUI error reporting) but were in many ways superior to Applix (visually comparing the XL, gnumeric, and Applix sheets). Staroffice was still the clear leader in terms of functionality.
However, the unmentioned advantage to gnumeric was its set of builtin functions. It has a significant percentage of the functions offered by XL for standard spreadsheets. kspread's notion of functions was much more primitive.
Licenses and popularity aside. Gnumeric is orders of magnitude further along the path to XL compatibility than kspread is.
- 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
Now having offended everybody, I depart, chortling mischieviously
Tom, you simply jump from 'they are doing things that fit windows users' to 'they are not doing things that fit unix users'.
Now, if you would be kind enough to explain me the logical connection between those two premises, I'd be happy to engage in an argument.
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 viceversa. I'll be happy to distribute "kde docs for leftys" for you.
Finally: you apparently missed the part about this being the opinion of two people. I am one other people. I care. At least I STILL care. If you rant some more, I may stop caring, and the reason will be that it's hard to care about ranters.
Ranters should expect people to expect them to care about themselves.
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.
Which Gnome doesn't have.
QT is not proprietary, it's free software, even RMS has said so, but this crap gets a 4. What bullshit moderation.
It really pisses me off that perfectly valid posts that like KDE are moderated to 0 or even -1 no matter if they have perfectly valid points or not, and anti-KDE posts - even if they contain lies - are moderated to 2, 3, and 4. You moderators are screwed in the head.
I should be able to extend open source any way I like - including porting it to Windows. But a Windows Qt port is not allowed under the QPL. Why did this toolkit get the open source blessing?
Quake2 in text mode... Fun stuff ;)
KSpread is pretty primitive with respect to Excel compatability when compared to Gnumeric.
KDE is shifting towards allowing components to be scripted together, giving pretty much what you asked for.
Sorry to say it, but voice-recognition won't get too much better until we come up with semi-conscious AI. Context is a major part of language, and you simply can't do real voice recognition without it. (eg. How do you make the computer know when you're talking *to* it, and when you're talking *about* it?)
Voice synthesis has room for improvement, but it's pretty much in the same boat.
--------
"I already have all the latest software."
That is the point. We should celebrate our diversity, not complain about it.
We have several open operating systems (Linux, *BSD, HURD...). We have tons of open protocols and open source programs. We have the power and the freedom to choose to use whatever we like, and avoid what we don't. On the other hand, Windoze users get to enjoy Microsoft's vision of their desktop and their future (where do you want to go today?); if they don't like it, that's too bad!
If someone is not implementing an operating system, a "desktop" environment, a browser, or whatever the way you think it should be, that is your golden opportunity! Develop what you do like (or find someone who can, and persuade them to), release it to the world, and watch people enjoy your innovation. Or watch it flounder and die miserably, because it was a horrible idea in the first place. Either way, you can still run whatever you want on your own system. Don't complain that I or someone else is not building your dream product -- do it yourself (or find someone who will).
As for the effects of competing products... I say that competition improves all concerned. Usually innovation in a product comes at the beginning of the product's lifetime. If innovation enters later, check the source: it probably originated somewhere else and was copied or stolen. Changes to a product over its lifetime are largely evolutionary and predictable, unless there is a competing product to steal ideas from and try to leap ahead of.
You will say that some products will not survive the competition, and that that may not be a good thing. If the product had an inherently good idea, then that good idea will not be gone for long. If the product had no inherently good ideas, then the marketplace is better served by its departure than by its existence. That is an example of natural selection that actually, demonstrably works. (and I can't wait for it to happen to Windoze!)
Well, this should start at least a little flamewar... Who wants to go first?
The Autonomous Cow. Moo.
Because you cannot read. The QPL does _not_ disallow a windows port. Where did you get this nonsense from?
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
This sort of thing has cropped up before. And it has always been due to human error.
--
This sort of thing has cropped up before. And it has always been due to human error.
HAL9000
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???
;)
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
It has been alleged that you are in fact are a commercial customer of Troll Tech currently paying for a commercial (strickly speaking proprietary) QT license. Your attempt to pressure Troll Tech into releasing QT under the BSD license maybe an attempt to cut your costs (license fees for QT) while continuing to sell your product/services. I put it to you, are you masquerading as a free software user/developer and non commerical customer of Troll Tech. Deceiving the free software community and preying on their good will in an effort to profit. Are you or have you even been a commercial Troll Tech customer?
Heh heh. That's a good one. And Microsoft isn't an abusive monopoly, either! :)
--------
"I already have all the latest software."
Read the Fucking license. Now tell me where it says you can't port it to win32.
GNU/Linux? That's Aladdin/WINE/KDE/GNOME/SPI/BSD/SYSV/VNC/X/GNU/Linu x, mister, or just Linux, for short.
I used to call it GNU/Linux, then I realised that the GNU is obvious, because there is currently no other system that runs on top of Linux. I see where RMS is coming from, he wants credit, but until we need to say "GNU/Linux" to distinguish it from another Linux-based system, there's really no need to call it anything other than "Linux". GNU/Linux is a technical term, but the informal (colloquial?) form is, and will remain just "Linux".
--------
"I already have all the latest software."
Does anybody have a link to magellan? I never heard of it before and sure would like to check it out. I searched freshmeat and it's not there. So does it really exist or it's just a vapourware?
___
If you think big enough, you'll never have to do it.
Hmm.. I'm not sure if this is a typo or not. Konqueror does indeed handle auto-completion... are you referring to 'tab' (or similar) completion?
It's kind of ironic that you bring this up now as there is a rather lengthy discussion about completion on the kde devel lists right now. We intend to support both kinds of completion (auto and key-based) in nearly everything. Auto-completion is done where history matters (web browsing, for instance) and key completion where the files matter. By key completion, I mean hitting the TAB or End or CTRL-E or whatever key to match an existing file. Note that in KDE, we will match not only local files, but files on, say, an FTP server too.
And with everything, it's configurable.
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.
--
how to invest, a novice's guide
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.
I find it amazing that there are still people out there that don't realize that competition makes for better products... I've witnessed it so many times in so many areas (both with OSS and proprietary software) that I take it as a given. Then again, who (with at least two digits in their IQs) wouldn't?
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?
That help system you want exists. It's called KDEHelp.
Not only does it integrate man pages and KDE docs, but also info pages (for which I really hope you don't find us poor KDE people accountable).
Now, if you want such a system to be available for CLI guys, port it. It's semi-trivial.
BTW: man pages are not such system, even if we keep KDE and info pages out of the question.
Have you ever tried installing qmail's man pages on unixware? You are bound for disappointment.
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.
...the irony of someone making unreadable posts about ease of use?
*takes it to email. yeesh.*
KDE only supports 8 desktops? My machine at work currently has 3 desktops devoted to each of general stuff, a bug tracking system, and a test bench. Then there are desktops for each of the 25 projects I am working on (or potentially creating bugs in) simultaneously. Total: 28 desktops. Each of these desktops has an alphanumeric name describing the project it is intended for. I can easily bounce windows (and often do) from one project desktop to another by name using a pull down menu. I can create and name a new project desktop in a few seconds whenever I discover that the code I am working on is shared with new projects. I use Window Maker and can't live without it. ---- A possible poll topic: how many virtual desktops do you need?
...but your brevity and acidity make me think you haven't put much thought into what you'd like to argue about. It looks like you just want to argue. That would make you a troll. Die troll, die!
:-)
Have a wonderful evening.
...yellow number five, yellow number five, yellow number five...
And when he "had to go", did he say
"Excuse me, Robin, I have to go to the Bat Room...:-)
No, "commerce" won't; only companies that rely upon proprietary licensing schemes must pay.
It just doesn't work anymore. Perhaps only people with a karma of over 20 or 50 or whatever should get moderation points, and they should have to spend them in order to moderate. And if they moderate poorly, they lose additional karma, making them less likely to be able to moderate in the future.
monkeyland:-> cd /opt/kde/share/doc/HTML/en/kwm
monkeyland:-> lynx index.html
Ta da!
You are wrong saying that except memory other components do not help. Examples: If you don't have enough ram (say only 32meg) you'll be swapping (believe me). The faster is the seek time on your hd the better perfomance you will get. Also in video cards acceleration support and speed plays a role. Try doing logout on old S3 card and see how long it takes to do stiple (the "shadow" effect). And, of course, 366mhz is overkill (though it doesn't hurt). Right now I am typing this on K5-PR90, 48meg ram and 10ms harddisk - no problems.
Secondly, I used both KDE and GNOME. And I can tell you that _both_ are pretty good. What's more (correct me if I am wrong) redhat comes with gnome default. So I don't think talking that _most_ users use KDE is correct.
Lynx doesn't understand the man:/ and info:/ URLs.
So, to wrap up the general Slashdot attitudes, any software that not given a free software license ala the GPL, be they hardware drivers, office suits, video games, etc, is crap because it's not truely "free." Only when all software is free will there be peace on this earth.
If software is written and given a free license, well that's not good enough. It must also be proprietary-compatible. If you can't write proprietary software with said software, there's no hope of advancing the operating system. The only reason this software was given a license that's too free is because they want nothing but world domination, the greedy sons-of-bitches. Doing it to give free software developers an edge, shyeah, it's all a front. God forbid they go IPO, that's just further proof they are Microsoft.
Hmm, there seems to be missing a license that is free only if you write proprietary apps. I shall call this the Private General License.
Any software that doesn't suit me, need not exist and is evil. If I think every app in the world should include some feature, and some crazy developer(s) can't include said feature, well it just shows their ignorance, doesn't it? I mean, how dare they not include this feature? It is purely out of spite. Spite for me, spite for you, and spite for the rocks in my driveway.
That pretty much covers all these posts. No wonder some people are hesitant to enter into this "community."
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.
:) And despite being the inventor of the mouse, he seemed very hesistant with it, probably due to his age. )
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
This kicks ass that this many people are just talking about the developement of a opensource project !
,James Brown
This in itsself is more valuable to a software project than almost the actual codeing.
These are exciting times.
The M$ way of thinking is sufficating.
" GOOD GOD, I KISS MYSELF AH "
hi how r u 2day. i c u have good opinion, i agree!!!! windows u can play games, linux sux - only space invderz!!! LOL -MeGaGuY
That's what I thought. I didn't see a single question get close to one of the one's that I proposed, which were VERY good questions... Why the hell didn't MINE show up? I don't know, I think ./ has a conspiracy against me ;o)
yeah
ya man cde n shit for gays
y uze cde when all u get 4 themes r just stupid colorz (YA OK GREEN THEME !!! A-OK!!!)
man i havnt seen ne1 here with good sense like u b4. who r u?
newayz az i was saying linux fuckin rocks!!!!
-ALiCE CoOpEr &&
TWiStEd SiSTeR
=----=--=-=-=-=-=-=-=-----=-=-=-=-=
The best thing to happen to software this decade (or maybe since the beginnings thereof) is the Open source movement. I equate the open-source movement to evolution. While the process of development may take longer than commercially-backed projects (however, usually, it doesn't), it does lead to a finer product. When you have thousands of elements involved, interacting, some dying, some succeeding, the end product will be the best adapted to it's environment. Features and designs of a product have been put through the gambit of testing, and let the superior design win. Commercially backed projects (ie Windows) have become fat and bloated, and unfortunately, the along with Windows, the publics expectations have evolved along with it. Linux is still young. But it's future is more diverse and wide-open that any other system on the planet. q.e.d.
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:
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?
-T
The QPL does not disallow a windows port. You are free to port the QT2.0 codebase from X to Win32 yourself.
Troll's OWN port of QT to Win32 is NOT free for you to use. You, the developer, must pay a one-off fee to Troll.
This is much more reasonalbe than most licenses, which require you to pay a fee on either a yearly basis, for every different app, or (even worse) a fee on every application sold.
--
because I couldn't think of a good beginning.
- The File/Edit/Goto/Bookmarks/Options menu bar doesn't make any sense. To make a new help window, you have to go to File. What does that have to do with a file? Likewise to search. I mean, honestly -- what are you thinking? This is a general problem in all the KDE stuff I looked at. You keep putting things in really non-intuitive categories. I mean, get serious: you've got "System", "Settings", and "KDE Control Center". Those make no sense to me. Why are some programs in one of those categories, but not another? What's the difference? "Applications", "Utilities", and "Internet". How am I supposed to look one place and not another? What's the difference between a program that's an "application" and a "utility"? And what about "Graphics", "Multimedia", and "Internet". Why aren't the graphical programs under Multimedia? Why is local user information (finger config) listed under "Internet"? Don't tell me "oh, you can edit those". The defaults should be sensible. These aren't.
- There's a "search" under File, but then a "find" under Edit. Why is there even an Edit button? How can I edit anything in static documents?
- Also under the File menu is some "Close" command. But when I used it, it didn't close the file I was viewing, which is what you expect a "File/Close" command to do. The other meaning of close, iconify, was actually what I was expecting. But guess what, the KDEhelp wasn't iconified. It was completely destroyed without warning or confirmation! You should choose a better word there. People who use the word "close" to mean iconify will keep killing things. On the other hand, "Destroy" (or perhaps better, "Exit") and "Iconify" aren't ambiguous.
- The next line, the one with happy icons on it, is not intuitive. How do you disable the pictures and turn on just the words, the way you can in netscape?
- It appears that you use the same happy icon in the KDEhelp window to indicate "reload current document" as you use in another menu to "rearrange icons". What the devil is this overloading about? This cryptohieroglyphic system doesn't help anyone at all. What does that bitmap mean? Why does it mean something totally different elsewhere? Why aren't there words?
- You can't use the regular keyboard for paging activity. I tried everything I knew. I used SPACE, BACKSPACE, ^F, ^D, ^B, ^U, B, F, b, f, ^J. Nothing works. This is not intuitive. How do I make it follow the conventions of less(1)? Even netscape recognizes space and backspace for going back and forth by a screenfull. This is what I mean about discriminating against people who can actually touch type.
- The cut-and-paste system doesn't by default work like xterm. How do I change that setting? The reason I need to do this is because your defaults are very week, but less powerful than I'm use to. It doesn't seem to follow the model of index-finger clicking once for a character, twice for a word, and thrice for a line. Even netscape can do this. Why can't you? And once you've grabbed a word (for example) you can't use the ring-finger click to delineate the word at the other end.
- In KDEhelp, you make the user guess whether something is, whether it's in man, kde, or info format. How is the user supposed to know? That's not nice.
- The presentation of available man stuff is just nowhere near reasonable. For example, choose section 1. You get a zillion names of commands. 964 of them, in fact. I can't visually search a thousand different things like that.
- You don't provide the whatis description of each man entry in that listing. That means the user has no way to guess what the page is about. That information is important.
- When it comes to choosing a section, you ignore both the users MANPATH setting and the operating system's default. That means you can't find, for example, ssh which is in
/usr/local/man. settings from the /etc/man.config file. (Actually, that file's name and syntax varies depending on your operating system, even within the family of operating system. Redhat Linux puts it under name, SuSE Linux puts it another name, and Debian Linux puts it in a different name still. And these actually have different parses, too. E2MANYLINUCES. Sheesh. But they're not alone. FreeBSD has its own notion of where to put the config file and how it parses, and this is different OpenBSD's notion of the same. And please don't talk to me about Solaris.) But the point remains that you have to respect the local configuration, or else you aren't actually doing what you say you are. - The output format is alphabetized on the X axis instead of on the Y axis the way it should be for convenient reading. People want to read down columns, not across rows. Why? Because it's a lot faster. If you keep going across the rows, you have to do a carriage return with your eye constantly. It's all back and forth and back and forth and back and forth. But going down the columns, you don't have to do that.
- So, your program doesn't understand man trees, whether in MANPATH or in the system config file. This is a problem, because you can't tell which mantree the hits came from. Also, you aren't able to limit you search to just locally installed stuff versus the standard operating system, etc.
- On the "Keyword Search", on the other hand, it does seem to respect your local conventions. It's also quite fast. I'll bet that's because it's just running apropos directly, which is more clever by half.
- The "Keyword Search" takes forever (ok, a very long time) when specify KDE documentation. Once again, you make people know where things should be.
- The documentation search, when you specify manpages, doesn't distinguish between the whatis database and the raw data. How do I say which one I mean?
- You do not provide a "word boundary only" search option. You don't tell people whether they can use a pattern match, but even if they can, would that be a \ or \bword\b?
- The return list is not helpful. It is not sorted in any understandable fashion. It does not show any of the line or sentence that matched. It contains redundancies. For example, one set of returns looked like this: But those are not really to the same places. They just have the same title. It looks like they did a full body search, but I can't tell.
- When you follow one of those links and return via the left arrow (hey, how does that play in right-to-left reading places?), it runs the whole damn slow search again! This is nutty. The KDEhelp window should cache those results. And why does it do a manual search anyway? Why don't you have a quickly searchable text corpus database index that's pre-generated by the system?
- When you hit the left-arrow to return to your search, you have lost the string that you were searching for. It's gone from that window. In fact, so are the button settings.
- I sometimes managed to get the Search window in some state where I couldn't just hit ENTER to launch the search, but had to use the silly mouse to push a button. I didn't figure out how to reproduce that consistently.
- In the Search window, you're sitting there typing something, and you hit ^W to back up a word (those are in my stty settings). Guess what? IT DESTROYS THE WHOLE WINDOW! Did you hear what I just said!? You don't get asked permission. It just destroys it. You lose all your state, your forward-back list, and your sunny and pleasant disposition. This is completely evil.
- I've tried to mouse grab from the KDEhelp window and paste it into the Find window. But I can't do that. It seems to have its own separate buffer system. This is very confusing.
- There's no "Clear" on the Find window to help with cut and paste.
- When you want to do a search, you have to hit ^F. How do I make that be a slash instead?
- When the find window pops up, it doesn't have the focus. Instead, you have to searching for it with the mouse. That's a waste.
- You can't use your normal editing characters in that little box it gives you. I tried ^U (my kill character), but was ignored. I tried ^W (my werase character), but was also ignored.
- If you already have a "Find" window up, but it's exposed, you don't realize this. You sit there in the KDEhelp window hitting ^F again and again, but absolutely nothing happens. There's no new find window that appears, no beeping, no flashing, and no raising of the existing window that you don't even know is open.
- The Find window is named "kdehelp". That's what shows up in the title bar and in the icon manager. That's not a good name, because it's not really the kdehelp window. It's a transient Find window managed by KDEhelp. Why is it even showing up there in the icon manager?
- When a Find fails, it pops up a "Find Complete" confirmation window. And this one is also without the focus, so you have to go chase it down with the mouse. That's crazy. You have nothing else to do. It should have the focus. You can try scrolling the KDE help window on your own, but it completely ignores you. It refused to do anything until you take your mouse and attack the Find Complete window. With a vengeance.
Consider this a bug report. The operating system is Red Hat Linux release 6.0 (Hedwig) , standard installation. I couldn't figure out how to report KDE's version: But it was the standard Redhat OS from VA, so you should be able to guess.While we're at it, what is that X11 stuff doing in /usr/bin? You aren't supposed to do that, you know. Otherwise you make non-X11 people suffer the search costs that they don't need. Help, /usr/bin has more than 1400 entries in it on this Redhat OS from VA. Somebody wasn't thinking: Linux is notoriously bad with large directories. Please don't contribute to this problem.
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.
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.
It is funny how some people think that repeating a lie will make it the truth, this one is great: 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. On what basis does he make this claim, some votes on you favourite desktop polls? If that is the case he should know that those polls go either, way. With Gnome comming out on top more often recently. I am not claiming that the opposite is the truth, but as of yet no hard evidence of desktop domminance is out there, either way.
The truth is that most users come to linux.. especially newbies to have a different feel with the desktop.. and to present it in the same way is a big turn-off... why do u need to have a juss another desktop that functions juss the same way.. while u have had more experience with the former one..
- When it starts up, it doesn't choose a large enough window to display all the columns, so you must immediately resize it.
- It complete ignores attempts to divine its version number. ktop -v, ktop -h, ktop -version, and ktop --version all are completely ignored. That is, it just pretends you didn't give it any options, accepting those that it didn't understand. This is simply brain-damaged and wrong; call it a bug.
- The column for SHARE always has 0 in it. Regular top(1) produces correct output on the same system, so it's not as though that information were unavailable. This is obviously a bug.
- The screen refresh is set to epileptic strobe mode. It clears the whole thing and rewrites everything, even though it doesn't have to. Just set it to fast update, and you'll feel start to get a really bad headache. This is not evolution; this devolution. Regular top(1) knows better than to do this to you. Only update the things that have changed! And don't clear it all first.
- After running for a while, I got this: And the program proceeded to die of a SIGABORT.
- The thing would often splat a zillion copies of on the eterm(1) that launched it.
- I couldn't find anyway to use the keyboard to get to the buttons at the buttom, like "show tree", "all processes", "refresh now", and "kill task".
- In regular top(1), you can use the space bar for an immediate refresh; that is, to get the next screen as you would in more(1) or less(1). You can't do that here. Why did you omit this simple intuitive interface?
- The default kill(2) signal down on the bottom is a SIGKILL. That's not a good idea! You should default to SIGTERM, just as kill(1) does. Save the big stick for a last resort.
- The happy little icons next to the program name doesn't seem useful. The bitmaps must have made sense to someone, but by and large, most of them mean nothing to me. And they're too small to read in many cases. Plus you can't even sort on them. And the dumb program uses some little blue sunburst for anything it doesn't know about. That's useless eyecandy. How do you turn those silly things off?
- Many of the commands had no string listed for their command line column. This is a bug.
- I couldn't seem to manipulate the menus using the normal keyboard as promised. I can hit ALT-R to get the Refresh-Rate menu, but then it offers things I can't get at. It suggests "Manual Refresh", "Slow Refresh", "Medium Refresh", and "Fast Refresh". But there's no underlined letter to tell me what to type. I tried M, S, and F, but that did me no good. I could type ENTER, but not ^M or ^J. And I couldn't move up and down the menu using either vi(1) or emacs(1) navigation sequences: j and k were ignored, as were ^N and ^P.
- You could only select one process at a time. This makes it impossible to send a signal to several processes at once.
- If you turn on tree mode, you can collapse and expand hierarchies. If you selected the collapsed node, such as an entire process group, and send a signal, it still just uses a single kill(2) on the top process rather than a multicast kill(2) to all of them, or perhaps better, a killpg(2). I couldn't figure out how to get process groups to even display, let alone how to affect them.
- You have to use ALT-P to get at the process killing list. A simple `k' would be much easier, and more intuitive. How do I create that shortcut?
- After an ALT-R or ALT-P or whatever, my focus is held prisoner, locked to the menu selection. That's quite rude. Definitely a bug.
- The signal list that ALT-P provides you is very limited. It only allows SIG{INT,QUIT,TERM,KILL,USR[12]}. Last I checked, there were plenty of other signals, including highly useful ones like SIGHUP. It doesn't allow you to type in a signal name or even signal number.
- The signal list that ALT-P provides you has incorrect expanatory text.
- It claims that SIGINT is a Control-C. Well, maybe. Actually, Control-C is going to do the whole process group, and this isn't. Also, it ignores my stty(1) settings again. I tested this like so: stty intr ^g; ktop But the message still said that SIGINT was Control-C. That would be wrong.
- It claims a SIGQUIT is a "core". Huh? Do you really think that means something to people? Anyway, it's wrong. I always run setrlimit(2)ed to 0. So some things certainly wouldn't core. Also, setuid(2) programs wouldn't core, either, or that would be a security problem. In any event, it's hardly the only signal that normally generates a core dump. So do SIGILL, SIGTRAP, SIGABRT, SIGEMT, SIGFPE, SIGBUS, SIGSEGV, and SIGSYS--according to my signal(3) manpage.
- The note for SIGTERM is "term."--how useful! Is that the best you can do?
- The note for SIGKILL is "term."--hold on! That's the same as the previous note's. This is wrong.
- You should use real signals with real explanations. Here's from the manpage:
- What about an option to kill insistently? You know, send a polite SIGTERM or SIGHUP, give it some time, and if that doesn't work, send it a SIGKILL.
- There's no search mechansism. It would be nice to be able to apply a filter expression, like to select only certain command names. If you wanted to make it really useful, you'll permit a filter that took a real expression, such as:
- ALT-H takes me to the misnamed "File" menu, not the "Help" menu that the display would lead you to believe.
- What is "quit program" doing in the File menu? What does exiting a program have to do with accessing files? This makes no sense at all. Why isn't it just ALT-X for eXit, or ALT-Q for Quit? Why is it ALT for anything? The program isn't doing anything else with those keystrokes. Just skip the ALT entirely.
- When you use Kill Task, it pops up an annoying confirmation window. That's bad enough, but it has the audacity to force you to drag your mouse up to the window, because it doesn't have the focus. You definitely have lots of incorrect focus problems in KDE, you know. And even once you're there, you have to use the mouse, because the keyboard is useless. You can't use C for continue or A for abort. You have to use the damned mouse. Put the thing in focus, and let me type. Sheesh!
- These stupid confirmation windows are unESCable. At least the ALT-x menus pay attention to that. This is inconsistent. Screw the confirmation windows. If I wanted my hand held, I'd be on a date, not a computer.
As you see, ktop is not as useful as even good old top(1) is, and is much harder to work with. I think it's pretty obvious that this program, like kdehelp(1), isn't ready for prime time. I find that every one of these KDE GUI things are much better at impressing people who don't have to use them. And those that are copies of existing tools always seem prettier but less functional than the originals. Who cares about pretty if it doesn't get the job done? What I'm saying is that they've paid a lot more attention to chrome than to power. This is why you need usability testing.I did finally find something it paid a small about of attention to: ktop --help. But that wasn't very helpful:
What are "kdeopts"? Where am I supposed to learn about them?Even if you were do that for only those four signals you permitted, it would still be better.
While KDE may not be the power user's desktop, it's great for the Windows-Linux transition.
My computer is an antiquated 486. For some reason, Windows 95 refuses to run for more than a few hours without crashing, corrupting the registry, and saying nasty things about my mother. I needed to word process, access the internet, my parents needed to use Quicken, and I was at my wit's end. In desperation, I reinstalled Windows 3.1. I still suffered the GPF's, the random crashing, and general unusability, but at least it ran. Eventually, I heard about Linux, and hastily installed it.
KDE gives me a full-featured desktop, and one that's pretty close to what all the Windows and Mac lusers are running. I can run the latest versions of Wordperfect, Netscape, etc. I can turn on my computer and be confident it won't crash. KDE may not be the end-all be-all desktop, but, as a former Microsoft user, I feel comfortable using it. Things work basically the same as they did in Windows, so I can get used to the Linux way of doing things without having to use a completely foreign environment. If it hadn't been for the Windows-ness of KDE, I probably would have given up on Linux.
- 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.
- There's a little checkbox at the bottom that says it will "include subfolders". Subfolders? SUBFOLDERS?? Here is a folder: And here are subfolders: If you mean directories, say the word. This is just something that really rankles this Unix user. It seem baby talk.
- 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!
- 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.
- 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.
- 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.
- 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!
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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?
- 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, 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.
- 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. - 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?
- 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.This approach to assembly has been tried before. Take a look at an old Kinetix product called Hyperwire. It was a Java dev tool aimed at users. Similar to using Visio to program. I don't know what happened to that product, but it might be a good jumping off point.
Constructive criticism is a good thing, but you're just being silly.
You're crying "Discrimination!" against people with non-Windows backgrounds. That's like saying a company that manufactures washing machines discriminates against people who grew up washing their clothes by hand.
If you're so intent on snubbing your nose at KDE (and GUIs in general it appears), why don't you just stop running X and live solely in the world of the command line?
I come from a Windows background and I MUCH prefer Linux, despite being a bit frustrated with it at times. I have to say that some of your claims seem hypocritical to me. You complain that many aspects of KDE's design are non-intuitive, but look at Unix! grep? cat? emacs? How intuitive is that? There's a mount program called "mount", but the unmount program is called "umount". That's not very intuitive. In fact, it discriminates against people who grew up having to spell words correctly.
One person's sense is another person's nonsense. Linux people want everyone to use Linux, but the only remaining people not using it are predominantly Windows and Mac users. You can't gain their favour without bending to their needs and wants. This is what I believe the KDE team is trying to do. *nix veterans (such as yourself) may not like this inevitable turn of events, but hey, you don't have to use KDE. Or Gnome. Or any GUI. You can just use the command line if you want. Isn't Linux great?
I have only recently converted over from Windows to Linux. Why I did so was because I was plain sick and tired of the drudgy boring limited features of the Windows desktop and OS. What KDE writes about porting for Windows users is very insulting and well I think stupid. I came to Linux (which I love dearly now) for a change... a better OS with limitless potential and the knowledge that I can configure it exactly how i like. KDE is good but GNOME may be a better alternative in the long run. I left Windows to find a better alternative... If KDE and or other X clients want to take the drudy M$ approach. Whats the point of converting. I really hope Linux doesnt beome another M$ style "innovation"
You are obviously a true *nix master.... one who edits with VI and uses the keyboard for everything. So why use KDE? If you need a window manager, if you need to run X programs... try blackbox! Sorry, I don't have a URL handy, but try blackbox.themes.org. Blackbox is small, minimalistic, and still nice-looking. Not sure about Minimize vs. Iconify... it shows iconified tasks in a menu rather than on the desktop. I usually just double-click the title bar to roll it up and get it out of the way. KDE is designed for two types of people: Windows users who are trying to (slowly) learn Linux (not that KDE helps by isolating them from the shell), and for Linux users who don't like the CLI. I like themes and pretty pictures too, but I can get all the pictures I want by running an Eterm on Blackbox. Much more system-resource friendly. --- I'm not anonymous. I'm me!