* Re: A community Windows binding
2004-10-05 23:28 ` Stephen Leake
@ 2004-10-06 4:26 ` David Botton
2004-10-06 17:42 ` Jeffrey Carter
2004-10-06 4:28 ` CBFalconer
` (4 subsequent siblings)
5 siblings, 1 reply; 41+ messages in thread
From: David Botton @ 2004-10-06 4:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-06 4:26 ` David Botton
@ 2004-10-06 17:42 ` Jeffrey Carter
2004-10-07 16:33 ` Warren W. Gay VE3WWG
0 siblings, 1 reply; 41+ messages in thread
From: Jeffrey Carter @ 2004-10-06 17:42 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-06 17:42 ` Jeffrey Carter
@ 2004-10-07 16:33 ` Warren W. Gay VE3WWG
2004-10-07 17:37 ` Jeffrey Carter
2004-10-08 1:36 ` Stephen Leake
0 siblings, 2 replies; 41+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-10-07 16:33 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-07 16:33 ` Warren W. Gay VE3WWG
@ 2004-10-07 17:37 ` Jeffrey Carter
2004-10-08 2:39 ` Alexander E. Kopilovich
` (2 more replies)
2004-10-08 1:36 ` Stephen Leake
1 sibling, 3 replies; 41+ messages in thread
From: Jeffrey Carter @ 2004-10-07 17:37 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-07 17:37 ` Jeffrey Carter
@ 2004-10-08 2:39 ` Alexander E. Kopilovich
2004-10-08 2:43 ` Nick Roberts
[not found] ` <rSftVP19_F@VB1162.spb.edu>
2 siblings, 0 replies; 41+ messages in thread
From: Alexander E. Kopilovich @ 2004-10-08 2:39 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-07 17:37 ` Jeffrey Carter
2004-10-08 2:39 ` Alexander E. Kopilovich
@ 2004-10-08 2:43 ` Nick Roberts
2004-10-08 4:56 ` tmoran
` (4 more replies)
[not found] ` <rSftVP19_F@VB1162.spb.edu>
2 siblings, 5 replies; 41+ messages in thread
From: Nick Roberts @ 2004-10-08 2:43 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-08 2:43 ` Nick Roberts
@ 2004-10-08 4:56 ` tmoran
2004-10-08 23:17 ` chris
` (3 subsequent siblings)
4 siblings, 0 replies; 41+ messages in thread
From: tmoran @ 2004-10-08 4:56 UTC (permalink / raw)
>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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-08 2:43 ` Nick Roberts
2004-10-08 4:56 ` tmoran
@ 2004-10-08 23:17 ` chris
2004-10-09 1:31 ` Jeffrey Carter
` (2 subsequent siblings)
4 siblings, 0 replies; 41+ messages in thread
From: chris @ 2004-10-08 23:17 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-08 2:43 ` Nick Roberts
2004-10-08 4:56 ` tmoran
2004-10-08 23:17 ` chris
@ 2004-10-09 1:31 ` Jeffrey Carter
2004-10-09 1:36 ` Jeffrey Carter
2004-10-14 16:46 ` Warren W. Gay VE3WWG
4 siblings, 0 replies; 41+ messages in thread
From: Jeffrey Carter @ 2004-10-09 1:31 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-08 2:43 ` Nick Roberts
` (2 preceding siblings ...)
2004-10-09 1:31 ` Jeffrey Carter
@ 2004-10-09 1:36 ` Jeffrey Carter
2004-10-09 3:15 ` Steve
` (2 more replies)
2004-10-14 16:46 ` Warren W. Gay VE3WWG
4 siblings, 3 replies; 41+ messages in thread
From: Jeffrey Carter @ 2004-10-09 1:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-09 1:36 ` Jeffrey Carter
@ 2004-10-09 3:15 ` Steve
2004-10-09 6:23 ` tmoran
[not found] ` <z7ybd.26154$hk6.998363@news20.bellglobal.com>
2004-10-09 13:20 ` Stephen Leake
2004-10-10 3:38 ` David Botton
2 siblings, 2 replies; 41+ messages in thread
From: Steve @ 2004-10-09 3:15 UTC (permalink / raw)
"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
>
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-09 3:15 ` Steve
@ 2004-10-09 6:23 ` tmoran
[not found] ` <z7ybd.26154$hk6.998363@news20.bellglobal.com>
1 sibling, 0 replies; 41+ messages in thread
From: tmoran @ 2004-10-09 6:23 UTC (permalink / raw)
>> 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.
^ permalink raw reply [flat|nested] 41+ messages in thread[parent not found: <z7ybd.26154$hk6.998363@news20.bellglobal.com>]
* Re: A community Windows binding
[not found] ` <z7ybd.26154$hk6.998363@news20.bellglobal.com>
@ 2004-10-15 1:12 ` Stephen Leake
2004-10-15 20:36 ` David Botton
0 siblings, 1 reply; 41+ messages in thread
From: Stephen Leake @ 2004-10-15 1:12 UTC (permalink / raw)
To: comp.lang.ada
"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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-15 1:12 ` Stephen Leake
@ 2004-10-15 20:36 ` David Botton
2004-10-17 13:25 ` Stephane Riviere
0 siblings, 1 reply; 41+ messages in thread
From: David Botton @ 2004-10-15 20:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-09 1:36 ` Jeffrey Carter
2004-10-09 3:15 ` Steve
@ 2004-10-09 13:20 ` Stephen Leake
2004-10-10 9:04 ` CBFalconer
2004-10-10 3:38 ` David Botton
2 siblings, 1 reply; 41+ messages in thread
From: Stephen Leake @ 2004-10-09 13:20 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-09 13:20 ` Stephen Leake
@ 2004-10-10 9:04 ` CBFalconer
2004-10-10 14:39 ` Stephen Leake
2004-10-14 16:53 ` Warren W. Gay VE3WWG
0 siblings, 2 replies; 41+ messages in thread
From: CBFalconer @ 2004-10-10 9:04 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-10 9:04 ` CBFalconer
@ 2004-10-10 14:39 ` Stephen Leake
2004-10-14 16:54 ` Warren W. Gay VE3WWG
2004-10-14 16:53 ` Warren W. Gay VE3WWG
1 sibling, 1 reply; 41+ messages in thread
From: Stephen Leake @ 2004-10-10 14:39 UTC (permalink / raw)
To: comp.lang.ada
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-10 9:04 ` CBFalconer
2004-10-10 14:39 ` Stephen Leake
@ 2004-10-14 16:53 ` Warren W. Gay VE3WWG
1 sibling, 0 replies; 41+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-10-14 16:53 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-09 1:36 ` Jeffrey Carter
2004-10-09 3:15 ` Steve
2004-10-09 13:20 ` Stephen Leake
@ 2004-10-10 3:38 ` David Botton
2 siblings, 0 replies; 41+ messages in thread
From: David Botton @ 2004-10-10 3:38 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-08 2:43 ` Nick Roberts
` (3 preceding siblings ...)
2004-10-09 1:36 ` Jeffrey Carter
@ 2004-10-14 16:46 ` Warren W. Gay VE3WWG
4 siblings, 0 replies; 41+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-10-14 16:46 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <rSftVP19_F@VB1162.spb.edu>]
* Re: A community Windows binding
[not found] ` <rSftVP19_F@VB1162.spb.edu>
@ 2004-10-08 8:18 ` Marius Amado Alves
0 siblings, 0 replies; 41+ messages in thread
From: Marius Amado Alves @ 2004-10-08 8:18 UTC (permalink / raw)
To: comp.lang.ada
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.
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-07 16:33 ` Warren W. Gay VE3WWG
2004-10-07 17:37 ` Jeffrey Carter
@ 2004-10-08 1:36 ` Stephen Leake
1 sibling, 0 replies; 41+ messages in thread
From: Stephen Leake @ 2004-10-08 1:36 UTC (permalink / raw)
To: comp.lang.ada
"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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-05 23:28 ` Stephen Leake
2004-10-06 4:26 ` David Botton
@ 2004-10-06 4:28 ` CBFalconer
2004-10-06 6:02 ` tmoran
2004-10-06 11:35 ` Georg Bauhaus
2004-10-06 6:22 ` Fionn mac Cuimhaill
` (3 subsequent siblings)
5 siblings, 2 replies; 41+ messages in thread
From: CBFalconer @ 2004-10-06 4:28 UTC (permalink / raw)
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!
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-06 4:28 ` CBFalconer
@ 2004-10-06 6:02 ` tmoran
2004-10-06 11:35 ` Georg Bauhaus
1 sibling, 0 replies; 41+ messages in thread
From: tmoran @ 2004-10-06 6:02 UTC (permalink / raw)
>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."
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-06 4:28 ` CBFalconer
2004-10-06 6:02 ` tmoran
@ 2004-10-06 11:35 ` Georg Bauhaus
2004-10-06 14:04 ` Steve
1 sibling, 1 reply; 41+ messages in thread
From: Georg Bauhaus @ 2004-10-06 11:35 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-06 11:35 ` Georg Bauhaus
@ 2004-10-06 14:04 ` Steve
0 siblings, 0 replies; 41+ messages in thread
From: Steve @ 2004-10-06 14:04 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-05 23:28 ` Stephen Leake
2004-10-06 4:26 ` David Botton
2004-10-06 4:28 ` CBFalconer
@ 2004-10-06 6:22 ` Fionn mac Cuimhaill
2004-10-06 17:18 ` Nick Roberts
` (2 subsequent siblings)
5 siblings, 0 replies; 41+ messages in thread
From: Fionn mac Cuimhaill @ 2004-10-06 6:22 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-05 23:28 ` Stephen Leake
` (2 preceding siblings ...)
2004-10-06 6:22 ` Fionn mac Cuimhaill
@ 2004-10-06 17:18 ` Nick Roberts
2004-10-07 6:38 ` Frank Piron
2004-10-07 9:44 ` Ross Higson
5 siblings, 0 replies; 41+ messages in thread
From: Nick Roberts @ 2004-10-06 17:18 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-05 23:28 ` Stephen Leake
` (3 preceding siblings ...)
2004-10-06 17:18 ` Nick Roberts
@ 2004-10-07 6:38 ` Frank Piron
2004-10-07 9:44 ` Ross Higson
5 siblings, 0 replies; 41+ messages in thread
From: Frank Piron @ 2004-10-07 6:38 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-05 23:28 ` Stephen Leake
` (4 preceding siblings ...)
2004-10-07 6:38 ` Frank Piron
@ 2004-10-07 9:44 ` Ross Higson
2004-10-07 16:39 ` Warren W. Gay VE3WWG
5 siblings, 1 reply; 41+ messages in thread
From: Ross Higson @ 2004-10-07 9:44 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 41+ messages in thread* Re: A community Windows binding
2004-10-07 9:44 ` Ross Higson
@ 2004-10-07 16:39 ` Warren W. Gay VE3WWG
2004-10-07 22:27 ` Ross Higson
0 siblings, 1 reply; 41+ messages in thread
From: Warren W. Gay VE3WWG @ 2004-10-07 16:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: A community Windows binding
2004-10-07 16:39 ` Warren W. Gay VE3WWG
@ 2004-10-07 22:27 ` Ross Higson
0 siblings, 0 replies; 41+ messages in thread
From: Ross Higson @ 2004-10-07 22:27 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 41+ messages in thread