Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
GNOME GUI

Havoc Pennington Answers 90

Posted by Roblimo from the when-does-he-sleep? dept.
Monday we requested questions for Havoc Pennington, who is (among other things) author of GTK+/Gnome Application Development- and got plenty of them. Today we have Havoc's answers (click below). Read and enjoy!

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
I'd like to see these four major parts of GNOME released as separate packages. But it remains to be seen what we'll decide.

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
This discussion has been archived. No new comments can be posted.

Havoc Pennington Answers More

Havoc Pennington Answers

Comments Filter:
  • Probably a better place for this discussion is on the GNOME lists but I'm not a developer so here goes.

    Here's how it looks to me. (a) is a bug, bugs should be fixed (b) is a planned feature for Imlib 2.0 I thought, and (c) sounds like gnome-specific enhancements. Why not just work with E people on Imlib 2.0 ?

    Actually it sounds like Imlib was only used in the first place as a fill-in, and now the real stuff is being written. Is there a chance to make the new stuff robust enough and non-gnome-specific enough that the E people will want to use it? Wider use catches more bugs faster.

    The other reply mentions that Imlib code is a mess, but is it really less effort to rewrite than to clean up. (sometimes it is so this is perfectly possible).

    Just some thoughts,
    -Dean Townsley (slashdot ate my account)

  • Seg Fault Dialogs need Themes :-) (Score:1)

    by Anonymous Coward
    I wonder if the seg fault dialogs will be themeable? Maybe someone should get Jamie Zawinski to write a set of segmentation faults ala xscreensaver. An H.R. Giger styled OpenGL segmentation fault could make you look forward to application errors!

  • Check it out now (Score:1)

    by Anonymous Coward
    In case you haven't noticed already, GNOME 1.0.40 is out. Check out: ftp://ftp.gnome.org/pub/GNOME/sources/gnome-1.0.40 / And pick up the goodies.

  • where #gnome channel? (Score:1)

    by Anonymous Coward
    What irc network is #gnome on then?
  • Imlib is one rather awful piece of code. I suggest looking at it and seeing if you can make any sense of it. It has to be a real challenge to keep it up to date and do bugfixes. Furthermore, it has really really serious memory management issues that must be resolved before it really ought to be used this much.
  • The only beauty I find in Unix are SGI fonts and Enlightenment widget designs.
    What about that little yellow sparkly feature in Irix's window manger? You know, the one that appears on icons you've just clicked to launch an app and keeps sparkling until the app window appears. :) Every other environment I've seen has had the "Please wait while program loads" syndrome, first a simple text message, then a watch, hourglass, etc. Contrast the sparkly, which instead of saying "you're going to be bored for a bit" says "Something cool is about to happen!"
  • Bruce Perens seems to enjoy that sort of thing. He was the primary author of the Debian Free Software Guidelines. Perhaps you should check out his website - http://www.technocrat.net/ [technocrat.net]
  • hrm. let me first just say that I am a linux person (running linux by choice right now :) and this is not intended to slam X at all... just my own observations...

    sorry but I have to agree that windows 95 is probably faster than X on a 486 at doing certain things. i havent timed anything (I dont have my 486 anymore ;) but i was running Win95 on my old 486-33 a couple of years ago, with 20meg of ram it was actually quite usable - even running netscape 4.0..

    the quickest "feeling" graphical interface i have seen actually seems to be Windows NT 4.0. by this I just mean in window redrawing (sizing, moving etc). the OS itself is still pig slow at swapping, and swaps quite a bit more than it should with my 96 meg work machine.

    regardless, i can live with X. it is *fast enough* and much more useful than any NT machine :)
  • There are several tutorials at www.python.org.
    Read those and browse the Python library documentation.

    The best way to learn Python is to start writing some simple programs. For example, I often find myself needing to munge some text file in a particular way, so I'll write a little throw-away Python script to do it.

    It also helps to have an editor with a good Python mode (I use emacs). Python 1.5.2 comes with an IDE called idle (after Eric Idle).

    If you find that you like it, invest in the _Learning Python_ book. You can get it for less than $25. See

    http://www.bestbookbuys.com/cgi-bin/bbb.cgi?ISBN =1565924649
  • >Raw API docs don't cut it, examples and >introductory texts are essential.

    Have you been paying attention? Havoc's introductory GNOME text was just published. That's why he's being interviewed here.

    Also, the gnome panel does have drawers. Still, I wish the panel had been more like the TkDesk dock.
  • Of course, you have the source, you can do whatever you like :)

    Seriously, you can set the environment variable 'GNOME_DISABLE_CRASH_DIALOG' to 1, and it will disable the dialogs.

    You do know that if you don't report crashes, they are hard to fix, right?
  • ftp://ftp.gurulabs.com/pub/gnome/updates/ [gurulabs.com]

    1.0.40 RPM's aren't there yet, but my guess is that they will be soon.
  • A lot of the 0.99.x betas also had nicknames...
    Profiling Bonobo, Preening Bonobo, Superstitious Bonobo, Simplified Bonobo...
    (ok the last 2 were gnumeric)

    Anyway, you can call it 1.0.50 if you like :)
  • It seems to me that a simple enough fix is to have a CORBA method (say, reloadMenu) in the Panel interface. You could have a simple command line utility to call this (RPMs would use this for post-install, for instance).

    Jason.
  • Yes, the beta versions had strange primate nicknames. But they were mainly intended for developers or 'early adopters' who are comfortable keeping up with the latest releases and can remember what all the different nicknames stand for. Once you have a stable release which everyone is using, it makes the ordinary user's life easier to have meaningful version numbers.

    Of course, you can still have nicknames as well as version numbers.
  • maybe the answer would be to make the capplets just overall faster,
    ex: load less libraries, etc.

    or resort to a different style: perhaps a windows-style or beos-style preferences interface.

    the windows-style interface solves the ui problem by actually suggesting to the user that the different control panel elements _WERE_ different programs. (window with icons resembling program shortcuts) this slowed down actual use, because you had to contantly refer back to the master window, but it allowed you to have many applets open at once.

    the beos-style interface goes about it in a similar manner. the menu of preferences suggests that the different prefereces dialogs were different programs. this actually is better than the windows approach because the menu is always present, and always referable. this also incorporates the ability to open more than one at once.

    gnome already implements beos-style mostly, but that menu should be more organized and intuitive.

    in my opinion, if _ANYONE_ is looking for intuitive, usability ideas, look at beos, it is THE most intuitive and smart interfaces i've ever seen. you don't think about what you're doing to the interface, you just do it.

  • my interpretation of the control-center is that is it _TOO_ modularized. everytime your click down on another tree entry, it RUNS ANOTHER *_capplet (control-center applet). these are nice for adding functionality to the control-center, but it shouldn't have to load them while people are pursusing the tree. the response time is due to the fact that it has to load it from disk and then run that program.

    a nice configuration system that is designed similarily (front-end functionality, not back-end) is the x-chat configuration dialog. same tree, same feel. the difference is that it's part of the same program, it's already running, all the elements are already in memory.

  • E wants to be beautiful.

    I have yet to find beautiful Unix widget sets - even my beloved SGI falls short by using Motif. The only beauty I find in Unix are SGI fonts and Enlightenment widget designs.

    I think there's room for an Enlightenment widget set, for those who think computing should be gorgeous. Remember, if you don't want them, well, don't use 'em.

    D

    ----
  • Truthfully, I think you're being a bit nostalgic here.

    Windows95 was essentially unusable on any 486 - I still remember the start menu taking ages and ages to come up.

    I don't know how much better or worse Gnome would be; my guess is that neither would be considered even vaguely acceptable on either system.

    D

    ----
  • I fear that the control-center, one way or another, will not be able to avoid this. In order for there to be any chance of either maintaining the capplets, or installing new ones, they need t o be separate modules.
  • Gee.. men, you sound like you religiously HATE Windows.
    Calm down, you might get an ulcer or something ..
  • Don't forget to try Windows 95 on your 486. I bet it will be much faster than either Gnome or KDE.
    This is not a flame , just another fact to consider for those who continue to imply that X is just as good or even better than Win32 graphics subsystem ...
  • "The widgets used for this are native to E, not GTK+. "

    That's quite stupid. There are at least two small and very efficient widget libraries (FLTK and Windowmakers Wings ) available and what do we have here ?? Raster will come up with another set....
    I think I will puke next time I hear somebody mentioning that open source facilitates source code reuse ..
    Joke.
  • there was no mention of cross platform nature of GTK or gnome

    I would like to know how distributed GNOME can get corba allows things to be placed any compont on differant systems

    I understand that GNOME used a file instead of doing things so that they may be located on machines across the network has this changed ?

    alot can be learned from microsoft's experances with the registery !
    It seems that @ the moment the idea of a sudo registery to aid install and management in large role outs is sort of tacked on the end, are people actualy takeing this seriously ??

    in order to convince people at my UNI remote admin through a simple interface so that people have only to do so much customisation to achive a look and feel of enviroment is standard.

    fo instance a machine on an Arts course would like all options on the GIMP while a Software Engineering course would prefer that GIMP and funky things be hidden and Documentation for codeing be very apparnt much can be learned from the way windows 2000 regitery is set up and why it is that way. They have had alot of problems achiveing a dynamic desktop acording to the user and not the machine.

    also no word on what GTK port to windows and wether parts of code would be able to run on windows or any other O/S due to corba

    overall I would like to comend Mr H. Pennington on his answers


    regards

    john


    a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
  • Open source facilitates code proliferation and feature sharing between different applications. What you allow people to do is to create their own vision of what computing should be like. The boys writing Enlightenment would like their desktops to be as much of a piece of art as the underlying kernel. ;)

    Code reusability comes from coding great modularity. Which is why toolkits exist today. Otherwise everyone would have to write their own for each individual application. People *still* have the OPTION to do so, however it is easier for most people who might want to struggle with just getting the core components of the application finished that their themeable interface doesn't take years to finish. The reason why the filemanager looks to use a new set of widgets is largely reusing the widgets created for the new configuration features of Enlightenment (this is all my speculation, I don't actually know any of this stuff for sure since I'm not exactly a developer...:)

    WindowMaker's WINGs toolkit has been used to start several different filemanagers, but the most you can do with it is something that ends up looking like WindowMaker. And to people in the Gnome and KDE camps, they'd rather see all their applications LOOK THE SAME, and work relatively similar to the rest of their desktop environments. A seemless experience with minimal re-training time when installing and using a new application for the first time is an admirable goal.
  • You make a good point. The GNOME community, while it does have a good number of users, does tend to attract developers, and most of the work tends to be in development and making development easier, as you say. I would also like to see more work being done in the area of production of apps, better desktop environment, etc. This is where some cooperation with the KDE team could go a long way.

    Having said that, GNOME is much more than just a desktop or a set of applications. GNOME is an application development framework. I think it's crucial that this is a very solid framework. That's why seeing the work being done on the libraries and things like Glade is so exciting for me.

    --Jamin Philip Gray
    jamin@DoLinux.org

  • I'm afraid you misunderstood me. Actually, I prefer GNOME to KDE as a desktop. And I wasn't accusing anyone of KDE-bashing. I was merily agreeing the the person who saw GNOME lacking in a few areas. And I was pointing out that it is important to have a solid framework.

    --Jamin Philip Gray
    jamin@DoLinux.org

  • I'm sorry. I misread the thread and thought the message was in reply to mine, but it was in reply to a message that was below my threshold. Apologies. You can ignore my comment. :)

    --Jamin Philip Gray
    jamin@DoLinux.org

  • Err... that's a good point; I don't know why I didn't think of it...

    *SMACK* me now!

    Erm, report crashes? Naw... I just try to fix 'em myself... which of course, only leads to more crashes :-)
    --
    - Sean
  • Ahhh... I know why I didn't think of that myself... because I shouldn't HAVE to go into the source to disable them!

    I mean, sure I can, and the ability is nice and all, and yes, it's something I'd be able to do.

    But not for a lot of people. And if everyone else's performance is anywhere near mine (just look at the tty you started X from for a laugh), then I'm not the only one who this would be an issue for.

    Now, granted, it's better to fix the problem than the symptom, for sure. Much better to fix the crash than hide the segfault, but I still think that it would be good... especially for non-programmers and newbies, to have an option where they wouldn't have to suffer from clicking another msgbox every coupla minutes.

    Argh, enough ranting for now :-)
    --
    - Sean
  • Please, please, please tell me that you'll be able to turn this "feature" off...

    I get so many segfaults when I run GNOME... it seems that about 70% of my programs crash on exiting. For the most part I don't care (yes, I'm sure this is an indication of a more serious problem somewhere), since they're exiting anyway, but I sure as hell don't want to click on a stupid dialog box every time this happens...

    Please tell me I'll be able to turn this off somewhere!
    --
    - Sean
  • Whoa, whoa there...

    I've tried to stay out of the flame war for a long time now, but.

    I think you're reading more into this than is actually there. I'm sorry... I don't see anyone saying that GNOME is superior because of anything.

    What people are saying, is simply that GNOME tends to focus more on the developer community, and KDE caters more to end-users. That both have their strengths and both have their weaknesses.

    I don't see this as favouring either one or the other. People are trying to be equitable, and all of a sudden you come in accusing people of KDE-bashing.

    Sorry... I don't see it.

    All I see is a bit of paranoia on your part -- I'm sure it's not intentional, but you seem to be escalating an even discussion into a flame war. Which no-one really needs.

    I think more could be accomplished by following the lead of Havoc, and other developers on both sides, and trying to bridge the gaps -- combine the best of both so they work together, rather than get all high and mighty, and fanning the flames even more.

    KDE is superior in many ways. GNOME is superior in many ways. Lets' work so that we can use both, and harness the power of both, ok?
    --
    - Sean
  • 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.

    ... I use WindowMaker or Sawmill, not E.

    Some versions of E do some things slowly.

    Sounds like E and RH are about to part ways.
    ---
  • I love hearing from a Havoc Penguin. :-)
  • but does anybody know of a newer set of stable RPM's than the GNOME-1.0 set RHAT released in April?

    I could compile everything from source, but I have a slow connection and don't feel like downloading it.

    Thanks,
    JMC

  • I agree 100%...stick to version numbers. They are much easier to understand!

  • Interesting...

    My own system (an old Compaq P100, 32MB, 2MB Matrox Millennium) seems to run Gnome much faster than KDE (default settings - even with E as gnome's WM).. window resizing & moving seems snappier, and the system just feels smoother..

    I still use both of them (not at the same time though :o)

    It would be interesting to try Gnome using Kfm for both help browsing and for desktop icons, since gmc is quite heavy.

    I tried using KWM and KFM under gnome (also tried Blackbox, with and without the gnome-patch), but experienced frequent crashes; I don't know whether this is something to do with my setup (libc5) but I don't care too much; I just don't use them together anymore :o)
  • Another interesting URL is the ICFP Programming Contest [virginia.edu]. The preliminary results report that two of the finalists used Haskell. None of the finalists used C.
  • Yes! Give me a way to run commands without
    using the mouse, or get out of my way!

    :))
  • And he even answered yours! :)
  • I have been using Gnome on my home machine: a K6-2/333 with 32Mb of ram, and was also suffering perfomance woes in comparison to KDE on the same system. I think the main issue is memory.

    Switching to the default theme helped. I also dumped E and switched to wmx [all-day-breakfast.com] (which is only 82K compiled with Gnome support, no pixmaps, stripped).

    The other big gain was setting the default help browser from Netscape to the gnome help browser. (For some reason the control center wouldn't let me do this at first, I eventually editted a text file. It works now). The help browser has some limitations, most noticably no new window on button2, but is OK in general. It would be interesting to try Gnome using Kfm for both help browsing and for desktop icons, since gmc is quite heavy.

    Having said that, I never tried themes under KDE, so I don't know if it has the same difficulties. I recently added a cheap 16Mb dimm: having 48Mb makes all the difference.

  • 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".

    You can do that. Open a foot menu, open desired submenu, drag the title entry (first entry in a menu) and drop it on panel. Or click with button3 on this title entry, and add it via context menu, as drawer or menu. You can set it all up as you want. Then you can even remove the foot icon entirely, I don't recommend it, though.

    Another thing I'd like to see is a popup "run" menu, like KDE's alt-f2 or window's meta-R.

    It's up to window manager, not desktop environment to deal with global key bindings.

    The focus issue you expirience, is also problem with window manager. I bet it'd take few lines of lisp code to get sawmill giving focus immediatly only to windows which match some regexp.

  • If the list and ranking of questions is to be frozen at a particular time, perhaps the thread should be archived at the same time. This would avoid any confusion about what should or should not have been sent to the interviewee, as well as avoiding wasted work/points on the part of the moderators (assuming that work and points spent changing the rankings of posts is wasted if it does not affect the short list).
  • I have read the GPL and the LGPL many, many times. I have even discussed these licenses at length with loads of people. There seems to be a great deal of "legal" confusion regarding these licenses. FSF site really doesn't help much either.
    Where can I find intelligent discussions / articles about developing commercial apps with GPL / LGPL licensed programs.
    P.S. I do contribute to "free" projects and would like to use these devel. tools for some commercial projects (because many of my clients have policies in place to avoid getting tangled into any unknown licenses)
    Bottom line is: I can't give these people straight answers regarding GPL and LGPL and I would like to.

    Thanks
  • I contribute to "open / free" projects on my spare time. At work I develop / enhance "commercial" technologies. I would like to use more "open / free" development tools however licensing has consistently been an issue here. Q1: Can I use GNOME as a development environment for "commercial" development of proprietary processes and technology safely? ie: keep the secret stuff secret? Q2: Are there any costs either monitary or procedural I need to be aware of?
  • 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
  • Actually this release may not be called 1.0.50, I think we are calling it "September GNOME" or something.

    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.

  • 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)
  • 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)
  • 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
  • ...I want know where I can learn Python so, I can get started on development on it as soon as possible. I am a broke first year college student without any money so a free guide or tutorial on the internet would be best for me....

    The official Python tutorial is on-line [python.org], and there are some other intros here [python.org].

    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 [fourthought.com], but the XML-SIG [python.org] 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

  • 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
  • > 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 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).
  • 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 [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 [haskell.org] 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

  • 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.
  • 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.
  • Well, I never maintained any packages. I was working on the Debian Tutorial but John and Ossama's book makes that obsolete. I'm still in principle working on gnome-apt but it is stalled waiting for a better tree widget; that's a really big job, and I don't have a month to work on it in the near future. But I do intend to when I get a chance.

  • 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.

  • Havoc said: What things are slow for you? Are you actually timing things?

    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.

  • 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)

  • observation of gnome community (Score:3)

    by doobman ( 6198 ) on Friday September 24, 1999 @07:30AM (#1662421) Homepage
    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.
    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 .002$ of observation

    -doobman

  • Re:What's up with Enlightenment and Imlib referenc (Score:3)

    by mmarker ( 10942 ) on Friday September 24, 1999 @06:46AM (#1662422) Homepage
    As one of the people who did the initial work on gdk-pixbuf, let me add reason D

    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."

  • Re:I think you hit the nail on the head (Score:3)

    by Arandir ( 19206 ) on Friday September 24, 1999 @09:51AM (#1662423) Homepage Journal
    "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.
  • 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?

  • Re:Process to select questions? (Score:3)

    by Havoc Pennington ( 87913 ) on Friday September 24, 1999 @06:25AM (#1662425)
    Nope I answered all the questions I was sent.

  • Re:Process to select questions? (Score:4)

    by Roblimo ( 357 ) on Friday September 24, 1999 @06:39AM (#1662426) Homepage Journal
    We pick from the highest-moderated questions *at the time we choose them*, which is generally between noon and 4 p.m. Eastern on Tuesday. After that, moderators can still score questions up or down, but it's too late. I think this is what you're seeing here.

  • Thoughtful and Informative (Score:4)

    by Uche ( 6766 ) on Friday September 24, 1999 @07:37AM (#1662427) Homepage
    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

  • Nice feature :-) (Score:4)

    by Ivo ( 26920 ) on Friday September 24, 1999 @06:10AM (#1662428) Homepage
    "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.

Slashdot Top Deals

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Close