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

[Anonymous Coward]

Gnome wants to be the
top Linux environment
Miguel leads the charge

KDE, ahem,
puts out a better product
sans all the fanfare

The real question, though
is why emulate Windows?
We need new ideas

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

[Anonymous Coward]

who else is tired of seeing screen shots of GNOME and KDE desktop.. always looks the same.. MP3 player..calendar.. bunch of term windows with chat.. how about some interesting tools and app for a change..

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?

[Anonymous Coward]

but how can u read this page it is in french

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

[Anonymous Coward]

shared library is the only choice, since the COM-style functionality is provided by the DE (WHY!?!). But wait, it gets worse. The two most popular DEs have INCOMPATIBLE Object models.

And its probably too late to fix it. Damn.

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

[Anonymous Coward]

while I agree with you, its not quite as bad as it seems, since GCC is portable to every platform under the sun. We should strive to write portable code (and for god's sake, why does gcc -ansi -Wall -pedantic still let you get away with some non-stadardisms?!?!) but its not a complete disaster.

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

[Anonymous Coward]

If you're looking for language-independent, don't waste your time on KOM. The only reason I code for GNOME over KDE is I hate this "C++ or the highway" attitude. The rabid KDE advocates will argue, but they have obviously never actually tried writing any code with the qtC bindings.

Note that many apps are written with the C++ bindings for GTK+, but no C apps are written with the C bindings for QT. KDE's #1 problem is that it is excessively tied to one language. Not using CORBA because mico sucks and NIH prevented them from finishing up the C++ bindings for ORBit was the worst mistake I've seen made by the free software community.

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

[Anonymous Coward]

"You want Linux to win?"

Win what?

Re:total rubbish

[Anonymous Coward]

"Those who do not understand Unix are condemned to irrational Linux advocacy"

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.

svefg cbfg va ebg-13!

[Anonymous Coward]

Guvf vf gur svefg cbfg va ebg-13! Urur, pbatenghyngvbaf ba svthevat vg bhg. :)

Ivfvg gur unvxh qvfphffvba ng ?fvq=unvxh!

Re:svefg cbfg va ebg-13!

[Anonymous Coward]

so u cant do real 1st posts n e more

Not true

[Anonymous Coward]

The stated goal of KDE at least is to bring *Unix* to the desktop, including of course Linux but no more than any other Unix. As a matter of fact, quite a few KDE developers I know use Solaris in lab settings.

Ripoff

[Anonymous Coward]

Not like it wasn't done by KDE first.

why you should use GNUStep

[Anonymous Coward]

"The GNU project has been hard at work on the Free Software product GNUStep, a product that will bring a truly free and technically excellent desktop to the GNU/OS. As a result of this project we already have released Window Maker, a fully functional window manager. The GNU project would like to ask Free Software developers to join and help complete this project."


--From GNU website

Is it just me or do they sound a bit desperate of the competition?

French?

[Anonymous Coward]

Why is the webpage in french? Are most GNOME developers from Paris? I'd like to know more about where GNOME developers are geographically located. Are they mostly french?

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: Titicaca

[Anonymous Coward]

Really?

Gnome email client?

[Anonymous Coward]

All I want to know is, when is there going to be a decent GUI email client for Linux? I've tried *all* of them I can find on freshmeat and searches of the web. All of them suck shit. Basically I want a GUI pine, html/image support inline with the message without launching external image viewers, etc. Kmail tries do so some of this but falls abysmally short and is horribly bug ridden and slow. So.. where are the Eudora's and Outlook Express's of the Linux world? AFAIK they simply don't exist. That's fine I suppose.. I can live with pine but new users definitely will NOT after using the Windows GUI clients. They are MUCH easier and much more intuitive.

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.

Re:Gnome email client?

[Anonymous Coward]

what are the best newsgroup readers? I want to be able to hide my true identity but Netscape doesn't allow me to do this.

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.

Re:Gnome email client?

[Anonymous Coward]

The way I heard it described, it will be WAY more than an outlook clone. I suspect it will feature an outlooky UI, though.

How to troll slashdot properly

[Anonymous Coward]

Someone needs to write (if it hasn't already been written) a simple program to post comments.. hundreds of them, as an AC. Exhaust the censors' points by using them to censor your trolls down. Then when they are empty, you can begin posting your Hot Grits stories at 0 instead of being censored down by the censors. This would be an awesome use of a Trin00 or TFN setup! Instead of flooding people, have slaves around the world sending messages to slashdot's comment section. That way even the editors won't be able to block you if it is coming from hundreds of different sites. Ah well. I don't like reading the troll crap but I disagree in principle with censorship of any posts. Slashdot didn't have this problem before they instituted mandatory logins to post as a non-AC.

Re:How to troll slashdot properly

[extrasolar]

Wow. Content from a Troll!

I am now waiting for pigs to fly.

Re:How to troll slashdot properly

[Anonymous Coward]

For someone who's been moderated up to 2, you can sure talk out of your ass!

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.

Thanks

[Anonymous Coward]

Looks like screenshots are on www.kdeforum.org which seems broke now.. when it is fixed I'll take a look. Sounds interesting.

Mi querido Miguel

[Anonymous Coward]

Ah, mi querido Miguel, you always had this thing for Paris and now that youve got a madral de dolares, youll be able to organize this Gnome conference in that city. Oh, well, if youve got it, flaunt it... (Do they say that in Boston?)

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.

not much interest in GNOME anymore?

[Anonymous Coward]

I'm just a bystander but about a year ago there was much interest in GNOME. Judging by the responses in this thread the interest seems to have waned down. What is it that has caused the loss in interest and sheer indifferences towards this previously highly-touted project?

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

Why should they?

[Anonymous Coward]

I am sick and tired of hearing everyone talking about compatibility. Don't get me wrong, if KDE and GNOME want to get together, fine. However, let it be their decision, and not public pressure. I hate everyone saying what KDE has to do with GNOME. Why? And what happens when a third desktop environment gets a following? Then KDE and GNOME have to be compatible with that? Besides, we all know why people are pushing for this. Aside from Rasterman's excellent work with themes, KDE beats GNOME hands down with their KOM/Open Parts model and with KOffice (a result of the hard work done on the KOM/Open parts model). People want GNOME and KDE to work with eachother so GNOME can finally get some applications under its belt by reusing (stealing) all the functional apps and KOM/Open Parts components from KDE. Then the GNOME users will bitch how KDE sucks, just so they can complete the hypocratic behavior known to most GNOME users. I say fuck that, and fuck these pro KDE/GNOME compatibility people.

Re:Why should they?

[Anonymous Coward]

I urge you to look into GNOME's component and document model Bonobo.

You can learn more about the various GNOME technologies that make up the component model here: http://developer.gnome.org/arch/componen t/

Bonobo uses ORBit, the GNOME fast and slim CORBA implementation for all its communication needs. Unlike popular belief, Bonobo components can be implemented as shared-library object, another process, or a remote process. Giving programmers the freedom they need

The Bonobo design is inspired by COM, Javabeans, Delphi controls, OLE2 and OpenDoc. The main document embedding interfaces are strongly modeled after OLE2, as this model is well understood, well documented and easy to implement.

Best wishes,
Miguel.

Re:Why should they?

[Anonymous Coward]

Bah, the KDE model looks much cooler. Look at developer.kde.org and get the embedded component tutorial thingy. It takes about a half hour to learn, is much cleaner, and is already used a lot in the KDE CVS (the image viewer, the PS viewer, DVI viewer, ...) not just the office suite.

GDB has non-command-line interfaces

[Anonymous Coward]

GDB has interfaces designed for interfacing with a GUI. It has many :-). See http://sourceware.cygnus.com/gdb/papers/libgdb2/ for a nice summary of the various interfaces (including what is wrong with many of them and how people are working on fixing it).

Agreed that none of them are where things should be, but in open source we don't call that "brokenness" we call it a "volunteer opportunity" :-).

Re:size does matter

[Anonymous Coward]

Yeah, but does she notice?

In addition...

[Anonymous Coward]

Just go set up a bogus webmail account, that way after you've exhausted all the moderator points, you can actually post your grits, portman stuff starting at a score of 1. With all the free webmail accouns there for the taking, there's no reason a troll should ever have to post as an AC starting with 0.

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

Gnus (is in GNU Emacs / XEmacs )

[Anonymous Coward]

Need I say more?

How is this flamebait???

[Anonymous Coward]

Improper moderation. The webpage says Gnome is a three year old project yet people keep on calling it young. That doesn't make sense to me.

Nope

[Anonymous Coward]

Turned out to be mostly talk and it wasn't able to do anything useful that other older projects couldn't do.

Maybe most are in Europe?

[Anonymous Coward]

You're making the assumption that people would need to travel a long way, presumably from the USA, to attend the conference.

Well, maybe most of them are in Europe, and hence this is actually cheaper?

I run BlackBox.

[Anonymous Coward]

I am a linux developer, and I run blackbox. It is simple, fast, efficient, and looks nice. It does everything I want and otherwise stays out of my way. I do not need (or like) KDE/GNOME, and can still get all my work done quite efficiently without them.

I think it's safe to code GUI apps for X. It's been around for awhile. While the "MVC" view has its merits, it's not always a valuable use of one's time to start out with a "headless" shared object before you even have a usable application--especially for apps that nobody is likely to run from a CLI. You would be writing the GUI over again *anyway* to port it to an incompatible system, so MVC/DocView aren't going to save you that step. Use a ported GUI library and you can avoid doing it twice.

In addition, it requires you to specify a complete interface before much code is written (and so before "proof-of-concept" items are worked out.) So when changes to the protocol are needed during development, a lot of work must be done documenting and synchronizing the interface and the "core app."

This is less of a problem in well-established areas like spreadsheets, where there are few unknowns in what you are going to be doing. But for any new or inventive application, having to specify everything beforehand is a waste of time because you will end up revising it anyway.

Professional appearance

[Anonymous Coward]

GNOME and KDE need professional-appearing applications. This means proper usage of grammar. It sickens me how many apps have absolutely shitty grammar in dialog boxes and popup menus. This, in my opinion, should be a major consideration in all applications, existing and in the planning stages. Nobody's grammar is perfect, but when you're writing an application only a little bit of text is involved. The coders should at least take the time (or have someone take the time) to double-check their grammar and spelling.
Call me a whiny bitch, but it's true.

Re:Professional appearance

[Anonymous Coward]

Your grammar bites ass.

Why GNOME hasnt taken over the world-

[Anonymous Coward]

GNOME is a great projects, however there are several
things which really seem to encumber it.
1. Lack of code re-use- basic GTK encourages far too
much reinventing of the wheel, lower level toolkits
are great as a back-end, but in the case of GTK, it
creates too much "bloat" and bugs. Forcing programmers
into a higher level toolkit certainly creates smaller,
leaner software.
2. Configurability bug- they want pretty rather
than stable, and bulletproof. -My 2c

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.