ooc-compiler

[ooc-compiler] VisualOberon or not VisualOberon?

[Frank H. <fh...@ph...>]

I am starting to use oo2c on Win32/MinGW.

Why not POW? Because IMHO oo2c is (i) more portable, because it (ii) 
offers more functionality (libraries) and it (iii) is easier to use in a 
multilingual project (use of library and program source code written in C).

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

I know the Oberon look-and-feel from System 3 and I like it. And using 
the language Oberon for the GUI would make programming more comfortable 
using VisualOberon. On the other hand: VO (i) would have to be 
statically linked to my programs or be installed on the target 
platforms, whereas Gtk already might be there. (ii) More people are 
familiar with C and Gtk. And finally: (iii) for Gtk an interface builder 
is available (Glade). So I tend towards the latter solution.

I am curious about your ideas out there, and especially about the 
objective opinion of Tim ;-)
-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA
Florianopolis, SC		
88030-000
Brasil

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

[Marco O. <Mar...@we...>]

Am Mittwoch, 26. Mai 2004 18:10 schrieb Frank Hrebabetzky:
> I am starting to use oo2c on Win32/MinGW.
>
> Why not POW? Because IMHO oo2c is (i) more portable, because it (ii)
> offers more functionality (libraries) and it (iii) is easier to use in a
> multilingual project (use of library and program source code written in C).
>
> I certainly will need GUIs, so should I use VisualOberon or another
> framework (Glade/Gtk, Qt, ...)?
>
> I know the Oberon look-and-feel from System 3 and I like it. And using
> the language Oberon for the GUI would make programming more comfortable
> using VisualOberon. On the other hand: VO (i) would have to be
> statically linked to my programs or be installed on the target
> platforms, whereas Gtk already might be there. (ii) More people are
> familiar with C and Gtk. And finally: (iii) for Gtk an interface builder
> is available (Glade). So I tend towards the latter solution.

It takes a some time to learn how to use VisualOberon. The
userinterfaces generated with VisualOberon are different from those
of the Oberon System. I think there are only a few minor points in
the interface, that may cause dissatisfaction.

>
> I am curious about your ideas out there, and especially about the
> objective opinion of Tim ;-)
> -----------------------------------------------------------
> Frank Hrebabetzky		Tel.:  +55/48/239-2258
> Photonita Ltda			Fax:   +55/48/239-2200
> Parque Tec. Alfa - Ed. CELTA
> Florianopolis, SC
> 88030-000
> Brasil
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler

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.

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

[Frank H. <fh...@ph...>]

Thanks for your detailed answer, Tim.

The point which let me think most, is about the size of the development 
groups. I knew that they are small, but I didn't expect thus few people 
in the case of oo2c.

The language decision is a hard one, once you are addicted to elegance 
(which according to Saint Exupery is reached not when there remains 
nothing to be added, but when there remains nothing to be left out), you 
have found it, and the tool for writing executables for the two 
dominating OSs worldwide depends on a single man.

With respect to GUI building, I'll try to postpone the decision as much 
as possible, following the MVC (model-viewer-controller) paradigm as 
long as possible, using the following strategy: writing programs which 
allow full control through command line parameters/options, compile them 
into an executables, and call them later from the GUI. It may still take 
some time, but you made me curious about VO, so I'll have a look at it.

-----------------------------------------------------------
Frank Hrebabetzky		Tel.:  +55/48/239-2258
Photonita Ltda			Fax:   +55/48/239-2200
Parque Tec. Alfa - Ed. CELTA
Florianopolis, SC
88030-000
Brasil