Re: GnomeGoal proposal: change AM_INIT_AUTOMAKE to create xz compressed pax tarballs
Hi; Olav wrote: > If nooone objects to this I'd like to get this GnomeGoal up and > running asap (ideally before 3.1.2 unstable release on Jun 13). I'd prefer tar-ustar over tar-pax. When I tried to use tar-pax once (admittedly a long time ago) I got a bug report, and so switched to tar-ustar. Also, the passage that Javier quoted from the gnu tar manual about the 'future' version using pax by default exists there since 2004 and afaict nothing in this direction has happened since. More generally speaking, I don't like bumping the automake version required just to dist with xz. _Disting_ is something just one (or at most a few) people do, while everyone else just _builds_ either the tarball or from git. Since—if I understood your original mail correctly—install-module'ing a .tar.gz or .tar.bz2 will still work and create the .tar.xz automatically, I don't think a GnomeGoal to make this change globally is warranted. (Individual maintainers can, of course, still choose to bump the automake version and do dist-xz, for their modules.) Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and profiles implementation
Hi; Just to avoid duplicate work going on, I wanted to make it known here that I'm working on implementing gsettingslist right now :) Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi; LightDM is not currently listed on http://www.canonical.com/contributors ; can you confirm that it does not require, nor will ever in future require, copyright assignment? Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 in March 2011
Hi; Vincent Untz wrote: > (Porting to GTK+ 3.0 does not mean that you won't be able to use GTK+ > 2.0 anymore -- see what we are suggesting with the > --enable-gtk=2.0/3.0 configure flag) [...] >- add a --enable-gtk=2.0/3.0 configure flag: for some modules, it's > really easy to do and it's enough. Frédéric did it for a few > modules, and here's an example in gcalctool: > http://git.gnome.org/browse/gcalctool/commit/?id=a2250ad2 Just a tiny note: you say --enable-gtk, but the example you cited, and also all of my modules (vte, gnome-terminal, gnome-games, gucharmap), use --with-gtk=2.0|3.0 instead. Others (e.g. empathy) use --enable-gtk3 instead. I suggest we standardise on just one of these variants and use it for all module. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using AS_ALL_LINGUAS instead of po/LINGUAS
Hi; -1 from me; I don't see any advantage here. With the current scheme, we have po/LINGUAS which is disted automagically. With your scheme, we need po/LINGUAS.ignore (which you have to dist manually). Also, if you add a new po/xx.po file, configure isn't re-run automatically so the new entry isn't added to ALL_LINGUAS. This works with the current po/LINGUAS file (since inltool's Makefile.in.in evaluates the LINGUAS file at build time, not configure time). Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
Hi; > Le mardi 06 juillet 2010 à 09:00 -0400, Ryan Lortie a écrit : > > Anybody who has an application that is GPLv2-only and has accepted > > enough contributions that it has become an unreasonable proposition > > to relicense has made a significant mistake. > > Anyone who licenses his work under a license “or later version” takes > a significant risk, which is roughly similar to that of copyright > attribution. I don't think this is true. The GPL2 promises that "new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns." Contrast that with copyright assignment, where you don't have *any* guarantees about the terms the new 'owner' may choose to distribute your work under. Also, even if you do consider "or later versions" a significant risk, you should note that you've *already taken* this risk by using LGPL2.1-only, since LGPL2.1 allows using the work under GPL2 or any later version of the GPL. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
Hi; > > The problem is not only with third-party apps that use the platform. > > There are also some significant GPLv2 only libraries that GNOME apps > > may want to use. As examples, Poppler and ClamAV come to my mind. > > Incidentally, this is one of the major reasons that GNU PDF was made a > high priority project by the FSF: besides implementing a broader > subset of PDF, but to have it be LGPLvN+. Currently N is 3 for GNU > PDF, but also currently I hear poppler does a better job at what it > does. I can't be the only one who was excited about discovering there's a LGPL3+ pdf library out there! I work a bit on evince, and I had never heard about it. However, the excitement was brief, and terminated by actually checking out the code... Also, it seems libgnupdf is GPL3+, not *L*GPL. I was pointed to mupdf [http://mupdf.com/] which is GPL3+ and seems a bit further along, but not quite as good a poppler; also it's not using cairo (it has its own drawing system, and apparently no cairo impl of it exists so far)... > Still, given that GLib is not breaking ABI, it doesn't seem that > LGPLv3+ is an option for it. We should however (IMO) promote GPLv3+ > for applications, where possible. With my GNOME maintainer hat on, I already switched aisleriot to GPL3+ some time ago, and plan to do the same with my other app modules soon. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
Hi; Am Sat, 03 Jul 2010 19:29:13 +0100 schrieb Philip Withnall : > On Sat, 2010-07-03 at 19:48 +0200, Christian Persch wrote: > > Am Sat, 03 Jul 2010 17:08:36 +0200 > > schrieb Milan Bouchet-Valat : > > > If only one string was provided, it would be a pain to find what > > > a key is supposed to do without reading the full description. And > > > that's what makes the settings database more useful than a mere > > > addition of binary values (for example, if we want a « plumbing > > > tool » to tweak advanced settings, we need it to have short and > > > useful summaries). > > > > Makes sense. We should at least discourage schema writers from > > making the description just a reworded summary. > > > > Or, let's only have the one string, and take the first > > line (paragraph?) of it as the "summary", and any extra text as > > detail that will only be displayed in a tooltip, 'detailed info' > > area, etc. > > > > Like we do for our git commit messages :) > > Isn't that somewhat betraying the idea of XML as a _structured_ > representation of data? True. So I'd settle for the style Ryan proposes in the other reply, and telling schema writers that it's ok to omit if it would end up just being a slightly reworded summary. (As is the case in many current gconf schemas.) Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
Hi; Am Sat, 03 Jul 2010 17:08:36 +0200 schrieb Milan Bouchet-Valat : > Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit : > > Coincidentally, taking a look at all the and > > strings, it seems to me that once these value enumerations are taken > > out, not too much remains that justifies the split between two > > strings. IMHO we should consider dropping from gschema > > and only provide for the one strings. > In the case of these schemas, I think you're right, but in general > the split is really needed. Consider for example this Metacity key, > which is only one example among many others: > > false > Whether to resize with the right button > > Set this to true to resize with the right button and show a > menu with the middle button while holding down the key given in > "mouse-button-modifier"; set it to false to make it work > the opposite way around. > > > > If only one string was provided, it would be a pain to find what a key > is supposed to do without reading the full description. And that's > what makes the settings database more useful than a mere addition of > binary values (for example, if we want a « plumbing tool » to tweak > advanced settings, we need it to have short and useful summaries). Makes sense. We should at least discourage schema writers from making the description just a reworded summary. Or, let's only have the one string, and take the first line (paragraph?) of it as the "summary", and any extra text as detail that will only be displayed in a tooltip, 'detailed info' area, etc. Like we do for our git commit messages :) > > Looks like this should use a settings list, with a base schema > > containing "exec", "needs-term" (should be "needs-terminal" as > > below) keys, and an extended schema for the browser settings adding > > the "nremote" key. > I've considered this too when reading the file, but in the end I was > really not sure we gain anything with a list. GSettingsList is > intended for schemas that will be extended at runtime, while here we > have a list that is mostly set in stone. Apps only look for a known > schema, and will never want to get the list of all registered > applications, nor add an application to the list. > > So I don't think that's worth the complexity it would add I don't think it adds complexity, but reduces it. You only need to write the schema once, and then can just reference it and override its values (this is not in gsettings yet, but I think it's going to land soon?). Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
Hi;
Am Sat, 03 Jul 2010 13:22:16 -0400
schrieb Ryan Lortie :
> On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote:
> >
> > Finally, I'd like to suggest that gsettings-desktop-schemas install
> > a header file containing #define's for each schema ID, schema, path
> > and all the key names.
> >
> I tried to discuss this on IRC because I believe it's a good idea.
> It's nice to have the compiler yell at you because you typed
> G_DESKTOP_BACKROUND instead of silently allowing
> "org.gnome.desktop.backround".
Exactly. So let's do this :)
> I was even considering one step farther, defining macros like:
>
> #define g_desktop_background_settings_new() -> g_setting_new("...")
>
> That then leads to g_desktop_background_settings_get_style() macros
> and such. That might be going too far.
'Too far' would be anything that makes this into a library instead of
just a set of .h files. Anything less goes, as far as I'm concerned.
Regards,
Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GSettings schema writing guidance [was: dconf/GSettings namespace]
Hi;
I think we should provide a more in-depth guide on how to write schemas
for gsettings, convering e.g.:
- schema names: tld.foo.FooApp vs. tld.foo.foo-app vs ...
- paths: /tld/foo/foo-app/ vs /apps/foo-app/ vs ...
- what key names to use
- how the and should differ and what they
should (and should not) contain.
(E.g. IMHO for enum and flags settings, the GConf schemas used to
contain a complete enumeration of the valid values. Since these are
stored in the schema itself for gsettings, I think the description
need not do this anymore.) [Actually I wonder if we should just drop
the summary altogether and only provide the description?]
- how to store some common data types:
* colours: should they be stored as "s" ('rrggbb' or '#rrggbb' or
'#bbb' or ...) or "(yyy)" (tuple of 3 bytes) or
"(nnn)" (tuple of 3 int16's) ? And should it always contain also
the alpha component?
* remind the programmer that filenames need to be "ay" not "s" (and
advise to just use URIs instead which can be stored as "s" ?)
* command lines as one line ("s" / "ay"), or argv ("as" / "aay")
* enums, flags should use the built-in gsettings support for them
* (host, port) pairs (e.g. in the proxy settings): separate keys for
host and port, or an "(si)" tuple ?
* window sizes, should they be two "i" settings for width and height,
or an "(ii)" tuple? same for window positions
* generalising the two above, when to use several individual settings,
and when to just one setting containing an tuple
* etc.
- when to use child schemas
- when to use settings lists
Regards,
Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
desktop schemas review [was: Re: GSettings migration status]
Hi; I think we should use the opportunity of converting to gsettings to redesign the desktop schemas, not just do a 1:1 translation from gconf. Let me make some remarks about the gsettings desktop schemas as they right now are in gsettings-desktop-schemas module. org.gnome.desktop.background.gschema.xml.in: 'zoom' Picture Options Determines how the image set by wallpaper_filename is rendered. Possible values are "none", "wallpaper", "centered", "scaled", "stretched", "zoom", "spanned". I don't think we need to enumerate all choices in the here. With gsettings, the valid values are stored in the schema via the enum, so this is unnecessary work for translators, and superflous. Coincidentally, taking a look at all the and strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping from gschema and only provide for the one strings. '@datadir@/pixmaps/backgrounds/gnome/background-default.jpg' Picture Filename File to use for the background image. This is a common error. Filenames need to be stored as "ay" and *NOT* "s" (since "s" is UTF-8). (I think this needs some enhancement in glib-compile-schemas to be able to still put a string in .) 100 Picture Opacity Opacity with which to draw the background picture. IMHO, should be a "d" with instead. Also, I wonder if all the picture-* keys should be inside a child schema here. --- org.gnome.desktop.default-applications.gschema.xml: Looks like this should use a settings list, with a base schema containing "exec", "needs-term" (should be "needs-terminal" as below) keys, and an extended schema for the browser settings adding the "nremote" key. 'mozilla' Default browser Default browser for all URLs. I wonder if we should support "as" as argv here, instead. Also, whether this should be "ay" (or "aay") since technically, programme names need not be UTF-8. --- org.gnome.desktop.interface.gschema.xml: Looks ok, but maybe the keys could be named more consistently. --- org.gnome.desktop.lockdown.gschema.xml: I wonder if this schema should simply contain a flag setting, instead of several boolean lockdown settings? -- org.gnome.desktop.url-handlers.gschema.xml: This should be a settings list, with a base schema for the "enabled", "exec" and "needs-terminal" keys; actually the same base schema as the default-applications schemas above. --- org.gnome.system.proxy.gschema.xml: Should use a settings list for the various (http/https/ftp/socks) proxies. Maybe the developers working on GIO proxy support could look at this schema and see if it maps nicely to what their code supports ? '' HTTP proxy host name The machine name to proxy HTTP through. 8080 HTTP proxy port The port on the machine defined by "/system/proxy/http/host" that you proxy through. IMHO this is _one_ setting that belongs together, as a "(sq)" tuple (string, uint16). - Finally, I'd like to suggest that gsettings-desktop-schemas install a header file containing #define's for each schema ID, schema, path and all the key names. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External Dependency Proposal: libappindicator
Hi; Am Fri, 19 Feb 2010 09:18:10 -0600 schrieb Cody Russell : > On Fri, 2010-02-19 at 14:16 +0100, Christian Persch wrote: > > Also, why is this LGPL 2&3-only instead of the usual LGPL > > 2.1-or-later? > > Because seriously, everything should be this way. None of us should > be saying "LGPL 2.1 or later". Ask a lawyer, even one from the FSF, > how much sense it makes to license your software that way. Really? The FSF *recommends* that you add the "or later" clause; see e.g. [1]. And if you are concerned about what the later [L]GPL version will say, you should at least keep open the possibility to use it, by designating a trusted proxy to make the licence upgrade decision, like KDE does by deferring this to the KDE eV membership in their licensing policy[2]. You definitly don't need copyright assignment for this. IMHO Gnome ought to have a similar policy here. Regards, Christian [1] http://www.gnu.org/licenses/gpl-faq.html#VersionThreeOrLater [2] http://techbase.kde.org/Policies/Licensing_Policy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External Dependency Proposal: libappindicator
Hi; > I would like to propose libappindicator as an external dependency. > libappindicator is a simple library that provides a way for an > application to put a menu inside an application specific area, most > typically on a panel. It also provides a fallback to generic KDE > Status Notifier Item and Notification Area protocols. > > Webpage: http://launchpad.net/indicator-application > Design: > https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators > Tarballs: https://launchpad.net/indicator-application/+download > License: LGPL v2/3 > Bindings: Python and Mono I'd like register my immediate objection to accepting this as an external dependency. According to http://www.canonical.com/contributors this work is covered under canonical's horrible and inacceptable contributor agreement. IMNSHO Gnome should not depend on any work that treats external contributors in such a way. Also, why is this LGPL 2&3-only instead of the usual LGPL 2.1-or-later? Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A not about GtkBuilder conversion
Hi; > This is not how things are supposed to be done ! gtk-builder-convert > is not something you should or can rely on as a build tool. It is > purely a one-time conversion help, with the assumption that the > generated .ui files are manually checked and used as the primary > source afterwards. However it is not always feasible to do this. E.g. the module in question, gnome-terminal, still keeps the original glade files since at least at the time of its gtkbuilder conversion glade-3 was unable to work with the converted .ui files. And it's not much use to use gtbuilder files natively if one can't edit them afterwards! Is there any special reason that gtk-builder-convert is unsuitable as a build-time tool? If it has bugs, they should simply be fixed. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libchamplain as an external dependancy for GNOME 2.28
Hi; John Stowers wrote: > Unfortunately, the original TangoGPS author, [...], ignores any > emails from me, other osm-gps-map developers, or users, that request > permission to change the license of osm-gps-map to LGPL. > > I guess the lesson here is to never create a library, derived from a > GPL project, unless you are sure that the original copy write holders > are open to re-licensing those parts of the code to LGPL, aka mature > and reasonable people. There are good reasons to choose GPL even for a library[1]. The code's author not agreeing to relicense his GPL'd code under LGPL does not give you permission to insult him as ›unreasonable‹ or ›immature‹ like you did above. I think just ignoring such relicencing requests is perfectly fine behaviour, esp. if, as you seem to imply above, multiple persons have pestered the author about it. Christian [1] http://www.gnu.org/licenses/why-not-lgpl.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Preserve glade files when switching from libglade to gtkbuilder format
Hi; recently more projects have been switching from libglade to gtkbuilder, converting existing .glade files to .ui with gtk-builder-convert, and then svn removing the .glade files from svn. However, glade-3 is still not working on all features in the gtkbuilder format (e.g. nautilus' and gnome-terminal's .ui files break badly when edited with glade-3). Please check that glade-3 can correctly edit and save your .ui files; or else the .glade files should be kept in svn so that changes to the UI may still be made (using glade-2 or glade-3 w/ glade format and then converting again with gtk-builder-convert). Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ANNOUNCEMENT: The Future of Epiphany
Hi; Bastien Nocera wrote: > On Tue, 2008-04-01 at 10:12 -0500, Jason D. Clinton wrote: > > On Tue, Apr 1, 2008 at 8:21 AM, Christian Persch wrote: > > > This single back-end will be * WebKit *. > > > > Hoping this is not an April Fool's joke, also. +1 > > I hope it's one or that Christian will help fixor Totem's browser plugin > to not use XPCOM. I've already started to work on that. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New GNOME Dependency Proposal: libgcrypt
Hi; > Reached this point i think GNOME should make a decision on what crypto > library is it going to use/bless: > evolution is using libnss > gnome-keyring will using libgcrypt/libgnutls > gnome-vfs can use openssl or libgcrypt/libgnutls Epiphany/Gecko uses NSS too. What's GVFS going to use, same as gnome-vfs? > Under certain circumstances gnome can be using the three > libraries! > > I think gnome should choose on of the libraries and stick to > it instead > of using the three of them. > > Summarizing, you are asking evo developers to port it to > gcrypt/gnutls, isn't it? No, why? Epiphany and evo use NSS, keyring and vfs use gcrypt/gnutls, so it's a draw :) I think the chances that Gecko is going away from NSS are about zero. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Epiphany and Epiphany Extensions branched for GNOME 2.18
Hi; Le jeudi 15 mars 2007 à 11:00 +0200, Lucas Rocha a écrit : > Hi Christian, > > What are the Epiphany plans for GNOME 2.20? We haven't really had time to plan which features we want to add for 2.20. The only thing that I have firm plans for---but of which I'm not sure I'll have the time to do it---is to finish GnomeGeckoEmbed, and to make Epiphany a XULrunner application using GGE instead of gtkmozembed. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Belarussian Latin translation
Hi; 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] 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? (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.) Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Limiting svn-commits-list to your project
Hi; > The svn-commits-list mailinglist now has a topic per SVN module. You can > configure svn-commits-list to only send the commit mails you are > interested in. I'd like to use this to limit the numbers of message I receive from svn-commits-list. But I also want to receive the mail for any commit that _I_ make, regardless of the module this commit is in. Would it be possible to implement that while still limiting the list of topics received normally? Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Remove gtk_window_set_wmclass call in gnome-hello
Hi, Le dimanche 04 février 2007 à 13:57 +0300, Nickolay V. Shmyrev a écrit : > В Сбт, 03/02/2007 в 19:52 +0100, Christian Persch пишет: > Hm, there are both help and doc subdirs in gnome-hello. While first is > converted to gnome-doc-utils, second one leaved as is :( Actually I have > no idea how it was done so, but probably we can just remove doc subdir. Yes, the doc subdir was unused (and contained no docs at all, just the infrastructure). I removed it in svn. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Remove gtk_window_set_wmclass call in gnome-hello
Hi, I've committed your patch; thanks for writing it! I don't see the OMF problems anymore; those files have been removed from svn. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Extra REQUIRED_AUTOMAKE_VERSION setting in gnome-hello's autogen.sh
Hi, > Anyway, there's an extra setting of REQUIRED_AUTOMAKE_VERSION in > gnome-hello's autogen.sh (it's overriden later in the file). The > attached patch removes it. Thanks; I've committed the patch to svn. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME Network Proxy Resolver
Hi, Le mercredi 22 novembre 2006 à 21:03 +0100, Vincent Untz a écrit : > So, hmm, just pinging: Christian, are you willing to propose this for > 2.18, or do you think it's too early? GNPR itself is ready, but since it's useless without gnome-vfs making use of it [http://bugzilla.gnome.org/show_bug.cgi?id=123900], I'm not proposing it at this time. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Multi-headed gecko apps [was: Re: Proposing GtkUnique 1.0 as a blessed external dependency]
Hi, I'd just like to point out that gecko is _not_ multi-head safe. So any single-instance application that uses gecko will need one instance _per screen_. And if it uses a (gecko) profile, it'll be basically impossible to use it on more than one screen at a time since you cannot share the profile among several running geckos. (There was some work done to allow this, but afaik it's incomplete and not enabled in standard builds.) Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME Network Proxy Resolver
Hi, Le jeudi 26 octobre 2006 à 18:38 +0800, James Henstridge a écrit : > Have you considered adding support for web proxy autodetection to this > (the "Auto-detect proxy settings for this network" option in firefox). > There is a copy of the internet draft available here: > > > http://www.web-cache.com/Writings/Internet-Drafts/draft-ietf-wrec-wpad-01.txt > > It is basically a protocol for discovering the location of the PAC > file for a network, using DHCP or DNS. As I understand it, the DHCP > part of the spec should be possible using NetworkManager. The DNS > based lookup should work without it. No, I haven't considered that. This programme is just a wrapper around necko's proxy service, so it'll support anything that necko supports. Necko has (limited?) WPAD support, which it handles internally just like ordinary PAC with a fixed URL: "http://wpad/wpad.dat";. The problem is that our Network Preferences capplet doesn't have an entry for WPAD. We could either handle that internally (using that URL if the autoconfig_url is empty), or expect the user to input that URL into the capplet. If you need anything that's not implemented by necko yet, it should be added to necko itself, not to GNOME Network Proxy Resolver. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME Network Proxy Resolver
Hi, Le mercredi 25 octobre 2006 à 23:29 +0100, Bastien Nocera a écrit : > That feature was missing for ages in the control-center (and GNOME > applications). This fixes a bunch of very old GNOME bugs like: > http://bugzilla.gnome.org/show_bug.cgi?id=123900 Note that it doesn't actually fix that but *yet*, since there's no patch for gnome-vfs. It's on the TODO; but I was actually hoping that by announcing this software, someone else with the requisite knowledge about gnome-vfs would feel motivated to write that patch before me :) Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies
Hi, > On 9/11/06, Elijah Newren wrote: > > On 9/11/06, Matthias Clasen wrote: > > The topic came up earlier, and I think there was a general consensus > > that it is a good idea to freeze the versions of external dependencies, > > and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. I would prefer to use the cvs/svn/whatever modules on the tag corresponding to the release, if it exists. That way you can use your jhbuild checkout to make patches (cvs diff), which is impossible for tarball builds. > I've put together a _preliminary_ page to help push these two ideas > along at http://live.gnome.org/TwoPointSeventeen/ExternalDependencies. > There may be inaccuracies or omissions there, but it has the basics > already. Thoughts? Comments? >From that lgo page: > xulrunner (mozilla) > 1.5.0.6 > http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/1.5.0.6/source/ The link points to the firefox source, not xulrunner. While xulrunner 1.8.0 doesn't suffice for epiphany dependency (you need some patches), xulrunner from the 1.8 branch (what the current jhbuild moduleset is building: MOZILLA_1_8_BRANCH) does. There's going to be a xulrunner 1.8.1 _release_ some time after the ff 2.0 release (see http://benjamin.smedbergs.us/blog/2006-08-22/xulrunner-updates/ ), so I think it should be safe to use that as the gecko dependency version for epiphany for the Gnome 2.18 release. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Epiphany branched for 2.16
Hi, Epiphany is now branched for Gnome 2.16; the branch name is "gnome-2-16". Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Epiphany & Epiphany Extensions branched
Hi, Epiphany and Epiphany Extensions have branched for GNOME 2.14. The branch name is "gnome-2-14". Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: breakage caused by removed icons from gnome-icon-theme
Hi, Rodney Dawes wrote: > On Sun, 2006-02-05 at 15:04 +0100, Christian Persch wrote: > > Le samedi 04 fÃvrier 2006 Ã 23:14 -0500, Matthias Clasen a Ãcrit : > > > On 2/4/06, Christian Persch wrote: > > > > The latest gnome-icon-theme release has removed the "gnome-spinner" and > > > > "gnome-spinner-rest" themed icons, causing breakage in (at least) > > > > epiphany, nautilus, gedit and beagle. Other people have told me that > > > > other removed icons also cause problems in nautilus and deskbar-applet. > > > > This removal needs to be reverted. > > > > > > Do you have a list of those other removed icons ? > > > > I downloaded the 2.12.1 and 2.13.6 tarballs from ftp (you can see from > > the size differences alone that it's a huge removal, 2.12.1's .bz2 is > > 3MB, and 2.13.6 only 2MB!), installed in different prefixes, and did a > > bit of find + diff magic, and the result seems to be that 187 icons > > names that are in 2.12.1 are not in the 2.13.6 install either as regular > > file or symlink (list attached). > > But this list does not show which icons are in active use. It simply > shows a list of files that were removed. I guarantee that there are a > lot more than 187 icons in gnome-icon-theme that aren't even being used. 153 of the removed icons are gnome-mime-* icons which are used automatically as mime type icons from libgnomeui's gnome-icon-lookup. Same for the gnome-fs-* icons, partly by libgnomeui, partly from nautilus. Nautilus also uses some gnome-dev-* icons. And the spinner icons are used widely, epiphany + nautilus + gedit + beagle (at least). That accounts for most of the removed icons already, and I just checked a few of the gnome core desktop modules that I have checked out; I didn't even check any third-party applications! Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: breakage caused by removed icons from gnome-icon-theme
Hi, Le samedi 04 février 2006 à 23:14 -0500, Matthias Clasen a écrit : > On 2/4/06, Christian Persch <[EMAIL PROTECTED]> wrote: > > The latest gnome-icon-theme release has removed the "gnome-spinner" and > > "gnome-spinner-rest" themed icons, causing breakage in (at least) > > epiphany, nautilus, gedit and beagle. Other people have told me that > > other removed icons also cause problems in nautilus and deskbar-applet. > > This removal needs to be reverted. > > Do you have a list of those other removed icons ? I downloaded the 2.12.1 and 2.13.6 tarballs from ftp (you can see from the size differences alone that it's a huge removal, 2.12.1's .bz2 is 3MB, and 2.13.6 only 2MB!), installed in different prefixes, and did a bit of find + diff magic, and the result seems to be that 187 icons names that are in 2.12.1 are not in the 2.13.6 install either as regular file or symlink (list attached). > > The new g-i-t has already been discussed here, > > http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00302.html, > > but insufficient emphasis seems to have been made about backward > > compatibility. While participants have asked about how to upgrade their > > apps, we should instead ask what happens when the user upgrades g-i-t, but > > does not simultaneously upgrade all his apps (apps which may not be > > maintained anymore, even!). > > > > Arguably the icon names provided by gnome desktop's gnome-icon-theme are > > part of some sort of ABI; should they therefore part of our ABI > > stability guarantee? > > Yes, at least we should avoid shooting our own foot by removing icon names > that > are in active use by gnome applications. Time to revert to > gnome-icon-theme 2.12 ? IMO yes. Regards, Christian -- 2.12.1-list 2006-02-05 14:55:25.0 +0100 gnome-character-map.png gnome-dev-cdrom.png gnome-dev-dvd.png gnome-dev-memory.png gnome-dev-pci.png gnome-dev-pcmcia.png gnome-dev-symlink.png gnome-fs-blockdev.png gnome-fs-chardev.png gnome-fs-directory-accept.icon gnome-fs-directory.icon gnome-fs-directory-visiting.icon gnome-fs-executable.png gnome-fs-fifo.png gnome-fs-loading-icon.png gnome-fs-locally-shared.png gnome-fs-regular.icon gnome-fs-share-private.png gnome-fs-socket.png gnome-fs-web.png gnome-library.png gnome-mime-application-par.png gnome-mime-application-pgp-encrypted.png gnome-mime-application-pgp-keys.png gnome-mime-application-pgp.png gnome-mime-application-pgp-signature.png gnome-mime-application.png gnome-mime-application-qif.png gnome-mime-application-rhythmbox-effect.png gnome-mime-application-rhythmbox-playlist.png gnome-mime-application-smil.png gnome-mime-application-vnd.ms-powerpoint.png gnome-mime-application-vnd.oasis.opendocument.chart.png gnome-mime-application-vnd.oasis.opendocument.database.png gnome-mime-application-vnd.oasis.opendocument.drawing.png gnome-mime-application-vnd.oasis.opendocument.formula.png gnome-mime-application-vnd.oasis.opendocument.graphics-template.png gnome-mime-application-vnd.oasis.opendocument.image.png gnome-mime-application-vnd.oasis.opendocument.presentation-template.png gnome-mime-application-vnd.oasis.opendocument.spreadsheet-template.png gnome-mime-application-vnd.oasis.opendocument.text-master.png gnome-mime-application-vnd.oasis.opendocument.text-template.png gnome-mime-application-vnd.oasis.opendocument.text-web.png gnome-mime-application-vnd.sun.xml.draw.png gnome-mime-application-vnd.sun.xml.writer.template.png gnome-mime-application-x-backup.png gnome-mime-application-x-bittorrent.png gnome-mime-application-x-bla.png gnome-mime-application-x-blender.png gnome-mime-application-x-blf.png gnome-mime-application-x-blv.png gnome-mime-application-x-cd-image.png gnome-mime-application-x-class-file.png gnome-mime-application-x-core-file.png gnome-mime-application-x-core.png gnome-mime-application-x-dc-rom.png gnome-mime-application-x-desktop.png gnome-mime-application-x-dia-diagram.png gnome-mime-application-x-dv.png gnome-mime-application-x-e-theme.png gnome-mime-application-x-executable.png gnome-mime-application-x-extension-nfo.png gnome-mime-application-x-extension-par2.png gnome-mime-application-x-font-afm.png gnome-mime-application-x-font-bdf.png gnome-mime-application-x-font-linux-psf.png gnome-mime-application-x-font-pcf.png gnome-mime-application-x-font-sunos-news.png gnome-mime-application-x-font-ttf.png gnome-mime-application-x-gameboy-rom.png gnome-mime-application-x-genesis-rom.png gnome-mime-application-x-glade.png gnome-mime-application-x-gnome-app-info.png gnome-mime-application-x-gnucash.png gnome-mime-application-x-gtktalog.png gnome-mime-application-x-ipod-firmware.png gnome-mime-application-x-jar.png gnome-mime-application-x-java-byte-code.png gnome-mime-application-x-lha.png gnome-mime-application-x-lhz.png gnome-mime-applicati
breakage caused by removed icons from gnome-icon-theme
Hi, The latest gnome-icon-theme release has removed the "gnome-spinner" and "gnome-spinner-rest" themed icons, causing breakage in (at least) epiphany, nautilus, gedit and beagle. Other people have told me that other removed icons also cause problems in nautilus and deskbar-applet. This removal needs to be reverted. The new g-i-t has already been discussed here, http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00302.html, but insufficient emphasis seems to have been made about backward compatibility. While participants have asked about how to upgrade their apps, we should instead ask what happens when the user upgrades g-i-t, but does not simultaneously upgrade all his apps (apps which may not be maintained anymore, even!). Arguably the icon names provided by gnome desktop's gnome-icon-theme are part of some sort of ABI; should they therefore part of our ABI stability guarantee? Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: "Document font" pref [was: Re: asking for approval for bug 160454]]
Hi, Le jeudi 26 janvier 2006 à 14:57 -0600, Shaun McCance a écrit : > Epiphany and Yelp both already say 'Fixed width', so let's > get some consistency here. Christian? Done. Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: "Document font" pref [was: Re: asking for approval for bug 160454]]
Hi, Le jeudi 26 janvier 2006 à 14:57 -0600, Shaun McCance a écrit : > On Thu, 2006-01-26 at 14:34 -0600, Federico Mena Quintero wrote: > > email message attachment, "Forwarded message - "Document font" pref > > [was: Re: asking for approval for bug 160454]" > > > Forwarded Message > > > From: Christian Persch <[EMAIL PROTECTED]> > > > To: Federico Mena Quintero <[EMAIL PROTECTED]> > > > Cc: [EMAIL PROTECTED] > > > Subject: "Document font" pref [was: Re: asking for approval for bug > > > 160454] > > > Date: Thu, 26 Jan 2006 20:46:55 +0100 > > > > > > HI, > > > > > > Le jeudi 26 janvier 2006 à 11:50 -0600, Federico Mena Quintero a écrit : > > > > On Wed, 2006-01-25 at 18:48 +0100, Christian Persch wrote: > > > > > > > > > the patch > > > > > [http://bugzilla.gnome.org/attachment.cgi?id=58055&action=view] from > > > > > bug > > > > > http://bugzilla.gnome.org/show_bug.cgi?id=160454 adds a "Document > > > > > font" > > > > > button in the control centre fonts capplet, to set the gconf key that > > > > > exists since libgnome 2.12 > > > > > [http://bugzilla.gnome.org/show_bug.cgi?id=160453]. > > > > > > > > I'm curious; do you know which programs use this key? > > > > The obvious ones *should*: epiphany, tomboy, yelp, evolution. Do you > > > > know if they actually do that? > > > > > > AFAIK, only Epiphany uses it, but it'll be trivial to make yelp and > > > devhelp use it. > > > Does anyone know if we use the "Document Font" gconf key anywhere other > > than Epiphany? > > > > Federico > > I didn't even realize we'd added it to libgnome already, and > I'm the one who requested it. Making Yelp default to it will > be easy. Devhelp and Evolution should also be changed to use > it. And Evolution should change its 'Terminal Font' string. > Have you ever used a terminal inside Evolution? I haven't. > > But, what was committed to control-center changed the string > 'Terminal font' to 'Monospace font'. All well and good that > we got rid of that horrible 'Terminal font' thing, but it > should probably be 'Fixed width font'. Yes, I did initially > suggest 'Monospace font', and I cooked the initial patch that > used that term. But I changed my mind, because that's the > sort of indecisive person I think I might possibly be. > > Epiphany and Yelp both already say 'Fixed width', so let's > get some consistency here. Christian? Yes, it should use "Fixed width", IMHO. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libgnome goption argument parsing and ABI stability
Hi, libgnome's gnome_program_init now supports GOption argument parsing. The gnome modules supply their GOptionGroup*'s via a hook func in the GnomeModuleInfo struct. The question in http://bugzilla.gnome.org/show_bug.cgi?id=326846 is now whether we can ABI-compatibly use a function pointer of type typedef GOptionGroup* (*GnomeModuleGetGOptionGroupFunc) (void) in the GnomeModuleInfo structure instead of gpointer (libgnome/libgnome/gnome-program.h): -gpointerexpansion1; +GnomeModuleGetGOptionGroupFunc get_goption_group_func; Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
String review
Hi, For quite some time, the general inconsistency of strings in the various GNOME modules has irritated me. For example, let's just look at some strings in GNOME: bug-buddy: "There already exists a file name '%s'.\n\nDo you wish to overwrite this file?" eog 1: "Overwrite file %s?" eog 2: "A file named '%s' already exists." epiphany: "A file %s already exists." evo 1: "%s already exists\nDo you want to overwrite it?" evo 2: "A file by that name already exists.\nOverwrite it?" galeon: "The file %s already exists.\nDo you want to replace it?" gedit 1: "A file named \"%s\" already exists.\n" gedit 2: "The file \"%s\" already exists" gnome-screenshot: "The file \"%s\" already exists. Would you like to replace it?" gseachtool: "The document \"%s\" already exists. Would you like to replace it?" gnumeric: "A file called %s already exists in %s.\n\nDo you want to save over it?" nautilus-cd-burner: "A file named \"%s\" already exists. Do you want to overwrite it?" totem: "A file named '%s' already exists. Are you sure you want to overwrite it?" --- You'll notice: - the varying messagestyle: "[do] it?", "Would you like to...?", "Are you sure you want to...?", "Do you want to...?". Is the file X, is it 'called' X, or 'named' X? - the varying presentation of the message, i.e. how the variable data (%s) is embedded in it: no quotes, single quotes, double quotes, pango markup. To fix this, I think we need: - a String Guidelines addendum to the HIG. The HIG already tells us what capitalisation to use in which circumstances; we need a complete style guide; - a database of all (present and past) string in all GNOME modules, and ways to find 'similar' strings to unify - a string review process to fix the existing strings as well as new strings when they're are added. Unifying strings will also make the work of translators easier by reducing the number of strings to translate. What do you think? Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libgnome*/libbonobo* and GOption
Hi, glib since version 2.6 has an option parser, GOption. But currently it's not possible to use gnome_program_init() with GOption. Pawel Sliwowski has provided patches for libgnome* and libbonobo* in http://bugzilla.gnome.org/show_bug.cgi?id=307312 . Since API freeze is in a few days and I think this is an important improvement, I'd like to get this reviewed and checked in. libgnome*/libbonobo* maintainers, can you please review / comment on these patches? Thanks, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new gnome-common release?
Hi, Le dimanche 19 juin 2005 à 16:32 +0100, Bastien Nocera a écrit : > On Sun, 2005-06-19 at 16:52 +0200, Christian Persch wrote: > > the latest gnome-common release is 2.8.0, but cvs contains some > > important fixes. gnome-common/MAINTAINERS lists "Malcolm Tredinnick > > <[EMAIL PROTECTED]>" as the maintainer, but he hasn't made a > > commit to it in more than a year. Is he still the maintainer, or if not, > > who is authorised to make a new release? > > I think most people agree that gnome-common isn't something that should > be packaged (at least that's true for Fedora/Red Hat distros), as gnome- > common is a development tool, to build from CVS. I think it should be > removed altogether from the FTP site, so as not to create confusion. > > If somebody is going to compile a program from CVS, they might as well > check out gnome-common at the same time. gnome-autogen.sh / the gnome common macros aren't just useful for things from gnome cvs. You can also use them in your own gnome programs; nothing says that you have to have gnome modules from cvs when developing programs against the platform. IMHO, gnome-common is part of a sane gnome development environment, and should therefore be released and packaged. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
new gnome-common release?
Hi, the latest gnome-common release is 2.8.0, but cvs contains some important fixes. gnome-common/MAINTAINERS lists "Malcolm Tredinnick <[EMAIL PROTECTED]>" as the maintainer, but he hasn't made a commit to it in more than a year. Is he still the maintainer, or if not, who is authorised to make a new release? Regards, Christian ___ 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, Le lundi 07 mars 2005 Ã 20:47 -0600, Federico Mena Quintero a Ãcrit : > On Mon, 2005-03-07 at 22:26 +0100, Christian Persch wrote: > > - If you have locale codes "ab_CD" and want to translate that into a > > human-readable description, you have to parse XML files from iso-codes > > package (there's also a tabular format, but that one is 'in flux', to > > cite the maintainer). Epiphany has code to do that (and Galeon has > > copied it already); if it's of interest to other modules, the code could > > be separated out for easy cut-and-paste (or even upstreamed as a library > > into the iso-codes package). > > Would it be feasible to write an preprocessor that munges the XML at > compile-time into some mmap()able binary file? That way we'll avoid a > lot of memory bloat. Sure, that should be feasible. Although, to avoid memory bloat, shouldn't that file be in iso-codes and therefore shared with between all apps, instead of per-app? Regards, Christian ___ 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,
Le lundi 07 mars 2005 Ã 20:44 +, Bastien Nocera a Ãcrit :
> On Mon, 2005-03-07 at 21:15 +0100, Christian Persch wrote:
> > Hi,
> >
> > 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].
> >
> > Using this package will remove the duplicated translations of language
> > and country names from GNOME programs. Epiphany and Galeon already have
> > support for iso-codes (optional dependency atm), and there's a bug with
> > patch to make gedit's spell-check using it too
> > [http://bugzilla.gnome.org/show_bug.cgi?id=150535].
> >
> > If nobody objects, I'm going to go ahead and make it a hard dependency
> > for Epiphany, and add the module to the gnome-2.12 jhbuild moduleset.
>
> Are the country names translated as well?
> I'd be interested in using that in Totem, for the subtitles/soundtracks
> menus, and preferences.
Yes, there's "iso_639" domain for the languages, and "iso_3166" domain
for the country names.
There are two ways to get translated language/locale names:
- If you only want to support a fixed set, you can proceed as with any
other translatable strings. Say, you have "Engligh (United Kingdom)".
You store those 2 separately, { "English", "United Kingdom" }, translate
the language name in the "iso_639" gettext domain, the country name in
the "iso_3166" domain, and build the string from that.
- If you have locale codes "ab_CD" and want to translate that into a
human-readable description, you have to parse XML files from iso-codes
package (there's also a tabular format, but that one is 'in flux', to
cite the maintainer). Epiphany has code to do that (and Galeon has
copied it already); if it's of interest to other modules, the code could
be separated out for easy cut-and-paste (or even upstreamed as a library
into the iso-codes package).
Regards,
Christian
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
New external dependency: iso-codes ?
Hi, 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]. Using this package will remove the duplicated translations of language and country names from GNOME programs. Epiphany and Galeon already have support for iso-codes (optional dependency atm), and there's a bug with patch to make gedit's spell-check using it too [http://bugzilla.gnome.org/show_bug.cgi?id=150535]. If nobody objects, I'm going to go ahead and make it a hard dependency for Epiphany, and add the module to the gnome-2.12 jhbuild moduleset. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Epiphany and Epiphany Extensions branched
Hi, Epiphany Epiphany Extensions have branched for GNOME 2.10. The branch is called "gnome-2-10". @gnome-i18n: Since modules not in desktop can only have one branch listed on the translationstatus page, please stay with HEAD for Epiphany Extensions. However, translators should also update the gnome-2-10 branch, since there will be regular releases at the same time as Epiphany releases for GNOME 2.10.x. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Intltool and disting of .gmo files
Hi, Le mardi 01 mars 2005 Ã 11:02 +0800, James Henstridge a Ãcrit : >Rodney Dawes wrote: > >>Currently, intltool is distributing the generated .gmo files, within >>tarballs. Christian Persch recently filed a bug against intltool, as >>this still causes some issues with builddir != srcdir. I'd prefer to >>not duplicate generated files if possible. If anyone has sufficient >>reason as to why they should be distributed, please speak up now, or >>I'm going to fix intltool to stop distributing them tonight, and make >>a release with some other fixes as well. The bug in question is: >> >>http://bugzilla.gnome.org/show_bug.cgi?id=166724 >> >> >I think the reason why gettext's Makefile.in.in distributes the .gmo >files is so that you can install the translations from a tarball install >even if you don't have the gettext utilities installed (msgfmt, etc). Removing the .gmo files has been proposed before, in a thread about tarball sizes: http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00070.html It will lead to substantial decreases in tarball sizes. For example, I just stopped distributing .gmo files for Epiphany, and the tarball went from 3.628 MB to 2.768 MB (1.5.6 -> 1.5.7 .tar.bz2's). >From a follow-up to the above mail, http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00073.html : > As an experiment the gmo files were deleted from the gnumeric > tarballs. Nobody noticed they were gone. I think the tarball size savings are much more important than an added build dependency on gettext utilities. Regards, Christian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
