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

[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

[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

[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

Re: Coupling or not coupling database and GUI libraries (was: GWindows and a future home for it)

[Ludovic Brenta]

As a backgrounder on my experience: a few years ago, I wrote a 120
kSLOC application in Java that did just that - an interface to a
database.  The front-end started as Swing but changed to HTML and a
bit of Javascript.  There was an abstraction layer over the database
that supported Oracle, DB2 and DB2/400 and provided the database
schema metadata to the visualisation layer.  There were a connection
pool, several caches of metadata and data, and application-level
permission settings (authentication was delegated to the database
server, authorisation done in the application).

I have several concerns with tight integration of GUI and database
libraries.

1. If every widget can be attached to a database query, will every
   update to a widget not cause an SQL query?  This should be avoided.

2. If every widget is attached to a query, is it possible to update
   several widgets with one query, i.e. that several widgets be
   attached to the same query?

3. Is it possible to perform arbitrarily complex, application-specific
   formatting to the data as it goes back and forth between the
   widgets and the database?

In the application I mentioned, we would routinely do queries that
joined 5 or 6 tables, and we had lots of heuristics to help speed that
up.  In one of the screens, we would present a tree structure
constructed from oh, perhaps 10 different queries.

I have not really had a deep look at either Delphi, MFC, or GWindows,
but I suspect that coupling the GUI and the database libraries is only
useful for quick-and-dirty work when you want to create forms where
one form=one record in the database.

But for anything more complex, such coupling just gets in the way.  In
fact, it is the job of any non-trivial database GUI to perform the
"grunt work" you mentioned, and I cannot think of a useful way the
library could ease that.  Or perhaps you were only thinking of
marshalling and unmarshalling of individual database fields to and
from the database?  Yes, this is grunt work, but it is often
application-dependent too.  And unlike Java, Ada has generics which
can be instrumental in making this grunt work a piece of cake.

Java's JDBC is not tightly coupled with Swing or AWT.  Both APQ and
GNADE are similar in concept to it, or the ODBC API which is also not
coupled with any GUI.

I do not think it is wise to have a GUI-dependent database library.

-- 
Ludovic Brenta.

Re: Coupling or not coupling database and GUI libraries

[Warren W. Gay VE3WWG]

Ludovic Brenta wrote:

> As a backgrounder on my experience: a few years ago, I wrote a 120
> kSLOC application in Java that did just that - an interface to a
> database.  The front-end started as Swing but changed to HTML and a
> bit of Javascript.  There was an abstraction layer over the database
> that supported Oracle, DB2 and DB2/400 and provided the database
> schema metadata to the visualisation layer.  There were a connection
> pool, several caches of metadata and data, and application-level
> permission settings (authentication was delegated to the database
> server, authorisation done in the application).

Ah, but you had to _build_ something, which is fine. I am not
suggesting an _implementation_, but I do think it needs to
be handled somehow. To do this elegantly, I believe that
GUI and database packages need to at least plan for the
possibilities.

> I have several concerns with tight integration of GUI and database
> libraries.
> 
> 1. If every widget can be attached to a database query, will every
>    update to a widget not cause an SQL query?  This should be avoided.

No of course not. This is configured at the point of building
the application (whether by GUI in Delphi or by some other means).

> 2. If every widget is attached to a query, is it possible to update
>    several widgets with one query, i.e. that several widgets be
>    attached to the same query?

Again, widgets are not hardwired to any database "concept". But yes,
it is possible in MFC for example, to associate multiple widgets
with column data. Someone with a better memory help me out here: there
is some kind of xfer event or API call.

> 3. Is it possible to perform arbitrarily complex, application-specific
>    formatting to the data as it goes back and forth between the
>    widgets and the database?

Complex cases always tend to be a "do it yourself" approach (no
surprise there). The there are many mundane cases that can be
handled elegantly. The simplest case is perhaps like the Dbase
case of a form matching a row of data (not using Dbase terminology).

> In the application I mentioned, we would routinely do queries that
> joined 5 or 6 tables, and we had lots of heuristics to help speed that
> up.  In one of the screens, we would present a tree structure
> constructed from oh, perhaps 10 different queries.

Joins by themselves are not a problem if you're only presenting data.
Doing updates are a bit different of course.

What you want to do is eliminate most of the grunt work. You won't
eliminate it all, but you can do a lot of it. Out of a large
application where you might have 200 screens, most of them will
be stupid and simple, and I see no point in handcrafting it all ;-)

> I have not really had a deep look at either Delphi, MFC, 

Delphi and MFC had ways to make your life much easier with
databases. MFC fell down when it came to handling NULL values
in calendar widgets etc., but it tried.


> or GWindows,
> but I suspect that coupling the GUI and the database libraries is only
> useful for quick-and-dirty work when you want to create forms where
> one form=one record in the database.

I have to disagree.

> But for anything more complex, such coupling just gets in the way.  

Much of the necessary coupling is grunt work. We have more creative
things to be doing.

 > In
> fact, it is the job of any non-trivial database GUI to perform the
> "grunt work" you mentioned, and I cannot think of a useful way the
> library could ease that.  

Well, you admit to not having tried it. Try it first, and then you
might see that there is at least a partial solution.

 > Or perhaps you were only thinking of
> marshalling and unmarshalling of individual database fields to and
> from the database?  

Nope. Column X must have its data populated in a control. WHen a
save occurs, you must do the reverse. Grunt work, plan in simple.
Multiply that by the number of column-widget pairs. More grunt.
It is also easy to automate this kind of stuff, with the right
kind of organization.

> Java's JDBC is not tightly coupled with Swing or AWT.  Both APQ and
> GNADE are similar in concept to it, or the ODBC API which is also not
> coupled with any GUI.

APQ is not currently linked to any GUI. I would like to perhaps
make a change on that score someday, but I haven't had much time
to plan it yet.

> I do not think it is wise to have a GUI-dependent database library.

Think in the larger sense of solving the problem, rather than its
implementation. How it is solved is unimportant to me, but it does
need to be solved. GUI and databases are frequently cousins.

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

Re: Coupling or not coupling database and GUI libraries (was: GWindows and a future home for it)

[David Botton]

I'd like to point out that the Database code in GWindows is in fact 
_not_ tightly coupled, although it offers a system to graft database 
functionality on to controls if one would wish to do so.

Personally, I like doing things myself :-)  Which is one reason I allow 
for it to be decoupled easily.

David Botton


On 2004-10-21 14:02:17 -0400, Ludovic Brenta 
<ludovic.brenta@insalien.org> said:

> As a backgrounder on my experience: a few years ago, I wrote a 120
> kSLOC application in Java that did just that - an interface to a
> database.  The front-end started as Swing but changed to HTML and a
> bit of Javascript.  There was an abstraction layer over the database
> that supported Oracle, DB2 and DB2/400 and provided the database
> schema metadata to the visualisation layer.  There were a connection
> pool, several caches of metadata and data, and application-level
> permission settings (authentication was delegated to the database
> server, authorisation done in the application).
> 
> I have several concerns with tight integration of GUI and database
> libraries.
> 
> 1. If every widget can be attached to a database query, will every
>    update to a widget not cause an SQL query?  This should be avoided.
> 
> 2. If every widget is attached to a query, is it possible to update
>    several widgets with one query, i.e. that several widgets be
>    attached to the same query?
> 
> 3. Is it possible to perform arbitrarily complex, application-specific
>    formatting to the data as it goes back and forth between the
>    widgets and the database?
> 
> In the application I mentioned, we would routinely do queries that
> joined 5 or 6 tables, and we had lots of heuristics to help speed that
> up.  In one of the screens, we would present a tree structure
> constructed from oh, perhaps 10 different queries.
> 
> I have not really had a deep look at either Delphi, MFC, or GWindows,
> but I suspect that coupling the GUI and the database libraries is only
> useful for quick-and-dirty work when you want to create forms where
> one form=one record in the database.
> 
> But for anything more complex, such coupling just gets in the way.  In
> fact, it is the job of any non-trivial database GUI to perform the
> "grunt work" you mentioned, and I cannot think of a useful way the
> library could ease that.  Or perhaps you were only thinking of
> marshalling and unmarshalling of individual database fields to and
> from the database?  Yes, this is grunt work, but it is often
> application-dependent too.  And unlike Java, Ada has generics which
> can be instrumental in making this grunt work a piece of cake.
> 
> Java's JDBC is not tightly coupled with Swing or AWT.  Both APQ and
> GNADE are similar in concept to it, or the ODBC API which is also not
> coupled with any GUI.
> 
> I do not think it is wise to have a GUI-dependent database library.

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

[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

[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]

>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

[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

[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

[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

[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

[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

[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]

> 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

[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

[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.

Licenses and physical things

[Björn Persson]

Marius Amado Alves wrote:

> The problem is that open source licenses 
> treat the software like a physical thing.

Proprietary licenses do that. Open source licenses encourage you to give 
copies to your friends. When was the last time you copied a lightbulb?

-- 
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

[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

[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

Gnat Pro and the GPL

[Björn Persson]

Marius Amado Alves wrote:

> As far as I know GNAT Pro is distributed under a proprietary license.

Gnat is based on GCC you know. You could even say it's a part of GCC. 
GCC is under the GPL. Distributing it under a proprietary license would 
be a violation of the GPL. Or do you think the Free Software Foundation 
would issue a special proprietary license to Adacore?

Besides, I distinctly remember that this was discussed and clarified 
here a few months ago.

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

Re: Gnat Pro and the GPL

[Marius Amado Alves]

Bj�rn Persson wrote:
> Gnat is based on GCC you know. You could even say it's a part of GCC. 
> GCC is under the GPL. Distributing it under a proprietary license would 
> be a violation of the GPL. Or do you think the Free Software Foundation 
> would issue a special proprietary license to Adacore?

Why not? Many open source businesses do.

Re: Gnat Pro and the GPL

[Björn Persson]

Marius Amado Alves wrote:

> Björn Persson wrote:
> 
>> Gnat is based on GCC you know. You could even say it's a part of GCC. 
>> GCC is under the GPL. Distributing it under a proprietary license 
>> would be a violation of the GPL. Or do you think the Free Software 
>> Foundation would issue a special proprietary license to Adacore?
> 
> Why not? Many open source businesses do.

Ever heard of a guy named Richard Stallman, founder and leader of said 
foundation? Ever heard anything about his opinions?

I'd suggest that you go to http://www.fsf.org/philosophy/philosophy.html 
and read a little. Not to convince you but to help you understand the FSF.

Although personally I think the name "Free Software Foundation" is 
enough to answer "Why not?".

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

Re: Gnat Pro and the GPL

[Marius Amado Alves]

Bj�rn Persson wrote:
 >>> ... do you think the Free Software
>>> Foundation would issue a special proprietary license to Adacore?
>>
>> Why not? Many open source businesses do.
> 
> Ever heard of a guy named Richard Stallman, founder and leader of said 
> foundation? Ever heard anything about his opinions?...

So at last we know the difference between open source and free software: 
Open source software can be dual licensed, and free software cannot! Ah, 
the beauty of simple things :-)

Re: Gnat Pro and the GPL

[Hyman Rosen]

Marius Amado Alves wrote:
> So at last we know the difference between open source and free software: 
> Open source software can be dual licensed, and free software cannot! Ah, 
> the beauty of simple things :-)

All software can be licensed in any way that its copyright holders choose.
Free software implies a certain set of restrictions upon the licensees if
they choose to redistribute. Open source implies a wider and more variable
set. The FSF is philosophically opposed to licenses which are not free
software, and thus will not dual-license under any such. Others may choose
otherwise. It is all perfectly simple, except to those people who wish that
certain owners would choose different licenses than the ones they actually
use.

Re: Gnat Pro and the GPL

[Björn Persson]

Hyman Rosen wrote:

> Free software implies a certain set of restrictions upon the licensees if
> they choose to redistribute. Open source implies a wider and more variable
> set.

The way the FSF defines free software and the way the OSI defines open 
source, they are identical. Maybe you're thinking of the difference 
between free software and what the FSF calls copyleft? As an example, 
the BSD license with the advertising clause removed qualifies as free 
software, but not as copyleft.

The philosophical difference between the FSF and the OSI is about 
advertising, not licensing. The FSF talks a lot about freedom. The OSI 
has chosen not to talk about freedom.

Other than that, I second your answer to Marius.

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

Re: Gnat Pro and the GPL

[Florian Weimer]

* Bj�rn Persson:

> The way the FSF defines free software and the way the OSI defines open 
> source, they are identical.

No, they aren't.  OSI considers the Apple Public Software License,
version 1.2, to be an open source license, but the FSF has clearly
stated that it's non-free.

Re: Gnat Pro and the GPL

[Björn Persson]

Florian Weimer wrote:

> * Björn Persson:
> 
>>The way the FSF defines free software and the way the OSI defines open 
>>source, they are identical.
> 
> No, they aren't.  OSI considers the Apple Public Software License,
> version 1.2, to be an open source license, but the FSF has clearly
> stated that it's non-free.

(I assume you mean the Apple Public Source License. It's best to be 
precise when there are so many similar names.)

Yes, the FSF rejected version 1.2 because it required that modified 
versions of software be published even if they were only used internally 
in an organization. I've heard that it was approved by the OSI by 
mistake, that this problem wasn't discovered before the license was 
approved, but that's unconfirmed.

I made a comparison a while ago and found two OSI-approved licenses that 
the FSF listed as non-free. The other was the Artistic License, which 
the FSF considers too vague: "The problems are matters of wording, not 
substance."

You may be right that the definitions aren't exactly identical, but the 
intention is and has always been that "open source" be another term for 
free software.

Besides, the problem with the APSL 1.2 was resolved in version 2.0, 
essentially by changing "deploy" to "externally deploy".

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

Re: Gnat Pro and the GPL

[CBFalconer]

Marius Amado Alves wrote:
> Bj�rn Persson wrote:
>
>>>> ... do you think the Free Software
>>>> Foundation would issue a special proprietary license to Adacore?
>>>
>>> Why not? Many open source businesses do.
>>
>> Ever heard of a guy named Richard Stallman, founder and leader of
>> said foundation? Ever heard anything about his opinions?...
> 
> So at last we know the difference between open source and free
> software: Open source software can be dual licensed, and free
> software cannot! Ah, the beauty of simple things :-)

No, AIUI software copyrights originally belong to the author.  They
may be licensed as the author pleases, which includes the GPL, or
the LGPL, or any other license.  In the case of GNU software all
rights have been assigned to GNU and the original author(s) is/are
out of the picture.

If the rights have not been assigned, sold, or whatever, the author
may charge as he wishes for anything.  However he may not charge
for derivatives of GPL licensed software, as that is specifically
forbidden by the license.  He may charge for physical delivery, and
must make any modified sources available at cost.  Whatever he
originates entirely remains his own, even though he makes it
available under the GPL etc.

All of my software published on my site (below) is freely
available, some in the public domain so that anyone may do anything
they wish with it, and some under GPL so that people may use it
freely, provided that anything they use it in is also put under
GPL.  If they don't like that they are free to negotiate some other
license with me.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Gnat Pro and the GPL

[Hyman Rosen]

Marius Amado Alves wrote:
> Why not? Many open source businesses do.

The FSF is not an open source business. It is a free software
organization. Releasing code under a proprietary license is
completely antithetical to its beliefs, and there is no chance
at all that it would ever do so.

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: Not redistributing GNAT Pro (was: GWindows and a home for it)

[Ludovic Brenta]

Stéphane Richard writes:
> Stephen Leake wrote:
>> 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.

> 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...;-)

Customers are allowed to make changes to GNAT Pro and distribute their
changes if they so choose, and they can even charge for that if they
want.  The GMGPL guarantees them those rights.

I am not a supported customer of Ada Core's, but I can imagine several
reasons why a customer would choose to respect Ada Core's request not
to distribute their changes:

- They are not compiler businesses.  They are busy writing mission- or
  life-critical software in Ada and have no time to devote to
  modifying GNAT.  In fact, that's what they pay Ada Core for.

- They do not want to make it public that they use Ada.

- They do not want to put their reputation at stake, should their
  modified GNAT Pro prove to be buggy.

- They do not want to fork away from GNAT Pro, because this would
  cause maintenance nightmares.  And Ada software engineers know how
  much that costs.

There may be other reasons as well which I have not thought of.  Would
a supported customer care to enlighten us?

-- 
Ludovic Brenta.

Re: Not redistributing GNAT Pro (was: GWindows and a home for it)

[Jeff C r e e.m]

"Ludovic Brenta" <ludovic.brenta@insalien.org> wrote in message 
news:87sm8qmjhv.fsf_-_@insalien.org...
>
> I am not a supported customer of Ada Core's, but I can imagine several
> reasons why a customer would choose to respect Ada Core's request not
> to distribute their changes:
> There may be other reasons as well which I have not thought of.  Would
> a supported customer care to enlighten us?
>

At the moment I am not supported (ran out a few months ago and we have not 
renewed just yet).

In any case, the first thing I wanted to say is that I have never been told, 
asked, or hinted at to not distribute anything by Ada Core Technologies. 
Perhaps they have asked hinted or told others this but it certainly never 
came up when we purchased support.


The reason I don't distribute i (and I suspect many others) is that I did 
not "buy" it. The support was purchased by my employer. While ACT may not be 
able to restrict who I give it to it is certainly not clear that my own 
company could not (it would seem to be that internal use never falls under 
the distribution clause of the GPL and thus the T & Cs of the GPL do not 
apply)... Now my company may or may not care or may or may not be within 
their rights to tell me not to distribute but who really wants to play that 
game with their employer.

gcc 3.4.1 is pretty solid. Sure it has got a few issues here and there but 
so does ever compiler (including the supported versions). I recommend that 
people who are unable or unwilling to purchase the supported version move on 
to gcc 3.4.1 and the various community supported side tools (such as ASIS, 
Florist).

It would be great it Ada Core Technologies would release another public 
version but I think they have enough work to do right now just trying to get 
ready for gcc 4.0.

Re: Not redistributing GNAT Pro

[Ludovic Brenta]

"Jeff C r e e.m" writes:
> gcc 3.4.1 is pretty solid. Sure it has got a few issues here and
> there but so does ever compiler (including the supported
> versions). I recommend that people who are unable or unwilling to
> purchase the supported version move on to gcc 3.4.1 and the various
> community supported side tools (such as ASIS, Florist).

I do not recommend this at the moment.  GCC 3.4.1 is on par,
quality-wise, with GNAT 3.15p, but it still lacks Glade and requires
an extra option (-gstabs+) to generate debugging information
compatible with the Ada-aware GCC 5.3.  When those two issues are
solved, I will consider GCC 3.4 as the next Debian Ada compiler.

-- 
Ludovic Brenta.

Re: Not redistributing GNAT Pro

[Jeff C r e e.m]

"Ludovic Brenta" <ludovic.brenta@insalien.org> wrote in message 
news:87oejdkvd0.fsf@insalien.org...
> "Jeff C r e e.m" writes:
>> gcc 3.4.1 is pretty solid. Sure it has got a few issues here and
>> there but so does ever compiler (including the supported
>> versions). I recommend that people who are unable or unwilling to
>> purchase the supported version move on to gcc 3.4.1 and the various
>> community supported side tools (such as ASIS, Florist).
>
> I do not recommend this at the moment.  GCC 3.4.1 is on par,
> quality-wise, with GNAT 3.15p, but it still lacks Glade and requires
> an extra option (-gstabs+) to generate debugging information
> compatible with the Ada-aware GCC 5.3.  When those two issues are
> solved, I will consider GCC 3.4 as the next Debian Ada compiler.


I think you mean GDB 5.3.

And yes for something like Debian Stable I would agree that sticking with 
3.15p probably makes sense.

Re: Not redistributing GNAT Pro

[Brian May]

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

    Ludovic> "Jeff C r e e.m" writes:
    >> gcc 3.4.1 is pretty solid. Sure it has got a few issues here
    >> and there but so does ever compiler (including the supported
    >> versions). I recommend that people who are unable or unwilling
    >> to purchase the supported version move on to gcc 3.4.1 and the
    >> various community supported side tools (such as ASIS, Florist).

    Ludovic> I do not recommend this at the moment.  GCC 3.4.1 is on
    Ludovic> par, quality-wise, with GNAT 3.15p, but it still lacks
    Ludovic> Glade and requires an extra option (-gstabs+) to generate
    Ludovic> debugging information compatible with the Ada-aware GCC
    Ludovic> 5.3.  When those two issues are solved, I will consider
    Ludovic> GCC 3.4 as the next Debian Ada compiler.

Will ASIS work with GCC 3.4? I read somewhere (perhaps the adabrowse
website), that adabrowse won't work with GCC 3.4, because it requires
ASIS which doesn't work with GCC 3.4. This might be out-of-date now?
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Not redistributing GNAT Pro

[Ludovic Brenta]

Brian May writes:
> Will ASIS work with GCC 3.4? I read somewhere (perhaps the adabrowse
> website), that adabrowse won't work with GCC 3.4, because it
> requires ASIS which doesn't work with GCC 3.4. This might be
> out-of-date now?

I think it is best to let Martin Krishik answer this, or browse his
SourceForge project on http://sourceforge.net/projects/gnat-asis

This project has a copy of AdaBrowse, but I don't know how well it
works.

-- 
Ludovic Brenta.

Re: Not redistributing GNAT Pro

[CBFalconer]

Ludovic Brenta wrote:
> 
> "Jeff C r e e.m" writes:
> > gcc 3.4.1 is pretty solid. Sure it has got a few issues here and
> > there but so does ever compiler (including the supported
> > versions). I recommend that people who are unable or unwilling to
> > purchase the supported version move on to gcc 3.4.1 and the various
> > community supported side tools (such as ASIS, Florist).
> 
> I do not recommend this at the moment.  GCC 3.4.1 is on par,
> quality-wise, with GNAT 3.15p, but it still lacks Glade and requires
> an extra option (-gstabs+) to generate debugging information
> compatible with the Ada-aware GCC 5.3.  When those two issues are
> solved, I will consider GCC 3.4 as the next Debian Ada compiler.

Is there a standard test suite for validating an Ada compiler, and
if so where, and is it free.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: Not redistributing GNAT Pro

[Jerry van Dijk]

CBFalconer <cbfalconer@yahoo.com> writes:
 
> Is there a standard test suite for validating an Ada compiler, and
> if so where, and is it free.

Yes, its called the Ada Conformity Assessment Test Suite, or ACATS for short.
It is integrated in recent gcc test suites. 

See: http://www.ada-auth.org/acats.html.

However, being an Ada programmer I have to pedantically point out that passing
a conformance suite in and by itself does not say much about the usability of
a compiler system for real work.

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

Re: Not redistributing GNAT Pro (was: GWindows and a home for it)

[Simon Wright]

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

> Customers are allowed to make changes to GNAT Pro and distribute
> their changes if they so choose, and they can even charge for that
> if they want.  The GMGPL guarantees them those rights.
> 
> I am not a supported customer of Ada Core's, but I can imagine several
> reasons why a customer would choose to respect Ada Core's request not
> to distribute their changes:
> 
> - They are not compiler businesses.  They are busy writing mission- or
>   life-critical software in Ada and have no time to devote to
>   modifying GNAT.  In fact, that's what they pay Ada Core for.
> 
> - They do not want to make it public that they use Ada.
> 
> - They do not want to put their reputation at stake, should their
>   modified GNAT Pro prove to be buggy.
> 
> - They do not want to fork away from GNAT Pro, because this would
>   cause maintenance nightmares.  And Ada software engineers know how
>   much that costs.
> 
> There may be other reasons as well which I have not thought of.  Would
> a supported customer care to enlighten us?

Those all sound reasonable reasons. But (for us) I personally think
the last is possibly the most important; the others aren't really on
the business's radar (it wouldn't occur to us to try selling Ada
compilers!)

As a current for-instance, we presently use a rebuilt RTS with (a) the
XDR version of System.Stream_Attributes, (b) an Ada.Command_Line that
doesn't raise exceptions on VxWorks (that's 3.16a1 only). This is all
very well, but we need to be sure that this rebuilt RTS is correct
(well, as correct as the supplied one). There are two ways I can see:
re-run ACATS ourselves, or pay ACT to do it. So it's an engineering
decision, to be preceded by asking ACT for a quote (today's job!)

By the way, thanks for the pointers in the Debian Ada Policy on the
inclusion of the ACATS subset in GCC.

-- 
Simon Wright                               100% Ada, no bugs.

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

[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.

Future of Ada volunteer efforts

[David Botton]

I thank you for the kind words the mean a lot to me.

There are things though the Ada community should have been doing and 
could be doing to make volunteer efforts and the Ada community as a 
whole more apealing, inspiring and vibrant. (perhaps this should be on 
the SigAda TEAM-ADA list instead of here, but any ways)

While I did do (no one ever closed any doors even if I haven't done 
anything for some time, so I guess in a sense "do") some consulting 
work in the Ada world for ACT my billing habits (or lack of billing) 
with them will confirm that I never did Ada work "for the money". 
Neither do most of the Ada folks that frequent/frequented C.L.A or 
create open source projects (even if it is their source of "money"). 
There is something else that makes most of us  "tick" and it is 
emotional not rational.

The problem with that is that to cultivate it requires a sensativity 
that frequently has been lacking amongst us for both good and bad.

The good is that those that hold on are the cream of the crop, some of 
the best minds in software I've met are/were here on CLA, other lists, 
or at the SigAda conference I spoke at some time ago.

The bad is that lack of sensativity leads to outside people "seeing" 
Ada as a bunch of has beens that are stroking each others egos for what 
they once did with no future path to recognition and inclusion. That 
doesn't mean to say that it is the case, but that the perception is 
that people that are active in a public way on the net for Ada are not 
in the limelight. The result is a public perception problem for those 
outside of the old circles.

If SigAda conferences included things like public recognition for the 
latest new inovcations, a $10 plaque for people making efforts in the 
past year not many years before, it would be a start... A student 
learning Ada in school that participated in a public project that then 
got recognition at a conference... now that is better than gold.

If a young programmer thought that one day he could be honored by the 
old guard it goes a long way to getting volunteer efforts and Ada 
vibrant on the net.

I know that the kinds words from Tucker Taft and a hand shake from him 
after my presentation meant a huge amount to me, but the lack of 
recognition of AdaPower or any one elses volunteer projects from a 
lecturn or in any other way by others also meant something.

I know that I am an egostical self serving fool who failed to get his 
foot in the door enough to stay in and whose inabilities to find time 
to contribute as a result will eventually disapear, but my perceptions 
may come in handy even if damning to myself to perhaps turn something 
like SigAda, CLA and the Ada community in to an organization that is 
recruiting the up and coming "youth" of the industry in to Ada instead 
of just touting the rational strengths of the language that most people 
in the public don't even care about.

Of course, if Robert Dewar was still on CLA he would likely argue that 
this angle is not important and in many ways I know he is correct, but 
my gut still tells me otherwise.

David Botton



On 2004-10-02 03:13:25 -0400, tmoran@acm.org said:

>>> 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: Future of Ada volunteer efforts

[stephane richard]

"David Botton" <david@botton.com> wrote in message 
news:2004100315034364440%david@bottoncom...
>I thank you for the kind words the mean a lot to me.
>
Don't mention it ;-). The words came out because they were surely justified 
to do so in my book :-)

> There are things though the Ada community should have been doing and could 
> be doing to make volunteer efforts and the Ada community as a whole more 
> apealing, inspiring and vibrant. (perhaps this should be on the SigAda 
> TEAM-ADA list instead of here, but any ways)
>
Ummmm errrr...ahem ahem.....I guess you could forward it ;-).  I think both 
team-ada and c.l.a. members might need to know this.

> While I did do (no one ever closed any doors even if I haven't done 
> anything for some time, so I guess in a sense "do") some consulting work 
> in the Ada world for ACT my billing habits (or lack of billing) with them 
> will confirm that I never did Ada work "for the money". Neither do most of 
> the Ada folks that frequent/frequented C.L.A or create open source 
> projects (even if it is their source of "money"). There is something else 
> that makes most of us  "tick" and it is emotional not rational.
>
I've noticed that, in my own personal experiences with other Ada programmers 
here on c.l.a. and that, to me is what sets Ada developers (the gurus) apart 
from the gurus of other languages....in my own Ada learning experiences 
questions I've asked (some more stupid than others ;-) I've never felt like 
a student learning from a God.  This is more than I can say from other 
languages (and communities) I've been to when I learned those languages. 
It's all part of what "really" converted me to Ada.  I got answers to 
questions and got "put back on the right track" by the Ada Community and 
today I have them to thank for the programmer I've become.  My hat is off to 
Ada community for this and other reasons.

This is something I've also noticed when other programmers coming here to 
"find out more" about Ada, I've never seen other languages put down....all 
I've seen is "Ada can do it" and with examples on how it can be done, 
well....etc etc.... ;-).....From the other forums/language worshippers, I 
can't say the same.  They keep on putting down other languages simply 
because they don't understand them. That was at least the majority of the 
case.

> The problem with that is that to cultivate it requires a sensativity that 
> frequently has been lacking amongst us for both good and bad.
>
> The good is that those that hold on are the cream of the crop, some of the 
> best minds in software I've met are/were here on CLA, other lists, or at 
> the SigAda conference I spoke at some time ago.
>
> The bad is that lack of sensativity leads to outside people "seeing" Ada 
> as a bunch of has beens that are stroking each others egos for what they 
> once did with no future path to recognition and inclusion. That doesn't 
> mean to say that it is the case, but that the perception is that people 
> that are active in a public way on the net for Ada are not in the 
> limelight. The result is a public perception problem for those outside of 
> the old circles.
>
Based on my previous comments above, I almost have to object to this 
one...give or take an example or two...but most of the time I didn't notice 
that :-).

> If SigAda conferences included things like public recognition for the 
> latest new inovcations, a $10 plaque for people making efforts in the past 
> year not many years before, it would be a start... A student learning Ada 
> in school that participated in a public project that then got recognition 
> at a conference... now that is better than gold.
>
I think you're definitaly right here.  Something like that would be 
inviting.

> If a young programmer thought that one day he could be honored by the old 
> guard it goes a long way to getting volunteer efforts and Ada vibrant on 
> the net.
>
> I know that the kinds words from Tucker Taft and a hand shake from him 
> after my presentation meant a huge amount to me, but the lack of 
> recognition of AdaPower or any one elses volunteer projects from a lecturn 
> or in any other way by others also meant something.
>
If you're stating here that non commercial efforts towards Ada and the 
community well I do wonder some...Mind you i didn't get a 10$ plaque ;-). 
but being considered and add in related links section of such websites as 
DDC-I, ACT, The Ada Information Clearing House, and others, well I've found 
somekind of "honor and priviledge" to be present there :-).

> I know that I am an egostical self serving fool who failed to get his foot 
> in the door enough to stay in and whose inabilities to find time to 
> contribute as a result will eventually disapear, but my perceptions may 
> come in handy even if damning to myself to perhaps turn something like 
> SigAda, CLA and the Ada community in to an organization that is recruiting 
> the up and coming "youth" of the industry in to Ada instead of just 
> touting the rational strengths of the language that most people in the 
> public don't even care about.
>
That's the main problem, they seem to think that it's not worth caring about 
whereas it should be, at least, a serious concern.  They need to see why Ada 
can say things like "Would you get aboard an airplane programmed in any 
other language?"  you know? :-).

> Of course, if Robert Dewar was still on CLA he would likely argue that 
> this angle is not important and in many ways I know he is correct, but my 
> gut still tells me otherwise.
>
> David Botton

Well I don't know Robert Dewar, but I do know David Botton ;-).  to me, any 
angle is good, any point of view, idealism, simple reason, you name 
it....it's very good and just as important as the other angles.  This would 
be like saying that suddenly, when turning your eyes to see around you, you 
don't need any angle between straight ahead of you and to your 
left/right...you just need straight left and right that's it.  I'm happy 
with the way my eyes are working right now :-).  I think we might even need 
to find more angles even.  Angles that can reach even the non programmer but 
be powerful enough to tell the programming community that "hey, there's a 
reason Ada's still here."  Even in today's world.

GWindows Database time type

[Stephen Leake]

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

> 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.

Native Windows might be the wrong choice; databases are hosted on many
operating systems, and GWindows should be able to provide clients for
any of them, possibly thru ODBC.

Here's a fragment from the MySQL manual
(http://dev.mysql.com/doc/mysql/en/TIME.html):

MySQL retrieves and displays TIME values in 'HH:MM:SS' format (or
'HHH:MM:SS' format for large hours values). TIME values may range from
'-838:59:59' to '838:59:59'.

For that, Time needs to be a string; that will always be the most
general format.

I couldn't find my SQL reference, so I'm not sure if that's standard
SQL or not. Anybody have a URL for a good SQL reference?

This gets back to "What are the requirements for GWindows"? Should it
meet some industry standard for SQL? or match MySQL, which is a
popular Open Source database? Or something else?

-- 
-- Stephe

Re: GWindows Database time type

[Fionn mac Cuimhaill]

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

>Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>
>> 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.
>
>Native Windows might be the wrong choice; databases are hosted on many
>operating systems, and GWindows should be able to provide clients for
>any of them, possibly thru ODBC.
>
>Here's a fragment from the MySQL manual
>(http://dev.mysql.com/doc/mysql/en/TIME.html):
>
>MySQL retrieves and displays TIME values in 'HH:MM:SS' format (or
>'HHH:MM:SS' format for large hours values). TIME values may range from
>'-838:59:59' to '838:59:59'.
>
>For that, Time needs to be a string; that will always be the most
>general format.
>
It's difficult to do tate arithmetic on strings; Windows already has a
SYSTEMTIME structure that is used in GNATCOM; there is also a 64-bit
integer representation of time. According to Microsoft docs,
SYSTEMTIME accomodates years all the way back to 1601. I'm not sure
what the 64-bit integer represents. (milliseconds since Jan 1,
1601???)  I have no idea of the reason for the 1601 date; in any case,
it is a great improvement over the 1901 limiting date used in
Ada.Calendar. There is no reason why a GWindows.Calendar package
couldn't be created that makes use of the SYSTEMTIME structure and
also supports a date representation usable for date arithmetic. It
looks to me like David Botton went with Ada.Calendar because it was an
already existing standard package, which if not perfect, was at least
usable and saved him the time of writing a calendar package.
>I couldn't find my SQL reference, so I'm not sure if that's standard
>SQL or not. Anybody have a URL for a good SQL reference?
>
>This gets back to "What are the requirements for GWindows"? Should it
>meet some industry standard for SQL? or match MySQL, which is a
>popular Open Source database? Or something else?

The native Windows time formats certainly cover a wide enough range of
dates to work better than Ada.Calendar. There doesn't seem to be any
element of GWindows which actually parses SQL; SQL code is managed
entirely by the programmer, and therefore any dialect of SQL can be
used. It wouldn't be too difficult to create a GWindows.Calendar that
could handle dates from any kind of database.

Re: GWindows Database time type

[Stephen Leake]

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

> On 29 Sep 2004 20:13:23 -0400, Stephen Leake <stephen_leake@acm.org>
> wrote:
> 
> >Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
> >
> >> 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.
> >
> >Native Windows might be the wrong choice; databases are hosted on many
> >operating systems, and GWindows should be able to provide clients for
> >any of them, possibly thru ODBC.
> >
> >Here's a fragment from the MySQL manual
> >(http://dev.mysql.com/doc/mysql/en/TIME.html):
> >
> >MySQL retrieves and displays TIME values in 'HH:MM:SS' format (or
> >'HHH:MM:SS' format for large hours values). TIME values may range from
> >'-838:59:59' to '838:59:59'.
> >
> >For that, Time needs to be a string; that will always be the most
> >general format.
> >
> It's difficult to do tate arithmetic on strings; 

Well, yes. But nothing says the type stored in the database has to be
the type you use to do date arithmetic.

> Windows already has a SYSTEMTIME structure that is used in GNATCOM;
> there is also a 64-bit integer representation of time. According to
> Microsoft docs, SYSTEMTIME accomodates years all the way back to
> 1601. I'm not sure what the 64-bit integer represents. (milliseconds
> since Jan 1, 1601???) 

I think that is the start of the Gregorian calendar, or something like
that. 

> I have no idea of the reason for the 1601 date; in any case, it is a
> great improvement over the 1901 limiting date used in Ada.Calendar.
> There is no reason why a GWindows.Calendar package couldn't be
> created that makes use of the SYSTEMTIME structure and also supports
> a date representation usable for date arithmetic. 

We could, but I would object to calling it Calendar; that's sort of a
reserved name in Ada. There are many other, equally good, ways to
build a date package. Hmm. I suppose if we accept up front that
GWindows is very Win32 based, it's not such a bad name.

Windex has a binding to Win32 system time and file time types.

> It looks to me like David Botton went with Ada.Calendar because it
> was an already existing standard package, which if not perfect, was
> at least usable and saved him the time of writing a calendar
> package. 

Yes. The consensus is that each user should write the time/date
package they need. For my real-time simulations, I use a 64 bit fixed
point time, with a resolution of nanoseconds and a range of 242 years.

> The native Windows time formats certainly cover a wide enough range of
> dates to work better than Ada.Calendar. There doesn't seem to be any
> element of GWindows which actually parses SQL; SQL code is managed
> entirely by the programmer, and therefore any dialect of SQL can be
> used. It wouldn't be too difficult to create a GWindows.Calendar that
> could handle dates from any kind of database.

Well, I still don't see why the design of GWindows.Calendar should be
at all influenced by databases; let's keep things orthogonal as much
as possible.

-- 
-- Stephe

Re: GWindows Database time type

[stephane richard]

"Stephen Leake" <stephen_leake@acm.org> wrote in message 
news:mailman.142.1096592260.390.comp.lang.ada@ada-france.org...
>
> Well, I still don't see why the design of GWindows.Calendar should be
> at all influenced by databases; let's keep things orthogonal as much
> as possible.
>
> -- 
> -- Stephe
>

I agree here totally with Stephen Leake.  I think GWindows.Calendar should 
be influenced neither by databases nor by Operating Systems either.

There is a date representation standard, ISO-8601, which can be read here 
http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html as 
well as other places on the web.  Perhaps it could be based on this standard 
instead?

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

Re: GWindows Database time type

[Randy Brukardt]

"stephane richard" <stephane.richard@verizon.net> wrote in message
news:mE27d.12084$XC.1409@trndny08...
>
> "Stephen Leake" <stephen_leake@acm.org> wrote in message
> news:mailman.142.1096592260.390.comp.lang.ada@ada-france.org...
> >
> > Well, I still don't see why the design of GWindows.Calendar should be
> > at all influenced by databases; let's keep things orthogonal as much
> > as possible.
> >
> > --
> > -- Stephe
> >
>
> I agree here totally with Stephen Leake.  I think GWindows.Calendar should
> be influenced neither by databases nor by Operating Systems either.
>
> There is a date representation standard, ISO-8601, which can be read here
> http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html
as
> well as other places on the web.  Perhaps it could be based on this
standard
> instead?

One obvious point is that you should determine what operations are needed
that are not provided by the standard. Remember that Ada 2005 includes
additional date/time operations for time zones, arithmetic, and formatting,
so it doesn't make much sense to re-invent the wheel in those areas. It also
expands the range of years upwards.

What's missing there (more advanced time zones, fancy date and time output)
probably can be built on top of those packages better and quicker than
starting from scratch.

                       Randy.

Re: GWindows Database time type

[stephane richard]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message 
news:LNadndc5E8x7VcHcRVn->
> One obvious point is that you should determine what operations are needed
> that are not provided by the standard. Remember that Ada 2005 includes
> additional date/time operations for time zones, arithmetic, and 
> formatting,
> so it doesn't make much sense to re-invent the wheel in those areas. It 
> also
> expands the range of years upwards.
>
> What's missing there (more advanced time zones, fancy date and time 
> output)
> probably can be built on top of those packages better and quicker than
> starting from scratch.
>
>                       Randy.
>
Indeed, maybe I didn't read the thread correctly, I thought there was no 
"viable calendar" in Ada, at least not at the level of discussion so far. If 
there is, I agree that more advanced time zones, fancy date and time output 
could probably be added like you said :-).

Re: GWindows Database time type

[Georg Bauhaus]

Stephen Leake <stephen_leake@acm.org> wrote:
: This gets back to "What are the requirements for GWindows"? Should it
: meet some industry standard for SQL? or match MySQL, which is a
: popular Open Source database? Or something else?

Perhaps GNADE has something to offer?

Re: GWindows Database time type

[Warren W. Gay VE3WWG]

Georg Bauhaus wrote:

> Stephen Leake <stephen_leake@acm.org> wrote:
> : This gets back to "What are the requirements for GWindows"? Should it
> : meet some industry standard for SQL? or match MySQL, which is a
> : popular Open Source database? Or something else?
> 
> Perhaps GNADE has something to offer?

I would like to suggest to David that any database support
should allow special hooks for other external packages like
my APQ to be hooked-in. Doing this requires extra effort, but
the end user wins because he is given more choice.

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

Re: GWindows Database time type

[David Botton]

I am now looking to do that in particular since the OS X port is now 
very much under way of GWindows (already has some basic functionality). 
What are the current choices out there for Ada right now.

So far:

GNADE
APQ

David Botton


On 2004-10-21 13:29:01 -0400, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> said:

> Georg Bauhaus wrote:
> 
>> Stephen Leake <stephen_leake@acm.org> wrote:
>> : This gets back to "What are the requirements for GWindows"? Should it
>> : meet some industry standard for SQL? or match MySQL, which is a
>> : popular Open Source database? Or something else?
>> 
>> Perhaps GNADE has something to offer?
> 
> I would like to suggest to David that any database support
> should allow special hooks for other external packages like
> my APQ to be hooked-in. Doing this requires extra effort, but
> the end user wins because he is given more choice.

Re: GWindows Database time type

[Warren W. Gay VE3WWG]

David Botton wrote:
> I am now looking to do that in particular since the OS X port is now 
> very much under way of GWindows (already has some basic functionality). 
> What are the current choices out there for Ada right now.
> 
> So far:
> 
> GNADE
> APQ
> 
> David Botton

I think there was an older package mentioned on this list a short
time ago, but my memory fails me. I don't know how relevant it is
now, because I got the impression it has been neglected for some
time.

Warren.


> On 2004-10-21 13:29:01 -0400, "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> 
> said:
> 
>> Georg Bauhaus wrote:
>>
>>> Stephen Leake <stephen_leake@acm.org> wrote:
>>> : This gets back to "What are the requirements for GWindows"? Should it
>>> : meet some industry standard for SQL? or match MySQL, which is a
>>> : popular Open Source database? Or something else?
>>>
>>> Perhaps GNADE has something to offer?
>>
>>
>> I would like to suggest to David that any database support
>> should allow special hooks for other external packages like
>> my APQ to be hooked-in. Doing this requires extra effort, but
>> the end user wins because he is given more choice.
> 
> 
> 

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

Re: GWindows Database time type

[Warren W. Gay VE3WWG]

Stephen Leake wrote:

> Fionn mac Cuimhaill <invisible@hiding.from.spam> writes:
>>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.
> 
> Native Windows might be the wrong choice; databases are hosted on many
> operating systems, and GWindows should be able to provide clients for
> any of them, possibly thru ODBC.
> 
> Here's a fragment from the MySQL manual
> (http://dev.mysql.com/doc/mysql/en/TIME.html):
> 
> MySQL retrieves and displays TIME values in 'HH:MM:SS' format (or
> 'HHH:MM:SS' format for large hours values). TIME values may range from
> '-838:59:59' to '838:59:59'.

I think MySQL now allows you to make time and dates stricter
through some configuration options (I am personally not surprised
that they've received requests for this). My APQ binding had
to deal with the fact that the newer versions of MySQL seem to
return dates in the "YYYYMMDDHHMMSS" format as a number. This
is different than the SQL standard "YYYY-MM-DD HH:MM:SS" format.
But APQ-2.2 now adjusts for this.

Slightly-OT and Shameless Plug:

I only note this because APQ is designed to shield the application
designer from some of these ugly differences. APQ-2.2 isn't quite
out yet, but it is coming. I think I have spent more time revising
the documentation, then I did on revising the code (whew). But
the end result will be worth it, since it is now much more readable,
and corrects a number of other gross problems that existed in the
last manual. The biggest change is the manual now documents all
API's in "code boxes" in Ada code, rather than as parameters in
a table. This should make it immediately much more readable.

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

AdaPower and GWindows community effort drive

[David Botton]

On 2004-09-28 22:48:03 -0400, Fionn mac Cuimhaill 
<invisible@hiding.from.spam> said:
>  David Botton seems to have fallen off the edge of the world,

Well sometimes I think I have (at least the Ada world), and I 
appologise to those who have e-mailed me and I have otherwise been 
unresponsive or have not received their e-mails.

>  and it occursto
> me that his  AdaPower web site could do the same thing.

Not unless the community asked me to do so, the $15.00 a year it costs 
to renew the domain name it is not an issue (the servers are not an 
issue either).

Ada, to my increadible surprise and very extreme major disapointment, 
turned out a dead end for me (I'd like to hope not others) when I 
needed to make a job change (saddest part is I was willing to work with 
all my passion and for half of the money  of offers I had received at 
the time for C++ and Web based technology work which of couse pays the 
bills then and now very nicely).

>  still have some time to build a consensus
> on a future home for GWindows.

I'd be very happy to offer full FTP access to a group interested in 
maintaing GWindows and/or AdaPower along with me.

I've set up an e-mail list:

admin-list @ adapower.com

send subscribe in the _subject_ to join. I will try and be as involved 
as I can on the list as well (sadly very little for now).

What I'd like to do is just turn over full ftp access to that group (or 
groups) and for the most part full license to do as they please with in 
limitations, ie. the site/GWindows is grown not chopped down with 
contents dispursed,  that everything remains free of charge, and if and 
whenever possible, a community effort.

David Botton

Re: AdaPower and GWindows community effort drive

[stephane richard]

1
"David Botton" <david@botton.com> wrote in message 
news:2004100311415116807%david@bottoncom...
> On 2004-09-28 22:48:03 -0400, Fionn mac Cuimhaill
>
> I'd be very happy to offer full FTP access to a group interested in 
> maintaing GWindows and/or AdaPower along with me.
>
> I've set up an e-mail list:
>
> admin-list @ adapower.com
>
> send subscribe in the _subject_ to join. I will try and be as involved as 
> I can on the list as well (sadly very little for now).
>
> What I'd like to do is just turn over full ftp access to that group (or 
> groups) and for the most part full license to do as they please with in 
> limitations, ie. the site/GWindows is grown not chopped down with contents 
> dispursed,  that everything remains free of charge, and if and whenever 
> possible, a community effort.
>
> David Botton
>
Hi David,

When you decide to answer posts, you ANSWER posts, I can't read one that 
another pops up ;-).

I'm still willing to be a co-webmaster of adapower, as I've explained here, 
I've likst information that allowed me to do updates.....but if I have them 
I could get back to it. ... provided I have the pasword I needed :-).

Just let me know, I'm still here :-)

Re: AdaPower and GWindows community effort drive

[David Botton]

That would be wonderful. I'll get you usernames and passwords ASAP.

What I'd like to do is push our websites (not just Adapower, but all of 
ours) to become more community oriented in maintenance so that the sort 
of lapses I endure or others don't become a drain on the Ada 
communities image.

The first order would be for us to better divide up what goes where and 
push to get contents rolling in to its appropriate places as regularly 
as we can.

David Botton


On 2004-10-03 12:45:05 -0400, "stephane richard" 
<stephane.richard@verizon.net> said:

> 1
> "David Botton" <david@botton.com> wrote in message 
> news:2004100311415116807%david@bottoncom...
>> On 2004-09-28 22:48:03 -0400, Fionn mac Cuimhaill
>> 
>> I'd be very happy to offer full FTP access to a group interested in 
>> maintaing GWindows and/or AdaPower along with me.
>> 
>> I've set up an e-mail list:
>> 
>> admin-list @ adapower.com
>> 
>> send subscribe in the _subject_ to join. I will try and be as involved 
>> as I can on the list as well (sadly very little for now).
>> 
>> What I'd like to do is just turn over full ftp access to that group (or 
>> groups) and for the most part full license to do as they please with in 
>> limitations, ie. the site/GWindows is grown not chopped down with 
>> contents dispursed,  that everything remains free of charge, and if and 
>> whenever possible, a community effort.
>> 
>> David Botton
>> 
> Hi David,
> 
> When you decide to answer posts, you ANSWER posts, I can't read one 
> that another pops up ;-).
> 
> I'm still willing to be a co-webmaster of adapower, as I've explained 
> here, I've likst information that allowed me to do updates.....but if I 
> have them I could get back to it. ... provided I have the pasword I 
> needed :-).
> 
> Just let me know, I'm still here :-)

Re: AdaPower and GWindows community effort drive

[stephane richard]

"David Botton" <david@botton.com> wrote in message 
news:2004100313293637709%david@bottoncom...
> That would be wonderful. I'll get you usernames and passwords ASAP.
>
> What I'd like to do is push our websites (not just Adapower, but all of 
> ours) to become more community oriented in maintenance so that the sort of 
> lapses I endure or others don't become a drain on the Ada communities 
> image.
>
> The first order would be for us to better divide up what goes where and 
> push to get contents rolling in to its appropriate places as regularly as 
> we can.
>
> David Botton
>
Agreed, As such, I've been thinking about just that too these past 
weeks....I'll be removing some of the Ada World contents (the tips and 
tricks and code snippets) since I haven't used them and other websites have 
it already.  I don't want any visitors to say well hey I saw that there....I 
think we should be like a big mall without anything to sell so to 
speak...they wanna do this with Ada they go there, they wanna do that, they 
go there, etc etc...at least for a good couple websites other than ours too 
:-)...

Re: AdaPower and GWindows community effort drive

[David Botton]

Agreed, AdaWorld is a good place to shoot them off from as well.

DB


On 2004-10-03 13:38:32 -0400, "stephane richard" 
<stephane.richard@verizon.net> said:

> 
> "David Botton" <david@botton.com> wrote in message 
> news:2004100313293637709%david@bottoncom...
>> That would be wonderful. I'll get you usernames and passwords ASAP.
>> 
>> What I'd like to do is push our websites (not just Adapower, but all of 
>> ours) to become more community oriented in maintenance so that the sort 
>> of lapses I endure or others don't become a drain on the Ada 
>> communities image.
>> 
>> The first order would be for us to better divide up what goes where and 
>> push to get contents rolling in to its appropriate places as regularly 
>> as we can.
>> 
>> David Botton
>> 
> Agreed, As such, I've been thinking about just that too these past 
> weeks....I'll be removing some of the Ada World contents (the tips and 
> tricks and code snippets) since I haven't used them and other websites 
> have it already.  I don't want any visitors to say well hey I saw that 
> there....I think we should be like a big mall without anything to sell 
> so to speak...they wanna do this with Ada they go there, they wanna do 
> that, they go there, etc etc...at least for a good couple websites 
> other than ours too :-)...

Re: AdaPower and GWindows community effort drive

[Stephen Leake]

David Botton <david@botton.com> writes:

> That would be wonderful. I'll get you usernames and passwords ASAP.
> 
> What I'd like to do is push our websites (not just Adapower, but all
> of ours) to become more community oriented in maintenance so that the
> sort of lapses I endure or others don't become a drain on the Ada
> communities image.

Which is precisely why a site like SourceForge makes more sense. They
don't depend on just one (or even a few) person for anything.

> The first order would be for us to better divide up what goes where
> and push to get contents rolling in to its appropriate places as
> regularly as we can.

It does make sense to maintain the AdaPower website, either on David's
servers or elsewhere.

I'd still like to pursue setting up a Claw or GWindows project at
Sourceforge, for code maintenance and development.

-- 
-- Stephe

Re: AdaPower and GWindows community effort drive

[stephane richard]

"Stephen Leake" <stephen_leake@acm.org> wrote in message 
news:mailman.177.1096855957.390.comp.lang.ada@ada-france.org...
> I'd still like to pursue setting up a Claw or GWindows project at
> Sourceforge, for code maintenance and development.
>
> -- 
> -- Stephe
>

Agreed here, the website could be maintained by a group.  GWindows or CLAW, 
I believe would be better managed through SourceForge simply because it's 
made for it.  Better control over what can go in it, easier ability to go 
back to a version should an added feature stops other parts from working 
properly.  SourceForge and CVS are just made for this kind of code 
maintenance.  I still don't see a problem in simply putting both of these on 
sourceforge.  As I said I think they both have their own specific set of 
advantage and minding that I think different developers from different 
worlds would and could get used to depending on their respective 
backgrounds. :-)

Re: AdaPower and GWindows community effort drive

[David Botton]

I have no objections at all to GWindows on SourceForge or any where 
else. I was offering a solution, but the choice is everyones not just 
mine.

David Botton

On 2004-10-03 22:12:27 -0400, Stephen Leake <stephen_leake@acm.org> said:

> Which is precisely why a site like SourceForge makes more sense. They
> don't depend on just one (or even a few) person for anything.

Re: AdaPower and GWindows community effort drive

[Fionn mac Cuimhaill]

On Sun, 3 Oct 2004 11:41:51 -0400, David Botton <david@botton.com>
wrote:


>
>I've set up an e-mail list:
>
>admin-list @ adapower.com
>
>send subscribe in the _subject_ to join. I will try and be as involved 
>as I can on the list as well (sadly very little for now).
>
I can't subscribe; my mail server sent this message to me:

This Message was undeliverable due to the following reason:

Each of the following recipients was rejected by a remote mail server.
The reasons given by the server are included to help you determine why
each recipient was rejected.

    Recipient: <admin-list@adapower.com>
    Reason:    Relaying not allowed

David Gressett AKA Fionn mac Cuimhaill
res1nntf.cabbage@kale.verizon.carrot.net (remove vegetables to get
correct address)

Re: AdaPower and GWindows community effort drive

[stephane richard]

"Fionn mac Cuimhaill" <invisible@hiding.from.spam> wrote in message 
news:had1m0pdvtdjpkcrr9j56n32ueuhdt5a0o@4ax.com...
> On Sun, 3 Oct 2004 11:41:51 -0400, David Botton <david@botton.com>
> wrote:
>
>
>>
>>I've set up an e-mail list:
>>
>>admin-list @ adapower.com
>>
>>send subscribe in the _subject_ to join. I will try and be as involved
>>as I can on the list as well (sadly very little for now).
>>
> I can't subscribe; my mail server sent this message to me:
>
> This Message was undeliverable due to the following reason:
>
> Each of the following recipients was rejected by a remote mail server.
> The reasons given by the server are included to help you determine why
> each recipient was rejected.
>
>    Recipient: <admin-list@adapower.com>
>    Reason:    Relaying not allowed
>
> David Gressett AKA Fionn mac Cuimhaill
> res1nntf.cabbage@kale.verizon.carrot.net (remove vegetables to get
> correct address)

Same here, with the same message. Relaying not allowed, etc etc... 

Re: AdaPower and GWindows community effort drive

[David Botton]

I'll take a look at the server and repost when I know it is fixed.

David Botton

On 2004-10-03 22:37:27 -0400, Fionn mac Cuimhaill 
<invisible@hiding.from.spam> said:

> On Sun, 3 Oct 2004 11:41:51 -0400, David Botton <david@botton.com>
> wrote:
> 
> 
>> 
>> I've set up an e-mail list:
>> 
>> admin-list @ adapower.com
>> 
>> send subscribe in the _subject_ to join. I will try and be as involved 
>> as I can on the list as well (sadly very little for now).
>> 
> I can't subscribe; my mail server sent this message to me:
> 
> This Message was undeliverable due to the following reason:
> 
> Each of the following recipients was rejected by a remote mail server.
> The reasons given by the server are included to help you determine why
> each recipient was rejected.
> 
>     Recipient: <admin-list@adapower.com>
>     Reason:    Relaying not allowed
> 
> David Gressett AKA Fionn mac Cuimhaill
> res1nntf.cabbage@kale.verizon.carrot.net (remove vegetables to get
> correct address)

Re: AdaPower and GWindows community effort drive

[David Botton]

The admin-list@adapower.com has been repaired. I ask all those 
interested in joining discussions and working on AdaPower as admins and 
content providers to please join.

Send the word subscribe in the _subject_ to admin-list@adapower.com

On 2004-10-04 09:44:18 -0400, David Botton <david@botton.com> said:

> I'll take a look at the server and repost when I know it is fixed.
> 
> David Botton
> 

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.