Slashdot Mirror

← Back to Stories (view on slashdot.org)

Gnome Developers Conference

Posted by Roblimo on from the moving-into-the-big-time dept.

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

24 of 92 comments (clear)

  1. Feature Creep by seaportcasino · · Score: 3

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

    1. Re:Feature Creep by paul.dunne · · Score: 2

      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.

    2. Re:Feature Creep by jrb · · Score: 3

      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.

  2. Gnome by prakash · · Score: 2

    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

    --
    Prakash
    FreeOS.com - The resource center for free operating systems.
  3. Who pays for this? by retep · · Score: 2

    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.

    1. Re:Who pays for this? by lacage · · Score: 2

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

  4. Linux applications by Stiletto · · Score: 4

    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.

    ________________________________

    1. Re:Linux applications by Utter · · Score: 2

      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.

    2. Re:Linux applications by Eman · · Score: 3

      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.

      --
      Eric Anderson
    3. Re:Linux applications by Havoc+Pennington · · Score: 4

      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.

    4. Re:Linux applications by ralphclark · · Score: 2

      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

    5. Re:Linux applications by ralphclark · · Score: 2

      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

    6. Re:Linux applications by harmonica · · Score: 3

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

    7. Re:Linux applications by Havoc+Pennington · · Score: 2

      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.

    8. Re:Linux applications by harmonica · · Score: 2

      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?

    9. Re:Linux applications by ralphclark · · Score: 2

      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

    10. Re:Linux applications by ralphclark · · Score: 2

      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

  5. Internet Development is not Enough by grrussel · · Score: 4

    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?

  6. Everyone uses KDE or GNOME? Wrong. by Dast · · Score: 2

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

    --

    This sig is false.

  7. Re:For example? by Stiletto · · Score: 2

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

  8. Re:Gnome email client? by Havoc+Pennington · · Score: 2

    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.

  9. Why so much hostility? by Anonymous Coward · · Score: 2

    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!

  10. Re:total rubbish by ralphclark · · Score: 2

    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

  11. Re:total rubbish by ralphclark · · Score: 2

    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