Slashdot Mirror

Looks like these guys made a tool to do the JS detection: http://www-rsec.cs.uni-tuebingen.de/laskov/papers/acsac2011.pdf

That means new languages should probably be at least a little C-like [... it should use] curly braces and cryptic operators [...] Furthermore, new languages should support familiar programming styles

What's the point of using a new language then? I found it liberating to get rid of the (function(){...})() cruft with the switch from Javascript to Coffeescript. According to TFA's philosophy, Coffee does it wrong because it alienates Javascript users. What would be the point of using it if it only offered "baby step" enhancements, at the expense of needing a Javascript interpreter/crosscompiler?

Or to say it with Alan Perlis:

19. A language that doesn't affect the way you think about programming, is not worth knowing. (Epigrams on programming -- original page seems down)

I lately had to present a paper dealing with these retina implants from Germany. It is quite amazing what can be done.
To have a quick view on what was possible there are some videos as additional material: Videos

B. The presence of ancient gold-and high-carbon-silicon steel making in almost all the coastal Mediterranean nations while their neighbors could only attain bronze. Many of these gold-and-steel-producing cultures were far-removed from each other, the only apparent link being their coastal Mediterranean location NB: metallurgical tech has always been connected with high culture. Think armor and armaments as well as jewelry.

(1) You indicate that Wells' story is set ten thousand years ago. Iron smelting wasn't a widespread technology around the Mediterranean until ca. 1300-1000 BCE.

(2) Finds of iron around the coasts of the Mediterranean and Black Sea and up major rivers such as the Danube are much more easily explained by trade than by an unsubstantiated hypothesis about sea level 7000 years earlier. It is independently known that sea- and river-trade were extremely extensive in the latter half of the Bronze Age. (See e.g. several of the maps reproduced in this lecture by the former excavator of Troy, esp. figures 46-51.) Iron was traded by sea and river even for a few centuries before smelting became really widespread.

(3) It is hard to tell what neighbours you are referring to who only had bronze. If the neighbours you refer to dwelled at a distance from major sea/river trade routes, it wouldn't exactly be surprising if they didn't have access to a heavily traded technology. Lack of trade leads to lack of iron, not the other way round.

Epigrams on Programming by Turing-award laureate Alan Perlis.

• Wikipedia on The Hitchhiker's Guide to the Galaxy
• Citizendium on The Hitchhiker's Guide to the Galaxy

Most CS instructors will cram down students' throats that if they concentrate on principles they can pick up any language/platform as if it's nothing at all. It's a lie, but that's what they say.

They actually aren't lying, although they might not be teaching principles as effectively as they could.

Alan Perlis once said that any programming language which doesn't change the way you think, even a little bit, isn't worth knowing. Most languages fall into this category: assembler, C, C++, Lisp, Scheme, ML, Perl, Smalltalk, etc. But I've talked to a number of people who learned Java after learning another object-oriented language, and not one of them thought that Java changed the way they think.

Java is a very useful language, as much as I personally dislike it. Its biggest theoretical weakness (the fact that the module system is conflated with the object system) is also one of its biggest practical strengths, since it localizes any problems which mediocre programmers could cause.

But this also makes Java a terrible language for teaching the principles of object-orientation. I can't tell you the number of people I've talked to who are convinced that encapsulation is by far the biggest benefit of OOP. I've tried to explain to them that there are certain things you can do in five minutes in object-oriented languages, like having run-time polymorphism, that would take you weeks to write and troubleshoot in C (although I hope that no one in their right mind would try to roll their own vtables anymore). Even C lets you do encapsulation -- you just declare "public methods" in the header file -- but C clearly isn't an object-oriented language, is it? Alas.

But anyway, my point is this: If the only language you ever learn in school is Java, learning additional languages will take a lot of work. But if you learn (like we do at Brown) Scheme, then ML, then Java, then C and C++, and then take a course where you write a fair number of programming languages yourself, you will be well equipped to learn whatever you need to. Yes, some schools pretend they're teaching "principles" when they're really teaching Java, but that's the fault of the school, not the idea.

Side note: If you really think that using C for everything will make it easy for people to understand your code, then you might want to come out from underneath your rock. There have been a huge number of advanced in programming languages in the 30 years since C first came out. For one, OOP is actually useful for many problems (again, you don't actually write your own vtables, do you?). Also, consider a language like Python. Not only does it support first-class vectors and hashtables, but it supports list comprehensions:


>>> [x**2 for x in range(100) if x**2 in range(100)]
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]


I would call that clear, wouldn't you? The equivalent function in C (and I apologize if my syntax is wrong) would take significantly longer, especially considering you'd have to include a list library.

C may be simple, but that doesn't mean code you've written in it is easy to understand.

Nothing as I can see it. It's still perfectly legal to link to copyright violating material in Sweden.

We already have something called transcranial magnetic stimulation. See:

http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumb er=1300793
http://groups.csail.mit.edu/vision/medical-vision/ surgery/tms.html -- most relevant to discussion, has section on visual signal injection
http://www.biomag.hus.fi/tms/
http://www.mp.uni-tuebingen.de/mp/index.php?id=94
http://en.wikipedia.org/wiki/Transcranial_magnetic _stimulation
http://pni.unibe.ch/TMS.htm

See here and here.

Here is an article about the legality of linking to illegal content. Court decisions are mixed, to say the least.

Some choice quotes:

• " If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don't enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won't be enough. "Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter" says Eric Raymond, author of The New Hacker's Dictionary. One of the best programmers I ever hired had only a High School degree; he's produced a lot of great software, has his own news group, and through stock options is no doubt much richer than I'll ever be.
  
• "This assumes that some people already have the qualities necessary for being a great designer; the job is to properly coax them along. Alan Perlis put it more succinctly: "Everyone can be taught to sculpt: Michelangelo would have had to be taught how not to. So it is with the great programmers".

Personally, as a person who contracts and hires hackers, my experience is similar to Norvig's. The best people I've worked with have often not gotten a degree or gone to a "no-name state school."

On a separate point, the worst developers I've ever had to work with were MIT grads. Arrogant pricks who neither understood engineering nor teamwork. People who have been in the industry longer than I have said MIT hackers have long had reps for not playing well with others. Other "top" schools aren't that much different.

http://bioclox.bot.biologie.uni-tuebingen.de/Html_ we/Buch/current/node53.html

A prey population without preditors will grow until the food supply is exausted, then their population will crash suddenly. Preditor populations grow slowly in comparison with prey populations.

-Phantom of the Operating System.

If in doubt, it's spam. Simple rule, really. If some company really wants to report that my "Payment is past due" they'll send me a letter. Besides, most corporate contacts aren't going to be named "kaislyais." It takes a split second to make this judgment.

Maybe you are smarter than the average spammer, but you need to prove it. When you produce your magical filter, I'll consider your intellectual prowess.

You make it sound like I was claiming to be the world's statistical NLP expert. Yes, I have my own ideas, along with hundreds of other people. In general I think it's a safe bet to say we're smarter than spammers. I'm not really interested in proving anything, since I never intended this to be an IQ competition. I don't think it's big-headed to assume I'm smarter than a slimeball.

As for the magical filter, it isn't magical, and it already exists. As I said, PC hardware severely limits the kinds of algorithms that we can use without making the user impatient. If you'd like to run it, I'll gladly send it to you, but don't expect me to document anything, and don't complain about the run time :-)

Currently I use a hybrid filter which uses a word clustering algorithm to concentrate the information which flows into a feed forward neural network. Currently I'm examining the use of SOMs instead of feed forward networks to automatically generate document classes. I'm also looking into ways to use the neural network as feedback to fine-tune the clustering algorithm.

I believe these blends of statistical and information-theory techniques with "sloppier" systems like neural networks will become more and more valuable as people continue to research them.

As I said though, it's a research project which means it has no documentation and the training process is laborious and not yet automated. It's not the kind of thing you install on a mail server and just forget about. I'm more interested in the filter than the mechanics of getting it integrated into mail systems.

> 1. As a hiring manager, unless you go to a school I've heard of, in an English-speaking country, I'm probably not going to think very highly of your degree.

Your loss, but no offence. How many schools have you heard of?
A major difference between universities in the US and in some European coutries, is that European universities have to meet some standards to call themselves "University". The US has the best universities in the world as well as the worst. Countries like Germany, France, the Netherlands and Belgium try hard to prevent self-proclaimed so-called universities from giving the official -- usually state sponsored -- universities a bad name. This knowledge may help unexperienced hiring managers to judge foreign degrees.

Of course, what ultimately matters is a person's skills - which are only indirectly related to the person's school. IMHO it's not too hard to get a degree on a "good" university with average skills while I've met several excellent techies with an MA degree from a "dubious" university.

If you're a techie already, go to a place where they don't teach "just" software engineering or computer science. Learn to do something useful with it. I'd go to one of the Edniburgh departments if I had a chance (sniff). Tubingen has a briliant group cognitive science / language. Amsterdam has rising star Johan van Benthem.

These pictures will explain it all (the girl in red)

Pic #1
Pic #2

A very funny Brazilian comic.

Apparently Tuebingen shall the rendering code that uses Qt.

More relativistic flight sims and visualizations:

Visual distortions around black holes

Visual effects of special and general relativity.

And finally, an oh-my-God particle - a proton with the mass of a bacterium, the kinetic energy of a brick dropped on your toe, and which, if it were a spaceship, could make it to the edge of the universe in a week and a half (ship-time, that is!).

The universe offered to us by science isn't just stranger than we do imagine. It's stranger than we can imagine. The universe of the mystics and new-age hucksters is positively boring in comparison.

More relativistic flight sims and visualizations:

Visual distortions around black holes

Visual effects of special and general relativity.

And finally, an oh-my-God particle - a proton with the mass of a bacterium, the kinetic energy of a brick dropped on your toe, and which, if it were a spaceship, could make it to the edge of the universe in a week and a half (ship-time, that is!).

The universe offered to us by science isn't just stranger than we do imagine. It's stranger than we can imagine. The universe of the mystics and new-age hucksters is positively boring in comparison.

Though you do bring up a lot of good points, I would like to point out, that most of your problems can be avoided, mostly by clean design.
I cannot tell all the details because it's too far back now and I wasn't the one who did all the hard work, but maybe you should check out this link, they implemented GUI and threads and all the stuff I was talking about, so it *can* be done. If you have trouble with German (which I assume most on this site have), this is the link where you can download it directly.
One final note on your In any case I cannot see any way a journal can avoid locks: To a certain extent this probably depends on how you define a lock. The traditional locking system I was talking about differs from the journal approach in the respect that you don't need locks because you pass the atomic operations to the journal-thread which deals with putting it in the right order. Since only this journal-thread is allowed to update/read data nothing else can interfere and the data stays consistent.

Though you do bring up a lot of good points, I would like to point out, that most of your problems can be avoided, mostly by clean design.
I cannot tell all the details because it's too far back now and I wasn't the one who did all the hard work, but maybe you should check out this link, they implemented GUI and threads and all the stuff I was talking about, so it *can* be done. If you have trouble with German (which I assume most on this site have), this is the link where you can download it directly.
One final note on your In any case I cannot see any way a journal can avoid locks: To a certain extent this probably depends on how you define a lock. The traditional locking system I was talking about differs from the journal approach in the respect that you don't need locks because you pass the atomic operations to the journal-thread which deals with putting it in the right order. Since only this journal-thread is allowed to update/read data nothing else can interfere and the data stays consistent.

If you *have* to play MP3's on that old 486, though, mpg123 runs on the command line. A Windows port is avaliable here

the university of tuebingen (germany) uses linux for their computer pools and some of their servers. They are using linux clients, with kerberos authentification and a home on an afs-server.
if you have a question i guess you could send an
email to beratungatzdv.uni-tuebingen.de.

cheers TheSegfault

Don't forget to visit Stefan Bechtold's Link Controversy Page that has links to legal articles, cases, technical solutions, link license agreements, hyperlink patents and related stuff.

Of course there are GUI's. There is the Commond Desktop Environment (much too exensive), Looking Glas (not too expensive but not really the solution), and several free X-Filemanagers that are almost GUI's. Moxfm for example is very well done, but unfortunately it is based on Motif. Anyway, the question is: What is a GUI? What should a GUI be?

First of all, since there are a lot of missunderstandings on this topic, what is NOT a GUI:

• the X-Window-System is NOT a GUI. It's what its name says: A Window system
• Motif is NOT a GUI. They tried to create a GUI when they made Motif, but unfortunately they couldn't really agree, so they released Motif as Widget-Library with a Window-Manager. Much later they completed Motif with the CDE, but too late, since Windows already runs on the majority of desktops.
• Window-managers are NOT GUI's. They are (better: should be) small programs that handle the windows. It's not really the idea to hack a lot of stuff into them.

IMHO a GUI should offer a complete, graphical environment. It should allow a users to do his everyday tasks with it, like starting applications, reading mail, configuring his desktop, editing some files, delete some files, look at some pictures, etc. All parts must fit together and work together. A nice button with a nice "Editor"-icon is not at all a graphical user environment if it invokes "xterm -e vi". Maybe you have been disappointed long time ago too, when you installed X with a nice window manager, clicked on that beautiful "Help"-Icon ... chrk chrk (the hard disk)...an ugly, unsuable, weird xman appeared on the desktop :-( A GUI for endusers The idea is NOT to create a GUI for the complete UNIX-system or the System-Administrator. For that purpose the UNIX-CLI with thousands of tools and scripting languages is much better. The idea is to create a GUI for an ENDUSER. Somebody who wants to browse the web with Linux, write some letters and play some nice games.

I really believed that is even yet possible with Linux until I configured my girlfriends Box. Well, I didn't notice anymore that I work with lots of different kind of menues, scrollbars and textwidgets. I already know that some widgets need to be under the mouse when they should get the keyevents, some sliders wants the middle mouse for dragging and some textwidgets only want emacs-bindings and don't understand keys like "pos1" or "end". And selecting some text is different everywere, too. Even the menues and buttons (for exampel Xaw, Fvwm, XForms, Motif) behave completely different.

One word to the Athena-Widgets: Although there are a few nice applications available that uses these "widgets" we should really get rid of them. Thinking that "Athena is a widget-library" is a similar missunderstanding like "X is a GUI". Athena is an very old example how widget libraries could be implemented with Xlib and Xt. It's more or less a online-documentation for Widget-Set-Programmers, but not a tool for application-programmers. Unfortunately, the old Unix problem, a so good online-documentation that people used it for applications.

So one of the major goals is to provide a modern and common look&feel for all the applications. And this is exactly the reason, why this project is different from elder attempts.

Since a few weeks a really great new widget library is available free in source and price for free software development. Check out http://www.troll.no

The stuff is called "Qt" and is really a revolution in programming X. It's an almost complete, fully C++ Widget-library that implementes a slightly improved Motif look and feel, or, switchable during startup, Window95.

The fact that it is done by a company (Troll Tech) is IMO a great advantage. We have the sources and a superb library, they have beta testers. But they also spend their WHOLE TIME in improving the library. They also give great support. That means, Qt is also interesting for commercial applications. A real alternative to the terrible Motif :) But the greatest pro for Qt is the way how it is programmed. It's really a very easy-to-use powerfull C++-library.

Qt is also portable, yet to Windows95/NT, but you do not have to worry about that. It's very easy to use UNIX/X specific things in programming, so that porting to NT is hardly possible :-)

I really recommend looking at this library. It has IMO the power to become the leading library for free software development. And it's a way to escape the TCL/TK monsters that try to slow down all our processors and eat up our memory...

It's really time yet to standarize the desktop somewhat. It's nonsense to load 10 different widgets into memory for the same task. Imagine this desktop:

• fvwm (own widgets)
• rxvt (own widgets)
• tgif (own widgets)
• xv (own widgets)
• ghostview (athena widgets)
• lyx (xforms widgets)
• xftp (motif widgets)
• textedit (xview widgets)
• arena (own widgets)

One may argue that a usual UNIX-Box has enough memory to handle all these different kind of widgets. Even if this might be correct, the really annoying thing is, that all these widgets (menus, buttons, scrollbars, etc.) behave slightly different. And this isn't only an academic example, I've really seen such desktops :-}

I know we couldn't get rid of this chaos at once, but my dream is a coexistance between Motif and Qt. The Kool Desktop Environment (KDE) I don't have the time to do this all alone (also since LyX is my main project). But a thing like a Desktop Environment can easily be cut into lots of parts. There is very probably a part for you, too! If you want to learn some X-programming, why not doing a small, neat project for the KDE? If you know others who like to programm something, please prevend them from writing the 1004th tetris games or the 768th minesweeper clone ;-) Think we also have enough XBiffs yet...

So here is my project list so far. Probably there are even more things to do that would fit great into the KDE. It's a very open project. Panel: The basic application. Run's as FvwmModule (at the beginning). Offers a combination between Windows95 and CDE. I think about a small taskbar at the bottom and a kind of CDE-panel on the top of the screen. The panel has graphical icon menus on the left (similar to GoodStuff) to launch applications, 4 buttons in the middle to switch to other virtual desktops and few icons for often needed applications on the right. There is for example a mail-icon that also indicates new mail, a wastebasket to open the delete-folder (that also indicates when it isn't empty and is capable of drag'n'drop). Maybe a analog clock with date at the very right. Also a nice special icon for exiting the environment or locking the screen. All the stuff is completly configurable via GUI. I'm also thinking about solutions, that only available applications can be installed on the desktop and that new applications appear on the desktop automatically.

I started to work on this panel, but would of course love some help. There are also lot of smaller things to do, like a tool to chose a background pixmap (for each virtual desktop) etc.

Also nice icons are needed!

Filemanager Another major application inside the KDE. The idea is not to create a powerful high-end graphical bash-replacement (like tkdesk tries to be), but a nice looking easy-to-use filemanager for simple tasks. Simple tasks are mainly deleting some files, copying some files, copying some files to floppy disk, starting applications by clicking on a file (for example ghostview for postscript files or xli for gifs, etc).

I'm thinking about nice windows, one for each directory, that shows icons for every file. It should be possible to drag files around (either copy or move), even between different windows. Another important point is the support of the floppy-disk, so that mounting/umounting is done user-transparent.

Dragging of icons should be done in a nice way, that means moving around a special window (see Qt's xshape example), NOT like xfm or xfilemanager by setting another monochrome bitmap for the cursor.

So it will also be possible to put files as icons on the desktop. This is IMO a very nice feature. Since applications are launched by the panel, it's even clear that icons are real data-objects. With fvwm-1 and the FvwmFileMgr it wasn't really clear wether an icon is yet a file or an iconified window.

Drag'n'drop inside a Qt application isn't really difficult. The filemanager is IMO a very nice and not too time consuming project. Who wants?

mail client A really comfortable mailclient. IMO the most comfortable mailclient for X is yet XF-Mail. And the author is willing to port it to Qt when the KDE-project will start! But he asks for some assitance (for example for coding the small popups, etc.)

easy texteditor Very small but important project. An editor that fits the needs of those who have to edit a textfile once in a month and didn't find the time yet to learn vi (and don't have the time to wait for x-emacs to start, and don't have the memory to use a motif-static-nedit, and don't have the cpu-power and memory to use a tk-monster like tkedit,...)

Unfortunatly the Qt multiline-textwidget isn't available in Qt-1.0, but Troll-Tech already announced the beta-testing. So the texteditor can be started in a few weeks, too.

Terminal Similar to the CDE terminal program. A kind of xterm with nice menu bar to set the font, exit, etc. Nice project, get the xterm sources and add a GUI with Qt!

Image viewer The application that will be launced as default from the filemanager for gifs, jpegs and all this. Well, xv is shareware and really needs quite a long time for startup. But there is a plain Xlib programm without any menues or buttons called "xli". Get the sources and make it userfriendly with Qt!

Lots of small other tools:

• xdvi with Qt-Gui
• ghostview with Qt-Gui
• xmag with Qt-Gui
• whatever you want

BTW: There is a Troll Tech Qt-competition (look at their webpages). The best application (not only functionallity, but also design counts. Just porting an existing great application to Qt won't probably be enough :-( ) wins $2000 and a few Qt on NT licenses (worth another $2000). They also mentioned a browser-project as an example. So a nice HTML-browser in Qt, ready in Janurary may be worth $4000 (This includes selling the unneeded NT licenses ;-) )

Window Manager At the beginning, the KDE panel will work as an Fvwm-Module. When this is done, a lot of stuff can be stripped from the bloated fvwm window manager. We don't need anymore fvwm-menus, icon handling and zillions of configurable things. We need a small, realiable windowmanager. So maybe stripping all unncessary stuff from fvwm will make sense in a while. But this may come very last.

System Tools Whatever a user, or you, might need. A graphical passwd comes to my mind. But probably there are a lot more! Maybe this will lead to a small system administration tool someday.

Games We have yet a nice tetris game (an Qt example program). What is needed is a nice set of small games like solitaire (please with nice cards that can be really dragged!). There are several nice card games available for X, for example xpat2. So why not take the cards from them and write a real solitaire games, very similar to MS-Solitaire. I really had to install Wine sometimes just to play solitair, what an overhead! But other games are needed, too. Take xmris, pacman, etc. add a nice GUI. Or write some from scratch. Whatever you want :)

Icons A set of nice icons. 3D-pixmaps are quite a good start (but why should the button be inside a pixmap, if we use a toolkit with buttons???)

Documentation A documentation project is always a good thing to have. But before we should clearify how the hypertext help system should look like. We can then start with documentation pages in the chosen HTML-subset and for example use arean as help browser. Anyway we need some application to document first.

Web-Pages / Ftp Server / Aministration We need a server for the files and webpages that inform about the state of the project. Especially what projects are currently worked on and what projects still wait for somebody to do them. I set up a preliminary homepage on http://www-pu.informatik.uni-tuebingen.de/users/et trich that just contains this posting yet and a few links. I may setup real webpages for the very beginning but I would be very happy if I could concentrate on discussion and coding. So if there is someone out there in the net who likes to design and maintain webpages, here is a job for him :)

Discussion The most important topic :-) If you are interested please join the mailing list kde@kde.org

Subscribing can be done by sending a mail with in *Body*: subscribe [your email address]
to
kde-request@kde.org

Applications When the KDE gets widely accepted, new (free) applications will hopefully be based on Qt, too, to fit with the comfortable and pleasant look and feel of the desktop.

We may for example port LyX to Qt, so that a comfortable wordprocessor is available. But that is still in discussion in the LyX Team.

A nice vector-orientated drawing tool would also be fine. Well, Xfig is a powerful but ugly monster. But there is "tgif", a very powerful, easy to use but ugly program. The author doesn't like the idea of adding a Qt GUI for the menus, icons and scrollbars, since Qt is C++ and he wants to keep tgif plain C, since on some sites no C++ compiler is available. Well, the KDE doesn't really aim on these old and weird UNIX boxes (also I think a g++ is almost everywhere available). But maybe the tgif-author agrees when somebody else adds a nice GUI to tgif (the sources are free, don't know wether this is GPL). Since tgif yet implements its own GUI this shouldn't be too difficult. It's really easy with Qt to access plain Xlib functionality and functions, so not very much will have to be rewritten. Also C++ makes it very easy to include plain C code.

What about an easy to use, nice newsreader similar to knews? Could also be integrated into the KDE. ... and ... and ... and.

So there is a lot of work (and fun) to do! If you are interested, please join the mailing list. If we get about 20-30 people we could start. And probably before 24th December the net-community will give itself another nice and longtime-needed gift.

The stuff will be distributed under the terms of the GPL.

I admit the whole thing sounds a bit like fantasy. But it is very serious from my side. Everybody I'm talking to in the net would LOVE a somewhat cleaner desktop. Qt is the chance to realize this. So let us join our rare sparetime and just do it!

Hopefully looking foward to lots of followups and replies! Regards,

Matthias Ettrich
(ettrich@informatik.uni-tuebingen.de)

BTW: Usually these postings get a lot of answers like "Use a Mac if you want a GUI, CLI rules!", "I like thousands of different widgets-libraries on my desktop, if you are too stupid to learn them, you should use windoze", "RAM prices are so low, I only use static motif programs", "You will never succeed, so better stop before the beginning", "Why Qt? I prefer schnurz-purz-widgets with xyz-lisp-shell. GPL! Check it out!", etc. Thanks for not sending these as followup to this posting :-) I know I'm a dreamer...

BTW2: You might wonder why I'm so against Tk. Well, I don't like the philosophy: Tk's doesn't have a textwidget, for example, but a slow wordprocessor. Same with other widgets. In combination with TCL the programs become slow and ugly (of course there are exceptions). I didn't yet see any application that uses Tk from C++ or C, although an API seems to exist. TCL/TK is very usefull for prototyping. Ideal for example for kernel configuration. And since Tk looks little similar to Motif, the widgets are also quite easy to use. But I really don't like any TCL/Tk application to stay permanantly on the desktop. And Qt is much easier (at least as easy) to program. Check it out!

BTW3: I don't have any connections to Troll Tech, I just like their product (look at the sources: really high quality!) and their kind of marketing: free sourcecode for free software. Original document by Matthias Ettrich,
HTMLized by Matt McLeod

Of course there are GUI's. There is the Commond Desktop Environment (much too exensive), Looking Glas (not too expensive but not really the solution), and several free X-Filemanagers that are almost GUI's. Moxfm for example is very well done, but unfortunately it is based on Motif. Anyway, the question is: What is a GUI? What should a GUI be?

First of all, since there are a lot of missunderstandings on this topic, what is NOT a GUI:

• the X-Window-System is NOT a GUI. It's what its name says: A Window system
• Motif is NOT a GUI. They tried to create a GUI when they made Motif, but unfortunately they couldn't really agree, so they released Motif as Widget-Library with a Window-Manager. Much later they completed Motif with the CDE, but too late, since Windows already runs on the majority of desktops.
• Window-managers are NOT GUI's. They are (better: should be) small programs that handle the windows. It's not really the idea to hack a lot of stuff into them.

IMHO a GUI should offer a complete, graphical environment. It should allow a users to do his everyday tasks with it, like starting applications, reading mail, configuring his desktop, editing some files, delete some files, look at some pictures, etc. All parts must fit together and work together. A nice button with a nice "Editor"-icon is not at all a graphical user environment if it invokes "xterm -e vi". Maybe you have been disappointed long time ago too, when you installed X with a nice window manager, clicked on that beautiful "Help"-Icon ... chrk chrk (the hard disk)...an ugly, unsuable, weird xman appeared on the desktop :-( A GUI for endusers The idea is NOT to create a GUI for the complete UNIX-system or the System-Administrator. For that purpose the UNIX-CLI with thousands of tools and scripting languages is much better. The idea is to create a GUI for an ENDUSER. Somebody who wants to browse the web with Linux, write some letters and play some nice games.

I really believed that is even yet possible with Linux until I configured my girlfriends Box. Well, I didn't notice anymore that I work with lots of different kind of menues, scrollbars and textwidgets. I already know that some widgets need to be under the mouse when they should get the keyevents, some sliders wants the middle mouse for dragging and some textwidgets only want emacs-bindings and don't understand keys like "pos1" or "end". And selecting some text is different everywere, too. Even the menues and buttons (for exampel Xaw, Fvwm, XForms, Motif) behave completely different.

One word to the Athena-Widgets: Although there are a few nice applications available that uses these "widgets" we should really get rid of them. Thinking that "Athena is a widget-library" is a similar missunderstanding like "X is a GUI". Athena is an very old example how widget libraries could be implemented with Xlib and Xt. It's more or less a online-documentation for Widget-Set-Programmers, but not a tool for application-programmers. Unfortunately, the old Unix problem, a so good online-documentation that people used it for applications.

So one of the major goals is to provide a modern and common look&feel for all the applications. And this is exactly the reason, why this project is different from elder attempts.

Since a few weeks a really great new widget library is available free in source and price for free software development. Check out http://www.troll.no

The stuff is called "Qt" and is really a revolution in programming X. It's an almost complete, fully C++ Widget-library that implementes a slightly improved Motif look and feel, or, switchable during startup, Window95.

The fact that it is done by a company (Troll Tech) is IMO a great advantage. We have the sources and a superb library, they have beta testers. But they also spend their WHOLE TIME in improving the library. They also give great support. That means, Qt is also interesting for commercial applications. A real alternative to the terrible Motif :) But the greatest pro for Qt is the way how it is programmed. It's really a very easy-to-use powerfull C++-library.

Qt is also portable, yet to Windows95/NT, but you do not have to worry about that. It's very easy to use UNIX/X specific things in programming, so that porting to NT is hardly possible :-)

I really recommend looking at this library. It has IMO the power to become the leading library for free software development. And it's a way to escape the TCL/TK monsters that try to slow down all our processors and eat up our memory...

It's really time yet to standarize the desktop somewhat. It's nonsense to load 10 different widgets into memory for the same task. Imagine this desktop:

• fvwm (own widgets)
• rxvt (own widgets)
• tgif (own widgets)
• xv (own widgets)
• ghostview (athena widgets)
• lyx (xforms widgets)
• xftp (motif widgets)
• textedit (xview widgets)
• arena (own widgets)

One may argue that a usual UNIX-Box has enough memory to handle all these different kind of widgets. Even if this might be correct, the really annoying thing is, that all these widgets (menus, buttons, scrollbars, etc.) behave slightly different. And this isn't only an academic example, I've really seen such desktops :-}

I know we couldn't get rid of this chaos at once, but my dream is a coexistance between Motif and Qt. The Kool Desktop Environment (KDE) I don't have the time to do this all alone (also since LyX is my main project). But a thing like a Desktop Environment can easily be cut into lots of parts. There is very probably a part for you, too! If you want to learn some X-programming, why not doing a small, neat project for the KDE? If you know others who like to programm something, please prevend them from writing the 1004th tetris games or the 768th minesweeper clone ;-) Think we also have enough XBiffs yet...

So here is my project list so far. Probably there are even more things to do that would fit great into the KDE. It's a very open project. Panel: The basic application. Run's as FvwmModule (at the beginning). Offers a combination between Windows95 and CDE. I think about a small taskbar at the bottom and a kind of CDE-panel on the top of the screen. The panel has graphical icon menus on the left (similar to GoodStuff) to launch applications, 4 buttons in the middle to switch to other virtual desktops and few icons for often needed applications on the right. There is for example a mail-icon that also indicates new mail, a wastebasket to open the delete-folder (that also indicates when it isn't empty and is capable of drag'n'drop). Maybe a analog clock with date at the very right. Also a nice special icon for exiting the environment or locking the screen. All the stuff is completly configurable via GUI. I'm also thinking about solutions, that only available applications can be installed on the desktop and that new applications appear on the desktop automatically.

I started to work on this panel, but would of course love some help. There are also lot of smaller things to do, like a tool to chose a background pixmap (for each virtual desktop) etc.

Also nice icons are needed!

Filemanager Another major application inside the KDE. The idea is not to create a powerful high-end graphical bash-replacement (like tkdesk tries to be), but a nice looking easy-to-use filemanager for simple tasks. Simple tasks are mainly deleting some files, copying some files, copying some files to floppy disk, starting applications by clicking on a file (for example ghostview for postscript files or xli for gifs, etc).

I'm thinking about nice windows, one for each directory, that shows icons for every file. It should be possible to drag files around (either copy or move), even between different windows. Another important point is the support of the floppy-disk, so that mounting/umounting is done user-transparent.

Dragging of icons should be done in a nice way, that means moving around a special window (see Qt's xshape example), NOT like xfm or xfilemanager by setting another monochrome bitmap for the cursor.

So it will also be possible to put files as icons on the desktop. This is IMO a very nice feature. Since applications are launched by the panel, it's even clear that icons are real data-objects. With fvwm-1 and the FvwmFileMgr it wasn't really clear wether an icon is yet a file or an iconified window.

Drag'n'drop inside a Qt application isn't really difficult. The filemanager is IMO a very nice and not too time consuming project. Who wants?

mail client A really comfortable mailclient. IMO the most comfortable mailclient for X is yet XF-Mail. And the author is willing to port it to Qt when the KDE-project will start! But he asks for some assitance (for example for coding the small popups, etc.)

easy texteditor Very small but important project. An editor that fits the needs of those who have to edit a textfile once in a month and didn't find the time yet to learn vi (and don't have the time to wait for x-emacs to start, and don't have the memory to use a motif-static-nedit, and don't have the cpu-power and memory to use a tk-monster like tkedit,...)

Unfortunatly the Qt multiline-textwidget isn't available in Qt-1.0, but Troll-Tech already announced the beta-testing. So the texteditor can be started in a few weeks, too.

Terminal Similar to the CDE terminal program. A kind of xterm with nice menu bar to set the font, exit, etc. Nice project, get the xterm sources and add a GUI with Qt!

Image viewer The application that will be launced as default from the filemanager for gifs, jpegs and all this. Well, xv is shareware and really needs quite a long time for startup. But there is a plain Xlib programm without any menues or buttons called "xli". Get the sources and make it userfriendly with Qt!

Lots of small other tools:

• xdvi with Qt-Gui
• ghostview with Qt-Gui
• xmag with Qt-Gui
• whatever you want

BTW: There is a Troll Tech Qt-competition (look at their webpages). The best application (not only functionallity, but also design counts. Just porting an existing great application to Qt won't probably be enough :-( ) wins $2000 and a few Qt on NT licenses (worth another $2000). They also mentioned a browser-project as an example. So a nice HTML-browser in Qt, ready in Janurary may be worth $4000 (This includes selling the unneeded NT licenses ;-) )

Window Manager At the beginning, the KDE panel will work as an Fvwm-Module. When this is done, a lot of stuff can be stripped from the bloated fvwm window manager. We don't need anymore fvwm-menus, icon handling and zillions of configurable things. We need a small, realiable windowmanager. So maybe stripping all unncessary stuff from fvwm will make sense in a while. But this may come very last.

System Tools Whatever a user, or you, might need. A graphical passwd comes to my mind. But probably there are a lot more! Maybe this will lead to a small system administration tool someday.

Games We have yet a nice tetris game (an Qt example program). What is needed is a nice set of small games like solitaire (please with nice cards that can be really dragged!). There are several nice card games available for X, for example xpat2. So why not take the cards from them and write a real solitaire games, very similar to MS-Solitaire. I really had to install Wine sometimes just to play solitair, what an overhead! But other games are needed, too. Take xmris, pacman, etc. add a nice GUI. Or write some from scratch. Whatever you want :)

Icons A set of nice icons. 3D-pixmaps are quite a good start (but why should the button be inside a pixmap, if we use a toolkit with buttons???)

Documentation A documentation project is always a good thing to have. But before we should clearify how the hypertext help system should look like. We can then start with documentation pages in the chosen HTML-subset and for example use arean as help browser. Anyway we need some application to document first.

Web-Pages / Ftp Server / Aministration We need a server for the files and webpages that inform about the state of the project. Especially what projects are currently worked on and what projects still wait for somebody to do them. I set up a preliminary homepage on http://www-pu.informatik.uni-tuebingen.de/users/et trich that just contains this posting yet and a few links. I may setup real webpages for the very beginning but I would be very happy if I could concentrate on discussion and coding. So if there is someone out there in the net who likes to design and maintain webpages, here is a job for him :)

Discussion The most important topic :-) If you are interested please join the mailing list kde@kde.org

Subscribing can be done by sending a mail with in *Body*: subscribe [your email address]
to
kde-request@kde.org

Applications When the KDE gets widely accepted, new (free) applications will hopefully be based on Qt, too, to fit with the comfortable and pleasant look and feel of the desktop.

We may for example port LyX to Qt, so that a comfortable wordprocessor is available. But that is still in discussion in the LyX Team.

A nice vector-orientated drawing tool would also be fine. Well, Xfig is a powerful but ugly monster. But there is "tgif", a very powerful, easy to use but ugly program. The author doesn't like the idea of adding a Qt GUI for the menus, icons and scrollbars, since Qt is C++ and he wants to keep tgif plain C, since on some sites no C++ compiler is available. Well, the KDE doesn't really aim on these old and weird UNIX boxes (also I think a g++ is almost everywhere available). But maybe the tgif-author agrees when somebody else adds a nice GUI to tgif (the sources are free, don't know wether this is GPL). Since tgif yet implements its own GUI this shouldn't be too difficult. It's really easy with Qt to access plain Xlib functionality and functions, so not very much will have to be rewritten. Also C++ makes it very easy to include plain C code.

What about an easy to use, nice newsreader similar to knews? Could also be integrated into the KDE. ... and ... and ... and.

So there is a lot of work (and fun) to do! If you are interested, please join the mailing list. If we get about 20-30 people we could start. And probably before 24th December the net-community will give itself another nice and longtime-needed gift.

The stuff will be distributed under the terms of the GPL.

I admit the whole thing sounds a bit like fantasy. But it is very serious from my side. Everybody I'm talking to in the net would LOVE a somewhat cleaner desktop. Qt is the chance to realize this. So let us join our rare sparetime and just do it!

Hopefully looking foward to lots of followups and replies! Regards,

Matthias Ettrich
(ettrich@informatik.uni-tuebingen.de)

BTW: Usually these postings get a lot of answers like "Use a Mac if you want a GUI, CLI rules!", "I like thousands of different widgets-libraries on my desktop, if you are too stupid to learn them, you should use windoze", "RAM prices are so low, I only use static motif programs", "You will never succeed, so better stop before the beginning", "Why Qt? I prefer schnurz-purz-widgets with xyz-lisp-shell. GPL! Check it out!", etc. Thanks for not sending these as followup to this posting :-) I know I'm a dreamer...

BTW2: You might wonder why I'm so against Tk. Well, I don't like the philosophy: Tk's doesn't have a textwidget, for example, but a slow wordprocessor. Same with other widgets. In combination with TCL the programs become slow and ugly (of course there are exceptions). I didn't yet see any application that uses Tk from C++ or C, although an API seems to exist. TCL/TK is very usefull for prototyping. Ideal for example for kernel configuration. And since Tk looks little similar to Motif, the widgets are also quite easy to use. But I really don't like any TCL/Tk application to stay permanantly on the desktop. And Qt is much easier (at least as easy) to program. Check it out!

BTW3: I don't have any connections to Troll Tech, I just like their product (look at the sources: really high quality!) and their kind of marketing: free sourcecode for free software. Original document by Matthias Ettrich,
HTMLized by Matt McLeod

Of course there are GUI's. There is the Commond Desktop Environment (much too exensive), Looking Glas (not too expensive but not really the solution), and several free X-Filemanagers that are almost GUI's. Moxfm for example is very well done, but unfortunately it is based on Motif. Anyway, the question is: What is a GUI? What should a GUI be?

First of all, since there are a lot of missunderstandings on this topic, what is NOT a GUI:

• the X-Window-System is NOT a GUI. It's what its name says: A Window system
• Motif is NOT a GUI. They tried to create a GUI when they made Motif, but unfortunately they couldn't really agree, so they released Motif as Widget-Library with a Window-Manager. Much later they completed Motif with the CDE, but too late, since Windows already runs on the majority of desktops.
• Window-managers are NOT GUI's. They are (better: should be) small programs that handle the windows. It's not really the idea to hack a lot of stuff into them.

IMHO a GUI should offer a complete, graphical environment. It should allow a users to do his everyday tasks with it, like starting applications, reading mail, configuring his desktop, editing some files, delete some files, look at some pictures, etc. All parts must fit together and work together. A nice button with a nice "Editor"-icon is not at all a graphical user environment if it invokes "xterm -e vi". Maybe you have been disappointed long time ago too, when you installed X with a nice window manager, clicked on that beautiful "Help"-Icon ... chrk chrk (the hard disk)...an ugly, unsuable, weird xman appeared on the desktop :-( A GUI for endusers The idea is NOT to create a GUI for the complete UNIX-system or the System-Administrator. For that purpose the UNIX-CLI with thousands of tools and scripting languages is much better. The idea is to create a GUI for an ENDUSER. Somebody who wants to browse the web with Linux, write some letters and play some nice games.

I really believed that is even yet possible with Linux until I configured my girlfriends Box. Well, I didn't notice anymore that I work with lots of different kind of menues, scrollbars and textwidgets. I already know that some widgets need to be under the mouse when they should get the keyevents, some sliders wants the middle mouse for dragging and some textwidgets only want emacs-bindings and don't understand keys like "pos1" or "end". And selecting some text is different everywere, too. Even the menues and buttons (for exampel Xaw, Fvwm, XForms, Motif) behave completely different.

One word to the Athena-Widgets: Although there are a few nice applications available that uses these "widgets" we should really get rid of them. Thinking that "Athena is a widget-library" is a similar missunderstanding like "X is a GUI". Athena is an very old example how widget libraries could be implemented with Xlib and Xt. It's more or less a online-documentation for Widget-Set-Programmers, but not a tool for application-programmers. Unfortunately, the old Unix problem, a so good online-documentation that people used it for applications.

So one of the major goals is to provide a modern and common look&feel for all the applications. And this is exactly the reason, why this project is different from elder attempts.

Since a few weeks a really great new widget library is available free in source and price for free software development. Check out http://www.troll.no

The stuff is called "Qt" and is really a revolution in programming X. It's an almost complete, fully C++ Widget-library that implementes a slightly improved Motif look and feel, or, switchable during startup, Window95.

The fact that it is done by a company (Troll Tech) is IMO a great advantage. We have the sources and a superb library, they have beta testers. But they also spend their WHOLE TIME in improving the library. They also give great support. That means, Qt is also interesting for commercial applications. A real alternative to the terrible Motif :) But the greatest pro for Qt is the way how it is programmed. It's really a very easy-to-use powerfull C++-library.

Qt is also portable, yet to Windows95/NT, but you do not have to worry about that. It's very easy to use UNIX/X specific things in programming, so that porting to NT is hardly possible :-)

I really recommend looking at this library. It has IMO the power to become the leading library for free software development. And it's a way to escape the TCL/TK monsters that try to slow down all our processors and eat up our memory...

It's really time yet to standarize the desktop somewhat. It's nonsense to load 10 different widgets into memory for the same task. Imagine this desktop:

• fvwm (own widgets)
• rxvt (own widgets)
• tgif (own widgets)
• xv (own widgets)
• ghostview (athena widgets)
• lyx (xforms widgets)
• xftp (motif widgets)
• textedit (xview widgets)
• arena (own widgets)

One may argue that a usual UNIX-Box has enough memory to handle all these different kind of widgets. Even if this might be correct, the really annoying thing is, that all these widgets (menus, buttons, scrollbars, etc.) behave slightly different. And this isn't only an academic example, I've really seen such desktops :-}

I know we couldn't get rid of this chaos at once, but my dream is a coexistance between Motif and Qt. The Kool Desktop Environment (KDE) I don't have the time to do this all alone (also since LyX is my main project). But a thing like a Desktop Environment can easily be cut into lots of parts. There is very probably a part for you, too! If you want to learn some X-programming, why not doing a small, neat project for the KDE? If you know others who like to programm something, please prevend them from writing the 1004th tetris games or the 768th minesweeper clone ;-) Think we also have enough XBiffs yet...

So here is my project list so far. Probably there are even more things to do that would fit great into the KDE. It's a very open project. Panel: The basic application. Run's as FvwmModule (at the beginning). Offers a combination between Windows95 and CDE. I think about a small taskbar at the bottom and a kind of CDE-panel on the top of the screen. The panel has graphical icon menus on the left (similar to GoodStuff) to launch applications, 4 buttons in the middle to switch to other virtual desktops and few icons for often needed applications on the right. There is for example a mail-icon that also indicates new mail, a wastebasket to open the delete-folder (that also indicates when it isn't empty and is capable of drag'n'drop). Maybe a analog clock with date at the very right. Also a nice special icon for exiting the environment or locking the screen. All the stuff is completly configurable via GUI. I'm also thinking about solutions, that only available applications can be installed on the desktop and that new applications appear on the desktop automatically.

I started to work on this panel, but would of course love some help. There are also lot of smaller things to do, like a tool to chose a background pixmap (for each virtual desktop) etc.

Also nice icons are needed!

Filemanager Another major application inside the KDE. The idea is not to create a powerful high-end graphical bash-replacement (like tkdesk tries to be), but a nice looking easy-to-use filemanager for simple tasks. Simple tasks are mainly deleting some files, copying some files, copying some files to floppy disk, starting applications by clicking on a file (for example ghostview for postscript files or xli for gifs, etc).

I'm thinking about nice windows, one for each directory, that shows icons for every file. It should be possible to drag files around (either copy or move), even between different windows. Another important point is the support of the floppy-disk, so that mounting/umounting is done user-transparent.

Dragging of icons should be done in a nice way, that means moving around a special window (see Qt's xshape example), NOT like xfm or xfilemanager by setting another monochrome bitmap for the cursor.

So it will also be possible to put files as icons on the desktop. This is IMO a very nice feature. Since applications are launched by the panel, it's even clear that icons are real data-objects. With fvwm-1 and the FvwmFileMgr it wasn't really clear wether an icon is yet a file or an iconified window.

Drag'n'drop inside a Qt application isn't really difficult. The filemanager is IMO a very nice and not too time consuming project. Who wants?

mail client A really comfortable mailclient. IMO the most comfortable mailclient for X is yet XF-Mail. And the author is willing to port it to Qt when the KDE-project will start! But he asks for some assitance (for example for coding the small popups, etc.)

easy texteditor Very small but important project. An editor that fits the needs of those who have to edit a textfile once in a month and didn't find the time yet to learn vi (and don't have the time to wait for x-emacs to start, and don't have the memory to use a motif-static-nedit, and don't have the cpu-power and memory to use a tk-monster like tkedit,...)

Unfortunatly the Qt multiline-textwidget isn't available in Qt-1.0, but Troll-Tech already announced the beta-testing. So the texteditor can be started in a few weeks, too.

Terminal Similar to the CDE terminal program. A kind of xterm with nice menu bar to set the font, exit, etc. Nice project, get the xterm sources and add a GUI with Qt!

Image viewer The application that will be launced as default from the filemanager for gifs, jpegs and all this. Well, xv is shareware and really needs quite a long time for startup. But there is a plain Xlib programm without any menues or buttons called "xli". Get the sources and make it userfriendly with Qt!

Lots of small other tools:

• xdvi with Qt-Gui
• ghostview with Qt-Gui
• xmag with Qt-Gui
• whatever you want

BTW: There is a Troll Tech Qt-competition (look at their webpages). The best application (not only functionallity, but also design counts. Just porting an existing great application to Qt won't probably be enough :-( ) wins $2000 and a few Qt on NT licenses (worth another $2000). They also mentioned a browser-project as an example. So a nice HTML-browser in Qt, ready in Janurary may be worth $4000 (This includes selling the unneeded NT licenses ;-) )

Window Manager At the beginning, the KDE panel will work as an Fvwm-Module. When this is done, a lot of stuff can be stripped from the bloated fvwm window manager. We don't need anymore fvwm-menus, icon handling and zillions of configurable things. We need a small, realiable windowmanager. So maybe stripping all unncessary stuff from fvwm will make sense in a while. But this may come very last.

System Tools Whatever a user, or you, might need. A graphical passwd comes to my mind. But probably there are a lot more! Maybe this will lead to a small system administration tool someday.

Games We have yet a nice tetris game (an Qt example program). What is needed is a nice set of small games like solitaire (please with nice cards that can be really dragged!). There are several nice card games available for X, for example xpat2. So why not take the cards from them and write a real solitaire games, very similar to MS-Solitaire. I really had to install Wine sometimes just to play solitair, what an overhead! But other games are needed, too. Take xmris, pacman, etc. add a nice GUI. Or write some from scratch. Whatever you want :)

Icons A set of nice icons. 3D-pixmaps are quite a good start (but why should the button be inside a pixmap, if we use a toolkit with buttons???)

Documentation A documentation project is always a good thing to have. But before we should clearify how the hypertext help system should look like. We can then start with documentation pages in the chosen HTML-subset and for example use arean as help browser. Anyway we need some application to document first.

Web-Pages / Ftp Server / Aministration We need a server for the files and webpages that inform about the state of the project. Especially what projects are currently worked on and what projects still wait for somebody to do them. I set up a preliminary homepage on http://www-pu.informatik.uni-tuebingen.de/users/et trich that just contains this posting yet and a few links. I may setup real webpages for the very beginning but I would be very happy if I could concentrate on discussion and coding. So if there is someone out there in the net who likes to design and maintain webpages, here is a job for him :)

Discussion The most important topic :-) If you are interested please join the mailing list kde@kde.org

Subscribing can be done by sending a mail with in *Body*: subscribe [your email address]
to
kde-request@kde.org

Applications When the KDE gets widely accepted, new (free) applications will hopefully be based on Qt, too, to fit with the comfortable and pleasant look and feel of the desktop.

We may for example port LyX to Qt, so that a comfortable wordprocessor is available. But that is still in discussion in the LyX Team.

A nice vector-orientated drawing tool would also be fine. Well, Xfig is a powerful but ugly monster. But there is "tgif", a very powerful, easy to use but ugly program. The author doesn't like the idea of adding a Qt GUI for the menus, icons and scrollbars, since Qt is C++ and he wants to keep tgif plain C, since on some sites no C++ compiler is available. Well, the KDE doesn't really aim on these old and weird UNIX boxes (also I think a g++ is almost everywhere available). But maybe the tgif-author agrees when somebody else adds a nice GUI to tgif (the sources are free, don't know wether this is GPL). Since tgif yet implements its own GUI this shouldn't be too difficult. It's really easy with Qt to access plain Xlib functionality and functions, so not very much will have to be rewritten. Also C++ makes it very easy to include plain C code.

What about an easy to use, nice newsreader similar to knews? Could also be integrated into the KDE. ... and ... and ... and.

So there is a lot of work (and fun) to do! If you are interested, please join the mailing list. If we get about 20-30 people we could start. And probably before 24th December the net-community will give itself another nice and longtime-needed gift.

The stuff will be distributed under the terms of the GPL.

I admit the whole thing sounds a bit like fantasy. But it is very serious from my side. Everybody I'm talking to in the net would LOVE a somewhat cleaner desktop. Qt is the chance to realize this. So let us join our rare sparetime and just do it!

Hopefully looking foward to lots of followups and replies! Regards,

Matthias Ettrich
(ettrich@informatik.uni-tuebingen.de)

BTW: Usually these postings get a lot of answers like "Use a Mac if you want a GUI, CLI rules!", "I like thousands of different widgets-libraries on my desktop, if you are too stupid to learn them, you should use windoze", "RAM prices are so low, I only use static motif programs", "You will never succeed, so better stop before the beginning", "Why Qt? I prefer schnurz-purz-widgets with xyz-lisp-shell. GPL! Check it out!", etc. Thanks for not sending these as followup to this posting :-) I know I'm a dreamer...

BTW2: You might wonder why I'm so against Tk. Well, I don't like the philosophy: Tk's doesn't have a textwidget, for example, but a slow wordprocessor. Same with other widgets. In combination with TCL the programs become slow and ugly (of course there are exceptions). I didn't yet see any application that uses Tk from C++ or C, although an API seems to exist. TCL/TK is very usefull for prototyping. Ideal for example for kernel configuration. And since Tk looks little similar to Motif, the widgets are also quite easy to use. But I really don't like any TCL/Tk application to stay permanantly on the desktop. And Qt is much easier (at least as easy) to program. Check it out!

BTW3: I don't have any connections to Troll Tech, I just like their product (look at the sources: really high quality!) and their kind of marketing: free sourcecode for free software. Original document by Matthias Ettrich,
HTMLized by Matt McLeod

[...] "self-made"? Numbers 215, 396, and 413 [...]

He, I've seen and worked with 215. Pretty non awe inducing group of 96 dual Pentium III boxes using a Myrinet interconnect. You can find some pictures at the Kepler homepage. It's amazing what good lighting and a good photographer can do :-) That aside, the system itself is pretty cool (and damn fast, even if there's some contention among its users for computing time)

http://math.usc.edu/~oliverm/linux
http://na.mathematik.uni-tuebin gen.de/~oliver/linux

Supposedly, you can get primitive 3D support with a bunch of hacks starting here. It involves using ancient versions of XFree and Mesa, so I haven't tried it. However, you may be able to learn something about the card by reading the sources...

I'm really hoping that XFree 4 will have 3D acceleration for the G200 card, but Matrox (who I annoy on a monthly basis about this) still refuses to release any information or write any drivers. The card is still really nice in X with 16M of video RAM, though :)