GLib 2.13.2 released
GLib 2.13.2 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.13/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.13/ glib-2.13.2.tar.bz2 md5sum: fe671c2152bda5510f6c07706c1f glib-2.13.2.tar.gz md5sum: 7c9a41df3851371d42aa13ef299de17c This is the third development release leading up to GLib 2.14. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.12. If you have problems, you'll need to reinstall GLib 2.12. * GLib 2.14 will be source and binary compatible with the GLib 2.12 series; however, the new API additions in GLib 2.13.1 are not yet finalized, so there may be incompatibilities between this release and the final 2.14 release. In particular, API described in the following enhancement request may be added: http://bugzilla.gnome.org/show_bug.cgi?id=432651 * Bugs should be reported to http://bugzilla.gnome.org. Contributing GLib 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 About GLib == GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.13.1 to GLib 2.13.2 === * Unicode support: - Add g_unichar_ismark() * GOption: - Allow to use callbacks for remaining args * Updated translations: Belarusian Latin ([EMAIL PROTECTED]) British English (en_GB) Galician (gl) Norwegian bokmål (nb) Oriya (or) Spanish (es) Thai (th) Thanks to all contributors: Yevgen Muntyan Behdad Esfahbod Dan Winship Dave Benson Tor Lillqvist Christian Persch Damien Carbery Vincent Untz Michael Natterer Joseph Sacco Philip Withnall Guillaume Desmottes Matthias Clasen May 23, 2007 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ Team Meeting Minutes - 22nd May 2007
hey everyone; these are the minutes for the gtk+ team meeting held on may, 22nd 2007. the meeting was incredibly good and I'd like to thank everyone that participated tonight. as usual, the (slightly edited) log of the meeting is available on the gtk+ website, at http://www.gtk.org/plan/meetings/ enjoy. +++ 1) decide next meetings' day and time the day seemed fine, but 21:00 UTC looked like to be pretty late for many; mclasen proposed to move the meeting time one hour earlier, at 20:00 UTC. everyone agreed. ACTION: the meeting date stays at tuesday (unless in case of major schedule conflicts), but the time is moved at 20:00 UTC 2) summary of board meeting about gtk+ rambokid reported on the AB meeting about gtk+: state of the maintenance (corporate support, GtkLove and GtkTasks); some companies promised more work with upstream and some are interest in financial support for the foundation. also in the AB meeting: the foundation offered support for allowing a conference call set up for the gtk+ team, in addition to the irc the usual GUADEC meetings. such conference call would be useful for discussing financial issues, pre-release high bandwidth decisions, etc. and it would be ideally done just once per release cycle. ACTION: ebassi will gather the action points and the attendees when the conference call is needed 3) GtkTasks gtk+ managerial-type tasks have been set up on the wiki. it seems they did reach out to the community and effectively made possible to spread out the management of gtk+ to a wider number of persons. mclasen proposed to add a GtkTask for pre-release checking: backend maintainers should smoketest a release before it's actually packaged. ebassi and jdahlin asked whether the build brigade could help in this task, by adding multiple architectures to the build and check that all the different backends are at least in a buildable state. also a "svn-frozen" state should be used on the glib/gtk+ repositories when the release is being made, to avoid commits breaking the dist check phase. ACTION: mclasen and bkor will investigate what's needed for locking a svn repository xan asked for a way to flag bugs and poke maintainers and core developers for reviewing patches in bugzilla. rambokid and mclasen wanted a regular bug summary, with a per-maintainer break down like the ones that owen sent on the list. ACTION: xan will do a bug rundown and regularly send it to the mailing list to avoid patches bitrotting in bugzilla 4) releasing schedule behdad wanted to land in gtk+ trunk the pango-1.18 changes, in order to target a pre-guadec release of pango; mclasen agreed. mclasen asked for outstanding API additions to glib 2.14; mitch and ebassi pointed out the xdg-user-dirs support, which has a full multi platform implementation in gimp, but no defined API. mclasen said that glib could delay API freeze if an API is proposed. ACTION: mitch will work on an API for xdg-user-dirs support no outstanding bugs blocking a semi-frozen glib 2.14 developers snapshot. ACTION: mclasen will try and get a glib API frozen snapshot out next week major blockers for gtk+ 2.12: gtkbuilder, finish notebook d-n-d API changes, offscreen rendering. gtkbuilder is the biggest blocker, followed by the offscreen rendering. rambokid has been reviewing the offscreen rendering patch and said that the widget snapshot code still has some bugs but might land in time for 2.12; the event redirection still needs work. gtkbuilder needs a final review cycle. notebook d-n-d changes too need a final review cycle for the window creation signal patch. ACTION: garnacho will work on the notebook d-n-d patches, and will cc mitch on this ACTION: rambokid will work on the offscreen rendering patch minor pending items for gtk+ 2.12 from kris: tooltpip positioning, tree view column resizing and tap-n-hold API. minor pending items fro gtk+ 2.12 from mclasen: compositing window patch from desrt. ACTION: mclasen will try and get a developers snapshot of gtk+ out next week along with the glib one kris proposed to shift the release dates for glib 2.14 and gtk+ 2.12 by a month; this would move the release dates from pre-GUADEC to slightly post-GUADEC, just like last year. everyone agreed. +++ ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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: Warning about reaped children
On Tue, 2007-05-22 at 13:32 -0400, Matthias Clasen wrote: > On 3/29/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I forgot to pass G_SPAWN_DO_NOT_REAP_CHILD to g_spawn_async_with_pipes() > > and ended up scratching my head about why my GChildWatch callback wasn't > > firing. After some hot strace action and RTFM, I added that flag and > > everything worked perfectly. Do we need a warning like the one in the > > attached patch? > > Sounds like a good idea to me. Hmm, Tim had a few objections: http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00037.html Though I think the common case is that one *isn't* doing the things that could cause waitpid() to return ECHILD --- so the warning would be adequate. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Shipping multiple themes by default (Was: Sudden Tango changes in trunk)
On Tue, May 22, 2007, Matthias Clasen wrote: > > Would it be difficult to ship multiple themes by default, for example > > "legacy" and "tango" (and perhaps "qt" and "metal" themes in the > > future?); the default theme could be selected at build time and the > > default default could be set to "tango" for win32 and win32 only. > How is that different from what existing theme engine, icon theme and > theme packages provide today ? (...other than shifting additional > maintenance burden on the GTK+ team) It would be possible at the distribution level and with the existing infrastructure, but the context of the proposal was that people were standing against the icon update because it might break the legacy uses, and people were standing in favor of the icon update because it would mean nicer icons under Win32. My proposal simply tried to map the two, by allowing Gtk to ship multiple icon themes, and let the distributor build one from the list, or default to a non-legacy one for Win32. -- Loïc Minier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ developers Ttam meeting tonight
On Tue, 2007-05-22 at 12:28 -0400, Olav Vitters wrote: > On Tue, May 22, 2007 at 02:29:28PM +0100, Emmanuele Bassi wrote: > > * are people in the foundation sponsoring a conf call for the team? > > The board uses the Sun conference call system. If allowed for gtk+, one > person has to set it up (forgot who) and then everyone should be able to > call in (for free). Glynn sets up the Sun system. But I believe there are other options too if Glynn is too busy to set it up. For example, Nokia, Red Hat, or Linux Foundation may be able to offer their conferencing system. Which one works best really depends on where people who want to join the conference are located. -- 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: first Gtk Version over DirectFB
Matthias Clasen ha scritto: > On 3/28/07, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote: >> >> i believe it would be nice if someone could sync directfb backend in >> trunk with stable release: all that's in trunk can be safely backported >> into 2.10 (also some autofile sysnc is needed). >> I sadly cannot do it by myself as i have no svn write access. >> >> Since more and more people use gtkdfb in production environments, i >> feels we need to have it working in regular gtk releases. >> >> BTW, the directfb gnome bug page is also messy: a lot of bugs duplicates >> exist, many closed bugs are still indicated as open etc.. >> i can take care of that as i take care of bugs related to gtkdfb in >> debian: do i need some special permission? indications about how to >> manage bugs in gnome? > > It is really up to the people working with and on the directfb backend to > a) merge bugfixes to the stable branch as appropriate > b) manage the backend-specific bugs > I realize that we may not have given Mike a proper "subsystem > maintainer initiation". Apologies for that... I was recently given write access to Gnome's BTS and SVN repository: i'll take care to maintain the directfb component bugreports page and to backport to the stable branch all the fixes Mike applies to trunk. Many bugs, even thanks to patches provided by users, were recently fixed in trunk and backported to gtk-2-10: i expect gtk+ 2.10.13 to contain a much more usable and stable DirectFB backend than before. regards Attilio Fiandrotti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkEditableLabel Widget
Hello All, It was recommended that I ask this question on the gtk-devel-list instead, so here it goes: I have an interest invested in an editable label widget because of an application I am working on. Because of this, I decided to work on the widget myself since the project seems to have been dropped from the list of priorities. On Bugzilla, there is an implementation that was written in 2005, but it is not acceptable because it uses more than the available signal padding slots from GtkLabel. It is quite obvious that the way to go is to use the GtkEditable interface in a new widget called something like GtkEditableLabel. However, there are two different approaches that I've come up with. One way to implement this widget would be to derive it from GtkLabel. This would allow the widget to inherit all of the code from GtkLabel, but may cause problems because of hidden data and the fact that GtkLabel already handles selections in a different way. The other option is to do what EelEditableLabel did and just derive from GtkMisc. This would add a little extra baggage because of reimplementing a few of the same features. However, I think this may be the better way to go in terms of API and speed of the widget. Does anyone have any thoughts on this issue, in one direction or the other? People were suggesting using GtkEntry, GtkTextView, and GtkCellView as a replacement, but these will not work. The label must be multi-lined, which cuts out GtkEntry. GtkCellView is gone because its editing requires a GtkEntry widget, and I want it inline. GtkTextView has too much overhead if you want many of these widgets. Thoughts? --- Andrew Krause ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Warning about reaped children
On 3/29/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > Hi, > > I forgot to pass G_SPAWN_DO_NOT_REAP_CHILD to g_spawn_async_with_pipes() > and ended up scratching my head about why my GChildWatch callback wasn't > firing. After some hot strace action and RTFM, I added that flag and > everything worked perfectly. Do we need a warning like the one in the > attached patch? Sounds like a good idea to me. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: first Gtk Version over DirectFB
On 3/28/07, Attilio Fiandrotti <[EMAIL PROTECTED]> wrote: > > i believe it would be nice if someone could sync directfb backend in > trunk with stable release: all that's in trunk can be safely backported > into 2.10 (also some autofile sysnc is needed). > I sadly cannot do it by myself as i have no svn write access. > > Since more and more people use gtkdfb in production environments, i > feels we need to have it working in regular gtk releases. > > BTW, the directfb gnome bug page is also messy: a lot of bugs duplicates > exist, many closed bugs are still indicated as open etc.. > i can take care of that as i take care of bugs related to gtkdfb in > debian: do i need some special permission? indications about how to > manage bugs in gnome? It is really up to the people working with and on the directfb backend to a) merge bugfixes to the stable branch as appropriate b) manage the backend-specific bugs I realize that we may not have given Mike a proper "subsystem maintainer initiation". Apologies for that... Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Shipping multiple themes by default (Was: Sudden Tango changes in trunk)
On 3/29/07, Loïc Minier <[EMAIL PROTECTED]> wrote: > Hi, > > Would it be difficult to ship multiple themes by default, for example > "legacy" and "tango" (and perhaps "qt" and "metal" themes in the > future?); the default theme could be selected at build time and the > default default could be set to "tango" for win32 and win32 only. > > Distributors could easily decide which themes they do ship and it would > be easy to switch the default default from "legacy" to "tango" with > $next_major_release for all platforms -- while still making it > available for legacy purposes. > > (In a way, this maps relatively close to how Java's Swing "Look and > Feel" themes are handled.) How is that different from what existing theme engine, icon theme and theme packages provide today ? (...other than shifting additional maintenance burden on the GTK+ team) Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How to generate python bindings correctly - for a GObject based system?
Hi, मयंक जैन (makuchaku) wrote: > I'm trying to write a python wrapper for my GObject derived system I think the PyGTK mailing list is a better place to ask this, since this list here is about the development of GTK+ (not applications, but the library) and related things. See http://www.pygtk.org/feedback.html . Greetings, - Felix ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk-pixbuf io-ico and Microsoft's new PNG icon format
On 10/27/06, Peter Zelezny <[EMAIL PROTECTED]> wrote: > Hi GTKers, > > I've noticed that the .ICO format is now a wrapper for BMP or PNG [1]. > > Has anyone thought about adding support for this in gdk-pixbuf/io-ico.c? > There'll probably be some .ICO images floating around the net shortly > (after Vista release?) that GTK+/Gimp cannot read because of this. > > After a not-so-extensive search I couldn't find any information on what > they've done to the header to shoehorn PNG into ICOs, perhaps a new > "Type" field (=2).. I hadn't about png-in-ico yet. If someone find information on the exact format modifications, we can certainly make the ico loader support it. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ developers Ttam meeting tonight
On Tue, May 22, 2007 at 02:29:28PM +0100, Emmanuele Bassi wrote: > * are people in the foundation sponsoring a conf call for the team? The board uses the Sun conference call system. If allowed for gtk+, one person has to set it up (forgot who) and then everyone should be able to call in (for free). -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib/gtk compilation subsets (Re: is glib too bloated?)
On 5/14/07, Tim Janik <[EMAIL PROTECTED]> wrote: > we've discussed that during last GUADECs Gtk+ meeting: >http://mail.gnome.org/archives/gtk-devel-list/2006-June/msg00146.html > the main outcome was that the ability to disable some of the non-strict-core > widgets in Gtk+ could be an interesting code size reduction in embedded > contexts. if done properly and if it's possibly interesting to have > for multiple parties, compilation subsets could also be backfolded into > the upstream Gtk+ configure.in/Makefile.am. > so far, no one has really attempted this and submitted a patch though, > and without anyone taking a stab at it, it won't happen. > I actually did an initial investigation of allowing build-time subsets in gtk, and I believe I reported the results on this mailing list sometime last year, but the memory savings were not overly spectacular. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common widget for choosing file formats
Am Dienstag, den 22.05.2007, 13:44 +0100 schrieb Bastien Nocera: > Could you please also show what the existing implementations look like > (both in terms of code and UI), as well as what your implementation > looks like? I've collected some screenshots and links and put them into the wiki: http://live.gnome.org/GTK%2B/FileFormatChooser Ciao, Mathias -- Mathias Hasselmann <[EMAIL PROTECTED]> http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common widget for choosing file formats
On Tue, 2007-05-22 at 16:34 +0200, Mathias Hasselmann wrote:
> Am Dienstag, den 22.05.2007, 14:51 +0200 schrieb Xavier Bestel:
> > On Tue, 2007-05-22 at 14:43 +0200, Mathias Hasselmann wrote:
> > > Applications supporting multiple file formats needs a file-format
> > > chooser in
> > > their file saving dialog. Several GNOME apps implement very similiar
> > > file-format choosers - so it makes sense to me, to add this widget to
> > > GTK+.
> > >
> > > The widget would be used like this:
> > >
> > > GtkWidget *format_chooser = egg_file_format_chooser_new();
> > > gtk_file_chooser_set_extra_widget(GTK_FILE_CHOOSER(dialog),
> > > format_chooser);
> > >
> > > EggFileFormat *format;
> > >
> > > format = egg_file_format_new (_("Scalable Vector Graphics (SVG)"),
> > > "svg", NULL);
> > >
> > > egg_file_format_chooser_add_format(EGG_FILE_FORMAT_CHOOSER(format_chooser),
> > > format);
> >
> > That may be a bit short for container formats, which must handle
> > subformats (e.g. AVI with different audio/video codecs).
>
> Definitly didn't have this case in mind, and maybe its out of scope for
> a _common_ widget
Agreed. After all applications needing to choose a codec will want to
specify a bitrate and some other settings, way out of scope for your
generic widget. A simple format name with an optional icon should be ok.
Xav
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [REMINDER] GTK+ developers Ttam meeting tonight
On 5/22/07, Emmanuele Bassi <[EMAIL PROTECTED]> wrote: > > tonight, tuesday may 22nd, at 21:00 UTC [2] > in #gtk-devel on irc.gimp.org And here's a little helper for timezone impaired such as myself: http://www.timeanddate.com/worldclock/fixedtime.html?month=5&day=22&year=2007&hour=21&min=0&sec=0&p1=0 -- Tommi Komulainen [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common widget for choosing file formats
Am Dienstag, den 22.05.2007, 14:51 +0200 schrieb Xavier Bestel:
> On Tue, 2007-05-22 at 14:43 +0200, Mathias Hasselmann wrote:
> > Applications supporting multiple file formats needs a file-format
> > chooser in
> > their file saving dialog. Several GNOME apps implement very similiar
> > file-format choosers - so it makes sense to me, to add this widget to
> > GTK+.
> >
> > The widget would be used like this:
> >
> > GtkWidget *format_chooser = egg_file_format_chooser_new();
> > gtk_file_chooser_set_extra_widget(GTK_FILE_CHOOSER(dialog),
> > format_chooser);
> >
> > EggFileFormat *format;
> >
> > format = egg_file_format_new (_("Scalable Vector Graphics (SVG)"),
> > "svg", NULL);
> >
> > egg_file_format_chooser_add_format(EGG_FILE_FORMAT_CHOOSER(format_chooser),
> > format);
>
> That may be a bit short for container formats, which must handle
> subformats (e.g. AVI with different audio/video codecs).
Definitly didn't have this case in mind, and maybe its out of scope for
a _common_ widget - nevertheless we should figure out, if a common
widget can cover this case.
What would be a good UI for that?
- A tree with the container formats as root nodes?
- A second chooser widget changing its content everytime a new
container format is choosen?
- Something completely different?
Ciao,
Mathias
--
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[REMINDER] GTK+ developers Ttam meeting tonight
hi everyone; since nobody has objected to the date/time for a developers meeting[1], here's the more format announcement/reminder: tonight, tuesday may 22nd, at 21:00 UTC [2] in #gtk-devel on irc.gimp.org the action points for the meeting: * where are we wrt FOSDEM release schedule [3]; * summary of the board meeting about gtk+; * are people in the foundation sponsoring a conf call for the team? * post-2-12 features initial rundown everyone can attend to the meeting. ciao, Emmanuele. +++ [1] http://mail.gnome.org/archives/gtk-devel-list/2007-May/msg00203.html [2] 17:00 EDT, 14:00 PDT, 00:00 EEST, 22:00 BST [3] http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg1.html -- Emmanuele Bassi, E: [EMAIL PROTECTED] 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: Common widget for choosing file formats
On Tue, 2007-05-22 at 14:43 +0200, Mathias Hasselmann wrote:
> Applications supporting multiple file formats needs a file-format
> chooser in
> their file saving dialog. Several GNOME apps implement very similiar
> file-format choosers - so it makes sense to me, to add this widget to
> GTK+.
>
> The widget would be used like this:
>
> GtkWidget *format_chooser = egg_file_format_chooser_new();
> gtk_file_chooser_set_extra_widget(GTK_FILE_CHOOSER(dialog),
> format_chooser);
>
> EggFileFormat *format;
>
> format = egg_file_format_new (_("Scalable Vector Graphics (SVG)"), "svg",
> NULL);
>
> egg_file_format_chooser_add_format(EGG_FILE_FORMAT_CHOOSER(format_chooser),
> format);
That may be a bit short for container formats, which must handle
subformats (e.g. AVI with different audio/video codecs).
Xav
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common widget for choosing file formats
On Tue, 2007-05-22 at 14:43 +0200, Mathias Hasselmann wrote: > Quoting myself from Bug 440431[1]: > > Applications supporting multiple file formats needs a file-format > chooser in > their file saving dialog. Several GNOME apps implement very similiar > file-format choosers - so it makes sense to me, to add this widget to GTK+. Could you please also show what the existing implementations look like (both in terms of code and UI), as well as what your implementation looks like? -- Bastien Nocera <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Common widget for choosing file formats
Quoting myself from Bug 440431[1]:
Applications supporting multiple file formats needs a file-format
chooser in
their file saving dialog. Several GNOME apps implement very similiar
file-format choosers - so it makes sense to me, to add this widget to GTK+.
The widget would be used like this:
GtkWidget *format_chooser = egg_file_format_chooser_new();
gtk_file_chooser_set_extra_widget(GTK_FILE_CHOOSER(dialog),
format_chooser);
EggFileFormat *format;
format = egg_file_format_new (_("Scalable Vector Graphics (SVG)"), "svg",
NULL);
egg_file_format_chooser_add_format(EGG_FILE_FORMAT_CHOOSER(format_chooser),
format);
format = egg_file_format_new (_("Compiliertes Layout (C-Header)"), "h",
NULL);
egg_file_format_chooser_add_format(EGG_FILE_FORMAT_CHOOSER(format_chooser),
format);
...
if (GTK_RESPONSE_ACCEPT == gtk_dialog_run (file_chooser))
{
EggFileFormat *format = egg_file_format_chooser_get_format
(format_chooser);
gchar *filename = gtk_file_chooser_get_filename (chooser);
if (NULL == format)
format = egg_file_format_chooser_guess_by_extension (format_chooser,
filename);
app_file_format_save (APP_FILE_FORMAT (format), filename);
g_free (filename);
}
Suggested API:
http://bugzilla.gnome.org/attachment.cgi?id=88596&action=view
http://bugzilla.gnome.org/attachment.cgi?id=88598&action=view
Is it OK, to commit this to GTK+? Should I add it to libegg first?
Ideas? Suggestions?
[1] http://bugzilla.gnome.org/show_bug.cgi?id=440431
--
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
How to generate python bindings correctly - for a GObject based system?
Hi,
I'm trying to write a python wrapper for my GObject derived system
---
// Object definition
struct _MakuObject
{
GObject parent;
gint age;
DBusGProxy *gproxy;
};
// ObjectKlass definition
struct _MakuObjectClass
{
GObjectClass parent;
/* Signals */
};
---
And one public function
---
void maku_object_say_cheese (int i);
---
I'm using SWIG for this process. SWIG is able to generate bindings correctly
---
import maku
maku.maku_object_say_cheese (10)
MakuObject just sent you a CHEESE! :)
---
HOWEVER, how can I get these bindings to be used as...
---
import maku
maku.say_cheese (10)
---
Is there any way I can accomplish this? The tarball of my project with
a sample Makefile is attached. Please run "make swig" to generate the
python module.
Any pointers, suggestions would be much appreciated :)
Thanks,
Makuchaku
swig.tar.gz
Description: GNU Zip compressed data
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
