GWindows and David Botton

GWindows and David Botton

[Fionn mac Cuimhaill]

Has anyone been able to contact David Botton? I need to make a number
of additions to GWindows, which I use at work. He seems to have little
or no time for it at present, and I have both the time and the
necessity to make improvements. I would prefer not to produce a
different fork of GWindows without asking him about his opinions, as I
feel that it would be a basic courtesy to get his blessings on the
project, but I have received no answer to the E-mail that I sent to
him, and I can't tell if he just has no time for even e-mail, or if an
overzealous spam filter has blocked communication with him.

I need to make extensive additions to printing support, which is at
present a fairly thin binding to the Windows printing API.

I also need to make additions to the support for databases.

The  Gwindows/GNATCOM mailing list seems to be defunct, and I would
also like to find a way to organize a replacement for it.

Re: GWindows and David Botton

[stephane richard]

"Fionn mac Cuimhaill" <invisible@hiding.from.spam> wrote in message 
news:pe94l0ln3ku677u8bu9f3r9fvm2ab63v5m@4ax.com...
> Has anyone been able to contact David Botton? I need to make a number
> of additions to GWindows, which I use at work. He seems to have little
> or no time for it at present, and I have both the time and the
> necessity to make improvements. I would prefer not to produce a
> different fork of GWindows without asking him about his opinions, as I
> feel that it would be a basic courtesy to get his blessings on the
> project, but I have received no answer to the E-mail that I sent to
> him, and I can't tell if he just has no time for even e-mail, or if an
> overzealous spam filter has blocked communication with him.
>
> I need to make extensive additions to printing support, which is at
> present a fairly thin binding to the Windows printing API.
>
> I also need to make additions to the support for databases.
>
> The  Gwindows/GNATCOM mailing list seems to be defunct, and I would
> also like to find a way to organize a replacement for it.

Hi Fionn,

I think the best thing to do for now is like konad did (in another thread on
comp.lang.ada) and they host their extension to GWindows themselves at least
until David eventually does reply. If you can't host it yourself, I'd be
happy to host your modifications for you on my website
(http://www.adaworld.com) is my website and I have plenty of space..

I'm sure many developers could and would benefit from your modifications so
I would gladly accept to host them for you.

I'm also trying to get in touch with David myself for another GWindows
related issue (the one with Konad in which a possible merger of their
modification into the official GWindows release if possible and all hosting
on Ada World).. Perhaps a merger of all three could be possible?

Stephane Richard
"Ada World" webmaster
http://www.adaworld.com

Re: GWindows and David Botton

[Stephen Leake]

Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:

> <snip GWindows stuff>
> 
> The  Gwindows/GNATCOM mailing list seems to be defunct, and I would
> also like to find a way to organize a replacement for it.

I suggest you use this newsgroup (comp.lang.ada), until it becomes
clear that you need another forum. I, for one, would like to hear if
Gwindows becomes a better supported and more widely used project.

I'm considering giving up on GtkAda for Windows development, and
resurrecting Windex (long story, for another thread :). But I would
consider joining an open Gwindows project, instead. I always thought
Windex and Gwindows should be merged.

-- 
-- Stephe

Re: GWindows and David Botton

[Stephen Leake]

"stephane richard" <stephane.richard@verizon.net> writes:

> I think the best thing to do for now is like konad did (in another thread on
> comp.lang.ada) and they host their extension to GWindows themselves at least
> until David eventually does reply. If you can't host it yourself, I'd be
> happy to host your modifications for you on my website
> (http://www.adaworld.com) is my website and I have plenty of space..

With all due respect, Stephane, I would suggest hosting a new Gwindows
project on Sourceforge, instead. It's entirely possible you will
suffer the same fate as David Botton (I hope he's moved on to
something he's happy with). Sourceforge is supported by a large
organization with what appears to be a solid business plan, so it's a
better choice for a joint project that we want to be around for a
while.

I used to recommend Savannah, supported by the Gnu Project; Grace was
there. But they took a _long_ time to recover from a hacker attack;
they clearly devote their main effort to the Gnu Project itself, and
don't really have the resources for us casual users.

-- 
-- Stephe

Re: GWindows and David Botton

[stephane richard]

I understand Stephen, and for that statement alone, I'd back your choice of 
hosting at sourceforge. :-)

Of course I don't plan on suffering the same faith ;-).  you don't plan for 
that.  :-)


"Stephen Leake" <stephen_leake@acm.org> wrote in message 
news:mailman.84.1095988127.390.comp.lang.ada@ada-france.org...
> "stephane richard" <stephane.richard@verizon.net> writes:
>
>> I think the best thing to do for now is like konad did (in another thread 
>> on
>> comp.lang.ada) and they host their extension to GWindows themselves at 
>> least
>> until David eventually does reply. If you can't host it yourself, I'd be
>> happy to host your modifications for you on my website
>> (http://www.adaworld.com) is my website and I have plenty of space..
>
> With all due respect, Stephane, I would suggest hosting a new Gwindows
> project on Sourceforge, instead. It's entirely possible you will
> suffer the same fate as David Botton (I hope he's moved on to
> something he's happy with). Sourceforge is supported by a large
> organization with what appears to be a solid business plan, so it's a
> better choice for a joint project that we want to be around for a
> while.
>
> I used to recommend Savannah, supported by the Gnu Project; Grace was
> there. But they took a _long_ time to recover from a hacker attack;
> they clearly devote their main effort to the Gnu Project itself, and
> don't really have the resources for us casual users.
>
> -- 
> -- Stephe
> 

Re: GWindows and David Botton

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.83.1095986128.390.comp.lang.ada@ada-france.org...
...
> I'm considering giving up on GtkAda for Windows development, and
> resurrecting Windex (long story, for another thread :). But I would
> consider joining an open Gwindows project, instead. I always thought
> Windex and Gwindows should be merged.

Another alternative (if you're starting over) is to work from the
Introductory version of Claw, which is also GMGPL. (I've got to find the
time to update the distribution to reflect that.) It's of course still
supported and actively worked on (not as much as I'd like, though). And Claw
works with a number of Ada compilers; you're not tied to GNAT when you use
it.

If there was sufficient demand, I could probably be talked into making the
rest of the Claw Binding (not the GUI Builder -- gotta keep something back!)
GMGPL. Our intent always was that the binding would be available to the
public once it stabilized enough, and I think we've reached that point. But
I'd like to see some interest (particularly in extending it) before going
through the hastle.

                           Randy.

Re: GWindows and David Botton

[Martin Dowie]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:5uKdnY_3FYH0C87cRVn-> If there was sufficient demand, I could probably 
be talked into making the
> rest of the Claw Binding (not the GUI Builder -- gotta keep something 
> back!)
> GMGPL. Our intent always was that the binding would be available to the
> public once it stabilized enough, and I think we've reached that point. 
> But
> I'd like to see some interest (particularly in extending it) before going
> through the hastle.

I've got a Claw Spashscreen extension if you want! (Thanks for the pointers 
;-)

Re: GWindows and David Botton

[Fionn mac Cuimhaill]

On 23 Sep 2004 20:35:20 -0400, Stephen Leake <stephen_leake@acm.org>
wrote:

>Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>
>> <snip GWindows stuff>
>> 
>> The  Gwindows/GNATCOM mailing list seems to be defunct, and I would
>> also like to find a way to organize a replacement for it.
>
>I suggest you use this newsgroup (comp.lang.ada), until it becomes
>clear that you need another forum. I, for one, would like to hear if
>Gwindows becomes a better supported and more widely used project.
>
>I'm considering giving up on GtkAda for Windows development, and
>resurrecting Windex (long story, for another thread :). But I would
>consider joining an open Gwindows project, instead. I always thought
>Windex and Gwindows should be merged.

OK, that sounds fine to me -  I will go with comp.lang.ada as a
communication medium  I have neve done anything with Sourceforge other
than download software from it. Does anyone here who might want to
work on GWindows have any experience with it? In any case, I will
investigate Sourceforge myself and see what it takes to start a new
project there.

And to get started, I would like to start laying out a roadmap of
things that need to get done.  I can think of several areas that can
stand some more work.

1. Documentation. The existing tutorial intro is a good start, but it
needs much work, as do the associated tutorial examples. For example,
there is no section in the tutorial intro about the use of radio
buttons, and there is no corresponding example program. 

Some of the examples show several variations of ways to do things,
which might be best broken up into several independent example
programs. The numbering scheme for tutorial programs needs to be
changed so that new ones can be added without renumbering all of the
later ones.

A reference manual is needed.

Documentation should be available in some form other than Word, as not
everybody has or likes it. Anybody can get a free Adobe pdf reader,
and I can easily create documents in that form. (I actually like
WordPerfect, but few use it nowadays, although it can easily produce
both pdf and html outputs.)

2. Bugs need to be identified and fixed. I hereby call for bug
reports, so that we can look to see what needs to be done.

3. Deficiencies in existing areas need to be addressed. An example
here is edit boxes. There seems to be no general way to capture
character entered into an edit box and do special handling for things
like carriage returns. In general, if Visual Basic can do something,
GWindows should be able to do the same thing.

4. Expansion areas need to be identified. Printing is important for
me. I want to do printing additions in two stages. The first level
should bring printing support up to a rough equivalent of what can be
done with Visual Basic 6, but done in a more coherent Ada way.
The second level needs to add some kind of higher-level document
abstraction. I have in mind something like the qPrinter package for
Visual Basic 6. (Google for qPrinter and you will find it
immediately.)

The existing thin binding to the Windows printing API should not be
neglected - various API functions are missing and should be added.

5. Various extensions need to be done to character string handling.
Gwindows tries to hide the difference between  character
representation among the various versions of Windows by defining a
GString to be composed of either ordinary or wide characters as
needed, and likewise tries to hide the differences between various
Windows API procedures and functions that use string arguments. This
hiding philosophy in not completely implemented and  I still need to
use a variety of Ada system packages that have both ordinary and
wide-character versions. (Typically the wide versions, as I do all of
my development on Windows 2K and XP)


I'm going to need help; I am far from being the best Ada programmer in
the world and I know little about low-level Windows API programming.
If all goes well, both of those situations will change for the better
as this project develops.

Re: GWindows and David Botton

[stephane richard]

>If there was sufficient demand, I could probably be talked into making the
>est of the Claw Binding (not the GUI Builder -- gotta keep something back!)
>GMGPL.

Well here's my demand ;-). 

Re: GWindows and David Botton

[Matthew Heaney]

You could also try tigris.org.  That's where Charles and the AI-302
reference implemention are hosted.

http://charles.tigris.org/



"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.84.1095988127.390.comp.lang.ada@ada-france.org...
> "stephane richard" <stephane.richard@verizon.net> writes:
>
> > I think the best thing to do for now is like konad did (in another
thread on
> > comp.lang.ada) and they host their extension to GWindows themselves at
least
> > until David eventually does reply. If you can't host it yourself, I'd be
> > happy to host your modifications for you on my website
> > (http://www.adaworld.com) is my website and I have plenty of space..
>
> With all due respect, Stephane, I would suggest hosting a new Gwindows
> project on Sourceforge, instead. It's entirely possible you will
> suffer the same fate as David Botton (I hope he's moved on to
> something he's happy with). Sourceforge is supported by a large
> organization with what appears to be a solid business plan, so it's a
> better choice for a joint project that we want to be around for a
> while.
>
> I used to recommend Savannah, supported by the Gnu Project; Grace was
> there. But they took a _long_ time to recover from a hacker attack;
> they clearly devote their main effort to the Gnu Project itself, and
> don't really have the resources for us casual users.
>
> -- 
> -- Stephe
>

Re: GWindows and David Botton

[Cesar Rabak]

Randy Brukardt escreveu:
> "Stephen Leake" <stephen_leake@acm.org> wrote in message
> news:mailman.83.1095986128.390.comp.lang.ada@ada-france.org...
> ...
> 
>>I'm considering giving up on GtkAda for Windows development, and
>>resurrecting Windex (long story, for another thread :). But I would
>>consider joining an open Gwindows project, instead. I always thought
>>Windex and Gwindows should be merged.
> 
> 
> Another alternative (if you're starting over) is to work from the
> Introductory version of Claw, which is also GMGPL. (I've got to find the
> time to update the distribution to reflect that.) It's of course still
> supported and actively worked on (not as much as I'd like, though). And Claw
> works with a number of Ada compilers; you're not tied to GNAT when you use
> it.
> 
> If there was sufficient demand, I could probably be talked into making the
> rest of the Claw Binding (not the GUI Builder -- gotta keep something back!)

Could't the GUI Builder be integrated with GPS?

--
Cesar Rabak

Re: GWindows and David Botton

[Pascal Obry]

Stephen Leake <stephen_leake@acm.org> writes:

> I'm considering giving up on GtkAda for Windows development, and

Well that's not the moment to give up :) Gtk+ on Windows is maturing quickly
and the 2.4.7 version is quite better than previous ones. Note also that the
Gtk+Wimp (Native Windows look&feel) is now part of the Gtk+ project.

Will this makes you stay on the GtkAda side ?

What I like in Ada is that the very same program can be compiled and run on
different OS. So GtkAda seems very important to me!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GWindows and David Botton

[Marius Amado Alves]

> What I like in Ada is that the very same program can be compiled and run on
> different OS.

It seems I always do web systems these days I don't need a GUI library 
much. But sometimes I do. Last time I used JEWL. Please guide me here. I 
seem to remember GtkAda as a binding to a C++ library and have way too 
much unecessary stuff like string functions, an interpreter, all that 
Tcl bagage. In the landscape I see also Glade, GWindows, Claw, Windex. 
The different OSes of GtkAda are just Linux and Windows right? GNAT has 
a lot more. Isn't there a GNAT-related GUI library? Glade?

I've sensed the same sort of doubts in others people and even in other 
fora. Maybe we could build a feature table of GUI libraries for Ada to 
help people chose, if that is not too politically incorrect. I'll kick 
off with what I seem to know, please correct and add.

Library   Level  Sublang  License  OSes       Other features
------------------------------------------------------------
Claw      Full
Glade     High            free
GtkAda    Full   C++      free     Win,Linux
GWindows                  free
JEWL      High            free     Win
Windex
Win32     Low             free     Win
------------------------------------------------------------

Thanks a lot.

Re: GWindows and David Botton

[tmoran]

> Library   Level  Sublang  License  OSes       Other features
How about adding a column "Support".

String handling and character encodings

[Björn Persson]

Fionn mac Cuimhaill wrote:

> 5. Various extensions need to be done to character string handling.
> Gwindows tries to hide the difference between  character
> representation among the various versions of Windows by defining a
> GString to be composed of either ordinary or wide characters as
> needed, and likewise tries to hide the differences between various
> Windows API procedures and functions that use string arguments. This
> hiding philosophy in not completely implemented and  I still need to
> use a variety of Ada system packages that have both ordinary and
> wide-character versions. (Typically the wide versions, as I do all of
> my development on Windows 2K and XP)

If you're planning big extensions to the string handling, you may want 
to have a look at how I have tried to solve the character encoding 
problem in my EAstrings library, which is part of AdaCL. EAstrings keeps 
track of how each string is encoded and transcodes automatically when 
necessary. (The strings are "encoding-aware".) EAstrings doesn't just 
hide the difference between String and Wide_String. It handles all the 
encodings that the operating system knows about.

You can see the code in its current state at 
http://cvs.sourceforge.net/viewcvs.py/adacl/adacl/Include/ (the 
adacl-eastrings* files). It works on Gnu-based systems (and maybe some 
other unixoids if they have the Iconv functions). A Windows port is on 
the to-do list. (Speaking of which, I could use some help from a Windows 
programmer.)

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

GTK

[Björn Persson]

Marius Amado Alves wrote:

> GtkAda    Full   C++      free     Win,Linux

I seem to recall that GTK is written in C, not ++, and I'd be surprised 
if it doesn't work on at least the three free BSDs - and Gnu/Hurd of course.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: GWindows and David Botton

[Georg Bauhaus]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:
: GtkAda    Full   C++      free     Win,Linux
           A Lot   C

Re: GWindows and David Botton

[Jeff C r e e.m]

"Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message 
news:mailman.91.1096057029.390.comp.lang.ada@ada-france.org...
>> What I like in Ada is that the very same program can be compiled and run 
>> on
>> different OS.
>
> It seems I always do web systems these days I don't need a GUI library 
> much. But sometimes I do. Last time I used JEWL. Please guide me here. I 
> seem to remember GtkAda as a binding to a C++ library and have way too 
> much unecessary stuff like string functions, an interpreter, all that Tcl 
> bagage. In the landscape I see also Glade, GWindows, Claw, Windex.
Gtk and GtkAda have nothing at all to do with Tcl/Tk. There is no 
interpreter.

There is no C++.

There is however some "extra" stuff like string libraries... 

Re: GWindows and David Botton

[Pascal Obry]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> different OSes of GtkAda are just Linux and Windows right? GNAT has a lot

No it is also ported to Mac OS-X.

> more. Isn't there a GNAT-related GUI library? Glade?

No GLADE is the GUI builder that generates GtkAda code.

> I've sensed the same sort of doubts in others people and even in other
> fora. Maybe we could build a feature table of GUI libraries for Ada to help
> people chose, if that is not too politically incorrect. I'll kick off with
> what I seem to know, please correct and add.
> 
> Library   Level  Sublang  License  OSes       Other features
> ------------------------------------------------------------
> Claw      Full
> Glade     High            free
> GtkAda    Full   C++      free     Win,Linux
                   C                 + MacOS-x  supported
> GWindows                  free
> JEWL      High            free     Win
> Windex
> Win32     Low             free     Win
> ------------------------------------------------------------

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GWindows and David Botton

[Marius Amado Alves]

I've collected what we have so far. I dropped the Level field, it was 
too hard to define. Binding renames Sublang. Added Install, Support, 
Remarks.

GUI libraries for Ada comparate
(C) Guys de Cla

Library   Binding  License  OSes    Install  Support  Remarks
-------------------------------------------------------------
Claw                        W
Glade              free                               (a)
GtkAda    C        free     L,M,W
GWindows           free
JEWL               free     W       easy
Windex
Win32              free     W
-------------------------------------------------------------
(a) visual tool for GtkAda

Binding:
Programming language X, if the library is a binding to a library in X.

OSes:
L = Linux
M = MacOS
W = Windows

Install:
easy = installs out of the box
hard = requires a guru

Support:
free = dedicated volunteer structure e.g. a maillist (not CLA)
com = commercial support
no = no support (but of course CLA continues to exist)
Append "/doc" if documentation exists (free)

* Related threads in comp.lang.ada *

GWindows and David Botton
GTK

Re: GWindows and David Botton

[Georg Bauhaus]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:
: I've collected what we have so far. I dropped the Level field, it was 
: too hard to define. Binding renames Sublang. Added Install, Support, 
: Remarks.
: 
: GUI libraries for Ada comparate
: (C) Guys de Cla
: 
: Library   Binding  License  OSes    Install  Support  Remarks
: -------------------------------------------------------------
: Claw               free/com W                ?/com
see http://www.rrsoftware.com/html/prodinf/tips.html#claw_faqs
The web pages also point you to doc.

Re: GWindows and David Botton

[Ludovic Brenta]

  Library   Level  Sublang  License  OSes          Other features
  ------------------------------------------------------------
+ AdaBindX  Low    C        free     Linux,*BSD    Xlib, Xt, Xm (motif/lesstif)
  Claw      Full
  Glade     High            free
- GtkAda    Full   C++      free     Win,Linux
+ GtkAda    Full   C        free     Win,Linux,*BSD,MacOS X
  GWindows                  free
  JEWL      High            free     Win
+ TASH      High   Tcl/Tk   free     Win,Linux,*BSD  interpreted
  Windex
  Win32     Low             free     Win
  ------------------------------------------------------------

I'm not sure what you mean by "level".  I suggest to split it into two
columns: one "level of language" to distinguish between thin and thick
bindings, and one "completeness" that gives an indication about the
features available.  For example, JEWL is high-level but no very rich,
whereas AdaBindX is low-level but feature-rich.

-- 
Ludovic Brenta.

Re: GWindows and David Botton

[Stephen Leake]

Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:

> OK, that sounds fine to me -  I will go with comp.lang.ada as a
> communication medium  I have neve done anything with Sourceforge other
> than download software from it. Does anyone here who might want to
> work on GWindows have any experience with it? 

I'm an administrator on the Grace project on Savannah; I believe
Sourceforge is similar.

Note that Grace is no longer active.

> In any case, I will investigate Sourceforge myself and see what it
> takes to start a new project there.

Ok. Please don't start one until we get some agreement about who's
going to be a member. We might not want to call it Gwindows :).

We should take seriously Randy's offer to open up the rest of Claw. I
have not examined much of Claw or Gwindows (I have of course read all
of Windex :), but from what I remember, I believe Claw is the best
structured of the three.

I'll download the current Gwindows and Claw and give them another
look.

But if there are enough people already using Gwindows, it makes sense
to go with that.

> And to get started, I would like to start laying out a roadmap of
> things that need to get done.  I can think of several areas that can
> stand some more work.

Ok.

> 1. Documentation. The existing tutorial intro is a good start, but
> it needs much work, as do the associated tutorial examples. For
> example, there is no section in the tutorial intro about the use of
> radio buttons, and there is no corresponding example program.
> 
> Some of the examples show several variations of ways to do things,
> which might be best broken up into several independent example
> programs. The numbering scheme for tutorial programs needs to be
> changed so that new ones can be added without renumbering all of the
> later ones.

Tutorials are always good, and always hard to get people to write. I
wrote test code for Windex, but not a tutorial. It is a good idea to
keep it on the List of Things To Do :).

Speaking of which, test code should also be included, preferably for
every package. I've got a GUI test driver framework for Win32 that
works quite nicely.

> A reference manual is needed.

I hope that the Ada specs can be the reference manual, given a good
tutorial and the MS API documentation. Again, getting people to write
documentation is hard.

> Documentation should be available in some form other than Word, as not
> everybody has or likes it. Anybody can get a free Adobe pdf reader,
> and I can easily create documents in that form. (I actually like
> WordPerfect, but few use it nowadays, although it can easily produce
> both pdf and html outputs.)

PDF is definitely the way to go for distribution. I prefer LaTeX for
the source format; it works nicely with CVS for change control.

> 2. Bugs need to be identified and fixed. I hereby call for bug
> reports, so that we can look to see what needs to be done.

Sourceforge has a nice bug reporting and tracking feature.

> 3. Deficiencies in existing areas need to be addressed. An example
> here is edit boxes. There seems to be no general way to capture
> character entered into an edit box and do special handling for
> things like carriage returns. In general, if Visual Basic can do
> something, GWindows should be able to do the same thing.

Yes, that's a good guideline. 

> 4. Expansion areas need to be identified. Printing is important for
> me. I want to do printing additions in two stages. The first level
> should bring printing support up to a rough equivalent of what can
> be done with Visual Basic 6, but done in a more coherent Ada way.
> The second level needs to add some kind of higher-level document
> abstraction. I have in mind something like the qPrinter package for
> Visual Basic 6. (Google for qPrinter and you will find it
> immediately.)

This raises the issue of architecture control. Will the Gwindows
project be a cathedral or a bazarre? Do we want to form a group that
requires consensus on major design decisions (like this one), or just
a set of people who happen to share a CVS repository?

In general, I prefer a consensus design, but it can be difficult to
manage.

> The existing thin binding to the Windows printing API should not be
> neglected - various API functions are missing and should be added.

Ok.

> 5. Various extensions need to be done to character string handling.
> Gwindows tries to hide the difference between  character
> representation among the various versions of Windows by defining a
> GString to be composed of either ordinary or wide characters as
> needed, and likewise tries to hide the differences between various
> Windows API procedures and functions that use string arguments. This
> hiding philosophy in not completely implemented and  I still need to
> use a variety of Ada system packages that have both ordinary and
> wide-character versions. (Typically the wide versions, as I do all of
> my development on Windows 2K and XP)

Hmm. In Windex I supported both Character and Wide-Character as I
needed to. I'd prefer that over "hidden magic". But I'm not familiar
with all the localization issues; I've seen some messages here that
imply we really need a Wide-Wide-Character.

> I'm going to need help; I am far from being the best Ada programmer in
> the world 

I can help there :).

> and I know little about low-level Windows API programming. 

I recommend you buy "Win32 Programming" by Brent E. Rector, Joseph M.
Newcomer. It covers most of the Win32 API, using just C. That makes it
easy to figure out how to do the same things in Ada. It's a little old
(1997), but it does a very good job of explaining all the things that
MS leaves out of their documentation.

Another good book is "Programming Windows" by Charles Petzold. That's
more tutorial oriented, and doesn't cover as much of the API as "Win32
Programming".

At the same time, the MS API documentation is online at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/windows_api_reference.asp
; it is quite readable (once you've read "Win32 Programming" :).

> If all goes well, both of those situations will change for the
> better as this project develops.

Yes, that's true :).

-- 
-- Stephe

Re: GWindows and David Botton

[Stephen Leake]

"stephane richard" <stephane.richard@verizon.net> writes:

> >If there was sufficient demand, I could probably be talked into making the
> >est of the Claw Binding (not the GUI Builder -- gotta keep something back!)
> >GMGPL.
> 
> Well here's my demand ;-). 

Stephane, I understand your enthusiasm for all Windows bindings. But
it would be best if the few of us who are willing to work on Windows
bindings agree to take just one forward. 

We should compare Windex, Gwindows, and Claw, and decide which one
makes the best starting point. Or decide to merge all three into some
new product. Or pick some other approach. It might be good to start
with some general requirements (like "do anything Visual Basic 6 can
do").

I suspect Randy will stick to Claw, since he's supporting it as a
commercial product. Randy; would you be open to having others
contribute to making architectural decisions about the future
development of Claw?

-- 
-- Stephe

Re: GWindows and David Botton

[Stephen Leake]

"Matthew Heaney" <mheaney@on2.com> writes:

> You could also try tigris.org.  That's where Charles and the AI-302
> reference implemention are hosted.
> 
> http://charles.tigris.org/

Sigh. Now we have to make a decision :). Going with Sourceforge was
easy when I thought it was the only option.

Matthew, can you give us some insight into Tigris? Do you have any
complaints or praise?

On a brief look thru the docs, it has ssh CVS access, BugZilla issue
tracking, and web page hosting. All good stuff, and similar to
SourceForge. 

Do they place limits on size?

Hmm. I just found their "Tigris mission statement"; they want projects
that are related to software engineering issues. Any idea whether a
Windows binding fits that? Hmm. Looking thru the list of projects, a
Windows binding seems ok.

-- 
-- Stephe

Re: GtkAda vs Windex, Gwindows

[Stephen Leake]

Pascal Obry <obry@act-europe.fr> writes:

> Stephen Leake <stephen_leake@acm.org> writes:
> 
> > I'm considering giving up on GtkAda for Windows development, and
> 
> Well that's not the moment to give up :) Gtk+ on Windows is maturing quickly
> and the 2.4.7 version is quite better than previous ones. Note also that the
> Gtk+Wimp (Native Windows look&feel) is now part of the Gtk+ project.

That's all good.

> Will this makes you stay on the GtkAda side ?

It doesn't address my issues.

The problems I'm having relate to basic issues of how signals and
events are propagated. I'm not paying for GtkAda support at work any
more, and I'm not getting good answers from the newsgroups/mailing
lists. I _really_ don't want to have to read the C code to find out
how things work, but that's what I'm stuck with.

For example, I can't figure out why an EventWindow doesn't respond to
a Focus event. (If you read the GtkAda mailing list, you've seen this
issue). The Gtk manuals are not clear on this topic, and neither the
GtkAda nor Gtk mailing lists have been much help. It's extremely
frustrating. When I write Ada code at home, it's for relaxation and
fun; I have a very low tolerance for frustration.

The lack of a good MDI is also a major stumbling block (no, I don't
like the GtkAda MDI; too buggy, and too hard to fix - I tried that
when I had support).

I _really_ like the auto-resizing features of Gtk, and the general
container design, and the ability to use 'tab' to move between
widgets. I'm sure it would take a lot of work to duplicate that in
Gwindows.

At the moment, I'm working on a card program. Robin's Cards (written
in Visual Basic 3, for Windows 3.1, for my wife - see
http://www.toadmail.com/~ada_wizard/robcards/robcard.html) finally
broke on Windows XP, so I need to rewrite it (in Ada, of course). I
had it partially done in Windex, so I finished it. It was remarkably
easy, compared to the struggles I've had with my GtkAda projects. On
the other hand, a card playing program only needs a drawing window for
bitblts, and a menu system; pretty basic.

I suspect when I try to do a more complex project in Gwindows, I'll
pine for some GtkAda features. But at least I'll be able to understand
_all_ the details of the code, if I need to.

> What I like in Ada is that the very same program can be compiled and
> run on different OS. So GtkAda seems very important to me!

I agree in principle. And if the core of Gtk was in Ada, I'd have no
problem committing to that.

I suppose I should try reading the C code, maybe it's not all that
bad. I'd feel better if I felt that others in the GtkAda community
shared my concerns.

At the same time, although I keep planning to get a Linux system to
"play with", it never seems worth it; Windows works well enough for
me, and I really don't have time to spend on two operating systems and
two GUI systems. I hate sounding like an ad for Microsoft, but it's
just the facts of life.

It may be that I'll only ever be happy with code I write myself - I
tend to be a perfectionist.

-- 
-- Stephe

Re: GWindows and David Botton

[Stephen Leake]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> I've collected what we have so far. I dropped the Level field, it was
> too hard to define. Binding renames Sublang. Added Install, Support,
> Remarks.

This needs to be on a web page, but I'll provide what I know about
Windex.

Binding: Win32 API (C)
License: GMGPL
OSes: Windows 95 .. XP
Install: tar.gz source
Support: occasional email


-- 
-- Stephe

Re: GWindows and David Botton

[Marius Amado Alves]

Update.

GUI libraries for Ada comparate
(C) Guys de Cla

Library   Binding  License  OSes    Install  Support  Remarks
-------------------------------------------------------------
AdaBindX  C        free     B,L                       (b)
Claw                        W
Glade              free                               (a)
GtkAda    C        free     B,L,M,W
GWindows           free
JEWL               free     W       easy
TASH      Tcl/Tk   free     B,W,L
Windex             GMGPL    W                free
Win32              free     W
-------------------------------------------------------------
(a) visual tool for GtkAda
(b) other features: Xlib, Xt, Xm (motif/lesstif)

Binding:
Programming language X, if the library is a binding to a library in X.

OSes:
B = BSD
L = Linux
M = MacOS
W = Windows

Install:
easy = installs out of the box
hard = requires a guru

Support:
free = dedicated volunteer structure e.g. a maillist (not CLA)
com = commercial support
no = no support (but of course CLA continues to exist)
Append "/doc" if documentation exists (free)

* Threads in comp.lang.ada *

GTK
GWindows and David Botton

Re: GWindows and David Botton

[Ed Falis]

I've used GTKAda on Solaris, too, and imagine it will work whereever you  
have GTK+ and GNAT.

- Ed

Re: GWindows and David Botton

[Jacob Sparre Andersen]

Ed Falis wrote:

> I've used GTKAda on Solaris, too, and imagine it will work whereever
> you have GTK+ and GNAT.

Which AFAIK means practically any Unix running X as a graphics system.

Jacob
-- 
No trees were killed in the sending of this message.
However a large number of electrons were terribly inconvenienced.

Re: GWindows and David Botton

[Ed Falis]

On 25 Sep 2004 17:59:28 +0200, Jacob Sparre Andersen <sparre@nbi.dk> wrote:

> Which AFAIK means practically any Unix running X as a graphics system.

That's what I assume.

Re: GWindows and David Botton

[Craig Carey]

On Fri, 24 Sep 2004 12:26:21 -0400, "Matthew Heaney" <mheaney@on2.com>
wrote:

>You could also try tigris.org.  That's where Charles and the AI-302
>reference implemention are hosted.
>
>http://charles.tigris.org/
>

I suggest that Ada project owners avoid Tigris.org, since it seems to
be under-manned, and have a site search feature that can't find Ada 95
projects.

There are 2 Ada projects hosted at tigris.org:

(1) http://charles.tigris.org/ :
   "Summary" : "Charles is a container and algorithms library for Ada."

(2) http://tope.tigris.org/ :
   "Summary" : "Ada 95 Symbolic Algebra quantifier eliminator & logic &
                geometry 

Tigris can'5 find both for these 4 searches done at the main "projects"
  tab webpage:

(i) searching for "ada": with and without, the double quotes;
(2) and searching using 'contains Summary' mode and using
   'contains Name'.


My fast Unbounded Strings package is faster than the Charles code in my
tests.
   http://tope.tigris.org/source/browse/tope/src/Striunli/

AdaCore replied ot a bug report which would be interpreted as saying
that low level string assignment code was rewritten.

>
>
>"Stephen Leake" wrote in message:
...
>> > (http://www.adaworld.com) is my website and I have plenty of space..
...
Any CVS/ (no(?))

>> I used to recommend Savannah, supported by the Gnu Project; Grace was
>> there. But they took a _long_ time to recover from a hacker attack;
...
The statement is true.

Re: GWindows and David Botton

[Fionn mac Cuimhaill]

On 25 Sep 2004 08:01:25 -0400, Stephen Leake <stephen_leake@acm.org>
wrote:

>Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>
>> OK, that sounds fine to me -  I will go with comp.lang.ada as a
>> communication medium  I have neve done anything with Sourceforge other
>> than download software from it. Does anyone here who might want to
>> work on GWindows have any experience with it? 
>
>I'm an administrator on the Grace project on Savannah; I believe
>Sourceforge is similar.
>
>Note that Grace is no longer active.
>
>> In any case, I will investigate Sourceforge myself and see what it
>> takes to start a new project there.
>
>Ok. Please don't start one until we get some agreement about who's
>going to be a member. We might not want to call it Gwindows :).
>
>We should take seriously Randy's offer to open up the rest of Claw. I
>have not examined much of Claw or Gwindows (I have of course read all
>of Windex :), but from what I remember, I believe Claw is the best
>structured of the three.
>
>I'll download the current Gwindows and Claw and give them another
>look.
>
>But if there are enough people already using Gwindows, it makes sense
>to go with that.
>
>> And to get started, I would like to start laying out a roadmap of
>> things that need to get done.  I can think of several areas that can
>> stand some more work.
>
>Ok.
>
>> 1. Documentation. The existing tutorial intro is a good start, but
>> it needs much work, as do the associated tutorial examples. For
>> example, there is no section in the tutorial intro about the use of
>> radio buttons, and there is no corresponding example program.
>> 
>> Some of the examples show several variations of ways to do things,
>> which might be best broken up into several independent example
>> programs. The numbering scheme for tutorial programs needs to be
>> changed so that new ones can be added without renumbering all of the
>> later ones.
>
>Tutorials are always good, and always hard to get people to write. I
>wrote test code for Windex, but not a tutorial. It is a good idea to
>keep it on the List of Things To Do :).
>
>Speaking of which, test code should also be included, preferably for
>every package. I've got a GUI test driver framework for Win32 that
>works quite nicely.
>
>> A reference manual is needed.
>
>I hope that the Ada specs can be the reference manual, given a good
>tutorial and the MS API documentation. Again, getting people to write
>documentation is hard.
>
>> Documentation should be available in some form other than Word, as not
>> everybody has or likes it. Anybody can get a free Adobe pdf reader,
>> and I can easily create documents in that form. (I actually like
>> WordPerfect, but few use it nowadays, although it can easily produce
>> both pdf and html outputs.)
>
>PDF is definitely the way to go for distribution. I prefer LaTeX for
>the source format; it works nicely with CVS for change control.
LaTeX is OK with me - I started with LaTeX 15 years ago, which I used
to document a large Fortran project that had grown up over several
years without adequate documentation.
>
>> 2. Bugs need to be identified and fixed. I hereby call for bug
>> reports, so that we can look to see what needs to be done.
>
>Sourceforge has a nice bug reporting and tracking feature.
>
>> 3. Deficiencies in existing areas need to be addressed. An example
>> here is edit boxes. There seems to be no general way to capture
>> character entered into an edit box and do special handling for
>> things like carriage returns. In general, if Visual Basic can do
>> something, GWindows should be able to do the same thing.
>
>Yes, that's a good guideline. 
>
>> 4. Expansion areas need to be identified. Printing is important for
>> me. I want to do printing additions in two stages. The first level
>> should bring printing support up to a rough equivalent of what can
>> be done with Visual Basic 6, but done in a more coherent Ada way.
>> The second level needs to add some kind of higher-level document
>> abstraction. I have in mind something like the qPrinter package for
>> Visual Basic 6. (Google for qPrinter and you will find it
>> immediately.)
>
>This raises the issue of architecture control. Will the Gwindows
>project be a cathedral or a bazarre? Do we want to form a group that
>requires consensus on major design decisions (like this one), or just
>a set of people who happen to share a CVS repository?
Some concensus is certainly desirable, as it will help to keep a good
team together. However, I don't want to build a GWindows architecture
that makes different ways of doing things impossible. In the printing
project that I want to do, I want to build a Gwindows printer object
similar in concept to the VB printer object, so that it can form a
stable base for higher level abstractions. For now, I'll call it
GPrinterObject. I would like to build a printable document abstraction
on top of that (GDocument)   I want to keep the two cleanly separated,
so that other printing projects using a quite different design
philosophy can be built on top of GPrinterObject. 
>
>In general, I prefer a consensus design, but it can be difficult to
>manage.
>
>> The existing thin binding to the Windows printing API should not be
>> neglected - various API functions are missing and should be added.
>
>Ok.
>
>> 5. Various extensions need to be done to character string handling.
>> Gwindows tries to hide the difference between  character
>> representation among the various versions of Windows by defining a
>> GString to be composed of either ordinary or wide characters as
>> needed, and likewise tries to hide the differences between various
>> Windows API procedures and functions that use string arguments. This
>> hiding philosophy in not completely implemented and  I still need to
>> use a variety of Ada system packages that have both ordinary and
>> wide-character versions. (Typically the wide versions, as I do all of
>> my development on Windows 2K and XP)
>
>Hmm. In Windex I supported both Character and Wide-Character as I
>needed to. I'd prefer that over "hidden magic". But I'm not familiar
>with all the localization issues; I've seen some messages here that
>imply we really need a Wide-Wide-Character.
The "hidden magic" of the GString character type is quite simple, but
it is used almost everywhere in GWindows where character strings are
needed. It would be simpler to proceed with that philosophy rather
that to change it.
>
>> I'm going to need help; I am far from being the best Ada programmer in
>> the world 
>
>I can help there :).
>
>> and I know little about low-level Windows API programming. 
>
>I recommend you buy "Win32 Programming" by Brent E. Rector, Joseph M.
>Newcomer. It covers most of the Win32 API, using just C. That makes it
>easy to figure out how to do the same things in Ada. It's a little old
>(1997), but it does a very good job of explaining all the things that
>MS leaves out of their documentation.
>
>Another good book is "Programming Windows" by Charles Petzold. That's
>more tutorial oriented, and doesn't cover as much of the API as "Win32
>Programming".
>
>At the same time, the MS API documentation is online at
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/windows_api_reference.asp
>; it is quite readable (once you've read "Win32 Programming" :).
>
>> If all goes well, both of those situations will change for the
>> better as this project develops.
>
>Yes, that's true :).

Re: GWindows and David Botton

[Stephen McNeill]

Fionn mac Cuimhaill <invisible@hiding.from.spam> wrote in message news:<9g87l018jg6p8q7vi6ttbdvrelt3ohrpfo@4ax.com>...

...

> And to get started, I would like to start laying out a roadmap of
> things that need to get done.  I can think of several areas that can
> stand some more work.
> 
> 1. Documentation. The existing tutorial intro is a good start, but it
> needs much work, as do the associated tutorial examples. For example,
> there is no section in the tutorial intro about the use of radio
> buttons, and there is no corresponding example program. 
> 
> Some of the examples show several variations of ways to do things,
> which might be best broken up into several independent example
> programs. The numbering scheme for tutorial programs needs to be
> changed so that new ones can be added without renumbering all of the
> later ones.
> 
> A reference manual is needed.
> 
> Documentation should be available in some form other than Word, as not
> everybody has or likes it. Anybody can get a free Adobe pdf reader,
> and I can easily create documents in that form. (I actually like
> WordPerfect, but few use it nowadays, although it can easily produce
> both pdf and html outputs.)

It seems not many enjoy writing documentation... What a shame, I enjoy
it.

I updated the existing (Botton) documentation for my own use and added
a reference manual, but I agree that it needs to be substantially
updated, and preferably overhauled completely. If this project goes
ahead with some kind of structure, I'd be happy to start working on
the documentation and reference manual.

> I'm going to need help; I am far from being the best Ada programmer in
> the world and I know little about low-level Windows API programming.
> If all goes well, both of those situations will change for the better
> as this project develops.

I think the key thing is to get the package up to the point where it
has the annoying bugs removed, and the basic capability smoothed out,
and documentation provided, so that new users can have some confidence
that using the package will be worth the investment in time. Then, and
only then, I think it will be worthwhile adding new modules, covering
new or expanded sections of the Windows API. That doesn't stop anyone
developing new capabilities of course.

Personally, I'm interested in extending the package in the multimedia
area, as well as providing some capability for graphics.

Stephen

Re: GWindows and David Botton

[tmoran]

>Personally, I'm interested in extending the [GWindows?] package in the
>multimedia area, as well as providing some capability for graphics.
  Claw has, in testing, Claw.Multimedia.Audio & Claw.Multimedia.Video
with some example programs.

Re: GWindows and David Botton

[Fionn mac Cuimhaill]

On 26 Sep 2004 14:57:54 -0700, mcneills@landcareresearch.co.nz
(Stephen McNeill) wrote:

... snip ...
>
>It seems not many enjoy writing documentation... What a shame, I enjoy
>it.
>
>I updated the existing (Botton) documentation for my own use and added
>a reference manual, but I agree that it needs to be substantially
>updated, and preferably overhauled completely. If this project goes
>ahead with some kind of structure, I'd be happy to start working on
>the documentation and reference manual.

Very good - we should use your improvemenrs as a first step.

... snip ...

>I think the key thing is to get the package up to the point where it
>has the annoying bugs removed, and the basic capability smoothed out,
>and documentation provided, so that new users can have some confidence
>that using the package will be worth the investment in time. Then, and
>only then, I think it will be worthwhile adding new modules, covering
>new or expanded sections of the Windows API. That doesn't stop anyone
>developing new capabilities of course.

I pretty much agree here. My main reason for pushing ahead with the
printing stuff is that I have an immediate need for it.

The very first step should be to establish a new home for GWindows. I
looked at Sourceforge, and one of the things that it wants done in
setting up a new project there is to establish that the software
license really is an open-source license.

The GWindows license is the GNU GPL with this tweak:

"As a special exception,  if other files  instantiate  generics from
this  unit, or you link  this unit with other files  to produce an
executable,  this  unit  does not  by itself cause  the resulting
executable  to  be covered  by the  GNU  General  Public  License.
This exception does not however invalidate  any other reasons why  the
executable file  might be covered by the  GNU Public License."

Do we need to improve on this, or is this OK as it stands? We should
make sure that we have a good open-source license regardless of which
home GWindows finds, whether it be Sourceforge or some other place.
>
>Personally, I'm interested in extending the package in the multimedia
>area, as well as providing some capability for graphics.
Graphics will overlap with printing - I definitely approve.


>
>Stephen

GWindows license (Was: GWindows and David Botton)

[Jacob Sparre Andersen]

Fionn mac Cuimhaill wrote:

> The very first step should be to establish a new home for
> GWindows. I looked at Sourceforge, and one of the things that it
> wants done in setting up a new project there is to establish that
> the software license really is an open-source license.
> 
> The GWindows license is the GNU GPL with this tweak:
> 
> "As a special exception, if other files instantiate generics from
> this unit, or you link this unit with other files to produce an
> executable, this unit does not by itself cause the resulting
> executable to be covered by the GNU General Public License.  This
> exception does not however invalidate any other reasons why the
> executable file might be covered by the GNU Public License."

This is known as the GMGPL or the GNAT-Modified General Public
License.  I think you can be sure it fits the Open Source Definition.
FSF do at least seem to be happy enough with it.

Jacob
-- 
�I'm perfectly happy with my current delusional system.�
                                           -- Mirabel Tanner

Re: GWindows and David Botton

[Georg Bauhaus]

Fionn mac Cuimhaill <invisible@hiding.from.spam> wrote:
: On 26 Sep 2004 14:57:54 -0700, mcneills@landcareresearch.co.nz
: (Stephen McNeill) wrote:
: 
: ... snip ...
:>
:>It seems not many enjoy writing documentation... What a shame, I enjoy
:>it.
:>
:>I updated the existing (Botton) documentation for my own use and added
:>a reference manual, but I agree that it needs to be substantially
:>updated, and preferably overhauled completely. If this project goes
:>ahead with some kind of structure, I'd be happy to start working on
:>the documentation and reference manual.
: 
: Very good - we should use your improvemenrs as a first step.

I hope that Randy Brukardt's and Tom Moran's respective offers (making
the rest of CLAW GMGPLed, which, if I understand correctly, will include
the media packages) are not deliberately ignored?

Or is there some technical profit in not co-ordinating efforts?
I guess Ada vendors have customer who do already use CLAW. Will
they be attracted to another great effort likely to be very similar
to CLAW, and abandon a supported product (CLAW) that already meets
their needs?
What kind of support can they expect?

Conversly, imagine that for a Windows bindings project you had
- RR Software's experience in building Windows bindings
- CLAW customers' interest in the project if based on CLAW
- and possibly other vendors' (and customers') interest in an
  alternative high level Ada binding.


-- Georg

Re: GWindows and David Botton

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.100.1096114015.390.comp.lang.ada@ada-france.org...
> "stephane richard" <stephane.richard@verizon.net> writes:
>
> > >If there was sufficient demand, I could probably be talked into making
the
> > >est of the Claw Binding (not the GUI Builder -- gotta keep something
back!)
> > >GMGPL.
> >
> > Well here's my demand ;-).
>
> Stephane, I understand your enthusiasm for all Windows bindings. But
> it would be best if the few of us who are willing to work on Windows
> bindings agree to take just one forward.
>
> We should compare Windex, Gwindows, and Claw, and decide which one
> makes the best starting point. Or decide to merge all three into some
> new product. Or pick some other approach. It might be good to start
> with some general requirements (like "do anything Visual Basic 6 can
> do").
>
> I suspect Randy will stick to Claw, since he's supporting it as a
> commercial product. Randy; would you be open to having others
> contribute to making architectural decisions about the future
> development of Claw?

I think so. For most areas, anyway, as there are many interesting areas
where we have no customer demand. I tend to tweak things a bit when they are
checked in (Tom can tell you all about that!) in order to keep things
consistent. But I rarely redo them.

                        Randy.

Re: GWindows and David Botton

[Stephen McNeill]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<cj916q$8as$1@a1-hrz.uni-duisburg.de>...
 
> I hope that Randy Brukardt's and Tom Moran's respective offers (making
> the rest of CLAW GMGPLed, which, if I understand correctly, will include
> the media packages) are not deliberately ignored?
> 
> Or is there some technical profit in not co-ordinating efforts?
> I guess Ada vendors have customer who do already use CLAW. Will
> they be attracted to another great effort likely to be very similar
> to CLAW, and abandon a supported product (CLAW) that already meets
> their needs?
> What kind of support can they expect?
> 
> Conversly, imagine that for a Windows bindings project you had
> - RR Software's experience in building Windows bindings
> - CLAW customers' interest in the project if based on CLAW
> - and possibly other vendors' (and customers') interest in an
>   alternative high level Ada binding.
> 
> 
> -- Georg

Georg, that is a fair point. That is one of the reasons why (in a
message a few weeks ago I think) I asked whether it was important to
continue working with GWindows, or alternatively give it a decent
burial. If the consensus is to stand in behind CLAW, then provided
there is some general assurance that it is likely to survive, with a
basic cost that is generally acceptable to a reasonable range of
users, then I shall stand in line to offer help.

Stephen

Re: GWindows and David Botton

[Robert C. Leif]

      
      Although CLAW is the only package that is able to hide most of
Windows' complexity and ugliness, continued development of it for the
Windows GUI is a poor long-term bet.  One of the major advantages of CLAW is
that it is a thick binding.  Since Scalable Vector Graphics (SVG) XML
Graphics for the Web (http://www.w3.org/Graphics/SVG/) and XForms
(http://www.w3.org/MarkUp/Forms/) provide the infrastructure for a GUI, why
not interface to them and have a truly portable standard GUI. The XML
documents (code) required to be generated should be of about the same
complexity as a Windows Resource file.  There is the extra benefit that this
product should interface with the next version of OpenOffice
(http://www.openoffice.org/). The OpenOffice schema are much more readable
that those for Microsoft Office and appear to be based on W3C standards,
such as SVG and XSL:fo.
      
      OpenOffice "Mission Statement"
      "To create, as a community, the leading international office suite
that will run on all major platforms and provide access to all functionality
and data through open-component based APIs and an XML-based file format."
      Bob Leif 
      ------------------------------
      
      Message: 2
      Date: 27 Sep 2004 14:23:13 -0700
      From: mcneills@landcareresearch.co.nz (Stephen McNeill)
      Subject: Re: GWindows and David Botton
      To: comp.lang.ada@ada-france.org
      Message-ID: <116a1020.0409271323.1922da15@posting.google.com>
      Content-Type: text/plain; charset=ISO-8859-1
      
      Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:<cj916q$8as$1@a1-hrz.uni-duisburg.de>...
       
      > I hope that Randy Brukardt's and Tom Moran's respective offers
(making
      > the rest of CLAW GMGPLed, which, if I understand correctly, will
include
      > the media packages) are not deliberately ignored?
      > 
      > Or is there some technical profit in not co-ordinating efforts?
      > I guess Ada vendors have customer who do already use CLAW. Will
      > they be attracted to another great effort likely to be very similar
      > to CLAW, and abandon a supported product (CLAW) that already meets
      > their needs?
      > What kind of support can they expect?
      > 
      > Conversly, imagine that for a Windows bindings project you had
      > - RR Software's experience in building Windows bindings
      > - CLAW customers' interest in the project if based on CLAW
      > - and possibly other vendors' (and customers') interest in an
      >   alternative high level Ada binding.
      > 
      > 
      > -- Georg
      
      Georg, that is a fair point. That is one of the reasons why (in a
      message a few weeks ago I think) I asked whether it was important to
      continue working with GWindows, or alternatively give it a decent
      burial. If the consensus is to stand in behind CLAW, then provided
      there is some general assurance that it is likely to survive, with a
      basic cost that is generally acceptable to a reasonable range of
      users, then I shall stand in line to offer help.
      
      Stephen

Re: GWindows and David Botton

[tmoran]

>      Although CLAW is the only package that is able to hide most of
>Windows' complexity and ugliness, continued development of it for the
>Windows GUI is a poor long-term bet.  One of the major advantages of CLAW is
>that it is a thick binding.  Since Scalable Vector Graphics (SVG) XML
>Graphics for the Web (http://www.w3.org/Graphics/SVG/) and XForms
>(http://www.w3.org/MarkUp/Forms/) provide the infrastructure for a GUI, why
  Claw has a lot besides a Windows GUI.  Registry, clipboard, sockets, event
handling, and real-time sound and graphics, for instance, come to mind.

Re: GWindows and David Botton

[Pascal Obry]

On big plus for Gwindows is that it can automatically generate binding for
all COM/ActivX objects. Everything that come as COM/ActivX on Windows can be
instantly used in Ada via Gwindows without the need to write a binding!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GWindows and David Botton

[stephane richard]

"Pascal Obry" <pascal@obry.org> wrote in message 
news:uekkmnv4c.fsf@obry.org...
>
> On big plus for Gwindows is that it can automatically generate binding for
> all COM/ActivX objects. Everything that come as COM/ActivX on Windows can 
> be
> instantly used in Ada via Gwindows without the need to write a binding!
>
> Pascal.
>
> -- 
>
> --|------------------------------------------------------
> --| Pascal Obry                           Team-Ada Member
> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
> --|------------------------------------------------------
> --|              http://www.obry.org
> --| "The best way to travel is by means of imagination"
> --|
> --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

here's one I didn't know :-)...... 

Re: GWindows and David Botton

[David Botton]

Much agreed. Windex has better support if I recall for working with 
bitmaps. The ease of use of GWindows (multiple event models, etc) 
combined with some of the areas you fleshed out better in Windex would 
be an awsome package.

David Botton


On 2004-09-23 20:35:20 -0400, Stephen Leake <stephen_leake@acm.org> said:
> 
> I'm considering giving up on GtkAda for Windows development, and
> resurrecting Windex (long story, for another thread :). But I would
> consider joining an open Gwindows project, instead. I always thought
> Windex and Gwindows should be merged.

Re: GWindows and David Botton

[David Botton]

Gtk may partialy look like windows, but it hardly will ever feel like 
windows now or in the future (do note that using GWindows you could 
actually lift GtkAda up to feel like windows, really look like windows 
and even offer ActiveX and .NET support to boot). I believe there is 
some sample code in GWindows for placing an ActiveX control on a GtkAda 
window. That technique and better ones exist for GtkAda integration 
with GWindows.

A Rapid like approach that uses GtkAda for Linux and GWindows for 
Windows on its backend would be the better approach to acheive your 
goals. GtkAda could in theory become the Rapid like approach itself as 
well if it could shift a bit away from Gtk on Windows.

David Botton




On 2004-09-24 14:58:15 -0400, Pascal Obry <obry@act-europe.fr> said:

> 
> Stephen Leake <stephen_leake@acm.org> writes:
> 
>> I'm considering giving up on GtkAda for Windows development, and
> 
> Well that's not the moment to give up :) Gtk+ on Windows is maturing quickly
> and the 2.4.7 version is quite better than previous ones. Note also that the
> Gtk+Wimp (Native Windows look&feel) is now part of the Gtk+ project.
> 
> Will this makes you stay on the GtkAda side ?
> 
> What I like in Ada is that the very same program can be compiled and run on
> different OS. So GtkAda seems very important to me!
> 
> Pascal.

Re: GWindows and David Botton

[David Botton]

I have a comparison between GWindows and CLAW at:

http://www.adapower.com/gwindows/GWindowsVsClaw.html

Stephen, I would suggest looking at the event models in GWindows in 
particular to see the major reason (in addition to doing what was 
needed to allow for COM/.Net/ActiveX controls which may be the chief 
reason in the end) why I didn't build off of Windex which is very 
tightly bound to the Windows way of doing things. Windex while in 
general a smaller library than GWindows does have some areas that it is 
better fleshed out in.

GWindows is also tuned toward the larger project I was working on for a 
GNU Delphi replacement. (GWindows + GNATCOM + GNAVI IDE). So it is very 
easy to target for a GUI builder based on its dispatching model 
combined with inheritance.

David Botton


On 2004-09-25 08:06:46 -0400, Stephen Leake <stephen_leake@acm.org> said:
> 
> We should compare Windex, Gwindows, and Claw, and decide which one
> makes the best starting point. 

Re: GWindows and David Botton

[David Botton]

The reference manual for GWindows looks like it broke when I moved 
servers, but GWindows specs are extremely well documented and using 
AdaBrowse I generated a great Reference manual for it.

I don't have anything set up right now to rerun AdaBrowse on the specs, 
but I would recommend starting with something like that for GWindows.

David Botton


On 2004-09-26 12:21:24 -0400, Fionn mac Cuimhaill 
<invisible@hiding.from.spam> said:
>> 
>> I hope that the Ada specs can be the reference manual, given a good
>> tutorial and the MS API documentation. Again, getting people to write
>> documentation is hard.

Re: GWindows and David Botton

[David Botton]

On 2004-09-27 02:13:22 -0400, Fionn mac Cuimhaill 
<invisible@hiding.from.spam> said:

> The very first step should be to establish a new home for GWindows.

I would recommend just keeping it where it is and I'll offer FTP access 
to you and others.

> The GWindows license is the GNU GPL with this tweak:

This is the standard Modified GPL of GNAT. It doesn't get freerer than 
that or your messed anyways :-)

David Botton

Re: GWindows and David Botton

[David Botton]

GWindows/GNATCOM was born out of:

Personal need for a solid GMGPL Windows library that would easliy 
support under the covers what is needed for serious COM and Active X 
control use and development. (Yes, I have actually used GWindows + 
GNATCOM to even develop fully working Active X controls running in VB 
or .NET programs).

Easy to use and teach (with all modesty aside its simplicity combined 
with extreme extensability is something I am proud of) - a person with 
moderate skills can teach himself most of GWindows in a few hours and 
any one familiar with Windows can work miracles not long after that 
with the advantages of Ada.

Very clean and well documented (in code at least) Windows framework 
that took real advantage of Ada the language not just a "binding" be it 
thick or thin. Take a look at the way I bind to windows functions and 
it becomes obvious how the approach of a thick binding using a thin set 
of prototypes is inferior and clutters code. (I would recommend any one 
looking to do bindings in the future consider this approach to creating 
solid code around an API instead of "bindings").

To insure that Ada would be fully usable on Windows (that means even 
Windows CE, etc. ala GStrings and things like that) including all the 
new Windows technogies that are COM based (as even .NET is built on COM 
for the most part) in to the way future with out need for constant new 
bindings.

To be part of my (sadly, once plan) to produce a GNU VB/Delphi killer 
that would start to draw more of a mass interest in Ada as a whole for 
all platforms (It is possible to compile large parts of GWindows using 
Wine under Linux, but that was not the plan, just to get a more 
diverese and "younger" crowd to Ada). Sadly it is so close but yet I am 
no longer in the position to really push for it these days.

There are may other reasons as well, but these should I hope at least 
get people interested in looking  deeper in to the heart of the 
GWindows and GNATCOM. There is much more to it then many realize.

David Botton



On 2004-09-28 14:25:40 -0400, "stephane richard" 
<stephane.richard@verizon.net> said:

> 
> "Pascal Obry" <pascal@obry.org> wrote in message news:uekkmnv4c.fsf@obry.org...
>> 
>> On big plus for Gwindows is that it can automatically generate binding for
>> all COM/ActivX objects. Everything that come as COM/ActivX on Windows can be
>> instantly used in Ada via Gwindows without the need to write a binding!
>> 
>> Pascal.
>> 
>> -- 
>> 
>> --|------------------------------------------------------
>> --| Pascal Obry                           Team-Ada Member
>> --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
>> --|------------------------------------------------------
>> --|              http://www.obry.org
>> --| "The best way to travel is by means of imagination"
>> --|
>> --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
> 
> here's one I didn't know :-)...... 

Re: GWindows and David Botton

[Marius Amado Alves]

David Botton wrote:
> I have a comparison between GWindows and CLAW at:
> 
> http://www.adapower.com/gwindows/GWindowsVsClaw.html

Very useful. For any effect, the last state of our little chart follows.

GUI libraries for Ada comparate
(C) Guys de Cla

Library   Binding  License  OSes       Install  Support  Remarks
----------------------------------------------------------------
AdaBindX  C        free     B,L                          (b)
Claw                        W
Glade              free                                  (a)
GtkAda    C        free     B,L,M,S,W
GWindows           free
JEWL               free     W          easy
TASH      Tcl/Tk   free     B,W,L
Windex             GMGPL    W                   free
Win32              free     W
----------------------------------------------------------------
(a) visual tool for GtkAda
(b) other features: Xlib, Xt, Xm (motif/lesstif)

Binding:
Programming language X, if the library is a binding to a library in X.

OSes:
B = BSD
L = Linux
M = MacOS
S = Solaris
W = Windows

Install:
easy = installs out of the box
hard = requires a guru

Support:
free = dedicated volunteer structure e.g. a maillist (not CLA)
com = commercial support
no = no support (but of course CLA continues to exist)
Append "/doc" if documentation exists (free)

* Threads in comp.lang.ada *

GTK
GWindows and David Botton

Re: GWindows and David Botton

[Jerry van Dijk]

David Botton writes:

> GWindows is also tuned toward the larger project I was working on for a GNU
> Delphi replacement. (GWindows + GNATCOM + GNAVI IDE). So it is very easy to
> target for a GUI builder based on its dispatching model combined with
> inheritance.

Indeed. Even when not on a Delphi 3 level immediately such a tool would
facilitate the serious use of Ada for real bread-and-butter Windows
applications.

I have not brought this up as it seemed GWindows was dead in the
water. However, putting my money where my mouth is, I'd be willing to put some
time in moving GNAVI further along.

-- 
--  Jerry van Dijk
--  Leiden, Holland
--
-- 'Tradition is not the worship of ashes, but the preservation of fire."
--                                              Gustav Mahler (1860-1911)

Re: GWindows and David Botton

[Ludovic Brenta]

Marius Amado Alves writes:
> GUI libraries for Ada comparate
> (C) Guys de Cla

Allow me to elaborate.  I've added a new column for the underlying GUI
library or system, in addition to the target language of the binding.
Also I've filled in some of the licenses.

Library   Binding  License  OSes       GUI          Install  Support  Remarks
-----------------------------------------------------------------------------
AdaBindX  C        GMGPL    B,L        Lesstif      (d)               (b)
Claw                        W          Win32                 comm
Glade              GPL      B,L,?      GTK+         (d)               (a)
GtkAda    C        GMGPL    B,L,M,S,W  GTK+         (d)      comm
GWindows  C        GMGPL    W          Win32
JEWL               free     W          Win32        easy
TASH      Tcl      GMGPL    B,W,L      Tk           (d*)
Windex             GMGPL    W          Win32                 free
Win32     C        free     W          Win32
-----------------------------------------------------------------------------
(a) visual GUI builder and code generator (gate) for GtkAda
(b) binding to Xlib, Xt, and Xm (motif/lesstif)

In the Install column, (d) means a Debian package is available, making
install easy.  Note that I have packaged TASH but I am unwilling to
support it in Debian.  If anyone wants to step in, I will gladly send
them the package.

In the Support column, "comm" means commercial support is available.

-- 
Ludovic Brenta.

Re: GWindows and David Botton

[Jerry van Dijk]

Ludovic Brenta writes:

> Glade              GPL      B,L,?      GTK+         (d)               (a)

If you include Glade, you might also want to include RAPID:

ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.usafa.af.mil/pub/dfcs/carlisle/usafa/rapid/index.html

BTW: I am of birding this week, back friday afternoon.

-- 
--  Jerry van Dijk
--  Leiden, Holland
--
-- 'Tradition is not the worship of ashes, but the preservation of fire."
--                                              Gustav Mahler (1860-1911)

Re: GWindows and David Botton

[Stephen Leake]

David Botton <david@botton.com> writes:

> On 2004-09-27 02:13:22 -0400, Fionn mac Cuimhaill
> <invisible@hiding.from.spam> said:
> 
> > The very first step should be to establish a new home for GWindows.
> 
> I would recommend just keeping it where it is and I'll offer FTP
> access to you and others.

Hmm. Welcome back, David. 

I would prefer to join a project that has more robust support. Several
people tried to contact you about GWindows, and were unsuccessful.

-- 
-- Stephe

Re: GWindows and David Botton

[Stephen Leake]

David Botton <david@botton.com> writes:

> I have a comparison between GWindows and CLAW at:
> 
> http://www.adapower.com/gwindows/GWindowsVsClaw.html

Looks good. I was not aware of the issue around ActiveX controls (I've
never used one).

> Stephen, I would suggest looking at the event models in GWindows in
> particular to see the major reason (in addition to doing what was
> needed to allow for COM/.Net/ActiveX controls which may be the chief
> reason in the end) why I didn't build off of Windex which is very
> tightly bound to the Windows way of doing things.

Sorry, I don't see the event mechanism in GWindows as very compelling.
It is nowhere near as powerful as the event mechanism in Gtk. It has
no marshalling of parameters, and only one handler per event. In fact,
I don't see how it is better than the inheritance overloading mechanism.

> Windex while in general a smaller library than GWindows does have
> some areas that it is better fleshed out in.

Thanks.

-- 
-- Stephe

Re: GWindows and David Botton

[Stephen Leake]

Stephen Leake <stephen_leake@acm.org> writes:

> David Botton <david@botton.com> writes:
> 
> > On 2004-09-27 02:13:22 -0400, Fionn mac Cuimhaill
> > <invisible@hiding.from.spam> said:
> > 
> > > The very first step should be to establish a new home for GWindows.
> > 
> > I would recommend just keeping it where it is and I'll offer FTP
> > access to you and others.
> 
> Hmm. Welcome back, David. 
> 
> I would prefer to join a project that has more robust support. Several
> people tried to contact you about GWindows, and were unsuccessful.

In addition, CVS (not just FTP) is necessary when several developers
collaborate on a project. SourceForge also supports mailing lists and
bug/task tracking, which are very useful.

-- 
-- Stephe

Re: GWindows and David Botton

[David Botton]

It is not the power but simplicity and the fact that the overloading 
mechanism is still there as well any time you want. It beautifly 
fulfills its goal, a GUI library intended to be as close as posible but 
not too close to the underlying API to simplify use.

David Botton


On 2004-10-03 22:06:07 -0400, Stephen Leake <stephen_leake@acm.org> said:
> 
> Sorry, I don't see the event mechanism in GWindows as very compelling.
> It is nowhere near as powerful as the event mechanism in Gtk. It has
> no marshalling of parameters, and only one handler per event. In fact,
> I don't see how it is better than the inheritance overloading mechanism.

Re: GWindows and David Botton

[David Botton]

The most robust support is one you pay for. I would recommend for you 
the pay version of CLAW.

What I am hoping will be accomplished (again, as I tried this before) 
here in the next day or so (I am on vacation, ie. why I've got some 
time on my hands and posting) is for GWindows, GNATCOM and AdaPower to 
become community efforts.

David Botton


On 2004-10-03 21:57:27 -0400, Stephen Leake <stephen_leake@acm.org> said:
> 
> Hmm. Welcome back, David.
> I would prefer to join a project that has more robust support. Several
> people tried to contact you about GWindows, and were unsuccessful.

Re: GWindows and David Botton

[David Botton]

Just to emphasize my point, try teaching some one just in to 
programming to use any of the other GUI libraries and then GWindows. 
GWindows is targeted for ease of use by a VB / Delphi crowd.

Adding multiple handlers is easy to implement for some one like me or 
you if we needed them using GWindows either through inheritance or 
creating a generic adapter to the current mechanisms.

From practical real world experience, the idea of using multiple 
handlers leads to sloppy programs unless you have tight control on the 
entire development process or all top notch people working for you.

David Botton




On 2004-10-03 22:06:07 -0400, Stephen Leake <stephen_leake@acm.org> said:
> 
> Sorry, I don't see the event mechanism in GWindows as very compelling.
> It is nowhere near as powerful as the event mechanism in Gtk. It has
> no marshalling of parameters, and only one handler per event. In fact,
> I don't see how it is better than the inheritance overloading mechanism.

Re: GtkAda vs Windex, Gwindows

[Warren W. Gay VE3WWG]

Stephen Leake wrote:
> Pascal Obry <obry@act-europe.fr> writes:
>>Stephen Leake <stephen_leake@acm.org> writes:
>>>I'm considering giving up on GtkAda for Windows development, and
>>
>>Well that's not the moment to give up :) Gtk+ on Windows is maturing quickly
>>and the 2.4.7 version is quite better than previous ones. Note also that the
>>Gtk+Wimp (Native Windows look&feel) is now part of the Gtk+ project.
> 
> That's all good.
> 
>>Will this makes you stay on the GtkAda side ?
...
> For example, I can't figure out why an EventWindow doesn't respond to
> a Focus event. (If you read the GtkAda mailing list, you've seen this
> issue). The Gtk manuals are not clear on this topic, and neither the
> GtkAda nor Gtk mailing lists have been much help. It's extremely
> frustrating. When I write Ada code at home, it's for relaxation and
> fun; I have a very low tolerance for frustration.

I have to agree that the documentation could be better. I have had
similar "feelings" in the past about GtkAda, but looking for a
portable solution, I was forced recently to re-examine and get better
acquainted with it. I now keep notes ;-)

What it really needs is a better guide and manual. While some of the
GtkAda package organization makes logical sense to me, I have trouble
understanding other ones. I find myself constantly grepping specs
to find what I think I need. Sometimes I am forced to look at bodies
as well.

While some of this is unavoidable as the project matures (like some
of the support moving to this Pango package), I found it rather
confusing. What is really needed is a comprehensive user guide,
with full blown examples (not the few that come with the sources).

One area that I found weak in the extreme was how to use GtkAda to
draw on some sort of a graphics area. Many questions came to mind
about that (and I have done X Window graphics), but I had to do a
lot of experimentation and spec grepping to get through that.

If the GtkAda team is reading this, I would be willing to volunteer
some time on the documentation, though I cannot always be available
(I can work on it in spurts).

I have personally expended a lot of energy on my APQ documentation
because I know how important it is for people. An example can save
the programmer from reading much verbiage and abstraction, and can
cut to the chase. This is the reason the APQ documentation has an
example for every API function.

I hope the GtkAda folks don't take offense to these remarks. I know
that they have travelled a long and perhaps even a thankless road.
I appreciate GtkAda for being there, since application portability
is very important to me. But I think it is fair to say that better
documentation is needed to get more people to use it.

> I suppose I should try reading the C code, maybe it's not all that
> bad. I'd feel better if I felt that others in the GtkAda community
> shared my concerns.

I haven't had to look at the C code much yet, but give me time.
Certainly in fairness to GtkAda, Gtk could be better documented
as well!

> At the same time, although I keep planning to get a Linux system to
> "play with", it never seems worth it; Windows works well enough for
> me, and I really don't have time to spend on two operating systems and
> two GUI systems. I hate sounding like an ad for Microsoft, but it's
> just the facts of life.

I guess it depends upon your end goals. I like to produce software
not only for myself, but software that can be shared with others.
If I only did software for myself, I'd probably just do Linux/*NIX
projects and use X Window bindings or something. Something else
for those few Windows apps that I run on the laptop. Most of the
time, I want to write the app once, and be usable wherever it is
important.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: GWindows and David Botton

[tmoran]

>Library   Binding  License  OSes       GUI          Install  Support  Remarks
>Claw                        W          Win32                 comm

The line for Claw in the table should be split (now, at least) into the
Intro Edition and the Full Version.  Also the Install column should
say "easy" for both, and the Remarks should add (e) (like (a))

Library   Binding  License  OSes       GUI          Install  Support  Remarks
Intro Claw  C      GMGPL    W          Win32        easy     free      (e)
Full Claw   C      comm     W          Win32        easy     comm      (e)

(e) visual GUI builder available

I don't understand why the three support categories are "free", "comm",
and blank.  Do "free" and blank both mean the same, and shouldn't that be
"volunteer"?

I also suggest a column "coverage", a quantifiable measure of which is
the number of distinct "pragma Import"ed functions.  A quick count for
Claw showed:
Intro Claw    468
Full Claw     498

The table should also include a measure of the docs and provided sample
programs in the "official version".

Re: GtkAda vs Windex, Gwindows

[Ludovic Brenta]

"Warren W. Gay VE3WWG" writes:
> While some of this is unavoidable as the project matures (like some
> of the support moving to this Pango package), I found it rather
> confusing. What is really needed is a comprehensive user guide, with
> full blown examples (not the few that come with the sources).
>
> One area that I found weak in the extreme was how to use GtkAda to
> draw on some sort of a graphics area. Many questions came to mind
> about that (and I have done X Window graphics), but I had to do a
> lot of experimentation and spec grepping to get through that.

Do you count testgtk in the "few examples"?  If memory serves, it does
have graphics examples using GtkCanvas and XPMs.

On Debian:

$ mkdir ~/src
$ tar xvzf /usr/share/doc/libgtkada2-doc/examples/testgtk.tar.gz
$ cd testktk
$ cat README
$ make -f testgtk.mak

-- 
Ludovic Brenta.

Re: GWindows and David Botton

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

    Stephen> In addition, CVS (not just FTP) is necessary when several
    Stephen> developers collaborate on a project. SourceForge also
    Stephen> supports mailing lists and bug/task tracking, which are
    Stephen> very useful.

Why use CVS for new projects now? There are lots of alternatives to
CVS which aren't as brain dead, e.g. bitkeeper, subversion, tla/arch,
etc.

My favourite is TLA/arch as

* Like CVS, it is entirely open source.

* allows for renaming/moving files/directories, while maintaining full
  history, without resorting to ugly hacks.

* distributed repositories (meaning I can create my own repository,
  commit to it, and synchronise upstream changes, even if I don't have
  write access to the "official" server)

* GPG signed repository updates (could be good especially important
  when writing critical software; makes it harder for intruders to
  tamper with the archive undetected).

* TLA/arch will also work (read-only) over standard HTTP. It also
  works (read/write) over FTP, sftp (ssh), or webdav.

* Other points I have forgotten, See
<URL:http://www.gnu.org/software/gnu-arch/> and
<URL:http://gnuarch.org/>.

Then again, this is getting off topic for this thread and this
newsgroup... However, I use it for all my Ada software ;-).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: GWindows and David Botton

[stephane richard]

"Brian May" <bam@snoopy.apana.org.au> wrote in message 
news:sa4d5zy3wmn.fsf@snoopy.apana.org.au...
> Why use CVS for new projects now? There are lots of alternatives to
> CVS which aren't as brain dead, e.g. bitkeeper, subversion, tla/arch,
> etc.
>
Well if if a project is hosted on sourceforge, CVS is the way to go on that 
project server :-) 

Re: GWindows and David Botton

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:
> 
>     Stephen> In addition, CVS (not just FTP) is necessary when several
>     Stephen> developers collaborate on a project. SourceForge also
>     Stephen> supports mailing lists and bug/task tracking, which are
>     Stephen> very useful.
> 
> Why use CVS for new projects now? 

Because that's what SourceForge supports. We need a server that won't
go away, that many independent developers can use.

CVS may be old, but it does the job well enough.

> There are lots of alternatives to CVS which aren't as brain dead,
> e.g. bitkeeper, subversion, tla/arch, etc.
> 
> My favourite is TLA/arch as

Is there an available, robustly supported server that provides
TLA/arch access, like SourceForge does for CVS?

> * allows for renaming/moving files/directories, while maintaining full
>   history, without resorting to ugly hacks.

That would be nice.

> * distributed repositories (meaning I can create my own repository,
> commit to it, and synchronise upstream changes, even if I don't have
> write access to the "official" server)

That's also nice, if it works well.

> * GPG signed repository updates (could be good especially important
> when writing critical software; makes it harder for intruders to
> tamper with the archive undetected).

I'm not sure that's much better than ssh access.

> Then again, this is getting off topic for this thread 

Not really; we do need to pick a server.

> and this newsgroup... However, I use it for all my Ada software ;-).

Ok, that's a good recommendation.

-- 
-- Stephe

Re: GWindows and David Botton

[David Botton]

I think that using pragma import as a measure is a bit of a problem. 
Both GWindows and CLAW offer much more functionality than just an API 
layer.

The other problem is that GWindows allows for instant extension using 
ActiveX controls and COM bindings generated by GNATCOM.

Also, you may want to include the Windows API bindings that come with 
GNAT and also GNATWin (the original GNATWin, ie the one I created not 
the gnatwin package for GNAT the compiler) Windows thin API bindings 
from the GNATCOM page. (BTW if we do a pragma import count it beats 
GWindows and CLAW, not that I recommend it for anything but cut and 
paste with either framework available :-)

David Botton



> I also suggest a column "coverage", a quantifiable measure of which is
> the number of distinct "pragma Import"ed functions.  A quick count for
> Claw showed:
> Intro Claw    468
> Full Claw     498
> 
> The table should also include a measure of the docs and provided sample
> programs in the "official version".

Re: GWindows and David Botton

[Stephen Leake]

David Botton <david@botton.com> writes:

> The most robust support is one you pay for. I would recommend for you
> the pay version of CLAW.

Well, no; I plan on providing support for the community Windows
binding, on a volunteer basis. I also plan to use it in my own
projects.

I was refering to the support of the CVS server. SourceForge is well
supported as a community project server; AdaPower is not.

> What I am hoping will be accomplished (again, as I tried this
> before) here in the next day or so (I am on vacation, ie. why I've
> got some time on my hands and posting) is for GWindows, GNATCOM and
> AdaPower to become community efforts.

What, exactly, do you mean by this? 

You have joined near the end of a discussion with a similar goal; to
establish a community-supported thick Windows binding. We are
converging on agreement to start with CLAW, and merge in Windex and
GWindows. (At least, that's my impression; the discussion is not over
yet).

We have pretty much agreed that SourceForge is the best host for the
community effort, because:

1) It is well supported; does not rely on any one person.

2) It provides good tools for distributed projects (CVS, bug/task
   trackers).

Would you be willing to join such a project, as a developer and/or
architect?

-- 
-- Stephe

Re: GWindows and David Botton

[David Botton]

GNAVI List Repaired

When I had to move AdaPower mail a few months ago to a new server the 
GNAVI (This is the e-mail list that supports GWindows and GNATCOM) list 
had been busted. It is now repaired and I will work on recovering the 
e-mails that were on the list (a few hundred).

So I would ask to add to your table that volunteer support is available 
as it was up until a few months ago for GWindows.

For those that are interested and would like to join the list send the 
word subscribe in the subject to gnavi-list@gnavi.org

I have also temporarily set up gnavi.org to refer to the COM page on 
AdaPower, but will update it with updates of GWindows, GNATCOM and 
updates about  GNAVI (the GNU Ada Visual IDE) soon.

Thanks,
David Botton

Re: GWindows and David Botton

[Stephen Leake]

David Botton <david@botton.com> writes:

> I think that using pragma import as a measure is a bit of a problem.
> Both GWindows and CLAW offer much more functionality than just an API
> layer.

It is _one_ measure; it certainly should not be the _only_ measure.

> The other problem is that GWindows allows for instant extension
> using ActiveX controls and COM bindings generated by GNATCOM.

Is there some reason we can't use those same bindings with CLAW? 

I looked thru the output of GNATCOM in the GWindows directory; it does
not 'with' GWindows, so it seems like it would be just as easy to use
with CLAW.

-- 
-- Stephe

Re: GWindows and David Botton

[David Botton]

GNATCOM can certainly be used with CLAW. There are some issues with GUI 
ActiveX controls related to CLAW's use of tasks, but even that with 
some effort can be worked out.

David Botton


On 2004-10-04 21:27:31 -0400, Stephen Leake <stephen_leake@acm.org> said:
> 
> Is there some reason we can't use those same bindings with CLAW?
> I looked thru the output of GNATCOM in the GWindows directory; it does
> not 'with' GWindows, so it seems like it would be just as easy to use
> with CLAW.

Re: GWindows and David Botton

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

    Stephen> Because that's what SourceForge supports. We need a
    Stephen> server that won't go away, that many independent
    Stephen> developers can use.

Any site that allows HTTP access will work with TLA, although in
read-only access.

Any site that allows sftp access will work with TLA, not sure if
sourceforge does or not.

    Stephen> CVS may be old, but it does the job well enough.

It is also the most popular.

    Stephen> Is there an available, robustly supported server that provides
    Stephen> TLA/arch access, like SourceForge does for CVS?

Yes, there are. For example there is http://alioth.debian.org/, run by
Debian, see http://arch.debian.org/ for details. I believe alioth also
supports subversion. There are others available, I can't think of them
off-hand.

    >> * allows for renaming/moving files/directories, while maintaining full
    >> history, without resorting to ugly hacks.

    Stephen> That would be nice.

Yes, definitely. It means you can commit your project straight away,
even though you may plan to completely redesign the file system
layout.

There are several ways this can be done, one way is to insert a
special tag into every file. This means to move a file, you just move
it. TLA will pick it up automatically.

Some people don't like this approach, so other methods are
available. I use the explicit method, which means every file has a
separate .id file, in the .arch-ids directory, which contains a unique
identifier for the file. If you move a file, you move its id at the
same time (I use Unix aliases to help me with this), so tla knows what
has happened.

    >> * distributed repositories (meaning I can create my own repository,
    >> commit to it, and synchronise upstream changes, even if I don't have
    >> write access to the "official" server)

    Stephen> That's also nice, if it works well.

Its a future I haven't used extensively, but on the rare occasion I do
use it, it works pretty well.

    >> * GPG signed repository updates (could be good especially important
    >> when writing critical software; makes it harder for intruders to
    >> tamper with the archive undetected).

    Stephen> I'm not sure that's much better than ssh access.

ssh solves a different problem; ssh is transport layer, this is when
it is stored on disk.

So, when committing a changeset, I sign the changeset too. Now if
somebody managed to get write access to the repository, and changed it
to make it look like I inserted malicious code, the signature would no
longer match, and it would be clear the archive is corrupt.

    >> and this newsgroup... However, I use it for all my Ada software ;-).

    Stephen> Ok, that's a good recommendation.

;-)

To be fair, it does have some disadvantages:

* It requires a new mind set, and old CVS concepts have to be
  forgotten and relearnt.

* It was built by a developer who hates Windows. As such, Windows
  support is still not official. There are unofficial versions
  versions for Windows, some people have complained of poor
  performance and other issues. For example, Unix supports a
  repository with two files "README" and "readme", but if you try to
  use this repository on windows, you will get unpredictable results,
  as Windows is case-insensitive.

  However, I have used the cygwin version, it seems to work fine, at
  least for my small projects. A native windows version is also
  available.

* The lead developer likes command line tools, e.g. patch, reject
  files, etc. Some people may not like the absence of a GUI
  interface. Dealing with rejects by looking at a reject file from
  patch takes a bit of getting use to (the developers have good
  reasons for doing it this way, they say it makes it easier to manage
  conflicts this way).

* Some commands are low level compared with other source code revision
  systems. There is no "annotate" command for example (although you
  can get it with add on software). There is no single command to
  compare two arbitrary versions (although comparing the current
  checked out version with the same version in the repository is easy;
  Also finding a list of change-sets that aren't in your checked out
  version is easy).

I think all of these issues are being worked on, I am not exactly
keeping up-to-date with the latest developments (due to time
constraints). I could imagine some of these points might be show
stoppers for some people, it depends on the developers who will be
using it, and what it is for, I guess.

Then there is also subversion. I realize the arch developers dislike
subversion, saying some of the design decisions are really bad,
doesn't support distributed repositories, archive format is ugly, etc,
but it does work well for a number of projects, and doesn't have some
of the limitations mentioned above.

Somebody once made the analogy that subversion like a newer version of
CVS, TLA is a complete rewrite from scratch.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: GWindows and David Botton

[David Botton]

I would join, but regardless of direction, I and others plan on 
continuing development of GWindows, GNATCOM and GNAVI (the Delphi like 
GUI builder I had started).

I would suggest looking at the GMGPL CLAW page on AdaPower 
http://www.adapower.com/claw/ as there is some good materials for a 
CLAW based startup if you decide that direction, ie.
	* Very good examples of using CLAW (Moran)
	* An example of how to put an ActiveX control on to CLAW windows (Myself)

The reason I plan on continuing (and perhaps you should consider before 
making a decision) is:

* There is already a decent install base of GWindows including use in 
traditional and GPL'd apps (of course, I assume in terms of users, CLAW 
has a vastly larger base)
* GWindows for the most part (but not all) is already a _superset_ of 
CLAW both in design and functionality
* Where GMGPL CLAW has more functionality, the code can easily be 
integrated in to GWindows
* GWindows ease of use for teaching GUI programming do to model and good specs
* GWindows shows good Ada design while demonstrating how to be 
practical in design choices instead of Academic, ie. it is "real world"
* GWindows ease of use for programming both very small and very large systems
* GWindows integration of COM/DCOM/ActiveX/.NET using all Ada, no C/C++ 
or MFC code needed (as in ObjectAda or older GWindows releases)
* GWindows integration of Database support
* GWindows design for future integration in to a Delphi like environment
* GWindows offers UNICODE API support out of the box making it a better 
choice for 64 Bit Windows, NT, 2000, XP and Longhorn - ie. the ANSI API 
(and thus CLAW, the thin Win32Ada binding, GWindows ANSI build, etc) 
should only be used where Win9X/ME is a must (and then one should offer 
both binaries).
* GWindows can be used for windows CE programming as well if a cross 
compiler was available
* GWindows has always been MGPL'd and as such has always been very much 
alive even if I was not :-)
* I have and attachment to the FSF's GNU/GPL philosophy and practice 
and want to support such projects. (Despite being a Mr. Windows in the 
Ada world, All of my own work and the majority of programming I do is 
on Linux, Darwin and Mac OS X. GWindows was created to advocate Ada and 
GPL/MGPL _not_ Windows, somehow that point always gets lost in the 
sauce....)

There are many more specific technical reasons on a feature by feature 
basis. There is a lot of  work to bring CLAW to the point where 
GWindows is (I had always hoped on my long absences that in fact CLAW, 
the framework, would have been advanced as I have never looked or 
intended to harm financially those working on CLAW with my efforts, nor 
the feelings of any including yours Stephen despite Windex having also 
been MGPL'd, GWindows grew out of different needs). The areas not 
"bound" by GWindows on the other hand are few and easily added by any 
one familiar with Windows and Ada.

The only reason I noticed for not supporting GWindows as the GNU Ada 
standard was my absences. I'd like to point out a few things:

* Despite my personal absence there has been continued development of 
GWindows by others (although true, I haven't integrated them in to the 
base yet, but they are available)
* There hasn't been much need of support and there has been some peer 
support from others on the GNAVI-List until it broke a few months ago 
(now fixed)
* More than one set of GMGPL'd professional extensions has been made
* The GMGPL Claw version has been around for some time now yet no one 
pushed to extend it, I expect that anything less than a full GMGPL 
version of CLAW will mean the same lethargic response
* CLAW, the framework, hasn't really been updated/extended per se. 
(Note the web page is older than that of GWindows) that despite the 
availability of many of my tools and some examples that could have been 
used with out compromising lic.,etc. (as pointed out by others) to give 
CLAW additional support where GWindows was stronger.

My 2 cents, you would be better off pushing forward with GWindows (as 
GWindows can't see why a name change, etc. is needed either, GWindows 
the (M)GPL'd//GNAT Windows binding for Ada). The code base is already 
there, it is MGPL'd, it has been proven in the real world, there are 
already people working to extend it, fix the few bugs it has had, etc.

David Botton


On 2004-10-04 20:54:39 -0400, Stephen Leake <stephen_leake@acm.org> said:
> Would you be willing to join such a project, as a developer and/or
> architect?

Re: GtkAda Package Hierarchy (was ...vs Windex, Gwindows)

[Warren W. Gay VE3WWG]

Ludovic Brenta wrote:
> "Warren W. Gay VE3WWG" writes:
> 
>>While some of this is unavoidable as the project matures (like some
>>of the support moving to this Pango package), I found it rather
>>confusing. What is really needed is a comprehensive user guide, with
>>full blown examples (not the few that come with the sources).
>>
>>One area that I found weak in the extreme was how to use GtkAda to
>>draw on some sort of a graphics area. Many questions came to mind
>>about that (and I have done X Window graphics), but I had to do a
>>lot of experimentation and spec grepping to get through that.
> 
> Do you count testgtk in the "few examples"?  If memory serves, it does
> have graphics examples using GtkCanvas and XPMs.

I don't recall now, because it was several weeks ago when I went
hunting. Part of the problem (and this is documentation related),
is what do you go grepping for? There are a number of example
programs there, but how do you look for "something that does drawing"
beyond the scribble program? You need to know what you're looking
for to begin with (documentation). I think I ended up looking at
GDK and GLIB references, but beyond that I don't recall now.

Anyway, I don't know if I finally ended up there or not, but I
managed to figure it out with a lot of trial and error and
looking at specs.

Another problem that often occurs in example programs is they
tend to highlight some all-singing all dancing feature or
group thereof. Simpler examples would probably be more useful,
in some cases. I know... we can contribute them ;-)

PACKAGE HIERARCHY COMMENTS:

One thing about the package hierarchy of GtkAda that "bugs"
me, is that the packages seem to subdivided on C terms.
For example why do we have a Gtk and GtkAda package? Why
are not all widgets and packages under a root GtkAda package?

I think the intention of GtkAda was to be a thick binding, so
why not make GtkAda the top level package and subdivide things
on a thick basis underneath? With the Glib, Gdk, Gtk,
GtkAda, Pango top level packages, it just seems a little bit
uncoordinated. It pollutes top level name space too. I always
ask myself, where is x in the GtkAda namespace? Some font
thingies are here, but others are in Pango, and yet others
are..

They would make more sense to me as a hierarchy
underneath GtkAda, and subdivided by functional category
perhaps. As a perfectionist, I guess I yearn for
greater namespace purity :)

The Gtk.Extra is another example. The fact that these are
"extra" widgets, doesn't necessarily imply that they cannot
be in a GtkAda.X hiearchy with other "normal" widgets. Why
should "extra" widgets be treated differently than others?
It just seems to be too much influenced by the fact that
they are in a gtkextra subdirectory, which is unimportant
to the end developer. If you care about traceability to
code, then comments in the specs do that job nicely.

Again folks, I am not trying to be critical here of the fine
effort that folks have done with GtkAda. I applaud their
efforts and as users of GtkAda the rest of us enjoy using
the fruits of their labour. It is always easier to be critical
than to contribute. Please just accept this as my humble
$0.02 worth of opinion. I just hope this post doesn't stir
up a hornet's nest, because that is not the intent. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: GtkAda vs Windex, Gwindows

[Stephane Riviere]

>I have personally expended a lot of energy on my APQ documentation
>because I know how important it is for people. An example can save
>the programmer from reading much verbiage and abstraction, and can
>cut to the chase. This is the reason the APQ documentation has an
>example for every API function.

I deeply second that. Although I'm not an APQ user, I've carefully
read your doc and study your code. Your manual is really good !

-- 
Stephane Riviere
Oleron Island - France
http://stephane.rochebrune.org
OpenPgp Key <5fd6a1e6> available on the web site above

Re: GtkAda vs Windex, Gwindows

[stephane richard]

"Stephane Riviere" <stephane@_delete_this_rochebrune.org> wrote in message 
news:4163d10e.2665823@news.free.fr...
>
> I deeply second that. Although I'm not an APQ user, I've carefully
> read your doc and study your code. Your manual is really good !
>
> -- 
> Stephane Riviere
> Oleron Island - France
> http://stephane.rochebrune.org
> OpenPgp Key <5fd6a1e6> available on the web site above

I third that.  ;-).  Like you I'm not an apq user...yet as I've never given 
myself a project requiring database handling.  However that may change as 
I'm thinking of possible starting a business application soon (to hit that 
side of the free software categories :-).  there's alot of programs being 
developed....anyone find a "good" accounting application ?  one that can be 
relied on?  that's just one example :-).  I'm thinking about it, filtering 
out what will be included (or not) at this stage....:-)

Stephane Richard
"Ada World" webmaster
http://www.adaworld.com

Re: GWindows and David Botton

[Ludovic Brenta]

Stéphane richard writes:
> Brian May wrote:
>> Why use CVS for new projects now? There are lots of alternatives to
>> CVS which aren't as brain dead, e.g. bitkeeper, subversion, tla/arch,
>> etc.
>
> Well if if a project is hosted on sourceforge, CVS is the way to go
> on that project server :-)

Then I would suggest meta-CVS.  It is a CVS client that uses a regular
CVS server for storage, but stores directory and filename information
under version control, records merges, and solves most of the problems
in CVS.

Check it out here: http://users.footprints.net/~kaz/mcvs.html

"System requirements: Meta-CVS runs on Linux, and on Windows under
Cygwin."

-- 
Ludovic Brenta.

Re: GWindows and David Botton

[Chris Humphries]

Ludovic Brenta wrote:
> Stéphane richard writes:
> 
>>Brian May wrote:
>>
>>>Why use CVS for new projects now? There are lots of alternatives to
>>>CVS which aren't as brain dead, e.g. bitkeeper, subversion, tla/arch,
>>>etc.
>>
>>Well if if a project is hosted on sourceforge, CVS is the way to go
>>on that project server :-)
> 
> 
> Then I would suggest meta-CVS.  It is a CVS client that uses a regular
> CVS server for storage, but stores directory and filename information
> under version control, records merges, and solves most of the problems
> in CVS.
> 
> Check it out here: http://users.footprints.net/~kaz/mcvs.html
> 
> "System requirements: Meta-CVS runs on Linux, and on Windows under
> Cygwin."
> 

The value that sourceforge provides seems more important and useful
than the actual revision control stuff.

1) sourceforge is not going anywhere
2) bug reporting
3) webhosting + file storage
4) project details and news
5) cvs
6) not operated by any single one person, but may be operated by
    many (with or without the original person that started it).
7) free

the code revision etc stuff seems minor when there is sourceforge.

Re: GWindows and David Botton

[Ludovic Brenta]

Chris Humphries writes:
> The value that sourceforge provides seems more important and useful
> than the actual revision control stuff.
>
> 1) sourceforge is not going anywhere
> 2) bug reporting
> 3) webhosting + file storage
> 4) project details and news
> 5) cvs
> 6) not operated by any single one person, but may be operated by
>     many (with or without the original person that started it).
> 7) free
>
> the code revision etc stuff seems minor when there is sourceforge.

Well, I have mixed feelings about this.  Despite its known and
annoying flaws, CVS was popular when SourceForge was established.
SourceForge chose to support CVS for its simplicity.  Now, the
popularity of SourceForge makes CVS popular, but the deficiencies in
CVS are still there.

I cannot help but think that CVS is the "C" of revision control
systems.  Ada programmers deserve better than that :)

With Meta-CVS, one can get the best of everything: the SourceForge CVS
server and surrounding tools, without the annoying CVS deficiencies.

At least, I think Meta-CVS is worth a look.

-- 
Ludovic Brenta.

Re: GWindows and David Botton

[Pascal Obry]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> Well, I have mixed feelings about this.  Despite its known and
> annoying flaws, CVS was popular when SourceForge was established.
> SourceForge chose to support CVS for its simplicity.  Now, the
> popularity of SourceForge makes CVS popular, but the deficiencies in
> CVS are still there.

That's wrong! CVS has always been very popular AFAIK. It has superceded RCS
and SCCS long time ago. I agree that CVS is not the best version control
system around but it is quite good, and it is good enough for some very large
projects ! 

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GWindows and David Botton

[tmoran]

>* GWindows for the most part (but not all) is already a _superset_ of
>CLAW both in design and functionality
  I know it's a political season and we're all used to ads stretching the
truth, but this is ridiculous.  GWindows is not a _superset_ of even the
currently GMGPLed Introductory version of Claw, let alone the full version.

Re: SourceForge, CVS and revision control systems (was: GWindows and David Botton)

[Ludovic Brenta]

Pascal Obry writes:
> Ludovic Brenta writes:
>
>> Well, I have mixed feelings about this.  Despite its known and
>> annoying flaws, CVS was popular when SourceForge was established.
>> SourceForge chose to support CVS for its simplicity.  Now, the
>> popularity of SourceForge makes CVS popular, but the deficiencies
>> in CVS are still there.
>
> That's wrong! CVS has always been very popular AFAIK. It has
> superceded RCS and SCCS long time ago. I agree that CVS is not the
> best version control system around but it is quite good, and it is
> good enough for some very large projects !

If you think that the deficiencies in CVS are not serious, think
again.  No atomic commits, no recording of merges, no versioning of
directory structure, no replication, poor scalability (in terms of
performance) come to mind.

I agree that CVS is "good enough", and I am aware that some very large
projects use it succesfully.  But that is not my point.  My point is
twofold:

- CVS has known flaws.  These are design, not implementation flaws and
  only a redesign can fix them.  There are several projects with the
  stated purpose to replace CVS with better designs.  To illustrate:
  the name "subversion" is not an accident.

- SourceForge helps maintain or even increase the popularity of CVS
  despite its known deficiencies.

The main reasons why CVS is still so popular despite its problems and
the concerted efforts by some groups to replace it are the installed
base, inertia (especially of large projects, by their very nature),
and its simplicity.

The large projects that use CVS do so at the cost of extra work on the
part of the developers.  For example, CVS does not help prevent
multiple merges of the same changes into a branch.  A skilled release
manager is required to perform this function manually, when it could
be performed automatically and reliably by the tool.

The parallel with the C programming language is quite obvious to me.
C replaced assembler a long time ago, and it is still being used
massively despite its known problems.

The large projects that use C do so at the cost of extra work on the
part of developers.  For example, C does not help prevent buffer
overflows.  A skilled programmer is required to perform this function
manually, when it could be performed automatically and reliably by the
compiler.

-- 
Ludovic Brenta.

Re: GtkAda vs Windex, Gwindows

[Warren W. Gay VE3WWG]

stephane richard wrote:
> "Stephane Riviere" <stephane@_delete_this_rochebrune.org> wrote in message 
> news:4163d10e.2665823@news.free.fr...
> 
>>I deeply second that. Although I'm not an APQ user, I've carefully
>>read your doc and study your code. Your manual is really good !
>>
>>-- 
>>Stephane Riviere
>>Oleron Island - France
>>http://stephane.rochebrune.org
>>OpenPgp Key <5fd6a1e6> available on the web site above
> 
> I third that.  ;-).  Like you I'm not an apq user...yet as I've never given 
> myself a project requiring database handling.  However that may change as 
> I'm thinking of possible starting a business application soon (to hit that 
> side of the free software categories :-).  there's alot of programs being 
> developed....anyone find a "good" accounting application ?  one that can be 
> relied on?  that's just one example :-).  I'm thinking about it, filtering 
> out what will be included (or not) at this stage....:-)
> 
> Stephane Richard
> "Ada World" webmaster
> http://www.adaworld.com

Thanks guys. Writing code is still more fun ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: SourceForge, CVS and revision control systems (was: GWindows and David Botton)

[Pascal Obry]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> If you think that the deficiencies in CVS are not serious, think

I did not say that ! I wanted to point out that saying that SourceForge made
CVS popular seems boggus to me.

> again.  No atomic commits, no recording of merges, no versioning of
> directory structure, no replication, poor scalability (in terms of
> performance) come to mind.

Agreed with this.

> I agree that CVS is "good enough", and I am aware that some very large
> projects use it succesfully.  But that is not my point.  My point is
> twofold:
> 
> - CVS has known flaws.  These are design, not implementation flaws and
>   only a redesign can fix them.  There are several projects with the
>   stated purpose to replace CVS with better designs.  To illustrate:
>   the name "subversion" is not an accident.

Ok.

> - SourceForge helps maintain or even increase the popularity of CVS
>   despite its known deficiencies.

I'm still not ok with this ;) But well that's not a big problem !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GWindows and David Botton

[David Botton]

For a small list of differences see: 
http://www.adapower.com/gwindows/GWindowsVsClaw.html

Although my point is, a superset of design and functionality, yes. 
There may be individual APIs here and there in areas where CLAW has 
more or GWindows has more, but the key is that GWindows is  more than a 
binding while still being as close to the API as a binding with out 
losing ease of use and understandability.

I would say that GWindows is to CLAW what Borland's VCL is to MFC.

The only thing is that CLAW is far away from being as complete as MFC 
while GWindows is just about on par with VCL of at least Delphi 3.

My point is that GWindows as an MGPL project from the start and as such 
was, is and will be alive regardless. In fact any work going in to a 
new project or versions of CLAW released as MGPL become good grounds 
for its growth. If CLAW becomes completely MGPL the same can be said 
about it as well in relationship to GWindows.

The question is, is it worth:

Creating yet another competing framework (I am sure that CLAW is not 
going to disappear either)
Negotiating to get as much of CLAW in to the MPGL space as possible 
when RR may not be ready yet to support an alternative financial model
Starting with CLAW and then having to go through the sources to recode 
for UNICODE support and other important features needed to support the 
advancement of windows beyond Windows 9X/ME
Redoing the creation thread of CLAW for COM/DCOM/ActiveX/.NET
etc.

GWindows is a more sound place to start as a code base and CLAW 
certainly has very much what to add.

As for the MGPL version of CLAW not being a subset, if any of the 
GWindows users needed what was there we would have incorporated it 
already (some may have in their own projects :-) I have seen a few 
loose APIs I may borrow from there in the future for the GWindows base, 
just haven't had a time or need yet.

David Botton



On 2004-10-05 15:44:33 -0400, tmoran@acm.org said:

>> * GWindows for the most part (but not all) is already a _superset_ of
>> CLAW both in design and functionality
>   I know it's a political season and we're all used to ads stretching the
> truth, but this is ridiculous.  GWindows is not a _superset_ of even the
> currently GMGPLed Introductory version of Claw, let alone the full version.

Re: GWindows and David Botton

[stephane richard]

"David Botton" <david@botton.com> wrote in message 
news:2004100517335116807%david@bottoncom...
>
> I would say that GWindows is to CLAW what Borland's VCL is to MFC.
>
And this is why I said, in another thread,  that CLAW and GWindows should 
co-exist.  Because of the difference in minding of both.  As you say if 
GWindows is VCL and CLAW is MFC then there's 2 very different types of users 
that will want to use either or both depending on their respective 
backgrounds :-).

> The question is, is it worth:
>
> Creating yet another competing framework (I am sure that CLAW is not going 
> to disappear either)
> Negotiating to get as much of CLAW in to the MPGL space as possible when 
> RR may not be ready yet to support an alternative financial model
> Starting with CLAW and then having to go through the sources to recode for 
> UNICODE support and other important features needed to support the 
> advancement of windows beyond Windows 9X/ME
> Redoing the creation thread of CLAW for COM/DCOM/ActiveX/.NET
> etc.
>
Well although this would be a free software effort on both, competition 
between VCL and MFC is what made these two class hierarchies what they are 
today.  I think it would be a good and healthy for both to be actively 
modified and altered in their own specific mindings.

I'm not a peace keeper here....this is my humble opinion :-) 

Re: GWindows and David Botton

[Stephen Leake]

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:
> 
>     Stephen> Because that's what SourceForge supports. We need a
>     Stephen> server that won't go away, that many independent
>     Stephen> developers can use.
> 
> Any site that allows HTTP access will work with TLA, although in
> read-only access.
> 
> Any site that allows sftp access will work with TLA, not sure if
> sourceforge does or not.

The question is whether the SourceForge servers are running the TLA
server software (I assume there is a server executable?). As far as I
know, they are not. Nor does the typical user (that's us) have the
permission to run new code on the servers.

>     Stephen> Is there an available, robustly supported server that provides
>     Stephen> TLA/arch access, like SourceForge does for CVS?
> 
> Yes, there are. For example there is http://alioth.debian.org/, run by
> Debian, see http://arch.debian.org/ for details. I believe alioth also
> supports subversion. There are others available, I can't think of them
> off-hand.

Hmm. It seems somehow "wrong" to host a Windows project on a Debian
server :). 

Do you have any insight into the reliability of alioth? I know Debian
in general strives for reliability over wizzyness. But it is an
all-volunteer organization. So for our purposes, I think SourceForge
is a better choice.

>     >> * GPG signed repository updates (could be good especially important
>     >> when writing critical software; makes it harder for intruders to
>     >> tamper with the archive undetected).
> 
>     Stephen> I'm not sure that's much better than ssh access.
> 
> ssh solves a different problem; ssh is transport layer, this is when
> it is stored on disk.
> 
> So, when committing a changeset, I sign the changeset too. Now if
> somebody managed to get write access to the repository, and changed it
> to make it look like I inserted malicious code, the signature would no
> longer match, and it would be clear the archive is corrupt.

Ok, that would be useful in some situations. But I'm not too worried
about that sort of thing.

> To be fair, it does have some disadvantages:
> 
> * It requires a new mind set, and old CVS concepts have to be
>   forgotten and relearnt.

Hey, we want people to learn new concepts (Ada vs C, etc); that's a
plus :).

> * It was built by a developer who hates Windows. As such, Windows
> support is still not official. 

That's obviously a killer for an explicitly Windows-only project.

> * The lead developer likes command line tools, e.g. patch, reject
>   files, etc. Some people may not like the absence of a GUI
>   interface. 

I need an Emacs interface. As in I won't use it without one.

>   Dealing with rejects by looking at a reject file from patch takes
>   a bit of getting use to (the developers have good reasons for
>   doing it this way, they say it makes it easier to manage conflicts
>   this way).

Have they ever seen Emacs pcvs? That's far and away the best user
interface to a CM tool I've ever seen.

> * Some commands are low level compared with other source code
> revision systems. There is no "annotate" command for example
> (although you can get it with add on software). There is no single
> command to compare two arbitrary versions (although comparing the
> current checked out version with the same version in the repository
> is easy; Also finding a list of change-sets that aren't in your
> checked out version is easy).

That's what the Emacs interface is for; you build user-friendly
front-end commands on top of the command line primitives.

-- 
-- Stephe

Re: GWindows and David Botton

[Stephen Leake]

David Botton <david@botton.com> writes:

> I would join, but regardless of direction, I and others plan on
> continuing development of GWindows, GNATCOM and GNAVI (the Delphi like
> GUI builder I had started).
> 
> I would suggest looking at the GMGPL CLAW page on AdaPower
> http://www.adapower.com/claw/ as there is some good materials for a
> CLAW based startup if you decide that direction, ie.
> 	* Very good examples of using CLAW (Moran)
> 	* An example of how to put an ActiveX control on to CLAW
> windows (Myself)

There was a distinct feeling that the Ada community in general would
benefit from going forward with only _one_ thick Windows binding,
because that would enhance the level of support for that binding (both
in terms of user experience and developers fixing problems and adding
features). 
 
> * There is already a decent install base of GWindows including use in
> traditional and GPL'd apps (of course, I assume in terms of users,
> CLAW has a vastly larger base)

Ok, so it makes more sense to proceed with CLAW as a base.

> * GWindows for the most part (but not all) is already a _superset_ of
> CLAW both in design and functionality

Ok, so it won't be hard to merge GWindows into CLAW. 

Although I agree with Randy; "superset" is not a proper description here.

> * Where GMGPL CLAW has more functionality, the code can easily be
> integrated in to GWindows

Or vice versa.

> * GWindows ease of use for teaching GUI programming do to model and
> good specs 

I don't get this impression from reading the code. I have not had much
experience in teaching any Ada GUI system to users. But I understand
the CLAW code more easily than the GWindows code, because the CLAW
code has better comments.

> * GWindows shows good Ada design while demonstrating how to be
> practical in design choices instead of Academic, ie. it is "real
> world"

I think CLAW has a better design. But I guess that will always be a
matter of opinion.

> * GWindows ease of use for programming both very small and very
> large systems

I don't see that as much different for CLAW. Perhaps this is a case of
"it's easier to program in a system I know".

> * GWindows integration of COM/DCOM/ActiveX/.NET using all Ada, no
> C/C++ or MFC code needed (as in ObjectAda or older GWindows
> releases)

That's _not_ GWindows, that's GNATCOM. As we have already established,
CLAW can easily take advantage of that as well. Please be consistent
in this discussion!

> * GWindows integration of Database support

That is a point. It looks easy to port to CLAW.

> * GWindows design for future integration in to a Delphi like
> environment

It would be interesting to hear how CLAW lacks in this department.

> * GWindows offers UNICODE API support out of the box making it a
> better choice for 64 Bit Windows, NT, 2000, XP and Longhorn - ie. the
> ANSI API (and thus CLAW, the thin Win32Ada binding, GWindows ANSI
> build, etc) should only be used where Win9X/ME is a must (and then one
> should offer both binaries).

Hmm. I guess I haven't looked at the Unicode issue in CLAW. Clearly it
could be added.

> * GWindows can be used for windows CE programming as well if a cross
> compiler was available

What prevents CLAW from doing that? Although I don't rank this high on
a list of requirements.

> * GWindows has always been MGPL'd 

As CLAW is now (or will be soon, if we agree to start a community
project with it).

> and as such has always been very much alive even if I was not :-)

Well, that's not true. That's exactly why this whole discussion got
started; there was no active support for GWindows, and we were
discussing the best way to start a support group.

> * I have and attachment to the FSF's GNU/GPL philosophy and practice
> and want to support such projects. (Despite being a Mr. Windows in the
> Ada world, All of my own work and the majority of programming I do is
> on Linux, Darwin and Mac OS X. GWindows was created to advocate Ada
> and GPL/MGPL _not_ Windows, somehow that point always gets lost in the
> sauce....)

Me too, but I'm not sure how it applies here. Once CLAW becomes
GMGPL, it meets the same philosophical goals.
 
> The only reason I noticed for not supporting GWindows as the GNU Ada
> standard was my absences. 

Actually, we are not talking about a GNU standard. I doubt the Gnu
Project would be interested in anything tightly bound to Windows.

We are talking about an Ada community standard.

> I'd like to point out a few things:
> 
> * Despite my personal absence there has been continued development of
> GWindows by others (although true, I haven't integrated them in to the
> base yet, but they are available)

Yes. And those others started a discussion on the best way to move
forward. Some agreed that a GMGPL'd CLAW was the best starting point.

> * There hasn't been much need of support and there has been some peer
> support from others on the GNAVI-List until it broke a few months ago
> (now fixed)

"need" is in the eye of the users. "need" was expressed here.

> * More than one set of GMGPL'd professional extensions has been made

I'm not clear how this is relevant.

> * The GMGPL Claw version has been around for some time now yet no one
> pushed to extend it, I expect that anything less than a full GMGPL
> version of CLAW will mean the same lethargic response

I personally didn't work with CLAW because it was not GMGPL. Making it
GMGPL changes that.

> * CLAW, the framework, hasn't really been updated/extended per se.

How is this relevant? If it's good, it's good.

> (Note the web page is older than that of GWindows) 

My Robin's Card's page is older than either. It still works, and is a
good card game. What's the point?

> that despite the availability of many of my tools and some examples
> that could have been used with out compromising lic.,etc. (as
> pointed out by others) to give CLAW additional support where
> GWindows was stronger.

There could be many reasons why your code was not added to CLAW; lack
of customer demand, for one. Lack of clear title, for another; GMGPL
is not enough when it comes to legal issues. You must also have clear
ownership, proof that the GMGPL license actually applies. 

But this actually illustrates the point that it would be better for
the Ada community if there is only one thick Windows binding. Then we
wouldn't have useful code that is not being used.

> My 2 cents, you would be better off pushing forward with GWindows
> (as GWindows can't see why a name change, etc. is needed either,
> GWindows the (M)GPL'd//GNAT Windows binding for Ada).

CLAW has a goal of compiler independence; that's actually a point in its
favor that I've forgotten to mention.

-- 
-- Stephe

Re: GWindows and David Botton

[Stephen Leake]

Ludovic Brenta <ludovic.brenta@insalien.org> writes:

> I cannot help but think that CVS is the "C" of revision control
> systems.  Ada programmers deserve better than that :)

I hadn't thought of it quite that way :).

> With Meta-CVS, one can get the best of everything: the SourceForge
> CVS server and surrounding tools, without the annoying CVS
> deficiencies.
> 
> At least, I think Meta-CVS is worth a look.

If Meta-CVS is a purely client tool, then each developer can use it or
not; it doesn't have to be a project-wide choice.

I already use CVS for _everything_. While in general I'm in favor of
learning new tools, in this case I'm sticking with CVS.

-- 
-- Stephe

Re: GWindows and David Botton

[Randy Brukardt]

"David Botton" <david@botton.com> wrote in message
news:2004100420540216807%david@bottoncom...
> I think that using pragma import as a measure is a bit of a problem.
> Both GWindows and CLAW offer much more functionality than just an API
> layer.

One problem with using a pragma Import count is that so many Windows
functions are messages, and they don't show up in such a could.

I've informally used the subprogram count for such things, but it too
doesn't prove much. It's the level and the design that matter.

              Randy.

Re: GWindows and David Botton

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.198.1097016057.390.comp.lang.ada@ada-france.org...
One point:

> > * GWindows offers UNICODE API support out of the box making it a
> > better choice for 64 Bit Windows, NT, 2000, XP and Longhorn - ie. the
> > ANSI API (and thus CLAW, the thin Win32Ada binding, GWindows ANSI
> > build, etc) should only be used where Win9X/ME is a must (and then one
> > should offer both binaries).
>
> Hmm. I guess I haven't looked at the Unicode issue in CLAW. Clearly it
> could be added

We originally intended to support "Wide_Claw" with the obvious semantics.
But there was virtually no interest in it, so in the end we didn't bother to
implement it. (One question I've always had was whether mixed programs
actually worked; the Microsoft APIs appear to assume all one or all the
other - which is easy to support in Claw or anything else for that matter.)

                      Randy.

Re: GWindows and David Botton

[David Botton]

On 2004-10-05 18:40:36 -0400, Stephen Leake <stephen_leake@acm.org> said:
>> * GWindows for the most part (but not all) is already a _superset_ of
>> CLAW both in design and functionality
> 
> Ok, so it won't be hard to merge GWindows into CLAW.
> Although I agree with Randy; "superset" is not a proper description here.
> 
>> * Where GMGPL CLAW has more functionality, the code can easily be
>> integrated in to GWindows
> 
> Or vice versa.

Actually my point is that it is easier to integrate the subset, i.e. it 
is easier to port CLAW "bindings" in to the GWindows "framework"

> 
>> * GWindows ease of use for teaching GUI programming do to model and
>> good specs
> 
> I don't get this impression from reading the code. I have not had much
> experience in teaching any Ada GUI system to users. But I understand
> the CLAW code more easily than the GWindows code, because the CLAW
> code has better comments.

CLAW is good code, I've never claimed else. I've also never heard 
complaints from lack of documentation in the specs, but certainly open 
to add more where needed.

>> * GWindows shows good Ada design while demonstrating how to be
>> practical in design choices instead of Academic, ie. it is "real
>> world"
> 
> I think CLAW has a better design. But I guess that will always be a
> matter of opinion.

Perhaps. We would have to compare on specific metrics to really make a 
fair statement.

> 
> 
>> * GWindows integration of COM/DCOM/ActiveX/.NET using all Ada, no
>> C/C++ or MFC code needed (as in ObjectAda or older GWindows
>> releases)
> 
> That's _not_ GWindows, that's GNATCOM. As we have already established,
> CLAW can easily take advantage of that as well. Please be consistent
> in this discussion!

No, it is GWindows, what you are missing is that there needs to be 
support all the way around to do it right. That is why GWindows was 
created to start with (to be part of GNATCOM).

> 
>> * GWindows integration of Database support
> 
> That is a point. It looks easy to port to CLAW.

It is.

> 
>> * GWindows design for future integration in to a Delphi like
>> environment
> 
> It would be interesting to hear how CLAW lacks in this department.

Its reliance on only an inheritance model, but everything can always be 
worked around, the question is how easily.


> 
>> * GWindows offers UNICODE API support out of the box making it a
>> better choice for 64 Bit Windows, NT, 2000, XP and Longhorn - ie. the
>> ANSI API (and thus CLAW, the thin Win32Ada binding, GWindows ANSI
>> build, etc) should only be used where Win9X/ME is a must (and then one
>> should offer both binaries).
> 
> Hmm. I guess I haven't looked at the Unicode issue in CLAW. Clearly it
> could be added.

There is a lot of work involved and there are other similar issues.

> 
>> * GWindows can be used for windows CE programming as well if a cross
>> compiler was available
> 
> What prevents CLAW from doing that? Although I don't rank this high on
> a list of requirements.

UNICODE is the primary reason.

> 
>> * GWindows has always been MGPL'd
> 
> As CLAW is now (or will be soon, if we agree to start a community
> project with it).

CLAW is not currently, although a decent subset is. It is up to them, 
but I think they should make sure they have a solid financial model 
before going forward.


> 
>> and as such has always been very much alive even if I was not :-)
> 
> Well, that's not true. That's exactly why this whole discussion got
> started; there was no active support for GWindows, and we were
> discussing the best way to start a support group.

The list was dead for a few months granted, but development didn't stop either.

> 
>> * I have and attachment to the FSF's GNU/GPL philosophy and practice
>> and want to support such projects. (Despite being a Mr. Windows in the
>> Ada world, All of my own work and the majority of programming I do is
>> on Linux, Darwin and Mac OS X. GWindows was created to advocate Ada
>> and GPL/MGPL _not_ Windows, somehow that point always gets lost in the
>> sauce....)
> 
> Me too, but I'm not sure how it applies here. Once CLAW becomes
> GMGPL, it meets the same philosophical goals.

Time will tell. As I said GWindows is already doing it, GMGPL, new code 
being developed by different groups, etc. Given that there is not much 
that CLAW is going to add to what GWindows already is and that it is 
easier to port CLAW code to GWindows, seems smarter to push forward in 
that direction.

When dealing with volunteer efforts the bottom line is what your heart 
desires. From my perspective community code under GMGPL is good 
regardless of what base you start with. In the end if it looks good and 
some one wants it as part of their project they will port it in. So I 
would support any effort to have more code written.


>> * More than one set of GMGPL'd professional extensions has been made
> 
> I'm not clear how this is relevant.

ie. It is already happening even if there is not a lot of discussion 
about it publicly.

> 
>> * The GMGPL Claw version has been around for some time now yet no one
>> pushed to extend it, I expect that anything less than a full GMGPL
>> version of CLAW will mean the same lethargic response
> 
> I personally didn't work with CLAW because it was not GMGPL. Making it
> GMGPL changes that.

If it was GMGPL to start with I likely would have never written 
GWindows, but now that I have and the result is a solid open source 
framework that

> 
>> that despite the availability of many of my tools and some examples
>> that could have been used with out compromising lic.,etc. (as
>> pointed out by others) to give CLAW additional support where
>> GWindows was stronger.
> 
> There could be many reasons why your code was not added to CLAW; lack
> of customer demand, for one. Lack of clear title, for another;

Clear title exists at this point to the code, but at some point that 
may change as GWindows garners more community involvement.

> 
> CLAW has a goal of compiler independence; that's actually a point in its
> favor that I've forgotten to mention.

Not sure that matters so much these days, but I've seen ports of 
GNATCOM/GWindows to other compilers (at least one vendor even ships it 
AFAIK).

David Botton

Re: GWindows and David Botton

[David Botton]

I think that the problem we all suffer from is not enough users (and in 
particular knowledgeable users) of any Ada framework :-)

Anything that produces more of those is golden.

DB

> 
> But there was virtually no interest in it, so in the end we didn't bother to
> implement it. 

Re: GWindows and David Botton

[Alexander E. Kopilovich]

Stephen Leake wrote:

> There was a distinct feeling that the Ada community in general would
> benefit from going forward with only _one_ thick Windows binding,
> because that would enhance the level of support for that binding (both
> in terms of user experience and developers fixing problems and adding
> features). 

Don't you think that essentially the same feeling tells that it must be
better for society if it has exactly one political party, and not two or
three? And that it is wrong for essentially the same reasons.

You have to choose between that determinism and popularity. If you choose
determinism that stop lamenting about being unpopular. Such determinism may
be very effective in some aspects, but it can be popular for short time only
(and this time was over long ago for Ada), because broad community faces
too broad spectre of problems and circumstances.

But if we descend from those general speculations to more specific
essentials, we can notice, that while CLAW is an example of thick Ada
binding in its purpose, the proclaimed purpose of GWindows/GNAVI is
essentially different. The latter seems to strive to be not just another
classical Ada binding, but a Delphi-like thing (if you never tried Delphi
then you probably can't imagine what it means) - a tool with which your
program binds to rich objects, and that binding is not just to some API,
but explicitly involves ontology of those objects... so, it may be seen
as a binding at ontological level (at least partially).

I can't say that I believe that GWindows/GNAVI have bright perspective -
I have some doubts about it (and some of them relate to Ada language itself),
but the purpose is surely very attractive (whether it is attainable - this
is another matter). And I'm sure that even if GWindows/GNAVI succeed and
reach the level of Delphi 2/3 there still always will be a good place for
some classical Ada binding for Win32 - such as CLAW.




Alexander Kopilovich                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: GWindows and David Botton

[David Botton]

GNATCOM + GWindows is nearly complete vs. Delphi/ C++ Builder 2/3 VCL

The part left is the environment, not the framework per se. So I think 
it is very attainable and if things went different job wise a year and 
a half ago it would already be here.

David Botton



On 2004-10-06 00:19:52 -0400, "Alexander E. Kopilovich" 
<aek@VB1162.spb.edu> said:
> 
> I can't say that I believe that GWindows/GNAVI have bright perspective -
> I have some doubts about it (and some of them relate to Ada language itself),
> but the purpose is surely very attractive (whether it is attainable - this
> is another matter). And I'm sure that even if GWindows/GNAVI succeed and
> reach the level of Delphi 2/3 there still always will be a good place for
> some classical Ada binding for Win32 - such as CLAW.

Re: GWindows and David Botton

[Pascal Obry]

Stephen Leake <stephen_leake@acm.org> writes:

> Have they ever seen Emacs pcvs? That's far and away the best user
> interface to a CM tool I've ever seen.

pcvs, is that also called PCL-CVS ? If so I agree this is the best interface I
have seen.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GWindows and David Botton

[Marius Amado Alves]

An update of our little table incorporating the latest contributions. I 
have also put it in the Universal Casbah wiki at

http://www.liacc.up.pt/~maa / Casbah / Miscellany / GUIs_For_Ada

or

http://www.liacc.up.pt/~maa/cgi-bin/casbah/casbah.cgi?operation=view&pagename=GUIs_For_Ada

so that contributions can go there directly.

GUI/Windows products for Ada comparate
(C) Guys de Cla

Product    Binding    License  OSes       Install  Support  Remarks
-------------------------------------------------------------------
AdaBindX   C/Lesstif  GMGPL    B,L        (d)               (b)
IntroClaw  C/Win32    GMGPL    W          easy     free     (f)
FullClaw   C/Win32    prop     W          easy     com      (f)
Glade      GTK+       GPL      B,L,?      (d)               (a)
GtkAda     C/GTK+     GMGPL    B,L,M,S,W  (d)      com
GWindows   C/Win32    GMGPL    W
JEWL       Win32      free     W          easy
RAPID                                                       (c)
TASH       Tcl/Tk     GMGPL    B,W,L      (e)
Windex     Win32      GMGPL    W                   free
Win32      C/Win32    free     W
-------------------------------------------------------------------
(a) visual GUI builder and code generator (gate) for GtkAda
(b) binding to Xlib, Xt, and Xm (motif/lesstif)
(c) visual GUI builder
(d) Debian package
(e) Debian package no longer updated
(f) visual GUI builder available

Binding:
Underlying programming language / library.

License:
prop=proprietary

OSes:
B = BSD
L = Linux
M = MacOS
S = Solaris
W = Windows

Install:
easy = installs out of the box
hard = requires a guru

Support:
free = dedicated volunteer structure e.g. a maillist (not CLA)
com = commercial support
no = no support (but of course CLA continues to exist)
Append "/doc" if documentation exists (free)

* Threads in comp.lang.ada *

GTK
GWindows and David Botton

* URLs *

RAPID
ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.usafa.af.mil/pub/dfcs/

carlisle/usafa/rapid/index.html

Re: GWindows and David Botton

[David Botton]

I modified the Wiki reflecting that GWindows has "free" support, ie 
gnavi-list@gnavi.org

(I'll be offline until Sunday, but I am not disappearing :-)

David Botton


On 2004-10-06 14:56:55 -0400, Marius Amado Alves <amado.alves@netcabo.pt> said:

> An update of our little table incorporating the latest contributions. I 
> have also put it in the Universal Casbah wiki at
> 
> http://www.liacc.up.pt/~maa / Casbah / Miscellany / GUIs_For_Ada
> 
> or
> 
> http://www.liacc.up.pt/~maa/cgi-bin/casbah/casbah.cgi?operation=view&pagename=GUIs_For_Ada

so 
> 
> 
> so that contributions can go there directly.
> 
> GUI/Windows products for Ada comparate
> (C) Guys de Cla
> 
> Product    Binding    License  OSes       Install  Support  Remarks
> -------------------------------------------------------------------
> AdaBindX   C/Lesstif  GMGPL    B,L        (d)               (b)
> IntroClaw  C/Win32    GMGPL    W          easy     free     (f)
> FullClaw   C/Win32    prop     W          easy     com      (f)
> Glade      GTK+       GPL      B,L,?      (d)               (a)
> GtkAda     C/GTK+     GMGPL    B,L,M,S,W  (d)      com
> GWindows   C/Win32    GMGPL    W
> JEWL       Win32      free     W          easy
> RAPID                                                       (c)
> TASH       Tcl/Tk     GMGPL    B,W,L      (e)
> Windex     Win32      GMGPL    W                   free
> Win32      C/Win32    free     W
> -------------------------------------------------------------------
> (a) visual GUI builder and code generator (gate) for GtkAda
> (b) binding to Xlib, Xt, and Xm (motif/lesstif)
> (c) visual GUI builder
> (d) Debian package
> (e) Debian package no longer updated
> (f) visual GUI builder available
> 
> Binding:
> Underlying programming language / library.
> 
> License:
> prop=proprietary
> 
> OSes:
> B = BSD
> L = Linux
> M = MacOS
> S = Solaris
> W = Windows
> 
> Install:
> easy = installs out of the box
> hard = requires a guru
> 
> Support:
> free = dedicated volunteer structure e.g. a maillist (not CLA)
> com = commercial support
> no = no support (but of course CLA continues to exist)
> Append "/doc" if documentation exists (free)
> 
> * Threads in comp.lang.ada *
> 
> GTK
> GWindows and David Botton
> 
> * URLs *
> 
> RAPID
> ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.usafa.af.mil/pub/dfcs/
> 
> carlisle/usafa/rapid/index.html

Re: GWindows and David Botton

[Samuel Tardieu]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

Stephen> Is there an available, robustly supported server that
Stephen> provides TLA/arch access, like SourceForge does for CVS?

This is not the way GNU Arch is usually works.

In a GNU Arch world, someone (A) sets up a repository that he can
write and others can read (on its home ADSL connection for
example). He commits in it, possibly using branches, since they are
very easy to setup.

When another developer (B) wants to participate, he branches off (A)
repository, as branches are cross-repository. He makes its changes,
commits into his own publicly visible but private repository, possibly
with branches too. When his changes are ready and committed, (A) can
then merge the changes from (B) repository. Of course, in the
meantime, (B) may have merged some new changes from (A), but GNU Arch
takes care of all that and remembers what has been merged in a
repository.

What if (A) machine gets off the net? No problem: (B) can work on its
own, branching made a copy of (A) repository at the branch point.

If (C) wants to experiment with the project, he can do the same thing,
pull a version from (A), import some changes from (B) and add some of
his own in his own private publicly-visible repository. Then (A) and
(B) will both be able to pull (C) changes if they wish, GNU Arch being
able to sort out how to merge all that, as it knows about the versions
that have been merged at any time (this information is present in
every repository).

The way you use it is that you have a main integrator which is in
charge of the official release for the project. Everyone can work by
branching the official version and updating regularly from here. The
integrator pulls changes from workers' repository at will, test them
and adds them in the official repository.

If one part of the project requires special expertise, an expert can
setup his branch in his own private publicly-visible repository, and
take care of integrating changes concerning this area. The official
maintainer would then blindly merge changes from the expert.

This is *very* scalable. The learning curve is quite important, but
once you get used to it, you get a productivity never encountered with
tools like CVS, Subversion, PRCS (great branching but lacks network
capability).

Of particular interest are also Darcs and Monotone, but this is
another story :)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: GWindows and David Botton

[David Botton]

I also modified GWindows to Win32 not C/Win32. GWindows binds directly 
to the DLLs, COM Objects, etc. using Ada, no C in GWindows at all, not 
even for Active X controls.

David Botton


On 2004-10-06 16:07:20 -0400, David Botton <david@botton.com> said:

> I modified the Wiki reflecting that GWindows has "free" support, ie 
> gnavi-list@gnavi.org
> 
> (I'll be offline until Sunday, but I am not disappearing :-)
> 
> David Botton
> 
> 
> On 2004-10-06 14:56:55 -0400, Marius Amado Alves <amado.alves@netcabo.pt> said:
> 
>> An update of our little table incorporating the latest contributions. I 
>> have also put it in the Universal Casbah wiki at
>> 
>> http://www.liacc.up.pt/~maa / Casbah / Miscellany / GUIs_For_Ada
>> 
>> or
>> 
>> http://www.liacc.up.pt/~maa/cgi-bin/casbah/casbah.cgi?operation=view&pagename=GUIs_For_Ada

so


so 
>> 
> 
> so
>> 
>> 
>> so that contributions can go there directly.
>> 
>> GUI/Windows products for Ada comparate
>> (C) Guys de Cla
>> 
>> Product    Binding    License  OSes       Install  Support  Remarks
>> -------------------------------------------------------------------
>> AdaBindX   C/Lesstif  GMGPL    B,L        (d)               (b)
>> IntroClaw  C/Win32    GMGPL    W          easy     free     (f)
>> FullClaw   C/Win32    prop     W          easy     com      (f)
>> Glade      GTK+       GPL      B,L,?      (d)               (a)
>> GtkAda     C/GTK+     GMGPL    B,L,M,S,W  (d)      com
>> GWindows   C/Win32    GMGPL    W
>> JEWL       Win32      free     W          easy
>> RAPID                                                       (c)
>> TASH       Tcl/Tk     GMGPL    B,W,L      (e)
>> Windex     Win32      GMGPL    W                   free
>> Win32      C/Win32    free     W
>> -------------------------------------------------------------------
>> (a) visual GUI builder and code generator (gate) for GtkAda
>> (b) binding to Xlib, Xt, and Xm (motif/lesstif)
>> (c) visual GUI builder
>> (d) Debian package
>> (e) Debian package no longer updated
>> (f) visual GUI builder available
>> 
>> Binding:
>> Underlying programming language / library.
>> 
>> License:
>> prop=proprietary
>> 
>> OSes:
>> B = BSD
>> L = Linux
>> M = MacOS
>> S = Solaris
>> W = Windows
>> 
>> Install:
>> easy = installs out of the box
>> hard = requires a guru
>> 
>> Support:
>> free = dedicated volunteer structure e.g. a maillist (not CLA)
>> com = commercial support
>> no = no support (but of course CLA continues to exist)
>> Append "/doc" if documentation exists (free)
>> 
>> * Threads in comp.lang.ada *
>> 
>> GTK
>> GWindows and David Botton
>> 
>> * URLs *
>> 
>> RAPID
>> ftp://sunsite.informatik.rwth-aachen.de/pub/mirror/ftp.usafa.af.mil/pub/dfcs/
>> 
>> carlisle/usafa/rapid/index.html

Re: GWindows and David Botton

[tmoran]

> There may be individual APIs here and there in areas where CLAW has
> more or GWindows has more, but the key is that GWindows is  more than a
> binding while still being as close to the API as a binding with out
> losing ease of use and understandability.

> [Claw binding] that is 1) friendly to Ada programmers,
  Several years ago I tried changing an existing text mode program to Claw
Windows graphics, and a GtkAda program to Claw, as an ease of migration
test.  In both cases, IIRC, a single package body (dealing with the user
interface) was substantially changed, with little or no changes to any
specs or to the logic of the program.  The programs were Michael Feldman's
Dining Philosophers and Jeffrey Carter's Mine Detector.  To see the code,
or try the same experiment with other bindings, see
www.adapower.com/os/windmine.html, and the Diners example in
www.rrsoftware.com/html/prodinf/claw/clawinto.html

Re: GWindows and David Botton

[tmoran]

> I also modified GWindows to Win32 not C/Win32. GWindows binds directly
> to the DLLs, COM Objects, etc. using Ada, no C in GWindows at all, not
> even for Active X controls.
  Similarly for Claw, which has never had any C at all.

Re: GWindows and David Botton

[Stephen Leake]

Pascal Obry <pascal@obry.org> writes:

> Stephen Leake <stephen_leake@acm.org> writes:
> 
> > Have they ever seen Emacs pcvs? That's far and away the best user
> > interface to a CM tool I've ever seen.
> 
> pcvs, is that also called PCL-CVS ? 

yes.

> If so I agree this is the best interface I have seen.

Another point in common :).

-- 
-- Stephe

Re: GWindows and David Botton

[Ludovic Brenta]

Stephen Leake writes:
> If Meta-CVS is a purely client tool, then each developer can use it
> or not; it doesn't have to be a project-wide choice.

Yes, it has to be project-wide.  The way Meta-CVS works is this:

- every file in your source tree gets a unique ID

- every file is stored in the root directory of the module in the CVS
  server under that ID

- a separate text file establishes the mapping between the unique IDs
  and the path name of each file

- when you do a "mcvs checkout module", it creates a directory
  module/MCVS under which the flat directory structure is checked out,
  then it recreates the tree using the metadata file.  It uses hard
  links if the filesystem allows that, copies otherwise.

So, using Meta-CVS instead of CVS changes the file structure of the
server.  For example:

/var/lib/cvs/my_project:
-r--r--r--  1 lbrenta src    2811 2003-08-23 20:17 F-FFA4733D2CD1E8D430F20908D38BE0DE.ads,v
-r--r--r--  1 lbrenta src   12137 2003-08-23 20:17 F-FFAE5C4ABA0AF1F53C01902609AC2355.ads,v
-r--r--r--  1 lbrenta src   41326 2003-08-31 19:48 F-FFE3C9276E16694199815F68FAF5B7C0.adb,v
-r--r--r--  1 lbrenta src    3846 2003-08-31 19:48 F-FFFE9E8E3AEE3959A23BBE6EAEE0672A.adb,v
-r--r--r--  1 lbrenta src    6135 2003-08-31 19:48 F-FFFF334EDA1C38D47B5FB63CC0CDD729.adb,v
-r--r--r--  1 lbrenta src  366052 2003-08-31 19:48 MAP,v
-r--r--r--  1 lbrenta src    3300 2003-08-31 19:48 TYPES,v

You can of course use the regular CVS client, but it's not exactly
user-friendly :)

-- 
Ludovic Brenta.

Re: GWindows and David Botton

[Brian May]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

It sounds like Samuel Tardieu <sam@rfc1149.net> as more experience
then me at using TLA in large posts, so read his posts too. Some of my
thinking may still be CVS orientated, as most projects I use it there
is only one contributor (currently).

    Stephen> The question is whether the SourceForge servers are
    Stephen> running the TLA server software (I assume there is a
    Stephen> server executable?). As far as I know, they are not. Nor
    Stephen> does the typical user (that's us) have the permission to
    Stephen> run new code on the servers.

There is no such thing as a "TLA server" as such.

Instead it uses whatever server you currently have, e.g. apache, sftp,
etc.

All TLA needs is commands to retrieve given files, the client does the
rest of the work. For better support directory listed support is also
required, but there is an easy method to work around this for HTTP, by
putting the directory list into a downloadable file.

TLA, unlike CVS, doesn't require write access to the server, this
eliminates many security bugs with CVS in one go (last I heard
anonymous read-only CVS access has considered extremely insecure, as
CVS was never designed for anonymous access).

This means, to use TLA on sourceforge, all you need to do is dedicate
part of the sourceforge website for TLA, and mirror an official
repository onto a dedicated location on the sourceforge website.

Other alternatives may include using sftp to a read/write location on
sourceforge, or using <URL:http://alioth.debian.org/> (which is
Debian's version of sourceforge; I believe it has similar features but
also supports subversion and TLA).

    Stephen> Hmm. It seems somehow "wrong" to host a Windows project
    Stephen> on a Debian server :).

Nonsense. There is a special section for Microsoft products.  AFAIK,
The only requirement is that the project must be open source.

    Stephen> Do you have any insight into the reliability of alioth? I
    Stephen> know Debian in general strives for reliability over
    Stephen> wizzyness. But it is an all-volunteer organization. So
    Stephen> for our purposes, I think SourceForge is a better choice.

I can't really vouch for the reliability. I haven't heard of any major
issues for a long time now. It is easy to make copies of TLA archives
though, so if you a worried about reliability in terms of "I might
loose my work", keeping a backup on another server may be a good idea
(regardless of what server or source code revision system you use).

    Stephen> Ok, that would be useful in some situations. But I'm not
    Stephen> too worried about that sort of thing.

It seems like you should be. If somebody breaks into the sourceforge
server for instance, it is impossible to know what malicious damage
they may have done to what projects. You have to check each and every
line of source code in every repository. Even then, you need warning
that somebody broke in.

It was be nice if this wasn't an issue, unfortunately it is a real
problem.

In my previous posts, I completely forgot to mention a major advantage
- changesets. With CVS, when you check in a set of changes to multiple
files, the change to each file is considered separate. That means,
while in the middle of committing a large set of changes, somebody can
do an update and get a broken version. It also makes it harder to undo
specific changes, you need to work out all related files, and the
related versions first.

With TLA, each change is called a "changeset". A changeset can
incorporate changes (including file renames,deletions,additions) to a
set of files. This makes it easier to identify everything a developer
did in order to make a change. It is also a strict atomic unit, you
either get none of the changeset, or all of it.

Obviously, there is also a related learning curve here. To use this to
its maximum potential, it isn't a good idea to make numerous unrelated
changes, and commit them all at once. Instead you make "one distinct"
change at a time, and commit it. There are techniques to learn in case
you start making major changes, and find that there is an unrelated
bug you have to fix first. Also, knowing what a "distinct" change
means is a matter of personal judgement and experience.

    >> * It requires a new mind set, and old CVS concepts have to be
    >> forgotten and relearnt.

    Stephen> Hey, we want people to learn new concepts (Ada vs C,
    Stephen> etc); that's a plus :).

Agreed ;-).

    >> * It was built by a developer who hates Windows. As such,
    >> Windows support is still not official.

    Stephen> That's obviously a killer for an explicitly Windows-only
    Stephen> project.

Yes. Although may want to talk to the developers of the Windows ports
before deciding based on this point.

    >> * The lead developer likes command line tools, e.g. patch,
    >> reject files, etc. Some people may not like the absence of a
    >> GUI interface.

    Stephen> I need an Emacs interface. As in I won't use it without
    Stephen> one.

IIRC, the lead developer (Tom Lord) uses emacs. I would be surprised
if this hasn't been considered in detail...

The only emacs feature I use, is its built in ability to handy reject
files. (I am a vim fan <grin>).

    Stephen> Have they ever seen Emacs pcvs? That's far and away the
    Stephen> best user interface to a CM tool I've ever seen.

There seem to be a list of emacs interfaces at
<URL:http://wiki.gnuarch.org/moin.cgi/Additional_20Tools>, under the
"Emacs interfaces" section. Some look like they could be very
good. Sorry, I haven't used any.

    >> * Some commands are low level compared with other source code
    >> revision systems. There is no "annotate" command for example
    >> (although you can get it with add on software). There is no
    >> single command to compare two arbitrary versions (although
    >> comparing the current checked out version with the same version
    >> in the repository is easy; Also finding a list of change-sets
    >> that aren't in your checked out version is easy).

    Stephen> That's what the Emacs interface is for; you build
    Stephen> user-friendly front-end commands on top of the command
    Stephen> line primitives.

That probably largely explains the philosophy of the lead developer
(also an Emacs/LISP fan).
-- 
Brian May <bam@snoopy.apana.org.au>

Re: GWindows and David Botton

[Brian May]

>>>>> "Samuel" == Samuel Tardieu <sam@rfc1149.net> writes:

    Samuel> This is *very* scalable. The learning curve is quite
    Samuel> important, but once you get used to it, you get a
    Samuel> productivity never encountered with tools like CVS,
    Samuel> Subversion, PRCS (great branching but lacks network
    Samuel> capability).

Thanks for your excellent summary.

    Samuel> Of particular interest are also Darcs and Monotone, but
    Samuel> this is another story :)

I have never used these.

There are come comparisons between different tools (CVS included) at
the top of:

<URL:http://wiki.gnuarch.org/>
-- 
Brian May <bam@snoopy.apana.org.au>

Re: GWindows and David Botton

[Jerry van Dijk]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> Product    Binding    License  OSes       Install  Support  Remarks
> -------------------------------------------------------------------


> RAPID      TASH       GPL      Windows    Medium   None     (c) (x)(y)

(x) Generated UI code is not OS specific
(y) Generates code for TASH (tcl/tk), JGNAT (GNAT for Java), 
    GtkAda or A# (GNAT for .net)

-- 
--  Jerry van Dijk
--  Leiden, Holland
--
--  'Tradition is not the worship of ashes, but the preservation of fire.'
--                                               Gustav Mahler (1860-1911)

Re: GWindows and David Botton

[Benjamin Ketcham]

Ludovic Brenta <ludovic.brenta@insalien.org> wrote:
> Stephen Leake writes:
>> If Meta-CVS is a purely client tool, then each developer can use it
>> or not; it doesn't have to be a project-wide choice.
> 
> Yes, it has to be project-wide.  The way Meta-CVS works is this:

Oh goody, more layers.
Shouldn't it really be called "Meta-Meta-RCS"?

> - every file in your source tree gets a unique ID
> 
> - every file is stored in the root directory of the module in the CVS
>  server under that ID
> 
> - a separate text file establishes the mapping between the unique IDs
>  and the path name of each file
[...]

Seems eerily reminiscent of Win32 "long filenames"....

Don't get me wrong, I think CVS is a half-baked hack with some
amazing oversights and omissions.  (And is the documentation situation
still as frustrating?)  Still, it's the de facto standard half-baked
hack, and by now all the build-managers have written their own
personal versions of the scripts necessary to automate the common
operations that CVS overlooks or makes needlessly tedious/counterintuitive.
This "Meta-CVS" would seem much more appealing if it *were* purely
client-side; has anyone attempted CVS improvements that way (I mean more
than just GUI front ends)?

--Benjamin

Re: CVS front-ends

[Stephen Leake]

Benjamin Ketcham <bketcham@drizzle.com> writes:

> Ludovic Brenta <ludovic.brenta@insalien.org> wrote:
> > Stephen Leake writes:
> >> If Meta-CVS is a purely client tool, then each developer can use it
> >> or not; it doesn't have to be a project-wide choice.
> > 
> > Yes, it has to be project-wide.  The way Meta-CVS works is this:
> 
> Oh goody, more layers.
> Shouldn't it really be called "Meta-Meta-RCS"?
> 
> > - every file in your source tree gets a unique ID
> > 
> > - every file is stored in the root directory of the module in the CVS
> >  server under that ID
> > 
> > - a separate text file establishes the mapping between the unique IDs
> >  and the path name of each file
> [...]
> 
> Seems eerily reminiscent of Win32 "long filenames"....

Yes.

> Don't get me wrong, I think CVS is a half-baked hack with some
> amazing oversights and omissions. 

Ok.

> (And is the documentation situation still as frustrating?) 

I find the documentation adequate.

> Still, it's the de facto standard half-baked hack, and by now all
> the build-managers have written their own personal versions of the
> scripts necessary to automate the common operations that CVS
> overlooks or makes needlessly tedious/counterintuitive. 

Yes. That is the CVS philosophy; provide basic features, let people
write higher level tools that fit their process.

> This "Meta-CVS" would seem much more appealing if it *were* purely
> client-side; has anyone attempted CVS improvements that way (I mean
> more than just GUI front ends)?

I've written some small extensions to Emacs pcl-cvs (aka pcvs). In
particular, I have one function called cvs-dtrt, for "do the right
thing" :). Given the pcl-cvs display, it invokes the appropriate
action for the file under the cursor, or prompts the user if there is
more than one.

A minor function, but quite a productivity boost.

See http://www.toadmail.com/~ada_wizard/

-- 
-- Stephe

Re: CVS front-ends

[Matthew Heaney]

Stephen Leake <stephen_leake@acm.org> writes:

> 
> I've written some small extensions to Emacs pcl-cvs (aka pcvs). In
> particular, I have one function called cvs-dtrt, for "do the right
> thing" :). Given the pcl-cvs display, it invokes the appropriate
> action for the file under the cursor, or prompts the user if there is
> more than one.
> 
> A minor function, but quite a productivity boost.
> 
> See http://www.toadmail.com/~ada_wizard/

I'll check this out.

Potential Emacs users should also realize that you can do a lot of stuff
just with vc, which supports a variety of backends, including both CVS
and RCS.

Recently I've starting playing around with the vc command to change
backends, which allows me to use RCS to keep track of source changes
locally, when I'm off network (and hence unable to use CVS).

Re: CVS front-ends

[Pascal Obry]

Matthew Heaney <matthewjheaney@earthlink.net> writes:

> Recently I've starting playing around with the vc command to change
> backends, which allows me to use RCS to keep track of source changes
> locally, when I'm off network (and hence unable to use CVS).

You can use CVS locally too, or are you saying that you use the same CVS
repository with CVS when you are online and RCS (working directly with the
,v files) when offline ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: CVS front-ends

[Stephen Leake]

Pascal Obry <pascal@obry.org> writes:

> Matthew Heaney <matthewjheaney@earthlink.net> writes:
> 
> > Recently I've starting playing around with the vc command to change
> > backends, which allows me to use RCS to keep track of source changes
> > locally, when I'm off network (and hence unable to use CVS).
> 
> You can use CVS locally too, or are you saying that you use the same CVS
> repository with CVS when you are online and RCS (working directly with the
> ,v files) when offline ?

This feature of Emacs supports a remote CVS repository when connected,
_and_ a local RCS repository when disconnected. I forget how it synchs
when reconnecting, and I haven't actually used it, but it does sound
good.

-- 
-- Stephe

Re: CVS front-ends

[Pascal Obry]

Stephen Leake <stephen_leake@acm.org> writes:

> This feature of Emacs supports a remote CVS repository when connected,
> _and_ a local RCS repository when disconnected. I forget how it synchs
> when reconnecting, and I haven't actually used it, but it does sound
> good.

Well, it sounds quite risky to me ! The sync with the server seems very
delicate and probably works only if you are the only one using the
repository...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GWindows and David Botton

[Kaz Kylheku]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.199.1097016199.390.comp.lang.ada@ada-france.org>...
> Ludovic Brenta <ludovic.brenta@insalien.org> writes:
> 
> > I cannot help but think that CVS is the "C" of revision control
> > systems.  Ada programmers deserve better than that :)
> 
> I hadn't thought of it quite that way :).
> 
> > With Meta-CVS, one can get the best of everything: the SourceForge
> > CVS server and surrounding tools, without the annoying CVS
> > deficiencies.
> > 
> > At least, I think Meta-CVS is worth a look.
> 
> If Meta-CVS is a purely client tool, then each developer can use it or
> not; it doesn't have to be a project-wide choice.

Such a tool can't do the things that Meta-CVS can do. People have
played around with scripts to do things like simulate renaming over
standard CVS projects that can be fully checked out with a regular
client.

In the Meta-CVS project, I did not want to aim the guns that low into
the ground, but rather elevate the muzzle above the horizon.

I just wanted to reuse all of the behaviors that CVS does reasonably
well: namely keeping a vector of text documents synchronized between a
remote repository and a local sandbox, with support for parallel
editing, branching and merging.

In order for an element of this vector to retain its identity, while
changing its name and position within the filesystem tree, it is
necessary to represent that name and position as a separate property.
The name, as known to CVS, then just becomes an abstract identifier,
which might as well be based on some 128 bit number or something like
that.
 
The question is where to store the name? The simplest answer is to
store it in some other file which can also be versioned, and subject
to branching and merging.

This way, when you check out the database, all you have to do is parse
this file, and arrange the rest of the documents into a tree, which
can be done using efficient hard-linking operations, rather than bulk
transfer of data.

In fact, what Meta-CVS does is keep a farm of hard links so that it
has the original vector as checked out by CVS. CVS checkouts and
updates take place in this farm area. A restructuring algorithm
reshapes the tree by looking at the differences between the current
structure and the newly desired version. A simple synchronization
algorithm repairs any broken hard links between the tree and farm.

> I already use CVS for _everything_. While in general I'm in favor of
> learning new tools, in this case I'm sticking with CVS.

Meta-CVS is my way of expressing essentially the same attitude: I'm
sticking with CVS! Only I'm going to make it jump through hoops that
over years of CVS mailing list discussions declared impossible, that's
all. ;)