OpenEV

On Wed, Jun 30, 2004 at 05:15:23AM -0700, Yao Heling wrote:
> I noticed there was some discussion last year about porting openev to
> gtk2, and I wonder what the openev devs think of this issue now as
> gtk2 has stabilized. I noticed there are a few people interested in
> such a port, and  I'm willing to get involved in the process if I can, 
> 
> By the way, if gtkmm is used for the porting, is there any gotchas?

There was an idea (and that idea is still here) to port the OpenEV to
GTK2, but it was postponed, because of non-trivial nature. I don't know
whether sombody tries to build OpenEV (probably Atlantis developers?)
with GTK2, but it should be generally desirable.

If you want to make a try I can recommend to start with porting the core
C library and pass to Python stuff as soon as gvtest application will be
functional. Many Python modules are not tied to GTK1 and should be higly
portable.

						Andrey

-- 
Andrey V. Kiselev
Home phone:  +7 812 5274898  ICQ# 26871517

Yao Heling wrote:
> Hi,
> 
> I noticed there was some discussion last year about
> porting openev to gtk2, and I wonder what the openev
> devs think of this issue now as gtk2 has stabilized. I
> noticed there are a few people interested in such a
> port, and  I'm willing to get involved in the process
> if I can, 
> 
> By the way, if gtkmm is used for the porting, is there
> any gotchas?

Yao,

I think Andrey already gave a primary answer to this. I would add a few
notes.
  o GTK 1.x is stable and works fine now.  It will likely "do" for OpenEV for
    a while.
  o GTK 2.x is much more attractive and making progress on many fronts.  For
    these reasons I would like to move to it at some point.  But it is a
    substantial effort.
  o I doubt we would use gtkmm (a C++ interface to GTK2).  OpenEV's core
    is C currently and I can't see any compelling reason to change that
    just now.

Is GTK 2 well supported on win32?  If not, that will be a major reason to hold
off.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

Hi,

On Tue, 06 Jul 2004 17:32:35 -0400, Frank Warmerdam <warmerdam@...> wrote:

>  o GTK 1.x is stable and works fine now.  It will likely "do" for OpenEV for
>    a while.

It does not work that well on win32... all OpenEV crashes, mishaps and strange behaviors I
experience are all related to GTK. And it's ugly :)

>Is GTK 2 well supported on win32?  If not, that will be a major reason to hold off.

Maybe this would shed some light on the issue:
http://members.lycos.co.uk/alexv6/

And I am not sure if this can be useful:

http://www.ethereal.com/distribution/win32/development/gtk2/


--
Mario B.
Mes images Landsat:
http://pages.infinit.net/starged/landsat/index.html

On Tue, 2004-07-06 at 15:32, Frank Warmerdam wrote:
> Is GTK 2 well supported on win32?  If not, that will be a major reason to hold
> off.

GTK, GUI Toolkits and Cross Platform Portability


Just to throw in my two cents, I've been working on a piece of image
analysis software for the last six months or so that uses GDAL. We
wanted a cross-platform (linux and windows) GUI and after considerable
thought we went with GTKmm/GTK 2. As a C++ programmer, I never liked
GTK's pseudo-object system - it seems like a crude attempt to graft C++
features onto C, and I wanted a proper OO language interface. The GTKmm
interface has an extremely nice and modern design - it uses namespaces,
standard strings and is beautifully crafted. The  GTKmm documentation is
also top-notch for the most part as well, though you have to use the GTK
docs for a few basics. A big disadvantage of GTKmm is that being a C++
library, binary compatibility between compilers and platforms is
non-existent. In addition, it's yet another dependency you have to worry
about, and another layer between your app and the OS. So if your major
concern is binary portability and reducing dependencies and you're not
too put off by GTK's syntax, then GTK 2 is fine, I guess...

Support on windows seems OK. GTK 2 now has themes which give you a
better windows look and feel than before, but it's far from perfect. In
particular the file chooser is completely non-standard and feels
prehistoric in comparison with the very nice standard windows file
chooser. After complaints from our customers we now start up a win32
file chooser directly on windows, but it doesn't interact perfectly with
the rest of the system...

Reliability also seems pretty good, on the whole, though you can't help
feeling that GTK is a very heavy extra layer between your app and the
windows calls. It consists of a vast number of libraries and adds
considerable megabytes to any windows installers you make.

An additional problem for GTKmm is that visual studio support for it is
minimal. If you use GTKmm, you're pretty much forced into using mingw,
which doesn't work nearly as well on windows as gcc does on unix. In
particular, debugging is pretty broken.

In summary, we're using GTK(mm) 2 on windows and it's getting the job
done. In retrospect however, I would probably have gone with a 
different toolkit, perhaps wxWidgets (formerly wxWindows).

FWIW, the other toolkits we considered were:

- wxWidgets: It changed its name earlier this year from wxWindows - see
the web page for details. Feels substantially lighter than GTK while
providing a nice C++ interface (not quite as nice as GTKmm though).
Tends to give much more native look and feel than GTK on windows. In
particular the file choosers work! You get the feeling that wxWidgets
people are serious about windows support, while for GTK people it's a
sideline. Doesn't have quite all the bells and whistles of GTK.

- Qt: Very well-regarded cross-platform C++ system offering solid
customer support in return for a fee (about $1500 per developer per
platform). There's also a GPL version without the support, but it only
runs on linux. Some people complain that it's a bit bloated and that the
C++ style is pretty dated. We rejected it because (a) we're cheapskates,
and (b) it didn't seem to offer that much over wxWidgets or GTKmm.

- Java: I've used Java quite a lot for cross platform GUIs, but they
never seem to look quite right on either windows or linux. It has it's
own L&F that you either love or hate. Plus I've had numerous problems
with incompatibilities between different JVMs. Ironically enough most of
these incompatibility problems occurred on Solaris machines...

- C#: Microsoft's java clone. The look and feel should be right on
windows at least, and it's undoubtedly a very nice language to code in,
that links well with other visual studio .NET languages. Portability to
linux is still pretty minimal though - I haven't heard much from Mono
for a while and it seems a bit optimistic to imagine that they can keep
up with MS's ever-changing target.


There's a reasonable survey of various toolkit options at:

http://freshmeat.net/articles/view/928

I disagree with some of the opinions, but it discusses a few other
toolkits I haven't mentioned.

Cheers,

Sy

Hi,

On Tue, 06 Jul 2004 17:32:38 -0600, Simon Perkins <sy@...> wrote:

>- wxWidgets: It changed its name earlier this year from wxWindows - see
>the web page for details. Feels substantially lighter than GTK while
>providing a nice C++ interface (not quite as nice as GTKmm though).
>Tends to give much more native look and feel than GTK on windows. In
>particular the file choosers work! You get the feeling that wxWidgets
>people are serious about windows support, while for GTK people it's a
>sideline. Doesn't have quite all the bells and whistles of GTK.

I would like a wxWidgets OpenEV, anybody's interested? I could take care of the wxPython part...
--
Mario B.