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


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.

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


The wxWidgets program cals are mostly small wrappers around the API, so 
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.


You can link statically or dynamically, and I'ver never seen any 
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