Slashdot Mirror

I'll second the goodness of the coming GNOME. The first thing I noticed was that they finally made type-ahead searching work right on treeviews. No more "C-f" to search -- now you just start typing in any list or treeview, and you'll get a helpful box showing you what you've typed (a la firefox) and instant selection of your item. Among other things, this makes the much-bemoaned new filechooser much more usable for the keyboard-centric (though C-L is still often faster). The one thing missing from their keyboard search AFAICT is a nice way to search-again (i.e. jump to the next hit) in a list. I instinctively try "C-g" but no luck.

Now there's just one major GTK change I'd like to see implemented soon: selection-via-typing on all drop-down ComboBoxes. I've implemented a hack version of this for my own gtk app because I couldn't stand not having it, but I'd much rather have it built into the toolkit. Everyone I know is used to type-ahead for comboboxes on web forms; I wish they'd make it universal across GTK soon.

At any rate, Ubuntu + GNOME's new release system is making great things happen and happen fast. I imagine a lot of debian users (like me) will make the move soon if they haven't already.

Well, if you think it sucks for GUIs, then don't use it for GUIs.

There are plenty of good GTK bindings for OO languages

such as JDBC drivers, XML parsers, SOAP tools and 3rd party components

Semi-check, built-in, check, and check (including a lot of real winners, particularly including multiple cross-platform GUIs).

(The semi-check is because I'm not 100% certain the python modules match the JDBC completely.)

The only advantage Java offers is when it has an actual library that you can't get in Python (or likely anywhere else); capability for capability the languages and libraries are pretty close to the same. I mean, we have "Web Application Servers" for Python (like Zope), but maybe you absolutely need some Java thing for some other reason. There's no one language that meets all needs. But there's no reason Python can't be used in very large scale projects successfully, as evidenced by the fact that it has been so used.

Personally, I'd much rather use Python for the larger scale projects since for a variety of reasons I think it scales better then Java; Java projects IMHO survive because they get a lot more resources thrown at them, not because the language does very much to hold large projects together. But that's just my opinion.

(Oh, and Jython, though I know it's been mentioned elsewhere.)

Remote Control and Scripting of Gnome Applications with Python. It should also work for KDE and Java apps once they get their act together.

It's here today, and it works. I was at the talk at LCA this year. Write a Python script, add a launcher for it on your panel/desktop, and away you go!

-mike

Is GTK for Win32 actually viable now?

The stable releases (2.0.x/2.2.x) are pretty much usable under win32.

Oh and yeh, I can't stand writing GUIs in C.

You don't have to "write GUIs in C": just use one of the bindings (C++, Python, Perl, ...).

• When you write in Gtk+, you can get an application that runs on all the platforms you listed. My gtk+ newsreader Pan runs on Linux, Windows, and Mac OSX.

• The window manager is orthogonal to the topic of what's important from the software maker's point of view: ICCCM compliance is the only feature any application writer cares about. No application requires a specific WM. To do so would needlessly limit their audience.

• Likewise, you're misinformed about Mono: nobody is telling anyone that they have to port anything to Mono. C# is just another language that Gnome supports. Never in the 4+ years I've worked on Pan has anyone mentioned porting Pan to C#.

• gtk doesn't lack documentation. In fact the documentation team has made leaps and bounds over the last year.

• If you prefer RAD tools, Anjuta and Glade are available.

• Discussing Qt as a `modern C++ based toolkit' and disparaging Gtk+ as lacking a `modern API' is just language bias (and ignores moc's pre-STL cruftiness). If you want to use gtk+ in an OO language, many language bindings are available.

Again, this isn't to take anything away from Qt -- its tools are pretty good, and its documentation is excellent. However, Gtk+ is very good too.

I don't touch C, except when I'm submitting patches to the GNOME libraries. I use PyGTK, the Python binding. James Henstridge and friends have done a bang-up job. GTK+, GLADE, libglade, PyGTK, and PyGNOME are a great set of tools. My biggest concern with GNOME is the apparent lack of a commitment to maintain backwards compatibility. This has hurt Galeon and GnuCash, I think, to say nothing of the time wasted porting other projects from GNOME 1 to GNOME 2. Maybe they'll have this worked out when it's a little more mature.

While I haven't spent as much time with PyQt, it didn't blow me away the way PyGTK did. It uses old-style, rather than new-style, classes. PyKDE is a separate project: while the latest release of PyQt is 3.7, you have to stay at 3.5 if you want to use PyKDE. Finally, the 250-GBP commercial license fee is ridiculous. I guess they have to pay for the Qt commercial license, somehow.

Have you ever installed an ATAPI CD burner?

I did it yesterday. You just plugged it in and it worked (*). No special modules, no kernel recompile, no boot parameters. Apparently, the whole ide-scsi mess isn't necessary anymore. Just plug in and launch xcdroast. Dead simple

However, I didn't know that, and I'm supposed to be an experienced Linux user. I only discovered it because I was in a hurry, and forgot to do the ide-scsi thing before I installed the cd burner. I've guided newbies through the ide-scsi thing countless times, and now I discover I made the whole thing much more complex than it actually was.

So I think an important problem is that many experienced people just don't learn new, easier ways of doing things. After all, they already know how to do it using the old way, why would they look for another way? And because of this they keep propagating overly complex solutions.

Another illustration is installing new fonts. With all the new font infrastructure work, all you need to do to install a new font is to throw it in your fonts folder. That's it. Just like Windows. It's surprising how few people actually know this. (If you don't believe me, here is a screenshot.)

(*) OK, you have to set the master/slave jumper correctly, but there's nothing that Linux can do about that.

Bonobogui is a way to turn CORBA servers (the way GNOME allows different programs to talk to each other) into GTK+ widgets (graphical stuff used mostly in GNOME). I have never actually used any of this stuff, but according to EggToolbar and EggMenu, the stock bonobo stuff doesn't allow for cool stuff that is used by browsers a lot:

• Some desired toolbar layouts are impossible.
• Right aligned items.
• items that expand (such as the location bar in a web browser).

http://developer.gnome.org/

http://www.daa.com.au/~james/pygtk/

http://www.student.oulu.fi/~jlof/gtkglarea/

If you're going to compare APIs you should at least make use of the features of each, and use languages of similar levels. No, ObjC is not a low level language either.

GTK UI construction in C is verbose yeah, but so is anything in C. You can make GTK apps very simply if you use the right bindings and use Glade (equivalent to .nib files), ditto for any part of the GNOME apis. Oh and I'd much rather not use Objective-C for anything, I find it incredibly hard to read, and I know many languages. I'm sure I could learn it if I wanted to, but I don't, language neutral APIs are generally much nicer imho.

Assuming the only GTK code you've seen is the C code (which I agree looks incredibly rowdy) you might want to have a look at the Gtk-Perl or PyGtk. I've used both and they make writing gnome/gtk applications tolerable. Also, learn how to use the Glade feature of Gtk. You design your interface in the Glade wyswyg UI editor, which generates an xml file describing the layout of the interface. You can have any number of scripting languages with Gtk bindings (Perl, Python, Ruby etc) at runtime load up the Glade xml file to build the GUI. Once you get Glade under your belt you'll be surprised how amazingly fast you can bang out workable GUI program.

I am sure that in both cases, that it is possible with either some switch settings or additional step somewhere.

I was wondering if the possibility of having a unified database for the packages might be reasonable, maybe an XML/RDF based database which then both apt-get and RPM can use mutally.

I was wondering if some of the concerns of those that aren't big fans of RPM are to use gnorpm and/or Redhat's Up2date. They seem to have some nice GUI aspects that make installing packages a little easier as well as providing for the ability to identify and install needed dependencies like apt-get does.

Or maybe some other tools like Auto Update or AutoRPM

Also would use of the package transalation tools like alien help in the two working together?

I think one of the concerns over all the recent hits on many of the distributions, which was one of the weaknesses in the Standard Linux projects has been inconsistant packaging. Perhaps, combining the projects may be beneficial to both parties so that other innovations and work can be done elsewhere.

BreezyGuy

I've seen various people say things about the Gimp's interface, like: "I don't like it", or "I'm used to Photoshop, so learning a new interface is a pain". Anyway, this idea bubbled up in my brain as I was walking home yesterday:

One of the projects in the Gnome Software Map is libglade, a library which allows an app to load a user interface definition from Glade (the GTK user interface designer) at runtime, thus enabling user interfaces to be changed and used without a recompile.

My idea was, if the Gimp's interface was designed in Glade, and loaded via libglade, surely it would be possible for people to customise it to their heart's content, and enterprising souls could design and release custom interfaces, eg Photoshop clones, for those who need a tool that "just works" and don't have time to fiddle.

(when I was coding on the Amiga, I originally used an editor called CygnusEd. Then I replace it with one called GoldEd, which had an extremely customisable interface, so I could make all the menus, hotkeys, etc. the same as CygnusEd. This was fantastic, but obviously a lot of work for the programmer - surely something like libglade could allow our major applications such flexibility without demanding too much effort from the developers at all?)

What does anyone think?

Python/Tk (called Tkinter) makes for a nice combination. You get Tk with the benefit of an OO language with real dynamic typing. Unfortunately it's no faster than Tcl/Tk. Here's a nice intro.

If your UI does not need to be crossplatform, pygtk may be a an even better choice. It has more widgets, is fast, and you can also write GNOME apps with the companion pygnome modules. (The pygnome package includes pygtk.)