which "GUI module" you suggest me to use?

[Samuel]

In the general case, wxWidgets wraps (not emulates) Gtk. I don't believe
that there are any common controls left which are still emulated (maybe
the list control? I'm not sure - I don't follow the bleeding edge of wx
anymore).

See my other response. Also, the fact that Gtk widgets are used does not
necessarily mean that the behavior is the same - you can still do all
kinds of weird stuff by hooking into the callbacks. Some of the
differences to Gtk were probably introduced to wx in order to have more
consistent behavior over different platforms.

wxPython (as opposed to wxWidgets, the C++ core) has a sizeable library
of custom controls as part of its standard lib. Most of these are
owner-drawn for various reasons and often won't appear native (Andrea
Gavin, probably the most prolific custom control author, works primarily
on Windows).

This affects the C++ core as well. aMule (which is written in CPP) is one
particular complex example that exposes many of those problems when used
on Linux.

That stretches the truth rather significantly. While the win32 theme
does use the windows theme apis for drawing, it still has slightly
different colors (especially window backgrounds and menus), and (more
importantly) vastly and notably different behavior.

Well, I have only tried Gaim on windows and could not tell the
difference. But then, I am not a regular Windows user.

Shortcuts are
different, renderings are different, the Gtk drawing model is used
instead of the windows one (leads to quite jarring repainting
differences), different fonts, etc, etc. It looks okay in a screenshot
but is clearly non-native and foreign in use.

Sounds bad. It also sounds much like what I experienced with wx on Linux.

I guess there is no perfect solution, you always have to target one
primary platform. (Well, there's SWT, but the Gtk emulation too has it's
drawbacks...)

-Samuel

 

[Chris Mellon]

That may be true in some cases, but in fact, most widgets show some sort
of difference. Take for example the HPaned - it looks totally different
(the slider is a lot slimmer, plus moving it makes a line appear. The
behavior is different as well).

I'm not familiar with any wxPython control called HPaned. There's a
couple different types of splitter, the Gtk native one is
wxSplitterWindow. The others are owner drawn with better or worse
native appearance. Splitters are one of those things where everyone
writes their own, like web frameworks.

Even simple widgets show differences. Try triple-clicking into entry
boxes, it's different from Gtk.

Text boxes are absolutely native controls under gtk.

Obviously, it does *not* always use Gtk.

It *always* uses Gtk. Some people write or use custom controls, which
may or may not have gtk native analogs. This isn't any different than
using pygtk and writing custom widgets.

 

[Chris Mellon]

See my other response. Also, the fact that Gtk widgets are used does not
necessarily mean that the behavior is the same - you can still do all
kinds of weird stuff by hooking into the callbacks. Some of the
differences to Gtk were probably introduced to wx in order to have more
consistent behavior over different platforms.

This is true and in the specific case of triple click, wx does indeed
report them to the application differently than gtk does. This
doesn't, to my knowledge, interfere with text controls that don't try
to handle the click, but it may result in inconsistent behavior with
an app that adds triple click behavior to it's own text controls.

This affects the C++ core as well. aMule (which is written in CPP) is one
particular complex example that exposes many of those problems when used
on Linux.

the aMule team makes heavy use of their own custom written controls -
issues with it are not necessarily representative of the toolkit. The
C++ core has very few controls which are entirely custom drawn, and
those are generally controls which don't exist in the native platform.

Well, I have only tried Gaim on windows and could not tell the
difference. But then, I am not a regular Windows user.


Sounds bad. It also sounds much like what I experienced with wx on Linux.

I regularly use wxGTK and wxPython under linux with gnome (it's my
sole desktop at home - I only use windows at work). The differences
are orders of magnitude in severity.

One common problem is that people use incorrect (but working on
Windows) code and don't test under linux, it can cause similar issues.
The *toolkit* is very strong on all platforms. Individual apps are
often much less strong, because relatively view developers have access
and motivation to test heavily on all platforms. wx tries to make
correct code work the same on all platforms, but it can't make
incorrect code fail the same way on all platforms.

And, of course, many people simply aren't familiar with or choose not
to use the APIs that wx provides for whatever reason. Custom controls
that don't use native fonts are fairly common, for example, even
though wx provides APIs to retrieve the correct fonts and the use of
them is encouraged - people just hardcode whatever they "know" the
right font is on their native platform.