check your grid spacings
Hi, this commit: http://git.gnome.org/browse/gtk+/commit/gtk/gtkgrid.c?id=d717a2dcfc8603561f8a0f78982244e8b8fd9006 fixed GTK+ to interpret GtkGrid spacing properties as documented. This change has happened in GTK+ 3.1.18. We've seen a number of modules affected by this, so here is a general call to action: If your modules is using GtkGrid, please check your row and column spacings. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting gnome-utils for 3.4
hi Dennis; On 2011-09-20 at 19:51, Dennis Cranston (Yahoo!) wrote: With the resources available to help on gnome-utils, it seems easier to continue releasing one tarball. Otherwise, we need to determine who will step up and handle releases of the disk usage analyzer, gnome-screenshot, font-viewer, gnome-dictionary, gnome-system-log, and gnome-search-tool tarballs. Sorry, I do not have the bandwidth these days to do gnome-search-tool releases. I don't think doing multiple tarballs is going to be any more problematic than it already is. the system log viewer, the font viewer and the current incarnation of the dictionary have seen far less action in the past few years. plus, having multiple repositories should help in getting new people interested — there are low hanging fruits in all the gnome-utils project and, currently, building gnome-utils presents a somewhat higher barrier for entry, as it requires a union of all prerequisite dependencies; if I want to hack only on the dictionary I have to build everything. as Cosimo said, splitting up gnome-utils also makes sense in the overall approach of designing the platform in terms of features, and less in terms of apps: it allows us to design all the components instead of shipping a hodgepodge that will be broken off by distributions anyway. Cosimo: the only issue I can think of when splitting up the repo are the translations; currently, everything is translated into the same domain, so we'll need the i18n teams to perform some surgery. we can probably do it during the split (probably at the cost of the history), though. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting gnome-utils for 3.4
Emmanuele Bassi wrote: Cosimo: the only issue I can think of when splitting up the repo are the translations; currently, everything is translated into the same domain, so we'll need the i18n teams to perform some surgery. we can probably do it during the split (probably at the cost of the history), though. The translations shouldn't be an issue, the .po files will be duplicated in the new modules, with a lot of unnecessary strings, and those will be eliminated automatically in l10n.gnome.org since they won't be in the respective .pot file. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting gnome-utils for 3.4
On 2011-09-21 at 13:47, Frederic Peters wrote: Cosimo: the only issue I can think of when splitting up the repo are the translations; currently, everything is translated into the same domain, so we'll need the i18n teams to perform some surgery. we can probably do it during the split (probably at the cost of the history), though. The translations shouldn't be an issue, the .po files will be duplicated in the new modules, with a lot of unnecessary strings, and those will be eliminated automatically in l10n.gnome.org since they won't be in the respective .pot file. thanks for the answering my remaining doubt. :-) ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: check your grid spacings
May be it would have been wiser to fix the documentation instead of breaking a lot of code. Best regards, Jean Le mercredi 21 septembre 2011 à 06:50 -0400, Matthias Clasen a écrit : Hi, this commit: http://git.gnome.org/browse/gtk+/commit/gtk/gtkgrid.c?id=d717a2dcfc8603561f8a0f78982244e8b8fd9006 fixed GTK+ to interpret GtkGrid spacing properties as documented. This change has happened in GTK+ 3.1.18. We've seen a number of modules affected by this, so here is a general call to action: If your modules is using GtkGrid, please check your row and column spacings. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting gnome-utils for 3.4
Hi guys, I support the idea of splitting the individual apps separately. Although the distribution will be tricky, but It will result in more serious development of individual apps, like baobab , which require more scanning capabilities and disk management. --Vinit On Wed, Sep 21, 2011 at 5:54 PM, Emmanuele Bassi eba...@gmail.com wrote: On 2011-09-21 at 13:47, Frederic Peters wrote: Cosimo: the only issue I can think of when splitting up the repo are the translations; currently, everything is translated into the same domain, so we'll need the i18n teams to perform some surgery. we can probably do it during the split (probably at the cost of the history), though. The translations shouldn't be an issue, the .po files will be duplicated in the new modules, with a lot of unnecessary strings, and those will be eliminated automatically in l10n.gnome.org since they won't be in the respective .pot file. thanks for the answering my remaining doubt. :-) ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gnome-utils-list mailing list gnome-utils-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-utils-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Attention anyone uploading binaries to ftp.gnome.org/pub/binaries - understand the GPL
Hi, For the next cycle I was going to look at having jhbuild generate some binaries directly out of git that could be used as a quickstart for developers. However in order to ship binaries, one has to comply with the GPL/LGPL's definition of source code: Source code for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. This is one of the very few things that the major distributions get right. And it looks like pretty much everyone uploading stuff to ftp.gnome.org/pub/binaries doesn't. For some of these, one can generally infer where to find the source code: For example, the source for binaries/win32/pango/1.28 can *probably* be found in sources/pango/1.28 (but is it? Are there any patches?) Also, just as important is scripts used to control the compilation. Saying oh the source code is in git.gnome.org/banshee or whatever isn't enough - *how* it is built needs to be documented. As a strawman - in each binary directory, add a file called SOURCES that explains how you generated the binary. The data we need could be summarized as what and how. For what: Just link to all source code that went into the binary. how is more interesting: 1) The host operating system: Did you compile natively on Windows XP? With MSVC++? Did you cross compile from Linux with the Debian mingw32 chain? 2) How did you invoke the compiler and make? Do you have any scripts? Actually, I realized this needs to be a wiki page. I've started one here: https://live.gnome.org/MaintainersCorner/Binaries Please help me out here - win32/mac binary maintainers, add a better example SOURCES file please. And let me know what you think in general. Also, just to move things along, I plan to remove any binary which does not have a corresponding SOURCES file in say one month from now. Thanks! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
RE: Splitting gnome-utils for 3.4
On Tue, 2011-09-20 at 19:51 -0700, Dennis Cranston (Yahoo!) wrote: Hi Cosimo, With the resources available to help on gnome-utils, it seems easier to continue releasing one tarball. Otherwise, we need to determine who will step up and handle releases of the disk usage analyzer, gnome-screenshot, font-viewer, gnome-dictionary, gnome-system-log, and gnome-search-tool tarballs. Sorry, I do not have the bandwidth these days to do gnome-search-tool releases. Hi Dennis, I plan to assign maintainership of each of the new modules to the relevant maintainers as listed here basically [1]. Tarballs are usually not a problem, and release-team members always stepped up and rolled tarballs when the maintainer wasn't available and a new release was needed. [1] http://git.gnome.org/browse/gnome-utils/tree/MAINTAINERS Thanks, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splitting gnome-utils for 3.4
Hi Cosimo, I am fine with the module split as long as the release team is okay with having to generate some more tar balls. Have they been asked? Thanks, Dennis On Wed, Sep 21, 2011 at 8:43 AM, Cosimo Cecchi cosi...@gnome.org wrote: On Tue, 2011-09-20 at 19:51 -0700, Dennis Cranston (Yahoo!) wrote: Hi Cosimo, With the resources available to help on gnome-utils, it seems easier to continue releasing one tarball. Otherwise, we need to determine who will step up and handle releases of the disk usage analyzer, gnome-screenshot, font-viewer, gnome-dictionary, gnome-system-log, and gnome-search-tool tarballs. Sorry, I do not have the bandwidth these days to do gnome-search-tool releases. Hi Dennis, I plan to assign maintainership of each of the new modules to the relevant maintainers as listed here basically [1]. Tarballs are usually not a problem, and release-team members always stepped up and rolled tarballs when the maintainer wasn't available and a new release was needed. [1] http://git.gnome.org/browse/gnome-utils/tree/MAINTAINERS Thanks, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
