[Xastir-dev] Topic: Supported Platforms, Xastir-NG

[Kristian Walsh]

Hi,

Quick introduction for the list:  I've done some work on a Search and  
Rescue tool called GAISS (http://www.tssg.org/project/gaiss/?cat=4)  
with John Ronan (EI7IG, lurking on this list).

During development, we had considered xastir , but the need to re- 
project all mapping to UTM was a bit of a headache, so we did our own  
visualisation system.

The Search & Rescue guys liked our software, but in the absence of  
more funding, we can't go ahead on our own. However, I wouldn't like  
to see our experience go to waste. I cannot give code, as the funding  
body retains the rights, but I would be willing to help out.

My comments below:

On 16 Jun 2008, at 18:17, Curt, WE7U wrote:

>
> Here are the tendencies in this thread so far:
>
>
> *) OO Design using UML (Unified Modeling Language), at least to the
>    class and method level.
>
>    Examples of UML tools:  bouml, argouml, eclipse, Oxygen, Dia.
>
>    Tom: Must we all use the same UML tools?

> ---------------------------------------------------------------------
>
> Language choice & supported platforms can wait until the UML design
> well under way, but here are the tendencies along those lines:
>
> *) C++ with STL.  Use only ANSI class libraries (no vendor-specific
>    class libraries).

Perhaps consider some of the Boost C++ libraries (www.boost.org):  
they are cross-platform and well supported.

>
> *) C libraries only where necessary, using C++ wrappers.
>
> *) C++, Python, Java, and Ruby bindings for the client API.
>
> *) Less dependence on external libraries, to control reliability/
>    quality/maintainability.
>
> *) Add a layer between the daemon and the database, to keep as much
>    database-agnostic as possible.
>
> ---------------------------------------------------------------------
>
> Objective-C:
>
> There was one vote for Objective-C, which evidently is also
> supported by GCC but has a lighter footprint than C++ or Java.
> It's supposed to be simpler than C++.  Any opinions on this
> language?
>
ObjC is a simpler language than C++, as it only adds dynamic method  
dispatch to C (if you're familiar with Smalltalk).  The penalty is in  
slower execution speed (method calls aren't just "jump to this  
address", they're "look up this method signature for this object,  
then jump to that address).  ObjectiveC is extremely loosely typed :  
there is only one type of object really, and that's "object" ;-) You  
may like this, or hate it

The language hasn't moved much since the mid 80's.  Apple have  
recently brought along an ObjectiveC 2.0, which adds garbage  
collection to the mix.


> Can we do the same wrapper technique to use C libraries with
> Objective-C?
>
Yes. The Objective-C runtime is the C runtime, with a couple of  
additional runtime functions.  All the things you hate about C are  
still there.

> Would we suffer any portability issues with Objective-C which we
> wouldn't suffer with C++?
C++ is standardised, Objective-C is not.

>
> ---------------------------------------------------------------------
>
> Supported Platforms:
>
> We need to choose our supported platforms, then select portable
> libraries which also play on the same selection of platforms.

We used GTK+ for our UI - it works on MacOS X (on X11) and on Linux.  
We never tried it on Windows.

>
> ---------------------------------------------------------------------
>
> Are there considerations which would limit our portability,
> particularly to embedded Linux devices or even PDA's/Cell-phones?
> How can we avoid these limitations?

I would not try to do a "one size fits all" UI - it will not work  
well on any platform. Decoupling the "engine" from the UI and  
allowing differnt UIs would be a better choice.

>
> -- 
> Curt, WE7U.				archer at eskimo dot com
> http://www.eskimo.com/~archer
>   Lotto:  A tax on people who are bad at math. - unknown
> Windows:  Microsoft's tax on computer illiterates. - WE7U.
> The world DOES revolve around me:  I picked the coordinate system!"
> _______________________________________________
> Xastir-dev mailing list
> Xastir-dev at xastir.org
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir-dev