Gnome Developers Conference

Mathieu Lacage writes "On the 16, 17 and 18 March 2000, more than 20 Gnome Hackers from all around the world will gather in Paris to meet application developers, users and discuss Gnome future. To learn more about this, go here."

Comments

Feature Creep

[seaportcasino]

Hopefully they concentrate on fixing existing features rather than adding new ones. It seems that in the race to keep up with the latest and greatest, nothing quite works right. In fact, I shouldn't just apply this to gnome, but most all software in general. "Feature Creep" is getting out of hand. We need to get back to basics and make sure all the code works properly and is 100% bug free (like TeX).

Re:Feature Creep

[jrb]

Most of the work in GNOME-libs nowadays consists of removing unnecessary features, and trimming it down to size. Expect the next release of GNOME to have smaller core libraries, with the stuff people really needs in them.

Linux applications

[Stiletto]

OK, so I'm going to rant a bit.

Whatever happened to Linux applications? I'm talking about apps that don't require GNOME or KDE or GTK or this or that--simple command-line tools that run with or without X, written in portable C, so they can be recompiled on whatever flavor of *nix you have.

Traditionally, you would have an underlying non-GUI program that was portable to every environment under the sun, and then a seperate application or script that was a GUI to wrap around the command-line tool.

The result is a portable tool that works everywhere, and several GUIs that allow users to easily interact with said tool, under whatever GUI they use.

Lately, we are seeng more and more GNOME-this and GTK-that and K-this, etc. where the functionality that is inherently not dependant on any particular GUI is all thrown in with the GUI app itself! PROGRAMMERS: Limiting your application to a single GUI is not the Linux way!

I call this abominable practice "Windows-itis," and I believe that it may be caused by all these ex-Windows programmers that seem to be flooding into Linux-land.

You see, anyone who has ever done any Windows programming knows: It's difficult, if not impossible in some cases, to seperate the actual program from the GUI. The (IMHO horribly broken) Win32 API pretty much guarantees that whatever your application does, it will do it with one and only one GUI--Windows. From the message callback system through the entire codepath through most Windows programs I have seen and worked with, there is this assumption that there will always be the Windows GUI. Most "how to program for Windows" books reinforce this terrible style, encouraging inexperienced programmers to tie the functionality of their program into the GUI.

Now these programmers are tinkering with Linux. Don't get me wrong, this is a GOOD THING! The more people that learn about Linux programming the better for everyone! But these new programmers should realize, that not everyone in our world uses GNOME or KDE. Not everyone uses X! They may even (egads!) use FreeBSD or Solaris or some other kind of *nix. If you have a good idea for a program, don't limit it to one GUI and one system.

I've seen some of my favorite X apps go "GNOME-only". I've seen apps all of a sudden not work on non-Intel systems after a certain version. For the sake of the whole non-Windows community don't do this!!!

Remember, not everyone runs GNOME, GTK and XFree on their i586 systems. Good applications are portable applications--across different architectures and different GUI's.

OK, my rant is done. Go back to bed.

________________________________

Re:Linux applications

[Eman]

Well, even that method is not that great either. The GUI's end up being slow because they are processing text output. Not to mention that command line interfaces can't display information like GUI's can so for things like charts and stuff the GUI then has to run several commands, combine and process information in order to display it.

The proper method IMHO is to to just seperate your model completely, and have your controller and view linking to it.

Take gdb for example. The program has great functionality, but it is tied to the command line interface. So all programs that wrap it with a GUI must then process that text output making them perform horrible. It seems to me what should have been done is provide a object file that has all the various functions and variables for getting information about debugging a program. And then write a CLI that links to this object file and uses those function to produce it's text output. Then later if someone wanted to write a GUI, then they could link to the same object file with their fancy graphical interface and have direct access to the same functions and variables that the CLI has instead of just access to the output of the CLI.

So basically what I am saying is that the CLI is a controller and view just like the GUI. I agree with you that functionality and interface need to be seperated, and am just trying to say that CLI is an interface also and needs to be seperated just like the GUI.

Re:Linux applications

[Havoc Pennington]

In an ideal infinite-development-time world I think you are right, but you're not presenting a balanced view of the situation; there are a number of tradeoffs.

• Separating the engine from the GUI ("model-view-controller") makes the single-GUI architectural work a good bit harder up-front; we tend to do this religiously in large GNOME apps anyway, (though to save time you usually end up using GtkObject - or QObject in Qt - in order to do it).
• Once you separate MVC you still have to write the same GUI multiple times for each platform! Nontrivial.
• Another approach is to develop a cross-platform framework for the VC part of MVC, as AbiWord does; but this _significantly_ slows down development, if you look at Mozilla or AbiWord development compared to say Gnumeric you can see this very clearly. Gnumeric moves _at least_ twice as fast, if not more, and with fewer developers. So I'd say factor of four increase in development time.
• You encounter a least-common-denominator problem where you can't support nice platform-specific features (for example, AbiWord wants to use Bonobo but can't until they write an OLE/Bonobo abstraction layer, a big barrier to entry; Mozilla has an elaborate XPCOM architecture to solve this problem).
• Developers have to learn/understand those additional platforms; and to really make it work the lead developer needs two development environments on at least two platforms.

Anyway as a first cut, GNOME stuff is generally written with MVC in mind, and works on any UNIX running X, regardless of whether you're actually using the GNOME desktop environment (you only have to install the libs, your environment can be KDE or E or whatever).

The next portability step will be to use GTK as a cross-platform kit, as the GIMP does to run on Win32/BeOS; then eventually someone might invest the time to move apps to an AbiWord type of framework. However, doing all this stuff from the start would just be a failure, since we'd have no useful apps for the next 3 or 4 years.

Re:Linux applications

[harmonica]

Of course there are lots of applications that don't need a GUI. But in case you want to create a mulit-platform GUI application, you should consider Java and either AWT or Swing. Depending on who you ask about their experience with it they'll come up with answers ranging from 'it worked great' to 'total crap'. I'd really like to see a fair test of a larger Java app on many operating systems using different virtual machines. Java is not right for everything, but if your app is GUI-intense and you don't need every bit of performance, development is sure easier with lots of potential error sources (pointers, memory allocation etc.) removed. Not meant as flamebait! I still use C for CPU-intensive jobs...

Internet Development is not Enough

[grrussel]

It seems that as projects get beyond a certain level of size and or complexity, key developers must meet in real life. Either that, or go entirely Cathedral mode in development. At some point, the lag in discussions etc in net life makes such conferences needed. It sounds like fun as well ;-) KDE has had two similar conferences - just prior to the beta series for KDE 1 and also prior to Krash, aka KDE 1.89 Perhaps desktop interoperability should be talked about at these things - get KDE and Gnome developers together in a hacking environment for a while.

Some other large projects like the Gimp could probably get together for a quick conference / bug squashing session - 1.2 is eagerly waited. Any other suggestions for projects that could benefit from these type of meetings?