Links to help glib/gtk+ devels and contributors
Hello all, I've created this page [1] with links to bugzilla gtk+/glib bugs. Maybe It's useful for some gtk+/glib developers or contributors. I think that It could improve the patch review process a bit: * You have a quick look of the bugs targeted for the next gtk+/glib release * People interested on one area (performance, quartz/win32 ports...) have a direct link to their bugs. * Official gtk+ devels could take a look at reviewed patches to accept or reject them. * New contributors could take a look at trivial bugs or documentation bugs. Or need-work bugs to improve them. * ...etc I know that all this info can be gathered from bugzilla, but I'm lazy and I prefer direct links ;) Of course, feel free to improve it, but I warn you that the page source is a bit messy ;) Have fun, [1] http://live.gnome.org/GTK%2B/BugzillaLinks -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Kinetic scrolling (was Minutes of the GTK+ Team Meeting - 2009-11-27)
2009/11/25 alex : > On Tue, Nov 24, 2009 at 10:13:20PM +, Emmanuele Bassi wrote: >> >> [...] >> >> 4. Implement finger and kinetic scrolling [jjardon] >> - Midori has a finger/kinetic scrolled window implementation >> - Hildon has one as well >> - OpenMoko had one >> - would it make sense to port the feature to GtkScrolledWindow when >> :gtk-touchscreen-mode is set to TRUE? >> - issue: event delivery to children requires subclassing to override >> current default behaviour of gtk+ widgets > The main issues now: > - Selection/dragging vs scrolling (touchscreen mode?, more complex > widgets or subclassing) > - Animations with timeouts in gtk are not that good (check Owen posts about > that), this is something to discuss about the library > - Embedding finger scroll widgets inside each other? > - Double events in the callbacks, original and reinjection if > widgets do not deal with them. > > I do not think this solution is a clean option, we should add clean > support for this event handling, maybe using top-down widget detection > in csw or adding new specific gdk event or something like that. We > could check how to do that. FYI, This is what was discussed in the meeting: ( see the complete log here: [1]) kinetic bug number: https://bugzilla.gnome.org/show_bug.cgi?id=601923 < jjardon> kalikianatoli added support for this in midori recently, maybe this stuff could be added to gtk+ < shaunm> is this the same kind of widget as HildonPannableArea? i.e. you can grab anywhere inside it to flick? < kalikianatoli> ebassi, I would wonder if it makes sense to support that in scrolled window itself < ebassi> kalikianatoli: well, yeah: if we decided to get it in gtk+ I'd definitely vote for adding the feature to ScrolledWindow < kalikianatoli> shaunm, yep, and you can choose whether it should just drag, or also move further < shaunm> ok, so one of the quirks I noticed is that other widgets needed to be modified/subclassed so as not to consume the drags in order to work correctly inside a pannable area < shaunm> because events in gtk are handled innermost-first < shaunm> at least in hildon. do other implementations have a less hacky way around this? < kalikianatoli> shaunm, Probably a property would solve this. To say whether it should select or drag < shaunm> yeah, I'm kind of wondering if gtk could have a cleaner way for parents to intercept events, without relying on the good faith of child widgets < shaunm> maybe a two-pass event propagation: top down and back up < ebassi> shaunm: just like clutter ;-) < ebassi> the first pass is: top-level to innermost child; the second pass is: innermost child to top-level < ebassi> so the kinetic scroller would intercept the events before they reach the children < kalikianatoli> although then you can't know if the child had a better idea of how to treat the situation < ebassi> it would imply adding a new event and doing the event chain in reverse order; then, if nothing returned TRUE, continue with the current behaviour < ebassi> kalikianatoli: there are always side effects :-) < kalikianatoli> a bit like going from not good to not good either :) < ebassi> you could handle the event and let it through anyway < kalikianatoli> but I definitely recall more than once where that would have been useful < kalikianatoli> so I would like to follow the idea if it can be done < ebassi> we added that behavioir exactly after doing the finger scrolling window on openmoko :-) [1] http://live.gnome.org/GTK%2B/Meetings?action=AttachFile&do=view&target=20091124.txt -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Native/Extended layout
2009/12/14 Johannes Schmid : > Hi everybody! > > You potentially know that GTK+ has some issues when it comes to > correctly assign space to widgets if the widgets don't have a fixed > size. In 2007, Mathias Hasselmann worked on this issues in a summer of > code project (see the extended-layout branch). > > You will find the original discussion here: > https://bugzilla.gnome.org/show_bug.cgi?id=101968 > > And for the more recent ideas here: > https://bugzilla.gnome.org/show_bug.cgi?id=104188 > > I finally created the "native-layout" branch that sums up the patches of > the second bug report. The original "extended-layout" branch is so far > behind recent development that merging is ends up in a rewrite more or > less and Behdad/Havoc expressed that they don't like the implementation > used. Hello Johannes, thank you for your work on this. I've also update the roadmap with all the new info [1]. Feel free to improve it if you want ;) Regards [1] http://live.gnome.org/GTK+/Roadmap -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+3: Help with latest needed accessors
Hello, as you already know, one of the major goals of future GTK+ releases is seal all public structure fields and use accessor functions instead direct access to these properties [1] There is a tracker bug for missing accessors functions here [2]. After doing some patches for various GTK+ apps [3], I think the most important missing accessors are - GTK_WIDGET_REALIZED(), GTK_WIDGET_MAPPED() ( see bug [4] ) (Also, is necessary an accessor for GTK_WIDGET_RC_STYLE() ?) - GtkTextView->need_im_reset ( see bug [5] ) Also, if someone knows the status of the GtkStyle [6] and GtkRcStyle [7] sealings, please comment here. I think that If we can solve the accessor functions for these 3 cases, most of the GTK+ apps can be compiled with GSEAL_ENABLED and be ready for GTK+3 transition. Regards [1] http://live.gnome.org/GTK%2B/3.0/Tasks#P1 [2] https://bugzilla.gnome.org/show_bug.cgi?id=597610 [3] http://live.gnome.org/GnomeGoals/UseGseal [4] https://bugzilla.gnome.org/show_bug.cgi?id=69872 [5] https://bugzilla.gnome.org/show_bug.cgi?id=163251 [6] https://bugzilla.gnome.org/show_bug.cgi?id=541136 [7] https://bugzilla.gnome.org/show_bug.cgi?id=540392 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: State of GTK3 (especially the theme api)
2010/2/1 Clemens Eisserer : > Hi, Hello Clemens > Does anybody know whats the state of GTK3? Whats the estimated release date? > I am especially interested in what the theme api looks like? A gtk-2-90 branch already exist in gnome git [1]. The work was started to remove all deprecated code, patches welcomed to help in this or other tasks, take a look here: [2] > All wiki pages I found were quite outdate :-( Did you see [3] ? > I ask because about 2 years ago I proposed changes to GTK's theme api > (bug 515600) allowing non-gtk applications (like FireFox and Java) to > efficiently use it, and was told I should wait for GTK-3. That was 2 > years ago and it still doesn't look like GTK3 is arround the corner. > The changes were completly backward-compatible. I think you may be interested in project monet [4] > Thank you in advance, Clemens Best Regards, [1] http://git.gnome.org/browse/gtk+?h=gtk-2-90 [2] http://live.gnome.org/GTK%2B/3.0/Tasks [3] http://live.gnome.org/GTK+/3.0/ [4] http://live.gnome.org/GnomeArt/Monet -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bug in g_content_type_guess
2010/2/6 Shixin Zeng :
> from http://git.gnome.org/browse/glib/tree/gio/gcontenttype.c
> we have the definition for this function as below, where
> *result_uncertain is never assigned.
>
> char *
> g_content_type_guess (const char *filename,
> const guchar *data,
> gsize data_size,
> gboolean *result_uncertain)
> {
> char *basename;
> char *type;
> char *dot;
>
> type = NULL;
>
> if (filename)
> {
> basename = g_path_get_basename (filename);
> dot = strrchr (basename, '.');
> if (dot)
> type = g_strdup (dot);
> g_free (basename);
> }
>
> if (type)
> return type;
>
> if (data && looks_like_text (data, data_size))
> return g_strdup (".txt");
>
> return g_strdup ("*");
> }
>
>
> Best Regards
>
> Shixin Zeng
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
Hello,
bug report created here:
https://bugzilla.gnome.org/show_bug.cgi?id=609143
Thanks,
--
Javier Jardón Cabezas
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Last call for missing accessors
2010/2/9 Matthias Clasen : > I need to do a GTK+ release tomorrow, and it realistically has to be > API frozen to make Gnome 2.30. > So, if any of the GTK3 crowd want to step forward and get some of the > important missing accessors in, > tonight would be a good time to do it... For the record, you can see here [1] the status of this. After doing some patches for USEGSEAL GnomeGoal [2], I think the most important ones are: - GTK_WIDGET_REALIZED(), GTK_WIDGET_MAPPED() [3] - GtkTextView & GtkEntry ->need_im_reset [4] (in progress) There are already patches for the two remaining GTK_WIDGET_* macros here [5], Is this aproach not valid? Also, Do somebody know the status of the GtkStyle [6] and GtkRcStyle [7] sealings? Or the plan is switch to a new style system? Best Regards, [1] http://live.gnome.org/GTK%2B/3.0/PendingSealings [2] http://live.gnome.org/GnomeGoals/UseGseal [3] https://bugzilla.gnome.org/show_bug.cgi?id=69872 [4] https://bugzilla.gnome.org/show_bug.cgi?id=163251 [5] https://bugzilla.gnome.org/show_bug.cgi?id=69872#c3 [6] https://bugzilla.gnome.org/show_bug.cgi?id=541136 [7] https://bugzilla.gnome.org/show_bug.cgi?id=540392 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Introduction
2010/2/22 Greg Sieranski : > > Hi guys, Hello Greg, > I currently work on the fedora website and marketing projects. I would love > to be able to help out with gtk+ development for gnome. I am very > experienced in c, c++, python. I am a huge fan of open source and love to > contribute any way I can. Please let me know how I may be of any > assistance. Great! :) Take a look here [1] for some GTK+ tasks and here [2] for GTK+ 3 stuff. If you are interested in bug triaging, you can use the links of this [4] page for specific kind of bugs (Search for trivial bugs with unreviewed patches would be a good start ;)) Regards, [1] http://live.gnome.org/GtkTasks [2] http://live.gnome.org/GTK+/3.0/Tasks [3] http://live.gnome.org/GTK+/BugzillaLinks -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: When deprecating, always say what the replacement is.
2010/2/23 Murray Cumming : > When we deprecate API, please remember to document what the replacement > is. People forget this quite often. > > A small recent example that doesn't do this: > http://git.gnome.org/browse/gtk > +/commit/?id=bb1824c131f247c2ef64f3c5f8b9ffe3885c9d90 Indeed, the info about the replacements is on the deprecated functions/macros documentation (inline comments ;)): http://git.gnome.org/browse/gtk+/diff/gtk/gtkwidget.h?id=bb1824c131f247c2ef64f3c5f8b9ffe3885c9d90 Best Regards, -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [glib] Compile failing on glib master
2010/4/23 Paul Smith : > Currently glib master won't compile: > Ryan just fixed this, thank you. > libtool: compile: ccache gcc -DHAVE_CONFIG_H -I. -I../../../glib/gio -I.. > -DG_LOG_DOMAIN=\"GLib-GIO\" -I.. -I../../../glib -I../../../glib/glib > -I../../../glib/gmodule -DG_ENABLE_DEBUG -DG_THREADS_MANDATORY > -DG_DISABLE_DEPRECATED -DGIO_COMPILATION > -DGIO_MODULE_DIR=\"/opt/evo-2.30/lib/gio/modules\" > -DG_DISABLE_SINGLE_INCLUDES -pthread -g -Wall -MT ginetaddress.lo -MD -MP -MF > .deps/ginetaddress.Tpo -c ../../../glib/gio/ginetaddress.c -fPIC -DPIC -o > .libs/ginetaddress.o > In file included from ../../../glib/gio/ginetaddress.c:34: > ../../../glib/gio/gnetworkingprivate.h:21:1: error: unterminated #ifndef > make[5]: *** [ginetaddress.lo] Error 1 > make[5]: Leaving directory `/opt/src/evo/evo-2.30/obj/glib/gio' > make[4]: *** [all-recursive] Error 1 > > Looks like there is no #endif in this sequence in gnetworkingprivate.h: > > #ifdef G_OS_WIN32 > ... > #else /* !G_OS_WIN32 */ > ... > ... > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Deprecations for 3.x
Hello, After the lastest GTK+ meeting I've assembled a list of "deprecatable" classes so you can review them more easily. Take a look to this query in bugzilla: [1] ( They are the bugs with the 'deprecations' tag ). Is it necessary to add some more? Regards, [1] https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=casesubstring;status_whiteboard=deprecations;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkAdjustment woes
2010/5/15 Tadej Borovšak : > Hi all. Hey Tadej, > One thing is clamping of GtkAdjustment::value. Currently, value is > clamped between values of GtkAdjustment::lower and > GtkAdjustment::upper, while API documentation states that value is > clamped between GtkAdjustment::lower and GtkAdjustment::upper - > GtkAdjustment::page-size. This inconsistency has been already fixed > once, but because this change broke many applications, fix has been > reverted and postponed until GTK+-3. I think now would be a good time > to fix this (again) in git master. I filled bug #619474 [1] with a patch to use the correct (documented) behaviour. > Next thing on the list are gtk_adjustment_changed() and > gtk_adjustment_value_changed() functions. They are used to emit > GtkAdjustment::changed and GtkAdjustment::value-changed signals > respectively after direct modification of GtkAdjustment's fields. > Since all of the public fields of GtkAdjustment are GSEALed now, those > two functions are redundant now and should probably be marked as > deprecated in GTK+-2.22 and removed from GTK+-3. I think that makes sense, any other opinnions? [1] https://bugzilla.gnome.org/show_bug.cgi?id=619474 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] gdk/gdkwindow.c: fix a typo in gdk_window_set_device_cursor().
2010/5/26 Christian Beier : > > Hi there, > the attached simple patch fixes a typo in > gdk_window_set_device_cursor(). Applies against master. Pushed, thanks a lot. Please, try to use bugzilla [1] next time so the patch don't get lost. Regards [1] https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [patch] stray commas
2010/6/5 Mark Brand : > Hi, > > File gio/gioenums.h b/gio/gioenums.h in glib-2.25.7.tar.bz2 has some stray > commas at the end of enums that gcc 4.5 does not like. This patch removes > them. Hey Mark, thanks for your patch but this issue was already fixed: http://git.gnome.org/browse/glib/commit/?id=07b5cee2a8273d7fdd20371b5494ecd320c3cd1c Regards, -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] gdk/gdkpixmap.[ch]: state constness of `data` in create pixmap routines
2010/6/22 Ben Stewart : > Hi all, > > The attached patch file resolves an issue where const char * data cannot > be passed to the GDK create pixmap from XPM routines. > > Apologies in advance if this is not the correct venue to submit a patch > - this is the first one I have submitted to the GTK+ project. Hello Ben, Could you submit the patch to GTK+ bugzilla [1] so It can't be lost? Also, I'd suggest you to use the git format-patch format for the patch [2] Regards, [1] https://bugzilla.gnome.org/enter_bug.cgi?product=gtk+ [2]http://live.gnome.org/Git/Developers#Contributing_patches -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Website proposal for usability
2010/8/12 Martyn Russell : > I like some of the proposed changes here. There are some other things > that I think need changing (which were there before) such as the NEWS on > the main page. It just doesn't get updated enough. I'd suggest to use the identi.ca [1] / twitter [2] acount for more up-to date info. Maybe in a separate section in the main page? BTW, Thanks for your work on this Devin. [1] http://identi.ca/gtktoolkit/ [2] http://twitter.com/GTKtoolkit -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk DirectFB backend
2010/8/25 John Stowers : > > For Google, and those that find this thread brings bad news, I > stumbled across a developers branch that gets Gtk+-2.20 working with > DirectFB again. > [1] http://mail.directfb.org/pipermail/directfb-dev/2010-May/005704.html > [2] http://git.potipota.net/cgi-bin/cgit.cgi/gtk+/log/?h=2.20-directfb-fixes I wonder why these patches were not submitted upstream -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ policy (was RE:rendering-cleanup-next)
2010/9/12 Matthias Clasen : > We don't have a written-down policy, beyond 'fit in locally'. But I > have become increasingly annoyed by trailing whitespace and mixed-in > tabs, since they do show up in my editor nowadays. So maybe we should > agree on a policy and put it in writing for 3.0. As a start point, we have an informal policy here: [1] [1] http://live.gnome.org/GTK%2B/BestPractices#Coding_Style -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Take part in gkt+ development
2010/9/22 Alexander Kuleshov : > Hello list, Hello Alexander, > First of all let me introduce myself. My name is Alexander Kuleshov. > Now I m student, programmer. I have some expirience in C/gtk+ > programming (i took part in Google summer of Code in this year) And I > want to take part in gtk+/glib development. Good to know! :) > 1) If i write patch, where must i send it? File it to Glib [1] or GTK+ [2] bugzilla > 2) What version of gtk+, must i use for development? From git? The current development focus is the master branch (future GTK+3) Regards. [1] https://bugzilla.gnome.org/enter_bug.cgi?product=glib [2] https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK3 breakage
2010/9/27 Allin Cottrell : > On Sun, 26 Sep 2010, Benjamin Otte wrote: > >> the GTK API docs have an ever-expanding migration guide... >> >> GtkObject is gone > > Is there any current documentation on how to use > gtk_adjustment_new? The doc for GTK+ 2.90.7 still says it returns > a pointer-to-GtkObject. It returns a pointer to a GObject now -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK3 breakage
El día 27 de septiembre de 2010 00:53, Havoc Pennington escribió: > Hi, Hello, > 2010/9/26 Javier Jardón : >> >> It returns a pointer to a GObject now >> > > Shouldn't it just return a GtkAdjustment* ? returning GtkObject was > some weird legacy thing. Patches filled here: https://bugzilla.gnome.org/show_bug.cgi?id=630731 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Language Bindings Update for Website
Hello all, 2010/10/25 Martyn Russell : > On 25/10/10 19:45, Murray Cumming wrote: >> >> On Mon, 2010-10-25 at 09:36 +0100, Martyn Russell wrote: >> That shows vala and Javascript as an "Official GNOME Binding", >> presumably meaning an official GNOME Platform Binding. But they are not: >> http://live.gnome.org/TwoPointThirtyone/Bindings > > I will change the "officially gnome" part on the site unless there are any > objections? > I do not know how is the situation with the moduleset reorganization, but I think JavaScript is a official binding as seed is already part of the bindings moduleset [1] and gjs was accepted in the last cycle [2] About Vala is already a external dependency [3], but I'm not very sure if It's enough. Regards [1] http://live.gnome.org/TwoPointThirtyone/Bindings [2] http://live.gnome.org/TwoPointThirtyone/Desktop [3] http://live.gnome.org/TwoPointNinetyone/ExternalDependencies -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Language Bindings Update for Website
2010/10/25 Arnaud Charlet : >> For anyone else wanting to update their language binding support listed on >> the site, please let me know so we can update them accordingly. >> >> ¹ http://www.gtk.org/language-bindings.html > > GtkAda (Ada binding) supports 2.22 (and below). What do you mean by "supports"? Can I access to new API added in GTK+ 2.18 ( like GtkSpinner ) from a Ada program? -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [pygtk] PyGtk and gtk-3.0 compatibility
2010/11/8 Stephen Langer : > Hi. I'm Alice, and I have no idea what you're talking about. I'm heavily > invested in PyGTK2 in a long-term project. As far as I can tell, PyGObject > is a low level library that doesn't serve the same purpose as PyGTK at all. > What's the relationship between the new PyGObject and the old? What kind of > porting do I have to look forward to, and on what time scale? > With PyGObject (since version 2.26) you can access any library with GObject Introspection support, for example GTK+. A complete list here: [1] More info in the project home page: [2] >> I think the community as a whole would be FAR better served by having >> not just better PyGObject code, but better documentation for PyGObject >> (including porting HOWTOs). > > Yes, please. > There are some tips here: [3] Also, there is a GnomeGoal to port applications from PyGTK to PyGObject here: [4] > Thanks, > Steve (not really Alice) Regards [1] http://live.gnome.org/GnomeGoals/AddGObjectIntrospectionSupport [2] http://live.gnome.org/PyGObject [3] http://live.gnome.org/PyGObject/IntrospectionPorting [4] http://live.gnome.org/GnomeGoals/PythonIntrospectionPorting -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gobject-Introspection and CMPH
On 16 December 2010 17:07, Colin Walters wrote: > On Wed, Dec 15, 2010 at 8:54 PM, Matthias Clasen > wrote: >> On Wed, Dec 15, 2010 at 8:43 PM, John Ralls wrote: >> >>> But since you bring it up, what is the "official" policy? Is it C89? Is it >>> published somewhere? >> >> For GTK+, we're generally avoiding C++ comments, since they cause >> problems for the compilers that are used on win32. What other non-C89 >> features do you have in mind ? > > But they *are* used in gtk3 right now... > I dont think so. Where are they used? Regards -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Mersenne Twister in GLib
On 17 December 2010 15:21, Allin Cottrell wrote: > There's a bad URL for info on the Mersenne Twister in glib/grand.c > (on line 71 in the glib-2.26.1 version), which propagates to > a broken link in the GLib documentation. > > The URL given is > http://www.math.keio.ac.jp/~matumoto/emt.html but the currently > correct address is > http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html Thanks for the report. Fixed in current master > Also, I'm wondering if the GLib implementation is up to date > with the code on the Hiroshima site, and if not, whether there > would be interest in updating it -- something that I could > probably contribute to. Dont know about this, but patches are always welcomed ;) -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ win32 binaries
On 25 March 2011 23:37, Pedro Santos wrote: > Hello everyone, > > Since the past six months I've actively used gtk+ and I noticed some lag > between the source release and win32 binary builds. Because of this, I've to > build gtk+ myself in order to use the most recent distribution. So, I'm > wondering if I can give you some help building win32 binaries, in order to > reduce this lag. I use MinGW to build my win32 binaries. I haven't tried to > build win64 binaries but I could do some tests and possibly contribute with > win64 too. Please let me know if I could help. Pardon me if I'm contacting > in the wrong place. If this is the case please point me in the right > direction. Hello Pedro, Thanks a lot for your help! All the resources about the windows backend development are here [1] Feel free to improve it if you want. The former windows maintainer doesnt have time anymore [2] to do the windows binaries, so any help is very welcomed Regards [1] http://live.gnome.org/GTK%2B/Win32 [2] http://tml-blog.blogspot.com/2011/03/gtk-on-windows-i-am-not-really-doing-it.html -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: cross-compiling glib-1.2
On 29 March 2011 13:14, joey kuo wrote: > Hello, Hello, > I'm currently trying to cross-compile gtk1.2.5 for mips-linux 4.3. Only curious, why not using GTK+3 instead GTK+1? -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: No Pascal in the Gtk bindings list?
On 4 August 2011 14:21, Felipe Monteiro de Carvalho wrote: > Hello, > > Please add Pascal in the Gtk bindings page: > http://www.gtk.org/language-bindings.php Done, thanks for noticing. Regards, -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Compilation of the GTK+ stack on Windows using Visual C++
On 19 August 2011 10:03, Fan Chun-wei wrote: > Hi List, > > I have (finally) managed to write up some instructions[1] to build the GTK+ > stack with a stock installation of Visual C++ 2008/2010 from scratch. > The instructions can be found at [1]. ... > [1]: https://live.gnome.org/MSVCCompilationOfGTKStack Hello Fan Chun-wei, thanks for your work Could you move that page to https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack and add a link to https://live.gnome.org/GTK%2B/Win32/ ? Thanks! -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On 7 September 2011 15:26, Federico Mena Quintero wrote: > > As to what is in Bugzilla, is there a quick way to find all the Quartz > bugs to speed up their review? (Or are those patches already in the > quartz-integration branch? I didn't look at individual commits to see > if they had bug numbers.) All quartz bugs: https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;component=quartz;product=gtk%2B with patches: https://bugzilla.gnome.org/buglist.cgi?query_format=advanced;field0-0-0=attachments.ispatch;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;type0-0-0=equals;value0-0-0=1;component=quartz;product=gtk%2B Regards, -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
2011/9/7 Javier Jardón : > On 7 September 2011 15:26, Federico Mena Quintero wrote: >> >> As to what is in Bugzilla, is there a quick way to find all the Quartz >> bugs to speed up their review? (Or are those patches already in the >> quartz-integration branch? I didn't look at individual commits to see >> if they had bug numbers.) I just added a table with links to gtk/glib/pango MacOS bugs in the wiki page [1] If you think any other query would be useful let me know. Regards [1] https://live.gnome.org/GTK%2B/OSX -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How GTK styling works
On 16 January 2012 22:21, John Ralls wrote: > > > There's one thing that could make it better: Put it on GnomeLive! so that > it's easy to find, even for people who don't read this list. > Done: [1] Feel free to improve the markup. Regards [1] https://live.gnome.org/GTK%2B/GTKCSSStyling -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.24.9 released
GTK+ 2.24.9 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.24/ http://download.gnome.org/sources/gtk+/2.24/ 84204bf24cac739fd979943127e7b29cb46b1017684aa24dce630faa01bcb61d gtk+-2.24.9.tar.xz This is a bug fix release in the stable 2.24 series. 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. Overview of Changes from GTK+ 2.24.8 to 2.24.9 = * Implement the editing-canceled property in GtkCellEditableEventBox * Backport GtkScale fixes * Several fixes in the MS-Windows theme * quartz: fix a race condition when waking up the CGRunLoop * Several build fixes: - Add gmodule-2.0 dependency for gtk-query-immodules-2.0 - introspection: Fix srcdir != builddir builds * Bug fixed: 663856 - Make option-foo accelerators use the right symbol 664238 - GTK apps crash when dragging something 665011 - Fix gtk-demo drawingarea example 665013 - Fix 16bit pixmaps 662814 - Don't print a g_warning() when GtkRecentManager can't find a file 620240 - Fix problems with DND on some X servers 629878 - Use the right icon-name for missing images 543520 - Set cups Custom print options correctly 639455 - Implement the editing-canceled property in GtkCellEditableEventBox 667458 - introspection: Fix srcdir != builddir builds Thanks to our contributors: Javier Jardón Benjamin Otte Stefan Sauer Michael Natterer Benjamin Berg Carlos Garcia Campos Stefan Sauer Ryan Lortie Federico Mena Quintero Dieter Verfaillie Alexander Larsson Matthias Clasen Florian Müllner John Ralls Michael Natterer Cosimo Cecchi January 24, 2012 Javier Jardón ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: building Glib-2.32.4 with mingw
On 18 July 2012 08:48, Damon Register wrote: > Now that I was able to build all the components up to and including gtk3, > I tried starting over so I could clean up my notes to be sure that I got > the notes right. I noticed that glib-2.32.4 had been released since I > started this with glib-2.32.2. I thought I would try it but found that > make fails with an error about an XDG item not being defined (I don't have > the notes handy at the moment). From what I could find with Google, it Hey Damon, what is the exact error you get here? Did you file a bug about this? Regards -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: AM_GLIB_GNU_GETTEXT
On 15 September 2012 20:16, Lanoxx wrote: > Hi there, Hey > # This will initialize the internationalization > # capabilities of glib (glib/gi18n.h) and gettext > IT_PROG_INTLTOOL([0.41.0]) > AM_GNU_GETTEXT_VERSION([0.18.1]) > AM_GNU_GETTEXT([external]) > > and in autogen.sh i only call autoreconf -ivs Yeah this is correct. In general avoid the use of AM_GLIB_GNU_GETTEXT. Check [1] for more info If you want to use intltool, you have 2 options: remove the gettext macros or keep them and add something like this to your autogen.sh: autopoint --force AUTOPOINT='intltoolize --automake --copy' autoreconf -ivs Regards [1] http://blogs.gnome.org/jjardon/2010/10/08/use-upstream-gettext-instead-the-glib-one/ -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib: AM_GLIB_GNU_GETTEXT
On 17 September 2012 01:38, Lanoxx wrote: > Hi Javier, Hey, >> If you want to use intltool, you have 2 options: remove the gettext >> macros or keep them and add something like this to your autogen.sh: >> >> autopoint --force >> AUTOPOINT='intltoolize --automake --copy' autoreconf -ivs > > thanks a lot for these comments. That makes it a lot more clear. It would be > awesome if these explanations could be included into the API Docs [1]. I'm > curious, what are the reasons that the glib-gettext macros were never > deprecated? If they should not be used, then a deprecation warning would be > quite useful. > > [1] http://developer.gnome.org/glib/2.31/glib-I18N.html I laready submit a bug to deprecate some time ago [1] Also to port GLib to upstream gettext [2], but as you see in the comments there are some problems about how upstream gettext update the po files I sent a mail to gettext mailing list [3] about this but seems that It was ignored, maybe you have more luck ;) Regards [1] https://bugzilla.gnome.org/show_bug.cgi?id=624186 [2] https://bugzilla.gnome.org/show_bug.cgi?id=622991 [3] http://lists.gnu.org/archive/html/bug-gettext/2012-08/msg3.html -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Language Bindings for GTK+ 3.2 / 3.4 (on website)
On 17 September 2012 20:12, Martyn Russell wrote: > On 17/09/12 12:07, Martyn Russell wrote: >> >> Hello all, >> >> So, I was checking these are up to date after Mathieu Dupuy asked me to >> update the D language bindings. >> >> I have added a GTK+ 3.2 column now and continued the 3.0 binding >> progress for each case. > > > I have added 3.4 too - I meant to add. Id remove all the 2.x columns and only left 2.24. Its the only GTK+ 2.x supported version anyway Regards -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Language Bindings for GTK+ 3.2 (on website)
On 18 September 2012 22:01, Martyn Russell wrote: > On 18/09/12 11:36, Andrew wrote: >> >> On 09/17/2012 07:07 AM, Martyn Russell wrote: >>> >>> Hello all, >>> >>> So, I was checking these are up to date after Mathieu Dupuy asked me >>> to update the D language bindings. >>> >>> I have added a GTK+ 3.2 column now and continued the 3.0 binding >>> progress for each case. >>> >>> PLEASE let me know if any status has changed here for your language >>> bindings out there. I can update accordingly. >> >> >> There are bindings for 3.4 for Pascal: >> http://wiki.freepascal.org/Gtk%2B3 > > > Done, thanks. If there is support for 3.0 and 3.2, let me know, I only > updated 3.4 at this point. Hey, Sorry if I misunderstand something, but if a binding support 3.4, Is it not implicit that support all the GTK+3 versions <= 3.4 ? -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding gtkparasite to gtk?
Hi Christian, On 10 October 2012 17:24, Christian Hammond wrote: > > Now I did miss the updates in that bug thread that mentioned that the latest > version of that patch worked on both GTK 2.0 and 3.0. I'm happy to see that, > and I'll take a look at it. It slipped through the cracks (we don't pay much > attention to that bug tracker, since very few people have ever used it) and > it got lost in the noise of patches sent to us over e-mail and GitHub pull > requests that broke 2.0 support. . 20 days passed, Is the patch to support GTK+3 already applied? What about the other patches? Regards -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GTK+ a cross-platform toolkit ?
Hi, On 5 March 2013 11:32, wrote: > OK, as a majority of people seem to be interested, here is what I will do : > 1) Produce binaries of following GTK+3 versions : > - 3.4.1 "stable" (http://packages.ubuntu.com/precise/libgtk-3-0, Debian > Wheezy provides 3.4.2 so we are safe) ; > - 3.6.4 "development" (last one). > 2) Package them as .zip files. I will use the same layout as existing GTK+2 > .zip files, except for the .spec file which I don't use. > 3) Put them, and the corresponding build environments, online. Give links so > you folks can download and test them. > I will post a new message here when it's ready. Should not be too long. Thanks a lot for your work. Until this get in a more 'official' form Ive added your work to the GTK+ wiki [1], feel free to improve the page if you find something not correct. Also, note that the latest GTK+ stable version is 3.6.4 (the current development version is 3.7.12) Thanks again and keep the good work ;) [1] https://live.gnome.org/GTK%2B/Win32 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Composite GtkBuilder template
On 7 April 2013 16:34, Emmanuele Bassi wrote: > On 7 April 2013 07:57, Tristan Van Berkom wrote: > > So I have to reiterate my question: How exactly does intltool make > > your life difficult maintaining GTK+ ? > > I cannot answer for Matthias, but he and I share the same dislike for > intltool. > FWIW, upstream gettext is getting support for glade files, take a look here [1] [1] http://lists.gnu.org/archive/html/bug-gettext/2013-03/msg00034.html -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gtk+ 3 Roadmap Draft2 wiki
Hello, reading about GTK+ 3 I found this post from Tim Janik : [1] As I didn't found any page in the gnome wiki with the contents of the mail (Gtk+ 3 Roadmap draft), I've created this page: [2] Hope it helps but If this is not correct, feel free to delete it. Best regards, [1] http://mail.gnome.org/archives/gtk-devel-list/2009-April/msg00048.html [2] http://live.gnome.org/GTK%2B/3.0/Roadmap -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
2.90 branch
Hello, I've read here [1] about the creation of a GTK+ branch for GTK+ 2.90/3.0 development after 2.14 has been released. GTK+ 2.18 has been released and I think that no branch was created, is there any plans to create that branch soon? Best Regards [1] http://live.gnome.org/GTK%2B/3.0/Tasks#Q0 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib, GTK+ branched
2009/10/8 Matthias Clasen : > - remaining missing gseal api. The goal here is to ensure that major > apps (gimp, epiphany, etc) can be built with gseal enabled For the record and for not duplicate the work, there is a GnomeGoal page for this [1] Indeed, there is a bug open to build epiphany with gseal enabled but they are needed some accessor functions to compile without errors (You can see the needed accesors in the bug report). Regards, [1] http://live.gnome.org/GnomeGoals/UseGseal [2] https://bugzilla.gnome.org/show_bug.cgi?id=595791 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ Roadmap
Hello, I've created this page [1] as a central place with info (repositories, trackin bugs ...) about Gtk+ 2.20 / Glib 2.24 tasks. Hope it help to find the info faster ;) Please, feel free to change/improve it Regards, [1] http://live.gnome.org/JavierJardon/GTKRoadmap -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Status on the TLS support in gio
2009/10/18 Philip Van Hoof : > Hi there, Hello Philip, > With GIO now supporting things like GSocket and GSocketConnection, what > are the plans for TLS support? It's in the plans for Glib 2.24 [1] ( TLS (SSL) support for GSocket ). Take a look to bug 588189 [2] Regards, [1] http://live.gnome.org/JavierJardon/GTKRoadmap [2] https://bugzilla.gnome.org/show_bug.cgi?id=588189 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Static GTypeInfo and GInterfaceInfo
2009/10/30 Nicola Fontana : > Hi all, Hello Nicola, > on a fresh tree of the latest stable releases: glib-2.22.2 and > gtk-2.18.3 (patches attached). I'm succesfully using them since tuesday. I've created a bug for glib [1] and another for gtk+ [2] to make more easy the review process ( Splinter rulez ;)) Regards, [1] https://bugzilla.gnome.org/show_bug.cgi?id=600161 [2] https://bugzilla.gnome.org/show_bug.cgi?id=600158 -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why do constructors return GtkWidget?
Hello, I'd like to continue the discussion here of thread [1] from gtk-app-devel-list: The question: why is it normal for GTK widget "constructors" to return GtkWidget and not their real type? For instance I would expect: gtk_menu_item_new () To return GtkMenuItem*. But it doesn't, it returns GtkWidget*. IMHO is much clear that constructors return their real type, instead GtkWidget. But maybe there is a technical reason for this. Can someone give me some light about this? Thank you for your responses, PD: If there is not technical reasons, maybe we can change this for GTK+ 3 (or 4 ;)), as I think a change like this will break the 2.x ABI. [1] http://mail.gnome.org/archives/gtk-app-devel-list/2009-September/msg00023.html -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtkglarea 2.1.0 released
This is a bugfix release to stop use deprecated api and clean the build system. Testing in Windows platform has not been tested, so if you have any problems please report in bugzilla! Changes in 2.1.0 General * Lots of clean ups in the build system * Modernize all the code as much as possible before a possible transition to GTK+3 * Remove GLU dependency Availability https://download.gnome.org/sources/gtkglarea/2.1/ Contact --- * Bugs in http://bugzilla.gnome.org * Mailing list http://mail.gnome.org/mailman/listinfo/gtkglarea-list Cheers, -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtkglarea 2.1.0 released
Hey Tarnyko, sorry for the late reply, On 28 April 2014 10:33, Tarnyko wrote: > Javier Jardón writes: >> >> Testing in Windows platform has not been tested, so if you have any >> problems please report in bugzilla! > > Just tested it, works perfectly under Win32. Nice! Good to know >> * Modernize all the code as much as possible before a >> possible transition to GTK+3 > > > Regarding GTK+3 : there is a patch which has been around for some time on > Bugzilla, and that I just adapted for the new release : > https://bugzilla.gnome.org/show_bug.cgi?id=707723#c11 > It basically allows specifying a "--with-gtk=3" option at configure time > (the library still targets GTK+2 by default). > Justed tested under Linux and Win32, it builds fine. The functionality stays > the same for GTK+2, still needs some additionnal work for Linux Font support > (which I have prepared). > Do you think it could be merged ? I already pushed a branch in the git repository with the GTK+3 port [1] Sorry, I didnt know those patches already exist. In my approach I removed the support for GTK+2 and focus in GTK+3 only. I will take a look to the patch and see how we can combine our work ;) Everything seems to work but the zkor example, not sure yet why. So if you have any idea it would be great! I also plan to change the namespace [2] of the api to not conflict with future GTK+ work on this. Cheers! [1] https://git.gnome.org/browse/gtkglarea/log/?h=jjardon/gtk3 [2] https://git.gnome.org/browse/gtkglarea/log/?h=jjardon/namespace_change ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkGlArea with GTK+3 support is now in master
Hi, just a quick mail to notify that GTK+3 version of gtkglarea is now in master ( a gtkglarea-2 branch has been created to keep the GTK+2 version) Apart for the port to GTK+3, there is a namespace change to not conflict with any future integration GL integration in GTK+ and also the use of libepoxy to configure the GL stuff. The zktor example is still not correctly working, but I prefer to merge the patches before they start to bitrot. Tarnyko, sorry we duplicate work here, but it would be great if you rebase your patches to add wayland support :) Please try it and report any regression! Cheers! -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
