Re: GTK and OSX: a call to sanity
John Ralls wrote: Not moduleset, modulesets. Three sets of 9 modulesets. Also 36 patches, some of which are obsolete and could be deleted (and a bunch more that could become obsolete if they were approved for committing to Gtk), a customized jhbuildrc and several examples for further customization. Yes, it could be integrated into the jhbuild repo, but it would take some discussion with the jhbuild maintainers to work out how to lay it out. I don't think JHBuild should be a repository for modulesets, those are better maintained next to their respective projects (be it gtk-osx, or spice, or sugar, etc.). JHBuild has support for remote modulesets, and remote patches, so I don't think this is a problem. Fred ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Git commit message with tag
Hi, Mike Massonnet wrote: This wiki page[1] has a note on how to prepend a commit message with a tag. This form of a tag is actually buggy with git am, git am will eat any text at the beginning of a subject line that is embraced by brackets. Instead, it should be updated to use this form: tag: . I hope you are fine with that (I've seen such a form on latest commits although right now I could not tell which ones). I updated the page already. [1] http://live.gnome.org/Git/CommitMessages This is about more than GTK+, would you mind resending to desktop-devel-list? Also we have been using [tags] since the Git migration, is this a new feature/bug of 'git am' ? Cheers, Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client-side-windows merged
Matthias Clasen wrote: Yes, the api breakage was discovered soon after the merge and is fixed in 2.17.4 Perfect; I didn't notice I was still tracking the csw branch; sorry for the noise. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client-side-windows merged
Alexander Larsson wrote: The client-side-windows branch has now been merged into master. The http://git.gnome.org/cgit/gtk+/commit/?id=0b586a5a change to gdkdrawable.h: @@ -100,6 +100,7 @@ struct _GdkDrawableClass void (*draw_drawable) (GdkDrawable *drawable, GdkGC*gc, GdkDrawable *src, + GdkDrawable *original_src, gint xsrc, gint ysrc, gint xdest, breaks a part of the API/ABI that is (at least) used in PyGTK: gdk.c:7243: warning: passing argument 4 of ‘((struct GdkDrawableClass *)g_type_check_class_cast((struct GTypeClass *)klass, gdk_drawable_get_type()))-draw_drawable’ makes pointer from integer without a cast gdk.c:7243: error: too few arguments to function ‘((struct GdkDrawableClass *)g_type_check_class_cast((struct GTypeClass *)klass, gdk_drawable_get_type()))-draw_drawable’ How should this matter be resolved ? Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ documentation wikified
Stefan Kost wrote: subtasks that I could need help with: 1) start a basic cgi for library.gnome.org (if I do it its gonna be perl, but I don't care so much) * have a hasmap there docmodule-sourcedir * implements a fast way to get from symbol to docblob * when calling edit.cgi?docmodule=glibsymbol=g_object_new * show a textfield with the docs for it 2) write a bugzilla_submit_patch function in for the above cgi (see link for how bugbuddy is doing it). This could probably be part of the symbols_server, (see http://bugzilla.gnome.org/show_bug.cgi?id=500378) 3) build-brigade - anyone reading this? whats the chances of getting a doc-builder, where we could also run this cgi? I had a few offers for build slaves, I'll get back to them. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up 2.16
Matthias Clasen wrote: On Mon, Dec 22, 2008 at 7:25 AM, Jaap A. Haitsma j...@haitsma.org wrote: Great. Shouldn't update jhbuild to build from trunk? That way 2.15 get's more testing Sounds like a good idea Done. @gnome-i18n: 2.26 will use GTK+ 2.16, you may have something to update in damned-lies. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: API has links that ends in 404
Mike Massonnet wrote: Just to let you know that the page about GtkStatusIcon[0] links against GIcon which ends to return 404[1]. Please file a bug in bugzilla.gnome.org, website product, library.gnome.org component. Thanks, Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: setting up a gtk dev environment
Owen Taylor wrote: I'm using the subversion trunk for jhbuild which I didn't assume was stable. I get the output below when I try jhbuild bootstrap In general, I'd strongly recommend against jhbuild bootstrap. It: It is already written down in the manual; but it is obvisouly not enough (especially since other documents will ask the user to do jhbuild bootstrap) so I will probably add a note the first time the command is used, pointing that on a modern distribution, it is way easier and safer to use packages. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: setting up a gtk dev environment
Patrick Hallinan wrote: I ignored that and tried jhbuild gtk+' but the first package (fontconfig-2.6.0) failed to build. I think that this is the first error: In file included from ../fontconfig/fcfreetype.h:27, from fcftint.h:26, from fcfreetype.c:48: /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such file or directory Fedora 9 has fontconfig-2.5.0-2. I guess I will file a bug against jhbuild if I can figure out how to. bugzilla.gnome.org has a jhbuild product. Note that build failures are most often caused by the modules, not jhbuild, so I would advise you to report your bug against fontconfig. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Fwd: gtk website content]
Olav Vitters wrote: Library uses tarballs. When you do a install-module, library.gnome.org updates after a while (5 min cron delay). Might not always take the latest version though (uses the r-t modulesets IIRC, something like micro being ok, but won't take newer major.. ask frepd if you want specifics). It now has some support to be smarter than that, if I remember correctly what I did. Library.gnome.org will take whatever is shipped in docs/tutorial/html/ or docs/faq/html/ in the GTK+ tarball, transforming the HTML files to match the site layout. I am not sure if it makes sense for those documents to be written using docbook and gnome-doc-utils. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk website bug
Stefan Kost wrote: the gtk website has no bugzilla entry. Could someone have a look at this bug (files for www.gnome.org right now), http://bugzilla.gnome.org/show_bug.cgi?id=531754 While you're at it, http://bugzilla.gnome.org/show_bug.cgi?id=514882 would also have benefited from a website component in gtk+ bugzilla. Thanks for Jeff, Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.13.0 released
Matthias Clasen wrote: GTK+ 2.13.0 is now available for download at: And its documentation is now available at http://library.gnome.org/devel/gtk/unstable/ Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Final Draft
Murray Cumming wrote: what is most unfortunate is that library.g.o only has glib development docs, but not gtk development docs. That's probably because there are no tarball releases of GTK+ from svn trunk at the moment. library.gnome.org can only use tarballs, I believe. That is the main issue; the other one would be this version wouldn't be in any GNOME module set as published by the release team but this is easy to work around. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: using jhbuild and gtk+ branches
Dr. Michael J. Chudobiak wrote: I have a jhbuild system set up, using the gnome-2.22 moduleset. That pulls in trunk versions of some things (gedit) and non-trunk versions of gtk+ (branches/gtk-2-12). The GNOME 2.22 module set brings modules that will be part of GNOME 2.22, and that means GTK+ 2.12. There is no gnome-trunk module set that would use everything from the bleeding edge. There is a bug report http://bugzilla.gnome.org/show_bug.cgi?id=419879 against JHBuild about such a module set. In the meantime you can just remove the revision attribute for gtk in your module set and that will checkout gtk+ from trunk. Regards, Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - Hosting Windows Binaries
Martyn Russell wrote: Actually, I noticed that it is on the wiki actually: http://library.gnome.org/devel/gtk-faq/stable/ How is it put there, just simply generated from docbook and slightly updated to fit into the style of the pages? It is generated from the source tarballs, files from docs/faq/html/ are processed to get into library look. I think it probably makes sense to have on library.gnome.org to be honest, since it is another form of documentation, which we are also linking to on the new gtk.org site. So it gets my vote :) Unfortunately it doesn't meet the easy to add/edit criteria; library will someday support annotating paragraphs (planned for 2.22 but won't be there on time) but this quite anecdotical to the possibility to edit questions/answers. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
Behdad Esfahbod wrote: - In http://library.gnome.org/developers/pango/ I see the following available versions: * 1.10 * 1.12 * 1.14 * 1.16 * 1.17 It makes sense to clearly mark 1.17 as devel/unstable. I'll do this. - Like others have said already, a http://library.gnome.org/developers/pango/latest alias that links to the latest stable release may make sense. stable is link to latest stable release, and latest to latest (eventually development) release; isn't it ok that way ? - Why not list the minor version of each of those available versions? It would multiply required disk space while not offering much advantages over current situation; me thinks. - The page http://library.gnome.org/developers/ links to a specific version, not the listing. How is one supposed to get to the listing? Using the wonderful 'up' toolbar button of Epiphany :) Seriously, I know there is currently no way to get to the version listing page; I have to list versions in the index. - This one may need changes in gtk-doc, but would be very useful if we could have something like http://library.gnome.org/developers/pango/symbols/pango_layout_set_text and have it work. In fact, what would be more useful would be to make http://library.gnome.org/pango_layout_set_text redirect to where it should. That's how php.net works and it has been extremely useful. If I want to read docs for the function phpinfo(), I go to http://php.net/phpinfo I believe this to be doable with RewriteMap; I just have to parse devhelp files and generate a big dbm file. Added to TODO. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
Tim Janik wrote: - the above link http://library.gnome.org/developer/ doesn't actually work - the front page links to http://library.gnome.org/devel/ which is a directory listing It is in the middle of a major rebuild, moving stuffs from /developers/ to /devel/, as suggested by jdub. - the API overview here: http://developer.gnome.org/doc/API/ is ordered by dependencies, this ordering needs to be preserved Okay. - the module names/titles shouldn't be marked in red (red is far too intrusive for normal text it allmost looks like error messages) Okay. - links should be clearly identifiable as links like on the current pages (blue with underline) Okay. - the most requested documentation feature at linuxtag was to make our docs searchable, http://developer.gnome.org/doc/API/ has a site specific google search entry now. this functionality needs to be preserved. It is most certainly possible; I don't know how site-specific Google search works. - i personally find the grey background image star on http://library.gnome.org/developers/gtk/2.11/ fairly irritating when reading the index. i'd prefer the index text to not change contrast by removing the grey star from the areas which display actual code (i.e. below the GTK+ Reference Manual block) It got lighter recently; if it still too much it can certainly be hidden on actual documentation pages. - currently, new trunk based docs can be put up (fixed) immediately by doing a new upload (a 24h lag due to automated builds would be acceptable here though). you say you're building docs nightly from release tarballs only? how can we get trunk based docs up then? You could just push the trunk tarball at at known location. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library? (fwd)
Tim Janik wrote: It is most certainly possible; I don't know how site-specific Google search works. here's the change for developer.g.o: http://svn.gnome.org/viewcvs/web-devel-2?view=revisionrevision=4584 the same snippet is needed for library.g.o, just with both occourances of value=developer.gnome.org replaced by value=library.gnome.org. or i can do the change to the library-web module myself if you prefer. Thanks for the pointer; I'll do it. You could just push the trunk tarball at at known location. ah, interesting, which location is that going to be? Whatever is convenient for you. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
Behdad Esfahbod wrote: It makes sense to clearly mark 1.17 as devel/unstable. I'll do this. Thanks. It is now marked as devel, perhaps not emphasized enough. http://library.gnome.org/devel/pango/ stable is link to latest stable release, and latest to latest (eventually development) release; isn't it ok that way ? It probably is. The only reason I prefer latest to point to latest stable is that I guess people will start linking to latest, and I don't want them to point users to unstable-will-changing API. So latest should be the same as stable, and I'd introduce unstable for the current development release ? Doable. - Why not list the minor version of each of those available versions? It would multiply required disk space while not offering much advantages over current situation; me thinks. I wasn't suggesting that you build docs for all micro versions. Just to write which micro version of pango 1.16 it is. The URL should stay at 1.16 though. Just pring 1.16.5 instead of 1.16. Okay, will do. cairo_*() symbols to their docs. It doesn't need much parsing even, this is how the .devhelp file looks like: I actualyl looked at them before suggesting it as possible :) Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
Murray Cumming wrote: http://library.gnome.org/developers/gtk/ is a page listing available versions of the documentation; do you believe a latest symlink would be useful ? As well as a stable symlink ? I would [find] them very useful. I just ran an update on library.gnome.org and such links are now installed; http://library.gnome.org/developers/gtk/stable/ http://library.gnome.org/developers/gtk/latest/ Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
David Nečas (Yeti) wrote:
do you believe a latest symlink would
be useful ? As well as a stable symlink ?
A stable or latest alias would be definitely useful, but...
This has been taken care of.
Let me explain: The conclusion on gtk-doc was that it is not
feasible to keep the on-line location of everything in
gtk-doc, instead libraries should advertise their on-line
reference base URLs (if there is any) and a mechanisms for
this and for base URL switching/correction have been already
implemented.
This would work well with the current state when each
library has one on-line location (containing the latest
version). The new scheme leaves me wondering what to do
when one just wants to link to GObject (gboolean, whatever)
documentation. What is the canonical link? Is there any?
Okay, I understand your problem now. Although I don't have a perfect
answer. Canonical link would be
http://library.gnome.org/developers/{doc_module}/latest/{whatever}
Current directory layout is the only one making sense if we want to
maintain several versions in library.gnome.org; however we could
probably devise a few mod_rewrite rules to expose other URI schemes,
such as http://library.gnome.org/api/{doc_module}/{whatever}.
Frederic
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ok to redirect http://developer.gnome.org/doc/API/2.0/ to GNOME Library?
David Nečas (Yeti) wrote: See for instance the GTK+ API reference on: http://library.gnome.org/developers/gtk/2.11/ What is the unversioned link to the latest available API reference of a library? http://library.gnome.org/developers/gtk/ is a page listing available versions of the documentation; do you believe a latest symlink would be useful ? As well as a stable symlink ? Will old documentation versions be kept there? Yes. Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
