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

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

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

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

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

"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

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

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."

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