Custom model in gtkada?

Custom model in gtkada?

[Dmitry A. Kazakov]

Does anybody know how to? (without coding in C, I mean)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[M E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Does anybody know how to? (without coding in C, I mean)

Could you explain what you mean?

Regards -- Markus

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On 13 Jun 2006 21:53:16 +0200, M E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Does anybody know how to? (without coding in C, I mean)
> 
> Could you explain what you mean?

An instance of Gtk_Tree_Model_Record like Gtk_List_Store_Record and
Gtk_Tree_Store_Record are. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Maxim Reznik]

On Tue, Jun 13, 2006 at 08:01:15PM +0200, Dmitry A. Kazakov wrote:
> Does anybody know how to? (without coding in C, I mean)
> 

I have an example in my ADBI library.
ABDI is an unified database interface for Ada. Now it works with
Firebird and Oracle. You can get it
http://www.ada-ru.org/files/adbi-0.2.tar.bz2

Coding Gtk Tree_Model in Ada was rather triО©╫ky. :-(
Look at adbi/gtk/ gtk-tree_model-db_query.ad[sb] and
gtk-tree_model-db_query-reg.ad[sb]

-- 
Maxim Reznik

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Wed, 14 Jun 2006 21:00:37 +0000 (UTC), Maxim Reznik wrote:

> On Tue, Jun 13, 2006 at 08:01:15PM +0200, Dmitry A. Kazakov wrote:
>> Does anybody know how to? (without coding in C, I mean)
> 
> I have an example in my ADBI library.
> ABDI is an unified database interface for Ada. Now it works with
> Firebird and Oracle. You can get it
> http://www.ada-ru.org/files/adbi-0.2.tar.bz2
> 
> Coding Gtk Tree_Model in Ada was rather triяПНky. :-(

This GTK+ stuff is not for my worn brain. (:-)) Why nobody did an
OS-independent widget library in Ada? There was Fresco project, I remember,
which died.

> Look at adbi/gtk/ gtk-tree_model-db_query.ad[sb] and
> gtk-tree_model-db_query-reg.ad[sb]

Thank you very much, Maxim. I will study your code.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> This GTK+ stuff is not for my worn brain. (:-)) Why nobody did an
> OS-independent widget library in Ada? There was Fresco project, I remember,
> which died.

We could copy/bind GEL, WEL, MEL, etc from the Eiffel world.
The license is fine.


Georg 

Re: Custom model in gtkada?

[Ed Falis]

I thought GTK+ was largely OS-independent, provided it's been ported?
I've targeted a largeish GTKAda application to various UNICES, OS X and
Windows without modifying its code for the targets.  Well, (to be
honest) I do use some preprocessing for pragma Imports for Windows to
retain backward compatibility with older versions of GNAT.  But that's
no longer necessary with GNAT 5.x.

Fresco was a nice design, and easier to use than GTK+, but it was no
more inherently target-independent.

- Ed

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Thu, 15 Jun 2006 17:31:56 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> This GTK+ stuff is not for my worn brain. (:-)) Why nobody did an
>> OS-independent widget library in Ada? There was Fresco project, I remember,
>> which died.
> 
> We could copy/bind GEL, WEL, MEL, etc from the Eiffel world.
> The license is fine.

How anything decent could have such names? (:-))

OK, seriously speaking, I know nothing about them. Do they support
multi-tasking?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[M E Leypold]

Ed Falis <falis@verizon.net> writes:

> I thought GTK+ was largely OS-independent, provided it's been ported?

Yes. Works fine for me. Still, GTK is a bit low level and the model
stuff reeks of C philosophy.

> I've targeted a largeish GTKAda application to various UNICES, OS X and
> Windows without modifying its code for the targets.  Well, (to be
> honest) I do use some preprocessing for pragma Imports for Windows to
> retain backward compatibility with older versions of GNAT.  But that's
> no longer necessary with GNAT 5.x.

Regards -- Markus

Re: Custom model in gtkada?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> OK, seriously speaking, I know nothing about them. Do they support
> multi-tasking?

EiffelVision2 supports multitasking insofar as there are single
threaded and multithreaded implementations of the underlying WEL,
MEL, GEL etc. libraries.
They already use agents for callbacks (for good or bad?). I think
these can be roughly equated to

  not null access procedure/function

But then the GTK is already ported to a number of OSs, as Ed has said.

(I had not known that a Gtk tree node is to be identified by
CSV-formatted numeric strings. :-)


-- Georg 

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Sat, 17 Jun 2006 17:13:34 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> OK, seriously speaking, I know nothing about them. Do they support
>> multi-tasking?
> 
> EiffelVision2 supports multitasking insofar as there are single
> threaded and multithreaded implementations of the underlying WEL,
> MEL, GEL etc. libraries.
> They already use agents for callbacks (for good or bad?). I think
> these can be roughly equated to
> 
>   not null access procedure/function

I would expect callbacks be primitive operations of a tagged type rather
than pointers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Emmanuel Briot]

Dmitry A. Kazakov wrote:
> I would expect callbacks be primitive operations of a tagged type rather
> than pointers.

This is of course a design choice, and you can easily implement a small
layer on top of GtkAda to do just that.
The advantage with pointers is that you can add or remove callbacks during
the life of a widget, which is harder to do with primitive operations where
you need flags to know whether to react to the event or not. Also you can
have multiple callbacks on the same signal, which, again, is harder to do
with primitive operations.

Emmanuel

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Thu, 22 Jun 2006 09:16:22 +0200, Emmanuel Briot wrote:

> Dmitry A. Kazakov wrote:
>> I would expect callbacks be primitive operations of a tagged type rather
>> than pointers.
> 
> This is of course a design choice, and you can easily implement a small
> layer on top of GtkAda to do just that.
> The advantage with pointers is that you can add or remove callbacks during
> the life of a widget, which is harder to do with primitive operations where
> you need flags to know whether to react to the event or not. Also you can
> have multiple callbacks on the same signal, which, again, is harder to do
> with primitive operations.

Maybe, though I doubt that events were a right design decision (as a
notification mechanism).

Another point, a list of pointers to subprograms is in no way better than a
list of tagged objects (with primitive subprograms).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Emmanuel Briot]

> Another point, a list of pointers to subprograms is in no way better than
> a list of tagged objects (with primitive subprograms).

I personnaly disagree, and since you don't provide technical, precise input,
I won't change my opinion.

Since Java's old AWT interface was using primitive subprograms, and was
replaced by SWING which uses signals, I would guess most people do believe
that signals are more flexible

Re: Custom model in gtkada?

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 22 Jun 2006 09:16:22 +0200, Emmanuel Briot wrote:
>
>> Dmitry A. Kazakov wrote:
>>> I would expect callbacks be primitive operations of a tagged type rather
>>> than pointers.
>> 
>> This is of course a design choice, and you can easily implement a small
>> layer on top of GtkAda to do just that.
>> The advantage with pointers is that you can add or remove callbacks during
>> the life of a widget, which is harder to do with primitive operations where
>> you need flags to know whether to react to the event or not. Also you can
>> have multiple callbacks on the same signal, which, again, is harder to do
>> with primitive operations.
>
> Maybe, though I doubt that events were a right design decision (as a
> notification mechanism).

How many GUI programs have you written? With how many different toolkits?

I've used Visual Basic (essentially tagged, I think :), Borland's C++
framework (tagged/dispatching), Windex (Ada tagged), GWindows (mixed
tagged/pointers), and Gtk (pointers).

I think Gtk is the best model, although the C underpinnings make
things difficult sometimes. In particular, it is difficult to detect
some errors at compile time, that the fully Ada systems can detect. At
root, the C pointers are not strongly typed.

> Another point, a list of pointers to subprograms is in no way better than a
> list of tagged objects (with primitive subprograms).

Why?

I would find a list of tagged objects confusing.

-- 
-- Stephe

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Fri, 23 Jun 2006 08:32:45 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Thu, 22 Jun 2006 09:16:22 +0200, Emmanuel Briot wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> I would expect callbacks be primitive operations of a tagged type rather
>>>> than pointers.
>>> 
>>> This is of course a design choice, and you can easily implement a small
>>> layer on top of GtkAda to do just that.
>>> The advantage with pointers is that you can add or remove callbacks during
>>> the life of a widget, which is harder to do with primitive operations where
>>> you need flags to know whether to react to the event or not. Also you can
>>> have multiple callbacks on the same signal, which, again, is harder to do
>>> with primitive operations.
>>
>> Maybe, though I doubt that events were a right design decision (as a
>> notification mechanism).
> 
> How many GUI programs have you written? With how many different toolkits?
> 
> I've used Visual Basic (essentially tagged, I think :), Borland's C++
> framework (tagged/dispatching), Windex (Ada tagged), GWindows (mixed
> tagged/pointers), and Gtk (pointers).

I used MACRO-11/Asynchronous System Traps + full-duplex terminal driver, (I
guess, it should be classified as callbacks (:-)), FORTRAN/FMS,
Ada83/C/TPU, C curses, Borland Turbo Pascal and later Delphi, C/C++
X11/Open Look, ANSI C LabVindows/CVI, Ada/C++ Windows API, LabView, Diadem
(graphical languages), now GtkAda.

> I think Gtk is the best model, although the C underpinnings make
> things difficult sometimes. In particular, it is difficult to detect
> some errors at compile time, that the fully Ada systems can detect. At
> root, the C pointers are not strongly typed.

I don't see how Ada could help there. An event is either handled or not.
"Event" is not an Ada term, so the compiler cannot check anything. An
abstract primitive subprogram is.

BTW, Gtk_Tree_Model is a clear candidate to become an interface. Thanks to
Maxim Reznik, I made an abstract tagged type from his code. It works fine
by now.

Anyway,

1. There are many communication / synchronization / notification
mechanisms. Among them events are not necessarily the best.

2. I don't see how events may influence the choice between pointers to
subprograms and primitive operations.

3. I designed soft-real time GUI libraries for Windows, where control over
resources and multitasking was essential. Especially because the data rates
(1-10ms) were sufficiently higher than the visualization rates (100ms). I
don't think that event/callback mindset is any good for such things. At
least it would require a lot of acrobatics.

>> Another point, a list of pointers to subprograms is in no way better than a
>> list of tagged objects (with primitive subprograms).
> 
> Why?
> 
> I would find a list of tagged objects confusing.

As I understood it, the point was made that procedures are good to chain a
list of event handlers. I see no difference between maintaining a list of
procedures vs. a list of handlers (objects). They are equivalent.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Jeffrey R. Carter]

Stephen Leake wrote:
> 
> I think Gtk is the best model, although the C underpinnings make
> things difficult sometimes. In particular, it is difficult to detect
> some errors at compile time, that the fully Ada systems can detect. At
> root, the C pointers are not strongly typed.

I think neither callbacks nor dispatching are good models. Callbacks are 
a way to get around C's lack of concurrency, since GUIs are inherently 
concurrent. Let the window manager control your code so you only have 1 
thread of control. The result violates locality, tends to result in lots 
of state variables global to the callbacks, is unintuitive, and is 
difficult to understand.

Dispatching is simply an attempt to model callbacks with something other 
than pointers. It has the same problems as callbacks. You can do 
something similar with generics, but it's still no improvement.

If you were designing a windowing system from scratch for a concurrent 
language such as Ada, you'd probably have a concurrent queue of events 
for each window, with a way to control what events are reported. That's 
far more straightforward and easy to understand. JEWL is an example of 
this, though very basic.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09

Re: Custom model in gtkada?

[Ed Falis]

Jeffrey R. Carter wrote:

> If you were designing a windowing system from scratch for a concurrent
> language such as Ada, you'd probably have a concurrent queue of events
> for each window, with a way to control what events are reported.

That's the way the BeOS APIs work.  Very elegant.  Check out the
Interface Kit http://www.zeta-os.com/cms/plugins/wrap/wrap.php?1.

- Ed

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Fri, 23 Jun 2006 16:59:28 GMT, Jeffrey R. Carter wrote:

> If you were designing a windowing system from scratch for a concurrent 
> language such as Ada, you'd probably have a concurrent queue of events 
> for each window, with a way to control what events are reported.

Events or messages? Are widgets active ("tasks") or passive ("protected
objects")?

BTW, "a way to control what events are reported" is IMO overriding.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> How many GUI programs have you written? With how many different toolkits?
>> 
>> I've used Visual Basic (essentially tagged, I think :), Borland's C++
>> framework (tagged/dispatching), Windex (Ada tagged), GWindows (mixed
>> tagged/pointers), and Gtk (pointers).
>
> I used MACRO-11/Asynchronous System Traps + full-duplex terminal driver, (I
> guess, it should be classified as callbacks (:-)), FORTRAN/FMS,
> Ada83/C/TPU, C curses, Borland Turbo Pascal and later Delphi, C/C++
> X11/Open Look, ANSI C LabVindows/CVI, Ada/C++ Windows API, LabView, Diadem
> (graphical languages), now GtkAda.

Excellent; we have some experience in common.

>> I think Gtk is the best model, although the C underpinnings make
>> things difficult sometimes. In particular, it is difficult to detect
>> some errors at compile time, that the fully Ada systems can detect. At
>> root, the C pointers are not strongly typed.
>
> I don't see how Ada could help there. An event is either handled or not.
> "Event" is not an Ada term, so the compiler cannot check anything. An
> abstract primitive subprogram is.

An Ada pointer to a subprogram is also strongly typed; that's what's
missing in the C code. You can easily specify a pointer to a
subprogram with the wrong parameter profile. If you are lucky, the
error will be caught at runtime, with a sort-of-helpful error message.

> BTW, Gtk_Tree_Model is a clear candidate to become an interface. Thanks to
> Maxim Reznik, I made an abstract tagged type from his code. It works fine
> by now.

Yes, there are many places where GtkAda can be made better thru Ada's
typing mechanisms.

> 1. There are many communication / synchronization / notification
> mechanisms. Among them events are not necessarily the best.

Well, of course. But that's not a very helpful statement.

For the specific case of windowing Graphical User Interfaces, I think
events are the best. For many other applications, they are not.

> 2. I don't see how events may influence the choice between pointers to
> subprograms and primitive operations.

You are correct, that is an orthogonal choice. 

> 3. I designed soft-real time GUI libraries for Windows, where control over
> resources and multitasking was essential. Especially because the data rates
> (1-10ms) were sufficiently higher than the visualization rates (100ms). I
> don't think that event/callback mindset is any good for such things. At
> least it would require a lot of acrobatics.

Clearly you don't generate GUI events for every real-time data point.

What is better than events, for this application, in your opinion? And
most importantly, why?

>>> Another point, a list of pointers to subprograms is in no way better than a
>>> list of tagged objects (with primitive subprograms).
>> 
>> Why?
>> 
>> I would find a list of tagged objects confusing.
>
> As I understood it, the point was made that procedures are good to chain a
> list of event handlers. I see no difference between maintaining a list of
> procedures vs. a list of handlers (objects). They are equivalent.

Ok, at the level of "maintain a list", yes, they are equivalent.

-- 
-- Stephe

Re: Custom model in gtkada?

[Stephen Leake]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> Stephen Leake wrote:
>> I think Gtk is the best model, although the C underpinnings make
>> things difficult sometimes. In particular, it is difficult to detect
>> some errors at compile time, that the fully Ada systems can detect. At
>> root, the C pointers are not strongly typed.
>
> I think neither callbacks nor dispatching are good models. Callbacks
> are a way to get around C's lack of concurrency, since GUIs are
> inherently concurrent. 

I disagree. I only click on one thing at a time.

I suppose lots of displays can be updated with new data
"simultaneously". But underneath, there is only one display device, so
it is not concurrent.

> Let the window manager control your code so you only have 1 thread
> of control. The result violates locality,

I'm not sure what you mean by "locality" here.

> tends to result in lots of state variables global to the callbacks,

Not in a well designed GUI framework; the window object is a parameter
to the callback; no globals.

> is unintuitive, 

Since when was anything in a computer "intuitive"? At root,
"intuition" means "innate skill, evovled in humans". Computers haven't
been around long enough for humans to co-evolve with them. 

You simply mean "unfamiliar". That is a function of time spent learning.

> and is difficult to understand.

Well, lots of people disagree.

> Dispatching is simply an attempt to model callbacks with something
> other than pointers. It has the same problems as callbacks. You can do
> something similar with generics, but it's still no improvement.

Yes, they all have similar features.

> If you were designing a windowing system from scratch for a concurrent
> language such as Ada, you'd probably have a concurrent queue of events
> for each window, with a way to control what events are reported.
> That's far more straightforward and easy to understand. 

You are saying "each window should have its own thread of control".
That's way overkill.

It's like saying "each object should have its own thread of control",
in an object oriented design, without analyzing the true concurrency.

In GWindows and GtkAda, each _thread_ has its own event queue. You can
put windows in as many threads as you need. That gives you explicit
control over the concurrency behavior. If you like, you can have one
thread per window. That will be cumbersome for most applications. It
would be possible to design a GUI system that makes that style easier.

> JEWL is an example of this, though very basic.

I have not looked at JEWL.

-- 
-- Stephe

Re: Custom model in gtkada?

[Jeffrey R. Carter]

Stephen Leake wrote:
> 
> I disagree. I only click on one thing at a time.

What is your program doing when you click? The concurrency comes from 
programs needing to do something else and respond to user events at the 
same time, which is a fairly common situation. That's easy to do with a 
concurrent language and a GUI library designed for concurrency. With a 
sequential language and sequential thinking, you get the typical C-style 
callback design, in which the GUI takes over the single thread of 
control, and you get other things to happen when you're not responding 
to user events through "idle functions".

> I'm not sure what you mean by "locality" here.

Locality is a basic SW-engineering principle. You should be familiar 
with it. It basically says that everything specific to understanding 
something should be located together. You should only have to look at 
one package spec to understand all the operations of a type declared in 
that spec, for example.

> Not in a well designed GUI framework; the window object is a parameter
> to the callback; no globals.

The window object is not the state of the program. Knowing how the 
previous event with widget X affects the program's response to this 
event with widget Y is the state.

> You simply mean "unfamiliar". That is a function of time spent learning.

No, I mean "intuitive". The standard imperative program model, in which 
the program is in control, and which almost everyone learns 1st, is 
intuitive. People grasp it easily; it corresponds to their understanding 
of how active entities function in the world. The callback model is more 
difficult to understand because it's not intuitive.

> You are saying "each window should have its own thread of control".
> That's way overkill.

No, I'm saying each window may have its own thread of control. For many 
programs, a single thread of control is sufficient. For others, there 
may be a need to update each window continuously. In such a case, each 
window having its own task is not overkill.

In the mid-1980s I considered how to implement a windowing system in 
Ada, and decided event queues were the simplest and clearest approach. I 
then used actual windowing systems, with callbacks, and saw nothing to 
change my mind. I've used CLAW, which uses type extension and 
overriding. When I used JEWL, which has an event queue, it was much 
easier to use. This is in part because JEWL is a simple windowing 
library, without the power and complexity of more complete systems. But 
it's also in part because, despite my familiarity with callback 
libraries, the event-queue model is simpler and more intuitive.

Don't take my word for it, though. Implement a few (not-too) simple 
using JEWL and your callback library of choice, and see what you think.

-- 
Jeff Carter
"I unclog my nose towards you."
Monty Python & the Holy Grail
11

Re: Custom model in gtkada?

[Alex R. Mosteo]

Jeffrey R. Carter wrote:

> In the mid-1980s I considered how to implement a windowing system in
> Ada, and decided event queues were the simplest and clearest approach. I
> then used actual windowing systems, with callbacks, and saw nothing to
> change my mind. I've used CLAW, which uses type extension and
> overriding. When I used JEWL, which has an event queue, it was much
> easier to use. This is in part because JEWL is a simple windowing
> library, without the power and complexity of more complete systems. But
> it's also in part because, despite my familiarity with callback
> libraries, the event-queue model is simpler and more intuitive.

Event queues are such a wonderful thing. I had a period of fever in which
I'd program every multitasking program with event queues. It was going to
the extreme, but there are valuable lessons there.

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Thu, 29 Jun 2006 13:11:12 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> I think Gtk is the best model, although the C underpinnings make
>>> things difficult sometimes. In particular, it is difficult to detect
>>> some errors at compile time, that the fully Ada systems can detect. At
>>> root, the C pointers are not strongly typed.
>>
>> I don't see how Ada could help there. An event is either handled or not.
>> "Event" is not an Ada term, so the compiler cannot check anything. An
>> abstract primitive subprogram is.
> 
> An Ada pointer to a subprogram is also strongly typed; that's what's
> missing in the C code. You can easily specify a pointer to a
> subprogram with the wrong parameter profile. If you are lucky, the
> error will be caught at runtime, with a sort-of-helpful error message.

Yes, but what pointers lack is safety of composition. Primitive operation
is safely inherited and required to be overridden when abstract. Also
within a primitive subprogram you are safe against re-dispatch. An
equivalent design based on pointers will always "dispatch".

>> 1. There are many communication / synchronization / notification
>> mechanisms. Among them events are not necessarily the best.
> 
> Well, of course. But that's not a very helpful statement.
> 
> For the specific case of windowing Graphical User Interfaces, I think
> events are the best. For many other applications, they are not.

For all, GTK events are probably not events, but some kind of dispatching
for poor. A 'true' event has no parameters and its handling is asynchronous
to the emitter. They lack serialization. IMO, GUI are better with messages,
because quite often the emitter needs to resynchronize itself with the
server to be sure about the state of the widget. It could also need to
receive some data back. Probably, a kind of transaction would even better,
considering low-level drawing, double buffering issues etc. Windows DCs are
much like transactions.

Another orthogonal problem is safe composition: widgets as containers,
extensible widgets. Here I don't see nothing better than some sort of
polymorphism. Events and messages are spaghetti. An alternative approach
would what we have for finalization. When a record is finalized all its
members will be finalized as well. Widget containers handle signals in
similar manner.

>> 3. I designed soft-real time GUI libraries for Windows, where control over
>> resources and multitasking was essential. Especially because the data rates
>> (1-10ms) were sufficiently higher than the visualization rates (100ms). I
>> don't think that event/callback mindset is any good for such things. At
>> least it would require a lot of acrobatics.
> 
> Clearly you don't generate GUI events for every real-time data point.
> 
> What is better than events, for this application, in your opinion? And
> most importantly, why?

In this particular case polling is better than events. The widgets are not
controlled by data flow. Instead of that there is a refresh engine which
orders the widgets to redraw themselves. But obviously keyboard input would
represent an opposite case, where polling would be wrong. One could, and
usually all GUI libraries do it, add some timer event or message. But this
makes things worse. A clean serialized model becomes in fact asynchronous,
because the sources of timer events and "normal" events are asynchronous.

IMO, Ada could provide a much cleaner view on these things, especially,
because it is natively multitasking.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Stephen Leake]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes:

> Stephen Leake wrote:
>> I disagree. I only click on one thing at a time.
>
> What is your program doing when you click? The concurrency comes from
> programs needing to do something else and respond to user events at
> the same time, which is a fairly common situation. 

In that case, the GUI is in one thread, and the "backend" is in
another (or more).

> That's easy to do with a concurrent language and a GUI library
> designed for concurrency. With a sequential language and sequential
> thinking, you get the typical C-style callback design, in which the
> GUI takes over the single thread of control, and you get other
> things to happen when you're not responding to user events through
> "idle functions".

Well, that's a poorly designed _system_. It has nothing to do with the
GUI design.

Hmm. The GUI has to allow communicating with the background thread.
But that's more of a language or communications package issue.

>> I'm not sure what you mean by "locality" here.
>
> Locality is a basic SW-engineering principle. You should be familiar
> with it. 

I'm familiar with several definitions; I'm wondering which one you are
talking about.

> It basically says that everything specific to understanding
> something should be located together. You should only have to look
> at one package spec to understand all the operations of a type
> declared in that spec, for example.

Ok, you are talking about source code "locality".

In an Ada GUI, the _spec_ for a callback is located in the same
package as the widget that provides the hook for the callback. Is that
no "local"? Obviously, the _body_ for the callback is provided by the
user.

How could it be otherwise, if a GUI is to provide a user-customizable
framework?

>> Not in a well designed GUI framework; the window object is a parameter
>> to the callback; no globals.
>
> The window object is not the state of the program. Knowing how the
> previous event with widget X affects the program's response to this
> event with widget Y is the state.

Ok. In that case, the window object needs to contain pointers to the
full state. Still no global variables.

>> You simply mean "unfamiliar". That is a function of time spent learning.
>
> No, I mean "intuitive". The standard imperative program model, in
> which the program is in control, and which almost everyone learns 1st,
> is intuitive. 

Ok, you are using a jargon definition of "intuitive". It still means
"familiar"; ie, "something I learned before".

> People grasp it easily; it corresponds to their understanding of how
> active entities function in the world. 

you mean "in computer programs they have used before". It is _not_ how
things work in the real world; physics and engineering is a better
model for that.

> The callback model is more difficult to understand because it's not
> intuitive.

Once you have grasped it, it is no more difficult.

>> You are saying "each window should have its own thread of control".
>> That's way overkill.
>
> No, I'm saying each window may have its own thread of control. 

Ok, I misunderstood.

> For many programs, a single thread of control is sufficient. For
> others, there may be a need to update each window continuously. In
> such a case, each window having its own task is not overkill.

Ok; the concurrency must be designed for the application. That's what
I've been saying.

> In the mid-1980s I considered how to implement a windowing system in
> Ada, and decided event queues were the simplest and clearest approach.
> I then used actual windowing systems, with callbacks, and saw nothing
> to change my mind. 

Now I'm confused. "event queue" is orthogonal to "callback", as far as
I can tell. The windowing systems I use have both event queues (to
store and serialize the events) and callbacks (to handle the events).

> I've used CLAW, which uses type extension and overriding. When I
> used JEWL, which has an event queue, it was much easier to use. 

I think you mean the event queue was more visible in JEWL. CLAW has an
event queue (because MS Windows does), but it's not visible to the
client packages.

> This is in part because JEWL is a simple windowing library, without
> the power and complexity of more complete systems. 

Yes.

> But it's also in part because, despite my familiarity with callback
> libraries, the event-queue model is simpler and more intuitive.

Not to me :).

> Don't take my word for it, though. Implement a few (not-too) simple
> using JEWL and your callback library of choice, and see what you
> think.

That is a reasonable request, but I don't have the time.

-- 
-- Stephe

Re: Custom model in gtkada?

[Jeffrey R. Carter]

Stephen Leake wrote:
> 
> Well, that's a poorly designed _system_. It has nothing to do with the
> GUI design.

That's the design of most windowing systems.

> How could it be otherwise, if a GUI is to provide a user-customizable
> framework?

The easiest way to answer this is to provide a complete example, which 
would be overkill here. JEWL comes with a number of examples; looking at 
a couple of those would do.

> Ok. In that case, the window object needs to contain pointers to the
> full state. Still no global variables.

I'd prefer to avoid this unnecessary use of pointers. Most windowing 
systems do not provide an easy way to associate data with a window, nor 
to access that data when responding to an event from a specific widget 
within the window.

> Ok, you are using a jargon definition of "intuitive". It still means
> "familiar"; ie, "something I learned before".
> 
> you mean "in computer programs they have used before". It is _not_ how
> things work in the real world; physics and engineering is a better
> model for that.

No, I mean the typical imperative program model, something like

do A
then do B

if some condition then
    do C
else
    do D

then do E

do F repeatedly until some other condition holds

corresponds to the way people with no programming experience describe 
how they do things. Maybe that's learned, but it's learned fairly early 
and seems pretty universal.

> Now I'm confused. "event queue" is orthogonal to "callback", as far as
> I can tell. The windowing systems I use have both event queues (to
> store and serialize the events) and callbacks (to handle the events).
> 
> I think you mean the event queue was more visible in JEWL. CLAW has an
> event queue (because MS Windows does), but it's not visible to the
> client packages.

I'm talking about the use of the system, not the details of how it's 
implemented. In the event-queue model, the client code obtains events 
from an event queue and responds to them; in the callback model the 
client associates events with subprograms it provides to the windowing 
system, yields control to the windowing system, and the windowing system 
calls the provided subprograms when it decides such calls are appropriate.

Say, even the description of the event-queue model is simpler than the 
description of the callback model.

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36

Re: Custom model in gtkada?

[Randy Brukardt]

"Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message
news:6bfpg.12754$FQ1.8736@attbi_s71...
...
> I'm talking about the use of the system, not the details of how it's
> implemented. In the event-queue model, the client code obtains events
> from an event queue and responds to them; in the callback model the
> client associates events with subprograms it provides to the windowing
> system, yields control to the windowing system, and the windowing system
> calls the provided subprograms when it decides such calls are appropriate.
>
> Say, even the description of the event-queue model is simpler than the
> description of the callback model.

That's surely true, but the problem with event-queues (at least in
real-world implementations like Windows and Mac) is that all of the possible
events come to one place. Windows has more than 800 events in its core, and
many more in the subsidiary packages. The whole reason for using tagged type
dispatching is to manage the complexity that comes from that: only sending
relevant events to the objects that care about them.

You could write such an infastructure yourself, but you will end up with
giant case statements handling and distributing events -- and the net effect
is pretty much the same as with a GUI framework, except now you have more
code to maintain.

I could imagine a hybrid framework that gave each window object its own
event queue, but then you'd need a thread of control for each object in
order that it be responsive (for instance, to a click that's intended to
bring a lower window to the top). [Or a very complex control structure.]

The truth is that GUIs are very complex beasts, and nothing is going to make
programming them simple (unless you needs are very basic [This is where JEWL
aims]). The tagged type/action handler works as well as any (it's even
better in Ada 2005 with the nesting limitations removed).

                               Randy Brukardt.

Re: Custom model in gtkada?

[Jeffrey R. Carter]

Randy Brukardt wrote:
> 
> I could imagine a hybrid framework that gave each window object its own
> event queue, but then you'd need a thread of control for each object in
> order that it be responsive (for instance, to a click that's intended to
> bring a lower window to the top). [Or a very complex control structure.]

I was thinking in terms of a queue per window, with a way to combine 
queues and to filter the events that get put on each queue.

-- 
Jeff Carter
"The time has come to act, and act fast. I'm leaving."
Blazing Saddles
36

Re: Custom model in gtkada?

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Thu, 29 Jun 2006 13:11:12 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>>> I think Gtk is the best model, although the C underpinnings make
>>>> things difficult sometimes. In particular, it is difficult to detect
>>>> some errors at compile time, that the fully Ada systems can detect. At
>>>> root, the C pointers are not strongly typed.
>>>
>>> I don't see how Ada could help there. An event is either handled or not.
>>> "Event" is not an Ada term, so the compiler cannot check anything. An
>>> abstract primitive subprogram is.
>> 
>> An Ada pointer to a subprogram is also strongly typed; that's what's
>> missing in the C code. You can easily specify a pointer to a
>> subprogram with the wrong parameter profile. If you are lucky, the
>> error will be caught at runtime, with a sort-of-helpful error message.
>
> Yes, but what pointers lack is safety of composition. Primitive operation
> is safely inherited and required to be overridden when abstract. Also
> within a primitive subprogram you are safe against re-dispatch. An
> equivalent design based on pointers will always "dispatch".

This is true, but I don't see how it is relevant to a GUI design. Of
course you want the call to "dispatch" to the user-provided operation!

If the GUI designer derives a new widget from an existing widget, the
designer must arrange for the callbacks to work properly. That can be
done with the pure pointer model, or with inherited operations.

I have not done much with deriving new widgets from existing widgets.
The few times I tried it I ended up with a totally new widget. I'd
have to go back and re-examine the details to understand why.

>>> 1. There are many communication / synchronization / notification
>>> mechanisms. Among them events are not necessarily the best.
>> 
>> Well, of course. But that's not a very helpful statement.
>> 
>> For the specific case of windowing Graphical User Interfaces, I think
>> events are the best. For many other applications, they are not.
>
> For all, GTK events are probably not events, but some kind of dispatching
> for poor. A 'true' event has no parameters and its handling is asynchronous
> to the emitter. They lack serialization. 

Well, that's an extreme definition. By that definition, no existing
GUI has an event queue.

> IMO, GUI are better with messages, because quite often the emitter
> needs to resynchronize itself with the server to be sure about the
> state of the widget. 

Indeed, in Microsoft Windows, the "events" are called "messages". In
Gtk they are called "events". I don't know what they are called in X
Windows.

> It could also need to receive some data back. Probably, a kind of
> transaction would even better, considering low-level drawing, double
> buffering issues etc. 

By "transaction", you mean something like an Ada rendezvous? Or like a
database transaction, with start, operate, end/rollback semantics?

> Windows DCs are much like transactions.

I assume "DC" = "Device Context". Yes, they do have start/operate/end
semantics. But no "roll back".

In Windex, I did the "start" and "end" parts in the top level message
handler, leaving only "operate" up to the client. That made things
simpler.

I assume the Gtk implementation for Windows uses DCs at the bottom
layer; it must do the start and end like Windex does.

> Another orthogonal problem is safe composition: widgets as containers,
> extensible widgets. Here I don't see nothing better than some sort of
> polymorphism. Events and messages are spaghetti. An alternative approach
> would what we have for finalization. When a record is finalized all its
> members will be finalized as well. Widget containers handle signals in
> similar manner.

The Gtk container widgets work pretty well for layout (position and
sizing of windows). They fail miserably when it comes to composing
event handling.

I never implemented container widgets in Windex. GWindows now has
Packing_Boxes, based on my experience with Gtk containers. We still
have not figured out a good way to compose the event handling.

Perhaps you'd like to help with that?

>>> 3. I designed soft-real time GUI libraries for Windows, where control over
>>> resources and multitasking was essential. Especially because the data rates
>>> (1-10ms) were sufficiently higher than the visualization rates (100ms). I
>>> don't think that event/callback mindset is any good for such things. At
>>> least it would require a lot of acrobatics.
>> 
>> Clearly you don't generate GUI events for every real-time data point.
>> 
>> What is better than events, for this application, in your opinion? And
>> most importantly, why?
>
> In this particular case polling is better than events. The widgets are not
> controlled by data flow. Instead of that there is a refresh engine which
> orders the widgets to redraw themselves. 

So that "order" is a GUI event, and the timing of that event is based
on how humans process visual information (minimum flicker rate
requirements). That's a good design.

> But obviously keyboard input would represent an opposite case, where
> polling would be wrong. 

Yes.

> One could, and usually all GUI libraries do it, add some timer event
> or message. 

To handle events that have timing requirements, but are asynchronous
from others, yes. Not to handle keyboard input.

> But this makes things worse. A clean serialized model becomes in
> fact asynchronous, because the sources of timer events and "normal"
> events are asynchronous.

Well, of course; that's reality. "serialized" means "in time order,
routed to the correct window". It does _not_ mean "synchronized with
some clock".

Why is that "worse"? What is the alternative?

> IMO, Ada could provide a much cleaner view on these things, especially,
> because it is natively multitasking.

Yes. But it doesn't eliminate the need for GUI events driven by timers.

-- 
-- Stephe

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Sun, 02 Jul 2006 11:17:17 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Yes, but what pointers lack is safety of composition. Primitive operation
>> is safely inherited and required to be overridden when abstract. Also
>> within a primitive subprogram you are safe against re-dispatch. An
>> equivalent design based on pointers will always "dispatch".
> 
> This is true, but I don't see how it is relevant to a GUI design. Of
> course you want the call to "dispatch" to the user-provided operation!

No I don't. More precisely I don't want it be the default. It is unsafe,
because some non-overridden behavior [already implemented and tested] of a
widget might change if some signals get overridden. Consider F1 emitting
F2. Let F2 is overridden while F1 is not. This would mean that F1 might
function differently. If W1 emits F1 it shall function exactly as it was
before W2 was derived from it.

> If the GUI designer derives a new widget from an existing widget, the
> designer must arrange for the callbacks to work properly. That can be
> done with the pure pointer model, or with inherited operations.

Yes, it is Turing complete. (:-)) I'd like to have "class-wide" and
"primitive" equivalents of signals.

> I have not done much with deriving new widgets from existing widgets.
> The few times I tried it I ended up with a totally new widget. I'd
> have to go back and re-examine the details to understand why.

Once I wrote an extensible dialog widget for Windows (in C++), which was
something like a mixture of Gtk.Boxes and a stack of widgets (subdialogs),
combined with messages handling. It was nasty. Especially handling messages
was. Because some messages propagated up the hierarchy, some did down. A
subdialog could either swallow a message (give a response), or let it
propagate. That was combined with a possibility for a widget to close
itself (and let swallow or propagate). A subdialog could catch events like
button clicks of its parents. Add here a translation of messages parameters
upon propagation...

>> It could also need to receive some data back. Probably, a kind of
>> transaction would even better, considering low-level drawing, double
>> buffering issues etc. 
> 
> By "transaction", you mean something like an Ada rendezvous? Or like a
> database transaction, with start, operate, end/rollback semantics?

Rollback upon exception would be nice. I agree, it is close to Ada
rendezvous. Messages are also close to rendezvous, one can route them etc.
However rendezvous lack marshaling, I am not sure if it is [always] bad.

>> Another orthogonal problem is safe composition: widgets as containers,
>> extensible widgets. Here I don't see nothing better than some sort of
>> polymorphism. Events and messages are spaghetti. An alternative approach
>> would what we have for finalization. When a record is finalized all its
>> members will be finalized as well. Widget containers handle signals in
>> similar manner.
> 
> The Gtk container widgets work pretty well for layout (position and
> sizing of windows). They fail miserably when it comes to composing
> event handling.

Yes, that's a problem

> I never implemented container widgets in Windex. GWindows now has
> Packing_Boxes, based on my experience with Gtk containers. We still
> have not figured out a good way to compose the event handling.
> 
> Perhaps you'd like to help with that?

I am not satisfied with my own solutions, how can I recommend them? But of
course, I'll help in what I can.

>> But this makes things worse. A clean serialized model becomes in
>> fact asynchronous, because the sources of timer events and "normal"
>> events are asynchronous.
> 
> Well, of course; that's reality. "serialized" means "in time order,
> routed to the correct window". It does _not_ mean "synchronized with
> some clock".
> 
> Why is that "worse"? What is the alternative?

Maybe model-view-controller design and decomposition across these lines.

>> IMO, Ada could provide a much cleaner view on these things, especially,
>> because it is natively multitasking.
> 
> Yes. But it doesn't eliminate the need for GUI events driven by timers.

Yes, but I suspect that in the most cases these events serve
multitasking-for-poor purpose. Ada is natively multitasking, so these
events could be replaced by explicit calls from tasks, rather than
callbacks from main loop or a hidden thread.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 02 Jul 2006 11:17:17 -0400, Stephen Leake wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> Yes, but what pointers lack is safety of composition. Primitive operation
>>> is safely inherited and required to be overridden when abstract. Also
>>> within a primitive subprogram you are safe against re-dispatch. An
>>> equivalent design based on pointers will always "dispatch".
>> 
>> This is true, but I don't see how it is relevant to a GUI design. Of
>> course you want the call to "dispatch" to the user-provided operation!
>
> No I don't. More precisely I don't want it be the default. It is unsafe,
> because some non-overridden behavior [already implemented and tested] of a
> widget might change if some signals get overridden. Consider F1 emitting
> F2. Let F2 is overridden while F1 is not. This would mean that F1 might
> function differently. If W1 emits F1 it shall function exactly as it was
> before W2 was derived from it.

Yes, that is an inherent problem in user-overridable subprograms that
are "supposed" to call other subprograms; there is no way to
enforce/check that behavior.

However, that is not unique to GUI event handling; it is a general
problem of subprogram operation specification. I would call it a bad
design to define such a callback. Or at least, such a callback should
be clearly labeled as "expert" or "dangerous".

> Yes, it is Turing complete. (:-)) I'd like to have "class-wide" and
> "primitive" equivalents of signals.

That's an interesting concept. But Gtk is already complex enough :).

>> I have not done much with deriving new widgets from existing widgets.
>> The few times I tried it I ended up with a totally new widget. I'd
>> have to go back and re-examine the details to understand why.
>
> Once I wrote an extensible dialog widget for Windows (in C++), which was
> something like a mixture of Gtk.Boxes and a stack of widgets (subdialogs),
> combined with messages handling. It was nasty. Especially handling messages
> was. Because some messages propagated up the hierarchy, some did down. A
> subdialog could either swallow a message (give a response), or let it
> propagate. That was combined with a possibility for a widget to close
> itself (and let swallow or propagate). A subdialog could catch events like
> button clicks of its parents. Add here a translation of messages parameters
> upon propagation...

Right. That's where I have problems with Gtk as well. Windex (my "pure
Ada" binding to Win32) is a little better, because I can use
Controlled types for some things. But I'm still not clear how to
handle message propagation cleanly.

On the whole, I think Gtk does the best job in GUI library design. But
it's far from "perfect".

>>> It could also need to receive some data back. Probably, a kind of
>>> transaction would even better, considering low-level drawing, double
>>> buffering issues etc. 
>> 
>> By "transaction", you mean something like an Ada rendezvous? Or like a
>> database transaction, with start, operate, end/rollback semantics?
>
> Rollback upon exception would be nice. I agree, it is close to Ada
> rendezvous. Messages are also close to rendezvous, one can route them etc.
> However rendezvous lack marshaling, I am not sure if it is [always]
> bad.

The marshalling packages in GtkAda are supremely confusing. I'd much
prefer an inheritance mechanism there. I started trying to extend
GtkAda to provide one, but I didn't have time to really work on it.
It's not a simple problem.

But I think marshalling is necessary to any real GUI event handling.

>> I never implemented container widgets in Windex. GWindows now has
>> Packing_Boxes, based on my experience with Gtk containers. We still
>> have not figured out a good way to compose the event handling.
>> 
>> Perhaps you'd like to help with that?
>
> I am not satisfied with my own solutions, 

Neither am I, with mine :).

> how can I recommend them? 

Dialog is almost always useful; the combination of two not-so-hot
ideas can sometimes produce a good solution :).

> But of course, I'll help in what I can.

Ok. The GWindows project is part of the Gnavi Sourceforge project; see
http://sourceforge.net/projects/gnavi/ . It's not very active, but
this might trigger some work.

-- 
-- Stephe

Re: Custom model in gtkada?

[Dmitry A. Kazakov]

On Tue, 04 Jul 2006 09:51:56 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 02 Jul 2006 11:17:17 -0400, Stephen Leake wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> Yes, but what pointers lack is safety of composition. Primitive operation
>>>> is safely inherited and required to be overridden when abstract. Also
>>>> within a primitive subprogram you are safe against re-dispatch. An
>>>> equivalent design based on pointers will always "dispatch".
>>> 
>>> This is true, but I don't see how it is relevant to a GUI design. Of
>>> course you want the call to "dispatch" to the user-provided operation!
>>
>> No I don't. More precisely I don't want it be the default. It is unsafe,
>> because some non-overridden behavior [already implemented and tested] of a
>> widget might change if some signals get overridden. Consider F1 emitting
>> F2. Let F2 is overridden while F1 is not. This would mean that F1 might
>> function differently. If W1 emits F1 it shall function exactly as it was
>> before W2 was derived from it.
> 
> Yes, that is an inherent problem in user-overridable subprograms that
> are "supposed" to call other subprograms; there is no way to
> enforce/check that behavior.

But tagged types in Ada enforce it. You dispatch only once. When W1.F1
calls to F2 that is W1.F2 and never W2.F2, unless the argument is
explicitly converted to W1'Class.

>>>> It could also need to receive some data back. Probably, a kind of
>>>> transaction would even better, considering low-level drawing, double
>>>> buffering issues etc. 
>>> 
>>> By "transaction", you mean something like an Ada rendezvous? Or like a
>>> database transaction, with start, operate, end/rollback semantics?
>>
>> Rollback upon exception would be nice. I agree, it is close to Ada
>> rendezvous. Messages are also close to rendezvous, one can route them etc.
>> However rendezvous lack marshaling, I am not sure if it is [always]
>> bad.
> 
> The marshalling packages in GtkAda are supremely confusing. I'd much
> prefer an inheritance mechanism there. I started trying to extend
> GtkAda to provide one, but I didn't have time to really work on it.
> It's not a simple problem.
> 
> But I think marshalling is necessary to any real GUI event handling.

Rather to any asynchronous event. If handling is synchronous, i.e. the
emitter is blocked until the action will take effect, then there is no need
to marshal anything.

I'm not sure about the relation, but it seems that a great majority of
events are synchronous. Another part is asynchronous, but can be pipelined
as a conveyer. This would be a sort of "transaction" model. The rest
(actually minor) is fully asynchronous - fire and forget. Only for the rest
one needs "hard" marshaling.

BTW, There is another way. Gtk marshals everything though it supports
garbage collection. The problem is that they didn't care to provide object
views, so that a mutator action would clone the object if anybody else
still uses it. That would be "marshaling on request."

>> But of course, I'll help in what I can.
> 
> Ok. The GWindows project is part of the Gnavi Sourceforge project; see
> http://sourceforge.net/projects/gnavi/ . It's not very active, but
> this might trigger some work.

I'll take a look, when I finish my current project. I am not sure, is it
Gtk-based or Windows API?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Custom model in gtkada?

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> The marshalling packages in GtkAda are supremely confusing. I'd much
>> prefer an inheritance mechanism there. I started trying to extend
>> GtkAda to provide one, but I didn't have time to really work on it.
>> It's not a simple problem.
>> 
>> But I think marshalling is necessary to any real GUI event handling.
>
> Rather to any asynchronous event. If handling is synchronous, i.e. the
> emitter is blocked until the action will take effect, then there is no need
> to marshal anything.

That's true.

> I'm not sure about the relation, but it seems that a great majority of
> events are synchronous. Another part is asynchronous, but can be pipelined
> as a conveyer. This would be a sort of "transaction" model. The rest
> (actually minor) is fully asynchronous - fire and forget. Only for the rest
> one needs "hard" marshaling.

True. All of the GUI frameworks I've used have not made this
distinction. It would be interesting to try to build a framework that
does.

>> Ok. The GWindows project is part of the Gnavi Sourceforge project; see
>> http://sourceforge.net/projects/gnavi/ . It's not very active, but
>> this might trigger some work.
>
> I'll take a look, when I finish my current project. I am not sure, is it
> Gtk-based or Windows API?

GWindows is built directly on the Windows API.

-- 
-- Stephe