GWindows and a future home for it

GWindows and a future home for it

[Fionn mac Cuimhaill]

Has anyone done any more thinking about a home for GWindows? David
Botton seems to have fallen off the edge of the world, and it occursto
me that his  AdaPower web site could do the same thing. It occurs to
me that Adaworld would be a goot temporary location, even if it
eventually moves to Sourceforge or Tigris. That would supply a bit of
insurance in case Adapower's plug gets yanked, and would allow us tp
proceed with development and still have some time to build a consensus
on a future home for GWindows.

On another front - the proposed bug list. I have an item for it.
This might be described as a restriction rather than a bug; this is in
GWindows.Databases. I was using one of the Field_Value functions to
get a SQL Server datetime value into a variable of type Time (as
defined in Ada.Calendar).  The problem is that the range of dates that
can be expressed with a variable of type Time is too narrow, and one
of the GNATCOM routines which converts the date extracted from SQL
Server into a Time choked on a date with a year before 1901.

GNATCOM and GWindows need a calendar package similar to Ada.Calendar
which is based on a native Windows time representation.

Re: GWindows and a future home for it

[stephane richard]

Well if someone goes to sourceforge and registers a project for gwindows 
.... that can then be ready quickly enough....the problem is CVS ;-).  at 
least for me it is...if anyone has good experience with CVS for file 
checkins so we can trransfer the codebase to it by all means :-).

Not sure how long it will take to create everything..in the mean time (be it 
a week or a month or two :-) whichever I'll gladly host gwindows on my 
website until it's ready to send to sourceforge.

Mr Stephen Leake?  Sounds good to you?  hehehe..j/k


"Fionn mac Cuimhaill" <invisible@hiding.from.spam> wrote in message 
news:es6kl0pddjvs52ch5sd7hp69m8roimj8ih@4ax.com...
> Has anyone done any more thinking about a home for GWindows? David
> Botton seems to have fallen off the edge of the world, and it occursto
> me that his  AdaPower web site could do the same thing. It occurs to
> me that Adaworld would be a goot temporary location, even if it
> eventually moves to Sourceforge or Tigris. That would supply a bit of
> insurance in case Adapower's plug gets yanked, and would allow us tp
> proceed with development and still have some time to build a consensus
> on a future home for GWindows.
>
> On another front - the proposed bug list. I have an item for it.
> This might be described as a restriction rather than a bug; this is in
> GWindows.Databases. I was using one of the Field_Value functions to
> get a SQL Server datetime value into a variable of type Time (as
> defined in Ada.Calendar).  The problem is that the range of dates that
> can be expressed with a variable of type Time is too narrow, and one
> of the GNATCOM routines which converts the date extracted from SQL
> Server into a Time choked on a date with a year before 1901.
>
> GNATCOM and GWindows need a calendar package similar to Ada.Calendar
> which is based on a native Windows time representation. 

Re: GWindows and a future home for it

[Martin Krischik]

stephane richard wrote:

> Well if someone goes to sourceforge and registers a project for gwindows
> .... that can then be ready quickly enough....the problem is CVS ;-).  at
> least for me it is...if anyone has good experience with CVS for file
> checkins so we can trransfer the codebase to it by all means :-).

Here, Me! But the import is quite easy:

cd /work/gwindows
cvs -d :ext:user_id@cvs.sourceforge.net:/cvsroot/gwindows import -m
"Imported from David Botton" . V_David_Botton R_1_x_x

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: GWindows and a future home for it

[Chris Humphries]

Fionn mac Cuimhaill wrote:
> Has anyone done any more thinking about a home for GWindows? David
> Botton seems to have fallen off the edge of the world, and it occursto
> me that his  AdaPower web site could do the same thing. It occurs to
> me that Adaworld would be a goot temporary location, even if it
> eventually moves to Sourceforge or Tigris. That would supply a bit of
> insurance in case Adapower's plug gets yanked, and would allow us tp
> proceed with development and still have some time to build a consensus
> on a future home for GWindows.
> 
> On another front - the proposed bug list. I have an item for it.
> This might be described as a restriction rather than a bug; this is in
> GWindows.Databases. I was using one of the Field_Value functions to
> get a SQL Server datetime value into a variable of type Time (as
> defined in Ada.Calendar).  The problem is that the range of dates that
> can be expressed with a variable of type Time is too narrow, and one
> of the GNATCOM routines which converts the date extracted from SQL
> Server into a Time choked on a date with a year before 1901.
> 
> GNATCOM and GWindows need a calendar package similar to Ada.Calendar
> which is based on a native Windows time representation.

I have a couple servers in the DC here at work. If you need webhosting,
sure we could work something out (for free), I would also foot the bill
if there was one for hosting adapower.com or whatever else that may be
helpful to the Ada community.

Sourceforge seems like a better environment for projects, but general
web stuff, it would be cool.

Re: GWindows and a future home for it

[stephane richard]

"Chris Humphries" <chris@unixfu.net> wrote in message 
news:10llbal8s5i732c@news.supernews.com...
> I have a couple servers in the DC here at work. If you need webhosting,
> sure we could work something out (for free), I would also foot the bill
> if there was one for hosting adapower.com or whatever else that may be
> helpful to the Ada community.
>
> Sourceforge seems like a better environment for projects, but general
> web stuff, it would be cool.

That's a very generous offer Chris.  The next thing is to attempt to get in 
touch with David to get his website and contents so we can transfer them 
accordingly to your servers.  Technically, I'm a cowebmaster of adapower, 
however, In recent (and not so recent) reformats and upgrades I've lost 
paswords to access the website so many things I planned on changing I need 
to wait for the password to get it done.  I'm waiting on david to get the 
password again.  I might need to email him gain as I'm now not sure if he 
got my email(s) back then with all the problems I was having.  I'll try that 
again but before I wanna see how he's doing and what he thinks about moving 
the website to another server. Maybe see about transfer the adapower name as 
well :-).

Hopefully, David will read this too and email me the passwords etc etc....or 
with an email i'll get through to him and we can talk about this.

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

Re: GWindows and a future home for it

[Chris Humphries]

stephane richard wrote:
> "Chris Humphries" <chris@unixfu.net> wrote in message 
> news:10llbal8s5i732c@news.supernews.com...
> 
>>I have a couple servers in the DC here at work. If you need webhosting,
>>sure we could work something out (for free), I would also foot the bill
>>if there was one for hosting adapower.com or whatever else that may be
>>helpful to the Ada community.
>>
>>Sourceforge seems like a better environment for projects, but general
>>web stuff, it would be cool.
> 
> 
> That's a very generous offer Chris.  The next thing is to attempt to get in 
> touch with David to get his website and contents so we can transfer them 
> accordingly to your servers.  Technically, I'm a cowebmaster of adapower, 
> however, In recent (and not so recent) reformats and upgrades I've lost 
> paswords to access the website so many things I planned on changing I need 
> to wait for the password to get it done.  I'm waiting on david to get the 
> password again.  I might need to email him gain as I'm now not sure if he 
> got my email(s) back then with all the problems I was having.  I'll try that 
> again but before I wanna see how he's doing and what he thinks about moving 
> the website to another server. Maybe see about transfer the adapower name as 
> well :-).
> 

No problem :) I work for http://burst.net/ so it would be in their DC.
I have access name servers if you need them, and more ip addresses if
you would like.

> Hopefully, David will read this too and email me the passwords etc etc....or 
> with an email i'll get through to him and we can talk about this.
> 

Cool. Just let me know, so I can set it up. I can give more specific
details and you may give whatever requirements you need, should it come
to that :)

> Stephane Richard
> "Ada World" and "AdaPower" webmaster
> http://www.adaworld.com
> http://www.adapower.com
> 
> 
> 
> 
> 

Re: GWindows and a future home for it

[Stephen Leake]

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

> Has anyone done any more thinking about a home for GWindows? 

I was hoping we would have a more general discussion of whether
Gwindows is what we want to take forward.

I've been collecting names in this thread. Here's what I think is the
current situation:

Stephen Leake
    Willing to proceed with GWindows or Claw, preference for GWindows,
    because it is closer to Windex
    Will merge Windex into either.

Fionn mac Cuimhaill
    would like to proceed with GWindows
    not clear if Claw would be an acceptable option

Randy Brukardt
    would like to proceed with Claw; willing to make the full Claw
    open source
    Switching to GWindows not an option

Martin Dowie
    willing to help
    not clear whether he prefers GWindows or Claw

stephane richard
    willing to help
    either GWindows or Claw

Björn Persson
    has string encodings library that could be useful

Stephen McNeill
    willing to work on gwindows documentation
    not clear on whether Claw is acceptable

I apologize if I've got your opinion wrong, or if I've left someone out.

Could we get a vote from the above people, and any others that will
actually work on this project, on how to proceed? I think it's clear
we should set up a SourceForge project with either Claw or GWindows.
As others have pointed out, it's not hard to set up a SourceForge
project. I have extensive experience in CVS, and have run a project on
Savannah; I volunteer to be the first admin for the SourceForge
project (we should have at least two at all times).

So the vote is for:

1) Start a GWindows SourceForge project. Let Claw do its own thing.

2) Start a Claw SourceForge project. Let GWindows wither away.

3) Do something else. Please be specific!

> On another front - the proposed bug list. I have an item for it.
> This might be described as a restriction rather than a bug; this is in
> GWindows.Databases. I was using one of the Field_Value functions to
> get a SQL Server datetime value into a variable of type Time (as
> defined in Ada.Calendar).  The problem is that the range of dates that
> can be expressed with a variable of type Time is too narrow, and one
> of the GNATCOM routines which converts the date extracted from SQL
> Server into a Time choked on a date with a year before 1901.
> 
> GNATCOM and GWindows need a calendar package similar to Ada.Calendar
> which is based on a native Windows time representation.

I'll answer this in a separate thread, so we don't confuse things.

-- 
-- Stephe

Re: GWindows and a future home for it

[stephane richard]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
>stephane richard
>   willing to help
>    either GWindows or Claw

Now now Stephen, you know I pledged fidelity to Windex  ;-).....

Seriously if you're gonna merge it into either CLAW or GWindows then any 
would be good like you said.  Although over reading some claw docs, I gotta 
say I kinda became familiar with CLAW.  GWindows I never really looked at 
too much till recently. 

Re: GWindows and a future home for it

[Fionn mac Cuimhaill]

On 29 Sep 2004 20:03:07 -0400, Stephen Leake <stephen_leake@acm.org>
wrote:

>Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>
>> Has anyone done any more thinking about a home for GWindows? 
>
>I was hoping we would have a more general discussion of whether
>Gwindows is what we want to take forward.
>
>I've been collecting names in this thread. Here's what I think is the
>current situation:
>
>Stephen Leake
>    Willing to proceed with GWindows or Claw, preference for GWindows,
>    because it is closer to Windex
>    Will merge Windex into either.
>
>Fionn mac Cuimhaill
>    would like to proceed with GWindows
>    not clear if Claw would be an acceptable option
Dumping GWindows for Claw would require me to start over learning a
new set of packages, and would complicate maintenance of existing
software. Database support is essential. If Claw is weaker than
GWindows on database support, that is a major strike against it. I
would go for Claw only if it has database support equal to or better
than GWindows, good printing support and as good a set of
controls/widgets. A good point-by-point comparison of the two by
someone familiar with both would be desirable.
>
>Randy Brukardt
>    would like to proceed with Claw; willing to make the full Claw
>    open source
>    Switching to GWindows not an option
>
>Martin Dowie
>    willing to help
>    not clear whether he prefers GWindows or Claw
>
>stephane richard
>    willing to help
>    either GWindows or Claw
>
>Bj�rn Persson
>    has string encodings library that could be useful
>
>Stephen McNeill
>    willing to work on gwindows documentation
>    not clear on whether Claw is acceptable
>
>I apologize if I've got your opinion wrong, or if I've left someone out.
>
>Could we get a vote from the above people, and any others that will
>actually work on this project, on how to proceed? I think it's clear
>we should set up a SourceForge project with either Claw or GWindows.
>As others have pointed out, it's not hard to set up a SourceForge
>project. I have extensive experience in CVS, and have run a project on
>Savannah; I volunteer to be the first admin for the SourceForge
>project (we should have at least two at all times).
>
>So the vote is for:
>
>1) Start a GWindows SourceForge project. Let Claw do its own thing.
>
>2) Start a Claw SourceForge project. Let GWindows wither away.
>
>3) Do something else. Please be specific!
>
>> On another front - the proposed bug list. I have an item for it.
>> This might be described as a restriction rather than a bug; this is in
>> GWindows.Databases. I was using one of the Field_Value functions to
>> get a SQL Server datetime value into a variable of type Time (as
>> defined in Ada.Calendar).  The problem is that the range of dates that
>> can be expressed with a variable of type Time is too narrow, and one
>> of the GNATCOM routines which converts the date extracted from SQL
>> Server into a Time choked on a date with a year before 1901.
>> 
>> GNATCOM and GWindows need a calendar package similar to Ada.Calendar
>> which is based on a native Windows time representation.
>
>I'll answer this in a separate thread, so we don't confuse things.

David Gressett AKA Fionn mac Cuimhaill
res1nntf.radish@beet.verizon.broccoli.net  (remove vegetables to get
correct address)

Re: GWindows and a future home for it

[Nick Roberts]

Stephen Leake wrote:
> I was hoping we would have a more general discussion of whether
> Gwindows is what we want to take forward.
> 
> I've been collecting names in this thread. Here's what I think is the
> current situation:
> ...

Please add me to this list. I actually have my own design, now called 
Titian, which I have not yet published. Its design is quite well advanced, 
but not its implementation.

Titian is designed to be totally non-specific to any platform, and to be 
most suited to Ada 95, in terms of a package structure, naming style, and 
general simplicity, and is not at all derived from any pre-existing non-Ada 
design. It has a comprehensive object-oriented component model (plus an OO 
device model, an OO window model, and an OO 'window manager' model), and 
some innovations. It is readily extensible, and makes provision for 
programs to be able to automatically adapt to widely differing environments 
(hardware capabilities). There are two basic levels of functionality: 
simple raster-based graphics, suitable for desktop GUIs and 
embedded/turnkey systems; advanced scaled graphics, suitable for 
sophisticated desktop GUIs and graphics workstations.

I have done a very small amount of work on a Windows implementation; enough 
to show, I think, that such an implementation is highly viable. Obviously, 
my aim is to make an AdaOS implementation in due course.

I had intended to start a Titian SourceForge project in the near future. 
However, this might be a silly duplication of effort if a GWindows or CLAW 
continuation or successor project is going to be started.

Would anyone be interested in a brief rundown of Titian's design?

-- 
Nick Roberts

Re: GWindows and a future home for it

[stephane richard]

"Nick Roberts" <nick.roberts@acm.org> wrote in message 
news:2s2k77F1em754U1@uni-berlin.de...
> Stephen Leake wrote:
>> I was hoping we would have a more general discussion of whether
>> Gwindows is what we want to take forward.
>>
>> I've been collecting names in this thread. Here's what I think is the
>> current situation:
>> ...
>
> Please add me to this list. I actually have my own design, now called 
> Titian, which I have not yet published. Its design is quite well advanced, 
> but not its implementation.
>
> Titian is designed to be totally non-specific to any platform, and to be 
> most suited to Ada 95, in terms of a package structure, naming style, and 
> general simplicity, and is not at all derived from any pre-existing 
> non-Ada design. It has a comprehensive object-oriented component model 
> (plus an OO device model, an OO window model, and an OO 'window manager' 
> model), and some innovations. It is readily extensible, and makes 
> provision for programs to be able to automatically adapt to widely 
> differing environments (hardware capabilities). There are two basic levels 
> of functionality: simple raster-based graphics, suitable for desktop GUIs 
> and embedded/turnkey systems; advanced scaled graphics, suitable for 
> sophisticated desktop GUIs and graphics workstations.
>
> I have done a very small amount of work on a Windows implementation; 
> enough to show, I think, that such an implementation is highly viable. 
> Obviously, my aim is to make an AdaOS implementation in due course.
>
> I had intended to start a Titian SourceForge project in the near future. 
> However, this might be a silly duplication of effort if a GWindows or CLAW 
> continuation or successor project is going to be started.
>
> Would anyone be interested in a brief rundown of Titian's design?
>
> -- 
> Nick Roberts

I'd like that rundown :-).....brief or detailed ;-).  you can email it to me 
if you want.  Unless it's ok to post it here?  whatever's good with you.

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

Re: GWindows and a future home for it

[tmoran]

>Titian is designed to be ...
  That's a very good idea to explicitly state the design plan.
For Claw, see the TriAda paper online at
www.rrsoftware.com/html/prodinf/triadapaper/triada.html

Re: GWindows and a future home for it

[Stephen McNeill]

Stephen Leake <stephen leake@acm.org> wrote in message news:<mailman.134.1096502599.390.comp.lang.ada@ada-france.org>...

> Stephen McNeill
>     willing to work on gwindows documentation
>     not clear on whether Claw is acceptable
> 
> I apologize if I've got your opinion wrong, or if I've left someone out.
> 
> Could we get a vote from the above people, and any others that will
> actually work on this project, on how to proceed? I think it's clear
> we should set up a SourceForge project with either Claw or GWindows.
> As others have pointed out, it's not hard to set up a SourceForge
> project. I have extensive experience in CVS, and have run a project on
> Savannah; I volunteer to be the first admin for the SourceForge
> project (we should have at least two at all times).
> 
> So the vote is for:
> 
> 1) Start a GWindows SourceForge project. Let Claw do its own thing.
> 
> 2) Start a Claw SourceForge project. Let GWindows wither away.
> 
> 3) Do something else. Please be specific!
> 

I hate to admit it but option (2) has a compelling logic to it, much
as option (1) is in some ways personally preferable. I suspect the
maturity of Claw has to win out in the end.

I vote option (2).

Stephen

Re: GWindows and a future home for it

[stephane richard]

"Stephen McNeill" <mcneills@landcareresearch.co.nz> wrote in message 
news:116a1020.0409301417.34b73028@posting.google.com...

>> So the vote is for:
>>
>> 1) Start a GWindows SourceForge project. Let Claw do its own thing.
>>
>> 2) Start a Claw SourceForge project. Let GWindows wither away.
>>
>> 3) Do something else. Please be specific!
>>
>
> I hate to admit it but option (2) has a compelling logic to it, much
> as option (1) is in some ways personally preferable. I suspect the
> maturity of Claw has to win out in the end.
>
> I vote option (2).
>
> Stephen

It seems to me that CLAW has it's strenghts and GWindows has it's own set of 
strenghts. It's hard to vote per se here as I think they both have very 
distinct set of advantage I see myself using.  I'm also thinking about konad 
and another individual that have extensions to the GWindows library.  How 
would they feel if the majority went for option 2?

To me CLAW and GWindows should both survive...for both existing users of 
both libraries and I think that newcomers, depending on how and what they 
learned and worked with might prefer GWindows or CLAW over the other because 
fo the different approaches they both have.  For example, I'm thinking 
delphi programmers would probably like GWindows (at least from what I read 
here on this newsgroup) seems that the minding behind the library was 
somewhat similar. Perhaps VB programmers or others might prefer CLAW because 
of the way it's designed.

Now since this is a vote, it's hard to choose one or the other :-).  but 
today, with how things moved on for the past 8 months or so, I'd choose CLAW 
because it's actively in the game whereas GWindows is there for downloading 
:-).  So to help the voting, I vote for 2) too.

Re: GWindows and a future home for it

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.141.1096581654.390.comp.lang.ada@ada-france.org...
> Unfortunately, that's not available. You'll have to go look at the
> Claw sources, and see for yourself. I just did a grep in the free Claw
> for "database", and came up empty. Randy - any support in the full
> Claw?
>
> I agree database access is important. Currently, I'm using GNADE and
> GtkAda for a database application. So some of us will have to change,
> whichever standard we agree on.

We didn't do any database support, mainly because no one working on Claw has
much experience in that area. We decided to concentrate on the GUI, and do
the database stuff when we got around to it (and everyone knows how that
works).

The most recent list of types is found at:
http://www.rrsoftware.com/html/prodinf/claw/clawcl13.html
That list seems to omit the Rich Text edit control and the ListView family
of controls. (I'll have to update it ASAP.) ListView includes a generic unit
to create a table from a type and a set of accessor routines. It's a bit
messy to set up, but then it does all of the hard work.

Someone mentioned printing. The basic capability is the printer canvas,
which supports the basic start and end document and page operations, and
operations for setting up a cancel button. We had planned to build a
document architecture on top of that, but never had much demand. And the
Rich Edit control has built-in support for rendering pages, complete with
margins. (And it's easy to add headers and footers to the output.) That's so
trivial to use, I've never found a need to use anything more complex (just
create a hidden rich edit control, load it with your formatted document, and
use Print_Range in the loop to print it).

                                 Randy.

Re: GWindows and a future home for it

[Stephen Leake]

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

> Dumping GWindows for Claw would require me to start over learning a
> new set of packages, and would complicate maintenance of existing
> software. Database support is essential. If Claw is weaker than
> GWindows on database support, that is a major strike against it. 

I've just done a quick browse thru the GWindows.Databases package. It
does _not_ 'with' any other GWindows package. So we could rename it
Claw.Databases, or just keep it GWindows.Databases, and the
functionality is the same. 

GWindows.Databases.Controls does use some GWindows stuff, but only
base windows, text boxes, and buttons. That should port easily to
using Claw windows. On the other hand, there are not enough comments
in the code for me to be sure. That's a point in Claw's favor; better
comments, better documentation.

The GNATCOM stuff does not appear to be integrated with GWindows at
all; it's orthogonal, so it can be used with Claw easily.


My problem with Claw is it has a significantly different style than
Windex (which is pretty close to GWindows in style). Both code
formatting style, and general code design style. But I think I can get
used to it. And the full Claw clearly covers more of the Win32 API
than either Windex or GWindows.

So I vote for Claw, and one of the first things we do is agree on how
to port GWindows.Databases.Controls. 

-- 
-- Stephe

Re: GWindows and a future home for it

[stephane richard]

"Stephen Leake" <stephen_leake@acm.org> wrote in message 
news:mailman.143.1096594117.390.comp.lang.ada@ada-france.org...
> Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>
> I've just done a quick browse thru the GWindows.Databases package. It
> does _not_ 'with' any other GWindows package. So we could rename it
> Claw.Databases, or just keep it GWindows.Databases, and the
> functionality is the same.
>
> GWindows.Databases.Controls does use some GWindows stuff, but only
> base windows, text boxes, and buttons. That should port easily to
> using Claw windows. On the other hand, there are not enough comments
> in the code for me to be sure. That's a point in Claw's favor; better
> comments, better documentation.
>
> The GNATCOM stuff does not appear to be integrated with GWindows at
> all; it's orthogonal, so it can be used with Claw easily.
>
>
> My problem with Claw is it has a significantly different style than
> Windex (which is pretty close to GWindows in style). Both code
> formatting style, and general code design style. But I think I can get
> used to it. And the full Claw clearly covers more of the Win32 API
> than either Windex or GWindows.
>
> So I vote for Claw, and one of the first things we do is agree on how
> to port GWindows.Databases.Controls.
>
> -- 
> -- Stephe
>

Well if the GWindows dependencies are at a basic level as you said, text 
boxes and primitive windows controls like that, I think perhaps 
CLAW.Databases.Controls (controls here would use CLAW basic controls).  That 
is my opinion :-).

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

Re: GWindows and a future home for it

[Fionn mac Cuimhaill]

On 30 Sep 2004 21:28:27 -0400, Stephen Leake <stephen_leake@acm.org>
wrote:

>Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>
>> Dumping GWindows for Claw would require me to start over learning a
>> new set of packages, and would complicate maintenance of existing
>> software. Database support is essential. If Claw is weaker than
>> GWindows on database support, that is a major strike against it. 
>
>I've just done a quick browse thru the GWindows.Databases package. It
>does _not_ 'with' any other GWindows package. So we could rename it
>Claw.Databases, or just keep it GWindows.Databases, and the
>functionality is the same. 
>
>GWindows.Databases.Controls does use some GWindows stuff, but only
>base windows, text boxes, and buttons. That should port easily to
>using Claw windows. On the other hand, there are not enough comments
>in the code for me to be sure. That's a point in Claw's favor; better
>comments, better documentation.
>
>The GNATCOM stuff does not appear to be integrated with GWindows at
>all; it's orthogonal, so it can be used with Claw easily.
>
>
>My problem with Claw is it has a significantly different style than
>Windex (which is pretty close to GWindows in style). Both code
>formatting style, and general code design style. But I think I can get
>used to it. And the full Claw clearly covers more of the Win32 API
>than either Windex or GWindows.
>
>So I vote for Claw, and one of the first things we do is agree on how
>to port GWindows.Databases.Controls. 

I am willing to go with Claw if two things happen:

1. Database support can be made to happen very soon

2. The whole thing becomes open-source. I'm not including the GUI
builder here, just the Claw packages. This is important; if it doesn't
happen, I will not use Claw and will continue to develop GWindows.

Re: GWindows and a future home for it

[Marius Amado Alves]

Stephen Leake wrote:
> Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>>Database support is essential. If Claw is weaker than GWindows on
>>database support, that is a major strike against it....

Duh? Was the project not a GUI library? What that has to do with database?

(Could not find the original post by Fionn apud Stephen)

Re: GWindows and a future home for it

[Fionn mac Cuimhaill]

On Fri, 01 Oct 2004 11:48:36 +0100, Marius Amado Alves
<amado.alves@netcabo.pt> wrote:

>Stephen Leake wrote:
>> Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>>>Database support is essential. If Claw is weaker than GWindows on
>>>database support, that is a major strike against it....
>
>Duh? Was the project not a GUI library? What that has to do with database?
>
>(Could not find the original post by Fionn apud Stephen)

It was never just a GUI library problem - GWindows supplies both a GUI
library and a databae library, and I need and use both.

David Gressett AKA Fionn mac Cuimhaill
res1nntf.beet@okra.verizon.rutabaga.net (remove vegetables to get real
address)

Re: GWindows and a future home for it

[Marius Amado Alves]

>>>>Database support is essential. If Claw is weaker than GWindows on
>>>>database support, that is a major strike against it....
>>
>>Duh? Was the project not a GUI library? What that has to do with database?
>>
>>(Could not find the original post by Fionn apud Stephen)
> 
> It was never just a GUI library problem - GWindows supplies both a GUI
> library and a databae library, and I need and use both.

I also need both food and soap, but I don't keep them together :-)

So it seems what you want is a set of facilities for development of a 
certain class of applications. Not pressing at all but I'd love to see a 
description of it.

Otherwise it's like the Common Ada Library idea again.

What I liked in the forming GWindows/Claw project was that it seemed to 
be about one well defined and manageable area, GUI. Oh well...

Re: GWindows and a future home for it

[stephane richard]

"Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message 
news:mailman.146.1096645193.390.comp.lang.ada@ada-france.org...
>
>>>>>Database support is essential. If Claw is weaker than GWindows on
>>>>>database support, that is a major strike against it....
>>>
>>>Duh? Was the project not a GUI library? What that has to do with 
>>>database?
>>>
>>>(Could not find the original post by Fionn apud Stephen)
>>
>> It was never just a GUI library problem - GWindows supplies both a GUI
>> library and a databae library, and I need and use both.
>
> I also need both food and soap, but I don't keep them together :-)
>
> So it seems what you want is a set of facilities for development of a 
> certain class of applications. Not pressing at all but I'd love to see a 
> description of it.
>
> Otherwise it's like the Common Ada Library idea again.
>
> What I liked in the forming GWindows/Claw project was that it seemed to be 
> about one well defined and manageable area, GUI. Oh well...
>
Well whether it's GWindows, CLAW or GWindows And CLAW...it's still a GUI 
project.  We wouldn't coding databases, at least not creating it, it's 
already existent. 

Re: GWindows and a future home for it

[Chris Humphries]

stephane richard wrote:
> "Marius Amado Alves" <amado.alves@netcabo.pt> wrote in message 
> news:mailman.146.1096645193.390.comp.lang.ada@ada-france.org...
> 
>>>>>>Database support is essential. If Claw is weaker than GWindows on
>>>>>>database support, that is a major strike against it....
>>>>
>>>>Duh? Was the project not a GUI library? What that has to do with 
>>>>database?
>>>>
>>>>(Could not find the original post by Fionn apud Stephen)
>>>
>>>It was never just a GUI library problem - GWindows supplies both a GUI
>>>library and a databae library, and I need and use both.
>>
>>I also need both food and soap, but I don't keep them together :-)
>>
>>So it seems what you want is a set of facilities for development of a 
>>certain class of applications. Not pressing at all but I'd love to see a 
>>description of it.
>>
>>Otherwise it's like the Common Ada Library idea again.
>>
>>What I liked in the forming GWindows/Claw project was that it seemed to be 
>>about one well defined and manageable area, GUI. Oh well...
>>
> 
> Well whether it's GWindows, CLAW or GWindows And CLAW...it's still a GUI 
> project.  We wouldn't coding databases, at least not creating it, it's 
> already existent. 
> 
> 

Of course, if people had a problem with it, they are free to submit
their own patches :) Which is kind of nice.

I am more a selfish programmer, I don't end up coding anything unless
it is something that I need, which may be something that is additional
to an open source library. Then I will submit a patch. The library not
being 100% of what you want it out of the box, shouldn't stop anyone :)

Basically, if someone really wanted it, they could write it themselves.
One thing about opensource is the freedom to do this and the ability
to submit a patch and have it be included for others (if you wish).
Note I am not attacking anyone, just pointing out that if someone wanted
something, they could write it themselves.

A GUI library should just be for GUI stuff.
A DB library should just be for DB stuff.

It should then be up to the programmer (implementer of libraries) to
create the new api that is specific to their project(s). It is easy
to do, and seems an easier way to manage things.

Even QT requires external libraries for it's database stuff, it just
has a common api for using any database... Which could be easy to write
in Ada.

Not sure why this is such a big deal :)

My opinion is for both projects to be on their own cvs repositories,
and for the direction of the project be decided by those that write
the code :)

my 2 cents,
Chris

Re: GWindows and a future home for it

[Björn Persson]

Stephen Leake wrote:

> Björn Persson
>     has string encodings library that could be useful
[...]
> Could we get a vote from the above people, and any others that will
> actually work on this project, on how to proceed?

Well, I'll reply since you more or less asked me to, but I abstain from 
voting. I haven't used any Windows GUI library, and as long as I'm 
programming for fun I'm not likely to write anything Windows-specific. 
If anyone finds my code useful I'll be happy to answer questions and 
accept suggestions for improvements.

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

Re: GWindows and a future home for it

[AndreS]

I have been doing a lot of testing with the early releases of GWindows. The
reason why I started with GWindows was the way CLAW is designed. GWindows
is much closer to the WIndows API.

Another advantage of GWindows is that is GNU and not commercial like
CLAW.

So my vote is for GWindows.

When David Botton gives up the support of GWindows, I will volunteer to be
one of the engineers in the team to solve problems and implement
extentions (I am already using some extentions in my own private version
of GWindows).

The best way to create a community on GWindows is probably SourgeForce. I
think I can overcome the CVS problem.

By the way, did somebody already try to contact David Botton on this
issue?

If anyone likes to join me to continue the development of GWindows, please
send an e-mail.

Re: GWindows and a future home for it

[Ludovic Brenta]

Chris Humphries writes:
> A GUI library should just be for GUI stuff.
> A DB library should just be for DB stuff.

I agree.

From what I read in this thread, GWindows.Database can be split away
from GWindows, so that the issue of database is made orthogonal to the
issue of the GUI - this is the Tao of Programming.

There are, to my knowledge, three free DB libraries in Ada: GNADE, APQ
and GWindows.Database.  I don't know enough about all three to decide
how much they overlap, but they certainly do.  I leave it as an
exercise to the reader to decide if this is worth a vote :)

-- 
Ludovic Brenta.

Re: GWindows and a future home for it

[Georg Bauhaus]

AndreS <username.avsaway@provider.hotmail.com> wrote:
: I have been doing a lot of testing with the early releases of GWindows. The
: reason why I started with GWindows was the way CLAW is designed. GWindows
: is much closer to the WIndows API.
: 
: Another advantage of GWindows is that is GNU and not commercial like
: CLAW.

The free version of CLAW is GMGPL, as Randy Brukardt has recently
said in this thread. It has been for some time, IIRC.

And then, GPL and commercial or not are two dimensions. Redhat is
a commercial company, as are others who have based (part of) their
business on GPL software.  (As always, freedom, not price.)

-- Georg

Re: GWindows and a future home for it

[Randy Brukardt]

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:cjk6e6$t7h$1@a1-hrz.uni-duisburg.de...
> AndreS <username.avsaway@provider.hotmail.com> wrote:
> : I have been doing a lot of testing with the early releases of GWindows.
The
> : reason why I started with GWindows was the way CLAW is designed.
GWindows
> : is much closer to the WIndows API.
> :
> : Another advantage of GWindows is that is GNU and not commercial like
> : CLAW.
>
> The free version of CLAW is GMGPL, as Randy Brukardt has recently
> said in this thread. It has been for some time, IIRC.
>
> And then, GPL and commercial or not are two dimensions. Redhat is
> a commercial company, as are others who have based (part of) their
> business on GPL software.  (As always, freedom, not price.)

Right. RRS will still sell support and the GUI builder for Claw, along with
prepackaged versions of the bindings, whether or not the bindings are open
source. It's simply a matter of making that available to the community.

And the offer was to make the whole of the Claw bindings GMGPL. I have to
make a business case for doing that, but I think I can do so.

                     Randy Brukardt

Re: GWindows and a future home for it

[Marius Amado Alves]

> And then, GPL and commercial or not are two dimensions.

I wish people would stop saying this as if it were feasible to sell open 
source software. The original poster was, unfortunately, right. (Please 
note I know you can sell support, proprietary licenses, warranty, 
T-shirts and coffee mugs.) Alternatives at http://www.softdevelcoop.org

Re: GWindows and a future home for it

[Nick Roberts]

stephane richard wrote:

> I'd like that rundown :-).....brief or detailed ;-).  you can email it to me 
> if you want.  Unless it's ok to post it here?  whatever's good with you.

I've knocked up something very quick. I've actually tagged it in HTML, but 
never mind.

I admit that, because Titian's is relatively undeveloped, it's not much of 
a runner. Possibly the one redeeming feature is that Titian really is very 
platform-independent, and everything about it is done 100% 'the Ada way'.

The point is, if something like GWindows or CLAW is developed (on 
SourceForge, for example), I will have develop Titian on my own anyway 
(also probably on SourceForge), because (I presume) neither GWindows nor 
CLAW could sensibly be ported to a very unWindows-like platform such as AdaOS.



<div class="titian">



<h1>Titian Summary</h1>
<p>October 1, 2004</p>
<p><i>Nick Roberts</i></p>

<p>...</p>



<h2>Quick Glossary</h2>

<dl>

<dt>orthogonal rectangle</dt> <dd>a rectangle whose sides are parallel
with the vertical and horizontal axes (abbreviated to
<dfn>orthorect</dfn>)</dd>

<dt>RGBA</dt> <dd>red, green, blue, and alpha (one minus the
percentage of how much the corresponding background should show
through)</dd>

<dt>component</dt> <dd>a self-sufficient (to some extent) thing that is
drawn on the screen (or a hardcopy page), and may have other associated
characteristics</dd>

<dt>window manager</dt> <dd>the piece of software which is responsible for
operating the mechanics of a GUI</dd>

<!--

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

<dt></dt> <dd></dd>

-->

</dl>



<h2>Package Structure</h2>

<p>The most important packages are shown here. There are numerous sub-
packages containing auxiliary stuff.</p>



<h3><code>Titian</code></h3>

<p>Base package, with just a few fundamental declarations (e.g. the
floating-point types <code>Inches</code> and <code>Centimeters</code>).</p>



<h3><code>Titian.Color</code></h3>

<p>The type <code>Basic_Color</code>, which holds RGBA values, and a basic
set of operations. An abstract palette type, with operations for storing
and retrieving colours, and for quantization.</p>



<h3><code>Titian.Raster_IO</code></h3>

<p>Basic functions for raster graphic calculations (points, lines,
orthogonal rectangles) and relationships (comparisons) between them.</p>

<p>The fundamental abstract type <code>Root_Context_Type</code>, which
represents anything that can be drawn on (e.g. a device, such as a video
screen or printer, or a window), and a large set of abstract primitive
drawing operations.</p>

<p>Operations include drawing the following: point marks, in a variety of
styles (dot, cross, plus, etc.); straight lines (horizontal, vertical, and
general), in a variety of styles (dashed, dotted, etc.); orthogonal
rectangles, optionally filled or hatched, with special corners; irregular
polygons (closed), and circles and ellipses (whole, partial, or segment),
optionally filled or hatched; text, in a selected typeface, in any of four
90&deg; orientations, with optional decoration (underline, etc.); bit
images (BITBLT), with image format conversion (explicit and automatic).</p>

<p>Each drawing operation supports three colour models: direct colour;
colour selector; current colour. Direct colour specifies an RGBA value; if
the video display supports only a colour palette, the colour is inserted
into the palette automatically (triggering quantisation if necessary).
Colour selector specifies an entry in a palette; a software palette is
provided if the hardware does not support one; current colour uses a 'pen',
a default colour which can be set direct or by selector. This scheme makes
it easy for the application program to use the model (direct or palette)
which suits it best, and allows an application to explicitly support both
models if it is deemed necessary.</p>

<p>The intention is that only (non anti-aliased) raster fonts are supported
by this package &mdash; more sophisticated drawing operations are provided
by the (optional) <code>Titian.Scaled_IO</code> package subhierarchy
&mdash; but the operations are designed in such a way that the font
rendering mechanism is not constrained by the interface (so a native
renderer, which might have more sophisticated capabilities, can be used by
an implementation if it would make sense).</p>



<h3><code>Titian.Components</code></h3>

<p>Three abstract component types: for a root component; for a control
component; for an interactive component.</p>

<p>A root component has a few operations, the most important of which is
<code>Draw</code>. When a component is registered with a window manager, the
window manager calls its <code>Draw</code> procedure to cause it to draw (or
redraw) all or part of itself on the manager's screen (or page).</p>

<p>A control component is a component which displays some aspect of the
application program's conceptual model, usually on a continuously updating
basis. Whenever that aspect changes, the program should call the
component's <code>Invalidate</code> procedure. When a control component is
activated, its manager calls its <code>Draw</code> procedure in response to
this invalidation. Examples of control components are: progress bar; VU
meter.</p>

<p>An interactive component is a control component which is able to gain
and lose the <dfn>focus</dfn>. Normally, a window manager allows only one
component at a time to have the focus, and directs keyboard input to that
component. Examples of interactive components are: push button; checkbox
button; radio button; menu bar/panel; scrollbar.</p>



<h3><code>Titian.Windowing</code></h3>

<p>Root window type, and operations. Two basic abstract window types: root
window; workspace window. The root window type is the root for all window
types. A simple z-order priority model is supported. A workspace window has
all the decorations of a typical application window (border/frame, title
bar, menu bar, etc.), can gain focus, and has some extra operations to
support that.</p>

<p>Every window has an orthogonally rectangular area in it (corresponding
to the 'client area' of a Windows window), called its <dfn>canvas</dfn>,
which can be set to a component. The component thus implements the canvas
of the window. Typically, window types do not need to be specialised; a
standard window will suffice, whose canvas is set to an appropriately
specialised component. Since there are many components which have other
components inside them (e.g. a panel splitter), this tends to be the ideal
structure.</p>

<p>Root window manager type, and operations. Window managers can be opened
and closed by name (like device files); not availble on some
implementations (e.g. Windows and Mac) where there is only one default
manager. There is always a default manager (which is automatically opened
if necessary).</p>

<p>The operations for a window manager include a set of standard component
constructors, providing a repertoire of essential components for the
manager. These will usually be implemented by the corresponding default
components of the manager's implementation.</p>

<p>A virtual window manager type, which provides the functionality of an
MDI window (one which allows multiple inner windows), and operations.
Constructors for: standard bare window; standard workspace window; standard
virtual window manager (MDI) window.</p>



<h3><code>Titian.Fonts</code></h3>

<p>Facilities for manipulating fonts, including opening and loading
external fonts (font files) by name, and obtaining metrics.</p>



<h3><code>Titian.Raster_IO.Text_Formatting</code></h3>

<p>Facilities for formatting text strings, including horizontal and
vertical alignment. Provides an efficient way for the application program
to 'see' the formatting, and perhaps adjust it (or to do its own
formatting), before the formatted text is drawn. Also allows text to be
formatted once and redrawn many times.</p>

<p>I think the facilities provided in this package are much better designed
(and more accurately defined) than those Windows provides.</p>



<h3><code>Titian.Components.Utility</code></h3>

<p>Provides a variety of useful facilities to help with using components.
In particular, provides horizontal and vertical <dfn>autospacers</dfn>,
which make it easy to neatly align many components (e.g. in a dialog); they
will keep their alignment even if the containing box is resized.</p>

<p>My personal preference is to code the components of a dialog by hand (in
Ada), and use autospacers to do the formatting. However, autospacers could
be used in a visual design tool (very successfully, I think).</p>



<h3><code>Titian.Raster_IO.Recording</code></h3>

<p>Provides a virtual device (a type derived from the root device type), an
in-memory container which can record a sequence of drawing commands, and
then replay them (to another device). The sequence can be saved and loaded
to/from a stream.</p>



<h3><code>Titian.Raster_IO.Imaging</code></h3>

<p>Provides a virtual device (a type derived from the root device type), a
bitmap image type, whose format and dimensions are controlled by
discriminants, which can be drawn on as an in-memory canvas, and then
itself drawn onto another device.</p>



<!--

<h3><code>Titian.</code></h3>

<p>

</p>



<h3><code>Titian.</code></h3>

<p>

</p>



<h3><code>Titian.</code></h3>

<p>

</p>



-->

<h3><code>Titian.Clipboard</code></h3>

<p>Provides all the usual functionality associated with transferring data
by clipboard. Supports different named formats, and stream I/O to read and
write data. Also provides direct support for a few basic formats.</p>



<h3><code>Titian.Scaled_IO</code> subhierarchy</h3>

<p>This package subhierarchy provides facilities for drawing continuously
scaled figures and text on a raster device, including selectable
anti-aliasing for text and lines, support for continuously scalable fonts,
continuous scaling of raster images, bezier curves, and many other advanced
functions (e.g. support for JPEG and PNG).</p>

<p>This subhierarchy is intended to be optional. It should be supported on
desktop GUIs and graphics workstations, where it will be required by
typical applications (e.g. a PDF viewer). It can be omitted, however, for
target machines where its support would be unnecessary or impractical (e.g.
an EFTPOS terminal).</p>

<p>I haven't got as far as writing the package specifications for this
subhierarchy yet, but I've a pretty good idea how it should be.</p>



</div>

-- 
Nick Roberts

Re: GWindows and a future home for it

[tmoran]

> whether or not the bindings are open source.
It might be mentioned that Claw has always been open source, small 'o'
and small 's'.  That's much simpler for code that is supposed to run
with multiple compilers.

Re: GWindows and a future home for it

[Stephen Leake]

"AndreS" <username.avsaway@provider.hotmail.com> writes:

> I have been doing a lot of testing with the early releases of GWindows. The
> reason why I started with GWindows was the way CLAW is designed. GWindows
> is much closer to the WIndows API.

Could you comment more on that? Both seem like a pretty thick binding
to me. Claw has one Ada task that runs all the GUI stuff, but that's a
good idea anyway.

> Another advantage of GWindows is that is GNU and not commercial like
> CLAW.

If you mean CLAW is not GMGPL, that's now changed, as Randy said. As
for "commercial", the fact that Randy has customers willing to pay for
support for CLAW and related products is a plus, in my mind. GNAT is a
"commercial" compiler; that's why it is still around, and why it is so
good. 

> So my vote is for GWindows.

I hope you consider the points above, and browse the CLAW web site for
more info on the full CLAW. The more people we get behind one Windows
binding, the better.

> When David Botton gives up the support of GWindows, 

He has effectively done so; no one is able to contact him.

> I will volunteer to be one of the engineers in the team to solve
> problems and implement extentions (I am already using some
> extentions in my own private version of GWindows).

Good.

> The best way to create a community on GWindows is probably SourgeForce. I
> think I can overcome the CVS problem.

Yes, that is the plan.

> By the way, did somebody already try to contact David Botton on this
> issue?

Yes. See the beginnings of this thread.

-- 
-- Stephe

Re: GWindows and a future home for it

[Jeffrey Carter]

Randy Brukardt wrote:
> 
> Right. RRS will still sell support and the GUI builder for Claw,
> along with prepackaged versions of the bindings, whether or not the
> bindings are open source. It's simply a matter of making that
> available to the community.

If all of Claw becomes GMGPL, that would be my choice. A free version of 
an actively supported product is not likely to suffer GWindows' fate.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: GWindows and a future home for it

[Fionn mac Cuimhaill]

On Fri, 01 Oct 2004 16:39:44 +0100, Marius Amado Alves
<amado.alves@netcabo.pt> wrote:

>
>>>>>Database support is essential. If Claw is weaker than GWindows on
>>>>>database support, that is a major strike against it....
>>>
>>>Duh? Was the project not a GUI library? What that has to do with database?
>>>
>>>(Could not find the original post by Fionn apud Stephen)
>> 
>> It was never just a GUI library problem - GWindows supplies both a GUI
>> library and a databae library, and I need and use both.
>
>I also need both food and soap, but I don't keep them together :-)
>
I presume that you keep them in the same house. :-)
>So it seems what you want is a set of facilities for development of a 
>certain class of applications. Not pressing at all but I'd love to see a 
>description of it.
>
>Otherwise it's like the Common Ada Library idea again.
>
>What I liked in the forming GWindows/Claw project was that it seemed to 
>be about one well defined and manageable area, GUI. Oh well...
A perfectly reasonable intersection of GUI and database exists in the
form of database-bound controls, which GWindows has.

David Gressett AKA  Fionn mac Cuimhaill
res1nntf.potato@lettuce.verizon.net (remove vegetables to get correct
address)

Re: GWindows and a future home for it

[Fionn mac Cuimhaill]

On Fri, 01 Oct 2004 12:58:14 -0400, "AndreS"
<username.avsaway@provider.hotmail.com> wrote:

>I have been doing a lot of testing with the early releases of GWindows. The
>reason why I started with GWindows was the way CLAW is designed. GWindows
>is much closer to the WIndows API.
>
>Another advantage of GWindows is that is GNU and not commercial like
>CLAW.
>
>So my vote is for GWindows.
I'm glad to hear that.
>
>When David Botton gives up the support of GWindows, I will volunteer to be
>one of the engineers in the team to solve problems and implement
>extentions (I am already using some extentions in my own private version
>of GWindows).
>
>The best way to create a community on GWindows is probably SourgeForce. I
>think I can overcome the CVS problem.
>
>By the way, did somebody already try to contact David Botton on this
>issue?
I have tried to reach him; I get no responses to my e-mail messages;
he is apparently not making any attempt to read his e-mail.
>
>If anyone likes to join me to continue the development of GWindows, please
>send an e-mail.

Re: GWindows and a future home for it

[tmoran]

>>By the way, did somebody already try to contact David Botton on this
>>issue?
>I have tried to reach him; I get no responses to my e-mail messages;
>he is apparently not making any attempt to read his e-mail.
  The newest files on www.adapower.com appear to be dated a year ago.
I think David should be greatly thanked for all the work he did.  It
is unreasonable to expect anyone to continue donating substantial time
to the Ada community for nothing forever.

Re: GWindows and a future home for it

[James E. Hopper]

Not entirely true.  the mac ada group is hosted by David at

http://macada.og 

this is actually an adapower machine.  David has been very good to host
us and our files are updated fairly regularly.

jim

In article <pys7d.160558$D%.7859@attbi_s51>, <tmoran@acm.org> wrote:

> >>By the way, did somebody already try to contact David Botton on this
> >>issue?
> >I have tried to reach him; I get no responses to my e-mail messages;
> >he is apparently not making any attempt to read his e-mail.
>   The newest files on www.adapower.com appear to be dated a year ago.
> I think David should be greatly thanked for all the work he did.  It
> is unreasonable to expect anyone to continue donating substantial time
> to the Ada community for nothing forever.

Re: GWindows and a future home for it

[David Botton]

GWindows fate is actually not quite what you make it out to be. Since 
it is GMGPL it will likely die when Windows and Ada dies, not either 
one of us.

The proof is that I haven't been able to work on GWindows for a great 
deal longer than I care to admit (nor want to admit to myself) yet it 
is still being used for new projects and will be for many very serious 
projects to come since its only real weakness is in the occasional area 
of older Windows API it has not been bound to (easily reamedied) and 
its advantage is its ability to easliy be extended and make use and 
have code automatily generated via GNATCOM for parts of Windows that 
don't even exist yet.

David Botton


On 2004-10-01 20:45:11 -0400, Jeffrey Carter <spam@spam.com> said:
> 
> If all of Claw becomes GMGPL, that would be my choice. A free version 
> of an actively supported product is not likely to suffer GWindows' fate.

Re: GWindows and a future home for it

[Georg Bauhaus]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:
:> And then, GPL and commercial or not are two dimensions.
: 
: I wish people would stop saying this as if it were feasible to sell open 
: source software.

I didn't say that you could sell Free Software, only that licensed
source code and commercial source code are two different aspects.
Still, GPLed software plays its part in commercial
software enterprises. Other open source licenses do and did work
in commercial software enterprises. It just takes either reason,
or enough laywers, to explain to customers that source code /=
"gift", unless the contract says so.

If people continue to say that delivering source code cannot be
done when payment is wanted, it becomes a kind of self-fulfilling
prophesy, I think.

I find it important to spread the news (huh!) that
producing software is work; people are familiar with the idea of
paying craftspeople; software producers aren't too different from
craftspeople; so, pay them. Some companies do know this, so when
they need X they pay other companies' developers who produce X,
using an open source license.

Not everyone is an opportunistic free rider.

It may still take some time to realize that open source software needs
maintenance.  But without this learning experience (and failures,
for sure, that happens during learing) nothing changes.
If you hide the process, it cannot be seen, therefore it cannot
be understood.

-- Georg

Re: GWindows and a future home for it

[Marius Amado Alves]

Georg Bauhaus wrote:
> Marius Amado Alves <amado.alves@netcabo.pt> wrote:
> :> And then, GPL and commercial or not are two dimensions.
> : 
> : I wish people would stop saying this as if it were feasible to sell open 
> : source software.
> 
> I didn't say that you could sell Free Software, only that licensed
> source code and commercial source code are two different aspects.

Two dimensions, different aspects, these words imply that you can have
any combination of {open, close} * {free, charged} (one of them being
the unfeasible open and charged, unfeasible because the minute you open
it, someone will put a copy for free on the Internet, bye bye business).

> Still, GPLed software plays its part in commercial
> software enterprises.  Other open source licenses do and did work
> in commercial software enterprises.


> It just takes either reason,
> or enough laywers, to explain to customers that source code /=
> "gift", unless the contract says so.

No, by the contrary, once they understand exactly open source licenses,
changes increase they'll look for a "free ride" first.

> If people continue to say that delivering source code cannot be
> done when payment is wanted, it becomes a kind of self-fulfilling
> prophesy, I think.

No, the problem is rooted at open source treatment of code like a
physical object.

> I find it important to spread the news (huh!) that
> producing software is work; people are familiar with the idea of
> paying craftspeople; software producers aren't too different from
> craftspeople; so, pay them.

Absolutely. This is the spirit of the SDC alternative.

> Some companies do know this, so when
> they need X they pay other companies' developers who produce X,
> using an open source license.

Seldom.

> Not everyone is an opportunistic free rider.

Everyone wants to cut down expenditures.

> It may still take some time to realize that open source software needs
> maintenance.

No, people are not unaware of that, they simply can get it for free.

Right now the connection to Ada is thin, so please continue discussion
in the SDC forum or privately.

Re: GWindows and a future home for it

[Ludovic Brenta]

Marius Amado Alves writes:
> Two dimensions, different aspects, these words imply that you can
> have any combination of {open, close} * {free, charged} (one of them
> being the unfeasible open and charged, unfeasible because the minute
> you open it, someone will put a copy for free on the Internet, bye
> bye business).

Not true; look at Ada Core. Have you ever been able to get your hands
on GNAT Pro without paying for it?  And even if you did, that would
not stop Ada Core from doing business.

The same goes with Code Sourcery.  Mark Mitchell works for them and is
the release manager of GCC.

-- 
Ludovic Brenta.

Re: GWindows and a future home for it

[Randy Brukardt]

I wrote:

> Right. RRS will still sell support and the GUI builder for Claw, along
with
> prepackaged versions of the bindings, whether or not the bindings are open
> source. It's simply a matter of making that available to the community.
>
> And the offer was to make the whole of the Claw bindings GMGPL. I have to
> make a business case for doing that, but I think I can do so.

I should note that I'm going on a short vacation later this week, and it
doesn't appear that I'm going to have time to work on this before I go. (And
unlike many people, I go on vacation to get away from computers - I'm not
taking one or reading any e-mail.)

I'll try to do something on this front when I get back; it's long overdue to
get the GMGPL into the Intro distribution at the very least.

                     Randy Brukardt.

Re: GWindows and a future home for it

[Marius Amado Alves]

Ludovic Brenta wrote:

> Marius Amado Alves writes:
> 
>>Two dimensions, different aspects, these words imply that you can
>>have any combination of {open, close} * {free, charged} (one of them
>>being the unfeasible open and charged, unfeasible because the minute
>>you open it, someone will put a copy for free on the Internet, bye
>>bye business).
> 
> 
> Not true; look at Ada Core. Have you ever been able to get your hands
> on GNAT Pro without paying for it?  And even if you did, that would
> not stop Ada Core from doing business.

(Nice trick to keep the thread on topic :-)

As far as I know GNAT Pro is distributed under a proprietary license. 
So, irrelevant.

Re: GWindows and a future home for it

[David Botton]

No, GNAT Pro is distributed under exactly the same lic. as the public 
version, GPL and GMGPL.

There is a request to customers not to distribute the non-public 
versions, but that is it, not even a contractual obligation not to do 
so.

The advantages of the Pro version is ACT's support and the cutting 
edge. The public versions are usually the most tested and stable 
versions, would you want a lack of stability or bugs in the public eye.

David Botton


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

> 
> (Nice trick to keep the thread on topic :-)
> 
> As far as I know GNAT Pro is distributed under a proprietary license. 
> So, irrelevant.

Re: GWindows and a future home for it

[Marius Amado Alves]

David Botton wrote:
> There is a request to customers not to distribute the non-public 
> versions, but that is it, not even a contractual obligation not to do so.

Ah, yes, the request, sorry, it's not a proprietary license, it's a 
request. All is well in open source dreamland. (Pink hearts floating 
around.) But wait, you need a request, so open source licensing doesn't 
work, does it? Ah, bugger!

Re: GWindows and a future home for it

[Hyman Rosen]

Marius Amado Alves wrote:
> Ah, yes, the request, sorry, it's not a proprietary license, it's a 
> request. All is well in open source dreamland. (Pink hearts floating 
> around.) But wait, you need a request, so open source licensing doesn't 
> work, does it? Ah, bugger!

What exactly is the problem? Any piece of maintained software goes
through interim stages where it may have problems that render it
less than suitable for wide release. Also, a non-public release of
GNAT may have changes in it that were done for a particular customer
and platform, and have not been widely tested on other platforms. So
ACT requests that such releases not be publicly distributed.

ACT customers aren't generally in the compiler distribution business
themselves, so it's unlikely that they care, and if they need to, they
can redistribute the compiler regardless. But they're certainly under
no *obligation* to distribute to third parties. If you think GNAT Pro
should be publicly distributed, why don't you become a supported ACT
customer and do so?

Re: GWindows and a future home for it

[Marius Amado Alves]

Hyman Rosen wrote:

> Marius Amado Alves wrote:
> 
>> Ah, yes, the request, sorry, it's not a proprietary license, it's a 
>> request. All is well in open source dreamland. (Pink hearts floating 
>> around.) But wait, you need a request, so open source licensing 
>> doesn't work, does it? Ah, bugger!
> 
> What exactly is the problem?

The problem is that open source licensing is unadjusted to what you 
really want (which is usually to charge for certain uses of the 
software) or to a fair rewarding of the authors. And you must resort to 
subtrefugial, convoluted, parasitic commercial schemes like the 
"request" or dual licensing. The problem is that open source licenses 
treat the software like a physical thing. Maybe there is no unsolvable 
problem really, but it is so clear that the open source licensing is 
unadjusted and unfair, that now and then I just have to step in and try 
to shake those irritating pink hearts.

Re: GWindows and a future home for it

[Hyman Rosen]

Marius Amado Alves wrote:
> The problem is that open source licensing is unadjusted to what you 
> really want (which is usually to charge for certain uses of the 
> software) or to a fair rewarding of the authors.

ACT does not appear to be unhappy with using the GPL.
It uses it even for new products, such as GPS. So it
must be what they really want, or they wouldn't do it.

> And you must resort to  subtrefugial, convoluted, parasitic commercial
 > schemes like the "request" or dual licensing.

When I buy toys, they often come labeled with warnings that they contain
small parts and are thus unsuitable for children under age three. When my
son was younger than three, sometimes I would let him have these toys
anyway, and sometimes I would not, depending on my judgement as to their
safety. The labels absolved the toy company from responsibility for use
of the product in a way they deemed unsuitable, while allowing me the
freedom to use them as I wished. None of the adjectives you use apply to
this circumstance, nor to the similar labels on GNAT Pro. ACT maintains
that versions of GNAT Pro are suitable for the customer who gets them,
and not necessarily for the public at large, because development and
testing are done for particular customers on particular platforms. Anyone
who chooses to disregard this is perfectly free to do so, but then ACT
takes no responsibility for the suitablity of the results.

> The problem is that open source licenses treat the software like a physical
 > thing. Maybe there is no unsolvable problem really, but it is so clear that
 > the open source licensing is unadjusted and unfair, that now and then I just
 > have to step in and try to shake those irritating pink hearts.

Apparently the authors do not find it unfair, since they persist in making
more free software. Apparently their paying customers are satisfied, since
they are in fact paying. As far as I can tell, everyone is perfectly satisfied
with these arrangements, except for people who seem to want the benefits of
being an ACT customer without actually becoming one.

Re: GWindows and a future home for it

[Marius Amado Alves]

Hyman Rosen wrote:
>> And you must resort to  subtrefugial, convoluted, parasitic commercial
>> schemes like the "request" or dual licensing.
> 
> [toy story] None of the adjectives you use apply to
> this circumstance, nor to the similar labels on GNAT Pro. ACT maintains
> that versions of GNAT Pro are suitable for the customer who gets them,
> and not necessarily for the public at large, because development and
> testing are done for particular customers on particular platforms. Anyone
> who chooses to disregard this is perfectly free to do so, but then ACT
> takes no responsibility for the suitablity of the results.

If this is the only purpose of the request, "no warranties", then I 
stand corrected on the issue of GNAT Pro licensing.

> Apparently the authors do not find it unfair, since they persist in making
> more free software. Apparently their paying customers are satisfied, since
> they are in fact paying. As far as I can tell, everyone is perfectly 
> satisfied with these arrangements.

Excelent. As I said, "all is well in open source dreamland".

, except for people who seem to want the benefits of
> being an ACT customer without actually becoming one.

Please don't put intentions on my mind. I'm simply discussing software 
licensing. Some people have left open source dreamland. They are 
gathering at the SDC and other places. They have posted articles there 
explaining why dual licensing is parasitic. And the other adjectives.

Re: GWindows and a future home for it

[Georg Bauhaus]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:
 
: The problem is that open source licensing is unadjusted to what you 
: really want (which is usually

Care to elaborate? How do you measure "usually"?

: to charge for certain uses of the 
: software) or to a fair rewarding of the authors.

Could it be that you have a problem selling _your_ software, imagining?
an open source license ? Fear of giving away your produce and getting
nothing back? Your choice, there is no universal law that requires all
software to be Free Software.

Obviously empirical facts do show that there are both closed source
and open source licensing schemes, as well as mixed schemes. The
president of AdaCore has said, on c.l.ada, that you, Marius, could
pick GNAT and build a business around it. How do you _define_
business?

1  "protect your secrets and sell a license to use",
2  "show what you've got, in source, but not publicly, and charge money"
3  "make both sources and binaries freely available and charge for support."
4  "make binaries freely availably and influence people to
    become dependent on more expensive binaries later (MS technique)"
...

If you can't live with 3 then this is your choice. No need to resort
to pink hearts. (Obviously others differ successfully.)
For serious use of most software products other than consumer
products for those kids who have been brought up with software "sharing",
you are well advised to buy support anyway, no? So what empirical facts
can you show that there is no way to build a business around 
the mentioned licensing models, including GPLed software?

As for a request not to give newer compilers away, unstable
wave front products so to speak, who wants them?
Fans who must have the latest and greatest? And, please,
real data if you have.

Many recent additions to GNAT are available in
GCC, the GPS snapshot binaries have recent source code in them,
the latest Ada enabled GDB is available from the libre site,
so what's your point?

-- Georg

Re: GWindows and a future home for it

[Marius Amado Alves]

Georg Bauhaus wrote:

> [a lot on software licensing]

The SDC site contains articles and links to articles explaining all 
this. The gist of Fair Source is: the source code is released openly and 
publicly, but commercial use must cut a deal. We believe in this model 
being more fair to authors than open source, and even being more true to 
the open source spirit, than the existing open source licenses. 
Sometimes I step in when I see indication that people are not aware of 
these issues. Sorry if I stepped in too strongly this time.

Re: GWindows and a future home for it

[Hyman Rosen]

Marius Amado Alves wrote:
> The SDC site contains articles and links to articles explaining all 
> this. The gist of Fair Source is: the source code is released openly and 
> publicly, but commercial use must cut a deal. We believe in this model 
> being more fair to authors than open source, and even being more true to 
> the open source spirit, than the existing open source licenses.

It is definitely not true to the free software spirit,
as espoused by the FSF. And the practical problems of
such "fair source" licenses will doom them. This is
exactly the same issue that doomed Microsoft's SenderID
proposal - the requirement that downstream users, no
matter how many generations removed, must locate and get
licensing for the full set of fair source pacakages that
are incorporated in the program. The weight of legal and
accounting requirements to track these is just as heavy
as for closed-source packages. Note in contrast how simple
the GPL is - you simply distribute under its terms. No one
must be located, no licensing must be negotiated.

Just because some programmer wants to make money does not
obligate anyone else to march to his drumbeat. If using
his software involves procedural and finacial annoyance,
then it's far simpler not to use it.

Re: GWindows and a future home for it

[Marius Amado Alves]

Hyman Rosen wrote:

> ... the practical problems of
> such "fair source" licenses will doom them.
 > ... The weight of legal and
> accounting requirements to track these is just as heavy
> as for closed-source packages.

In that case I see no problem, because proprietary software does not 
seem to be suffering from this :-)

Of course managing shares in fair source is more complicated than in 
open source--where there are none. But we think it can be done, and 
we're working toward putting some tools in place for it. See for example 
the Relative Credit Scheme and the respective provisions in Bob Leif's 
Ada Developers Cooperative License.

> ... Just because some programmer wants to make money does not
> obligate anyone else to march to his drumbeat.

Well, you can just say it the other way around: if some programmer does 
not want to make money...

Anyway in fair source any author can forfeit his right to be rewarded.

Thanks for your time and knowledge. I'll take a look at the Id Sender 
business.

Re: GWindows and a future home for it

[Hyman Rosen]

Marius Amado Alves wrote:
> In that case I see no problem, because proprietary software does not 
> seem to be suffering from this :-)

Proprietary software doesn't have the additional complication of
allowing intermediate non-commercial use. And I doubt that most
commercial software incorporates many small separately licensed
components.

> Thanks for your time and knowledge. I'll take a look at the Id Sender 
> business.

Microsoft claims to have applied for patents on the SenderID
technology. They were offering to license these royalty-free,
but each vendor/implementor was required to individually get
such a license from Microsoft. Naturally, this is a problem
for open source, where the distinctions between implementor,
vendor, and user may be non-existent. The proposal was not
accepted as an IETF standard.

Re: GWindows and a future home for it

[Stephen Leake]

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

> Ludovic Brenta wrote:
> 
> > Marius Amado Alves writes:
> >
> >>Two dimensions, different aspects, these words imply that you can
> >>have any combination of {open, close} * {free, charged} (one of them
> >>being the unfeasible open and charged, unfeasible because the minute
> >>you open it, someone will put a copy for free on the Internet, bye
> >>bye business).
> > Not true; look at Ada Core. Have you ever been able to get your hands
> > on GNAT Pro without paying for it?  And even if you did, that would
> > not stop Ada Core from doing business.
> 
> (Nice trick to keep the thread on topic :-)
> 
> As far as I know GNAT Pro is distributed under a proprietary license.
> So, irrelevant.

You are incorrect. The GNAT Pro toolset is covered by the same GMGPL
license as the public version. There is an informal understanding
among supported customers that it is not appropriate to distribute the
Pro version to unsupported people, because it is _not_ ready for
unsupported use.

-- 
-- Stephe

Re: GWindows and a future home for it

[stephane richard]

"Stephen Leake" <stephen_leake@acm.org> wrote in message 
news:mailman.228.1097108872.390.comp.lang.ada@ada-france.org...
>
> You are incorrect. The GNAT Pro toolset is covered by the same GMGPL
> license as the public version. There is an informal understanding
> among supported customers that it is not appropriate to distribute the
> Pro version to unsupported people, because it is _not_ ready for
> unsupported use.
>
> -- 
> -- Stephe
>
By that do you mean that customers could customize GNAT Pro with whatever 
extensions and that's what they're not allowed to distribute or at least 
it's the reason why they're not allow to distribute GNAT pro themselves?  if 
so it makes sense.  I might not want to test a new thing some customer added 
to their gnat pro...;-) 

Re: GWindows and a future home for it

[Robert C. Leif]

   I appreciate Marius' kind words.
   I apologize in advance for the length of my comments.  
   An example of the source of my continuing motivation to foster the
development of commercial products occurred today. FrameMaker 7.1 document
processor further increased my motivation when it unsuccessfully tried to
produce a Word file and scrambled some cross-references in the original file
of my latest chemistry patent application. For me this is a mission critical
application. In case anyone is interested, the cross-referencing and column
numbering technology in Word are unsuitable for this task.  Since FrameMaker
is expensive, my use of it establishes that like most scientists, I am
motivated to spend money on products. Lawyers and physicians also need
reliable products. 
   Previously, having been depressed by Ada's lack of commercial success and
frustrated by the unreliable and poor software I use at work (see above), I
came up with the obvious way to increase the commercial use of Ada; it was
to apply the old American adage, "Money talks". A few Ada millionaires would
be the best counterargument to the C group of languages aficionados. 
   One simple business observation about the largest software corporation,
Microsoft, is that the company has very nice buildings and treats its
employees very well. In short, there is a very significant overhead and
salary component in its costs. 
   Ada technology fortunately provides a means to eliminate most of the
corporate building and overhead costs and to change the economic model of
software development from a centralized to a decentralized structure.  In
fact, Randy Brukardt and Tom Moran have demonstrated with CLAW the
feasibility of distributed Ada development. I believe that with Ada because
of its readability, use of separate specifications, etc. the scaling from 2
developers to 100 or 1,000 distributed developers is possible. Ada also has
the advantage that the number of developers required is inversely
proportional to their productivity. However, these technological advantages
do not provide a sufficient business case for the use of Ada.
   The use of Ada has the very large commercial advantage in that an ASIS
program can be created that divides up the royalties paid to the developers.
This will remove very significant legal and accounting costs as well as
upfront capital investment. A software based method to calculate
compensation will permit the use of down-stream and evolved or mutated
software components. If a product is successful, it will assure the upstream
developers obtain a good return for their initial effort.
   As we all know, software design is a critical component. Frankly, it
would be a very high-risk undertaking to start a business composed of
software experts who had minimal domain knowledge of a commercial product.
   However, this risk factor is mitigated by the use of existing
well-thought-out designs. We are now well along in what is an XML centric
market. If we build products that are based on the World Wide Web Consortium
standards, much of the design and domain knowledge problems are mitigated.
This type of development is further simplified by the semantic similarity
between Ada and XML schema.  I also have a gut feeling that Ada program
designers would realize that there was significant commonality between a
table in document and a spreadsheet. I suspect that a simple object based
design could result in much smaller and fast packages.
   Since we already have the Commercial Ada Users Working Group (CAUWEG), I
can think of no better aim for CAUWEG than the commercial use of Ada.
   Yours,
   Bob Leif
   
   
   Message: 4
   Date: Wed, 06 Oct 2004 22:28:36 +0100
   
   From: Marius Amado Alves <amado.alves@netcabo.pt>
   Subject: Re: GWindows and a future home for it
   To: comp.lang.ada@ada-france.org
   Message-ID: <41646384.6030805@netcabo.pt>
   Content-Type: text/plain; charset=us-ascii; format=flowed
   
   Hyman Rosen wrote:
   
   > ... the practical problems of
   > such "fair source" licenses will doom them.
    > ... The weight of legal and
   > accounting requirements to track these is just as heavy
   > as for closed-source packages.
   
   In that case I see no problem, because proprietary software does not 
   seem to be suffering from this :-)
   
   Of course managing shares in fair source is more complicated than in 
   open source--where there are none. But we think it can be done, and 
   we're working toward putting some tools in place for it. See for example 
   the Relative Credit Scheme and the respective provisions in Bob Leif's 
   Ada Developers Cooperative License.
   
   > ... Just because some programmer wants to make money does not
   > obligate anyone else to march to his drumbeat.
   
   Well, you can just say it the other way around: if some programmer does 
   not want to make money...
   
   Anyway in fair source any author can forfeit his right to be rewarded.
   
   Thanks for your time and knowledge. I'll take a look at the Id Sender 
   business.

Re: GWindows and a future home for it

[Marin David Condic]

Or is it pastel unicorns and gumdrops with flying pixies sprinkling gold 
dust all over everything. :-) If all it is is a "request", one would 
think that at least one customer might have said "No" and put the whole 
suite of things up on a website somewhere. As far as I know, the only 
stuff that is generally available is the stuff that ACT chooses to 
release publically whenever they choose to release it. Have they put out 
any of their cross-targeted compilers or other spiffy stuff, or are they 
just putting out the general things that are older and no longer 
generate serious revenue?

Mind you, I don't object. Its their software and they have every right 
to put whatever restrictions on it they like. ACT needs to make a profit 
and its pretty hard to sell something to someone if they can get the 
same thing free. "Open Source" in its more zealous form is not what is 
happening here. ACT is giving away older products that can no longer be 
milked for large volumes of cash with the hope of expanding their market 
share. Theres nothing wrong with that - it just means that software is 
intellectual property that costs money to develop and it has economic value.

MDC

Marius Amado Alves wrote:
> 
> Ah, yes, the request, sorry, it's not a proprietary license, it's a 
> request. All is well in open source dreamland. (Pink hearts floating 
> around.) But wait, you need a request, so open source licensing doesn't 
> work, does it? Ah, bugger!
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Power corrupts.  Absolute power is kind of neat"
         -- John Lehman, Secretary of the Navy 1981-1987
======================================================================

Re: GWindows and a future home for it

[Georg Bauhaus]

Marin David Condic <nobody@noplace.com> wrote:

:  or are they 
: just putting out the general things that are older and no longer 
: generate serious revenue?

I don't think it is old stuff. If you look at ChangeLog.GNAT
in the publicly available GDB repository at ACT Europe's libre
site, you can see a list of additions, the latest entries are
only a few days old. Are you speculating?

-- Georg

Re: GWindows and a future home for it

[Warren W. Gay VE3WWG]

Ludovic Brenta wrote:
> Chris Humphries writes:
> 
>>A GUI library should just be for GUI stuff.
>>A DB library should just be for DB stuff.
> 
> I agree.
> 
> From what I read in this thread, GWindows.Database can be split away
> from GWindows, so that the issue of database is made orthogonal to the
> issue of the GUI - this is the Tao of Programming.
> 
> There are, to my knowledge, three free DB libraries in Ada: GNADE, APQ
> and GWindows.Database.  I don't know enough about all three to decide
> how much they overlap, but they certainly do.  I leave it as an
> exercise to the reader to decide if this is worth a vote :)

I am going to stick my neck out here to David's benefit without
actually looking at his Database support. Based upon what I have
seen from Delphi and even MFC's database support, you _do_ need
to integrate the two to some degree, if you want to reduce the
enormous amount of grunt work that is involved (Microsoft's MFC
approach uses a lot of C++ macro glue).

Yes, you can make the two totally separate, but this comes
at an incredible cost. It means that every time you bring up a screen full
of new column data, every stinken widget now must be coded for to
transfer from the query to the widget. When you want to save
changes, or save a new row of data, you have the reverse issue.
You must code for every stinken widget to get values from widgets
to the database for the update/insert operation. Very very messy
and time consuming. Surely there is a better, less error prone
way.

So I applaud efforts like David's, to make this a whole lot easier
and transparent. I never got into Delphi in a big way, but I could
see the advantages of their approach, from my past exploratory
experiences with it. Delphi did allow you to specify how to load
a combo control for example, from a database table. Simple to
talk about, but very gruntish to code for every widget.

So I would suggest to anyone that thinks that the GUI and DB can
be totally separate, to go and write a simple update screen with
15 or so I/O widgets containing values. You'll come away with that
experience thinking "there has to be an easier way". I believe that
is the direction that David is going (or has been). You should
reconsider what you are asking for. ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg