Re: GWindows and a future home for it

[Stephen Leake <stephen_leake@acm.org>]

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