GTK+ 2.12.8 released
GTK+ 2.12.8 is now available for download at: http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.12/ gtk+-2.12.8.tar.bz2 md5sum: 1e0d7db0bfa210881743e1d42ee91a24 gtk+-2.12.8.tar.gzmd5sum: f8ff1c2b418cf7ca80f8b96e31ef12dc This is a bug fix release in the 2.12 series. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.12.7 to 2.12.8 == * Make the directfb backend build with GLib 2.15 * Improve the handling of modal windows on win32 * GtkFileChooser: - Activate bookmarks on single-click - Improve some focus handling issues - Don't select filename extensions in the save dialog * Bugs fixed: 499835 No object:state-changed:selected event when [un]selecti... 516024 filechooser critical warning when loading thumbnail pixbufs 144269 GtkHPaned flickers and leaves widgets in child panels unr... 419737 File save dialog deletes/empties filename when changing d... 148828 Side Pane in File Selector requires double-click 455627 Keyboard input gets confused with modal windows 473786 Needs keyboard navigation for gtkstatusicon 494515 GdkPixbufLoader does not always return an image at the si... 499940 Focus shouldn't go to file list when selecting a bookmark 503569 Leak in GtkTreeViewColumn 505928 Right-clicking taskbar entry for minimized window causes ... 51 [Win32] Modal dialogs should affect the entire applicatio... 511987 filter is not working 514621 Crash when changing model while handling GtkTreeSelection... 514643 Hiding a modal window still causes its parents to be blocked 514789 Clicking a menu in a maximized windowcauses it to restore... 515047 check for all return/space keys consistently 515667 gtk_file_chooser_get_current_folder_uri does not check fo... 362516 File extensions should not be selected by default * Updated translations: Greek (el) Spanish (es) Galician (gl) Hebrew (he) Brazilian Portugese (pt_BR) Slovak (sk) Swedish (sv) A list of all the bugs fixed in this release can be found here: http://bugzilla.gnome.org/buglist.cgi?bug_id=144269,505928,148828,499940,419737,514789,511987,503569,473786,514621,515047,499835,362516,515667,455627,51,514643,514789,494515,516024 Thanks to all contributors: Richard Hult Cody Russell Sven Neumann Federico Mena Quintero Josselin Mouette Sven Herzberg Jonh Wendell Emmanuele Bassi Kristian Rietveld Li Yuan Andreas Koehler Christian Persch Rich Burridge LiYan Zhang Francesco Montorsi Mike Morrison February 12, 2008 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE:
On 12-Feb-2008 Markus Müller wrote: . . . The widgets will be nested: The train-widget provides a array of vehicles which provides a array of waggons with an array of cameras... Accessing the object properties can be done with references/pointers to the data variables (the normal access to struct-members e.g.: train.vehicle[1].waggon[4].camera[3].colour = green) One of the biggest questions therefore is the structure of the necessary manipulating functions: How can i best handle e.g. the redrawing of a camera when its de-/selected (In C++ i would create a member-function to the camera-object!?). I think to create a function set for every widget which can always provide the interface for the upper parent instance!? Alternative there could be a set of top level functions, but therefore the parameters are getting kind of nasty !? it would be much the same in the gtk environment. You will associate a callback when the object is deselected. Depending upon the type of object, you will have a callback on, e.g. a clicked event. My initial reaction is that you might draw your camera on a button, and associate a clicked event with the button, and the callback would redraw the object w/ the appropriate colour. If you need the redraw to be done when ANOTHER event happens (e.g. some OTHER object is selected/deselected, then obviously you need to store a handle to the camera object somewhere. How this is done is left as an exercise to the reader. Common ways are: g_object_set/get_data(), creating a class like structure, and passing the handle to that structure (or that structure instance, as the case might be), as the callback arg, global arrays/structures, etc. I find the last to be too dirty for my tastes (I like encapsulation). I find the first to be messy (but quite common, and convenient, in gtk code). At the moment, I'm gravitating towards the 2nd approach, and passing a structure pointer as the callback arg, which allows me to pass as much/little information into the callback as I need to (and it's more class like in it's approach). (I should hasten to point out that while I listed only 3 approaches, I'm sure that creativity can come up with others... :) I think, at the end of the day, how you organize your data will be key in how you will be able to access it, and pass it around. That is to say that your data organization will more or less dictate your choice of parameter accessability (or vice versa. if you eant to enforce from the accessability point of view, then that will dictate how the data must be organized). best rgds, -Greg +-+ Please also check the log file at /dev/null for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Strange warning when adding gtk_status_bar to gtk_hbox
Just for those who are interested: I finally managed to get rid of the warning by issuing gtk_statusbar_set_has_resize_grip(GTK_STATUSBAR(_status_bar), false) before adding the status bar to the hbox. The resize grip did not make any sense anyways (just didn't know this was a property) and apparently it could not find the window it was attached to. Best regards, Torsten On Jan 28, 2008 5:02 PM, Torsten Reuss [EMAIL PROTECTED] wrote: Thanks for the reply, Mikael. On Jan 28, 2008 3:13 PM, Mikael Hallendal [EMAIL PROTECTED] wrote: I'm in the process of porting an application from GTK 1.2 to GTK 2.12. One thing I can't get behind is a warning I am getting concerning a gtk_status_bar widget. The warning: Gdk-CRITICAL **: gdk_window_set_cursor: assertion `GDK_IS_WINDOW (window)' failed It looks odd that that the code you pasted will give this warning and it sounds like it's actually coming from some other part. I thought the saem, but I verified by debugging and by printing out output before and after this line, that it is in fact this line. Just one thing I noticed though (not sure if it is just here or if you actually pasted code) is that you leak a GtkStatusBar. In the actual code _status_bar is a member variable of the dialog class, so the status bar is not leaked. I just pasted minimum code here in hope that this warning rings a bell for someone, as too me it really makes very little sense. Thanks and regards, Torsten ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Gorshkov wrote: Lack of patience, and the feeling that I was talking to a brick wall, to be perfectly honest. I even posted all the code he needed to implement the solution - and given that it was only about 20 or 30 lines total, I wouldn't exactly call it overly complicated. The only code I did not give him was the code to actually save the data to a file - everything else - the signal handlers, callbacks, etc, is there. I had already implemented the solution you gave me before I resurrected the old thread. It works for restoring the column widths after exiting and restarting the program. My lengthy comments were not criticism of your suggestion but an attempt to explain why its application does not meet all of my needs in a straightforward manner. The remaining problem is that a remote section of code needs to know the column widths while the program is running. It would have been trivial to obtain the information from the file, but the file does not get updated when the column widths change, only when the treeview is destroyed. The solution which you, Dave Howorth, and even I have suggested in this thread is to read the column widths from the treeview. Usually, implementing that solution is also trivial. It is not trivial in my situation because the remote section of code does not know about the treeview. Nevertheless, the solution is practicable. Note that in my original posting I did not ask for a solution, I asked why GTK has this small limitation. I understand that there is a way to implement a solution, but I long for the solution that would have been trivial. The implication that writing the file when the treeview is destroyed is equivalent to writing it when the column widths change is wrong. Although there are cases where the two approaches are equivalent, they are not equivalent in situations that Scott and I have encountered. Moreover, the designers of Qt and wxWidgets evidently don't consider the two approaches to be equivalent because they chose to support both. My objective in posting my message was simply to encourage the designers of GTK also to support both. With that resolution, you would be free to continue to use the destroy signal and I would be free to use the column-width-changed signal, even if we were both doing so out of stubborn adherence to the familiar. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Placing Widgets over another on the screen
Hello all, i created two widget classes. The first one (Widget A) draws a simple square with a predefined color in a drawingarea . This widget should have four members of the second widget (Widget B) which has the same architecture and draws a simple self-defined symbol. The placement on the screen should finally look like that the four little symbols are placed (like in a hbox) in the square. The color of the symols has to be changed during runtime by events/callbacks. Everything compiles well, with program start Widget A is created and drawn and also all four Widgets B can be created. When trying to add the Widgets B to A like gtk_container_add(GTK_CONTAINER(Widget_A),Widget_B); the console creates an error that Widget A (of coursce) is no Containter-Class but Widget A-Class... Q1) Is there a way to configure my Widget A to contain others widgets so they can be drawn too like mentioned above or Q2) Is there another principial mechanism to draw widgets over another Best regards Markus - Gersys GmbH, Hans-Urmiller-Ring 46c, D-82515 Wolfratshausen, Germany Geschaeftsfuehrer: Erwin Sterzer, HRB 137 872 Muenchen, Fon: +49(0)8171 9986-6 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Filechooser and Bookmarks spec
On Mon, 2008-02-11 at 18:01 +0100, nf2 wrote: Or perhaps GIO could be split into two *.so libraries . One for file-management and one for the file chooser shortcuts API, GAppInfo, ... Extra libraries make applications more bloated (at least 4kb nonsharable memory per process using the library), whereas adding unused code to a library hardly affects a process using that library at all. So, its more likely that things will be added to libgio.so rather than in separate libraries. This has been discussed a lot recently, and the likely approach we'll have for future additions of gobject based glib APIs is to put them in libgio.so, but have them be a separate .pc file. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.12.8 released
GTK+ 2.12.8 is now available for download at: http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.12/ gtk+-2.12.8.tar.bz2 md5sum: 1e0d7db0bfa210881743e1d42ee91a24 gtk+-2.12.8.tar.gzmd5sum: f8ff1c2b418cf7ca80f8b96e31ef12dc This is a bug fix release in the 2.12 series. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.12.7 to 2.12.8 == * Make the directfb backend build with GLib 2.15 * Improve the handling of modal windows on win32 * GtkFileChooser: - Activate bookmarks on single-click - Improve some focus handling issues - Don't select filename extensions in the save dialog * Bugs fixed: 499835 No object:state-changed:selected event when [un]selecti... 516024 filechooser critical warning when loading thumbnail pixbufs 144269 GtkHPaned flickers and leaves widgets in child panels unr... 419737 File save dialog deletes/empties filename when changing d... 148828 Side Pane in File Selector requires double-click 455627 Keyboard input gets confused with modal windows 473786 Needs keyboard navigation for gtkstatusicon 494515 GdkPixbufLoader does not always return an image at the si... 499940 Focus shouldn't go to file list when selecting a bookmark 503569 Leak in GtkTreeViewColumn 505928 Right-clicking taskbar entry for minimized window causes ... 51 [Win32] Modal dialogs should affect the entire applicatio... 511987 filter is not working 514621 Crash when changing model while handling GtkTreeSelection... 514643 Hiding a modal window still causes its parents to be blocked 514789 Clicking a menu in a maximized windowcauses it to restore... 515047 check for all return/space keys consistently 515667 gtk_file_chooser_get_current_folder_uri does not check fo... 362516 File extensions should not be selected by default * Updated translations: Greek (el) Spanish (es) Galician (gl) Hebrew (he) Brazilian Portugese (pt_BR) Slovak (sk) Swedish (sv) A list of all the bugs fixed in this release can be found here: http://bugzilla.gnome.org/buglist.cgi?bug_id=144269,505928,148828,499940,419737,514789,511987,503569,473786,514621,515047,499835,362516,515667,455627,51,514643,514789,494515,516024 Thanks to all contributors: Richard Hult Cody Russell Sven Neumann Federico Mena Quintero Josselin Mouette Sven Herzberg Jonh Wendell Emmanuele Bassi Kristian Rietveld Li Yuan Andreas Koehler Christian Persch Rich Burridge LiYan Zhang Francesco Montorsi Mike Morrison February 12, 2008 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Release download locations
On Tue, 2008-02-12 at 19:04 -0600, Cody Russell wrote: The gtk.org website's download section links to ftp://ftp.gtk.org/pub/gtk/2.12/ and it appears that Matthias posts the releases to http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.12/ Going by the website, the latest release shown on the front page is 2.12.3, and the latest release on ftp.gtk.org is 2.12.6. So, two things: Should the download URL just be switched to ftp.gnome.org? And do we need someone to update the news on the front page when releases are made? I don't mind volunteering for this for now if it's something that needs doing. What I typically do when releasing pango is: - Upload to gnome.org and install-module - Wait for mirrors to catch up, sending out release announcement to fill the time - ssh to gtk.org and run my script to mirror the tarballs from gnome.org. That is, if the harddisk is not full again... - If I remember to do it, update the webpage. Also note that the preferred address for gnome.org tarballs is download.gnome.org/ / Cody -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pidl - an IDL for GObject boilerplate and language bindings
Good to see others working on abstractions like this. We have a closed
system for internal use, but it was developed to do much of the same
by reimplementing/extending the GOB syntax and writing a new
compiler for it. Simultaneous code is output in both C/C++ with an
introspection system added for both methods and static methods (in
addition to properties which already exist in GObject) that allows
automatic bindings for JS integration. Standard public/private methods
are still allowed, but just don't get any JS binding. GOB isn't
exactly an IDL, but it accomplishes the same feat when tweaked. The
advantage is that you don't have to maintain a separate IDL file and
implementation. This is still possible, of course, by only exposing
GInterfaces to the binding and declaring everything via an interface.
Example:
interface Foo from G:Interface
{
public void foo(void);
}
[Design:Time:Attribute(...)]
class My:Object from G:Object
(interface Foo)
{
private gint my_variable = 5;
private GList *my_list = NULL destroywith g_list_free;
static_method My:Object marshal_as OBJECT (NONE) Self *
new(void)
{
return GET_NEW;
}
[Design:Time:Attribute(...)]
method BOOL (INT, G:Error:Ref marshal_as POINTER) gboolean
my_class_method(self, gint foo, GError **error)
{
g_debug(__GOB_FUNCTION__: value: %d, selfp-my_variable);
g_set_error(error, ...);
return FALSE;
}
public void
method_only_to_c_cpp_callers(void)
{
}
interface Foo
private void
foo(void)
{
}
}
Automatically becomes (in JS):
var foo = new MyObject();
foo.foo();
foo.my_class_method(5));
... throws an exception here
-Andrew
On Feb 12, 2008 10:18 AM, Christian Berentsen
[EMAIL PROTECTED] wrote:
https://launchpad.net/pidl
Pidl is an Interface Description Language for GObject C-code with
automatic language bindings.
The programmer mainly writes '.pidl' files and implementation in C. Much
GObject boilerplate is hidden.
Language bindings are automatically generated.
(Currently for Python, C++ and C#)
As we are developing a product relying heavily on GObject, we came to
the conclusion that the risk of having every developer handling
boilerplate code could become a big maintenance headache.
Pidl is still in its infancy and is being evolved on a day to day basis.
The system is developed in TDD fashion, with test coverage in Python.
Could this be interesting for anybody else writing GObject based
software?
Current feature summary:
Emits C++, Python and C# (and GObject front stubs in C)
Supports classes, interfaces, properties, methods, and signals.
Supports implementing interfaces in C++ and C# (not yet Python)
Enums
Errors/Exceptions on methods marked as throwing. (GError marshalled to
language exceptions, modelled after dbus-glib)
Weak references (Properties only)
Inheritance
and more.
--
Jarl Christian Berentsen
Ole Andre Vadla Ravnaas
(Pidl core monkeys)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Release download locations
The gtk.org website's download section links to ftp://ftp.gtk.org/pub/gtk/2.12/ and it appears that Matthias posts the releases to http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.12/ Going by the website, the latest release shown on the front page is 2.12.3, and the latest release on ftp.gtk.org is 2.12.6. So, two things: Should the download URL just be switched to ftp.gnome.org? And do we need someone to update the news on the front page when releases are made? I don't mind volunteering for this for now if it's something that needs doing. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
visible window rectangle in pixmap redirection
hi Alex. it'd be great if you could take a look at my latest comment on the offscreen windows bug report, i.e.: http://bugzilla.gnome.org/show_bug.cgi?id=318807#c48 it adresses just the pixmap redirection portions that you split off some while ago and lists remaining issues that need solving before inclusion. in particular, i'd like to know: - gtk_widget_get_snapshot() is supposed to snapshot whole widgets (i.e. all of widget-allocation.width/height). so why is gdk_window_end_paint() calling _gdk_window_calculate_full_clip_region() (indirectly via setup_redirect_clip()) to constrain the redirected area to the visible widget area? - why is _gdk_windowing_window_get_visible_rect() a backend specific function? couldn't we get the visible rectangle of a window from window-parent-width/height and window-x/y? - i'm wondering if there is a use case at all for snapshooting *only* the visible area of a widget. i think the semantics of gtk_widget_get_snapshot() are fine if it snapshoots all of a widgets allocation, and i'd like to get rid of all the clip-to-visible-rect logic. if there is indeed a use case for snapshoting only the visible portion of a widget (afaics relevant in scrolled window contexts only), we should be able to simply provide: void gtk_widget_get_visible_rect (Widget*, Rect*); that provides coordinates for use with gtk_widget_get_snapshot(). thanks for the patch in the first place. i think the above are the last major issues left before pixmap redirection can go in. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pidl - an IDL for GObject boilerplate and language bindings
https://launchpad.net/pidl Pidl is an Interface Description Language for GObject C-code with automatic language bindings. The programmer mainly writes '.pidl' files and implementation in C. Much GObject boilerplate is hidden. Language bindings are automatically generated. (Currently for Python, C++ and C#) As we are developing a product relying heavily on GObject, we came to the conclusion that the risk of having every developer handling boilerplate code could become a big maintenance headache. Pidl is still in its infancy and is being evolved on a day to day basis. The system is developed in TDD fashion, with test coverage in Python. Could this be interesting for anybody else writing GObject based software? Current feature summary: Emits C++, Python and C# (and GObject front stubs in C) Supports classes, interfaces, properties, methods, and signals. Supports implementing interfaces in C++ and C# (not yet Python) Enums Errors/Exceptions on methods marked as throwing. (GError marshalled to language exceptions, modelled after dbus-glib) Weak references (Properties only) Inheritance and more. -- Jarl Christian Berentsen Ole Andre Vadla Ravnaas (Pidl core monkeys) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ Team Meeting -- 12 February 2008
On Tue, 2008-02-12 at 16:04 +0100, Tim Janik wrote: the points are: * Remove linux-fb backend because it's unmaintained since stone age (mitch) * Add GRegion (bug 508540) (Benjamin Otte) * Offscreen redirection (bug 318807) (ebassi) * Miscellaneous i'd like to add: * Migrating gtk.org contents to the machine that is currently cube.gtk.org added to the wiki page, thanks. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] GTK+ Team Meeting -- 12 February 2008
hi everyone; this is the usual reminder for the IRC GTK+ Team Meeting. the meeting will be held in the #gtk-devel channel on irc.gnome.org, at 20:00 UTC[1]. the points are: * Remove linux-fb backend because it's unmaintained since stone age (mitch) * Add GRegion (bug 508540) (Benjamin Otte) * Offscreen redirection (bug 318807) (ebassi) * Miscellaneous eventual changes will be notified on the wiki page[0]. everyone can participate, as usual. ciao, Emmanuele. +++ [0] http://live.gnome.org/GTK+/Meetings [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=2day=12year=2008hour=20min=0sec=0p1=0 -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pidl - an IDL for GObject boilerplate and language bindings
Sounds good! I am actually mostly interesting in such a system, that could wrap c++ classes, but I guess this system could be extended to do such a thing. Maybe a nice project for one day:) On 2/12/08, Christian Berentsen [EMAIL PROTECTED] wrote: https://launchpad.net/pidl Pidl is an Interface Description Language for GObject C-code with automatic language bindings. The programmer mainly writes '.pidl' files and implementation in C. Much GObject boilerplate is hidden. Language bindings are automatically generated. (Currently for Python, C++ and C#) As we are developing a product relying heavily on GObject, we came to the conclusion that the risk of having every developer handling boilerplate code could become a big maintenance headache. Pidl is still in its infancy and is being evolved on a day to day basis. The system is developed in TDD fashion, with test coverage in Python. Could this be interesting for anybody else writing GObject based software? Current feature summary: Emits C++, Python and C# (and GObject front stubs in C) Supports classes, interfaces, properties, methods, and signals. Supports implementing interfaces in C++ and C# (not yet Python) Enums Errors/Exceptions on methods marked as throwing. (GError marshalled to language exceptions, modelled after dbus-glib) Weak references (Properties only) Inheritance and more. -- Jarl Christian Berentsen Ole Andre Vadla Ravnaas (Pidl core monkeys) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
