[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Help: How to do a standalone app ?
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-03-25 23:40:45
[Download RAW message or body]

On Sunday 25 March 2001 13:03, JP wrote:
> Hello, everybody.
>
> I'm sorry if my question was already answered. I did a fair amount of
> searching and found nothing. If it is, somebody please tell me simply so
> and I will dig deeper.
>
> My question is as follows. I'm now trying to port a commercial application
> of mine to Linux (Itīs MSWindows now). I have been doing research of
> development possibilities, and I will be using KDevelop. I would like my
> application to run without a dependence on the Windowing system the user
> will have. That is, to work from KDE, Gnome, or even as standalone X window
> if called from a console. Is that possible ? Is that automatic, and I a
> moron for asking it? Which kind of pitfalls should I avoid during
> development? I havent coded a line yet, am deciding things like the kind of
> toolkit classes and which database to use and things like that. I have
> already developed for X, but in a closed enviroment (HP-UX) so that problem
> didn't arise.
>
> If anybody can help me, or redirect to good resources, or anything, I would
> be very grateful.

I think you can follow a few approaches depending on the architecture of your 
code and the requirements you want. If you really don't want to use any 
toolkit you'll have to use a multi-tiered design model that has all the GUI 
and I/O related stuff that _might_ be platform or toolkit dependent in 
separate units that all derive from the same common set of base classes. 
There are some alternatives to this, but they mostly end up with a similar 
result.

Another option might be to use e.g. Qt for most of the code, so that at least 
the signal/slot event model is available in all of your code and link 
statically against Qt so that the end user doesn't need it. Disadvantage is 
the big size of executables as opposed to dynamic loading. I'm not sure if 
dynamic and static loading of the same library can be mixed. If this is the 
case you can put the GUI stuff (that isn't always used and can have a few 
more dependencies) using a dynamically loaded Qt. This way only the most 
basic Qt parts are used in the common part to keep file size down. Not sure 
if that's possible though.

And lastly you can ask your users to install Qt and use a it freely around 
your code.

In either case you have to separate the GUI part here, because you also want 
to support the console. It is no problem however to use the non-visual parts 
of Qt if there is no X, if you take the proper precautions.

Using all of KDE might not be a good idea for the non-GUI part of you app. I 
don't know what the overhead for that is when you run from the console. I 
guess you'll have to test for that.

Regards,

Martijn
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]