A community Windows binding

A community Windows binding

[Stephen Leake]

I'd like to step back from the "GWindows vs CLAW" debate and take
stock.

David Botton has made several points in favor of using GWindows as the
starting point for a community Ada binding. He has also pointed out
the existence of a GWindows user/developer group on the GNAVI mailing
list; perhaps those people have not been represented in the
discussions here.

My personal interest is in establishing a community supported Free
Software Windows Ada binding. I can easily go with either GWindows or
CLAW as a starting point.

I think the crucial issue is "how many developers will actually join
the project?".

I have volunteered to be the first sysadmin of a SourceForge project
for a community Ada Windows binding. I'd like to get started :).

In order to get started, I'd like to hear from everyone who is willing
to be a developer. 

So far, I've heard from the following:

    Fionn mac Cuimhaill
        willing to work on GWindows
        needs database access
        willing to go with Claw if we port Gwindows.databases.controls

    Randy Brukardt
        willing to make full CLAW GMGPL, hosted on SourceForge

    stephane richard
        willing to work on GWindows and/or CLAW

    Stephen McNeill
        has worked on gwindows documentation
        willing to work on GWindows
        willing to work on CLAW

    Nick Roberts
        willing to work on GWindows

    André van Splunter
        willing to work on GWindows

    Stephen Leake 
        willing to work on GWindows
        willing to work on CLAW

    David Botton 
        willing to work on GWindows

I apologize if I've gotten anything wrong, or left anyone out; this
has been a little chaotic :). Let me know.

David, if there are people on the GNAVI list who should join this
discussion as potential developers, please invite them.

As the list stands now, there is a clear preference for GWindows.

-- 
-- Stephe

Re: A community Windows binding

[David Botton]

On 2004-10-05 19:28:03 -0400, Stephen Leake <stephen_leake@acm.org> said:
> 
> I have volunteered to be the first sysadmin of a SourceForge project
> for a community Ada Windows binding. I'd like to get started :).

If GWindows becomes the base, there is a number of updates ready to be 
integrated. Frank Piron's GWindows_Extended code is the first major 
chunk, Craig Carey's redone Scintilla Bindings, various other tidbits 
here and there. Also some one should go through Windex and GMGPL CLAW 
to pick up missing APIs, etc.

> 
> In order to get started, I'd like to hear from everyone who is willing
> to be a developer.
> So far, I've heard from the following:
> 
>     Fionn mac Cuimhaill
>         willing to work on GWindows
>         needs database access
>         willing to go with Claw if we port Gwindows.databases.controls
> 
>     Randy Brukardt
>         willing to make full CLAW GMGPL, hosted on SourceForge
> 
>     stephane richard
>         willing to work on GWindows and/or CLAW
> 
>     Stephen McNeill
>         has worked on gwindows documentation
>         willing to work on GWindows
>         willing to work on CLAW
> 
>     Nick Roberts
>         willing to work on GWindows
> 
>     Andr� van Splunter
>         willing to work on GWindows
> 
>     Stephen Leake         willing to work on GWindows
>         willing to work on CLAW
> 
>     David Botton         willing to work on GWindows

I'd work on either, but certainly more motivated for GWindows :-)

> 
> I apologize if I've gotten anything wrong, or left anyone out; this
> has been a little chaotic :). Let me know.
> 
> David, if there are people on the GNAVI list who should join this
> discussion as potential developers, please invite them.

I will mention it on the list now. Some other people not listed that 
are actively adding code to the GWindows project include  David 
Gressett, Gautier de Monmollin, Craig Carey and Wiljan Derks.

Jerry Van Dijk has also offered to work on GWindows / GNAVI in another thread

David Botton

Re: A community Windows binding

[CBFalconer]

Stephen Leake wrote:
>
> I'd like to step back from the "GWindows vs CLAW" debate and take
> stock.
> 
> David Botton has made several points in favor of using GWindows as
> the starting point for a community Ada binding. He has also pointed
> out the existence of a GWindows user/developer group on the GNAVI
> mailing list; perhaps those people have not been represented in the
> discussions here.
> 
> My personal interest is in establishing a community supported Free
> Software Windows Ada binding. I can easily go with either GWindows
> or CLAW as a starting point.
> 
> I think the crucial issue is "how many developers will actually
> join the project?".

I have been watching this from lurking distance, and it seems to me
that you are all missing the point.  You want a GUI interface to
Ada.  So the first thing to define is that interface.  What OS it
runs on is immaterial.  Obviously the first implementation will be
(is) to Windoze.  I consider that a database interface is a
different feathered horse.

-- 
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: A community Windows binding

[tmoran]

>that you are all missing the point.  You want a GUI interface to
>Ada.  So the first thing to define is that interface.  What OS it
>runs on is immaterial.
  Wants may have changed, but the abstract of the original TriAda
paper on Claw began:  "Ada 95 provides new tools to support a
compiler independent binding that is 1) friendly to Ada programmers,
2) raises the abstraction level, 3) allows resulting applications
that have the look and feel of the Windows applications familiar to
the end user."

Re: A community Windows binding

[Fionn mac Cuimhaill]

On 05 Oct 2004 19:28:03 -0400, Stephen Leake <stephen_leake@acm.org>
wrote:

>I'd like to step back from the "GWindows vs CLAW" debate and take
>stock.
>
>David Botton has made several points in favor of using GWindows as the
>starting point for a community Ada binding. He has also pointed out
>the existence of a GWindows user/developer group on the GNAVI mailing
>list; perhaps those people have not been represented in the
>discussions here.
>
>My personal interest is in establishing a community supported Free
>Software Windows Ada binding. I can easily go with either GWindows or
>CLAW as a starting point.
>
>I think the crucial issue is "how many developers will actually join
>the project?".
>
>I have volunteered to be the first sysadmin of a SourceForge project
>for a community Ada Windows binding. I'd like to get started :).
>
>In order to get started, I'd like to hear from everyone who is willing
>to be a developer. 
>
>So far, I've heard from the following:
>
>    Fionn mac Cuimhaill
>        willing to work on GWindows
>        needs database access
>        willing to go with Claw if we port Gwindows.databases.controls
I would amend this to "willing to go with Claw ( with some reluctance)
if we port GWindows.databases.controls. I would be much more
enthusiastic about working on GWindows.
>
>    Randy Brukardt
>        willing to make full CLAW GMGPL, hosted on SourceForge
>
>    stephane richard
>        willing to work on GWindows and/or CLAW
>
>    Stephen McNeill
>        has worked on gwindows documentation
>        willing to work on GWindows
>        willing to work on CLAW
>
>    Nick Roberts
>        willing to work on GWindows
>
>    Andr� van Splunter
>        willing to work on GWindows
>
>    Stephen Leake 
>        willing to work on GWindows
>        willing to work on CLAW
>
>    David Botton 
>        willing to work on GWindows
>
>I apologize if I've gotten anything wrong, or left anyone out; this
>has been a little chaotic :). Let me know.
>
>David, if there are people on the GNAVI list who should join this
>discussion as potential developers, please invite them.
>
>As the list stands now, there is a clear preference for GWindows.

Re: A community Windows binding

[Georg Bauhaus]

CBFalconer <cbfalconer@yahoo.com> wrote:
 
: I have been watching this from lurking distance, and it seems to me
: that you are all missing the point.

I think the point is Windows programming, not general GUI
programming. There are things that make OSs and GUIs look
and feel different. In particluar, if your program uses
Windows specific features, how do you define an interface
that uses Windows specific features on *BSD/X, say?

How would you define an interface that is capable of being
ported to _both_ Windows and 8 1/2 (the Plan 9 graphical
interface)?

-- Georg

Re: A community Windows binding

[Steve]

IMHO,
  The community Windows binding should not get bogged down in building a
system that is compatable with other OS or windowing systems.
  I am a strong advocate of Ada.  Ada is the best general purpose
programming language I have met to date.  I have met several programming
languages to date, and continue to meet them (C# being the latest).
  I have come to the realization about making the most economic and logical
choices: it doesn't matter.
  When OS/2 was a more stable and uniform OS, the bulk of new development
went to Windows and NT, which at the time was comparatively unstable.  OS/2
was a better choice... it doesn't matter.
  Using Ada is the best choice for much of the development done today.  It
doesn't matter, development is rarely done in Ada.  I think that's why David
Botton has been away from this list for a long period of time.

  For the community windows binding, I think it's best that we focus on
Windows and only Windows (even though it sucks).

Steve
(The Duck)

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:ck0l9m$3ac$2@a1-hrz.uni-duisburg.de...
> CBFalconer <cbfalconer@yahoo.com> wrote:
>
> : I have been watching this from lurking distance, and it seems to me
> : that you are all missing the point.
>
> I think the point is Windows programming, not general GUI
> programming. There are things that make OSs and GUIs look
> and feel different. In particluar, if your program uses
> Windows specific features, how do you define an interface
> that uses Windows specific features on *BSD/X, say?
>
> How would you define an interface that is capable of being
> ported to _both_ Windows and 8 1/2 (the Plan 9 graphical
> interface)?
>
> -- Georg

Re: A community Windows binding

[Nick Roberts]

Stephen Leake wrote:

> So far, I've heard from the following:
> ...
>     Nick Roberts
>         willing to work on GWindows

I don't think I actually ever said I would work on GWindows.

;-)

However, I would, in fact, be willing to work on GWindows or CLAW, albeit 
through gritted teeth.

The gritted teeth would be mainly because the GWindows and CLAW interfaces 
are Windows-specific. However, I would reluctantly agree that the 
difficulty of designing and supporting a serious platform-independent GUI 
would be too immense; to do this, it is necessary to write a great deal of 
GUI functionality as part of the implementation, and only use the minimum 
common subset of facilities provided by the various underlying platforms.

GWindows and CLAW are surely both about leveraging as much power from the 
Windows infrastructure as possible. A platform-independent GUI would really 
be a totally different project (worthwhile, but very ambitious).

I was once quite knowledgeable about the Win32 interface, and Windows 
programming in general, but my knowledge is old, and does not stretch, for 
example, to COM (or OLE, ActiveX, and so on). But I can learn!

I think I would be most interested in improving (extending) existing 
documentation, and producing new documentation. What would be the most 
appropriate source format? I might also be interested in producing a sample 
application (or two), big enough to be realistic, but small enough to be 
done quite quickly and serve its pedagogical purpose.

I do not, by any means, have any (personal) favour for GWindows over CLAW, 
or vice versa. I know only a very little about either, so I'm not in a 
position to judge.

-- 
Nick Roberts

Re: A community Windows binding

[Jeffrey Carter]

On 2004-10-05 19:28:03 -0400, Stephen Leake <stephen_leake@acm.org> said:
> 
> In order to get started, I'd like to hear from everyone who is willing
> to be a developer.

I have no experience with Gwindows, some with Claw, and a fair amount 
with JEWL and GtkAda. I have no real preference for a basis for a GMGPL 
windows binding, although my preferences are for platform portability 
and not using callbacks. If I may be of assistance, I am willing to help.

-- 
Jeff Carter
"Death awaits you all, with nasty, big, pointy teeth!"
Monty Python & the Holy Grail
20

Re: A community Windows binding

[Frank Piron]

05 Oct 2004 19:28:03 -0400 Stephen Leake <stephen_leake@acm.org> wrote:

> I'd like to step back from the "GWindows vs CLAW" debate and take
> stock.
>
> David Botton has made several points in favor of using GWindows as the
> starting point for a community Ada binding. He has also pointed out
> the existence of a GWindows user/developer group on the GNAVI mailing
> list; perhaps those people have not been represented in the
> discussions here.
>
> My personal interest is in establishing a community supported Free
> Software Windows Ada binding. I can easily go with either GWindows or
> CLAW as a starting point.

Our position here at KonAd:

1)
Every effort which leads to a broader use of Ada should be supported.

2)
Building a library or binding which for easy construction of
production quality GUI interfaces on the windows operating system
is an effort in the sense of 1).

3)
Last year we decided to extend GWindows because we had to decide
something (otherwise no money) and GWindows was there: free, available,
easy to use and to extend.

4)
Of course we will participate in every community effort concerning
the further development of GWindows.

Frank Piron

Re: A community Windows binding

[Ross Higson]

Stephen Leake wrote:

> In order to get started, I'd like to hear from everyone who is willing
> to be a developer. 
> 

Although I may not have a lot of time to spend on it, I would be willing
to be a developer for GWindows as and when time permits. I have some
experience with the package and have been impressed by its ease of use
(given some minimal exposure to Windows development). I should point out 
that I have no comparable experience with Claw, but I like GWindows 
because it is very simple to extend, and does not attempt to artifically 
limit users to a particular style of development - as thick bindings go, 
it is commendably "thin".

Ross Higson.

Re: A community Windows binding

[Warren W. Gay VE3WWG]

Jeffrey Carter wrote:

> On 2004-10-05 19:28:03 -0400, Stephen Leake <stephen_leake@acm.org> said:
>> In order to get started, I'd like to hear from everyone who is willing
>> to be a developer.
> 
> I have no experience with Gwindows, some with Claw, and a fair amount 
> with JEWL and GtkAda. I have no real preference for a basis for a GMGPL 
> windows binding, although my preferences are for platform portability 
> and not using callbacks. If I may be of assistance, I am willing to help.

JEWL when I looked at it last (>= yr) was nice and simple. As a
GUI training vehicle, I don't think you can beat it (unless you
insist on training on callbacks). I don't believe that JEWL's
design goals were such that it ever should be a General Purpose
interface for GUI. Problems such as the inability to redirect a
focus to a specific widget limits its wider use.

There was a thread on the GUIs & callbacks sometime ago, where I
believe MDC was quite vocal. Callbacks are a pain, but there aren't
too many practical alternatives. The big main loop that JEWL uses, is
one such alternative, but I am not convinced this scales well to
larger projects.

I think probably the only thing that can be agreed upon is that
callbacks are normal for GUIs now, GWindows uses them (like many
others), and it should not be a limiting factor in its choice.

As for portability, I would be greatly surprised if GWindows ever
goes beyond Windows support, so in my mind, asking for more than
that is barking up the wrong tree (this is why GtkAda remains
important for those that insist on portability). I wish it were
otherwise, but I don't think it is practicle to expect otherwise
for GWindows. I'd be willing to be wrong on that, but if I were
asked to make a bet..
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A community Windows binding

[Warren W. Gay VE3WWG]

Ross Higson wrote:

> Stephen Leake wrote:
> 
>> In order to get started, I'd like to hear from everyone who is willing
>> to be a developer.
> 
> Although I may not have a lot of time to spend on it, I would be willing
> to be a developer for GWindows as and when time permits. I have some
> experience with the package and have been impressed by its ease of use
> (given some minimal exposure to Windows development). I should point out 
> that I have no comparable experience with Claw, but I like GWindows 
> because it is very simple to extend, and does not attempt to artifically 
> limit users to a particular style of development - as thick bindings go, 
> it is commendably "thin".
> 
> Ross Higson.

For GUI work, I'll probably continue to work with GtkAda. But having
said that, if I wanted a Windows only product (or a native-feel one)
in Ada, I would definitely choose GWindows for ease-of-use, and its
ability to use COM/Active-X objects with GNATCOM. I haven't tried the
database aware widget support, but that is another factor that is
important to me. Just my $0.02.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: A community Windows binding

[Jeffrey Carter]

Warren W. Gay VE3WWG wrote:

> JEWL when I looked at it last (>= yr) was nice and simple. As a
> GUI training vehicle, I don't think you can beat it (unless you
> insist on training on callbacks). I don't believe that JEWL's
> design goals were such that it ever should be a General Purpose
> interface for GUI. Problems such as the inability to redirect a
> focus to a specific widget limits its wider use.

JEWL is very nice for its purpose, which is instruction and fairly 
simple windowing on Windows. It was never intended to be complete, and 
is pure GPL.

> There was a thread on the GUIs & callbacks sometime ago, where I
> believe MDC was quite vocal. Callbacks are a pain, but there aren't
> too many practical alternatives. The big main loop that JEWL uses, is
> one such alternative, but I am not convinced this scales well to
> larger projects.

Between callbacks and the single queue of events for all windows of JEWL 
is an approach more suited to concurrent languages: multiple queues, one 
per top-level window, with the assumption of one task per queue/window. 
There should be the ability to select what events will be put in the 
queue, and the possibility to combine queues when a window doesn't merit 
its own task. Such an approach should scale better than JEWL's single 
queue, and be more readable than callbacks.

What would be ideal would be an Ada-centric windowing library, with 
implementations based on Win32, X, and the like.

-- 
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

Re: A community Windows binding

[Ross Higson]

Warren W. Gay VE3WWG wrote:


> 
> For GUI work, I'll probably continue to work with GtkAda. But having
> said that, if I wanted a Windows only product (or a native-feel one)
> in Ada, I would definitely choose GWindows for ease-of-use, and its
> ability to use COM/Active-X objects with GNATCOM. I haven't tried the
> database aware widget support, but that is another factor that is
> important to me. Just my $0.02.

Absolutely agree. I wish there was a good platform independent GUI 
toolset, and I support the goals of GtkAda in trying to fill this gap 
even though I personally find it a bit limited and more difficult to use 
than GWindows. But I thought we were talking here about a Windows 
specific binding, and I think GWindows is the right choice for that. It 
would also help promote the use of Ada on the Windows platform because 
it would be familiar territory to any Windows programmers who decided to 
try Ada.

Ross Higson.

Re: A community Windows binding

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> There was a thread on the GUIs & callbacks sometime ago, where I
> believe MDC was quite vocal. Callbacks are a pain, but there aren't
> too many practical alternatives. 

Neither CLAW nor Windex uses "callbacks". They use dynamic
dispatching. GWindows uses either dynamic dispatching _or_ callbacks.
Gtk uses very complex chains of callbacks.

-- 
-- Stephe

Re: A community Windows binding

[Alexander E. Kopilovich]

Jeffrey Carter wrote:

> Between callbacks and the single queue of events for all windows of JEWL 
> is an approach more suited to concurrent languages: multiple queues, one 
> per top-level window, with the assumption of one task per queue/window. 
> There should be the ability to select what events will be put in the 
> queue, and the possibility to combine queues when a window doesn't merit 
> its own task. Such an approach should scale better than JEWL's single 
> queue, and be more readable than callbacks.
>
> What would be ideal would be an Ada-centric windowing library, with 
> implementations based on Win32, X, and the like.

Well, message queue management can be made Ada-centric, and perhaps this is
really a good idea (but are there any preliminary works in this direction?
not necessarily already Ada-centric, perhaps some abstract foundations may
be of interest if they rely upon only those concepts that have adequate
representation in Ada).

But this (message queue managent) is just one aspect of full-scale windowing
library, and actually most users touch it only briefly. Much more heavily
used aspect is ontology, and the windowing ontologies of Win32 and X systems
aren't the same. For example, vast majority of Delphi users don't know the
term "canvas", but as far as I know, all X programmers are perfectly aware
of it.

Also, full-scale windowing library always use containers rather heavily.
But reading all discussions on AI-302 (Container Library) I never seen a sign
of recognition of this need.





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

Re: A community Windows binding

[Nick Roberts]

Jeffrey Carter wrote:

> Between callbacks and the single queue of events for all windows of JEWL 
> is an approach more suited to concurrent languages: multiple queues, one 
> per top-level window, with the assumption of one task per queue/window. 
> There should be the ability to select what events will be put in the 
> queue, and the possibility to combine queues when a window doesn't merit 
> its own task. Such an approach should scale better than JEWL's single 
> queue, and be more readable than callbacks.

I have long felt that the approach most suited to a concurrent language 
(such as Ada) is for the 'window manager' to be a separate task, or 
possibly many tasks.

The window manager calls -- via callbacks, or (better) dispatching -- the 
'draw' procedures of a registered set of 'visual components', in response 
to the movement, resizing, uncovering, deminimisation, etc., of those 
components, as they are placed on the screen. The window manager may do the 
actual drawing itself directly to the hardware, or it may be a proxy for an 
underlying subsystem. I appreciate that this model doesn't fit Win32 
perfectly, but it can be done.

All that a simple program (with no separate tasks of its own) needs to do 
is to set up the components, and register them with the window manager. Its 
main data needs to be protected (in protected objects), so that it can be 
accessed concurrently by the components' draw (and other) procedures, as 
they are called by the window manager.

However, this is all very idle and speculative.

 > What would be ideal would be an Ada-centric windowing library, with
 > implementations based on Win32, X, and the like.

Which sounds like Titian. But, as I mentioned elsewhere, this would be a 
huge project.

-- 
Nick Roberts

Re: A community Windows binding

[tmoran]

>I have long felt that the approach most suited to a concurrent language
>(such as Ada) is for the 'window manager' to be a separate task, or
>possibly many tasks.
  Claw has a (hidden) separate task for the window manager.

>The window manager calls -- via callbacks, or (better) dispatching -- the
  Claw uses dispatching.

>'draw' procedures of a registered set of 'visual components', in response
>to the movement, resizing, uncovering, deminimisation, etc., of those
>components, as they are placed on the screen. The window manager may do the
>actual drawing itself directly to the hardware, or it may be a proxy for an
>underlying subsystem. I appreciate that this model doesn't fit Win32
>perfectly, but it can be done.
  When, eg resizing, is done by the user, the Claw window manager calls
(by dispatching) the programmer's "When_Resize" procedure, which in turn
may make calls to draw the various objects that should be visible in the
resized window.

>All that a simple program (with no separate tasks of its own) needs to do
>is to set up the components, and register them with the window manager.
  In Claw (for non-trivial programs) the programmer defines, eg,
type My_Stereo_View_Window_Type is new Basic_Window_Type with ...
procedure When_Resize(Window : in out My_Stereo_View_Window_Type; ...
A call to the (inherited) Create procedure creates the window (usually
also displaying it).  On a resize event for a window, dispatching goes
to the appropriate When_Resize procedure.

>Its main data needs to be protected (in protected objects), so that it can be
>accessed concurrently by the components' draw (and other) procedures, as
>they are called by the window manager.
  Most windows programs do everything on an interrupt, er, event basis
so there's really only one task - the window manager - doing anything.
The main program merely sits and waits for the window manager and other
tasks to finish.
  But you're quite right, if the main program or other tasks needs to
non-trivially access shared data protected objects will likely be appropriate.

>However, this is all very idle and speculative.
  Hardly, see www.rrsoftware.com/html/prodinf/claw.claw.htm

Re: A community Windows binding

[Marius Amado Alves]

Alexander E. Kopilovich wrote:
> Also, full-scale windowing library always use containers rather heavily.
> But reading all discussions on AI-302 (Container Library) I never seen a sign
> of recognition of this need.

What do you mean. One of the motivations for Ada.Containers is the good 
of having all libraries that require containers using the same container 
types. This has been voiced in AI-302 and in other places e.g. my 
Ada-Europe 2004 paper.

Re: A community Windows binding

[Alexander E. Kopilovich]

Marius Amado Alves wrote:

> > Also, full-scale windowing library always use containers rather heavily.
> > But reading all discussions on AI-302 (Container Library) I never seen a sign
> > of recognition of this need.
>
>What do you mean.

I meant only that there are no grounds for making a windowing library
"Ada-centric" in this significant respect.

I certainly did not mean that containers needed for a windowing library
can't be provided in Ada (with or without Standard Container Library).
All that is really necessary for providing tolerable containers for a
windowing library is class-wide access type, and Ada has it.





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

Re: A community Windows binding

[chris]

Nick Roberts wrote:

> I have long felt that the approach most suited to a concurrent language 
> (such as Ada) is for the 'window manager' to be a separate task, or 
> possibly many tasks.

You might want to look at Joe Armstrongs' X stuff for Erlang.  This 
takes a radically different approach from the 'standard' GUI approaches. 
  Might help stimulate some new ideas.

Re: A community Windows binding

[Jeffrey Carter]

Nick Roberts wrote:

> Which sounds like Titian. But, as I mentioned elsewhere, this would be a 
> huge project.

Right. The best way to get it worked on is to have the spec and 
semantics be defined in the ARM :)

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: A community Windows binding

[Jeffrey Carter]

Nick Roberts wrote:

> The window manager calls -- via callbacks, or (better) dispatching -- 

Callbacks and dispatching are essentially the same thing in a windowing 
system. You have to write little pieces of code that can be invoked in 
any order at any time outside your control. You have to use global 
variables extensively for these little pieces of code to communicate. 
The code is difficult to read because you have to understand all these 
little pieces to understand any part of the software.

With an event queue approach, one writes standard imperative software 
using your standard imperative language (Ada's about the only one). The 
code is well structured and easy to read and understand.

-- 
Jeff Carter
"I'm a lumberjack and I'm OK."
Monty Python's Flying Circus
54

Re: A community Windows binding

[Steve]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:KgH9d.9844$M05.267@newsread3.news.pas.earthlink.net...
> Nick Roberts wrote:
>
> > The window manager calls -- via callbacks, or (better) dispatching -- 
>
> Callbacks and dispatching are essentially the same thing in a windowing
> system. You have to write little pieces of code that can be invoked in
> any order at any time outside your control. You have to use global
> variables extensively for these little pieces of code to communicate.
> The code is difficult to read because you have to understand all these
> little pieces to understand any part of the software.
>

Don't confuse the architecture into which software must be developed
with poor design.  It is entirely possible to develop software that is
easy to follow in a windowing system... without resulting to using global
variables extensively for these little pieces of code to communicate.

For example: in windows a reference to an object may be associated with
a window.  The message handling routine has access to the window, and
likewise the reference to the object.  Nothing is global.  This may not be
the most obvious implementation, but is certainly more clean.

Steve
(The Duck)

> With an event queue approach, one writes standard imperative software
> using your standard imperative language (Ada's about the only one). The
> code is well structured and easy to read and understand.
>
> -- 
> Jeff Carter
> "I'm a lumberjack and I'm OK."
> Monty Python's Flying Circus
> 54
>

Re: A community Windows binding

[tmoran]

>> system. You have to write little pieces of code that can be invoked in
>> any order at any time outside your control. You have to use global
>> variables extensively for these little pieces of code to communicate.

>For example: in windows a reference to an object may be associated with
>a window.  The message handling routine has access to the window, and
>likewise the reference to the object.  Nothing is global.
  In Windows *all* events are associated with a window (whether it makes
sense or not).  In a system using dispatching like Claw, you declare, eg,
   type This_Window_Type is new Basic_Window_Type with record ...
and the window of This_Window_Type is passed to the dispatched routine,
which has access to the contents of the record extension.  Nothing need
be global.

>> The code is difficult to read because you have to understand all these
>> little pieces to understand any part of the software.
  It does force you to think in an OO way:  you must think about the type
This_Window_Type ...  and its behavior independent of anything else.  What
should a This_Window_Type do when the user asks to resize it?  What should
it do when there's a redraw request (perhaps some data has been changed
and the redraw should show the updated data).  What should happen when the
mouse is moved or clicked in the window?
  Ideally, you will be creating (or using) a new reusable object.  For
instance, in Orbitals (www.adapower.com/os/orbitals.html) there's a
reusable window that displays in 3-D a set of points, rotated by mouse
movement.  The rest of the program, or any program using
  type Cloud_Display_Type(Max_Particle_Count:  Positive)
    is new Claw.Basic_Window.Basic_Window_Type with private;
need know nothing about displaying or stereo projection or tracking mouse
movements or resizing windows.  The total required external interface of
the type is open, close, and set data values.  Yes, at a higher level of
abstraction you need to think simultaneously about calculating the point
data and about displaying it, but you can focus on each of those quite
separately.

>> With an event queue approach, one writes standard imperative software
>> using your standard imperative language (Ada's about the only one). The
>> code is well structured and easy to read and understand.
  A windows interface is user-driven: the user can click or key in any
order at any time outside your control.  So the event queue approach
turns out to be
  loop
    case Fetch_Next_Event is
      when resize => ...
      when keyin  => ...
      when draw   => ...
A dispatching system like Claw simply makes that internal and each "when"
branch consists of a dispatching call to, eg, When_Resize, for that Type
of window.  Given the number of different events ("case" branches) and the
possible different kinds of windows (implemented by "if" or subsidiary
"case" statements in each branch), explicitly writing the event queue code
for any non-trivial program would be truly huge and ugly.

Re: A community Windows binding

[Stephen Leake]

Jeffrey Carter <spam@spam.com> writes:

> Callbacks and dispatching are essentially the same thing in a
> windowing system. You have to write little pieces of code that can be
> invoked in any order at any time outside your control. You have to use
> global variables extensively for these little pieces of code to
> communicate. The code is difficult to read because you have to
> understand all these little pieces to understand any part of the
> software.

In Windex, GWindows, CLAW, and GtkAda, each "little piece of code" has
as a parameter the user window type. That type stores all the
information needed; no global variables are necessary.

I can (with a lot of effort to suppress my normal style :) write
messy, hard to read code in Windex, using global variables. But it's
certainly not required.

> With an event queue approach, one writes standard imperative
> software using your standard imperative language (Ada's about the
> only one). The code is well structured and easy to read and
> understand.

MS Windows has an event queue. The core program in Windex, CLAW, and
GWindows reads events from the event queue as they become available,
and calls the appropriate handler, via dispatching. or optionally via
a registered callback in GWindows.

The handler may make GUI calls that put other events on the event
queue (like "invalidate this rectangle" or "hide this widget"). Some
GUI calls call the main event handler directly, rather than going thru
the queue.

GtkAda is similar, but fewer things go thru the queue, and all handlers
are registered callbacks.

What is it you are talking about that is different?

I guess I should go look at the JEWL code.

-- 
-- Stephe

Re: A community Windows binding

[David Botton]

It is possible with GWindows to work directly with the Event Queue if 
you choose to as well.

David Botton

On 2004-10-08 21:36:42 -0400, Jeffrey Carter <spam@spam.com> said:

> With an event queue approach, one writes standard imperative software 
> using your standard imperative language (Ada's about the only one). The 
> code is well structured and easy to read and understand.

Re: A community Windows binding

[CBFalconer]

Stephen Leake wrote:
> Jeffrey Carter <spam@spam.com> writes:
> 
>> Callbacks and dispatching are essentially the same thing in a
>> windowing system. You have to write little pieces of code that
>> can be invoked in any order at any time outside your control.
>> You have to use global variables extensively for these little
>> pieces of code to communicate. The code is difficult to read
>> because you have to understand all these little pieces to
>> understand any part of the software.
> 
> In Windex, GWindows, CLAW, and GtkAda, each "little piece of
> code" has as a parameter the user window type. That type stores
> all the information needed; no global variables are necessary.
> 
> I can (with a lot of effort to suppress my normal style :)
> write messy, hard to read code in Windex, using global
> variables. But it's certainly not required.

I disagree that callbacks and dispatching are essentially the same,
unless you take the view that the OS and all its processes are one
large program, which in turn falls down in the presence of
multi-processors.  To me, callbacks are simply a way of customizing
another piece of software, much as (in C) qsort is customized by a
comparison function.  Dispatching has to do with selecting a
process (or thread) to execute.

As an example, there follows an extract from my hashlib.h (complete
package available on my site), which has no data space of its own. 
The hashinit function allocates space in the callers data space, in
which it records the location of various customizing functions (all
typedef'd in the same header).  The package is fully re-entrant,
except when calling malloc, etc.  All other calls pass back the
pointer to that space, much like the 'this' pointer in C++.  In
many ways hshinit and hshkill are equivalent to fopen and fclose.

Not really being familiar with Ada, but lurking here, this is the
best I can do for an example of so-called callback functions.  This
package was, among other things, originally intended to be an
example of OO techniques in C, and a testbed for hashing
functions.  Note that nothing spells out the table size.

/* initialize and return a pointer to the data base */
hshtbl *hshinit(hshfn hash, hshfn rehash,
                hshcmpfn cmp,
                hshdupfn dupe, hshfreefn undupe,
                int      hdebug);

/* 1------------------1 */

/* destroy the data base. Accepts NULL and does nothing */
void   hshkill(hshtbl *master);

/* 1------------------1 */

/* find an existing entry. NULL == notfound */
void * hshfind(hshtbl *master, void *item);

/* 1------------------1 */

/* delete an existing entry. NULL == notfound      */
/* Disposal of the storage returned by hshdelete   */
/* (originally created by hshdupfn) is up to the   */
/* application. It is no longer managed by hashlib */
/* It will usually be disposable by hshfreefn().   */
void * hshdelete(hshtbl *master, void *item);

/* 1------------------1 */

/* insert an entry.  NULL == failure, else item */
void * hshinsert(hshtbl *master, void *item);

-- 
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: A community Windows binding

[Stephen Leake]

CBFalconer <cbfalconer@yahoo.com> writes:

> Dispatching has to do with selecting a
> process (or thread) to execute.

That is one use of the term "dispatching". In this context, however,
we mean an object-oriented dispatching call, based on the type tag.
All within one thread.

-- 
-- Stephe

Re: A community Windows binding

[Stephen Leake]

Given the response so far, it is clear there is much more support for
using GWindows as the base of a "community Windows binding" than CLAW.

Also, it seems clear that SourceForge is the platform to use. Using
Gnu Arch is appealing, but it requires that each developer open their
machines to outside access. I'd rather let SourceForge worry about the
security implications of that. The other hosts suggested don't seem as
well supported as SourceForge.

Before I actually create a SourceForge project, I'd like to get at
least one other developer to commit to being a sysadmin on the
project. I don't think being sysadmin will take much time; it mostly
consists of setting up accounts for developers. When we get to doing
releases, there will be more work, but we can deal with that then.

Another minor issue is the name of the project. 

We want to host GWindows code (no need to change the name of that
package).

Also the Gnatcom code? I'm not clear if this is available anywhere
other than AdaPower, or if it needs a CVS project.

And possibly a version of Ada.Collections, until they become widely
available from vendors. We should start using that for any collection
needs in GWindows. Or we could just redistribute a .tar.gz of Matthew
Heaney's current stuff.

And possibly other GUI/Windows related packages in the future; maybe a
separate database binding, or a GUI builder, etc.

So perhaps GWindows is not the best name for the SourceForge project.

Let's have a short discussion on this, then I'll set up the project
next weekend, and we can start using that mailing list for any other
issues.

For my part, I actually think we should use GWindows; it's currently a
recognized name, and is general enough to mean "Anything Open Source
in Ada related to Windows".

-- 
-- Stephe

Re: A community Windows binding

[Andre]

Stephen Leake wrote:
> Given the response so far, it is clear there is much more support for
> using GWindows as the base of a "community Windows binding" than CLAW.
> 
> Also, it seems clear that SourceForge is the platform to use. Using
> Gnu Arch is appealing, but it requires that each developer open their
> machines to outside access. I'd rather let SourceForge worry about the
> security implications of that. The other hosts suggested don't seem as
> well supported as SourceForge.
> 
> Before I actually create a SourceForge project, I'd like to get at
> least one other developer to commit to being a sysadmin on the
> project. I don't think being sysadmin will take much time; it mostly
> consists of setting up accounts for developers. When we get to doing
> releases, there will be more work, but we can deal with that then.
> 
> Another minor issue is the name of the project. 
> 
> We want to host GWindows code (no need to change the name of that
> package).
> 
> Also the Gnatcom code? I'm not clear if this is available anywhere
> other than AdaPower, or if it needs a CVS project.
> 
> And possibly a version of Ada.Collections, until they become widely
> available from vendors. We should start using that for any collection
> needs in GWindows. Or we could just redistribute a .tar.gz of Matthew
> Heaney's current stuff.
> 
> And possibly other GUI/Windows related packages in the future; maybe a
> separate database binding, or a GUI builder, etc.
> 
> So perhaps GWindows is not the best name for the SourceForge project.
> 
> Let's have a short discussion on this, then I'll set up the project
> next weekend, and we can start using that mailing list for any other
> issues.
> 
> For my part, I actually think we should use GWindows; it's currently a
> recognized name, and is general enough to mean "Anything Open Source
> in Ada related to Windows".
> 

I already checked on SourceForge, but GWindows is already in use.
Maybe AdaOnWindows is a project name covering its contents?

Re: A community Windows binding

[tmoran]

>Maybe AdaOnWindows is a project name covering its contents?
  Seems a bit general to me.  What might a project named
JavaOnWindows contain, and what Java programs, running on Windows,
might it exclude?

Re: A community Windows binding

[David Botton]

If the decision is to make GWindows the base, I would suggest moving 
the discussion (at least for the time being) to the GNAVI list where 
GWindows / GNATCOM has been supported up to now.

I would like to be the other SysAdmin if there is no objection :-)

David Botton


On 2004-10-10 14:05:57 -0400, Stephen Leake <stephen_leake@acm.org> said:

> Given the response so far, it is clear there is much more support for
> using GWindows as the base of a "community Windows binding" than CLAW.
> 
> Also, it seems clear that SourceForge is the platform to use. Using
> Gnu Arch is appealing, but it requires that each developer open their
> machines to outside access. I'd rather let SourceForge worry about the
> security implications of that. The other hosts suggested don't seem as
> well supported as SourceForge.
> 
> Before I actually create a SourceForge project, I'd like to get at
> least one other developer to commit to being a sysadmin on the
> project. I don't think being sysadmin will take much time; it mostly
> consists of setting up accounts for developers. When we get to doing
> releases, there will be more work, but we can deal with that then.
> 
> Another minor issue is the name of the project.
> We want to host GWindows code (no need to change the name of that
> package).
> 
> Also the Gnatcom code? I'm not clear if this is available anywhere
> other than AdaPower, or if it needs a CVS project.
> 
> And possibly a version of Ada.Collections, until they become widely
> available from vendors. We should start using that for any collection
> needs in GWindows. Or we could just redistribute a .tar.gz of Matthew
> Heaney's current stuff.
> 
> And possibly other GUI/Windows related packages in the future; maybe a
> separate database binding, or a GUI builder, etc.
> 
> So perhaps GWindows is not the best name for the SourceForge project.
> 
> Let's have a short discussion on this, then I'll set up the project
> next weekend, and we can start using that mailing list for any other
> issues.
> 
> For my part, I actually think we should use GWindows; it's currently a
> recognized name, and is general enough to mean "Anything Open Source
> in Ada related to Windows".

Re: A community Windows binding

[David Botton]

I am going to send this off to the GNAVI list as well. gnavi-list@gnavi.org

On 2004-10-10 14:05:57 -0400, Stephen Leake <stephen_leake@acm.org> said:
> Another minor issue is the name of the project.
> We want to host GWindows code (no need to change the name of that
> package).

I recommend we use the original name of the GWindows/GNATCOM project, ie. GNAVI

> 
> Also the Gnatcom code? I'm not clear if this is available anywhere
> other than AdaPower, or if it needs a CVS project.

CVS for GNATCOM and GWindows was actively maintained by ACT when they 
were supporting it for their customers. As far as I know this is not 
officially the case any more.

> 
> And possibly a version of Ada.Collections, until they become widely
> available from vendors. We should start using that for any collection
> needs in GWindows. Or we could just redistribute a .tar.gz of Matthew
> Heaney's current stuff.

I think just linking / redistributing Matthew Heaney's current stuff is ideal.

David Botton

Re: A community Windows binding

[Warren W. Gay VE3WWG]

Nick Roberts wrote:
> Jeffrey Carter wrote:
>> Between callbacks and the single queue of events for all windows of 
>> JEWL is an approach more suited to concurrent languages: multiple 
>> queues, one per top-level window, with the assumption of one task per 
>> queue/window. There should be the ability to select what events will 
>> be put in the queue, and the possibility to combine queues when a 
>> window doesn't merit its own task. Such an approach should scale 
>> better than JEWL's single queue, and be more readable than callbacks.
> 
> I have long felt that the approach most suited to a concurrent language 
> (such as Ada) is for the 'window manager' to be a separate task, or 
> possibly many tasks.

At the end of the day, a task begins to look like a callback,
with the exception that the delivery mechanism is different.

I can only see 4 ways to deal with GUI events :

1. The JEWL big main loop approach
2. The callback approach (Windows)
3. The "pipeline" event approach (X Window)
4. The "method" calls in an OO structure for
    certain events (Java/C#), and the use of
    inheritance to gain control during certain
    events. This is very similar to #2, except
    that inheritance allows installed callbacks
    through overrides.

Ada tasks IMHO, are a variation of #2. In fairness,
#4 is very similar to #2 as well.

I don't believe #1 is practicle for a large application:
   - the main loop is too large code-wise
   - many cases (harder to modularize)
   - unwanted coupling between cases is possible through
     shared objects/code in the module containing
     the main loop(though this can be avoided).

People dislike #2 for various reasons:
   - perhaps complexity
   - distributed code (too little coupling?)
   - difficulties with "user data" parameter/type

The X Window approach has its own problems:
   - performance: latency between request and
     event response (in synchronous mode), but
     this makes error handling easy and neat.
   - error handling: (asynchronous mode) it is
     very messy tracking requests vs returned
     responses (often X Window programs ignore
     returned errors because they were n events
     ago). This leads too poor quality of app.

My biggest beef for callbacks and similar techniques
is the need for the "user data" parameter. I don't
have a problem with the callback mechanism itself,
but for Ada the "user data" type and parameter is
usually a problem.

If however, some main object for an application
was used and made available in every callback,
then the application can extend that and gain
access to custom application values. I seem
to recall that some GUIs do it this way, which
seems about right to me.

...
> All that a simple program (with no separate tasks of its own) needs to 
> do is to set up the components, and register them with the window 
> manager. 

But the process is much the same. Registering a callback or
an object, is a very similar process (or burden ;-)

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

Re: A community Windows binding

[Warren W. Gay VE3WWG]

CBFalconer wrote:

> Stephen Leake wrote:
>>Jeffrey Carter <spam@spam.com> writes:
>>>Callbacks and dispatching are essentially the same thing in a
>>>windowing system. You have to write little pieces of code that
>>>can be invoked in any order at any time outside your control.
>>>You have to use global variables extensively for these little
>>>pieces of code to communicate. The code is difficult to read
>>>because you have to understand all these little pieces to
>>>understand any part of the software.
>>
>>In Windex, GWindows, CLAW, and GtkAda, each "little piece of
>>code" has as a parameter the user window type. That type stores
>>all the information needed; no global variables are necessary.
>>
>>I can (with a lot of effort to suppress my normal style :)
>>write messy, hard to read code in Windex, using global
>>variables. But it's certainly not required.
> 
> I disagree that callbacks and dispatching are essentially the same,

Agreed. In a dispatching program there is too much temptation
for the programmer to have unwanted coupling between the cases
of code (they could share object(s)/variable(s) that were
unintended). In a callback, this risk is reduced because the
object(s)/variable(s) are localized to the callback itself.

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

Re: A community Windows binding

[Warren W. Gay VE3WWG]

Stephen Leake wrote:

> CBFalconer <cbfalconer@yahoo.com> writes:
>>Dispatching has to do with selecting a
>>process (or thread) to execute.
> 
> That is one use of the term "dispatching". In this context, however,
> we mean an object-oriented dispatching call, based on the type tag.
> All within one thread.

Ok, ignore my prior post ;-)  I though you were speaking
of a large case statement.

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

Re: A community Windows binding

[Stephen Leake]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes:

> Ah, but some systems work with "user data" parameters better
> than others. In C/C++, the issue is easy because of the liberal
> use of void *ptrs, but in Ada one constantly pines for a
> purer strongly typed way to do it.

GWindows, CLAW, and Windex are all strongly typed at the user code
level. One core routine does all the unchecked conversions from the
Win32 API types.

GtkAda is less strongly typed, because the user has to figure out what
generics to instantiate to get the marshalling right. That's one
reason I'm giving up on it.

> The only practical way to do this in a pure Ada way IMO, is to have
> a "main object" that you can extend. 

Which is how GWindows, CLAW, and Windex do it. Great minds do think
alike ;).

-- 
-- Stephe

Re: A community Windows binding

[David Botton]

Just thought I would mention that I have a very basic start now of a 
port of GWindows to Mac OS X.

Perhaps a port is not the best thing to call it, it is the start of a 
re-implementation of GWindows using as many of the same interface as 
possible of GWindows for Win32. In theory if you don't make use of 
Win32 resources or Win32APIs and the like the code will most likely be 
able to run by just swapping the frameworks. I have not ETA on putting 
out a snap shot, but some basic things are already functioning.

I hope to do a similar re-implementation of GWindows in the long term 
using GtkAda.

David Botton

Re: A community Windows binding

[Stephane Riviere]

>I hope to do a similar re-implementation of GWindows in the long term 
>using GtkAda.

Gwindows could become a simpler approach to create multi-platform
softwares (and will be immediatly integrated in AIDE, as all embedded
AIDE softwares must be multi-platform aware).

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