An alpha version of the new GTK+ 2.0 based, Gnome 2.0, is now available for download and testing. The new version enhances anti-aliased text and internationalisation support, accessibility features and more. Screenshots available. Our Take: Note on the Gnome roadmap that they expect to also break binary and source compatibility for version 3.0 as they currently do now for 2.0. I wonder if this is what makes proprierty systems (eg. Windows) more successful commercially. The support for backwards compatibility is certainly something that users will always appreciate if they can run their closed source programs for the years to come or, for open source apps, users will be able to compile for the new Gnome version without changes in the app’s source code. However, supporting older versions, can cause “bloat”. Is the trade off acceptable? Discuss.
GNOME 2.0 Desktop Alpha Available
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Butt F….ing ugly!
Those screenshots make Windows UI look Good!
I supported BeOS’s compabtability break as, every now and again it’s needed.
Optonal compatablity layers are almost always nice thou.
I’m posting this using Galeon under Gnome on Mandrake 8.1. Like most versions of Linux there dog-arse slow compared to BeOS, hell even compared to Windows.
If breaking binary/source compatability can give Linux/X a faster sleeker GUI I’m all for it. Its not like it gonna be too hard to beat its nemesis KDE when it comes to responsiveness.
As always, the fonts are all wrong. Blurry (that’s one of their big features), ugly, out of proportion => hard to read.
The gnomebar and its taskbar looks cheap, nautilus (the filemanager) is very slow, and everything depends on a mile long list of libraries.
They say that most improvements are not visible to the user and I sure hope so because those screenshots are almost identical to 1.2
Until gnome and KDE looks and feels right, I’m using blackbox + xterm
I can barely even see a difference between that a 1.4 I currently use! The only major difference is the control panel from what I can see. I assume most of the difference is in the code.
stfu most of u use beos so just don’t talk
Personally, I am a bit “old fashioned”.
I mean, even when Gnome and KDE break compatibility with each major version (KDE also breaks compatibility), I haven’t notice any major speed enhancement. In fact, they are getting slower anyway.
Microsoft was able to captivate the 94% of the desktop market by being able to run DOS programs in their Windows95. There are many businesses that had dbs and other important old Windows3.1 or DOS software, and being able to run those under Windows9x, it was a bless for them!
While I think that Microsoft overdid it a bit with compatibility, I believe that one should break compatibility every 7 to 10 years. Not once every year though (like KDE did
).
Linux is a server system. I have seen an installation of Oracle under Linux. Both the database and installer is closed source. And it works with Gnome 1.x I think. Now, let’s say that we upgrade to Gnome 2. The installer won’t work. And I don’t even think that Oracle will update the app for gnome 2, as they have abandoned the Linux camp. However, the db works, it is the installer that doesn’t. I think that’s a bummer. And let’s say now that it was an open source app that you need and that it has no support and that the guy who wrote it does not support it anymore. It will need SOURCE changes to make it compile in the new gnome. But most of the users are not programmers. Another bummer.
Personally, I believe that a the middle way is always the wise one. Break compatibility, but do it every few years (7-10). Not so often though.
Why do they release things in alpha? Do people actually use the stuff, or is it just for developers?
Looked at the screenshots – GTK widgets look horrible, as they always have.
>Why do they release things in alpha? Do people actually use the stuff, or is it just for developers?
There was a previous alpha version for developers. This one is for users. They need wider testing before Gnome goes live in 2 months.
>GTK widgets look horrible, as they always have.
Yes, I agree. GTK+ is an incredibly ugly toolkit. Even with the addition of themes, it just doesn’t look right.
QT looks much better, but I can’t say that KDE overall is “sexy”. It is certainly better than Gnome, but KDE is over bloated with zillion other things.
originally posted by TJ
stfu most of u use beos so just don’t talk
Many of us still do, yes. Thing is, that’s why we complain so much … because we’ve experienced something better.
I aesthetically prefer GNOME to KDE in many aspects, I just don’t feel right under KDE. The GNOME 2.0 control center looks very nice, the system icon is neat. Pitty that both GUIs are so memory hungry and don’t display correctly the fonts.
Stability is another problem in my opinion. I remember discovering a few years ago how unstable Linux was within a GUI, it was hard to believe that with this allpraised stable OS I had to count the minutes before Konqueror crashed. I am an amateur programmer at a very basic level, that is why I don’t understand very well why does Linux go for such an inconsistent GUI with X under. Maybe someone can explain it to me.
What commercial Gnome applications are there that would suffer from breaking binary compatibility?
and make a better Video server. one that makes it simple to write drivers to, one that is speedy, one that does not offer network transperency. if you are admining a server, you can do so through webmin remotly, or telnet in and edit some text files…. Do it now before people start writing popular comercial applications. the new video server should have its own wiget set and be what applications write to, not the desktop environment.
jeremy, rock on brotha!
The Oracle Installer is closed source indeed, just it uses java since version 8i. So it only depends on an X-Server. OUI (Oracle Universal Installer) does not require any gnome or kde libs.
Best regards.
Since I think it’s butt ugly as well, but the difference between Windows and Gnome is that when Gnome breaks source compatibility, you can keep as many old libraries around as you want to be able to run your old apps. And for those that don’t want to run the old apps, you don’t need to leave around the extra bloat of the old libs.
in unix (or BeOS for that matter), you can have:
libgtk-1.0.0.so
libgtk-1.2.0.so
libgtk-1.3.9.so
…etc., and just have the headers around for building new (modern) apps. In windows, installers auto-upgrade over DLLs, or DLLs have to contain 14 versions of the same API to maintain bug compatibility, or they freaking rename APIs by appending a number at the end. That’s ugly.
…that’s “when Gnome breaks source *or binary* compatibility”, that is.
<blockquote>While I think that Microsoft overdid it a bit with compatibility, I believe that one should break compatibility every 7 to 10 years. Not once every year though (like KDE did
). </blockquote>KDE 1 and 2 libraries can run side-by-side. They support as much legacy as Microsoft, anyway.
Gnome 2.0 is built on GTK 2.0 which means we can ditch X (in GTK 2 apps) for Linux Framebuffer.
<blockquote>and make a better Video server. one that makes it simple to write drivers to, one that is speedy, one that does not offer network transperency. if you are admining a server, you can do so through webmin remotly, or telnet in and edit some text files…. Do it now before people start writing popular comercial applications.</blockquote>Dude, there’s no reason to ignore remote desktops. It’s not a feature that slows down X. The lack of speed is due mostly to the window managers, XFree legacy support of <3, and occasionally the toolkits (QT3 is duper fast).
<blockquote>the new video server should have its own wiget set and be what applications write to, not the desktop environment.</blockquote>Sounds like <a href=”http://www.berlin-consortium.org“>Berlin (now named Fresco).
I do absolutely agree with Ranger Rick!
Since you will always be able to build gtk < 2.0 apps with the appropriate headers/libs that is nothing to complain about IMHO.
Ok, apps that aren’t ported to the new version of gtk will probably never be able to improve and use new features like AA but they stay exactly the way they are.
So please don’t complain about broken binary/source – compatibility
Here I shall attempt to debunk several myths about GNOME, X and UNIX in general.
1. GNOME is ugly
The <a href=”http://developer.gnome.org/dotplan/“>screenshots are only meant to display the new GNOME’s capabilities, not its looks. Yes, these screenshots are ugly, but only because no themes are employed. Looks are a matter of taste – I personally prefer the GNOME look (with a good theme ) to the KDE look (although KDE isn’t bad).
2. GNOME 2.0 isn’t much better than 1.4
Feature-wise, you are correct. Most of the work has been done where it matters: under the hood. This will provide a solid foundation to create useful features on top. KDE 3.0 will be similar – it is mostly a port of KDE 2.2 to QT3.
3. Breaking compatibility is bad/good
UNIX allows the installation of multiple versions of the same library. You should be able to use GTK1, GTK2, QT1, QT2 and QT3 all at the same time. In other words, there is little to lose and much to gain by breaking compatibility every now and then. Once a year may be a little too often, but this will slow as the toolkit feature set stabilises. Windows doesn’t have this kind of luxury, and so is bogged-down with ‘compatibility code’.
4. X runs like a dog and should be replaced
To quote an Anonymous post above, “there’s no reason to ignore remote desktops. It’s not a feature that slows down X. The lack of speed is due mostly to the window managers, XFree legacy support of <3, and occasionally the toolkits”.
X was built to do many things, not just run single desktop computers. For the most part, it does its job admirably. XFree 4 features a new, highly modular architecture which will allow the gradual phasing-out of the legacy 3.x code. Things will get better, but only with time.
So what are the alternatives to X? The main two would be <a href=”http://www.berlin-consortium.org“>Berlin and direct framebuffer rendering. Berlin is still under heavy development, and won’t be ready for a long time. I am of the opinion that the toolkit competition in the UNIX world has brought great advances in functionality. I am afraid that while a unified toolkit (like what Berlin offers) may unify development, it may also reduce the competitive drive that exists today. Direct framebuffer rendering is not a real alternative to X, because it is incapable of more complex features like operating over a network. It may probably find a niche in low-end systems and portable devices (PDAs, etc.).
Themes
I think that most themes is even uglier than the default look. Also I don’t like themes in general. Horrible for usability. You move from one computer to another and everything looks different. Have one design and do it right!
Features
I agree that improvements under the hood are very good. You are comparing Gnome 2.0 with KDE 3.0 though. Remember KDE 2.0? It had many new features + improved libraries. (The sad part is that the new complexity also introduced many, many bugs)
KDE seems to be moving much faster and they seem to be more organized.
Compability
I remember the difficulties involved when gtk+ 1.2 was released. Most gtk+ apps didn’t compile anymore and I don’t think there was an easy way to have both gtk+ 1.0 and 1.2 installed side by side.
Windows has a lot of compability code and you can run apps written for Windows 3.11 in Windows XP but is it bogged down? True, looking at the Win32 API and MFC is a horrifying experience but that’s something only developers has to deal with. Users couldn’t care less.
Maybe Windows would run faster without the compability code but it already runs much faster than Linux with KDE or Gnome and has many more features and better usability.
X will get better
I think so too but it will probably never be suited for todays desktops. X development seems slow and I highly doubt it will catch up with Windows and MacOS. Will they even move in the same direction? Windows and X have different goals.
Also I don’t think that the zillion toolkits for unix is a good thing. Again, usability suffers. The wheel is invented every other week, apps do not cooperate and looks different, development goes in all directions at once.
I like Linux/Unix but for reasons other than being a good desktop OS for average user.
“True, looking at the Win32 API and MFC is a horrifying experience ”
I really don’t think it’s such a bad API. Can you please explain a bit further what you think is so bad with Win32 API. Have you ever really used it?
i run KDE, compiled for my processor, by me, about a week ago. it opens a very large number of cans of whup-arse on windows and QNX. the difference is SOURCE. my system is optimised for me, only the libraries *I* want and only the apps *I* want. my system runs a decent web-browser (which QNX and BeOS cant match) a professional quality development toolchain and Knuth’s beautiful TeX.
all this weighs in at ~500MB. yes, BeOS fits in 50MB, but it uses stripped (ie: non-debuggable) libraries and doesnt have the 3 big apps i previously mentioned (yeah, i know theyre available, but i havent tested the size thing yet). lets break it down:
+ 150MB = X windows + Xlib. this would be less if i deleted unused drivers, etc…
+ 150MB = KDE. includes Konq, the best web-browser for linux which is more-or-less all i use from KDE (but more has been compiled, i was playing with kdevelop, but it sucked).
+ 150MB = /usr/lib. miscellaneous libraries. i probably need most of them, but as i said before theyre not stripped which increases their size by a factor of 2. theyre also compiled -O3 which means “make it fast, i dont care about size”.
+ 50MB = evenly spread. lots of config files in /etc and binaries in /bin, /usr/bin…
my windows partition has 900MB space taken up. and i dont have office or visual studio. that is the base installation + IE6. all i can say is the massive drop in speed and the 45% bloat must be backwards compatibility.
QED.
many people complain about the usablility of linux. i’m not going to say theyre wrong: Brooks says “Conceptual integrity does require that a system reflect a single philosophy and that the specification as seen by the user flow from a few minds.” he contends that usablility is directly related to the unity of the design, which for KDE & GNOME & GNUstep & LessTif & Tcl/Tk & the other million X toolkits could be seen as a problem. in fact, it was this problem that convinced Thomas Roessler to write KDE in the first place.
however, i dont like toolbars on the bottom of my screen and i dont like title bars either. i like window shading, not minimising and anti-aliased fonts (theyre a drug, i swear i’m addicted now). you might be different, in fact you almost certainly are.
this is a big problem. how can i have my preferences and apply them to all apps on all desktops, but when you use the same computer it reflects your preferences? i think microsoft is tackling this in .net – making passport carry your desktop with you would be very useful.
what do you think?
> I really don’t think it’s such a bad API. Can you please explain a bit further what you think is so bad with Win32 API. Have you ever really used it?
Take a look at the MacOSX apis.
>>”X was built to do many things . . .”<<
1 – display multiple xterms over a network
2 – display xclock
3 – display xcalulator
Years ago somebody built a skateboard and since the free-as-stallman camp is using its blueprints to attempt building a car.
>> I really don’t think it’s such a bad API. Can you please explain a bit >>further what you think is so bad with Win32 API. Have you ever really used it?
>Take a look at the MacOSX apis.
What is wrong with the Win32 API and what makes MacOSX API better? Can you please give me an example of what is bad with the Win32 API.
Win32 API is based on C and MacOSX API is based on Objective C (Or am I wrong?).
You can’t compare them.
Or are you trolling?
> I really don’t think it’s such a bad API. Can you please explain a bit further what you think is so bad with Win32 API. Have you ever really used it?
I’d try to explain.
When I first looked at MFC after learning C++ and coding some unix stuff I thought it looked alien. A lot of CAPS, WinMain, hungarian notation and lots of code just to open a simple window. I did some small test programs but then I decided to look for alternatives (and found Qt).
About the compability, there are stuff in MFC that are simply not used anymore, even in those minimal apps I did. Also, they say that there are data types (using hungarian notation) with wrong prefixes. They have changed the data type but the name is still the same (for backwards compability).
Yes, I admit I’ve used plain Win32 API to little to say anything but since it’s older and not OO I suspect it has similar problems.
I’m about to try C# and I think I will like that much better (coming from Java)
> I really don’t think it’s such a bad API. Can you please explain a bit further what you think is so bad with Win32 API. Have you ever really used it?
Yes. I spent a couple years when I was in college writing a 3d graphics engine, with a win32 frontend. Now, I’d been programming for years already, and was familiar with DOS mode graphics, and java for gui work. Obviously, java wasn’t going to work for the front end of my 3d engine, so I bought a couple books on the win32 api and downloaded scads of tutorials.
Now, for reference, the engine already worked, it just needed a gui. But regardless, it took me three weeks to get a usable, primitive gui on the screen. It took another 2 weekends of banging my head against the keyboard to get dialog boxes working and even then, they had that awful windows 3.1 look (this was in 1997). I could never get it to link against the modern ctrl3d.dll controls. And it crashed all the time because I couldn’t wrap my mind around how the system worked.
Now, in 1998 I bought BeOS 4.something and started porting my code. I dind’t buy any books (yet) and I downloaded *one* tutorial. I wrote a full gui and high quality interface in *one* evening. My first evening with BeOS. And it worked flawlessly.
After the mass BeOS exodus in 2000, I went to Qt/KDE. I ported my favorite personally written BeOS apps to QT in, on average, one day each. Even though Qt works *massively* differently from the Be API, it *makes sense*, so it wasn’t a problem. For reference, I was able to get my first Qt app (which was just a frontend to a geometric graphics thing I had written under BeOS) written and working in a couple evenings. No books, just concise developer tutorials and a friendly community.
So, as a fella who’s written gui apps under ancient macintoshes (Mac Classic with 496k ram, in pascal & c), digital cable boxen (in assembler and c), win32, java, BeOS, GTK+, & QT/KDE, I can say with experience and zero prejudice (because windows 2000 really is pretty good), that win32 was second worst api I’ve used, with MFC taking the cake. Frankly, I’d rather be back writing UIs for that set top box in assembly than write another line of win32 or MFC.
Here’s why:
No standard conventions. The “grammer” of the api is inconsistent. The only thing that’s consistent, is that almost every function parameter in the win32 api is a pointer to a different struct with about 300 entries you need to fill yourself.
Poor design. Being as it’s the 21st century, you shouldn’t still be using the kind of struct-packing, function pointer setting, void-starring and bitwise-orring that’s necessary for win32 and MFC. Somewhere, a gtk+ programmer is screaming
But I say, at least GTK is consistent and well documented, which brings me to…
Poor documentation (though, I confess I never paid through the nose to get into the developer network). In BeIDE, or KDevelop, I can highlite a function, method, whatnot and find html documentation explaining it effectively. In VC++ they had great support for standard c (in fact it was great) but their documentation for their own APIs was utterly lacking. Yes, it described every function, but no, it didn’t tell me anything useful.
So there’s my rant. I hope it explains why some people hate win32 apis.
>I can highlite a function, method, whatnot and find html documentation explaining it effectively
Highlight a function in “Visual C++ 6.0” and press F1. Voila! A HTML Page with a short description of the function, the arguments,the return value and where it’s included and what library is needed. Press the “Content”-tab and you get a tree-view where you can get the function-family and general info. A bit different from the awfull “info”-system in linux.
>The only thing that’s consistent, is that almost every function parameter in >the win32 api is a pointer to a different struct with about 300 entries you >need to fill yourself.
So many functions aren’t they which take structs as arguments. I can’t realy understand what’s wrong with taking a struct as argument when there are many parameters which needs to passed to the API. Maby it’s a matter of taste.
>So there’s my rant. I hope it explains why some people hate win32 apis.
I can understand why you dislike it. But I think a lot of people dislike it because it’s written by MS.
BeOS and MacOSX probebly have good APIs (I haven’t used them) but what I mean is that Win32 isn’t so bad. When speaking of API’s I must say that Gtk (the c-API) is/was (haven’t tried it in a while) a bad API (coding OO in C is not a very good idea).
Just my 2-euros.
Why don’t they hire designer ?
“i run KDE, compiled for my processor, by me, about a week ago. it opens a very large number of cans of whup-arse on windows and QNX. the difference is SOURCE. my system is optimised for me, only the libraries *I* want and only the apps *I* want.”
Then again, how long does it take before one comes proficient enough w/Linux so that they can take KDE from source and compile only the stuff they want to use?
Heck, I have installed a couple of distros (Slackware & Mandrake), where the installs are well over 1GB. I’d just like to be able to take a distro and build it from the ground up to include only the stuff I want.
I tried LFS and got about halfway through it, before I realized that it was much more work than I had time to accomplish.
Besides that, compiling under Linux can be next to impossible if you don’t know what the dependencies are and/or you don’t know what you’re doing.
>Highlight a function in “Visual C++ 6.0” and press F1. Voila! A HTML Page with a short description of the function, the arguments,the return value and where it’s included and what library is needed. Press the “Content”-tab and you get a tree-view where you can get the function-family and general info. A bit different from the awfull “info”-system in linux.
Looks like they’ve improved the help system in vc++ since I last used it, which was, admittedly, several years ago. I think I had vc++ 5.0.
I *still* however, don’t think that gui programming in low level languages it worth the effort. I know, from the tone of people on these and other boards, that real haxors write their own gui toolkits from the bottom up in assembler, or in binary via a hex editor if they’re truly 3733t. And that any user friendliness and system functionality is bloat.
Well, I say wring your brain out writing the logic for your program. Write it low level, make it fast and efficient, and design it well. Hell, if you design it well and *know what you’re doing* you can make it fast as blazes and still write it in something high level like c++.
But writing the gui shouldn’t take longer than your core logic. The gui should be nothing more than one way of accessing your program. It should be nothing more than a view and a controller. The program logic should be separare.
>I *still* however, don’t think that gui programming in low level languages it >worth the effort.
That is another question.(I _agree_ with you that gui coding in low level languages is not worth the effort.). The Win32 API may be bad since it’s based on C and not a OO Language. But it is a acceptable _C_ API.
I am currently designing a API and I am very interested in advices concerning API design. Personly I like High level apis that are wrappers for a simple core low level API.
At the end of the day… GNOME still has the ugliest Desktop Environment ever… KDE is the way to go š
If you want help on API design just look at a few good apis. Look at QT. Look at GTK. Cocoa looks nice, but I’m not willing to learn objective c.
Especially, look at GTK. I wouldn’t write a gui in GTK if you paid me — but, the c++, python and soon to be c# bindings look quite nice. Since you seem to be interested in making the core low level and the main API high level, GTK+ is a good example.
On the other hand, if you were to ask me, I’d just write the whole thing in a relatively high level language like c++. You get wonderful STL containers, iterators, exceptions, and flexibility to write parts in c, like file IO and whatnot. And, since you’ve got *real* object orientivity, your programs can haul ass, since they don’t need to cast and assert void pointers everywhere, like in gtk. Everybody complains to high heaven that KDE apps start slowly — well yes, they do. But compare running speed to GNOME apps… in my experience KDE apps run every bit as quickly and often faster than GNOME. If you look at GTK programming you’ll see hundreds of these void * castings and asserts and nastiness to verify that the GObject can actually be cast to whatever widget. That’s the trouble. Compare that to C++ where the only speed concern is vtable virtual method call indirection.
Anyway, that’s my 2c.
When the GNOME people say that this version will be incompatible, they mean that it’s not a drop-in replacement. You can, of course, have both in exchange for the additional disk and resources, but no Free Software users will have to do this for long, because major projects are already porting to GNOME 2.0. Shared library versioning is a feature of Unix. If you don’t have it, don’t complain when we use it.
Yes that means GTK+ 1.0 software still works on a Red Hat 7.2 system *if* you choose to install compatibility libraries, just like (most) Win3.1 programs run on NT *if* you choose to install the necessary compatibility environment.
The GNOME 2.0 stuff can live happily side by side with GNOME 1.x until you decide that you don’t need it any more and upgrade forever. If you’ve got some proprietary software that absolutely must have GNOME 1.0 support then you’ll be stuck with the bloat of compatibility drivers. If you don’t, you won’t.
None of this should be read as meaning that I think GNOME 2.0 is good or bad, because I simply haven’t tried it, even though at some point soon I will need to install it to continue my coding on the APPLICATIONS, which is what this is really all about, the GIMP, and Gnumeric and so on.
Arrgggh!
When you have tried to write an application in GTK then you can talk about how much it sucks but in my experience, having developed with both Qt/KDE, raw Win32, MFC, OpenStep, GTK and the BeOS APIs I’d say GTK is the best. Why ?
Well first of it doesn’t require you to use any OO language at all since GTK is just that, OO extension of C. The GLib and GObject libraries are great application frameworks providing superb control and extendability.
The GUI part of GTK width GtkWidget at it’s base works but it’s nothing revolutionary. The GNOME extensions to GTK are also a bliss to work with, incorporating into the GTK library, complementing and extending functionality. Often if there is something functionality you find missing in GTK it will be in GNOME. The documentation is scetchy in some parts, mainly BETA stuff but often the function calls and parameter names explain the context clear enough.
About Qt/KDE,
Qt/KDE is perhaps one of the most over featured of all the toolkits I ever come across. They have a wrapper for almost everything but they fail horribly when it comes to the design of the toolkit in itself. If you just need a simple Widget library it’s ok but if you are looking at it as an application framework it plain sucks. There is no good way to implement asyncronous IO for instance in the Qt library without using some kind of threading. The KDE libraries extend and/or replace the Qt libraries not like the GTK/GNOME variant but instead more of placing another KDE layer ontop of Qt providing extra confusion and extra indirection. Add to that the overall feeling of being a large, clunky overengineered framework that more or less looks like MFC5 without the horrible notation it is less than the best of the bunch.
Next up we got OpenStep,
OpenStep is a beauty, Objective C is a great language far better than C++ for GUI work and the OpenStep API is probably the best API I ever come across. It’s extendable like you wouldn’t believe due to the nature of Objective C. Unfortunately the open source version, GNUstep, is dated (and looks like shit too) and needs an update to bring it up to par with the Apples Cocoa. I don’t think OpenStep will ever “make it” on other platforms than OS X. It’s sad but so it is.
What about MFC then ?
MFC, as many people pointed out, has a horrible notation. True, hungarian notation and MFC naming schemes are teh suck. But to anyone who has ever used MFC and actually understood the Document/View/Frame/App thing they got going knows it’s pretty easy to work with as long you do the standard stuff. Add to that the best documentation I ever come across, a great IDE more or less revolving around it and a ton third party libraries and tools it is a very usable albeit not beautiful library. And they didn’t f*** up the application framework part like the KDE guys did when they, more or less, copied MFC.
Onwards to Win32,
Anyone who has programmed in Win32 knows how confusing it was in the beginning. “Window Classes WTF ?” but when you give it some time you will understand how the guys designing it thought. Win32 is more of a system programming environment than a GUI toolkit although the GUI part is what people tend to think of. As far as GUI toolkits come Win32 is not the best of them, not even compared to other C APIs but it’s not bad either. It has great documentation and is very powerfull. Asynchronous IO has fantastic support in the Windows family and that is mirrored in the Win32 API where you “poll” for data on almost anything. Besides Win32 UI functions should be compared with Xlib anyway. Compared to Xlib they still suck but not as much.
And finally we have BeOS.
The BeOS APIs are very immature but they have a neat design the way BMessages/BHandler/BLooper are used extensivly throughout. There is limited to no support for asynchronous IO and there is no “application model” as in MFC or KDE. Writing a complete UI BeOS requires quite a lot of effort compared to the resource files of MFC and Win32 or Glade but when you got the UI extending it is very easy since most modifications is all about deriving from a BHandler. Unfortunately BeOS is DEAD.
Although Winforms in the .NET libraries look like a mix between Swing and Win32 it seems to be a good enough. Nothing special but it ain’t bad either. C# is da bomb language, I just love delegates, very smooth but not as neat as Objective C selectors.
Well, my dream API would probably be the perfect Objective C wrapper around GTK where the GObject is the base object class, that would be great.
Please feel free to flame my post.
GTk+ is easy, consistent and there are themes (eg mozilla-2) that make it quite nice.
GNOME is nice as app framework but I still prefer enlightenment as window manager.
hopefully e17 will make his way
I have programmed nextstep/openstep, windows, gtk with glade and libglade and looked at kde and java and c#.
In my opinion the best is design: nice and broad design (it covers not only gui creation), very nice bidirectional programmers ide (you add a class you see istantly the class in the gui, click on it and you can create some instances).
I like also the idea that ide does not write 1 million of lines of code with comments “please do not remove this comment”…
I see gnustep is doing a lot of work to replicate openstep: please help them!
I obviously like a lot glade! True OO _design_ (you do not need a language to be OO expecially c++ that is not _real_ OO) and libglade remembers me nextstep a lot.
Oh and I can also use perl!
Windows programming is orrible!!! You lose time fighting with c++ to c calls or c to pascal calls…
Kde it too much c++ for my taste but is not bad.
I followed java from 1.0 and I see they are getting better (because 1.0 was not good at all š ) but more bloated. I will wait and see!
C# is nice, better than java but it has “borrowed” a lot of ideas from eiffel language. But not the best one: design by contract!
Mario
Many people seem to believe that we shouldn’t judge Linux by how it is now, since in the future, X and the rest of Linux will be much better. I’m sorry, but why should anybody bother using Linux NOW if the only explanations for its flaws are: “It’ll improve in time.” Well, BeOS, MacOS, and Windows are also improving in time, and as long as Linux continues at the same pace, it will always be in last place.
As for the comparison of OSes by matt, why is it that Linux advocates always compare a version of Linux optimized for their system to a default installation of Windows? Although I am sure Linux would still win against Windows 9x/ME in a fair fight, it would be surprising to see the results of an actual unbiased comparison between Linux and Windows NT/XP.
As for GNOME 2.0, I’m happy to see GNOME being developed again. When I used Linux, it was my choice for a GUI. It’s a shame they are sticking with Nautilus. One would believe that somebody in the GNOME camp would be intelligent enough to know that Nautilus is GNOME’s worst feature.
As for compatibility, I believe it would hurt Linux to be backwards compatible at this time. I wouldn’t bother with it until it was out of its infancy. After all, a child usually can’t fit in the same clothes he/she wore one year ago.
Whenever I run into the dump X vs. keep X debate I eventually have a thought to the effect of “Isn’t QNX a *nix-like system with the video server (Photon) integrated into the kernal?”
I have old articles on QNX RtP by Eugenia (from her BeNews days) and ArsTechnica, in the context of comparing it with BeOS 5 (sigh), but those were both some time ago now. Does anyone know if planned future versions of QNX address some of the areas of the QNX RtP 6.1 shortcomings? It seems like QNX is a viable *current* alternative for those looking for a lightweight, stable alternative OS with a decent GUI experience … but I have never used it.
I think QNX should stay, though I haven’t met a QNX user yet in person. I do like some of the stuff I have read and the QNX community doesn’t seem to be a bad bunch of folks from reading the forums they get involved in!
QNX 6.2 was just released as a closed beta 2 weeks ago — expect general release at the end of Q1.
Funny thing is that we all use QNX but we just don’t know it. Drive through an automated highway road toll — you are a QNX user. Stopping your car at a red traffic light — the traffic lights are controlled by a QNX system. Get a burger at Harvey’s — you paid your money into a QNX cash register.
Unfortunately QSSL thinks of QNX as a development environment only. They’ll never design it for anyone but developers. I was frankly amazed by what I saw when I first loaded RTP 6.0 … a completely POSIX-compliant operating system with a decent GUI. Sure it’s a realtime microkernel, and that has its disadvantages, but it was responsive and well thought all the way through.
I’ll be sure to download 6.2 when it comes. Hope it works with an AMD Athlon XP
I suggest to look at tigert site to see if GNOME is or not a good UI…
Yeah – but KDE has crap icons, and the default font (in Redhat 7.1, Mandrake) looks like an overstretched stretched Verdana.
I use it, but I don’t like it. Gnome will always have my heart.