Looking Ahead at GNOME 2
Able writes "This is a good article that will teach you how to use the new and improved libraries available with GNOME 2 so that you can write your own Nautilus view, and panel applets. It also provides you with the understanding to compile a few sample GTK+ 2 programs that will give you a good understanding of GTK+ 2's many improvements over GTK+ 1."
This might sound like trolling, but I'd wait a bit until the GTK libraries are settled before beginning to seriously develop for Gnome. One of the big problems with GTK from version 1 to 2 was how certain widgets went through two or three different revisions, namely that very attractive treeview widget. With bonobo architecture on the way, stuff might change even more.
-------------------------------------------------
charlton heston is more of a man than yo
Rubbish. XFree86 has supported what Microsoft calls "ClearType" for over a year.
The method, called sub-pixel rendering, is designed to work with LCD panels. This is why Microsoft are pushing for its use on laptops and palmtop devices. On standard CRTs, it holds no advantage over standard greyscale anti-aliasing.
A single pixel of an LCD screen is actually composed of three "sub-pixels": one red, one green, and one blue (R-G-B). Taken together this sub-pixel triplet makes up what we've traditionally thought of as a single pixel. This means that an LCD screen boasting a horizontal resolution of 800 whole pixels is actually composed of 800 red, 800 green, and 800 blue sub-pixels interleaved together (R-G-B-R-G-B-R-G-B
"ClearType" can be enabled in XFree86 versions 4.01 and greater by modifying
match edit rgba = rgb;
An in-depth look into sub-pixel rendering support in XFree86 is available here.
No, the transparent menu effect that Mosfet made for his liquid theme (and will now get added to kde 3.0 builtin themes I think) takes a snapshot of the area behind the menu and uses that image to make a pseudo-translucent effect.
Not a very good way of doing it in my opinion, and this becomes clear when you move through the different menus in a menubar, you can see the ghosts of the menu you had previously opened beneath your current menu.
If there is a better way of doing it, I'm not sure what it is, although I think you can do true translucent effects with Keith Packard's XRender extension.
But it doesn't seem that anyone is using that to do translucency so either its really hard to use or theres problems. I'd love to know which it is if anyone has some more information.
PS - No offense to Mosfet or anyone else using this code to do translucent menus, it's a very good idea and I do use it when I'm in KDE. I just think it'd be cool to have it without the little quirks like seeing things behind the menu that shouldn't be there.
FiGZ.COM - A waste of perfectly good web space
Ximian isn't a fork of gnome. They just package it for the end user.
This is a good article that will teach you how to use the new and improved libraries available with GNOME 2 so that you can write your own Nautilus view, and panel applets. It also provides you with the understanding to compile a few sample GTK+ 2 programs that will give you a good understanding of GTK+ 2's many improvements over GTK+ 1.
Not really -- that's what the series intends to cover, but this particular article only covers an introduction and overview of Gnome 2. For those familiar with the pace of previous IBM Developerworks Gnome articles, you know that it will take awhile before this series gets finished (assuming it does).
I think the key problem GNOME has is that there is no native web browser that isn't a complete monster. In my brief usability tests comparing Mozilla with Konqueror I concluded that Konq is lightyears ahead of Mozilla in terms of usability, customization, ease to compile, and integration with a desktop environment (note that this last is also a potential drawback since it depends on certain KDE i/o slaves to do its work-- and yes, it can run under any wm or destkop, but will be most efficient inside KDE).
I see the following two main advantages to gtk over Qt (and this is why I will not use Qt except as a user): gtk is written for C development. C is much more standard on Unix/GNU/Linux than C++. Perl is written in C, which means that adding wrappers for the gtk library is likely to be less problematic than for some other toolkits (although Perl has it's own excellent version of tk... this advantage is likely to extend to other languages written in C, Ruby being foremost in my mind).
gtk has the same LPGL terms for every instance of the toolkit. This means that no matter what type of development you are doing that you never have to worry about licensing, at least not the way you might with Qt.
It is too bad, however, that on top of these two fairly decent widget toolkits the desktop environments are vastly different. GNOME just ain't as easy to get up and running with as KDE-- and I mean in the "compile from source and install" sense. I've also noticed distinct efficiency differences between the two on low-end hardware (KDE coming out ahead).
What we're left with is a mess, but it's a good mess. We have real powers like IBM supporting gtk/GNOME, and we have other serious groups like the German government supporting Qt/KDE (witness the Aegypten project for secure communications). We get the best of both worlds, and fortunately we can do some mixing and matching as needed. So either way users win and developers seem to have two decent high-quality choices to choose from (forgetting about the ubiquitous Tk for a moment).
I do not have a signature
I am currently typing this with a USB keyboard, and will click the 'submit' button with a USB mouse, both of which are plugged into a USB hub on my monitor. If you plug more than one mouse into the computer each gets its own /dev/input/mouseX device.
As for installing font packs, yes it can be that easy. On my system I'd just have to type 'apt-get install kde-i18n-ja', but if you really must have a point and click interface to it, you can install RedCarpet which will make things similarly easy.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
Which strides is KDE making that are more useful than the ones GNOME is making? I'm curious.
I am also concerned about the Ximian fork, (even though I use it) How long till XImian hack up all the libs to work for their effort and how compatible will it be ?
Ximian does not produce a "fork" of GNOME. Ximian packages a "distribution" of GNOME and makes it easy to download. They tweak some minor things such as artwork, splash screens, etc, but it's not a fork of GNOME. I don't think you understand Ximian's relationship to GNOME. I suggest you spend some time on irc.gnome.org in #gnome and spend some time getting to know folks better.
Does it seem to anyone else latley Gnome is becoming a throw in everything and if the kitchen sink dosent work its OK, or is it just me.
That is not at all how it works. We're very particular about what we put in the release. I suggest you spend some time reading the archives of mailing lists such as desktop-devel. Much work has gone into making GNOME 2 more usable, accessible, functional, and a better development platform while keeping it solid.
Admittedly Gnome 2 has some nice stuff but how much will be functional by first release
We won't release if it's not functional :)
-jamin
Celebrate the finer things in life
Lo and behold, Gtk 2 won't need a hscroll because it will have word wrapping (finally!). The developerworks articles on Gtk 2 have a few screenshots.
People were refusing to use KDE due to Trolltech's licencing restrictions on QT - and even a few KDE developers started to create a free version of QT. Trooltech then decided to GPL their Unix version of QT and kept the QPL for the Windows in order to keep the revenue. Basically, Trolltech wants money.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.