www.digitalmars.com         C & C++   DMDScript  

c++.wxwindows - General newbie question

reply Mathias <Mathias_member pathlink.com> writes:
Hello all,

sorry for this probably somewhat lame question. I'm pretty new to cross platform
development and would appreciate some general information.
As I understand it, when I use wxWidgets for my programs instead of just using
the native API then they become larger and a bit slower, or I have to distribute
a DLL with my programs.
Other GUI libraries seem to work similar.
A different approach is Java, but Java programs become much slower and depend on
a virtual machine.
Interpreter languages depend on, well, an interpreter, are often slow, and make
it impossible to hide the source code.

My question is:
Is there any alternative library or something else that enables cross platform
development without adding any overhead to the programs that are generated? That
means, I can use a special GUI language (or whatever) and then recompile the
whole thing under Windows, Linux, OS/2, MacOS, etc, and the commands in this GUI
language are *not* mapped to an internal library but to the native API, e.g. the
Win32 GDI API.
I think this would be difficult to achieve, but I can't believe no one ever
tried this!
Does anyone have information about such things?

Thanks,
Mathias
Sep 14 2004
next sibling parent Jerry van Dijk <jerry jvdsys.demon.nl> writes:
Mathias <Mathias_member pathlink.com> writes:


 Is there any alternative library or something else that enables cross platform
 development without adding any overhead to the programs that are generated?

One nice page that might help you answer the question yourself is: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html And GTK+ probably come closest to what you seem to need. Performance has never been a problem for a UI in my experience (except for games, but that's another story. If that is your issue, check out e.g. OpenGL). Anyway, the two ways I know of to create platform independence for a GUI are: 1) Use an embedded interpreter 2) Use a library The first option gives you for example Tcl/Tk. The second option can go two ways: a) Common subset implementation (only implement what all UI's have in common) b) Own GUI implemented on top of native UI API An example of a) is the simple V framework. An example of b) is Gtk. The disadvantage of method b) is of course that the application does not look like a native application on the platform However, most toolkits seem to provide some sort of skins/themes to compensate. Gtk does. Hope this helps. -- -- Jerry van Dijk -- Leiden, Holland
Sep 14 2004
prev sibling next sibling parent reply Arjan Knepper <arjan ask.me> writes:
Mathias wrote:
 Hello all,
 
 As I understand it, when I use wxWidgets for my programs instead of just using
 the native API then they become larger and a bit slower, or I have to
distribute
 a DLL with my programs.

To start with the last statement: no you don't HAVE to distribute a dll, you may choose to link statically the wxWidget libs. And yes using the native api _might_ result in smaller and maybe faster programs but.... not portable. For the execution/running speed, I wouldn't worry, we're talking GUI here so how fast will your program user type on his/her keyboard and how fast will they use the mouse? Speed in rendering: depends largely on the used programming practices and rendering engine. Since wxWindgets is a wrapper around the native API, I wouldn't expect to much rendering speed improvements when using the WIN32 GDI API directly.
 Other GUI libraries seem to work similar.
 A different approach is Java, but Java programs become much slower and depend
on
 a virtual machine.
 Interpreter languages depend on, well, an interpreter, are often slow, and make
 it impossible to hide the source code.
 
 My question is:
 Is there any alternative library or something else that enables cross platform
 development without adding any overhead to the programs that are generated?
That
 means, I can use a special GUI language (or whatever) and then recompile the
 whole thing under Windows, Linux, OS/2, MacOS, etc, and the commands in this
GUI
 language are *not* mapped to an internal library but to the native API, e.g.
the
 Win32 GDI API.

Than the WIN32 GDI API has to be available on the other platforms as well, which isn't. Or the toolkit has to translate the GUI-language at compile time to the native GUI API calls which is (almost) impossible.
 I think this would be difficult to achieve, but I can't believe no one ever
 tried this!
 Does anyone have information about such things?

See: http://www.atai.org/guitool/ Arjan
Sep 14 2004
parent reply Mathias <Mathias_member pathlink.com> writes:
Hello, thanks for your answer.

In article <ci8ok1$q48$1 digitaldaemon.com>, Arjan Knepper says...

Than the WIN32 GDI API has to be available on the other platforms as 
well, which isn't. Or the toolkit has to translate the GUI-language at 
compile time to the native GUI API calls which is (almost) impossible.

I believe that what you say is correct and I really don't plan to start a great discussion here, but could elaborate on this? I admit it might be difficult to translate these calls at compile-time, but why do you think it is "(almost) impossible"? BTW, I'm afraid this might be rather off-topic. If you happen to know a more appropriate forum, newsgroup, or mailing list, I'd be glad if you redirected me. Thanks again, Mathias
Sep 16 2004
parent reply "Roald Ribe" <rr.no spam.teikom.no> writes:
"Mathias" <Mathias_member pathlink.com> wrote in message
news:cic37u$2kdr$1 digitaldaemon.com...
 Hello, thanks for your answer.

 In article <ci8ok1$q48$1 digitaldaemon.com>, Arjan Knepper says...

Than the WIN32 GDI API has to be available on the other platforms as
well, which isn't. Or the toolkit has to translate the GUI-language at
compile time to the native GUI API calls which is (almost) impossible.

I believe that what you say is correct and I really don't plan to start a

 discussion here, but could elaborate on this? I admit it might be

 translate these calls at compile-time, but why do you think it is

 impossible"?
 BTW, I'm afraid this might be rather off-topic. If you happen to know a

 appropriate forum, newsgroup, or mailing list, I'd be glad if you

There is always winelib (winehq.com). A GPL source library that implements the WIN32 API on X windows. And there is wine, that will execute your WIN32 app directly on Linux/BSD. For the best possible portability the best choice is wxWidgets (AFAIK). It contains a lot more than portable GUI, it has: portable i/o, threads, printing, db access +++ Roald
Sep 24 2004
parent Mathias <Mathias_member pathlink.com> writes:
In article <cj138t$1aa$1 digitaldaemon.com>, Roald Ribe says...

There is always winelib (winehq.com). A GPL source library that implements
the WIN32 API on X windows. And there is wine, that will execute your WIN32
app directly on Linux/BSD.

For the best possible portability the best choice is wxWidgets (AFAIK).
It contains a lot more than portable GUI, it has: portable i/o, threads,
printing, db access +++

I think I'm beginning to understand... Speed is not important anyway for a GUI. And the overhead in program (executable) size is not significant I guess. So I'll try wxWidgets. Thanks all, Mathias
Oct 05 2004
prev sibling next sibling parent chris elliott <biol75 york.ac.uk> writes:
Mathias wrote:
 Hello all,
 
 sorry for this probably somewhat lame question. I'm pretty new to cross
platform
 development and would appreciate some general information.
 As I understand it, when I use wxWidgets for my programs instead of just using

that if you are using MS-Windows, Unix or a mac, you can compile the same code but get a native-look and feel
 the native API then they become larger and a bit slower, or I have to
distribute
 a DLL with my programs.

differnce in the feel of the apps, except in the situation where you ahve 4 or so apps using the same DLL, when you get a faster startup. I think speed is only important when you do a calculation or image rendering, for which wxWidgets provide idel events so you don't wreck the user interactuion chris
Sep 15 2004
prev sibling parent reply Steve <Steve_member pathlink.com> writes:
In article <ci7tia$d6n$1 digitaldaemon.com>, Mathias says...

Is there any alternative library or something else that enables cross platform
development without adding any overhead to the programs that are generated? That
means, I can use a special GUI language (or whatever) and then recompile the
whole thing under Windows, Linux, OS/2, MacOS, etc, and the commands in this GUI
language are *not* mapped to an internal library but to the native API, e.g. the
Win32 GDI API.

You can try Trolltech's commercial (and pretty expensive) Qt enviroment for Win32, Unix, Mac, and embedded Linux. From their website http://www.trolltech.com/products/qt/index.html : "(...) Qt applications require no bulky runtime environment to be installed on the target systems, and hence there are no version conflicts to worry about. And on Windows, no X servers are required either. (...) Qt requires no "virtual machines" or emulation layers. It writes directly to low-level graphics functions, just like native apps do. So Qt applications run at native speed."
Nov 10 2004
parent Jan Knepper <jan smartsoft.us> writes:
Before making any statements about QT... Have you tried QT versus wxWidgets?

Jan



Steve wrote:
 In article <ci7tia$d6n$1 digitaldaemon.com>, Mathias says...
 
 
Is there any alternative library or something else that enables cross platform
development without adding any overhead to the programs that are generated? That
means, I can use a special GUI language (or whatever) and then recompile the
whole thing under Windows, Linux, OS/2, MacOS, etc, and the commands in this GUI
language are *not* mapped to an internal library but to the native API, e.g. the
Win32 GDI API.

You can try Trolltech's commercial (and pretty expensive) Qt enviroment for Win32, Unix, Mac, and embedded Linux. From their website http://www.trolltech.com/products/qt/index.html : "(...) Qt applications require no bulky runtime environment to be installed on the target systems, and hence there are no version conflicts to worry about. And on Windows, no X servers are required either. (...) Qt requires no "virtual machines" or emulation layers. It writes directly to low-level graphics functions, just like native apps do. So Qt applications run at native speed."

-- ManiaC++ Jan Knepper But as for me and my household, we shall use Mozilla... www.mozilla.org
Nov 11 2004