Re: Low memory hacks
Hi Simos,
Yesterday at 15:02, Simos Xenitellis wrote:
I'll like to see some real numbers on the memory usage instead of
numbers being thrown around.
In Ubuntu 7.10, the PO files for en_GB are
$ du
-h /usr/share/locale/en_GB/LC_MESSAGES
/usr/share/locale-langpack/en_GB/LC_MESSAGES/
2.3M/usr/share/locale/en_GB/LC_MESSAGES
17M /usr/share/locale-langpack/en_GB/LC_MESSAGES/
$_
In Ubuntu 8.04 (alpha 6), the PO files for en_GB are
$ du
-h /usr/share/locale/en_GB/LC_MESSAGES
/usr/share/locale-langpack/en_GB/LC_MESSAGES/
84K/usr/share/locale/en_GB/LC_MESSAGES
2.2M /usr/share/locale-langpack/en_GB/LC_MESSAGES/
$_
What I am missing here is that I do not know when/how Ubuntu adds this
functionality. It would benefit other distros as well. Did Debian
introduce with feature? Danilo, any links?
I am not handling Ubuntu packaging stuff—it'd be worth checking with
Ubuntu guys instead. Martin Pitt is probably the right person to ask
about it, but looking at the language pack sourcepackage should give a
clue as well.
However, I'd note that en_GB is not really the right locale to do
the metrics on.
From the 2.3M + 17M MO files in Ubuntu 7.10, a typical GNOME session
loads up a subset of the MO files,
# lsof | grep \.mo\$ | awk '{print $7,$9}' | sort -n | uniq
At this moment, my 7.10 is a bit messed up (I have en_GB.UTF-8 but most
apps have en_US?!?). The figures for 8.04 with el_GR should be
comparative of what you get now with 7.10 and en_GB:
They wouldn't be. A majority of el_GR probably uses two-byte UTF-8
sequences, while en_GB would use a majority of single byte UTF-8
sequences (i.e. ASCII).
# lsof | grep \.mo\$ | awk '{print $7,$9}' | sort -n | uniq | awk
'{printf %d+,$1}' /tmp/bc_sums
Using bc with /tmp/bc_sums gives the figure
3.6M (3624412) for a standard session. This figure is a bit
conservative, because en_GB probably did more work than el.
With Ubuntu 8.04 (alpha6) and en_GB, the figure for the MO files is
less than 600K (585375).
Bastien, could you provide the proper figure for your system?
That is a saving of at least 3M in memory.
As Bastien explained, mmap() doesn't read the entire file into memory,
but only reads it as needed.
The stripping of unneeded messages is good, and should happen at the
package generation level (not in GNOME, or when creating tarballs).
Technically, I've opposed introducing this in intltool because of a
one incompatible difference:
current gettext(Something) != such gettext(Something)
i.e. if Something was (un)translated as Something in the MO file,
gettext would return a static pointer with the string Something. If
it was untranslated, it would return the passed pointer.
That can and was used to detect whether there is a translation in some
programs (I've seen it done), so, until gains are proven to be big
enough to warrant breaking a few programs in strange ways, I wouldn't
do it on the packaging/build time.
Of course, providing numbers to show what the gains are would help
make the decision.
Cheers,
Danilo
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade branched for gnome 2.18
Hi Tristan, Sorry for the late response, On March 6th, Tristan Van Berkom wrote: I've already requested a string break for some important blockers (i.e. glade in 2.18 is feature incomplete without them)... and I'll be periodically requesting code freeze breaks for minor bug fixes on Glade 3.2.x (for instance I have a simple fix pending on: http://bugzilla.gnome.org/show_bug.cgi?id=396436 ). Since I was convinced by you that this is a real issue (properties in Glade files being lost, a serious regression), you are allowed to fix this. As agreed, translators should expect to have at least another 24 hours to update their translations since Glade3 release will be rolled out tomorrow near the deadline (which is, to remind my fellow translators, Monday 12UTC). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Belarussian Latin translation
Hi chpe, Today at 14:05, Christian Persch wrote: Recently, the Belarusian Latin translation team has started adding its translations to many GNOME modules. However, they chose to use the [EMAIL PROTECTED] name for their PO files, instead of following the precedent from [EMAIL PROTECTED] and [EMAIL PROTECTED] to use [EMAIL PROTECTED] Unfortunately, we'll be switching to '[EMAIL PROTECTED]' instead. The same is probably true for '[EMAIL PROTECTED]', since they had the same problem with getting their locale named [EMAIL PROTECTED] past Ulrich Drepper and into glibc (who claimed that the GNU libc established practice was to use lowercase fully-spelled-out English words for modifiers, whereas there were only a couple of modifiers at the time, such as euro and cyrillic: nothing I'd call a rule myself especially since cyrillic was only used with [EMAIL PROTECTED] which was going away, but anyway) So, even if Latn is an ISO 15924 identifier for Latin script, it made no difference, so while [EMAIL PROTECTED] never made it into GNU libc (after sitting in Bugzilla for ~3 years), [EMAIL PROTECTED] made it in just a couple of days ago (when Ulrich responded for the first time to request to add [EMAIL PROTECTED], we already had all of GNOME translated, and even Serbian KDE team started using it for Latin translations). Afaik, Fedora, SuSE, Debian, Ubuntu have been shipping [EMAIL PROTECTED] locale already, but I don't know about other distributions. Can we please resolve this before the GNOME 2.18 release, as to not create a backward compatibility problem for our users by having to change it in a later release? Since SVN allows file renames, this is not as big problem as we had with that until recently. As far as compatibility is concerned, people will be able to use both anyhow, and I guess Belarusian guys are actually better off with [EMAIL PROTECTED] since that's what'll get into GNU libc (yeah, big distributions will pick up anything people actually use, like they picked up [EMAIL PROTECTED], but smaller ones usually use only what GNU libc provides). And fwiw, GNU libc has a fallback mechanism, so even if locale with modifier is not present, the one without is used (so, if we later rename [EMAIL PROTECTED] to [EMAIL PROTECTED], people will only have to change their LC_* settings to point to it, and it will display proper translations, but things coming from locale such as dates will be in the wrong script). (This question was already asked on gtk-devel-list [ http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00044.html ] but apparently nobody from the [EMAIL PROTECTED] translation team has responded.) I don't know if Uzbekistani team is aware that they'll also need to change theirs to [EMAIL PROTECTED] (according to http://sources.redhat.com/ml/libc-alpha/2003-09/msg00091.html thread, and especially Ulrich's response). As far as Serbian is concerned, I wouldn't bother with it right now since we've got really fast recode-latin-sr script in GNU gettext 0.15 and later, and I want to generate [EMAIL PROTECTED] on the fly in the future (so, I'll modify makefiles for GNU gettext, intltool and gnome-doc-utils to do that). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problems with gnome-hello's OMF files
Today at 10:00, Nickolay V. Shmyrev wrote: Heh, migration is finished, hopefully without new problems. Thanks for taking care of this :) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problems with gnome-hello's OMF files
Hi Mariano, Today at 18:46, Mariano Suárez-Alvarez wrote: Someone who knows how to do it should really port gnome-hello to g-d-u, though. Cf. http://mail.gnome.org/archives/gnome-doc-list/2007-January/msg00067.html Just so it's clear that people have seen that email, but mostly lack the time to take on that responsibility, I'll point out: http://live.gnome.org/GnomeDocUtilsMigrationHowTo which should help in migration, and anyone who carries it out should be able to tell us if the docs are lacking. Anyone on #docs will be happy to help with minor issues that may come up in the migration. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: atk and gail branched
Hi Bill, On January 9th, Bill Haneman wrote: Danilo Šegan wrote: I know SVN makes no difference between tags and branches, but lets have at least some consistency. Can you please move these to gail/branches/? Li Yuan has pointed out the 'svn mv' command to me. Is that all that is needed? I think that should do it (sorry for the late response, it's hard to keep track of d-d-l traffic, so it's best to CC me :) When you've done it, just let me know so I can update l10n.gnome.org data. Thanks, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: atk and gail branched
Hi Bill, Today at 17:51, Bill Haneman wrote: I've created gnome-2.16 branches for atk and gail. atk seems to be under http://svn.gnome.org/viewcvs/atk/tags/gnome-2-16/ instead of http://svn.gnome.org/viewcvs/atk/branches/gnome-2-16/ Similarly for gail at: http://svn.gnome.org/viewcvs/gail/tags/gnome-2-16/ I know SVN makes no difference between tags and branches, but lets have at least some consistency. Can you please move these to gail/branches/? Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME git repositories? (was Re: GNOME subversion migration)
Hi Kjartan, Today at 22:12, Kjartan Maraas wrote: Maybe we should consider setting up a formal git infrastructure so that projects that want to use git will have a way to distribute their repositories in a more standard way across GNOME? git.gnome.org anyone? With a gitweb interface? And bzr? Mercurial? (I know at least some would be interested in using bzr, and I even remember some discussion about it on #gnome-hackers) This would encourage developers to use non-central repositories, thus making work of non-developers (think translators, artists, documentors) much harder. In other words, GNOME subprojects would not be able to work with those other repositories as easily as with the main CVS/SVN one. And where do we draw the line? Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME git repositories?
Today at 22:44, Germán Poó Caamaño wrote:
This would encourage developers to use non-central repositories, thus
making work of non-developers (think translators, artists,
documentors) much harder. In other words, GNOME subprojects would
not be able to work with those other repositories as easily as with
the main CVS/SVN one.
That is a big misunderstanding about how it works. Using a distributed
source system doesn't mean that doesn't exist any central ('main')
repository.
You misunderstood the point. Some developers would be using GIT,
others would be using bzr, yet others Mercurial. And anothers would
stick with SVN or CVS or something else altogether.
And you want translators, who often have problems with understanding
PO file and CVS command syntax itself, to cope with all of these? At
the same time? Or documentors who constantly mess up DocBook tags?
(it's not because they are stupid, it's because they are good at what
they do: translate, document, draw, etc.)
If the point is not yet clear:
Choose *ONE* RCS GNOME-wide, and stick with it
I am not saying they are any worse or better than SVN (actually, I
know they are better, except for the fact that SVN usage is so similar
to CVS that it'll be easier to migrate both developers and
non-developers to it).
Moreover, it can works the same way it has been working until now.
The big difference is any contributor can have his or her own copy
of the repository (as usual) but the whole history.
Not really, if you have to handle both GIT and SVN. And then add bzr,
mercurial, darcs into the mix.
And don't forget to think of our poor sysadmin team as well, who would
have to maintain central servers for all of these.
Gnome servers should provide enough infrastructure to help develop
Gnome and related software. We should not aim for project hosting
services, imo (we simply don't have the resources to do that).
Cheers,
Danilo
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME git repositories?
Today at 23:22, Sriram Ramkrishna wrote: Even better, you don't have to give a cvs/svn account to every contributor. Allowing the barrier of entry to be a lot easier. You guys seem to be engaging in the SVN vs. GIT (or any other RCS) again. I thought that this discussion was over, and I am not getting into it now ;) I am against having more than one way of accessing source code for GNOME source code. It's as simple as that. For the benefit of translators, documentors, artists, and heck, even developers (imagine this: to install GNOME, get gnome-panel using bzr, gtk+ and glib using git, nautilus using SVN, ...). I am also against GNOME SysAdmin team having to provide for different project hosting services. But if they feel they can take it, then by all means, be my guests and lets have git.gnome.org and bzr.gnome.org :) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
On Friday at 23:42, Matthew Paul Thomas wrote: Right, and the reason Epiphany can't *solely* use the language from the locale is that (as I understand it) the locale can refer to only one language. There is no way to say, for example, I prefer reading stuff in Swiss German, but if that's not available, give me Swiss French or France French. It would be good if this list could be set system-wide. Isn't this provided by LANGUAGE environment variable on GNU systems? Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
2.18 proposed modules: i18n evaluation
Hi all, This is my evaluation (with GTP spokesperson hat on) of the Gnome modules which are proposed for inclusion in 2.18. It's based only on the perceived localizability of the app, usually untested, but judging by the strings in the PO files, and how comfortable will GTP in working with them. I didn't evaluate anything else. If I failed in being objective (no doubt I did :), please point that out if you think it will affect final 'score'. Legend: - No objections: no objections whatsoever to including it - No strong objections: all objections can be easily addressed in 2.18 timeframe - Strong objections: it's doubtful objections can be addressed in time for 2.18; for modules listed below, it means they use outside SVN and I doubt they'd be willing to switch over to Gnome CVS Short evaluation: No objections: devhelp, NetworkManager No strong objections: Anjuta, Glade3, tracker, seahorse Strong objections: GnomeScan, MonoDevelop Read below for details. DESKTOP = gnomescan = Strong objection to including it. It seems to support l10n, but it's outside of Gnome CVS. Strings are otherwise fine and there seem not to be any common problems with them. The only big problem is that it's not using Gnome CVS. My recommendation would be to NOT include it UNLESS it's moved to Gnome CVS before the January 15th (so translators would actually have the time to work on it aside from string freeze period). Of course, if it's not moved at all, I would strongly oppose to including it in Gnome from I18N perspective. Only 4 translations, but the module seems small enough (~100 messages). No docs, so no gnome-doc-utils usage concerns. = NetworkManager = No objections. It uses Gnome CVS, is i18n-enabled, and everything seems to work fine. Based on i18n-merits, it IS recommended for inclusion. 23 languages with over 95% of a total of 192 strings translated. No docs, so no gnome-doc-utils usage concerns. = sea-horse = No strong objections. It uses Gnome CVS, is i18n-enabled, and everything seems to work fine. Based on i18n-merits, it IS recommended for inclusion. 6 translations above 50%, total of 745 messages. seahorse-0-8 branch is better with 16 translations of =98%, and a total of 527 messages (if translators would merge this into HEAD, it would probably be much better). Docs are using gnome-doc-utils (this is a good thing :), and they add another 303 messages to translation. = tracker = No strong objections. It uses Gnome CVS, there is some i18n support, but it hasn't been announced for translation (so no status pages). Only 3 translations, but the file is reasonably small (100 messages). Docs seem to be only available as man pages, and we don't support localizing them easily at the moment (if they used XML as a source format, it would be much easier). DEVTOOLS All of devhelp, anjuta and glade3 sit in the Gnome CVS. MonoDevelop is outside, so that's a big concern. DevHelp and Anjuta have been long-time Gnome modules, and they have reasonable translation support. = Anjuta = No strong objections. Anjuta POTFILES.in hasn't been updated recently, so that might be a concern. Otherwise, there are ~1700 messages (pretty large module) for translation, with 10 languages over 80%. Docs seem not to be ported over to gnome-doc-utils, so that's another i18n concern. = DevHelp = No objections. Small module (62 messages) with 21 languages over 80%. No docs so no concern over gnome-doc-utils usage there. = Glade3 = No strong objections. Uses Gnome CVS, messages seem fine. 739 messages for translation, but with only 4 languages over 75%. I am hoping some of old Glade translations can be reused (~1300 msgs, 30 languages with =80% translations). It uses gnome-doc-utils for the docs, so that's another plus. = MonoDevelop = Strong objection. It's i18n-enabled, and uses gettext PO files for translation, which is a good thing. There seems to be a placeholder documentation which is not using gnome-doc-utils (but it doesn't matter much since it's a placeholder, i.e. not real document). The big problem is that it's not using Gnome CVS for development, which is a serious barrier to GTP work (see gnomescan evaluation above). POTFILES.in also seems to be out of date (some 200 messages are missing, out of 1336 messages total), and there are 12 languages with ~1000 messages translated. This might still be a bigger problem then expected, since it's a large module and former translation teams might use different terminology from Gnome translation teams. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.18 proposed modules: i18n evaluation
Hi Don, Today at 17:59, Don Scorgie wrote: What about gnome-main-menu [1]? Is it still proposed (I may have missed something)? What's the i18n teams take on it? It's not listed in any of the ReleaseSuites on http://live.gnome.org/TwoPointSeventeen So, what's the status on that one? Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
Hi Matthew, On Monday at 11:48, Matthew Paul Thomas wrote: Ideally Epiphany's language preferences wouldn't be in Epiphany, they'd be in a system-wide preferences tool (as they are for Windows Internet Explorer with the Regional Settings control panel, and for Safari and other Mac browsers with the International preferences pane). The language list it configured would also determine the default for Totem's subtitle/audio language, and for any other application that needs to know your preferred languages (such as an ISV's app that ships with its own translations). If I remember correctly, Epiphany uses the language from the locale as the default (I have since set my languages in there manually, since sr-CS, sr caused some web site to crash, and I wanted to add hr in my list as well). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
2.18 proposed modules: i18n evaluation
Hi all, This is my evaluation (with GTP spokesperson hat on) of the Gnome modules which are proposed for inclusion in 2.18. It's based only on the perceived localizability of the app, usually untested, but judging by the strings in the PO files, and how comfortable will GTP in working with them. I didn't evaluate anything else. If I failed in being objective (no doubt I did :), please point that out if you think it will affect final 'score'. Legend: - No objections: no objections whatsoever to including it - No strong objections: all objections can be easily addressed in 2.18 timeframe - Strong objections: it's doubtful objections can be addressed in time for 2.18; for modules listed below, it means they use outside SVN and I doubt they'd be willing to switch over to Gnome CVS Short evaluation: No objections: devhelp, NetworkManager No strong objections: Anjuta, Glade3, tracker, seahorse Strong objections: GnomeScan, MonoDevelop Read below for details. DESKTOP = gnomescan = Strong objection to including it. It seems to support l10n, but it's outside of Gnome CVS. Strings are otherwise fine and there seem not to be any common problems with them. The only big problem is that it's not using Gnome CVS. My recommendation would be to NOT include it UNLESS it's moved to Gnome CVS before the January 15th (so translators would actually have the time to work on it aside from string freeze period). Of course, if it's not moved at all, I would strongly oppose to including it in Gnome from I18N perspective. Only 4 translations, but the module seems small enough (~100 messages). No docs, so no gnome-doc-utils usage concerns. = NetworkManager = No objections. It uses Gnome CVS, is i18n-enabled, and everything seems to work fine. Based on i18n-merits, it IS recommended for inclusion. 23 languages with over 95% of a total of 192 strings translated. No docs, so no gnome-doc-utils usage concerns. = sea-horse = No strong objections. It uses Gnome CVS, is i18n-enabled, and everything seems to work fine. Based on i18n-merits, it IS recommended for inclusion. 6 translations above 50%, total of 745 messages. seahorse-0-8 branch is better with 16 translations of =98%, and a total of 527 messages (if translators would merge this into HEAD, it would probably be much better). Docs are using gnome-doc-utils (this is a good thing :), and they add another 303 messages to translation. = tracker = No strong objections. It uses Gnome CVS, there is some i18n support, but it hasn't been announced for translation (so no status pages). Only 3 translations, but the file is reasonably small (100 messages). Docs seem to be only available as man pages, and we don't support localizing them easily at the moment (if they used XML as a source format, it would be much easier). DEVTOOLS All of devhelp, anjuta and glade3 sit in the Gnome CVS. MonoDevelop is outside, so that's a big concern. DevHelp and Anjuta have been long-time Gnome modules, and they have reasonable translation support. = Anjuta = No strong objections. Anjuta POTFILES.in hasn't been updated recently, so that might be a concern. Otherwise, there are ~1700 messages (pretty large module) for translation, with 10 languages over 80%. Docs seem not to be ported over to gnome-doc-utils, so that's another i18n concern. = DevHelp = No objections. Small module (62 messages) with 21 languages over 80%. No docs so no concern over gnome-doc-utils usage there. = Glade3 = No strong objections. Uses Gnome CVS, messages seem fine. 739 messages for translation, but with only 4 languages over 75%. I am hoping some of old Glade translations can be reused (~1300 msgs, 30 languages with =80% translations). It uses gnome-doc-utils for the docs, so that's another plus. = MonoDevelop = Strong objection. It's i18n-enabled, and uses gettext PO files for translation, which is a good thing. There seems to be a placeholder documentation which is not using gnome-doc-utils (but it doesn't matter much since it's a placeholder, i.e. not real document). The big problem is that it's not using Gnome CVS for development, which is a serious barrier to GTP work (see gnomescan evaluation above). POTFILES.in also seems to be out of date (some 200 messages are missing, out of 1336 messages total), and there are 12 languages with ~1000 messages translated. This might still be a bigger problem then expected, since it's a large module and former translation teams might use different terminology from Gnome translation teams. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to add Orca to GNOME 2.16
Today at 17:41, Sri Ramkrishna wrote: So there's been no comment on this (or I must have missed it). Are we considering Orca for GNOME 2.16[1]? It is pretty clear that we want to replace Gnopernicus with Orca, especially since Gnopernicus maintainers support that as well. Who are we to argue them? ;) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-themes branched
Yesterday at 18:09, Calum Benson wrote: I've just branched gnome-themes in preparation for 2.15 development work; branch name is gnome-2-14 as usual. Thanks for the notice, translation status pages updated. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: release notes: first draft
Hi Bob, Yesterday at 23:41, Bob Kashani wrote: I like this much better. It flows much nicer too. I made the changes. Also note that if you want translated release notes, you'll have to be much more strict about such changes at this time. We are only 5 days from a release, and there are only 3 or 4 translations under-way: http://kvota.net/doc-l10n/by-modules.html#release-notes With Gnome 2.12 we were very successful with translation (24 languages!), but notes were finished two weeks before the release, and stabilised at least a week before release. I think it looked really cool on http://gnome.org/start/2.12/ and it gave an impression of Gnome truly being the international desktop it is :) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: release notes: first draft
Today at 0:54, Elijah Newren wrote: On 3/9/06, Davyd Madeley [EMAIL PROTECTED] wrote: On Fri, Mar 10, 2006 at 12:27:32AM +0100, Danilo ??egan wrote: With Gnome 2.12 we were very successful with translation (24 languages!), but notes were finished two weeks before the release, and stabilised at least a week before release. I think it looked really cool on This is basically my fault for sucking really badly. I should stop offering to do things, because I suck. No, no, no -- you're a hero for all the work you do. You've had to handle a lot more work (fewer helping out, among other thigns), plus we got in the way by not getting the module decisions done in a reasonable amount of time. Sorry about that, btw. Thanks for all your rocking work on the release notes. Seconded. (...thinking... damn with that seconded thing) Davyd, you really, really are THE PROMOTER of any new Gnome releases. Your hot previews and work on the release notes is what energizes both us in/around Gnome, and those just looking at it from the outside! Keep it going :) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: release notes: first draft
Today at 1:37, Bob Kashani wrote: I am going to let Bob and Claus finish up with the editing, but I will understand if at GUADEC, any translators want to come up and punch me in the face. Not really, if we can negotiate a truce. See below. ;) In general I think that you've done a really good job. Most of the paragraphs are concise and to the point. Not bad for a CS guy. :) I also do understand Danilo's, concerns about translators so we will try and minimize the changes to make it easier for them. For any simple spelling, rewording or similar changes which don't change meaning, can I suggest you use en translation for them (that's what we did last year for some last-minute changes)? That means translations will stay complete and correct without spurious needs to update. Of course, if you do more extensive changes in a paragraph, fix all the small things as well ;) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
String freeze break in gnome-volume-manager
Hi Jeffrey, Your commit on February 24th to gnome-volume-manager broke the string freeze: http://cvs.gnome.org/viewcvs/gnome-volume-manager/src/manager.c?r1=1.130r2=1.131 Please revert this change and instead consider: - branching for Gnome 2.14 before introducing this change - asking for string freeze break approval (highly unlikely to get one from me, if the sole reason is the one in bug #326955[1]), following the procedure outlined on: http://live.gnome.org/ReleasePlanning/Freezes - putting a patch in Bugzilla and marking it as accepted_commit-after-freeze and committing it when you branch Cheers, Danilo [1] http://bugzilla.gnome.org/show_bug.cgi?id=326955 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions
Hi Dan, Today at 15:11, Dan Winship wrote: Do we have any evidence that any distro actually cares what we consider to be in and out of the desktop release? Is there some distro out there loyally shipping epiphany as its default browser and waiting for us to certify GIMP before they allow it into the default desktop install? There are distros who have version freeze dates for most packages way sooner than for our desktop components. I know Ubuntu and SuSE include what we declare stable even if they don't include incremental updates of other software for at least two months before our and their release. I guess Fedora does the same. I.e. distros trust our modules more than others'. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver
Hi Vincent, Today at 8:24, Vincent Untz wrote: We'll be trying something new for new modules in 2.16. I think most of us agree that it didn't turn out well for this cycle. Like: lets remove all desktop modules, and reevaluate them again? Not that it would bring any concrete results, but I'd love the flamefest (d-d-l is seriously lacking these days :) Now, seriously, can you at least give us a hint of what you have in mind? And who is we dammit? :) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-icon-theme branched for gnome-2-14
Hi guys, Today at 2:55, Rodney Dawes wrote: I have just branched gnome-icon-theme for gnome-2-14, from an earlier date in the 2.13 cycle, where the changes to follow the naming spec have not yet been implemented. A couple of fixes and a new icon used by the search functionality added to Nautilus in 2.14, are still in however. release-team, this is becoming a bit confusing—are we to use gnome-2-12 or gnome-2-14 branch for gnome-icon-theme (granted, your decision happened before dobey announced his plans for 2.14)? Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: CVS conflicts for po files in doc directories
On Tuesday at 21:16, Shaun McCance wrote: And Danilo, that reminds me, we *really* need to get some sort of sans-autogen sans-make method of updating documentation po files into gnome-doc-utils/xml2po in the next release cycle. I'm sure translators are sick of me forcing them to do full checkouts and actually build the software. Agreed. In most cases it's easy to work-out that (if a maintainer isn't using too complex scheme to construct variables to be passed to gnome-doc-utils.make stuff). But, we already have some similar rules for that in intltool? Or do we want to tell maintainers to be a bit more restricted with it ;) And I have something in my l10n-doc-status scripts as well (in Python) that can work out the simpler cases. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: CVS conflicts for po files in doc directories
Yesterday at 20:00, Elijah Newren wrote: On 1/30/06, Torsten Schoenfeld [EMAIL PROTECTED] wrote: Aloha, why am I seeing more and more CVS conflicts for *.po files in documentation directories? This happens for quite a few modules (gucharmap and gnome-applets come to mind); and their number is increasing. Is this related to xml2po? Can it be fixed? It may be related to: 2006-01-29 Shaun McCance shaunm gnome org * gnome-doc-utils.make: - Do not automatically update po files but I'm just taking a guess here... That should actually fix things ;) (I.e. your PO files got automatically updated before this when you ran make, and this resulted in them being changed from whatever is in CVS at the moment) So Torsten, try updating your gnome-doc-utils instead :) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [BUG] Volumes not translated due wrong POTFILES.in
Today at 12:27, Luca Ferretti wrote: It's quiet obvious that we want to have those translated. Feel free to patch POTFILES.in, and please don't forget to send an e-mail to gnome-i18n. No CVS access and no subscription to gnome-i18n :-P So could other brave do it? I've just fixed it. Thanks for the report. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: String review
Today at 21:08, Vincent Untz wrote: The difficult part is, however, to make maintainers use this database when they add new strings. I don't know how we could do this. I think it would be simple to make them use it provided we have a good similarity matching algorithm. Also, this will only make sense doing if we provide such a mechanism in the first place (or is anyone interested in hand-selecting all the cases? :). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Preliminary Gnome 2.14 Schedule
Hi Elijah, It's wonderful that you're taking initiative to streamline our release process! I love all the suggestions, and I'll chip in with my thoughts. Today at 7:42, Elijah Newren wrote: The specific solutions I'm proposing are: - Tarballs are due by 23:59 UTC on the Monday specified Can we also add a general guideline as to *earliest* when tarballs should be rolled out? I know we can't be too strict on this one (every now and then there will be a couple of exceptions; for some we will be using very old tarballs such as previous Gnome releases), but I believe documentation and translation projects would benefit from having exact date until they can work on something while being sure that their work will end up in the release. So far, I have always had problems answering the ultimate question of all translators: up to when can we submit our translations to be sure that they are making it into the release? Yeah, every day counts. Maybe that's what current two days in the roll out period is about, but I just want to make it a bit more specific. Asking for a simple notify gnome-i18n, gnome-doc-list if you are releasing early (just like Rich did with gcalctool in this round) would be a great help as well. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Evolution and Evolution-Data-Server branched
Hi Harish, (I've picked this from a response by Luis Villa :) On Wednesday at 16:34, Luis Villa wrote: On 8/31/05, Harish Krishnaswamy [EMAIL PROTECTED] wrote: hi, The gnome-2-12 branch for Evolution and Evolution-Data-Server has been created. This would be the stable branch for Evolution 2.4 and Evolution-Data-Server 1.4 Please don't forget to CC gnome-i18n and gnome-docs-list when creating new branches, especially this close to a release, since we may still work on HEAD not knowing that we need to switch! Translators, Evolution and Evolution Data Server have been branched for Gnome 2.12, so please use that and merge back any translations you did in a last couple of days! Translation status pages should show new branches when they update. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing: Project Ridley
Yesterday at 17:14, Rodney Dawes wrote: Beyond that, the only other thing which I care about that uses expat, is the XML::Parser perl module, which we require for intltool. But note that in the long run, I'd be willing to port intltool to libxml2. However, we all remember the problems we had with XML::Parser migration, and libxml2 Perl modules are even less likely to be installed. Most everything else in terms of Gnome, use libxml2 anyway. Gnumeric, Abiword, the background capplet, gconf, etc... all use libxml2. I believe gconf uses glib-internal (and incomplete) XML parser, but what matters is that it doesn't use expat. :) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 branched for 2.12
Today at 8:06, Brian Cameron wrote: The gdm2 GNOME module is now branched for 2.12. Try gnome-i18n@gnome.org instead of [EMAIL PROTECTED] (Hum, how about creating an alias?) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [BUG?] Issues in recent doc switch for gnome-panel
Hi Luca, Today at 8:12, Luca Ferretti wrote: Using g-d-u 0.3.2 if you don't declare DOC_FIGURES in Makefile.am images will be ignored. This variable needs the 'full relative' path to all images you want to install. See following reduced installation logs Shaun already fixed this problem: he called install-figs only if DOC_FIGURES was declared, so even if they would be installed by running make install-figs manually, there was a small problem that this target was not even called. Naughty, naughty Shaun! 1. Add DOC_FIGURES = figures/clocl_applet.png to Makefile.am and regenerate Makefile 1. Add DOC_FIGURES = figures/window_list_applet.png figures/window_list_group_applet.png to Makefile.am and regenerate Makefile These workarounds should not be needed anymore with CVS g-d-u. ### Fish ### 1. Add DOC_FIGURES = fish_applet.png to Makefile.am and regenerate Makefile 2. Note the missing figures/ directory in previous declaration You're expecting too much. I mean, it's not hard to do that, but it's kinda wrong, ya know? Figures can also be in any other directory. If you're suggesting that we REQUIRE everybody to use figures directory, I don't see why shouldn't we instead REQUIRE everybody to use full path to the figure, and allow pictures like help/C/fish_applet.png help/C/a11y-theme/fish_applet.png help/C/figures/fish_applet.png to be different, yet used in the same document. IMHO the Fish example should work. As well as you declare only basenamed XML filenames in DOC_INCLUDES, I suppose the DOC_FIGURES should accept basenamed PNG filenames. And it should be the right synopsis. And you do. Base in this context is where $DOC_MODULE.xml resides (i.e. help/C). Figures can be directly inside it as well, and they can be deeper in the hierarchy. Maybe a DOC_FIGURES_DIR (or DOC_FIGURES_DIRS) variable could be useful, if images aren't under XX/figures/ (but for example under XX/images). IMHO, you're complicating it too much. You can have them under not-figures/ already, and you just need to mention them one by one. I agree that there's no much point in requiring it to be figures, but that's only a recommendation. I mean, your suggestion is ok, but it's really not that important. If it was done from scratch, I'd recommend doing it, but I don't see the value in changing it now: either make it simple for yourself by putting all the images in figures, or put them wherever you wish and make it harder for yourself. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [BUG?] Issues in recent doc switch for gnome-panel
Yesterday at 23:51, Shaun McCance wrote: Probably not related. This is likely an issue of how gnome-doc-utils is calling xml2po. I think xml2po does something like take the basename of the po file as the language. I remember before having to adjust how I called it to make sure the language codes got set right. I suppose I didn't get it quite right. I'll look into it. I've did a small update to xml2po which should fix this. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
ANNOUNCEMENT: Gnome-Doc-Utils Migration Guide
Heya hackers, We've just written a guide to help you migrate your modules to gnome-doc-utils, which will immensly help both documentors and translators. Just head straight over to: http://live.gnome.org/GnomeDocUtilsMigrationHowTo The early winners are bug-buddy (which shaunm converted) and gnome-panel (rock on vuntz!). chpe has been working on enlightening the epiphany behind the scenes, and davyd is already convinced to make g-d-u do the work for gnome-applets. If you need any live help, you can find shaunm or danilo on IRC, but I'm sure other guys with experience will be glad to help as well :) (vuntz, chpe). Worthy of mention is that if you switch your module, you'll get doc translation statistics like those at: http://kvota.net/doc-l10n/by-modules.html (ok, they can be prettier, but that's not high priority yet :). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clearlooks and GNOME 2.12
Today at 22:42, Richard Stellingwerff wrote: Personally, I'd really prefer to keep distributing standalone packages, since it allows me to do more frequent releases. Nobody would object if gtk-engines got more frequent releases. :) I.e. this should not impact a decision, since if clearlooks is included and maintained inside gtk-engines, you could ask for releases as often as you wish, or even more likely, do them yourself. I can't imagine anyone complaining about someone else doing the work :) I'm not terribly aware of the release schedules and procedures of GNOME. As I understand, a few weeks before the new release there will be a feature freeze. How would this apply to Clearlooks? You'd switch to bug fixing mode for around two months. New development might happen on another branch (HEAD), while this one is stabilised. Though, I'm not sure if gtk-engines follows Gnome or Gtk+ schedule (they're different). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make check failures- gnome-vfs, e-d-s, at-spi
Today at 18:56, Elijah Newren wrote: Sane? Insane? Does it matter? I think it'd be useful, though I'm betting libwnck fails and I'll be unable to fix it (I wasn't able to last time I tried, but thankfully people smarter than I are handling the releases...) I managed once to build entire Gnome during 2.7 using jhbuild (with features jamesh just introduced back then to build outside of your checkout directory, basically mimicking what distcheck is doing, without the make check part :), and I remember having only to fix a few Makefile.am's to use $(top_srcdir) and $(top_builddir) where appropriate. And yeah, some gtk-doc stuff was causing big problems for me, but I can't remember if I resolved that or I just disabled it at the time. :( So, I think it should be doable, and more than useful! Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application/System Tools vs System/Administration
Yesterday at 21:36, Larry W. Virden wrote: On Thu, 2005-07-07 at 07:43 -0700, Rob Adams wrote: and focus-follows-mouse is just silly really, despite the fact that I use it :-) ). Sorry - but focus follows mouse is so far from silly that the word loses its meaning in context. Let me remind everyone that this is a discussion about showing this as a preferences capplet. To illustrate my point, I use the following: - focus follows mouse - double clicking titlebar shades the window - I don't have a taskbar anywhere on my desktop (I have a window list menu button though, but I rarely use it: I have a big [3x4] number of workspaces) - I don't have minimise on my titlebar (I just have close button on the left side, and general menu on the right—I should probably remove the menu one as well, since I rarely use it, and it's available with a right-click on the titlebar as well) To get to all of these, I need to use gconf-editor anyway. I didn't even know you could set some of these through a Windows capplet. I'm not yet ready to become your average home user (to use all the defaults), so I appreciate having these options, but I really don't care about the Windows crapplet. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Control center and capplet merging
Today at 11:09, Reinout van Schouwen wrote: I don't know what liboobs is, but you did remind me of the fact that the GNOME i18n applet still hasn't been integrated. Does anyone know the status of that? Can we get it in for 2.12? While servers are still up: http://bugzilla.gnome.org/show_bug.cgi?id=307121 Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Language and Culture Capplet update
Hi Peter, all the Gnome Hackers, I'm CCing d-d-l since this is a discussion about l10n API addition that will affect many developers as well. I've added my comments to bug Peter Nugent opened: http://bugzilla.gnome.org/show_bug.cgi?id=307121 and I'd appreciate if any of the hackers responsible for relevant pieces of code (glib or g-c-c, though I seriously doubt we want this API in g-c-c) can comment on this. I should state that this is kind of functionality that GTP seriously wants to see in Gnome! Peter, it'd also be nice to get a cleaner and simpler overview of the proposed API, and the reasoning behind it (i.e. why are date/time formats locales provide not enough, and how do we expect API users to select each of the formats; next, why is this not possible without introducing new API, i.e. what's the reason for it?). I'm holding my judgement until this is explained. When we resolve that, we should probably discuss the way to store settings (since it'd be hard to make Glib depend on GConf, and introducing pluggable backends sounds like overengineering). Cheers, Danilo Today at 10:58, Peter Nugent wrote: I have filed a bug 307121 with updated code and screenshots for this capplet. I would appreciate any feedback people can provide, especially owners of apps which use locale data. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: i18n and GNOME hackers
Hi Federico, Last Wednesday at 21:02, Federico Mena Quintero wrote: It would be great if you could start a checklist in live.gnome.org of particular APIs which are widely used and upon which people need to set up things like gettext domains. I could certainly use this for the Gnome certification thingy here :) http://live.gnome.org/GnomeCertification I added a couple of pointers to: http://live.gnome.org/GnomeI18nDeveloperTips Not sure if that helps. Oh, now that I think of it, when we're talking about Gnome Certification, we should also probably mention .desktop files, .schemas, etc even though it's mostly covered in Malcolm's i18n guide listed second under Documentation there. Note that I don't know the APIs too well, and some of the online API references seems to be pretty outdated (like libglade one I found through Google). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: i18n and GNOME hackers
Today at 16:27, Frederic Crozat wrote: So, if you are a non-english native speaker GNOME hacker (or if you are fluent enough to use GNOME in another language than english), please use it by default on your system and report bugs (when translations is there but not displayed). And of course, this call is also valid for translators who usually know which parts of applications they have already translated. I support this initiative by Frederic, and let me add that apart from misreferenced gettext domain names, it's not uncommon for programmers to miss appropriate calls to set up translation when they switch to GtkUIManager (from GtkItemFactory) or even miss to set up translation domain when they load in .glade files: these kinds of omissions are usually reflected in application menus being untranslated, so you can notice them quite fast. Btw, Frederic, what were the untranslated applications you noticed? I'm running 2.10 since it came out and I didn't notice any regressions in the apps I regularly use. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Idea for mailman lists
Today at 13:54, Dave Neary wrote: Is it possible to add an RSS feed for archives of mailman lists which makes it easy to subscribe read-only to mailing lists using rss? It's that many more ways that someone can read the list, and eventually ignore it for days if they don't have time without getting hundreds of mails building up. How about using gmane instead? (there's even blog.gmane.org, but it doesn't cover as much lists as the regular gmane) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Attempt to clean up gconf usage in gnomecc some...
Yesterday at 20:52, Kjartan Maraas wrote: This patch tries to clean up gconf usage so we at least unref GConfClient whenever we use them. There are some other bits in here as well, but nothing controversial. Feedback is much appreciated. I think this won't compile with GCC 2.95.* (or any C89 compiler). Are we sure we don't want to support them anymore? - client = gconf_client_get_default (); + + GConfClient *client = gconf_client_get_default (); (there's another similar change at the end of patch, but at the start of nested block, so it should work even with GCC 2.95; maybe I don't see enough context in this part, so if you're certain that you're not introducing compatibility problems, just ignore me :) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm2 string freeze breakage
Today at 13:48, Bill Haneman wrote: Perhaps. But with the political issues surrounding 'Taiwan', would it not be safer not to introduce this string? We're not proclaiming it's independence of China, in the same way that we're not proclaiming Hong Kong's independence of China, even though there's a string Chinese (Hong Kong). Taiwan _is_ the name of the province/country (depending on who you are :), so I see nothing disputable there (clearly, the Hong Kong example should indicate that we're not insisting on territories being countries in there, since it's a Special Administrative Region of People's Republic of China; we're simply not saying that Taiwan is not as well, but we aren't saying that it is either). Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eog string freeze breakages
Any news on this, Jens? Last Tuesday at 22:57, Danilo egan wrote: Hi Jens, (Though I suspect this was unintentional, and Jens only forgot to branch EOG for gnome-2-10 [at least I don't see it], I'm using almost standard mail template for string freeze breakages.) There have been numerous string freeze breakages (at least twelwe new/changed messages) in EOG: http://cvs.gnome.org/viewcvs/eog/libeog/eog-image.c?r1=1.44r2=1.45 http://cvs.gnome.org/viewcvs/eog/shell/eog-window.c?r1=1.125r2=1.126 Both seem to be part of a single commit: 2005-03-14 Jens Finke [EMAIL PROTECTED] * Merged the experimental-job-mgr branch back to head. What you probably want to do is to branch eog at some point before these changes, because I can hardly think of a reason to add 12 new strings in a string frozen branch now. If you still feel there's a need for string freeze breakage, I suggest to follow the procedure outlined below: http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks. Basically, we need (very) good reasons why are these new strings necessary. Cheers, Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
eog string freeze breakages
Hi Jens, (Though I suspect this was unintentional, and Jens only forgot to branch EOG for gnome-2-10 [at least I don't see it], I'm using almost standard mail template for string freeze breakages.) There have been numerous string freeze breakages (at least twelwe new/changed messages) in EOG: http://cvs.gnome.org/viewcvs/eog/libeog/eog-image.c?r1=1.44r2=1.45 http://cvs.gnome.org/viewcvs/eog/shell/eog-window.c?r1=1.125r2=1.126 Both seem to be part of a single commit: 2005-03-14 Jens Finke [EMAIL PROTECTED] * Merged the experimental-job-mgr branch back to head. What you probably want to do is to branch eog at some point before these changes, because I can hardly think of a reason to add 12 new strings in a string frozen branch now. If you still feel there's a need for string freeze breakage, I suggest to follow the procedure outlined below: http://developer.gnome.org/dotplan/tasks.html#ApprovingFreezeBreaks. Basically, we need (very) good reasons why are these new strings necessary. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New external dependency: iso-codes ?
Hi Simos, Today at 22:01, Simos Xenitellis wrote: It looks more canonical to me to make the dependancy to the Translation Project. You got it a bit mixed up :) Translation Project (TP) is basically for other programs what GTP is for Gnome: a translation project. You cannot add a dependency on GTP for any software module, because it's not software, it's a group of people and some infrastructure :) The discussion here was whether to make iso-codes build- and run-time dependencies of Gnome software. That can be done several ways, and one is to make it a soft dependency (everything would work fine even if it's not there, except there might be no translations), or hard dependency (package won't install if a hard dependency is not installed). For example, xkeyboard-config translations are a soft dependency of Gnome keyboard preferences: you get untranslated layout names if xkb-config is not included. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New external dependency: iso-codes ?
Today at 21:15, Christian Persch wrote: I'd like to add a new external dependency to GNOME Desktop: the iso-codes package. It's available from cvs [http://alioth.debian.org/projects/pkg-isocodes/] and tarball [http://people.debian.org/~mckinstry/iso-codes-0.45.tar.gz]. FWIW, you have my support in doing this. If this is agreed for entire Gnome, we (GTP) are going to start treating extensive lists of country and language names marked for translation as bugs, so developers beware! ;) Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] [RFC] Announcing: Control-Center-GUI 0.1
Today at 23:27, Rodney Dawes wrote: This is a bug, that I believe jody just fixed in HEAD. Given proper categories, you get the same UI that you were talking about, and that Mac OS X uses. Even better! So, what is wrong with it actually? Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Xlock on login
Hi Ryan, Today at 2:51, Ryan McDougall wrote: I think the best place to put this pre-load optimization is the same place Windows XP, (I think MacOSX,) and FC4 put it: On boot they read into RAM a working set of files optimally arranged on disk (100MB should take a couple seconds), so that (hopefully) starting GNOME should rarely ever seek to disk. This was discussed a couple of weeks or months back on this very same list, I think. Someone (Sean?) even did some benchmarks if I'm not mistaken. Or, perhaps this was only about re-arranging files on disk for better read throughoutput, I don't remember right now. Cheers, Danilo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
