Slashdot Mirror
Havoc Pennington Answers
Signal 11 asks: There has been a lot of discussion about merging KDE and Gnome together either via a universal toolkit, or by actually merging the two code-bases together.
What are the technical (and legal?) obstacles that need to be overcome for this to succeed? How does the KDE and Gnome developers feel about such a merger? Is there currently any work being done to further this goal at present (by either camp)?
Havoc answers:
Merging the entire code base is completely impossible, both technically and legally - not to mention that it would involve scrapping and rewriting close to a million lines of code, actually more I think, once you count applications. So we can consider that an official Bad Idea.
However there is a lot of room to share code. Some things aren't really desktop-specific; for example, a sound server or my GConf configuration storage library or libxml or libart. These are components the desktops could easily share.
We're making lots of progress on interoperability. For example, the window manager hints spec, so your KDE desktop icons won't show up underneath your GNOME panel, your GNOME panel will work with the K Window Manager, etc.
Some work has been done on "themeballs" which are collections of "matching" themes; we'd have an app that knows how to install the theme collection as a group, so your GNOME app, KDE apps, and window manager would all reflect the same theme. Someone from GNOME has been trying to write a GTK pixmap theme that loads the Qt pixmap theme format, as well. (For proof-of-concept, check out the Sawmill window manager, which automatically "matches" the current GTK theme.)
CORBA is sort of inherently interoperable, modulo some small details. Things are looking pretty good on this front.
BadmanX asks: When do you see Gnome getting some sort of threading capability, like that which makes the Be operating system so integrated?
Havoc answers:
I think GNOME is a bit too high-level for this; I would expect it to be more of an X server or kernel issue. GNOME should be able to take advantage of multimedia speed enhancements almost automatically. Of course the Linux kernel and GNU C library already have a fairly solid threading capability, but it isn't used as pervasively as it could be perhaps.
As an aside, the glib library used in GTK+ provides a nice main loop abstraction that allows us to avoid the need for threads in many cases, which can make writing applications much simpler. There are some cases where threads are necessary (a server that does blocking IO for example), but we try to minimize their use because they are a maintenance and portability problem.
Skeezix asks:
Could you give us a rough timeline of what we can expect to see coming from the GNOME project in the next months, and years? Could you give us an idea of when we can expect to see the 1.0.50 and 2.0.0 releases of GNOME? And what will those releases look like?
Havoc answers:
1.0.50
1.0.50 may have come out by the time you read this. It has lots of small new features; the file manager has been significantly enhanced, the libraries have some new stuff for developers, there are "segfault dialogs" that come up and tell you when apps have crashed, control center fixups, logout animation, gdm2 (the first PAM-compliant X login daemon, someone told me today), gnome-session has no known crashes, removable media is auto-detected, etc. Just incremental enhancements.
Actually this release may not be called 1.0.50, I think we are calling it "September GNOME" or something. In any case; we've been releasing some component or other every week since GNOME 1.0, but this is a synchronized release of all the components and represents the end of our active work on the 1.0 series. (Though there will doubtless be a few small releases for whatever reason.)
I noticed a little flame war in the comments for the first article about "what has GNOME been doing"; basically we have been working on applications and next-generation development infrastructure. GNOME Workshop totals 400,000 lines of code, counting a semicolon as a line; this is close to a million lines if you use the plain "wc -l" method of counting. That's a whole lot of code hidden behind the sucky GNOME Workshop web page. Other GNOME projects over the last few months include the Bonobo component architecture, libglade, and bug fixes. :-)
2.0
It's probably a bad idea to announce a date for 2.0 at this time. Most likely in the first half of next year. Well, we are going to try our damnedest to get it done within 6 months I think.
One thing I'd like to see in 2.0 are multiple releases, not necessarily at the same time. The components as I see them are:
- GNOME Developer Toolkit: Libraries and development tools like Glade
- GNOME Desktop Environment: File manager, window manager, panel, trash can, etc.
- GNOME Application Suite: The 20 or so small utility apps that are distributed with GNOME itself.
- GNOME Workshop: The office suite
Here are some of my thoughts on 2.0, obviously it will evolve a little bit along the way and other GNOME project members will disagree:
- Bonobo component architecture library (already mostly done, has to be released and stabilized)
- New file manager (asynchronous virtual file system layer is done, code such as metadata database will be reused from gmc, but lots of stuff to rewrite).
- Hopefully a default window manager that we know works well with GNOME and we have enough influence over to "sync" with our release and be sure it has an interface we can live with. Of course you will still be able to choose your favorite WM if you want, we're working with KDE on a nice WM spec.
- Mozilla-based help system. The Mozilla build tree already has a GtkMozilla widget in it, and we're standing ready to slap a Bonobo wrapper around Mozilla as soon as the thing shows signs of stabilizing. Dave Mason at RHAD Labs is an expert on online help and SGML/XML (he wrote the 100 page illustrated GNOME User's Guide as well), and Mozilla hacker Chris Blizzard also works at Red Hat though not in the labs. We think that together they can create a sweet system.
- Replacing Imlib. This should result in some small performance gains, and a simpler codebase for us to maintain. The gdk-pixbuf replacement library has already been written.
- libglade integration. libglade is already in use, but we have to integrate it with gnome-libs. This is a library which parses an XML resource file and creates an interface. This makes for some serious rapid application development.
- GConf configuration system. This makes it much easier to deploy the desktop in computer labs or larger offices.
- Enhanced language bindings. We want to flesh out any remaining gaps in the language bindings and be sure these work well.
- Internationalization. Owen Taylor at RHAD Labs is working full-time on internationalization issues in GTK+; we will support Unicode, and all kinds of writing systems (including bidirectional text). Very few (if any) toolkits support internationalization to this extent.
- Printing. We already have a gnome-print library, which needs some polishing up for a stable release. It will be included in GNOME 2.0. Gnumeric and Dia already print using gnome-print, however.
As you can see we have quite a bit of code waiting in the wings ready to go in GNOME 2.0; that's why we hope to finish on a tight schedule. But of course things could go wrong, you never know.
Hackers who want to get involved are encouraged to start lurking on the mailing lists and the #gnome IRC channel, and start reading documentation on our developer's site. There's a lot of stuff to do and the future looks exciting.
Tet asks:
There have been many half hearted explanations for GNOME's poor performance, ranging from Gtk to CORBA to X itself. However, none of those really cut it. Given the responsiveness of standalone Gtk apps, I think Gtk can be ruled out. Orbit is supposedly 3 the fastest CORBA implementation by a factor of 3, even with all the assertions left in. While the X protocol may be somewhat slower than it could be, X is still quite responsive on my old 486.
I now have an AMD K62-450, and GNOME still feels sluggish, about the same speed as Windows 95 on my P75. That has to be wrong. Yes, GNOME probably does more than W95, including things like network transparency, and the like, but even taking that into account, along with Gtk, CORBA and X itself, you shouldn't be looking at more than, say, reducing performance by half, and that's being pessimistic. In reality, you're looking at GNOME being 3 or 4 *times* slower than it ought to be. Simple question: why?
Havoc answers:
This question is really too vague; let me know if my answer is still half-hearted. What is your setup? What theme? What window manager? Is your X server good or is it one of the semi-finished ones? What things are slow for you? Are you actually timing things?
I have a Pentium 166 laptop and GNOME is very fast and responsive. But I do two things:
I use only theme engines, especially the GTK default theme, no pixmap themes. If you use the glitzy themes you pay in speed and memory.
I use WindowMaker or Sawmill, not E.
There are some specific things we know are slow:
- Application startup is slow. This is primarily due to the fact that a GNOME application links to so many separate shared libraries; if we merged all the libraries into one or two giant libraries, you would have many fewer system calls on startup and faster start time. However, there would be some disadvantages from a maintenance/download-size standpoint. We've addressed this problem by changing Imlib to dynamically load libpng, libtiff, etc. on-demand instead of on startup; we'll probably be removing Imlib in the next release. We could probably change things so the sound libraries are also loaded on demand.
- GTK flickers a lot if you have opaque resize turned on. This is a complicated problem that's hard to address; the long term solution is probably to move GTK+ to an architecture like the GNOME Canvas widget instead of the more traditonal toolkit architecture based on X windows. The flicker isn't really slow, but it makes people feel that things are sluggish.
- Some versions of E do some things slowly. For example moving windows around can be slow. WindowMaker is much more consistenly snappy, and Sawmill is nice too. Those are just my preferences, lots of people swear by icewm, fvwm, scwm, etc.
- Some specific applications may be slow for whatever reason - if some particular operation seems too slow, please file a bug on http://bugs.gnome.org.
Anonymous Coward asks:
You are known to be a programmer, and a programmer always has some ideas on languages and tools. What of the currently available languages would be your programming language of choice now? What about two years from now? Why? How would you change it so it becomes the ideal language? What's the worst language you've written something substantial in? How would you change it so it becomes the absolutely most evil language?
Havoc answers:
OK, you are setting me up to be flamed. :-)
I don't think the language is really the primary issue right now. People are interested in the quality of the available implementations, the availability of support and training, the kind and number of useful add-on modules, the documentation, and so on. Basically for any project, you decide whether you need the speed of C/C++, and if you don't you do your best to use a higher-level more reasonable language with a good implementation. "Academic" languages like Haskell and Eiffel, while much nicer languages than Perl or Python or C++ or Java, have implementation issues that often restrict their use.
With the Cygnus/GNU Java compiler, lots of GNOME people are cheering for Java. We even have a good start on the Java bindings for GNOME. Java offers an object oriented environment syntactically similar to C/C++, but has some important safety advantages (no pointers), reduced complexity, and lots of nice libraries.
For rapid application development I like to suggest Python as a sort of "Visual Basic equivalent"; PyGNOME and libglade by GNOME's James Henstridge allow you to write a fairly complex, nice-looking application in a couple days. The Red Hat 6.1 installer is written in PyGNOME.
I've used Guile some as an extension language; the Guile-to-C API is very simple and easy to use. Again, an implementation issue that becomes important.
There's an O'Reilly book coming out about Perl/GTK, I'm told, so I assume those bindings are pretty good. Judging by the list traffic quite a few people are using them.
Anyway I've been playing with Haskell lately and I think there are some practical issues with it, but it's improving and I enjoy it a lot. So if I'm having a language war I like to defend it. But in practice I end up using C to write libraries, if I were writing a high-level tool I'd probably use Python. My largest two projects to date (Guppi and gnome-apt) are in C++. gcj makes me want to have another look at Java. Just use whatever works.
Ian Bicking asks:
There are a ton of preceding and current desktop environments: KDE, CDE, GNUStep, Windows, MacOS, Xerox Star, BeOS, QNX/Photon, and a whole bunch of others.
Are there any ideas from other such environments that you think are really neat? Any ideas that you would like to be part of Gnome, or even plan to try yourself?
Havoc answers:
We do our best to steal shamelessly from all other user interfaces; we have the Mac UI guide and a Windows box at RHAD Labs, as well as KDE installations, and we often look at how these other groups implemented a given dialog or widget. I'm sure the GNOME hackers on the net do the same thing; Miguel is always talking about the latest Excel feature he just cloned in Gnumeric.
In general we want to keep the UI "sufficiently similar to" the windows-mouse-icon model of Windows and Mac, because trying to be revolutionary on this point would be a disaster (read the gnome-gui-list archives if you have any doubts). But we like to add nifty enhancements, such as themes or the GNOME panel. And of course hackers who work on innovative stuff are welcome.
Most of my interface ideas are for particular applications. Having just written a book, I have an elaborate plan for the ultimate document-writing application. But Emacs will have to do until I get some more time. :-)
SEGV asks:
Havoc, how did you find the process of writing a book? Can you tell us more about the process? How long did it take? How did you find the time? What were some of the hurdles you had to overcome? Are you as pleased with the final product as you imagined when you began? Would you do it again?
Havoc answers:
Writing a book involves sitting down for long periods of time and typing. As an activity, that's pretty much what it involves. :-) Well, there's some thought that goes into it.
Seriously. I wrote a "fast book," it took about 4 months. Lots of books are written in well over a year, but I wanted to write a book that people could begin using as soon as possible. If it sells well there may be a second edition sometime after GNOME 2.0 (even without the second edition it will continue to be maintained as part of the GNOME project).
The process is simple. You make an outline and get opinions on it from all your editors and technical advisors, then you revise it a few times. After that you start to write the chapters in the outline; each chapter is reviewed for technical accuracy and writing quality, then sent back to you. You make the suggested changes, then submit the final chapter. After you've done that for all the chapters, you just wait for the book to appear in print. That's about it, modulo some boring details.
I found the time by spending a lot of weekends with my computer instead of doing something fun, and by staying up late some nights. I think in general there is a poor work/pay ratio, so it's important to want to get the information out there, you won't be getting rich on book-writing.
ajs asks:
I hear things about Glade getting sucked into core GNOME libraries as a way of dynamically reconfiguring applications (an ambitious goal!) How much planning has been done for this, and is it expected to impact application performance?
Havoc answers:
Well, we are already using libglade in some applications, such as Gnumeric, and it doesn't seem to be causing a problem. :-)
Glade won't be sucked in, but rather libglade. libglade has about two function calls in the whole library; all it does is load an XML file generated by the Glade GUI builder. It uses the file to create widgets for your user interface. You can avoid writing widget-creation code; you just have to write the callbacks that actually implement the functionality of your application.
There is some amount of performance overhead but it is fairly small and only at application startup time; once you've loaded the widgets, they are just as fast as they would be if hand-coded. There are also some performance advantages:
- You can often halve the number of lines of code in the application itself, thus reducing application size.
- You save tons and tons of programmer time, so hackers can focus on optimizing the truly time-sensitive portions of the application.
If speed becomes a genuine problem we can implement a way to "compile" the XML files into some kind of high-speed binary format I guess. That would be pretty trivial and would avoid the XML parser overhead. But as I said, we're already using libglade in several places and I haven't noticed a speed problem.
Next week: Eric S. Raymond
By far the most obvious one is the time taken for the Gnome start menu to become visible.
I'd recommend turning the "store menus in memory" setting in the global panel preferences to on.
Also, putting the system/user/etc menus as submenus speeds up the initial draw.
The problem is that there is a lot of disk access involved, my guess is that this will be improved in 2.0.
..but I was wondering if you could clarify for me exactly what your status with Debian is now that you work for RH. Have you orphaned your packages, or are you still actively maintaining them? What's the state of gnome-apt? Last I checked it was (don't take this personally, please) pretty pathetic. Are you working on it or have you handed it off to someone else?
In general -- what's the situation?
Daniel
Hurry up and jump on the individualist bandwagon!
Please don't do this. Stick to regular version numbers. Since Win95, everything has started using a date to signify versions, and it sucks. October GNOME could have 3 typos corrected over September GNOME, or it could have 50,000 extra lines of code. There's no way to tell how whether it's a major new release of not. In contrast, 1.1 is a fairly good clue that nothing major has changed since 1.0, while 2.0 usually means major new functionality.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
GNOME really does need a default window manager. E shouldn't be it. We duplicate a lot of stuff. Now I'm not saying you shouldn't use E with GNOME, but you shouldn't feel like you have to do either one.
--
Geoff Harrison (http://mandrake.net)
Senior Software Engineer - VA Linux Labs (http://www.valinux.com)
Geoff "Mandrake" Harrison
Some Random UI Hacker
Whether or not Redhat ships E as the default it doesn't particularly matter. they shipped it because at the time it was the most feasible thing to ship that worked with GNOME. Luckily for them they have some other choices now. Despite the fact that I was happy to see enlightenment in the 6.0 load, I still don't think enlightenment is finished, or ready for a large-scale use. Maybe when we hit 1.0, right? there are still lots of bugs (even though I don't always see them, I am sure they're there) and there are still tons of features to implement, and there's always the high chance that we'll scratch a lot of basic stuff and rewrite core segments of code. Right now there is still a lot of work to do. I'm not saying you shouldn't run E, only that we've got a lot more up our sleeves.
--
Geoff Harrison (http://mandrake.net)
Senior Software Engineer - VA Linux Labs (http://www.valinux.com)
Geoff "Mandrake" Harrison
Some Random UI Hacker
Whether this boils down to personal animosity or not I can't say, but while the RHAD/Gnome team are pulling away from using E, Mandrake and Rasterman are pulling away from GTK+. The Enlightenment configuration utility that complemented E 0.15 will be redundant in E 0.16, as all configuration can be done from E itself. The widgets used for this are native to E, not GTK+. Mandrake and Ratserman are also talking about a file manager utility built into uture versions of E.
Personally I use a mix of the Blackbox WM on my Sparc (small and fast) and E on my laptop (big and baroque). The file manager that may go into E would no doubt be seamless and well designed - but adding any further functionality to the WM has to be questionable.
Chris Wareham
The official Python tutorial is on-line, and there are some other intros here.
I know you said you're a broke student, but if you can save up enough Ramen noodle wrappers, consider David Ascher's excellent "Learning Python", which O'Reilly recently put out.
For Python/XML, I'd of course advocate my company's open-source 4Suite, but the XML-SIG also has an excellent package.
If you have any questions, try the XML-SIG's mailing list, where many python/XML gurus hang out.
Good luck.
--Uche
"What thou lovest well remains, the rest is dross" -- E.P.
I must add that it was with somewhat of a cringe that I read H.P.'s comparison of Python to VB. I understand that the point of the comparison was to highlight Python's strength for rapid prototyping, but I wonder whether readers may get the impression that there is more similarity there. Python combines elegance and versatility in a way that VB cannot approach. The evolution of both languages from different teaching languages (the unfortunately successful BASIC and the not-so successful ABC) is an interesting aside in Computer Science.
I do get quite weary of explaining that Python is _much_ more than a prototyping or scripting language. I have used it in place of C++ (my favorite before ANSI got their hooks in it) and Java many times over and I see it fully as an application programming language.
--Uche
"What thou lovest well remains, the rest is dross" -- E.P.
> It's up to window manager, not desktop environment to deal with global key bindings.
Grog no understand, Grog have desktop, but desktop no work way other desktop work. Grog want feature in desktop and Grog not care what part of desktop do what part.
Now if SawMill can do that, then it already sounds a lot more powerful than E, and I might suggest that gnome ship with some keybindings that do all that. Matching a window by its title does not seem to be the most elegant way of doing this. Something on the order of xtoolwait that gives me the windowid of the newly mapped window would be far more preferable.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I was using kde since the beta versions, and tried out gnome at the 1.0 release. After many cries of disgust and peals of ridiculing laughter, I swore off gnome forever. Recently I played musical distributions, going to debian then back to redhat 6.0 (I won't get into why) and in the process, installed gnome and not kde, as I wanted to work with KDE from CVS only.
It's not bad now. It's definitely a lot faster. E is even respectable looking, though I have plans to replace that with Sawmill. What with the million and a half language bindings for gtk+, I definitely can't hold the language card over its head. But I still have some issues with gnome. Mind you I have 'em with KDE, but this isn't a KDE forum at the moment:
DOCUMENTATION!!!: I can't say it enough. The state of GNOME's documentation, from gtk to everything else, is pathetic. The KDE classes themselves aren't always terrifically documented, but Qt's documentation is phenomenal. Make no mistake, GNOME has irretrievably lost potential developers because they couldn't get the documentation they needed. This has to be addressed. Raw API docs don't cut it, examples and introductory texts are essential.
If you're shamelessly ripping off items from other desktops, here's something to take from CDE: I'd like a panel setup that had several drawers of grouped functions ala CDE instead of one awful Cascading Menu From Hell known as the "Start Menu". Take this from CDE: create drawers that have an icon that when clicked, start the app, and an arrow *above* them that opens the drawer. Have drop targets in all the drawers that can add a new item to the drawer. Allow setting any item in the drawer as the launcher icon. CDE is otherwise an awful cumbersome piece of junk, but this feature is just so amazingly ergonomic and useful. You work for Redhat, they have to have an old copy of TriTeal CDE sitting around: boot it and learn it.
Another thing I'd like to see is a popup "run" menu, like KDE's alt-f2 or window's meta-R. See, I bound this in enlightenment to a key, but it tended to launch an instance of the launcher every time I hit the key, in a random place, then didn't give it focus. If I set E to give it focus, I would have to make it give *all* popups focus. Alt-F2 is probably the single reason I still run KDE (and now it's gotten buggy with focus problems that it's losing its worth).
I've finally had it: until slashdot gets article moderation, I am not coming back.
Along those same sorts of lines..
I have a friend who has an Imac, which will say customizable random things for different error conditions. I almost fell off my chair when I heard it say:
"Well, at least it's not the dreaded Blue Screen of Death..."
hehehe
Ben
python.org Go to "documentation" and choose "Tutorial". That and the library reference (both free) will get you pretty far, though I must say that ORA's "Learning Python" is an amazingly well-done book that covers more than the python tutorial.
Most of you have probably heard about Python, Perl, Java, and the other languages Havoc Pennington mentioned in his answer to the potentially flame-inducing "what's the best language" question. Here's the URL to the Haskell Home Page that has lots more info on the language and down-loadable implementations of Haskell compilers and interpreters.
It might not be the language for everybody, of course...
King Babar
Babar
Hello,
I thought that the questions with the highest scores would be sent to the person that's being interviewed.
However, I notice that Havoc answers questions that had a score of 3, while a lot of the questions with score of 4 are not answered. Does the person who is interviewed select the final questions?
Mvg,
Ivo
I thought they already had. ;)
Does it matter though? Raster and Mandrake have said over and over again that they will add whatever features E needs in order to be the wm with the best options/configurability. For example, take the kde support in the dev 16 snapshots. Most E users really love E, and if a new desktop widget comes out that does not yet have E support, I'm sure that someone will step forward to code it.
Sig:
Barbeque is a noun. Not a verb.
The dialog gives you a process ID you can use to attach with gdb/DDD or send an abort signal to the process. This is the most reliable way to implement this feature I think; Gimp had code to attach gdb on segfault for a long time, and it didn't work that well.
Please keep in mind that I don't speak for Red Hat, these are my personal preferences. I'm talking about the GNOME default anyway, not the RH one.
GNOME can be used for proprietary software without any fees. However, this is not legal advice and you should read the GNU Library General Public License and understand how its terms apply to you.
Right, the panel menu has problems. It is actually checking for newly-added entries, which appear dynamically. So it's doing a bunch of slow filesystem access. But this feature probably isn't worth the speed hit.
We'll definitely want to look at fixing this code for 2.0.
The control center could use some optimization as well, you're right.
By far the most obvious one is the time taken for the Gnome start menu to become visible. No, I haven't timed anything, but it should appear almost instantly, even on low-end hardware. It's slow whether I click the foot on a panel, or bring it up from within E -- BTW, I find E to be more than fast enough for everything else. It's slow whether I use the default theme or pixmap themes. Using my preferred wm (fvwm2) doesn't help, either.
There's also the Gnome configuration utility. It redraws things *far* too much. This could be an inefficiency of gtk+, or it could just be that Gnome uses gtk+ calls in a less than optimum way.
I have more than enough memory (128MB), and a fast video card (Matrox G400), which I'm using with the XSVGA-3.3.5 server. Yes, G400 support is relatively new, but it draws on the previous G100/G200 support, and is fast enough for other things.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
you can take a look at some of the new imlib 2 stuff off our web site. obviously it's all just toys. I personally don't care if the gnome people keep using imlib or not, but I can tell you it wasn't designed with gnome in mind, so their using something else that was designed with gnome in mind is probably not a bad thing. Imlib was more designed with enlightenment in mind, with a caching system that enlightenment could use. That's the long and the short of it. Imlib happens to solve a bunch of problems for other people, and I don't find imlib nearly as frightening as some other people do. But they're right about it being fairly closely tied to X. It's the same reason you won't find porting enlightenment to a non-X supported platform fairly complicated. I'm not sure if this post had much of a point, but I hope I helped you at least a little
--
Geoff Harrison (http://mandrake.net)
Senior Software Engineer - VA Linux Labs (http://www.valinux.com)
Geoff "Mandrake" Harrison
Some Random UI Hacker
I have been passively watching gnome develop since around .60 and am very excited about the progress everyone has made. With that said I have noticed that there is not really a gnome user community. For instance, the KDE web site just seems more pointed toward users while the GNOME site is concentrating on a developer style site. Another thing I noticed during the interview is how much you are developing to ease the development work. I of course understand this but it seems the majority of development is to make development work easier, with users and UI falling just behind that. With so much work being done on this the gnome user community seems nonexsistent. I know that Miguel has setup a website with the help of volunteers to get users to supply input on UI matters etc.
.002$ of observation
I just wonder if GNOME will reorient itself to the userbase, instead of technical white papers a mass fury of user level documentation and support would really help out GNOME, IMO.
just my
-doobman
dons nomex suit
d) Imlib is one frightening piece of code. I wouldn't want to be one to help maintain it
(that, and the use of X calls in the 'gdk_imlib' portion of Imlib also made my life miserable as I played with win32/other non-x ports...)
--
"... the deep things in science are not found because they are useful; they are found because it was possible to find them."
"the deep things in science are not found because they are useful; they are found because it was possible to find them."
"For instance, the KDE web site just seems more pointed toward users while the GNOME site is concentrating on a developer style site."
I think you just nailed the biggest difference between Gnome and KDE at the present time! It also shows in other areas. KDE got the UI complete first (1.0) and left a lot of the advanced underpinnings for later (2.0). Gnome did just the opposite. With only a very few exceptions, everything in KDE is accessible via the keyboard, but in Gnome there are many applications that are unusable without a mouse. However, Gnome has myriads of bindings but KDE is still 95% C++.
Here at work, those people that use KDE are the ones that need to get their work done. Those that use Gnome are the Linux "evangelists". I'm using WindowMaker.
A Government Is a Body of People, Usually Notably Ungoverned
Havoc sounds kinda hostile towards Enlightenment, and the library it's based on, Imlib. I wonder why.
His comment about needing to pick a default window manager which they have more control over is disturbing. And why replace Imlib? It seems great to me.
Anyone familiar with the merits of gtk-pixbuf know why?
"There's so much left to know/ and I'm on the road to find out." -Cat Stevens
Let me first of all comment that Slashdot's plenary interviews, if I may coin a phrase, are very-well conceived and produce excellent results.
This, however, I think may have been the best of them. The moderation system forwarded a very even-handed and broad set of questions, and H.P.'s answers were clearly well though-out.
I'd also like to note that H.P. helps give the lie to attempts by some to paint the entire GNOME movement with a broad brush of script-kiddie dilletantism. Miguel has made some unfortunate comments about KDE in the past, and there are several trolls in various GNOME lists, but in my general ovservation, the GNOME developers are smart, focused on GNOME, cognizant of its shortcomings and willing to go to extraordinary lengths to eliminate them, including cooperation with KDE where appropriate.
I've had a chance to look at KDE 1.1.2, and it is an excellent desktop. GNOME is my desktop of choice, but I can see how the competition has improved both. There is no doubt that GNOME has more rough edges than KDE, but as a developer, I find GNOME more interesting and faster-moving than KDE. I am very excited about libglade, Bonobo and libxml. The embryonic Orbit bindings for Python open up endless possibilities in my favorite language. Openparts is the KDE phenomenon that most piques my interest. All I know is that the Linux desktops are implementing what IBM, Motorola, Taligent, Apple, Microsoft, etc. only talked about, fought over and roundly politicized, and I'm very excited to be a part of real progress.
So thanks to Slashdot, H.P., The KDE and GNOME developers. Thanks to the eternally vilified Red Hat and Troll Tech. And let's get on with the work.
--Uche
"What thou lovest well remains, the rest is dross" -- E.P.
"there are "segfault dialogs" that come up and
:)
tell you when apps have crashed"
I'd like these to be full screen and blue if possible. Just for fun.
Greetings,
Ivo
Here is some explanation from Miguel about why Imlib is being replaced: a. refcouting is implemented properly, there is no concept mixing between refcounting and caching which disabled us from activating things like the thumbnail support in the file manager as it would have leaked every single image loaded. b. It keeps the alpha channel in the image and it handles it correctly. This means that we can finally ship an image viewer that shows the alpha channel as well as not breaking the image (the previous ones replaced the alpha above 50% for a magenta color). c. It enables us to use all the power of libart and the image support in the Canvas correctly (because the ArtPixbuf data structure has been there since GNOME 1.0, it is not a recent addition). So, all in all, gdk-pixbuf will actually reuse existing code, while being correct.