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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f26a27628ab2a2fe X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.204.131.75 with SMTP id w11mr448038bks.0.1330160811849; Sat, 25 Feb 2012 01:06:51 -0800 (PST) Path: t13ni67770bkb.0!nntp.google.com!news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: help building ada with glade Date: Sat, 25 Feb 2012 10:06:40 +0100 Organization: cbb software GmbH Message-ID: <1rlxflx3vn7d2$.gwfur2yxe3we.dlg@40tude.net> References: <66ce64dd-1428-4db1-8d0e-a4ba68f9f09d@e27g2000vbu.googlegroups.com> <1dfmw0tj24ol0.pdfi51pextgu$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: kuQH/mT1psJwQvBx6E6CEw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: 2012-02-25T10:06:40+01:00 List-Id: On Sat, 25 Feb 2012 00:12:06 +0100, J-P. Rosen wrote: > Le 24/02/2012 09:39, Dmitry A. Kazakov a �crit : >> I doubt that code generated by GLADE illustrates issues essential for >> dealing with GTK: objects (GObject), values (GValue), signals, containers >> (packing), MVC (in trees, combos, text buffers). > Exactly. Glade protects me from all that complicated mess. If I want an > action on button pressed, I select the action in Glade, and I just have > to fill the body of a subprogram named On_Key_Pressed. Do you really mean the "key-press-event"? [*] I presume you rather did "clicked" event from a button widget. If GUI consisted of only buttons, then you would need no GLADE to design such simple thing. > You may argue > that I don't learn the intrinsics of Gtk this way, fine, but I prefer > not to have to. I would argue that this nasty stuff need to be learnt in order to design GTK applications. >> I don't believe that a GUI project can be assisted with GLADE, which >> presumes its ability to incorporate user made modifications of the >> generated code. GTK is simply unsuitable for this. It is too low level, too >> messy. It lacks any means to separate the UI from the semantics. Ergo, no >> need to look into any generator (I admit, I don't know GLADE well), none >> can be good for GTK. >> > Please use it first. Not much different from MS GUI builder, which I long ago ceased to use for same reasons I never used GLADE. One lesson was enough. > A nice thing with Glade is precisely that the > semantics is well separated from all the glue, and (on Linux at least) > it is able to make round-trip engineering (i.e. : if you add stuff to > what has been generated, it is not lost the next time you regenerate > your interface). But it is impossible to do due to GTK design [**]. The most typical and safe pattern for handling signals is that a composite widget connects to a signal of its child and passes itself as a parameter to the signal handler, because you need to know it in the handler. For this Gtk.Handlers.User_Callback must be instantiated. I have no idea how a code generator could deal with this in the round-trip manner. I presume that GLADE rather uses strictly static forms when each composite widget has just one instance and all callbacks are statically bound to just one instance of the emitter and one recipient. I never use such design, even if it appears sufficient at first glance, e.g., as you said, for a casual GUI. My advice for the beginners is to learn to use GtkAda in a different way and as early as possible. That is when any widget is designed to have multiple instances and be usable as a child of any container. For each widget a corresponding Ada type is derived from some base GTK container (like Gtk_Table_Record). The children are kept hidden as well as handlers of their signals. I.e. widgets are kept opaque. -------- * Handing "key-press-event" is far from trivial in GTK. They are not emitted at all, by default, as well as the "key-release-event" signal. To handle these signals the application must modify the Gdk_Event_Mask of the widget using Set_Events, with far reaching consequences for some widgets. ** Though handling signals is important one needs much more to know how to use GTK. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de