Re: Static linking in GTK Windows



...(some list members) wrote:
Does the above mean that there is no practical way to
> distribute a single [GTK-based] .exe file and expect it
> to run on the user's computer?
... That is correct...
...
In my experience most Windows users are becoming very
> reluctant to "install" a test/demo...
...
Most Windows users are over-eager to install software...

> You are absolutely right when it comes to novices [but]
> our target audience are experienced computer users,...
> ...

Thank you all for the comments. I believe now that GTK
is simply not the right tool for the job. Let me spell
out in more detail what we have and want to do; there might,
or (more likely) might not be any way to achieve this.
Comments, either on or off-list are welcome.

We have a rather large Win32 application, with some
fancy internal computations and some 3rd party format
parsing (our bread and butter), in clean, cross-platform
C code and with such minimal GUI as required to 'drive' it
(file selections, description entry dialogs, canvas windows
with visualization of some vector diagrams - pretty simple
as far as modern GUI's are concerned).

The application can be operated in "demo" mode, but
we simply can not convince enough prospects to 'install'
(enough on that has been said) and give it a try. We
are therefore rewriting parts of it as a test/demo version,
so that it is a single .exe file. This is a *given*
(i.e., no folders, no 'zipped archive' and definitely *not*
something that requires 'installation'). We know we can do
that for Win32 easily (has been done before) and that is
where most of our prospects are (at present); however, we
would like to leverage this work and have the same test/demo
code base that can be compiled for Linux; also resulting in
a single executable file. We realize the difficulties
involved in multi-platform GUI, but, as mentioned, our
requirements in that department are probably as simple as
they get.

Some further restrictions and relaxations:

All our code is C; this project is not considered
sufficient reason to move any of our code-base to C++.

Win32 version must 'feel native', Linux version need not.

Size of the resulting executable(s) is of little consequence.

GUI/graphical 'performance' is also of little consequence.

In conclusion, if no ready solution is at hand, we will
build Win32 version only, but will attempt to abstract GUI
calls with our own 'operator interface layer', with a view
of (later?) constructing and adding other platform-specific
layers. Is there a better way?

Roger






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]