From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!aioe.org!sk0Beg7Zrzno4hcHZ70Y5A.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: GtkAda's "On_Edited" Date: Mon, 30 May 2022 20:57:23 +0200 Organization: Aioe.org NNTP Server Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="61917"; posting-host="sk0Beg7Zrzno4hcHZ70Y5A.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.9.2 Xref: reader02.eternal-september.org comp.lang.ada:63888 List-Id: On 2022-05-30 09:46, John Perry wrote: >> On_* procedures are useless most of the time. > > I guess you mean in GtkAda? Yes. > I've found them invaluable in other contexts. If so, that's disappointing. To be fair, in the hours of reading on this I did notice that Gtk+ itself makes this difficult; the On_* procedures seem to be a GtkAda enhancement. Yes, GtkAda adds a typed layer on top of untyped GTK signals. > In the end I made it work with an On_* design, but it was your suggestion that helped! I used the second form of On_Edited and passed a TreeView in the slot. To get the model: > > Tree_View: Gtk_Tree_View := Gtk_Tree_View(Self); > Model: Gtk_Tree_Model := Get_Model( Tree_View ); > Iter : Gtk_Tree_Iter := Get_Iter_From_String(Model, Path); > Store: Gtk_List_Store := Gtk_List_Store( To_Object(Model) ); > > Getting the rest wasn't too hard after I had that. What I hadn't understood at first was that the Model had to be converted from the Interface via the To_Object function. If that is OK to you, but in production code you need a lot of stuff to do in a handler, most of it is unrelated to the tree view. This is why a custom widget is always advisable. Using a slot is a matter of taste/ I never use slots and avoid run-time type conversions. BTW, derived widgets is also a GtkAda feature, in GTK a derived widget require a lot of work. In GtkAda they are trivial. Typically in a renderer edit commit you would maintain undo/redo buffers, change the active cell for smooth navigation, [un]gray/hide a couple of buttons (like Save). Same goes with the buttons and basically with all signals. The design pattern you need to keep in mind is that a signal sent to a visual element like renderer or button, logically, is rather sent to some container widget a couple layers above. If you do not follow this logic, you will have a very complicated fragile code. > PS If anyone knows how to make the first form of On_Edited work, I'd be delighted to know. The first form can be used with a static layout and global variables. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de