* Custom model in gtkada? @ 2006-06-13 18:01 Dmitry A. Kazakov 2006-06-13 19:53 ` M E Leypold 2006-06-14 21:00 ` Maxim Reznik 0 siblings, 2 replies; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-13 18:01 UTC (permalink / raw) Does anybody know how to? (without coding in C, I mean) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-13 18:01 Custom model in gtkada? Dmitry A. Kazakov @ 2006-06-13 19:53 ` M E Leypold 2006-06-14 7:17 ` Dmitry A. Kazakov 2006-06-14 21:00 ` Maxim Reznik 1 sibling, 1 reply; 33+ messages in thread From: M E Leypold @ 2006-06-13 19:53 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-13 19:53 ` M E Leypold @ 2006-06-14 7:17 ` Dmitry A. Kazakov 0 siblings, 0 replies; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-14 7:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-13 18:01 Custom model in gtkada? Dmitry A. Kazakov 2006-06-13 19:53 ` M E Leypold @ 2006-06-14 21:00 ` Maxim Reznik 2006-06-15 7:38 ` Dmitry A. Kazakov 1 sibling, 1 reply; 33+ messages in thread From: Maxim Reznik @ 2006-06-14 21:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-14 21:00 ` Maxim Reznik @ 2006-06-15 7:38 ` Dmitry A. Kazakov 2006-06-15 15:31 ` Georg Bauhaus 0 siblings, 1 reply; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-15 7:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-15 7:38 ` Dmitry A. Kazakov @ 2006-06-15 15:31 ` Georg Bauhaus 2006-06-15 16:24 ` Ed Falis 2006-06-15 16:25 ` Dmitry A. Kazakov 0 siblings, 2 replies; 33+ messages in thread From: Georg Bauhaus @ 2006-06-15 15:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-15 15:31 ` Georg Bauhaus @ 2006-06-15 16:24 ` Ed Falis 2006-06-15 18:44 ` M E Leypold 2006-06-15 16:25 ` Dmitry A. Kazakov 1 sibling, 1 reply; 33+ messages in thread From: Ed Falis @ 2006-06-15 16:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-15 16:24 ` Ed Falis @ 2006-06-15 18:44 ` M E Leypold 0 siblings, 0 replies; 33+ messages in thread From: M E Leypold @ 2006-06-15 18:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-15 15:31 ` Georg Bauhaus 2006-06-15 16:24 ` Ed Falis @ 2006-06-15 16:25 ` Dmitry A. Kazakov 2006-06-17 15:13 ` Georg Bauhaus 1 sibling, 1 reply; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-15 16:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-15 16:25 ` Dmitry A. Kazakov @ 2006-06-17 15:13 ` Georg Bauhaus 2006-06-17 16:44 ` Dmitry A. Kazakov 0 siblings, 1 reply; 33+ messages in thread From: Georg Bauhaus @ 2006-06-17 15:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-17 15:13 ` Georg Bauhaus @ 2006-06-17 16:44 ` Dmitry A. Kazakov 2006-06-22 7:16 ` Emmanuel Briot 0 siblings, 1 reply; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-17 16:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-17 16:44 ` Dmitry A. Kazakov @ 2006-06-22 7:16 ` Emmanuel Briot 2006-06-22 8:31 ` Dmitry A. Kazakov 0 siblings, 1 reply; 33+ messages in thread From: Emmanuel Briot @ 2006-06-22 7:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-22 7:16 ` Emmanuel Briot @ 2006-06-22 8:31 ` Dmitry A. Kazakov 2006-06-22 12:08 ` Emmanuel Briot 2006-06-23 12:32 ` Stephen Leake 0 siblings, 2 replies; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-22 8:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-22 8:31 ` Dmitry A. Kazakov @ 2006-06-22 12:08 ` Emmanuel Briot 2006-06-23 12:32 ` Stephen Leake 1 sibling, 0 replies; 33+ messages in thread From: Emmanuel Briot @ 2006-06-22 12:08 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-22 8:31 ` Dmitry A. Kazakov 2006-06-22 12:08 ` Emmanuel Briot @ 2006-06-23 12:32 ` Stephen Leake 2006-06-23 13:58 ` Dmitry A. Kazakov 2006-06-23 16:59 ` Jeffrey R. Carter 1 sibling, 2 replies; 33+ messages in thread From: Stephen Leake @ 2006-06-23 12:32 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-23 12:32 ` Stephen Leake @ 2006-06-23 13:58 ` Dmitry A. Kazakov 2006-06-29 17:11 ` Stephen Leake 2006-06-23 16:59 ` Jeffrey R. Carter 1 sibling, 1 reply; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-23 13:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-23 13:58 ` Dmitry A. Kazakov @ 2006-06-29 17:11 ` Stephen Leake 2006-06-30 12:29 ` Dmitry A. Kazakov 0 siblings, 1 reply; 33+ messages in thread From: Stephen Leake @ 2006-06-29 17:11 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-29 17:11 ` Stephen Leake @ 2006-06-30 12:29 ` Dmitry A. Kazakov 2006-07-02 15:17 ` Stephen Leake 0 siblings, 1 reply; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-30 12:29 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-30 12:29 ` Dmitry A. Kazakov @ 2006-07-02 15:17 ` Stephen Leake 2006-07-03 18:23 ` Dmitry A. Kazakov 0 siblings, 1 reply; 33+ messages in thread From: Stephen Leake @ 2006-07-02 15:17 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-07-02 15:17 ` Stephen Leake @ 2006-07-03 18:23 ` Dmitry A. Kazakov 2006-07-04 13:51 ` Stephen Leake 0 siblings, 1 reply; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-07-03 18:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-07-03 18:23 ` Dmitry A. Kazakov @ 2006-07-04 13:51 ` Stephen Leake 2006-07-05 13:06 ` Dmitry A. Kazakov 0 siblings, 1 reply; 33+ messages in thread From: Stephen Leake @ 2006-07-04 13:51 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-07-04 13:51 ` Stephen Leake @ 2006-07-05 13:06 ` Dmitry A. Kazakov 2006-07-06 7:10 ` Stephen Leake 0 siblings, 1 reply; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-07-05 13:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-07-05 13:06 ` Dmitry A. Kazakov @ 2006-07-06 7:10 ` Stephen Leake 0 siblings, 0 replies; 33+ messages in thread From: Stephen Leake @ 2006-07-06 7:10 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-23 12:32 ` Stephen Leake 2006-06-23 13:58 ` Dmitry A. Kazakov @ 2006-06-23 16:59 ` Jeffrey R. Carter 2006-06-23 17:37 ` Ed Falis ` (2 more replies) 1 sibling, 3 replies; 33+ messages in thread From: Jeffrey R. Carter @ 2006-06-23 16:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-23 16:59 ` Jeffrey R. Carter @ 2006-06-23 17:37 ` Ed Falis 2006-06-23 18:11 ` Dmitry A. Kazakov 2006-06-29 17:20 ` Stephen Leake 2 siblings, 0 replies; 33+ messages in thread From: Ed Falis @ 2006-06-23 17:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-23 16:59 ` Jeffrey R. Carter 2006-06-23 17:37 ` Ed Falis @ 2006-06-23 18:11 ` Dmitry A. Kazakov 2006-06-29 17:20 ` Stephen Leake 2 siblings, 0 replies; 33+ messages in thread From: Dmitry A. Kazakov @ 2006-06-23 18:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-23 16:59 ` Jeffrey R. Carter 2006-06-23 17:37 ` Ed Falis 2006-06-23 18:11 ` Dmitry A. Kazakov @ 2006-06-29 17:20 ` Stephen Leake 2006-06-29 20:08 ` Jeffrey R. Carter 2 siblings, 1 reply; 33+ messages in thread From: Stephen Leake @ 2006-06-29 17:20 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-29 17:20 ` Stephen Leake @ 2006-06-29 20:08 ` Jeffrey R. Carter 2006-06-30 10:28 ` Alex R. Mosteo 2006-06-30 16:07 ` Stephen Leake 0 siblings, 2 replies; 33+ messages in thread From: Jeffrey R. Carter @ 2006-06-29 20:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-29 20:08 ` Jeffrey R. Carter @ 2006-06-30 10:28 ` Alex R. Mosteo 2006-06-30 16:07 ` Stephen Leake 1 sibling, 0 replies; 33+ messages in thread From: Alex R. Mosteo @ 2006-06-30 10:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-29 20:08 ` Jeffrey R. Carter 2006-06-30 10:28 ` Alex R. Mosteo @ 2006-06-30 16:07 ` Stephen Leake 2006-06-30 19:45 ` Jeffrey R. Carter 1 sibling, 1 reply; 33+ messages in thread From: Stephen Leake @ 2006-06-30 16:07 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-30 16:07 ` Stephen Leake @ 2006-06-30 19:45 ` Jeffrey R. Carter 2006-06-30 22:41 ` Randy Brukardt 0 siblings, 1 reply; 33+ messages in thread From: Jeffrey R. Carter @ 2006-06-30 19:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-30 19:45 ` Jeffrey R. Carter @ 2006-06-30 22:41 ` Randy Brukardt 2006-07-01 5:11 ` Jeffrey R. Carter 0 siblings, 1 reply; 33+ messages in thread From: Randy Brukardt @ 2006-06-30 22:41 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Custom model in gtkada? 2006-06-30 22:41 ` Randy Brukardt @ 2006-07-01 5:11 ` Jeffrey R. Carter 0 siblings, 0 replies; 33+ messages in thread From: Jeffrey R. Carter @ 2006-07-01 5:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2006-07-06 7:10 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-06-13 18:01 Custom model in gtkada? Dmitry A. Kazakov 2006-06-13 19:53 ` M E Leypold 2006-06-14 7:17 ` Dmitry A. Kazakov 2006-06-14 21:00 ` Maxim Reznik 2006-06-15 7:38 ` Dmitry A. Kazakov 2006-06-15 15:31 ` Georg Bauhaus 2006-06-15 16:24 ` Ed Falis 2006-06-15 18:44 ` M E Leypold 2006-06-15 16:25 ` Dmitry A. Kazakov 2006-06-17 15:13 ` Georg Bauhaus 2006-06-17 16:44 ` Dmitry A. Kazakov 2006-06-22 7:16 ` Emmanuel Briot 2006-06-22 8:31 ` Dmitry A. Kazakov 2006-06-22 12:08 ` Emmanuel Briot 2006-06-23 12:32 ` Stephen Leake 2006-06-23 13:58 ` Dmitry A. Kazakov 2006-06-29 17:11 ` Stephen Leake 2006-06-30 12:29 ` Dmitry A. Kazakov 2006-07-02 15:17 ` Stephen Leake 2006-07-03 18:23 ` Dmitry A. Kazakov 2006-07-04 13:51 ` Stephen Leake 2006-07-05 13:06 ` Dmitry A. Kazakov 2006-07-06 7:10 ` Stephen Leake 2006-06-23 16:59 ` Jeffrey R. Carter 2006-06-23 17:37 ` Ed Falis 2006-06-23 18:11 ` Dmitry A. Kazakov 2006-06-29 17:20 ` Stephen Leake 2006-06-29 20:08 ` Jeffrey R. Carter 2006-06-30 10:28 ` Alex R. Mosteo 2006-06-30 16:07 ` Stephen Leake 2006-06-30 19:45 ` Jeffrey R. Carter 2006-06-30 22:41 ` Randy Brukardt 2006-07-01 5:11 ` Jeffrey R. Carter
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox