Does TiLP support GTK+ 2.8 yet?

TiLP compiles and runs just fine with GTK+ 2.8, and the binaries compiled with 2.6 also run fine with 2.8. The reason we don't use 2.8 only is that GTK+ 2.8 doesn't work on Windows 9x/Me nor NT4.

Next time use Qt or Tk.

Better yet, just use the native Win95 API like normal people, since cross-platform toolkits are fail on Windows 9x and the hardware it runs on.

Hum, Romain Liévin will _not_ use QT (because of the portability if I remember).

Using QT is still a nice dream :)

I have chosen GTK+ because it was free when released. Qt weren't.
For now, Qt4 is available but I can't rewrite all of the code to switch on QT4: too much work !

I would have preferred Qt (I'm a KDE user) but technical choices are always heavy !

GTK+ 2.6 definitely DOES work on Window$ 9x/Me.

As for Tk, that's not that bright an idea. The GDB-enabled TiEmu 3 builds actually do use Tk for the Insight debugger (http://sources.redhat.com/insight/). But you'll notice that Insight's Tk windows look even less like native windows than the GTK+ ones, that Tk uses Tcl, an interpreted language, making it slower than GTK+ and that Tk is really an obsolescent toolkit these days. So I really don't see what we'd have to gain by using it over GTK+ (other than a unified toolkit in the GDB-enabled TiEmu 3).

Qt 4 may be up for discussion now, but when TiEmu was written, there was no GPLed Qt for Window$. Now there's still the issue of Qt 4 not blending well into a Qt-3-based KDE 3 environment, this will change with KDE 4, but that may well be a year from now.

As for native Win32 windows/dialogs:
* Window$ is not the only OS in the world.
* Plain Win32 is a PITA to develop for.
* MFC is a proprietary M$VC-only technology (you can't even compile them with other Window$ compilers) and is also a PITA (though less than bare Win32).
In one word: no. Where Win32 offers ready-made dialogs such as file dialogs or message boxes, using them can be considered, and in fact we already do for the file dialogs (mainly because I hate the GTK+ ones; I've also implemented using the KDE file dialogs on *nix).

He wanted to do a write-once, run anywhere application. While I run KDE and GTK apps don't look quite as nice in KDE as they do in a GTK-based DE like Gnome or XFCE, they still compile, work, and run well. Actually, GTK on Windows NT looks more like its native Gnome/XFCE implementation than it does in KDE.

If he wrote in the Win95 API, then it would force two rewrites: one for WinNT and another for Linux. There are roughly an order of magnitude more people that run Linux than run Windows 95, so I think that no compatibility with the 3.x% of users who run Linux and a crapshoot with the ~80% that run NT, 2K, or XP is a losing proposition for an OS that is 12 years outdated and has something around 1/10 of 1% marketshare.

You want to use a common theme for GTK+ and KDE. Bluecurve works well here. Or try the GTK-Qt-Engine.

The compile went pretty smoothly - I'm on Ubuntu Breezy Badger, if you care :)

Unfortunately, many of the features didn't work for me. In fact, the most I could do was get it to send a program. Getting a dirlist, sending apps, etc didn't work. I'll file that in a bug report. But, I can say for sure, sending that one program was _really_ fast :)