Re: [ooc-compiler] VisualOberon or not VisualOberon?

[Tim T. <ra...@ed...>]

Hallo!

> I certainly will need GUIs, so should I use VisualOberon or another=20
> framework (Glade/Gtk, Qt, ...)?

That depends. If you choose anything other than VisualOberon and want to =

use oo2c you must write the necessray foreign or interface modules. This =

is possible for GTK, since it is C based, but is very difficult for Qt,=20
since it is C++.

GTK is nice to use, but at least the 1.X were not that nice to program.=20
2.x is likely better, but it is also likely that you quickly want to=20
write some OO layer on top of it (like the C++ bindings for GTK), you=20
hide all that lengthy and crytic procedure names. So a lot of effort.

So if you want to use oo2c VO has some initial benefit ;-)

> I know the Oberon look-and-feel from System 3 and I like it. And using =


VisualOberon is themeable. While themability is not perfect it should be =

possible to simulate the look of Oberon System if that is a problem for y=
ou.

> the language Oberon for the GUI would make programming more comfortable=
=20
> using VisualOberon. On the other hand: VO (i) would have to be=20

I personally think that VisualOberon is simple to use if you have=20
understood some basic concepts.

> statically linked to my programs or be installed on the target=20
> platforms, whereas Gtk already might be there. (ii) More people are=20

Yes. VisualOberon is still in development phase and API changes are=20
likely. So eitehr you build versioned packages are better use a static=20
library (not that the binary sice can be drastically reduced if you=20
switch of run time checks). Versioning of GTK is definitely better.

> familiar with C and Gtk. And finally: (iii) for Gtk an interface builde=
r=20

It is your program. Why should you bother what other people like?

> is available (Glade). So I tend towards the latter solution.

You do not need an interface builder for VisualOberon. In fact IMHO=20
interface builder stoped progress of GUI technics. You should try=20
VisualOberon to know what I mean. VisualOberon also supports XML=20
description files (VGD) which seems to be the future (Avalon ;-)). And=20
if you like you can still write a GUI builder for VO ;-)

You havn't mention the real problems of developing with VisualOberon.=20
oo2c and VisualOberon are both a one man show. If one of them stops=20
their work you are in problems if you want bugfixes or new features -=20
unless you take over development.

VisualOberon is not that feature rich as GTK or QT are. The reason for=20
this is not bad design but lack of help. It is likely that if Microsoft=20
or Apple release their next generation OS and Gnome and KDE further=20
develop VisualOberon will fall back since I cannot compete with hundreds =

of developers. Interfacing to third party library is a help but not=20
everything is easy to integration (try write a HTML control for VO based =

on the Mozilla engine!). That still means that you can program nice and=20
smart GUIs and if you are missing a control that should be easy to add=20
but you won't get transparency, animations, HTML stuff, Richtext=20
control, OO database, CORBA, SOAP, webservices or .NET support. But that =

is a problem that otehr plattform independent GUI libraries share, it is =

just that they have more developers to compensate.

> I am curious about your ideas out there, and especially about the=20
> objective opinion of Tim ;-)

I tried by best :-)

--=20
Gru=DF...
        Tim.