From dsears at ncsa.uiuc.edu Wed Nov 4 18:20:43 2009 From: dsears at ncsa.uiuc.edu (Duane Searsmith) Date: Wed, 04 Nov 2009 12:20:43 -0600 Subject: [cl-gtk2-devel] SBCL Install Message-ID: <4AF1C5FB.90401@ncsa.uiuc.edu> I just installed on SBCL 1.0.18.debian and ran the demos. Everything appears to be working great! Thanks so much to everyone that has worked on this project. I'm planning on building a couple projects that will use this library. One is a text analytics framework. The other is an application/interface for software defined radio. I'm sure I'll have questions. Thanks, -- Duane From dsears at ncsa.uiuc.edu Wed Nov 4 18:20:43 2009 From: dsears at ncsa.uiuc.edu (Duane Searsmith) Date: Wed, 04 Nov 2009 12:20:43 -0600 Subject: [cl-gtk2-devel] SBCL Install Message-ID: <4AF1C5FB.90401@ncsa.uiuc.edu> I just installed on SBCL 1.0.18.debian and ran the demos. Everything appears to be working great! Thanks so much to everyone that has worked on this project. I'm planning on building a couple projects that will use this library. One is a text analytics framework. The other is an application/interface for software defined radio. I'm sure I'll have questions. Thanks, -- Duane From dsears at ncsa.uiuc.edu Wed Nov 18 22:14:04 2009 From: dsears at ncsa.uiuc.edu (Duane Searsmith) Date: Wed, 18 Nov 2009 16:14:04 -0600 Subject: [cl-gtk2-devel] Adding an Export Message-ID: <4B0471AC.7000501@ncsa.uiuc.edu> Can "(export 'widget-hide)" be added to gtk.widget.lisp? Many thanks, -- Duane From kalyanov.dmitry at gmail.com Wed Nov 18 22:43:00 2009 From: kalyanov.dmitry at gmail.com (Kalyanov Dmitry) Date: Thu, 19 Nov 2009 01:43:00 +0300 Subject: [cl-gtk2-devel] Adding an Export In-Reply-To: <4B0471AC.7000501@ncsa.uiuc.edu> References: <4B0471AC.7000501@ncsa.uiuc.edu> Message-ID: <200911190143.11253.Kalyanov.Dmitry@gmail.com> On Thursday 19 November 2009 01:14:04 Duane Searsmith wrote: > Can "(export 'widget-hide)" be added to gtk.widget.lisp? It's already added in the version in Git. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From andy128k at gmail.com Thu Nov 26 19:10:31 2009 From: andy128k at gmail.com (Andrey Kutejko) Date: Thu, 26 Nov 2009 21:10:31 +0200 Subject: [cl-gtk2-devel] let-ui & non-widget objects Message-ID: <2ea864070911261110l26df64ebnefd8ab9b5ad37813@mail.gmail.com> Hello. I have used let-ui and it's very nice for GUI. Bye-bye GtkBuilder. :) The only thing I miss is non-widget objects like GtkTreeViewColumn, GtkCellRenderer and so on. Is it possible to enhance let-ui this way? Thanks. From kalyanov.dmitry at gmail.com Thu Nov 26 19:26:41 2009 From: kalyanov.dmitry at gmail.com (Kalyanov Dmitry) Date: Thu, 26 Nov 2009 22:26:41 +0300 Subject: [cl-gtk2-devel] Test mail (ignore this) Message-ID: <200911262226.44630.Kalyanov.Dmitry@gmail.com> Ignore this -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mathrick at gmail.com Sun Nov 29 00:36:54 2009 From: mathrick at gmail.com (Maciej Katafiasz) Date: Sun, 29 Nov 2009 01:36:54 +0100 Subject: [cl-gtk2-devel] Property accessors naming Message-ID: <50b7e5180911281636i419aaa06lb1e0da4f901a936@mail.gmail.com> Hi, I'm working on wrapping GooCanvas with CL-GTK2 (as Dmitry already knows from previous private correspondence), and while it's generally very helpful, one thing that irks me are the prefixes in generated property accessors. That is, the accessor for left-padding child property in GooCanvasTable is called TABLE-CHILD-LEFT-PADDING instead of simply CHILD-LEFT-PADDING. IMHO that's completely unnecessary, and in the particular case of GooCanvas, pretty harmful as it leads to an explosion of names because of how the inheritance tree is organised. Namely, many common properties are not defined in the parent classes, but instead are defined separately in each subclass. This means I have dozens of differently-named accessors, all wrapping "width", "height", etc. A similar situation arises in child properties, as there are two classes, GooCanvasTable and GooCanvasTableModel, both defining the exact same child properties as they're each other's functional equivalents, but because they're not directly related by inheritance, I end up with a separate set of TABLE-MODEL-CHILD-* mirroring all of TABLE-CHILD-*. That's very much suboptimal. I don't believe there should ever be any reason to disambiguate the accessors' names, as they all wrap simple properties, so all have compatible lambda lists and can freely be defined as methods of a single generic function. So the only reason remaining is the somewhat prevalent convention of naming accessors CLASS-NAME-SLOT-NAME. However, I think it's particularly ugly, as well as unecessarily leaky with regard to abstractions; it shouldn't matter what exact class the accessor has been defined for, it still accesses the same slot and represents the same conceptual operation. Adding the prefix only makes the code more brittle and prone to breakages when the class hierarchy changes. So, to sum up, I'd like to request a change in how the autogenerated names in DEFINE-CHILD-PROPERTY and DEFINE-G-OBJECT-CLASS forms are constructed for properties: from the current CLASS-NAME-PROP-NAME to simple PROP-NAME. That would obviously be an API breakage, but one that should be trivial to deal with (not to mention the amount of code depending on CL-GTK2 is still fairly small), and if it was absolutely critical, the old names could be still provided in the previously published classes. It would be good, however, to clean it up before eventually moving to the long-term goal of fully introspected definitions backed by gobject-introspection, to avoid gratitious incompatibilities and ugliness in the resulting APIs. Cheers, Maciej PS. That's mail 1 resulting from the last two days of my hacking; mail 2 will be coming soon to deal with some changes I had to do in CL-GTK2 to beL able to cope with GooCanvas mimicking-but-not-deriving its child properties mechanism from GTK+'s one.