From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: hreba Newsgroups: comp.lang.ada Subject: Re: Where do I get my Cairo context from (in GTK3)? Date: Wed, 27 Apr 2016 15:15:40 +0200 Message-ID: References: <0a9cf35e-45ba-49c1-9d6a-4a0da3457e70@googlegroups.com> <31e4394b-eb85-4d31-bd25-f2bd332c7c9b@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net CZFfjjDTmb54fpomXPwKhg4HPyDk4wbniW20Bd8OXJc1mZ+67k Cancel-Lock: sha1:GaRCvr47ixXtrOCSAqDpsynAqt4= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <31e4394b-eb85-4d31-bd25-f2bd332c7c9b@googlegroups.com> Xref: news.eternal-september.org comp.lang.ada:30303 Date: 2016-04-27T15:15:40+02:00 List-Id: On 04/27/2016 09:47 AM, briot.emmanuel@gmail.com wrote: >> I would use On_* procedures if I didn't need user data. Until now no >> success. > > Are you sure you really need that user data ? In my experience, it is often > better to extend the widget type in your application, store whatever information > is needed in that child type, and then use the On_* procedure passing a Slot > object (so that the callback receives your widget type, rather than the widget > on which the action occurred). This works in 95% of the cases. > > The GNAT Development Studio (GPS), which is about 500_000 lines of code > has almost no use of user data, and those that remain are mostly because > that part of the code hasn't been updated yet. > I am creating a drawing surface, a new layer for isolating the end user from GTK. The idea is that the end user gets a constructor for a new type "Canvas". He has to specify 3 handlers: the first is called once after the canvas appears on the screen, the second is called after each resizing, the third one when the canvas needs redrawing. Drawing is done by calling a series of of standardized drawing procedures (for lines, arcs etc.) The end user needs no knowledge about connecting handlers, about cairo contexts or "Stroke" calls. He gets a framework for technical drawings with a simple user interface. The drawing handler at the end user level is a subprogram with basically one parameter: the user data which specifies what has to be drawn. I am implementing the framework and I don't now what the end user will draw, so I write a GTK "draw" handler which calls the handler of the end user and passes the end user's data. Probably I will never do it, but in principle the framework could be implemented with other graphics toolkits than GTK and the end user would have the same API. Meanwhile I have found a solution for my problem. It compiles but is not tested yet. It doesn't use a marshaller: -- package DA_Ret_Callback is new Gtk.Handlers.User_Return_Callback (Gtk.Drawing_Area.Gtk_Drawing_Area_Record, Boolean, Handler_DataD); function Draw_Handler (da: access Gtk.Drawing_Area.Gtk_Drawing_Area_Record'Class; pars: Glib.Values.GValues; hd: Handler_DataD) return Boolean is begin hd.can.cc:= Cairo.Get_Context (Glib.Values.Nth(pars, 1)); hd.Draw (hd.data, hd.gads); return True; -- don't propagate signal further end Draw_Handler; procedure Connect_Handlers (obj: Glib.Object.GObject; hd: Handler_DataD; sn_realize, sn_config, sn_draw: Glib.Signal_Name) is begin ... DA_Ret_Callback.Connect (Gtk.Drawing_Area.Gtk_Drawing_Area(obj), sn_draw, Draw_Handler'Access, hd); end Connect_Handlers; -- hd.Draw is the drawing handler of the end user, and hd.data is the end user's data. -- Frank Hrebabetzky +49 / 6355 / 989 5070