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

[LonEagle]

I totally agree. What I'm wondering is, is this inevitable with software? Does every software package eventually get the feature creep sickness? Or is it because a certain development model is broken? I don't use TeX at all (mainly because I can't find a book on it.) so I can't speak for any quality of bugfreeness in that. But what seems to me is happening, is that Microsoft is setting the speed for the free developers. They are pushed by some invisible force to keep adding new features, or else people start saying the project is "dead".

Re:Feature Creep

[paul.dunne]

The TeXbook, Donald E. Knuth, Addison-Wesley, 1984. The ISBN is 0201134489. There is an etext version of the book (in TeX format, naturally) out there somewhere, also.

Re:Feature Creep

[gimpboy]

Kopka and Daly have a pretty good one for LaTeX:A Guide to LaTeX2e. It got me up and running in a couple days with the stander stuff that comes with RedHat.

I think it's a pretty good book for beginners like myself. You can get it at Amazon/Barnes & Nobel.

You really cannot beat the way TeX/LaTeX handles Chapters/Sections/Subsections, generates bibliographies, Table of contents, Lists of figures/Tables, etc.
There really isn't anything like it that I have seen in current wordprocessors. (not implying that it is a word processor)


john

Re:Feature Creep

[AeiwiMaster]

I know that Elliot(GNOME) is interested in finding a good formal testing approach for GNOME.
If you have some time to look at it please do so.

This links might or might not be of some help.

http://www.mirror.ac.uk/packages/prog/tools/GCT. html
GCT (Generic Coverage Tool)

http://www.gnu.org/software/greg/greg.html
A guile testing framework.

http://www.debian.org/Packages/unstable/utils/lt race.html
ltrace

http://www.canb.auug.org.au/~millerp/aegis/aegis .html

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.

Re:Feature Creep

[Catullus]

More Slashdot comments should be written as haikus. Moderate this up.

--

Gnome

[prakash]

I hope this will help in making KDE and GNOME more compatible with each other. Right now the newbies get fragmented and some use GNOME while some go the KDE way. Ofcourse we must give them a chance but we should also ensure that the applications are compatible with each other. Prakash FreeOS.com

Who pays for this?

[retep]

Meetings like this raise a question, Who pays for all this? It can't be cheap to get 20 developers from around the world to Paris.

Re:Who pays for this?

[lacage]

actually, firms like those which are listed in the sponsors section... They don't do this just because they like Free software... They ARE interested: there will be some press coverage of the event and many ppl will come there so many ppl will see their name...

Re:Who pays for this?

[boc]

try index.phtml.en

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

[pberry]

Keep in mind though that not every program can be made to work in a commandline mode. Remember, no everyone runs ncurses on their system ;-)

Also, a lot of the gnome and kde stuff is merely gui front ends to a command line program. Grip sits on top of any number of CD rippers and mpeg encoders. Gwget sits on top of wget.

Also when you mention that some of your favorite apps have gone to one or the other guis only please keep in mind that the people creating these works have limited time. A lot of decisions are based on saving time. Try reading kernel-traffic and you'll see how much of what goes on depends on the effect it will have on the life of Linus.

Finally, it is not required of programmers to support everyone under the sun. It is certainly nice if they do, but don't go laying a guilt trip on people if they don't.

Re:Linux applications

[cdwiegand]

It's not that easy. Really. I code geheimnis (see freshmeat.net/appindex), and I try to wrap around PGP 2, PGP 5, PGP 6, and GPG. Except for GPG, it's hard to wrap around a CLI-based program, since they're relatively one-dimensional and aren't designed for it. GPG's actually pretty good as far as being nice to other programs. Perhaps other programs should look at how Werner did it in GPG, because otherwise writing a GUI-wrapper for a CLI-program is like writing a Web wrapper around a CLI-app - a pain in the arse!

Re:Linux applications

[Anonymous Coward]

For the most part I agree with you. As others
have pointed out, some apps cannot be
command-lined, but I believe that there is a lot
of "functionality" that can be separated from the
GUI and made publicly available to other apps.
This could be achieved by something heavy weight
like exposing the interface as a CORBA service,
or something lightweight like a library (language
specific). In any case, programs that need
that functionality would access the
service/library.

Parsing the output from a process is not
always an elegant/efficient approach to making
programs interact. But then again, sometimes
it is very elegant - esp in the realm of file
based text processing.

Re:Linux applications

[Utter]

Binding your *real* code to a specific GUI is bad. It will stop you from porting to other GUIs, CLI and to platforms where your GUI isn't supported.

But I find it equally stupid to make a CLI interface and make a GUI wrapper. It will require that you build a parser and maybe even a whole script language for using the tool.

My point is that you either make a shared library or a COM object from which you then use from your GUI or CLI.

E.g., I would like a gdb or cvs shared library to be able to make faster and more sophisticated GUIs around these tools.

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

[liki]

A piece of addition, many new gpl-softwares use horrible coding practices, void pointer arithmetics allowed by gcc, assumptations on element sizes (like int == long) etc. Which means you cannot compile the source using decent compilers like cc on Solaris and good portability becomes compromised, most likely the software will only work on x86-platform.

Re:Linux applications

[gimpboy]

I could be wrong but...
I dont think you have to use KDE to use a KDE application. You do have to have the qt stuff installed, but you can run the application in any WM/DE right?

I have run a few KDE applications in twm. The only difference is that they cannot dock to the kpanel(which isnt running), and they missout on some KDE specific stuff. They are however functional.

People need to be able to use some sort of graphics library when writing xapps; which would you prefer? Please dont say tcl. Its really slow. Could you comment more with respect to this?


john

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

[ralphclark]

My point is that you either make a shared library...

Good.

...or a COM object...

Er, I think you must mean a CORBA object. COM object support is only implemented on Windows AFAIK, so implementing a COM object is as bad as writing the application directly to the GUI.

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Re:Linux applications

[ralphclark]

Keep in mind though that not every program can be made to work in a commandline mode. Remember, no everyone runs ncurses on their system ;-)

Then it's not a compliant box. Curses support is a part of standard Unix, with or without X. You might as well say that not everyone runs stdlib.

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Re:Linux applications

[Sludge]

The idea of moduluar applications with the GUI being a separate binary has interested me for a while.

Before I start my list, I'd like to say that I agree completely with Stiletto. One thing no one is disputing is that RMS's philosophy of making portable to the hardware and to the OS apps has served well; Hear him speak and he'll tell you that was one of the primary goals of the GNU project early on.

Here are some of the ways to separate the GUI:
1) mpg123 and gqmpeg are a combo that allows the user to play mp3s on the command line and with a GTK widget set. It communicates through signals. This is limited, but it's one form of IPC.

2) AF_UNIX. Unix socket IPC seems like a viable choice. Furthermore, anything that's written with AF_UNIX can be easily ported to AF_INET. (For those not familiar with the socket API, this means the GUI can be on another computer on a TCP/IP network, though I believe this is redundant with the way X works.)

3) Fire-parameters-out-to-commandline-binary. This works for simpler apps. For example, a program called xgrep, which is a GUI shell for grep would have dialog boxes, and other GUI widgets that represent parameters for grep. When everything is set and the user is satisfied, he would click 'search', which would execute the real grep. The output would be taken back to the GUI program.

The book Beginning Linux Programming, which was reviewed here on Slashdot covers quite a few ways, with some brevity (a chapter each) of using IPC. Perhaps someone with real world programming experience would like to reply to this and comment about the upsides and downsides of each one.

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

Re:Linux applications

[Havoc Pennington]

The problem with Java right now is that the target platform is Linux, and Linux does not support Java all that well even with proprietary solutions. There is no free version of AWT/Swing at all. This is changing, but it hasn't yet changed.

Many of the GNOME developers really like Java, it's just not practical yet for Linux applications.

Re:Linux applications

[harmonica]

I didn't have the opportunity to test the latest Línux JDK releases of Sun myself, but at least the Blackdown folks seemed to pass most tests. On Jan 3 Sun released RC-2 and they explicitly mentioned the inclusion of the Swing components: http://developer.java.sun.com/developer/earlyAcces s/j2sdk122 (you'll need a free login). The VM also is faster, but I'm not sure how it compares to IBM's fast 1.1 VM.

On the missing free version of the libs, that is of course true. BTW, while I know that classpath.org is supporting AWT, do they plan to come up with Swing? Is anyone else writing a free clone?

Re:Linux applications

[smurfi]

You might as well say that not everyone runs stdlib.

Not everybody does, right. Or even stdio. Ever looked at qmail source code?

To go back on topic: for my current project (OpenTrader -- no code yet, but getting close), I've gone the multiple-process way, for debuggability. It's much easier to trace whatever is happening with a hung or runaway background process without all those pesky X events getting in the way...

Re:Linux applications

[ralphclark]

That's very interesting; I hadn't heard of your project before now. Multiprocess is a common and sensible approach in real-time systems (I've some experience writing high-volume stock tickers and the like). Tell me, are you using Berkeley sockets or named pipes? A colleague of mine who attempted something similar on NT4 found that named pipes provided *far* better performance in terms of throughput than the sockets library (almost an order of magnitude better).

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Re:Linux applications

[ralphclark]

I thought I'd better add that (of course) shared memory controlled via mutexes ought to be the most efficient of all. Only problem is overflowing the queue at high data rates; you basically have to write your own pseudo-I/O routines to provide control over blocking vs. non-blocking etc.

I'm sure you already know all that, I just didn't want to appear stupid in public :o/

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Re:Linux applications

[holloway]

The GUI's end up being slow because they are processing text output

A little wrong there. Not all GUI apps with UI seperation need to read output text - the true seperation from UI is the option to output a number of ways. An example of this is something like MySQL results being sent to a PHP script. Quite a different format from the text output.

ps. All 'GDB' is an example of, is a badky designed app.

DOH!!

[Stiletto]

Look at me, forgetting that slash-B. Sorry, folks--I'll hit PREVIEW next time!
________________________________

Re:DOH!!

[Anonymous Coward]

yeah, I thought you were one angry son of a gun

Re:DOH!!

[Zurk]

In any event doing this is a bitch. The CLI tool may do as its told, but wrapping a GUI control around it means that you have to have some interprocess communication going on..i've tried to do this with a simple text parser which parses the output of the CLI but its not working as well as an integrated gui app would. problems with text being buffered and assorted crap (printf tends to buffer a lot) makes the gui tool unreliable at best.

Re:DOH!!

[Krusty Da Klown]

The true way to do this is to write language-independent objects using something such as COM (I'm looking forward to checking out KOM.) That way an interface can be written for any environment (shell, KDE, GNOME, etc.) without compromising the functionality or the integrity of the original code.

Re:DOH!!

[Krusty Da Klown]

Yeah but I like the spelling. :)

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?

total rubbish

[browser_war_pow]

This is about Linux development, not *nix development. GNOME and KDE were designed with Linux and *BSD users in mind. Though they will work on solaris, irix, etc.... they were meant to make Linux and other x86/ppc *nix's like Linux and *BSD easy to use. Solaris users probably wouldn't use GNOME/KDE anyway. You want Linux to win? Then stop complaining that one GUI is winning out, even though the majority of Linux users like it and want to code for it. Sorry but every Linux user I have personally met uses KDE or GNOME. Just my $.02

Re:total rubbish

[ralphclark]

GNOME and KDE were designed with Linux and *BSD users in mind. Though they will work on solaris, irix, etc.... they were meant to make Linux and other x86/ppc *nix's like Linux and *BSD easy to use. Solaris users probably wouldn't use GNOME/KDE anyway.

Where's your evidence for this? I rather suspect both the GNOME and KDE developers would be overjoyed if their beloved desktops became popular on a range of different platforms. Linux as it is won't suit *all* purposes and even where it does there are more issues to consider tham personal preference (say for example, a company which develops and sells Solaris applications). But even in these cases people may still want to run KDE on their Solaris box,in order to get more functionality and a wide range of free applications.

It looks to me like you're guilty of the same overdone advocacy as the people you're criticizing.

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Re:total rubbish

[PD]

Greetings, Earthling. I was one of the first 10,000 on the planet to learn about Linux, and one of the first 100,000 to install it.

I don't run either GNOME or KDE, finding them both to do nothing that I absolutely need.

So, now you know at least one who doesn't use a desktop.

Re:total rubbish

[Jonas �berg]

Well, actually he's right. The purpose of the GNU project is to create a wholly-free operating system; all GNU software is supposed to run on the GNU system. Making it run on other systems is secondary. Developers might accept changes from people on other operating systems and insert them into the code, but they shouldn't go out of their way to make the software run on, for example, Solaris.

Re:total rubbish

[ralphclark]

Hi Jonas.

I know you're an insider so I can only accept your answer with regard to GNOME. However the KDE folks aren't quite so politically motivated. Obviously they favour Linux but I expect they'd be prepared to go a little further to achieve multiplatform support since there's no ideological barrier to overcome.

Consciousness is not what it thinks it is
Thought exists only as an abstraction

Re:total rubbish

[Jonas �berg]

I suppose that might be true; they might be like XFree in the regard that they measure success in how many people use their software.

fast track developing

[Anonymous Coward]

This sounds like a good event which will allow the core developers to make quick headway as everyone will be in the same timezone(assuming sleep patterns are synced!) and people interested in using the GNOME development environment can get the inside track directly. Access to the developers has got to be one of the key benefits of Open Source projects such as this - you can mee t the person whose work your using and find out more about why they used a particular technique or the overall strengths/weaknesses in the design. I certainly hope to go if I can stump up the cash and the holiday time. blah

Re:Gnome email client?

[uh]

pine is pretty intuitive, college kids who have never used unix pick it up pretty quickly. If your users are more concerned with email and less with asthetics, they could lvie with it, however most have these priorities in the reverse order. Netscape's Email client does all that you've requested.

Re:Gnome email client?

[dangermouse]

Some KDE-affiliated people are working on Magellan, which is outlooky.

That's nice but..

[Asparfame]

What about all of those who have ideas for GNOME, but can't get all the way to Paris. Maybe if the GNOME developers started taking some of my bug submissions more seriously, they wouldn't need to spend all this cash.

Everyone uses KDE or GNOME? Wrong.

[Dast]

"Sorry but every Linux user I have personally met uses KDE or GNOME."

You need to get out more.

I know plenty of people who don't use kde or gnome. Including myself.

Re:How to troll slashdot properly

[extrasolar]

Wow. Content from a Troll!

I am now waiting for pigs to fly.

For example?

[drivers]

Please cite one significant instance of a program written for GNOME or KDE that would have the same functionality as a command line program, which does not already have an equivalent program written for the command line. I personally can't think of any. "Rant" is right.

Re:For example?

[Stiletto]

Fortunately, most examples I am about to list DO have portable alternatives, if you don't like their particular GUI. So I suppose it wasn't much more than a rant when I think about it ;-)


Many email/news clients are GUI only, but there are quite a few mail/fetchmail/trn wrappers.

Most if not all ICQ clients out there are standalone. A portable alternative is micq.

Most if not all GUI .mp3 players would be more usable as mpg123 wrappers.

Most GUI-based FTP clients are standalone.

--

I'm not trying to control what other people code on their own time, for their own reasons. That's one of the greatest things about Linux--the fact that anyone can scratch whatever itch they want. Rather I'd like to encourage people to contribute GUI's to existing command-line projects that are already portable and robust.

If all you want is a car with nicer doors and windows, don't rebuild it from scratch--instead contribute new doors and windows to an already working car.
________________________________

Re:For example?

[finkployd]

Most if not all ICQ clients out there are standalone. A portable alternative is micq.

Actually, the best (IMHO) icq client, LICQ, has the ideal type of interface. in order to run it, you need to compile and run a plugin. There is the standard qt-gui, but also they have a consol and working on a gtk gui. This is the type of coding we should be emulating.

Finkployd

Re:Gnome email client?

[Havoc Pennington]

Miguel and Nat's Helix Code company is hiring about 16 people (in addition to Nat and Miguel) to write an Outlook clone called Evolution, and they've already been working on it for several months. Since there are so many hackers on it it should certainly end up being finished and be pretty cool.

Why so much hostility?

[Anonymous Coward]

This was a pretty neutral announcement, yet I've seen a number of GNOME basher, some GNUstep bashers, and a few KDE bashers.

I'm glad the people who actually write code, work on the documentation, and work on the GUI human factors design, have a lot better things to do.

Long live GNOME!
Long live KDE!
Long live GNUstep!
Long live the command line!

Re:Why so much hostility?

[PurpleBob]

Phew. I'm glad I started browsing at +1 with hard thresholds - I didn't see any of that.
--

OpenTrader, Re:Linux applications

[smurfi]

I'm using sockets. Named pipes are unidirectional, so I'd have to set up a second pipe for the return traffic.

Anyway, any sensible operating system should have identical performance for unix-domain sockets and named pipes.

The reason you haven't heard of OpenTrader is probably that there hasn't been any announcement yet. ;-) We'll have to finish at least one module that actually does any real-world trading, or nobody will take the thing seriously. For reasons of pure arbitrariness, that module will probably be one that talks to Datek.