Slashdot Mirror

Raw Gtk is a C library. Of course it's too much to type - it has to be explicit about a lot of things that are otherwise implied in most OO languages. Any proper OO wrapper hides that complexity. And, of course, 3 years ago is 3 major releases ago - and it changed a great deal from 1.x to 2.x.

Here is what a simple program in Python and Gtk looks like today.

Javascript is already used for building desktop applications, the most popular probably being Firefox.

Many desktop applications already use scripting languages. For example see the following list of python gtk applications.

Nowadays you can easily write the parts of an application that requires high performance in C and the rest of the program, including the interface, in an interpreted language.

The problem Javascript has to face, though, is that it has very few libraries available for desktop or web applications. And the existing libraries are specifically written for one or the other task. CommonJS would be a common library for all environments and would allow porting code from one to another a lot more easily than it is today.

A major fault that I've seen in numerous sub-threads is the idea that a Java user interface equals Swing. It most certainly does not. Swing is merely Java's complete pure-Java (i.e. cross-platform) user interface geared towards providing a unified look-and-feel. In this respect, it does a good job. While there's nothing inherently wrong with it from a toolkit perspective, it is absolutely not appropriate for usage on the Linux desktop.

Programming for the Linux desktop means more than producing a windowed application; one must integrate their application, both in terms of user interface consistency and application interoperabililty, with a major desktop distribution. Specifically, I'm talking about Linux's "big two" desktop environments, KDE + Qt and GNOME + GTK+. While each of these environments have their preferred languages (C++ and C respectively), many other languages have no issues whatsoever being tightly integrated into them via bindings.

Java is no exception! In Java, I can program a wonderful GNOME/GTK+ application just fine with java-gnome. Similarly, I can program a Qt4 application with Qt Jambi (although I can't seem to find an equivalent KDE4 bindings library) in Java. An application written in either will appear and operate on par with any application written in other languages, either natively (via C or C++) or via another bindings library (Python has a ton of bindings).

Furthermore, just like GTK+ and Qt have cross-platform capability, so do the bindings, and if the appropriate binding library for a given platform is installed on that platform, the Java application, too, will be able to be cross-platform without modification. This is, of course, the job of the distribution and/or installer software, but operates similar to the Deluge (Python) installer for Windows, installing the client port of the toolkit (GTK+, in this case) and the language bindings (PyGTK) alongside the application.

That's exactly how the Mono desktop applications work: they write their logic in native C# and use GTK+ bindings (GTK#, in most cases) to integrate with the Linux desktop environment.

Any Java application written for the Linux desktop that uses Swing over native desktop bindings is foolish. Each has their place, for sure, but on the desktop integration is everything.

Thoughts on PyGtk? I know people seem to like ignoring it. It has most of the positives of developing with C#. In the end you are either passing your code through a java interpretor or a python interpretor anyway. Plus PyGtk looks more crossplatform in a real way than C#.

From their site: http://www.pygtk.org/

PyGTK lets you to easily create programs with a graphical user interface using the Python programming language. The underlying GTK+ library provides all kind of visual elements and utilities for it and, if needed, you can develop full featured applications for the GNOME Desktop.

PyGTK applications are truly multiplatform and they're able to run, unmodified, on Linux, Windows, MacOS X and other platforms.

Other distinctive features of PyGTK are, besides its ease of use and rapid prototyping, its first class accesibility support or the capability to deal with complex multilingual or bidirectional text for fully localized applications.

...because GTK doesn't support doing floating and dockable toolbars or multiple open files in a good way

I use gtk.HandleBox for detachable toolbars and gtk.Notebook for detachable tabs. It's a good way.

...because GTK doesn't support doing floating and dockable toolbars or multiple open files in a good way

I use gtk.HandleBox for detachable toolbars and gtk.Notebook for detachable tabs. It's a good way.

Well, the same is true also for Perl, PHP, Python and even Lua, so that's nothing radically new.

The idea is to develop specifically for the set of libraries associated with Sugar. This means libraries like pyGTK, pygame, olpcgames, and in this case, pyBox2d and Elements.

There is a lot of information about creating OLPC Activities on the OLPC Wiki.

As for what is wrong with GTK + C? Well nothing is wrong with it but it's not the only choice. One thing to keep in mind though is that graphical displays usually consist of conceptual objects "windows", "buttons", "listboxes", "textboxes", etc. These are all "things" which to be honest, creating code to describe "things" is what object oriented programming excels at.

To be fair, there is gtkmm and PyGTK which are both awesome ways to do GTK development.

Both languages may have been established, but even today you don't see many "rich client" applications using either language

Except the official bit-torrent client etc..? I suspect we'll be seeing more as powerful multi-core machines become commonplace.

Java apps feel sluggish

Java is cross platform, naturally it's going to be slower than .NET. Performance is at least comparable and it's perfectly possible to write bloated, poorly performing code in C/C++ (hello acrobat reader).

the OP is an example of how well entrenched MS languages are with many developers.

That's kind of the point I was making. Not just that the MSDN mentality is entrenched, that Microsoft devs are often woefully ignorant of the alternatives. "developers, developers, developers" was afterall about getting developers to target Microsoft platforms exclusively. Terrifying concept :-(

Combining PyGtk and PyGlade is one of the most amazing user interface programming experiences I've ever had. That is to say, it's not completely unbearable. My favorite feature by far is that if you have a class (let's call it "InterfaceSignals"), you can call signal_autoconnect(InterfaceSignals) to automagically connect every method in that class to the respective signals defined in your Glade file, due to Pythons wonderfully introspective nature.

Also, unlike wxPython, pyGtk actually has very nice documentation. For reference, here's the signal_autoconnect method I mentioned:
http://www.pygtk.org/pygtk2reference/class-gladexm l.html#method-gladexml--signal-autoconnect

If you don't want to use Tkinter and hate the obtuseness of WxPython, there's always PyGTK.

"Doing GUI's is not the strength of any scripting language..."

This is why projects like pyGTK exist ;)

My goals are pretty simple: I want to write applications that have a great look & feel that will primarily be pulling information from the web (think weather & news), play with that information and present it in interesting ways. I'd like those applications to be usable on the Linux and perhaps Mac OS X platforms.


In that case I'd recommend something like python combined with some gui toolkit such as wxpython or pygtk.

...into the guts of the machine


Since you're on some unix-like system, you could do worse than plain C and a few books (C:ARM5 by Harbison & Steel and Advanced Programming in the Unix environment by Stevens spring to mind). Some asm knowledge might be useful too.

As for tools, frameworks etc. there is of course an unending list of those. For an IDE, a like emacs code browser.

If you're using Mono for GNOME/GTK development, it's actually quite stable, and much more usable than trying to write applications in old-fashioned C.

Yes, but let's be honest here: if you're writing a GTK/GNOME application you're writing a reasonably high level application and pretty much anything (Java, Python, hell even C++, bindings) would be "much more usable" than "old-fashioned C".

Please note that I am not dissing Mono. Variety is nice, and C# does provide a relatively nice language to be able to code GUI applications in. My issue is with the common implication that C# is unique in this - it isn't. Try out PyGTK for instance (particularly with libGlade).

Jedidiah.

I believe that its Python bindings are also decent.

The Python GTK+ bindings are the only thing keeping GTK+ running on my home system at all. pygtk makes using GTK+ a breeze. And I don't consider myself of GUI programmer type.

Check out tkinter and wxPython.

Unless you use Linux.

I can't stand tkinter and wxPython - wxPython/wxWidget's GTK implementation seems to use some nasty generic tree instead of GtkTreeView. It's _ugly_ in a big way. tkinter doesn't rely on an underlying toolkit in Linux and is also rather ugly.

I recommend pygtk There's even Windows bindings for it - and the applications look almost native on Windows. IMHO, more 'native'-looking than wxPython on GTK.

I generally find PyGTK to be cleaner than wx too, but that's just my opinion. :)

And then there's PyQT ... but I've never used it before ... anyway, I'm a gnome user ;)

Erm, not sure if this is a joke or not, however, VB is a language and Visual Studio is the IDE. Not sure what you mean by "command line" language, unless you mean there's no good IDE for it. It's just a language. You can create GUI programs, you can create web pages with it, and you can even created compiled Windows programs using Visual Studio .NET.

• A large standard library that rivals "programming" languages like Java
• Hooks into popular interface libraries
• for developing GUI applications
• A JIT optimizing compiler for speeding up interpreted bytecode to near-directly compiled code speeds
• Great support for regression/unit testing by allowing "main" functions to be used in every script/class file in large projects

In short, Python can do pretty much anything Java or Mono is likely able to do. In addition, it's faster and easier to code in than most "programming" languages, largely due to dynamic variable typing.

For developer friendliness Mono and Java are a step up from C/C++, but languages like Python (and probably Ruby, though I haven't used it) have potential to be even more.