Re: The hall of bloat
On Mon, 16 May 2005, Soeren Sandmann wrote: There is a cost if the mapping has just a few random pages filled as you have to fill in the whole page table heirarchy down to the page in question. Isn't it always the case that you have to fill in the page table hierarchy down to the pages that you are actually using, regardless of the size of the mapping? Why would a mapping of 8K with both pages used require more page table entries than a mapping of 10M with two pages used? I'm no export here, but I think this is what Allan was saying: If you have a 10M stack that only uses the last two couple of pages, then the page table for the whole 10M will be initialized, most of them not mapped though. So the penalty is allocating and initializing 10M/4k=2560 page structs. Søren --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome terminal displaying utf-8 unicode text
On Tue, 14 Jun 2005, Krishna Mohan Gundu wrote: gnome-terminal does not display utf-8 unicode text correctly, atleast the telugu codes 0x0C00-0x0C7F and I believe most indic code tables. What do you mean does not display? I would like to know which source files I should look to for to correct the behavior. I'm a random Joe here, but I do not think rendering complex scripts is in the near future of gnome-terminal (vte to be exact.) --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: xscreensaver, any plan do drop it !!
On Fri, 8 Jul 2005, Bastien Nocera wrote: We definitely need a way to have a poke at the screensaver so that it doesn't get enabled without resorting to the current fake key events hacks. Ah... And I thought its the weirdest bug of all software that when running xine and switching windows using alt+tab, I get my keyboard language changed once in a while... And that after once running gok, running xine brings up a you pressed shift too many times, do you need any help dialog that I don't even know how to turn off... And that running xine brings the Typing Break screen lock up every 20 minutes even I don't touch the mouse and keyboard... What I didn't know is that it was all to free me from turning off the screensaver when watching movies...that I do anyway, since mplayer doesn't have this feature of sending fake key events... sigh --behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Certification for GNOME apps
On Thu, 14 Jul 2005, Jonathan Blandford wrote: Behdad Esfahbod [EMAIL PROTECTED] writes: On Thu, 14 Jul 2005, Alan Cox wrote: On Mer, 2005-07-13 at 21:04, Jonathan Blandford wrote: The first two seem like no-brainers, but what are you thinking of 'harming the name of GNOME'? Is a clause requiring acceptable levels of privacy sufficient? Do you have other, concrete concerns here? I guess the extreme example might be What do you do if someone comes to you with a HIG compliant, gtk+ using, accessible, i18n translated 'Bomb the New York Subway' game [hello MI5] There are things you want a reason never to be associated with. Or one day we may want to refuse certification from companies that support the other operating system :D. Is the foundation going to certify apps or are companies allowed to evaluate and certify their own apps? If the former, should there be any fee for getting GNOME certified? To make it more clear, the intention is to make this a self-certification system. We (GNOME) don't really want to get into the business of certifying at the moment, and we should make it clear that the products are certified aren't inherently endorsed by GNOME at all. Then I don't see how Alan's point can be applied. Someone with a Bomb... game should be free to label GNOME certified if it happens to satisfy the technical aspects. And it should be clear that it's a self-certificate. Maybe it should not be called a certificate after all. GNOME Friendly may be a better term. Thanks, -Jonathan --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build break: gnome-keyring
On Fri, 15 Jul 2005, Alexander Larsson wrote: On Thu, 2005-07-14 at 23:13 +0200, Murray Cumming wrote: A clean checkout of gnome-keyring in jhbuild gives me: gcc -DHAVE_CONFIG_H -I. -I. -I. -DPREFIX=\/opt/gnome212\ -DBINDIR=\/opt/gnome212/bin\ -DLIBEXECDIR=\/opt/gnome212/libexec\ -DGNOMELOCALEDIR=\/opt/gnome212/share/locale\ -I. -I. -D_XOPEN_SOURCE -I/opt/gnome212/include/gtk-2.0 -I/opt/gnome212/lib/gtk-2.0/include -I/opt/gnome212/include/atk-1.0 -I/usr/include/freetype2 -I/opt/gnome212/include/cairo -I/opt/gnome212/include/pango-1.0 -I/opt/gnome212/include -I/usr/include/libpng12 -I/usr/X11R6/include -I/opt/gnome212/include/glib-2.0 -I/opt/gnome212/lib/glib-2.0/include -I/opt/gnome212/include/glib-2.0 -I/opt/gnome212/lib/glib-2.0/include -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith-Wcast-align -Wsign-compare -Werror -g -O2 -Wno-strict-aliasing -Wno-sign-compare -c `test -f 'gnome-keyring-daemon.c' || echo './'`gnome-keyring-daemon.c cc1: warnings being treated as errors gnome-keyring-daemon.c: In function ‘gnome_keyring_application_ref_new_from_pid’: gnome-keyring-daemon.c:347: warning: implicit declaration of function ‘readlink’ gnome-keyring-daemon.c:347: warning: nested extern declaration of ‘readlink’ make[2]: *** [gnome-keyring-daemon.o] Error 1 This looks very strange. readlink is part of libc, and man 2 readlink gives: #include unistd.h int readlink(const char *path, char *buf, size_t bufsiz); gnome-keyring-daemon.c includes unistd.h, so I don't understand why this would happen. Seems like an issue with your installation? I just checked out HEAD and don't have that problem. I do have problem with symbol gtk_window_set_icon_name, that probably means my gtk+ is not recent enough, but then configure should catch that. --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Mon, 18 Jul 2005, Luis Villa wrote: We're not lacking people doing tinderboxing.[1] The thing we're really missing (which has always been more important than tinderboxing, IMHO) is for someone to build daily rpms and debs for popular distributions, so that 'average' users can use rug, yum, or apt to run CVS HEAD every day. One way to go about is to require all involved modules to have an RPM .spec file, and jhbuild can be instructed to build and install RPMs, but most probably this will not be accepted practice in GNOME. Or am I wrong? Luis [1] Though ATM it is just me, and doing it on other platforms (solaris, bsd, gcc4, -j 1) would be great. --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: make distcheck in tinderbox [was Re: make check failures- gnome-vfs, e-d-s, at-spi]
On Tue, 19 Jul 2005, Mark McLoughlin wrote: I think I'm with Matthias on this - make distcheck shows plenty of issues that aren't going to affect anyone in reality, and no maintainer wants to be pestered every day about the latest random thing that's gotten screwed up. If people want to distribute snapshots from CVS, then make dist will do fine. If the resulting tarball can't be built, then *they* can report *that* issue. That's going to involve a lot less problems reported and maintainers can be confident that by fixing the issues they're actually doing something useful. I don't quite agree here. 'make distcheck' mainly checks things like building in a different directory, or from readonly source base, which are quite useful to packagers and distro people. And the point is that, if a package passes make distcheck, then any future break would be a one-line fix of adding a file to the Makefile or something like that. If fixing it is a bigger problem, like redoing part of the build system in another way, then that would better be fixed sooner than just before the release. Cheers, Mark. --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: audioconvert! the new super script to convert audio files! would you like to include it?
On Fri, 5 Aug 2005, Rodney Dawes wrote: Having said that, I've not yet seen the original e-mail, and have not googled to find the software in question, so have yet to try it. However, I still am not sure that nautilus scripts is the best UI for doing something which may be so important to the user. Converting the audio when the user chooses to sync it to their hardware device, in the music library application, is definitely not the way to do it though. I have a 60GB iPod, and would certainly not want to wait for the amount of time it would take to convert 60GB of my OGG files, to MP3. I also would not want the software to assume that the iPod does not support OGG, either. It may not do so officially, but I do intend to install iPodLinux on it, so that I can just use OGGs directly. The plan is that eventually hal can tell you what formats the device support. -- dobey --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: tinderbox breakages in moz, soup, gnome-menus, libgnomeprint
On Sat, 13 Aug 2005, Tor Lillqvist wrote: I hope libgnomeprint is fixed now: 2005-08-14 Tor Lillqvist [EMAIL PROTECTED] * libgnomeprint/filters/Makefile.am (install-exec-hook): Hack to make make install work, especially in tinderbox-like situations. See http://mail.gnome.org/archives/desktop-devel-list/2005-August/msg00110.html The real fix would be to change the source code organization of libgnomeprint to avoid the need to cd back and forth and run sub-makes. A suggestion: put libgnomeprintfilter in a directory of its own, as a sibling to libgnomeprint. The plugin modules should also be in a sibling directory to libgnomeprint, not a subdirectory of it. The top-level Makefile.am would have them in SUBDIRS in the order: libgnomeprintfilter, libgnomeprint, filters. I think the libs would then naturally build in the correct dependency order? Not sure how it performs with make -j though. --tml --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing: Project Ridley
On Thu, 25 Aug 2005, Rodney Dawes wrote: Not for me. The installed package on my machine requires libxml2, but does not have a dependency on libexpat. However, the dbus-gtk stuff seems to, though presumably that is indirect due to pango's dependency on expat, which gtk+ requires for obvious reasons. Excuse me?! grep -r expat pango/ doesn't suggest anything. behdad -- dobey On Thu, 2005-08-25 at 19:32 +0300, Olexiy Avramchenko wrote: dbus also depends on expat. Olexiy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing: Project Ridley
On Thu, 25 Aug 2005, Rodney Dawes wrote: On Thu, 2005-08-25 at 13:33 -0400, Behdad Esfahbod wrote: On Thu, 25 Aug 2005, Rodney Dawes wrote: Not for me. The installed package on my machine requires libxml2, but does not have a dependency on libexpat. However, the dbus-gtk stuff seems to, though presumably that is indirect due to pango's dependency on expat, which gtk+ requires for obvious reasons. Excuse me?! grep -r expat pango/ doesn't suggest anything. Jesus. Doesn't anyone read the entire thread. Pango depends on expat indirectly through fontconfig. Sheesh. I don't call that pango's dependency on expat. Fontconfig have been already discussed in the thread. -- dobey --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing xrdb for 10% startup win?
On Sun, 28 Aug 2005, Michael Banck wrote: On Sun, Aug 28, 2005 at 11:37:31AM +0100, Gustavo J. A. M. Carneiro wrote: So how about GNOME doing this instead: 1- stat(~/.Xresources) -- if fail return 2- stat(~/.Xresources.compiled) 3- if ~/.Xresources.compiled does not exist OR ~/.Xresources.compiled older than ~/.Xresources: 3.a) run cpp ~/.Xresources -o ~/.Xresources.compiled 4- Run xrdb -nocpp ~/.Xresources.compiled Why not grep for any preprocessor statements, and only run cpp if some are present? Or simply use make with cpp-produced dependency rules! 15 minutes of hacking. Michael --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing xrdb for 10% startup win?
On Sun, 28 Aug 2005, Ikke wrote:
On Sun, 2005-08-28 at 07:57 -0400, Behdad Esfahbod wrote:
Or simply use make with cpp-produced dependency rules! 15
minutes of hacking.
Stopwatch just started, waiting for the patch ;)
Attached. Ok, 30 mintues ;).
--behdad
http://behdad.org/--- /etc/X11/xinit/xinitrc-common.orig 2005-08-28 08:06:35.0 -0400
+++ /etc/X11/xinit/xinitrc-common 2005-08-28 08:33:37.0 -0400
@@ -24,8 +24,20 @@
sysxkbmap=/etc/X11/Xkbmap
# merge in defaults
-[ -r $sysresources ] xrdb -merge $sysresources
-[ -r $userresources ] xrdb -merge $userresources
+[ -r $sysresources ] xrdb -nocpp -merge $sysresources
+if [ -r $userresources ]; then
+{
+ echo -include $userresources.dep
+ echo '%.compiled: %'
+ echo ' cpp -MP -MD -MF $.dep -MT $@ -o $@ -E -nostdinc $'
+} | make -f /dev/stdin $userresources.compiled /dev/null
+
+if [ $? = 0 ]; then
+ xrdb -nocpp -merge $userresources.compiled
+else
+ xrdb -merge $userresources
+fi
+fi
# merge in keymaps
if [ -r $sysxkbmap ]; then
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing xrdb for 10% startup win?
On Mon, 29 Aug 2005, Lorenzo Colitti wrote: Alexander Larsson wrote: So, as Owen says, most of the time is spent just reading the cc1 binary into memory. I have no idea why it's reading around all over the place instead of performing one big sequential read of the whole file though. My guess is that it just maps the whole executable on start, and then demand loads pages as they are needed (i.e. on page faults). Yes, I suppose you're right! Thanks for enlightening me. However, that's not the most efficient way to load *anything* if you know you're going to need the whole file. I see this happening with shared libraries a lot. But surely someone has thought of this before? That's in fact my Summer of Code project :-). http://preload.sf.net/ Cheers, Lorenzo --behdad http://behdad.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: EOG features
On Wed, 30 Nov 2005, Calum Benson wrote: On 30 Nov 2005, at 21:40, Lucas Rocha wrote: I'm having a little dilema about EOG redesign: should EOG be able to save image changes (rotation) to disk? I tend to say no because, actually, EOG is an image VIEWER (there is GIMP for image editing). I think the question here is whether you consider rotation a viewing or editing function. I'd say it's certainly as much of one as the other, so I think it's fine to be able to rotate images in EOG, and to save the rotated image with the original filename-- provided you don't just save the image automatically when the user rotates it, as rotation is often lossy, and you don't want to be losing the user's data behind their backs. Rotating jpegs is lossless. And that's a good reason to autosave on rotation :) --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glib 2.10 / Pango 1.? for GNOME 2.14?
On Thu, 19 Jan 2006, Luca Ferretti wrote: Il giorno mer, 18/01/2006 alle 10.21 -0600, Federico Mena Quintero ha scritto: Sorry that I dropped the ball on this, and haven't followed all the discussion. Other than Pango optimizations and and GSlice in Glib, is there a compelling reason to use the new Glib/Pango in GNOME 2.14? Unicode 4.1 ? Yes, which is very important IMHO. Also Pango HEAD handles OpenType Latin (and other basic scripts) fonts. It also does cairo-fc hexbox drawing. That change deserves going into stable branch, but it was a non-obvious change and needed some porting work, so I didn't do myself. I think a better way to rephrase Federico's question is: should the floating stuff be rolled back? I think that was discussed and closed already. So we have a glib release that we want to not use?! The question is really about glib now. Pango is using some new stuff in latest glib, includeing g_slice, like many other modules do already.. --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: CVS branches
On Wed, 8 Feb 2006, Gustavo J. A. M. Carneiro wrote: And I have a case when I forgot to add a regular tag at the start of a branch. So now I'm finding it very hard to obtain a diff of all changes since I started the branch. I'll have to do it manually, file by file, looking at revision numbers :-/ You can still add such a tag. Just figure out the date you made the branch (that you can do I suppose, there's no reason you cannot), do cvs co -D the-date, and cvs tag. CVS branches are hard, you have to admit it ;-) Right. And Carl Worth wrote to tell us how easy it is in git: http://lists.freedesktop.org/archives/cairo/2006-February/006255.html --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: requesting official list of modules and versions for GNOME 2.14
On Sun, 12 Feb 2006, Paul Drain wrote: - a remote user causing trouble (multiple incorrect SSH password attempts, for example). I would love Your system is under attack. So StarCrafty. :-D Oops, I successfully spammed ddl. --behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Only one instance of a capplet should be allowed
On Tue, 21 Feb 2006, Havoc Pennington wrote:
Virtually all apps really should be single-instance (though they often
allow multiple document windows). There should be an API in GTK for it,
in fact ignoring back compat, single-instance ought to be the default
behavior for a GNOME application unless the programmer does something
special. Probably too late to make it the default, but it should at
least be easy.
May I ask for the reason? Processes are cheap in Unix, and we
have been making all kind of static data shared among processes.
By overly making all apps be single-instance, we only make you
lose more of your work when a process crashes... If type-system
initialization and such is an issue here, the kdeinit road can be
taken. Apps can be categorized in three groups:
1) Those that it doesn't make much sense to run in more than
one instance. Capplets are probably a good example of this.
This access a resource that is best not accessed by more than one
application at a time. Like your gconf configurations.
2) Those that are preferred to just pop-up on later
invocations, but it may make sense to run more than one instances
of them too, in certain circumstances. Your favorite music
player and gaim fit in this category. Normally when you press
the gaim launcher, you want a gaim to pop up, you don't need a
new instance most of the time. Sometimes you may want to run a
separate gaim instance in booth-mode where it loads no
configuration and logs nothing...
3) Those that there's no reason (other than technical reasons)
to do single-instance. They typically don't have much shared
configuration/preferences. Evince may be a good example of this.
Evince is single-instance right now, but that's just the way it
is implemented I guess. It could have been non-single-instance
and perform quite the same.
Since arg parsing/handling is different for single-instance apps
(certain kinds of arg don't make sense for instances after the first,
such as --display) gtk could offer a gtk_init() alternative perhaps. The
Can you elaborate? Why doesn't --display make sense?
behdad
API would let an app register a new instance callback essentially,
which would be called when the app is first launched, and also if it's
launched again and forwarded to an existing instance.
Something like:
int
new_launch_callback(int argc, char **argv)
{
}
int main(int argc, char **argv)
{
gtk_set_instance_handler(new_launch_callback);
return gtk_invoke_instance(argc, argv);
}
If the app is already running, then the callback is not invoked in this
process but instead invoked again in the existing process. If the app is
not already running, callback is invoked in the current process.
There are a variety of complexities, but this is a pretty longstanding
thing nobody has ever fixed... every app is hand-rolling some wacky
solution.
Havoc
--behdad
http://behdad.org/
Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill
-- Dan Bern, New American Language
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: release notes: first draft
Oops. Forgot to CC lists. On Tue, 7 Mar 2006, Behdad Esfahbod wrote: Neat job. In front page: free software = Free Software Users - Performance: font rendering = text rendering (we did not optimizing the actual drawing at all, just the text layout...) the entire dictionary = an entire English word list / an entire dictionary Developers: Developer's Platform = Developers' Platform Cheers, behdad On Mon, 6 Mar 2006, Davyd Madeley wrote: Ok guys and gals. I am announcing a preliminary draft of the release notes for 2.14. We now require proof readers for spelling, grammar and technical correctness. The latest committed version is online at: http://www.gnome.org/start/2.14/notes/C/index.html You can also check out the release notes from CVS: http://cvs.gnome.org/viewcvs/gnomeweb-wml/www.gnome.org/start/2.14/notes/docbook/C/ We are using gnome-doc-utils for translation. I hope the translators know how to get all of that working, because I have no idea. Warning, I AM AN AUSTRALIAN, SPELLINGS MAY BE CONSIDERED INCORRECT. My grammar is also pretty appalling. Please send through corrections for these. Feel free to correct minor spelling mistakes yourself. Discussion should happen on list as appropriate or on the IRC channel #release-notes on irc.gnome.org. Addendum: - If anyone knows the status of the LiveCD, that section requires updating. - Danilo was meant to be providing the i18n stats page, he said he added it, but I can't see where. - Does anyone want to take charge on writing a press release? I am willing to raise my hand again if so required. --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: critical warnings; turn them off now?
On Tue, 7 Mar 2006, Marco Barisione wrote:
versions = g_strsplit (VERSION, ., 3);
if (versions versions [0] versions [1])
{
int major;
major = atoi (versions [1]);
if ((major % 2) != 0 is_later_than_date_of_doom ())
I believe we used to call that 'minor'.
--behdad
http://behdad.org/
Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill
-- Dan Bern, New American Language
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: critical warnings; turn them off now?
On Tue, 7 Mar 2006, Federico Mena Quintero wrote: On Tue, 2006-03-07 at 15:39 +, Bill Haneman wrote: Since we're now in code freeze for 2.14, shouldn't we turn off the critical warnings behavior in gnome-session now? They'll turn themselves on automatically when the version number reaches .14; they are on in .13 (they are based on even/odd). By the way, shouldn't that be enabled/disabled using configure/Makefile/preprocessor magic instead of parsing the version number? There are lots of places where this causes unnecessary crashes, particularly in gail and at-spi. While we want to fix them eventually, it's made accessibility pretty much DOA in 2.13 so far. A critical warning is not some annoying spew in your console which you can ignore; it is an indication that something has gone HORRIBLY wrong and you should fix it immediately. It is not a faint light that says check engine, it is a big siren screaming, HOLY SHIT, SOMEONE PUT SUGAR IN YOUR GAS TANK. In many cases it's a false alarm. Something that should not have marked as such in the first place. From my experience with Pango modules recently, one major cause of these false alarms are g_return_if_fail()s. It's important to differentiate between some unusual but perfectly valid failure of something (like failing to lock a font face, because the font file may have been removed), and invalid input from the user. With former, you may want to do a g_warning and return, only with latter one should use g_return_if_fail. In other words, you should use g_return_if_fail in cases that upon seeing the crash, the developer has something to fix. This is not quite the case when font locking fails :) Federico --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Supporting po/LINGUAS in 2.16
On Mon, 10 Apr 2006, Rodney Dawes wrote: On another note, can we please discuss major changes such as this, on this list, before deciding on making them goals that people should be working on? Completely agreed. As someone who wrote one of the current goals, I was a bit scared by how the goal went live with review from only three people, and it could have been flawed seriously. In this case (AppIcons) it probably is not, but the PoLinguas raised the internal this-is-a-nasty-hack signal of me too. It indeed works *for now*, but I too think that we should not spent this massive effort on things we know should change soon. I would like to take the opportunity to thank Vincent for starting the GnomeGoals project again. I can literally see new contributors coming in as part of the proejct. Awesome! --behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Supporting po/LINGUAS in 2.16
On Mon, 10 Apr 2006, Adam Schreiber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Behdad Esfahbod wrote: Completely agreed. As someone who wrote one of the current goals, I was a bit scared by how the goal went live with review from only three people, and it could have been flawed seriously. In this case (AppIcons) it probably is not, but the PoLinguas raised the internal this-is-a-nasty-hack signal of me too. It indeed works *for now*, but I too think that we should not spent this massive effort on things we know should change soon. Behdad, While we're on the topic of the AppIcon goal, could you respond to the question raised earlier today? Hi Adam, As far as I can understand from reading them icon-theme spec, what I wrote in the GnomeGoal only applies to application icons. For one thing because we are installing into icons/theme/48x48/apps. It should similar for other icons too, but I'm no expert. behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: LINGUAS file support in po directories
On Thu, 13 Apr 2006, Vincent Untz wrote:
Le mardi 11 avril 2006 à 23:22 -0400, Rodney Dawes a écrit :
OK,
So, in accordance with previous correspondence I sent about the use of
po/LINGUAS rather than ALL_LINGUAS in configure.{in,ac}, I hereby
present to you, the Correct (TM) way to migrate to using the LINGUAS
file in your po subdirectory or even multiple subdirectories with
different levels of i18n support.
Great!
I updated http://live.gnome.org/GnomeGoals/PoLinguas accordingly. Could
you verify there's no insanity in there (or fix them)?
And Rodney, can you make that 0.35 release or at least bump the
version up to 0.35, so we can simply require 0.35 instead of
0.34.90?
behdad
Thanks,
Vincent
--behdad
http://behdad.org/
Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill
-- Dan Bern, New American Language
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The Bango Project
On Mon, 17 Apr 2006, Jakub Steiner wrote: On Thu, 2006-04-13 at 22:56 -0400, Jon Bolt wrote: The Bango Project With a perfect name like this, this project cannot but succeed! ;) Isn't that what Pango is called with certain accents? ;) --behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Mentoring for GNOME in Google Summer of Code
Hello freedom lovers, As you probably know by now, GNOME will be participating in the Google Summer of Code again this year. For details about the program visit: http://code.google.com/soc/ and this page about the GNOME involvement: http://live.gnome.org/SummerOfCode2006 We are now looking for mentors. To apply for mentorship you need a Google account (GMail account works) and should sign up here: http://code.google.com/soc/mentor_step1.html and then choose GNOME as (one of) the organization you want to mentor for. Of course we do not promise to assign projects to everybody signing up, but we try our best to optimize our use of resources. Also note that, mentors are volunteers, and will be rewarded by: 1) gaining experience mentoring a motivated student, 2) having a student doing paid work on your favorite project, 3) potential to get the said student as a longterm new developer for your project, 4) getting a Google Summer of Code t-shirt, 5) help GNOME Foundation get a $500 donation per project. Based on previous year's experience, we are targeting 20 projects for now, but if we get enough volunteers, ideas, and good applications, we may go much higher as well. The Mono Project did an excellent job last year in best using the SoC programme and we should learn from them. Good old Migy again ;). You are encouraged to append ideas to the pool of ideas: http://live.gnome.org/SummerOfCode2006/Ideas Please take some time and think about what your project(s) can benefit most from before adding random ideas to that page. While we do not guarantee that the ideas listed there are necessarily at the level of winning a grant, we don't want to mislead the students. And also have in mind that the coding period of the project is only three months long (it was two months last year), and the coder is a mortal student that is probably not involved in Free Software development yet, let alone GNOME. So don't list Write Topaz as one of the ideas for example. Your SoC administrators, Behdad Esfahbod Vincent Untz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2 infinity and beyond [was Re: Tango and 2.16]
On Tue, 18 Apr 2006, Alan Horkan wrote: I return to my point about Gnome being quite different from what it was and all the change that have happened. A developer (an Independant Software Vendor (ISV) for example) could create an acceptable gnome 2.x application but using older APIs that are supported but not exactly the ideally recommended choices. Gnome 3.0 could be taken as an oportunity to clarify best practice and appeal to ISVs which has been previously mentioned as something people were interested in. Gnome 3.0 could be taken as a way to celebrate all the progress and encourage people to take another look. We can also enforce the best practices by leaving the deprecated interfaces *behind*. For example, currently we have the library gtk+-2.0. When gtk+ goes 3.x, we will rename the base library to gtk+-3.0, and leave all the deprecated stuff in a dummy gtk+-2.0 which itself will depend on gtk+-3.0, pulling all the non-deprecated stuff in. The effect is that applications written for gtk+-2.0 will continue to work and compile still, but those targeting gtk+-3.0 do not see the deprecated interfaces. A bit hackish, but I thought I would say. --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono bindings a blessed dependency? [Was: Tomboy in 2.16]
On Fri, 21 Apr 2006, Jamie McCracken wrote: Definitely not - that is unmanageable and unfair. If something is optional it means there are alternatives and one alternative should not block another (as then an inferior alternative could block a vastly superior alternative getting into the desktop as would be the case with beagle and Tracker) It's also unacceptable to ask everybody not to add beagle support simply because you and only you think Tracker is a vastly superior solution. This claim was never proved, nor Tracker is integrated in any core GNOME application that I know of. And if you allow all alternatives in you end up with a mess! --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please review po/LINGUAS patches so that people can build Gnome from CVS
On Fri, 28 Apr 2006, Rodney Dawes wrote: On Fri, 2006-04-28 at 16:58 -0400, Behdad Esfahbod wrote: On Fri, 28 Apr 2006, Rodney Dawes wrote: The new intltool just does an AC_SUBST(ALL_LINGUAS), which may or may not cause sed to break, depending on whether there are any newlines in ALL_LINGUAS. And that's regression AFAIU. It's rejecting input that was accepted before. You're welcome to file a bug against autotools. But quite frankly, sed has never accepted that input. This is not an intltool-specific issue, and I will not add code in intltool to work around one symptom, when the problem can occur in any AC_SUBST() call. I've explained the issue in bugzilla and pasted a script there as well, which shows the issue outside the scope of autotools. If you want something to parse the variables and strip out newlines, it's going to have to be done at the right level, in autotools. Is there an unwritten invariant that every variable defined in a configure.in file should survive AC_SUBST? I don't know why you keep blaming autotools. As a user I don't care what autotools does or doesn't. What I care is that the new version of intltool breaks my app. What you are saying is like we change g_unichar_isalpha in glib to call libc's isalpha and when people complain that it doesn't work as expected on some systems, we point them to libc... -- dobey --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please review po/LINGUAS patches so that people can build Gnome from CVS
On Fri, 28 Apr 2006, Rodney Dawes wrote: The new intltool just does an AC_SUBST(ALL_LINGUAS), which may or may not cause sed to break, depending on whether there are any newlines in ALL_LINGUAS. And that's regression AFAIU. It's rejecting input that was accepted before. -- dobey --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: po/LINGUAS fallout
On Sun, 14 May 2006, Bastien Nocera wrote: On Sun, 2006-05-14 at 16:17 -0400, Joe Marcus Clarke wrote: Since the move to po/LINGUAS, many GNOME 2.15 distfiles do not install translation files. Some don't even include the files in the dist tarball. The problem seems to stem from use of intltool-0.34.2 instead of 0.34.90. The three most recent offenders are totem-1.5.0, sound-juicer-2.15.2, and gnome-terminal-2.15.0. Is there anything that can be done to automatically check these distfiles, and send email to the maintainers? I'll blame intltool. I have this line in my configure.in: IT_PROG_INTLTOOL([0.34.90]) And I have this version of intltool installed: intltool-0.34.1-1.1 I guess its auto-fu macros suck. The intltool.m4 shipped with those versions of intltool only checks the two first components of the version number :(. This has already been fixed in HEAD. --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fixing bug #330868 in a smart way
On Mon, 2006-06-19 at 12:31 -0400, Christian Rose wrote: On 6/19/06, Paolo Maggi [EMAIL PROTECTED] wrote: I was giving a look to bug #330868 (Adding License button and dialog to About dialog). It seems to me we are duplicating the same long strings (mostly the GPL license) in most applications marking them for translation in order to add a License button to the about dialog. What about storing the most important open source licenses in a unique repository in order to minimize string duplication and translators work? I'm thinking to a special package like the one containing all the languages name (the iso_639 module). I would prefer if such functionality could be added to GTK+, at least for the short License declarations (like This program is free software; you can redistribute it and/or modify it under the terms...), for the following reasons: I replied to this thread, but seems like it didn't make it through the list. I've been working on exactly what you suggest in this bug: http://bugzilla.gnome.org/show_bug.cgi?id=336225 A couple of technical questions remain open, but you get the idea. -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: FreeType upgrade = apps linked against libttf.so need to be rebuilt
On Mon, 2006-07-10 at 12:48 -0400, Joseph E. Sacco, Ph.D. wrote: OK... Which leads us back to my original comment that apps that are linked against libttf.so need to be rebuilt. Still no. Even rpms built using it don't need to be rebuilt, as rpms depend on /usr/lib/libtts.so.*, not the freetype package. So, as soon as the freetype1 is available in the extras, everything will start working again. -Joseph = On Mon, 2006-07-10 at 12:34 -0400, Matthias Clasen wrote: On 7/10/06, Joseph E. Sacco, Ph.D. [EMAIL PROTECTED] wrote: FreeType-2.1.x contains libttf.so as well as libfreetype.so. See Fedora 4 5. In version 2.2.x, the true type font stuff has been incorporated into libfreetype and libttf.so has been eliminated. Thats entirely a fedora packaging issue. Freetype 1 was subsumed in the freetype package. -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: FreeType upgrade = apps linked against libttf.so need to be rebuilt
On Mon, 2006-07-10 at 12:07 -0400, Joseph E. Sacco, Ph.D. wrote: FreeType-2.1.x contains libttf.so as well as libfreetype.so. See Fedora 4 5. In version 2.2.x, the true type font stuff has been incorporated into libfreetype and libttf.so has been eliminated. No, you are wrong. The FreeType *Fedora package* was shipping both FreeType 1 and FreeType 2, so it included libttf.so. When updating it to FreeType 2.2.1, I removed the FreeType 1 stuff. That hit Rawhide this weekend. I'm going to package freetype1 for extras. To summarize, this has nothing to do with FreeType proper, or GNOME. Just a Fedora packaging issue. behdad -Joseph === On Mon, 2006-07-10 at 23:35 +0800, James Henstridge wrote: On 10/07/06, Joseph E. Sacco, Ph.D. [EMAIL PROTECTED] wrote: FreeType has been upgraded from 2.1.x = 2.2.x. Freetype-2.2.x does *not* contain libttf.so. Applications that were linked against libttf.so need to be rebuilt. Unless I'm mistaken, isn't libttf.so the Freetype 1.x library? It hasn't been present in any freetype-2.x release and is not compatible with the freetype-2.x series anyway (so it isn't just a case of needing to rebuild applications). James. -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to make sure your applications still works with Bug-Buddy 2.16.0
On Sun, 2006-08-13 at 20:55 +0200, Fernando Herrera wrote: On 8/13/06, Behdad Esfahbod [EMAIL PROTECTED] wrote: Another thing that may be very easy to get in Bug-Buddy, yet is very helpful to developers is the output form pmap on the crashed process. Tells a fortune in one list. Do you think you can do that? Yes, is it quite easy, I was planning to include that when no gdb nor debug info is present: - mem map of the application - linked libraries md5sum - symbolic stack trace so we could populate this backtrace on server-side (the famous debug server project). However, if you find useful the mem map with current reports, I can add it. Yes, I find that information very useful even with a stacktrace. That shows the .so version of all the libraries linked in, which with a bit or work can be converted to release version numbers. Thanks in advance. Salu2 -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to make sure your applications still works with Bug-Buddy 2.16.0
On Sun, 2006-08-13 at 22:27 +0200, Fernando Herrera wrote: Replying to my-self, this time adding d-d-l :) I did a try with bug-buddy adding the /proc/self/maps contents: http://bugzilla.gnome.org/show_bug.cgi?id=351197 Those contents are really huge for a GNOME applications linked to our little stack of libraries. Wow, that's really long. Maybe you can make it do it as an attachment? That needs more work though. Is there a way to make it not wrap the lines? Some kind of pre element that bugzilla supports? I know that pmap output is smaller and prettier, but is it installed on all GNOME supported platforms? On Linux systems pmap should be always available. On SunOS pmap is available and useful too, but /proc/self/map (map, not maps) is available but apparently has some kind of binary format. Not sure about any other systems. behdad Salu2 On 8/13/06, Fernando Herrera [EMAIL PROTECTED] wrote: On 8/13/06, Behdad Esfahbod [EMAIL PROTECTED] wrote: Another thing that may be very easy to get in Bug-Buddy, yet is very helpful to developers is the output form pmap on the crashed process. Tells a fortune in one list. Do you think you can do that? Yes, is it quite easy, I was planning to include that when no gdb nor debug info is present: - mem map of the application - linked libraries md5sum - symbolic stack trace so we could populate this backtrace on server-side (the famous debug server project). However, if you find useful the mem map with current reports, I can add it. Salu2 -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to make sure your applications still works with Bug-Buddy 2.16.0
On Sun, 2006-08-13 at 16:53 -0400, Olav Vitters wrote: On Sun, Aug 13, 2006 at 02:06:10PM -0400, Behdad Esfahbod wrote: On Sat, 2006-08-12 at 18:44 -0400, Olav Vitters wrote: Having the X-GNOME-Bugzilla-Version is optional, but highly recommended. The server will automatically change versions like 2.15.90 to 2.15.x, so this doesn't have to be changed in the .desktop/.server file. I recommend keeping the real version in the desktop file as I might put this version in a comment. Please do that. In vte I experience the need every single day. I committed a crashers that went into GNOME 2.15.90, and fixed it when the first report came in. But now I hardly can tell if all the reports coming in are from the same version or if from a crasher in the newer version... Seems I already have the warning messages enabled for I forgot to actually append them to the comment. It will not help vte though, it is a lib (or will you make an educated guess based upon gnome-terminal version?). There is also another problem.. I run gnome-terminal for so long that .desktop file info is likely not the one I'm really running (but this can be seen from the started timestamp + cpu usage, etc). I see... maps/pmap output helps with most of these. Thanks again -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUnique [Was: gnome-utils branched for GNOME 2.16]
On Fri, 2006-09-22 at 05:49 -0400, Richard Hughes wrote: So I propose, tell maintainers to link against linguniqueapp (as it's more sane that what we have already[1]) and then depreciate it in a couple of years time when we've decided where it belongs. This means maintainers like me get single-instance support *now*. It also means that even with deprecation, it will be used and shipped around for years to come, just because someone doesn't like depending on Gtk+ 2.12, or have not converted, or whatever. Copy/pasting is a superior solution if we know the code is going to be merged soonish. -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.17.1 release of gnome-session
On Mon, 2006-10-16 at 16:46 -0400, Vincent Untz wrote: Hi, For some obscure reasons, I'm unable to use cvs. I wanted to branch gnome-session for 2.16 and roll a 2.17.1 tarball... Can somebody apply the fix in bug 362541 [1] and do all the hard work? I promise that I'm not being lazy :-) I'm doing. behdad Thanks, Vincent [1] http://bugzilla.gnome.org/show_bug.cgi?id=362541 -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing GtkUnique 1.0 as a blessed external dependency
On Tue, 2006-11-14 at 07:43 -0500, Paolo Borelli wrote: This would avoid yet-another-mini-lib that distro have to ship and then keep around for a long time because any random third party project may have started to depend on it. +1. - One class - One library - 4kb of private memory per process using it - Two RPM (deb, etc) packages per distro maintained for 10 years Not really worth it for piece of code known to be merged next year. -- behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Moving spellcheckers into the Gtk+ stack
Hi, So, everybody wants to find a steak that's slightly red. Oops, I mean, they all want spell-checking for free in all their text widgets. Spell-checking is as natural a feature as i18n text rendering, or input methods. Individual apps shouldn't have to bother. If editors or word processors want to add more sophisticated features, like a spell-check dialog, whatever, fine. Here is a proposal: - Move Enchant into glib as a new module called gspell. Enchant is a small client-side library that loads modules that interface with spell-checking backends, like aspell, ispell, MySpell, etc. It's written by Dom, uses glib, and KDE recently forked it and called it kspell2 or something. So, I don't think it has a lot more opportunities as a fd.o project, and all its users are using the GNOME stack already. Other projects (OO.o, Mozilla), prefer to interface directly with backends or reinvent their own wrapper. So, by moving Enchant to glib, we bring spell-checking to the entire GNOME stack for free. This is quite in par with the gregex and gvfs efforts going on. Dom is pretty positive about this. - Port automatic spell-checking from libsexy and GtkSpell to Gtk+ editable text widgets. - Add properties and Gtk settings for turning on/off spell-checking globally, setting default languages, etc. Possibly adding context menu entries too. - Develop a simple tool for control-center to adjust above settings. - If popular enough, move some spell-checking dialogs from Gedit or other implementations to Gtk+. Comments? -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ 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
Thanks to everyone who responded! Paolo already filed this as: http://bugzilla.gnome.org/show_bug.cgi?id=383706 As for the implementation, Marco (of gregex fame) is already working on the glib side, Dom will be helping on the Enchant side, others are helping on the design, and I'll be working on any locale-specific functionality missing in glib and pango. Cheers, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME git repositories?
On Thu, 2006-12-28 at 20:33 -0500, Alberto Ruiz wrote: In fact, now, a lot of people from the windows world can just use a simple tool like TortoiseSVN or Subclipse (SVN for eclipse) to create patches or download the trunk versions without using the commandline. Right. But how many of our developers do their work on Windows (and how many of them without cygwin)? Translators are different. But we can come up with alternate means of submitting translations rather easily. git for example don't even has an usable version on the windows commandline (the cygwin version is really slow). I really doubt that it can be slower than CVS. Not that I'm arguing against the SVN transition. Just pointing out that we don't have to care about all platforms on earth. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: tracker
On Mon, 2007-01-08 at 19:27 +, Jamie McCracken wrote: tracker is now in fedora and I have a Debian Developer putting it into debain and ubuntu so if distro inclusion is a good guide (which you asserted to last time) then why should it not be suitable for inclusion in gnome at this point? It's different. Almost any piece of Free Software can make it into Fedora, Ubuntu, and Debian. That's because all those projects have formal, documented means to include software without much technical review or comparisons. They all welcome multiple projects providing the same functionality, etc etc. In other words, being in Fedora Extras or Ubuntu Universe means not much. What *is* a very high point in a project's profile is whether any distros ship it as part of their default installation and used as a distro feature. NetworkManager or gnome-power-manager are for example shipped by Fedora as such. They are part of the default install (ok, NetworkManager is not enabled by default, but g-p-m is), and advertised as part of the distro in Release Notes, etc. Tracker isn't. In contrast, Beagle kinda is, in Fedora Core 6. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RTL support in Gnome
On Tue, 2007-01-16 at 11:39 +0200, Yair Hershkovitz wrote: Hi, I've been working lately on some bugs with RTL (right to left languages) support in Gnome. Thanks Yair for the work. I have few suggestions to help improve RTL support in Gnome: 1) I want to start a mailing list for RTL support discussions ( [EMAIL PROTECTED] ???) I don't think it's quite necessary. One reason is that only people directly interested in RTL support will be there, while most of the time one wants comment from main developers of modules or other interested hackers. You don't get it there. 2) I think we should add an rtl keyword to bugzilla, for tracking RTL issues. We've been using a tracker bug for everything blocking perfect Persian support in GNOME for some while, and it's been quite handy. It's aliased 'persian': http://bugzilla.gnome.org/show_bug.cgi?id=persian I suggest you create an aliased tracker too. When you want to add this keyword to a bug, you just add persian to the bugs it blocks... However, I think you may just want to follow the 'persian' bug. Almost everything related to RTL support is listed there, and the Persian-specific stuff is not that much. Tnx, Yair. Regards, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RTL support in Gnome
On Wed, 2007-01-17 at 08:41 +, Kjartan Maraas wrote: Isn't this really just a specialized group within the i18n team? Can't it be solved there without creating yet another list, keyword in bugzilla etc etc? Right. But gnome-i18n has turned into being a translation-only kind of list, and gtk-i18n-list is too lowlevel... -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RTL support in Gnome
On Wed, 2007-01-17 at 13:26 -0600, Shaun McCance wrote: Unfortunately, gnome-i18n has already become the de facto list for l10n, so naming a new i18n list would be tricky. gnome-i18n-devel? -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RTL support in Gnome
On Wed, 2007-01-17 at 21:15 -0500, Owen Taylor wrote: And how would this differ significantly in practice from gtk-i18n-list? - Owen People can discuss issues in Evolution, gnome-panel, Nautilus, GIMP, other apps... So far I've only seen such stuff on bugzilla. Or is that ok on gtk-devel-list? -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cairo-1.2.6 required
On Tue, 2007-01-23 at 10:56 -0700, Elijah Newren wrote: Sounds good to me, but there is (at least) one issue. Do pycairo-1.2.6 and cairomm-1.2.4 work with cairo-1.3.x? I don't see any pycairo-1.3.x or cairomm-1.3.x at either http://cairographics.org/releases/ or http://cairographics.org/snapshots/, so I'm worried about breaking gtkmm and pygtk. cairo-java and the perl equivalent may have similar issues... Does anyone have any more details on this? My knowledge of bindings is at best zero, but I don't see any reason why they shouldn't work with 1.3.x. Cairo has the same strong API/ABI guarantees that GNOME Platform modules have. That said, we are thinking of possibly changing return type of some functions from void to int or cairo_status_t. AFAWK that will not break API/ABI on any interesting platform. Though, bindings need to be updated to support the new information being returned (most probably throwing an exception if the returned status is not SUCCESS). -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bumping cairo requirement for 2.18 from 1.3.12 to 1.3.14
Thought this is automatic. Anyway, please bump. 1.3.14 has been out for a couple of weeks now... 1.4.0 will be out really soon now. Blockers are being fixed at a rate of 2 or 3 a day, and only 4 or 5 are remaining. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bumping cairo requirement for 2.18 from 1.3.12 to 1.3.14
On Wed, 2007-02-28 at 14:38 -0700, Elijah Newren wrote: This page can be updated at any time by the release-team. Others not in the release team can update the micro version number of modules if (a) they introduce no other new (or newer) external dependencies and (b) the module has committed to API/ABI stability guidelines equivalent to those of our Developer or Bindings platforms, and Developer or Bindings platforms is that what we call them? I had Platform or Binding sets in mind. (c) the person who does the updates ensures that jhbuild and GARNOME are either updated or at least notified of the need to update. Please update only the recommended version instead of the minimum version unless an official GNOME module will require the newer version to build. Updating jhbuild has been easy enough, but I have no idea about GARNOME. Can't the people responsible for those two just subscribe to the wiki and get notified automatically? -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cairo 1.4.0 now available
On Tue, 2007-03-06 at 11:37 -0700, Elijah Newren wrote: On 3/6/07, Carl Worth [EMAIL PROTECTED] wrote: GNOME should be able to update its dependency for cairo from cairo 1.3.16 to cairo 1.4.0, (1.3.16 was a release candidate for 1.4.0---there have not been any API changes between the two versions). Awesome, great work. A few points will be deducted from your score for being just over a month behind your original schedule and running so close to the GNOME 2.18.0 deadline, thus making me worry that you might not be getting a release out before GNOME 2.18 was due. However, the speed and coolness of the new release will make up for it. ;-) Yeah, sorry about that. Cairo's release management is still young and learning. We are going to work on a more timely release management plan. In this case, a few issues popped up that delayed the release. I'm going to blog them extensively. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
On Tue, 2007-03-06 at 22:31 +0100, Vincent Untz wrote: Hi, Do you all remember that we list our contributors in About GNOME? The list of GNOME contributors is probably outdated: many people contributed a lot of stuff in recent years and are not there. It's a shame to not thank them, so we have to fix this! Haha, neat meme you started. Want to get wild? Post it on planet! (please don't) It would be really great if all maintainers could take 10 minutes and check that all of their main contributors are listed in there. To do so, open this URL and look for the name of your contributors: http://svn.gnome.org/viewcvs/gnome-desktop/trunk/gnome-about/contributors.h?view=markup If there are some missing contributors, send me a private reply with the names of those contributors. I'll make sure to add them before 2.18.0. It'd be great to have the non-ascii characters in hexa, so for example: Mariano Su\xc3\xa1rez-Alvarez instead of Mariano Suárez-Alvarez. Any reason for hex encoding? That's ugly, and we should handle UTF-8 just fine. I'll ask for a hard code freeze break to get this in (yes, this is code ;-)). And maybe it's time to make it data instead of code? Thanks, Vincent On Tue, 2007-03-06 at 17:01 -0500, Luis Villa wrote: And I'll buy a $BEVERAGE_OF_CHOICE for anyone who makes the dang thing sexy and less slow in 2.19.0. This is 2007; if our about box doesn't optionally utilize GL, surely we've failed. :) I suggest we give MacSlow (CC'ed) till the end of the week to come up with something uber sexy. I'll give it a lame try if he doesn't. Bonus points for making it take less than, ya know, about a million hours to go through the whole list :) Yeah, one-by-one alphabetical order doesn't sound very friendly. /me remembers the old Win95 contributors easter egg... [And a full case of $BEVERAGE_OF_CHOICE to whoever goes through the list of top bugsquad contributors and makes sure they are all in there for 2.18.0. Unsung heroes and all that.] Others not to forget: - Quim Gil - Carl Worth - The new vte uber-hacker, Chris Wilson Luis behdad, who is not in the list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
On Wed, 2007-03-07 at 00:01 +0100, Vincent Untz wrote: Le mardi 06 mars 2007, à 17:31, Behdad Esfahbod a écrit : On Tue, 2007-03-06 at 22:31 +0100, Vincent Untz wrote: It'd be great to have the non-ascii characters in hexa, so for example: Mariano Su\xc3\xa1rez-Alvarez instead of Mariano Suárez-Alvarez. Any reason for hex encoding? That's ugly, and we should handle UTF-8 just fine. Because it's a C string, and we're not using UTF-8 in our source code, I believe. Old policy, or something like this. We do in cairo, and it's a lot of fun :). I'll ask for a hard code freeze break to get this in (yes, this is code ;-)). And maybe it's time to make it data instead of code? Bastien suggested this, and wanted to open a bug. It's not too late if you want to open the bug before he does! I was too late by 3 bug numbers (or two mins): http://bugzilla.gnome.org/show_bug.cgi?id=415519 at least I dupped it myself, so got a point for closing a bug, if not for opening one :-D. Vincent -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
On Wed, 2007-03-07 at 12:58 +, Iain * wrote: Seeing as this is the only real reason for having this (I mean, who else has ever run the about program and looked at all the names in it) I'm not sure what the purpose of this message of you was, but anyway, I've done that a few times. Mostly when I was not maintaining anything in GNOME. So yes, there are people who do that (and yes, they are probably all geeks). So what are we going to do? Add 1000 new names? Where to put the cut? A simpler solution is to remove it. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
On Wed, 2007-03-07 at 12:50 +, Thomas Wood wrote: I thought this was GNOME we're talking about. We do professional software, not pointless eye-candy, right? I'm not saying professional looking software has to be boring, but there seems to be a tendency to go over the top with GL effects on the desktop at the moment. Most professional software doesn't have a list of contributors. Are you suggesting that we remove it? I'm fine with that, but if we are going to keep it, we may as well have some fun and make it look nice. It's a useless piece of dialog otherwise. We may as well use it to show off some cool things you can do with GNOME technology. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
On Thu, 2007-03-08 at 08:39 -0300, Germán Poó Caamaño wrote: On Thu, 2007-03-08 at 01:06 -0500, Behdad Esfahbod wrote: On Wed, 2007-03-07 at 12:58 +, Iain * wrote: Seeing as this is the only real reason for having this (I mean, who else has ever run the about program and looked at all the names in it) I'm not sure what the purpose of this message of you was, but anyway, I've done that a few times. Mostly when I was not maintaining anything in GNOME. So yes, there are people who do that (and yes, they are probably all geeks). So what are we going to do? Add 1000 new names? Where to put the cut? A simpler solution is to remove it. Another one is put it them only members of GNOME Foundation. It supposed to be integrated by active members in the last two years (4 releases). Foundation members makes a lot of sense to me. I'm all for it. Keep the old list, don't remove them. Just from now on, add new Foundation members. Easy and deterministic. If anyone cares to be there, they should also care about becoming a member. Also, as a geek thing, it could encourage(?) to contributors to being part of the foundation. Regards, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A New GNOME Order
On Fri, 2007-03-09 at 02:28 +0100, Esben Stien wrote: It would be very nice with a policy of separating the core and UI throughout GNOME. This does not only mean applications using libraries; this means using daemons as the core of every application. Couldn't resist mentioning: http://www.joelonsoftware.com/articles/fog18.html Lets not forget that what users ultimately care about is whether they can download what they want, listen to what they want, and generally do what they want. What they don't care is how many processes are needed to download a file. And don't forget that you can spend 10 years architecturing and not have a final design even. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: add libcolorblind as an external dependencie
On Sat, 2007-04-14 at 21:58 -0300, Carlos Eduardo Rodrigues Diógenes wrote: Sometime ago, I was talking with Daniel Ruoso about this and he give a good suggestion, that was to develop an applet where a user can select only a filter and this applet will start the magnifier with 1x, so it will behave to the user as a colorblind filter only, not a magnifier. Also, some colorblind users talked that they don't want the filter running all the time, so a keystroke must be defined to enable/disable it when the user think that he/she is not distinguishing colors. I will try to provide an implementation for this until the end of the mounth and I also created a bugzilla reference to track this: http://bugzilla.gnome.org/show_bug.cgi?id=422347 Does it make more sense to have this functionality in a compositing manager? You probably can hack up a compiz/beryl plugin in an afternoon. Don't forget metacity though :). -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Information needed: Modules in official GNOME releases but not on the official release cycle
On Wed, 2007-04-18 at 11:42 -0600, Elijah Newren wrote: Hi all, So I was trying to improve our release documentation by coming up with a list of modules in official GNOME release sets that do not follow the GNOME release cycle, such as gtk+. We have discouraged adding such modules as time has gone on, but there are still lots of existing modules like this from 2.0 and early 2.x days. Problem is, I wasn't around for all the discussions way back then, and I really don't know the state of all modules (nor even all the reasons for this splitting). It'd be really helpful if people could read over my initial draft and provide corrections and clarifications: http://live.gnome.org/ReleasePlanning/SeparateReleaseCycleModules Pango totally follows GNOME's release cycle. Dasher does too as far as I remember. Thanks, Elijah -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: .so versions
On Thu, 2007-05-17 at 18:26 +0100, Sergey Udaltsov wrote: Could anyone please comment on the question of the shared library versions: http://www.advogato.org/person/svu/diary.html?start=95 Most modules I know use libtool versioning. yes. Here is the bits from Pango for example: dnl The triplet m4_define([pango_version_major], [1]) m4_define([pango_version_minor], [17]) m4_define([pango_version_micro], [0]) m4_define([pango_version], [pango_version_major.pango_version_minor.pango_version_micro]) dnl The X.Y in -lpango-X.Y line. This is expected to stay 1.0 until Pango 2. m4_define([pango_api_version], [1.0]) dnl Number of releases since we've added interfaces m4_define([pango_interface_age], [0]) dnl Number of releases since we've broken binary compatibility. m4_define([pango_binary_age], [m4_eval(100 * pango_version_minor + pango_version_micro)]) dnl Module API version. This should be stepped up when a change causes dnl older modules to not work with new pango. m4_define([pango_module_version], [1.6.0]) ... dnl libtool versioning m4_define([lt_current], [m4_eval(100 * pango_version_minor + pango_version_micro - pango_interface_age)]) m4_define([lt_revision], [pango_interface_age]) m4_define([lt_age], [m4_eval(pango_binary_age - pango_interface_age)]) VERSION_INFO=lt_current():lt_revision():lt_age() ... LIBRARY_LIBTOOL_OPTIONS=-version-info $VERSION_INFO So other than the module version we also keep track of an interface_age. Conceptually we can get rid of it as it should stay at zero for stable releases and is only useful during development cycles. Other modules that may break binary compatibility from time to time do not use an automated binary_age. See gucharmap and vte for example. In those cases one has to update the libtool version triplets manually. Thanks, Sergey -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rise of the Plugins
On Thu, 2007-05-17 at 12:46 -0500, Shaun McCance wrote: On Thu, 2007-05-17 at 19:41 +0200, Andy Wingo wrote: Hi, On Thu, 2007-05-17 at 18:26 +0200, Vincent Untz wrote: Plugin vs extension? [...] My €0.02: I think that people are getting used to the Extension term, and it sounds less geeky. Extension has the advantage that there's only one way to spell it (as opposed to plugin vs plug-in). A minor point, Not that I'm disagreeing, but it's worth pointing out that the GNOME Documentation Style Guide (which doubles as terminology guidelines for the entire desktop) has had plugin as the recommended spelling for quite some time. How would esr's aunt Tilly take that? M-W redirects to plug in: Main Entry: plug in Function: verb intransitive verb : to establish an electric circuit by inserting a plug transitive verb : to attach or connect to an electric receptacle (as an outlet) As opposed to plug-in: Main Entry: plug-in Pronunciation: 'plg-in Function: adjective : designed to be connected to an electric circuit by plugging in a plug-in toy a plug-in circuit board And: Main Entry: ex·ten·sion Pronunciation: ik-'sten(t)-shn Function: noun Etymology: Middle English, from Late Latin extension-, extensio, from Latin extendere 1 a : the action of extending : state of being extended b : an enlargement in scope or operation tools are extensions of human hands And btw the GNOME Documentation Style Guide link on http://developer.gnome.org/projects/gdp/styleguide.html seems to be broken. -- Shaun -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Should GNOME Get a Global Application Menubar?
On Fri, 2007-05-18 at 13:28 +0200, Thom Holwerda wrote: Note the emphasis on option, and turned off by default. The poll results show that 80% of the OSNews readers who voted (1154 votes cast as of writing) would like to see this included in GNOME. Obviously, the statistic validity of such a poll is limited, since the readers of OSNews do not qualify as a representative group of GNOME users. However, that does not negate the fact that this result does give a rough indication of how wanted such a patch actually is. The poll doesn't have a I don't care option, so most people tend to vote yes, doesn't hurt. Not really a measure for how wanted a patch is, really. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Roadmap Released
Somebody's gonna get drunk in a few weeks! More pointy hairy: Thanks Lucas et al! behdad On Fri, 2007-05-25 at 22:48 +0300, Lucas Rocha wrote: Hi everyone, The GNOME Roadmap for 2.20 (and partially for 2.22 and future 2.x releases) is available at: http://live.gnome.org/RoadMap The GNOME Roadmap is a big-picture view of functionality we expect GNOME to include in short-term and long-term future. The roadmap is based on feedback from current GNOME developers and other community members. We hope this roadmap increases the awereness about the future steps of the project inside and outside the community and helps us to look forward and plan where we want to go. For a quick overview of our roadmap process, please see: http://live.gnome.org/RoadMap/Process Let's make GNOME rock even more! Thanks, --lucasr -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: online desktop update
On Tue, 2007-06-05 at 15:31 -0400, Havoc Pennington wrote: Sven Neumann wrote: Hi, On Tue, 2007-06-05 at 14:30 -0400, Havoc Pennington wrote: We are piling a few more people onto this from the Red Hat end, and I created a Google Group for the project: http://groups.google.com/group/online-desktop Is there a particular reason for discussing this very interesting topic in a Google Group instead of creating a mailing-list for it at gnome.org? What's the next thing, Yahoo Groups? Google Groups is nicer in various ways, such as ability to participate without getting email, ability to post files, people in the group can have a profile, etc. It is a group system, not a mailing list system. But if you want to just get email from it you can, as far as I know. Yeah, if you try hard enough... And don't think about teaching it that your gmail and non-gmail addresses belong to the same person... Havoc -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME startup time: gconf tree merging
On Fri, 2007-06-15 at 14:15 +0200, Denis Washington wrote: Hello, While informing myself about ways to reduce GNOME's startup time, I found a site named Analyzing and Improving GNOME Startup Time on gnome.org [1]. Among other things, it talks about the possibility of merging together the several gconf xml files to bigger trees, which seems to dramatically reduce startup time. As stated in the text, a patch for this was commited, but quickly reverted in 2004 because of legacy support issues [2]. My question: is the big amount of small XML files still as much of a problem in the current gconf version as in 2004? And if yes, are the reasons for which it was rejected still legitimate today? The problems arised with GNOME versions 2.6 which want to use the same database; we're at version 2.18 now I think if it still brings significant startup time reductions, we should seriously consider to get this patch into GNOME 2.20. I have a vague memory that something like this committed, or floating around, a few months ago. Search the archives. behdad Regards, Denis [1] http://www.gnome.org/~lcolitti/gnome-startup/analysis/ [2] http://bugzilla.gnome.org/show_bug.cgi?id=138498 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versions of External Dependencies in jhbuild
On Sun, 2007-06-17 at 16:47 -0600, Elijah Newren wrote: On 6/16/07, Jaap Haitsma [EMAIL PROTECTED] wrote: Hi, Overhere [1] are the versions of external dependencies listed. I'm guessing that the minimum version should be the one present in jhbuild. This way it can be checked if all the software builds with the minimum version. But for instance cairo has a minimum version of 1.2.2 at [1] but in jhbuild version 1.4.6 is build. (Which is also not the recommended version at [1]) We're kind of stuck in a funny middle ground. We want to be able to test newer (e.g. cairo) releases to make sure they're solid when adopted by the distros. However, we don't want to make GNOME unbuildable with older releases if there's no reason to, so it makes sense to lag the minimum build requirements. As you point out, if we don't test with the minimum build requirements then it becomes difficult to tell if they are really the minimum. So it's a tough nut to crack, and I'm really not sure how to resolve this. For now, though, I would prefer to see us testing the recommended versions of external dependencies since those are the ones distros are likely to adopt. Have a build bot that builds with minimum requirements, another with recommended. Need to automate version extraction though or it will fall outdated too. behdad Just my $0.02. Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discussion for a more robust panel layout
On Tue, 2007-03-20 at 16:58 +0100, Manu Cornet wrote: Recently the problem of changes of resolutions has been raised [1] on the usability list. I would like to start a discussion about how to manage the effect of resolution changes on the panel layout better than what we do today. This implies another way of storing the panel layout. Just store all locations as percentage of screen width/height. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discussion for a more robust panel layout
On Sun, 2007-07-08 at 17:22 +0300, Kalle Vahlman wrote: 2007/7/8, Behdad Esfahbod [EMAIL PROTECTED]: On Tue, 2007-03-20 at 16:58 +0100, Manu Cornet wrote: Recently the problem of changes of resolutions has been raised [1] on the usability list. I would like to start a discussion about how to manage the effect of resolution changes on the panel layout better than what we do today. This implies another way of storing the panel layout. Just store all locations as percentage of screen width/height. That would mean creating gaps between applets when growing the width, unless some special keep me next to that guy-states exist. I'd rather see some gravity settings (always try to go towards the left edge), since that's where you'll want to have the applets anyway, on the edges. In that case just keep the gaps in a percentage of extra space available. You doesn't even have to be percentage. For each gap keep a number which is its stretchiness. Then allocate extra space to gaps in proportion to their stretchiness. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating the icon cache (GNOME Goals)
On Mon, 2007-08-06 at 16:44 -0500, Federico Mena Quintero wrote: Hi, I just saw this http://live.gnome.org/GnomeGoals/AppIcon about making apps update the GTK+ icon cache during make install. This would be fine in a tarball-only world, but I wonder if distros will just end up patching out that part of Makefiles, and calling gtk-update-icon-cache on their own. Hi Federico, The Makefile.am snippet only runs gtk-update-icon-cache if DESTDIR is empty. The idea is that distros make install to a temporary DESTDIR and the actual install happens later. In this case, gtk-update-icon-cache is not called in make install and it's up to the packager to call it at the right time. This trick is common practice, used at least in fontconfig and pango too. For example, in openSUSE we update the icon cache separately from package installation, with the idea that the cache will only be updated once even if many packages are installed. (The really right way may be to use an RPM %posttrans - no idea if that works.) So, do we really need this in tarballs? I'd say yes. Federico Cheers, -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MAINTAINERS in svn -- have it or don't get any SVN account approved
On Wed, 2007-08-08 at 00:36 +0200, Olav Vitters wrote: Some Name E-mail: [EMAIL PROTECTED] Userid: svn-account-name Note that the userid is really important. Otherwise ensure that the E-mail address is the one your @svn.g.o alias forwards to. Can you make it understand [EMAIL PROTECTED] address please? -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MAINTAINERS in svn -- have it or don't get any SVN account approved
On Wed, 2007-08-08 at 11:11 -0400, Matthias Clasen wrote: Should be easy enough to make the script just grep for triples of lines following the pattern Some Name E-mail: foo Userid: bar and ignore all the rest. It's actually like that already. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Full screen GtkDrawingArea performance sucking - help me!
On Mon, 2007-08-27 at 03:49 +0100, Alex Jones wrote: Hi list In my quest to write an awesome backdrop rendering app, I have this test program that draws random colours to a GtkDrawingArea. For me, any size over about 300x300 at 60fps just causes insane lag in Xorg -- the renderings seem to queue up. If I run cairo clock maximised full screen, it literally LAGS by about 5 seconds. Telling it to close takes ages, as if the X connection is completely saturated. My own cairo clock which draws the second hand smoothly between intervals shows that it seems to run at less-than-real-time, but still smoothly. Eventually, the clock skips ahead by 10 seconds or so. FWIW I experienced the same slowness in full-screen mode at our (Carl and I) GUADEC talk. Profiling showed most of the time spent in xorg, as expected. I imagine massive pixmap migration happening... Carl may know more. behdad I have a 2.8 GHz Pentium 4 with 1 GB of RAM, nothing using my CPU and a Radeon 9800 Pro with the r200 drivers. What's going on? This is a total spanner-in-the-works for me. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Full screen GtkDrawingArea performance sucking - help me!
On Mon, 2007-08-27 at 20:58 +0100, Alex Jones wrote: The problem is that the expose handler gets called again before the XRender operations from the previous exposes have finished. Hence, XRender operations just queue up behind each other at a certain level of utilisation. It's the queueing that manifests itself as lag. As a workaround, you can block the expose handler until the drawing is actually done, but that's not very nice if you have other things to service in the same thread like audio etc. Isn't that just an after-effect of the drawing being too slow? Sure you can gdk_display_sync() to not accumulate updates on the server. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Python 3.0 plans
On Wed, 2007-08-29 at 13:52 -0400, Behdad Esfahbod wrote: - Do things more Pythonesque. Looking at Pango bindings, for example replace all to_string() methods with __str__. Same for compare(), equal(), etc. Or should it be in addition? Other example I once really wanted was generator iterators on PangoLayoutIter such as lines(), clusters(), ... so I can do: i = layout.get_iter() for line in i.lines(): print line But then the iterator object becomes redundant, so maybe add lines() on the layout itself: for line in layout.lines(): print line -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MAINTAINERS in svn -- have it or no commit for you
On Sun, 2007-09-02 at 21:39 -0600, Elijah Newren wrote: I'm with Jeff and Vincent on this; I'm worried about the adverse affect this could have on the release, given how close it is. Can we consider delaying it until after 2.20 is out? How hard would it be for someone to intersect all the modules in the GNOME release with the list of those missing a correct MAINTAINERS file and add the missing ones? Elijah -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MAINTAINERS in svn -- have it or no commit for you
On 9/3/07, Olav Vitters [EMAIL PROTECTED] wrote: New list of missing modules (again, by comparing with jhbuild list): gamin, libxml2, zenity, libsigc++2, libart_lgpl, libxslt Of these, only zenity has translations, righ? Lucas? Are all the others unmaintained? Looks so to me. libart_lgpl is Ok as everyone should be moving to cairo. Not sure about gamin. Is it fading out due to inotify too? Is libsigc++2 maintained by gtkmm maintainers? And what to do with the XML libraries. Is DV still maintaining them? -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintenance releases for 2.20
On Mon, 2007-09-10 at 22:35 +0300, Lucas Rocha wrote: - gucharmap I'll make my releases on Monday. Am away for the weekend. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Tue, 2007-09-11 at 11:41 -0400, Bryan Clark wrote: GNOME is not in need of a DSCM or any other kind of new SCM. For source control, SVN works fine, just like CVS worked fine. You probably have not used git-bisect before. After you use it once, all you can do is regret all the time you've spent manually bisecting using CVS/SVN. This even happened to me yesterday. Bug 474897: - Sat 16:54 UTC I report a regression against devhelp and leave it alone, hoping that someone picks it up. - Mon 17:33 UTC Richard Hult blames it on Gtk+ and bisects using his git-svn Gtk+ checkout and points to the commit causing the regressions. - Mon 18:10 UTC I have committed the fix to SVN. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 09:54 +1000, Jeff Waugh wrote: quote who=Adam Schreiber As a maintainer for a smaller project where there are only 2 regular contributors (who are both maintainers), I count myself in the Why would we need this for our project category?. Also because where Carl and I were hacking on slippy, our presentation tool, at GUADEC and there was no internet connection at the hotel and we were happily fetching from each other, with no central repo at all. You can do the same on a plane too... Pretty cool stuff, seriously. You can't know until you give it a try. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Wed, 2007-09-12 at 12:10 +0200, Josselin Mouette wrote: Le mardi 11 septembre 2007 à 22:37 +0200, Soeren Sandmann a écrit : This is true. There are issues with git, most importantly that it was written by someone for whom usability is not, um, a core competence, but is has a couple of killer features over CVS/SVN: * The abilty to commit offline You can already do it with svk or git-svn. Like a wise man once said: you could as well drill a hole into your knee and insert a screw to adjust the desired pain level more precisely. ;-) * Bisect, as Behdad says This is definitely a killer feature, but there is no design limitation preventing implementation of such a feature in subversion. A working svn-bisect script would definitely be a worthwhile contribution. Ya, you need to be sitting on top of the GNOME SVN server for it to work though. There are also a couple of non-killer improvements: * Performance: git is consistently fast; svn is slow. It should be noted this is only the case for git, not for other DSCMs. Furthermore, svk also noticeably improves performance on svn repositories. What's worse than a broken tool is using another tool to unbreak it. As several people already stated, most of git's improvements are already available to those who love git thanks to git-svn. It strikes me that we would actually lose svn's killer feature (simplicity) if the whole repository is migrated to git. No, git-svn only facilitates git-bisect. Almost no other benefit of git is readily available: you have to flatten your branch before pushing it to SVN. It doesn't fetch all branches. You can't freely push and pull branches with other developers. In short: it's very, very, fragile. It's easier to do something wrong than right. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Sun, 2007-09-16 at 00:13 +0200, Jaap Haitsma wrote: Hi Talking to Daniel Cheese Siegel we asked ourselves: Why do all GNOME projects have a ChangeLog file? Isn't it redundant when you just save a commit message. Because SVN sucks... I'm on a plane, I find a regression in Gtk+ that I believe is introduced recently. How do I find out? Of course you can autogenerate ChangeLog from CVS/SVN logs, and a few projects do that, but it's just easier to use GNOME ChangeLog-generator scripts and copy/paste as commit message. Attaching the script I use. Of course no project using git maintains ChangeLog. One reason I gave up using git-svn is that the script doesn't fully understand how to generate ChangeLog from a git repo. I tried to hack it in but it's far from done. If anyone wants to finish that... Jaap -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 gnome-changelog Description: Perl program ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Sun, 2007-09-16 at 01:10 +0200, Ali Sabil wrote: I am also afraid that we might be just becoming nothing more but geek fashion addicts trying to follow the latest RCS tendency without really building solid and constructive arguments ! I was going to be offended, but you warned :). Now that most probably means that you don't hack on the more crowded projects that much... Many Gtk+ developers for example could not have been as productive as they are right now if it wasn't for git-svn. And that's only a half-arsed solution. Yeah, I am not against DRCS at all, in fact I cannot stand using svn or any CRCS, what I was pointing out is that basically everyone is calling for using git while superior alternatives to git exists out there. I am not a user of Mercurial for example, but I think it is the DRCS out there that gives a very good balance between ease of use, speed and functionalities. Actually I use bzr daily, but I cannot claim that bzr is very fast (the upcomming 0.92 is supposed to be quite fast). I think that both bzr and mercurial give a better balance than git, which is indeed very fast on posix systems, but ad Ross said a while ago : Git is a good core of a yet to be written revision control system. I think that Git is to revision control system, what Autotools is to build systems. I am just afraid that everyone is calling for using Git, without even considering the existing and less hyped alternatives. And again don't get offended by what I say ;) I am just calling for a fair comparison of the tools, instead of a biased one :) Ok, lets be fair: most people who care about hacking on GNOME already know git, why should other options be selected? Seriously, kernel is using it, freedesktop.org is using it, and KDE is considering it. Git is one of those ones you need to learn at some point anyway. Bazaar on the other hand from what I see is a Ubuntu/Canonical focus and Mercurial's biggest deployment, yet to be finished, will be Mozilla. I've seen many Mozilla hackers regret that they are not moving to git. Was going to add these to the wiki page, feel free to do: - Keith Packard did a fairly extensive research of which DSCM system to use for xorg and other fd.o projects, from a storage robustness / performance point of view, and he wrote this excellent piece: http://keithp.com/blog/Repository_Formats_Matter.html Surprising to some, he comes to the same conclusion that Linus does about SVN. And here is Linus clarifying many aspects of git vs central repositories for KDE hackers: http://lwn.net/Articles/246381/ -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Sun, 2007-09-16 at 09:10 +0100, John Carr wrote: On Sat, 2007-09-15 at 18:26 -0400, Behdad Esfahbod wrote: On Fri, 2007-09-14 at 21:31 +0200, Ali Sabil wrote: I am wondering why discussion is continuing in the Git vs SVN (was: Can we improve things?) thread, why the discussion is not happening here instead ?! I don't want to offend anyone (so take it lightly), but I am afraid that many of us are subject to a Confirmation bias ... Can't we just continue the discussion in this thread comparing svn to DRCS in general before deciding on which DRCS would be the most appropriate to use within the GNOME project ? Because you can't talk about some abstract concept. I can't imagine anyone having any remotely legitimate reason to discuss that DSCM systems are not good for GNOME. This is simply a corollary of the fact that DSCMs provide all functionality that the SCSMs do. So, theoretically, you don't lose anything, and gain some. How do you set up a master repository with GIT/BZR? Generally it seems to involve pushing over ssh/sftp? Does that integrate with GNOME accounts? Does letting people push mean they could push other crap and hurt the repo? Or have they both gained daemons? Do they have logins that integrate with gnome accounts? Can one daemon handle multiple repos? These are all no problem at all. See fd.o for example. We are already using ssh with SVN. It's the same with git. Perhaps a legitimate reason is that moving to a DSCM won't be a benefit to everyone, yet everyone will have to learn another set of tools. Even just last month someone didnt know how to link to a file in SVN. And in order to make happy The GIT Crowd (and piss off all the people that just want to get on with their project) a sugar load of infrastructure needs to be tossed away. Who was that someone? Lets say we install a web application for translators. Who else can't be bothered to learn the new tool? If they can't, they can always submit patches. Does CIA.vc have bzr/git support? I guess a few GNOME projects must use it as GNOME is the third most active project today. Yes, at least for git, but I'm pretty sure it does bzr too. You could have took a look and tell too. Do your homework. How does buildbot work with bzr/git? The project looks a bit stalled, but the GNOME buildbot was a great idea that I was hoping to see gain ground. jhbuild supports both. In practice however, git is too hard and confusing to learn. *That* is a reason against this specific DSCM system. This is the reason i've been using bzr-svn. Its svn with benefits style suits me very well. The fact is, i'm happy with svn until i'm stranded without an internet connection, thats with bzr steps in. And its brilliant. We should get past all this git-svn and bzr-svn if we really are to decide anything. I am also afraid that we might be just becoming nothing more but geek fashion addicts trying to follow the latest RCS tendency without really building solid and constructive arguments ! I was going to be offended, but you warned :). Now that most probably means that you don't hack on the more crowded projects that much... Many Gtk+ developers for example could not have been as productive as they are right now if it wasn't for git-svn. And that's only a half-arsed solution. Again, its ok to say something is crap, but please tell us why! SVN SUCKS!! and GIT FTW!! aren't very compelling reasons. No idea how to write it down in short... Because branches are not designed for easy merging. Because I don't get the entire history at my fingertips. Because bisecting is not an option. Because even committing is slow. Because I can't commit locally, so have to finish a patch before pushing it out and I have to do my own svn diff x.patch to have some kind of backup in case I screw up. John -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Sun, 2007-09-16 at 14:00 +0200, Étienne Bersac wrote: Hi, In Gnome Scan, i generate ChangeLog using svn2cl. See http://svn.gnome.org/svn/gnome-scan/trunk/Makefile.am and ChangeLog: target. I also generate TODO from anjuta TODO.tasks. Note that generating ChangeLog makes it lag one commit behind. You have to commit and then update the ChangeLog. I've done ChangeLog generation for a couple of projects, thought the Makefile.am bits may be useful to some. Both automatically update the ChangeLog before make dist and take care of few other things. With CVS, should be easy to update to svn: http://webcvs.freedesktop.org/fribidi/fribidi2/Makefile.am?view=markup With git for cairo: http://gitweb.freedesktop.org/?p=cairo;a=blob;h=99f5ed6010d752037d2b66a70a28f4ca20f7b454;hb=3f4875dbe20e1d093d70f49c32f7ddf6a6e6ef61;f=ChangeLog.mk This one is actually way more advanced because 1) it caches ChangeLogs up to certain tags to speed up future ChangeLog generations. 2) It generates multiple ChangeLogs based on module version and release repo tags. For example for cairo it currently generates: ChangeLog.pre-1.0, ChangeLog.pre-1.2, and ChangeLog. When we release cairo 1.6, it will automatically move some stuff from ChangeLog to ChangeLog.pre-1.4. Anyway, ChangeLog is important. I'm used to read ChangeLog of projects i use from SVN (Gegl, Anjuta, etc.). However, i never read a ChangeLog from a release (but NEWS file instead). Regards, Étienne. -- E Ultreïa ! -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Sun, 2007-09-16 at 09:42 +0200, Vincent Untz wrote: Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit : Ok, lets be fair: most people who care about hacking on GNOME already know git, why should other options be selected? I don't think it is fair to state this. A lot of people certainly care about hacking on GNOME and don't know git (and don't care about it). Sorry, I meant more people hacking on GNOME who care about voicing their preference. The other camps are either very small or very shy. [sorry, this doesn't add anything useful to the debate] Vincent -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Mon, 2007-09-17 at 21:05 -0600, Elijah Newren wrote: On 9/17/07, Sebastien Bacher [EMAIL PROTECTED] wrote: Le dimanche 16 septembre 2007 à 09:42 +0200, Vincent Untz a écrit : Le samedi 15 septembre 2007, à 21:44 -0400, Behdad Esfahbod a écrit : Ok, lets be fair: most people who care about hacking on GNOME already know git, why should other options be selected? I don't think it is fair to state this. A lot of people certainly care about hacking on GNOME and don't know git (and don't care about it). I think Vincent is right there, looks like some people are using git and trying to make it look like that's the case for everybody else in the GNOME world which is not correct To be fair, if my guess is right that low-level GNOME hackers are highly correlated with git users (and anti-correlated to usage of other SCM systems)[1], then it may well have seemed to Behdad that this was in fact the case, as he is most likely to interact development wise with his fellow low-level hackers. Yep, most probably. Didn't want to cheat. I corrected myself in a follow-up. All I'm saying is that in all the various threads about this issue this past couple of weeks, we've seen many pro-git hackers, but not as many pro-others. But I particularly think your low-level vs higher-level separation is very real. Which leads me to think that there's no reason why all GNOME modules have to live in the same kind of repository. Again, just some food for thought. Elijah [1] http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00195.html -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Tue, 2007-09-18 at 11:50 -0500, Shaun McCance wrote: With git, it's simple as well. I could, in principle, prepare my NEWS entry from git log. But the messages would no longer be grouped as they are with separate ChangeLog files. What's more, it seems most git users don't prefix their commit messages with the affected files. So I'd end up seeing a commit message like Updated the Spanish translation Try git-log --stat -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Why have a ChangeLog file if you already have commit messages?
On Tue, 2007-09-18 at 12:30 -0500, Shaun McCance wrote: On Tue, 2007-09-18 at 12:57 -0400, Behdad Esfahbod wrote: On Tue, 2007-09-18 at 11:50 -0500, Shaun McCance wrote: With git, it's simple as well. I could, in principle, prepare my NEWS entry from git log. But the messages would no longer be grouped as they are with separate ChangeLog files. What's more, it seems most git users don't prefix their commit messages with the affected files. So I'd end up seeing a commit message like Updated the Spanish translation Try git-log --stat Well hot damn. Why isn't that in the man page? Yeah, that's a known issue with the git man pages, that they refer to other man pages for almost everything. Thanks, Behdad. Another very useful git tool, specially for getting an overview of what the project has been up to, is gitk or the GNOME version giggle. You get to see a summary of all commits, their parent-child tree, and choose a commit to see the patch right there. Very handy for patch review and cherry-picking to stable releases for example. -- Shaun -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On Sun, 2007-09-16 at 19:11 +0100, John Carr wrote: On Sun, 2007-09-16 at 12:27 -0400, Behdad Esfahbod wrote: On Sun, 2007-09-16 at 09:10 +0100, John Carr wrote: On Sat, 2007-09-15 at 18:26 -0400, Behdad Esfahbod wrote: On Fri, 2007-09-14 at 21:31 +0200, Ali Sabil wrote: I am wondering why discussion is continuing in the Git vs SVN (was: Can we improve things?) thread, why the discussion is not happening here instead ?! I don't want to offend anyone (so take it lightly), but I am afraid that many of us are subject to a Confirmation bias ... Can't we just continue the discussion in this thread comparing svn to DRCS in general before deciding on which DRCS would be the most appropriate to use within the GNOME project ? Because you can't talk about some abstract concept. I can't imagine anyone having any remotely legitimate reason to discuss that DSCM systems are not good for GNOME. This is simply a corollary of the fact that DSCMs provide all functionality that the SCSMs do. So, theoretically, you don't lose anything, and gain some. How do you set up a master repository with GIT/BZR? Generally it seems to involve pushing over ssh/sftp? Does that integrate with GNOME accounts? Does letting people push mean they could push other crap and hurt the repo? Or have they both gained daemons? Do they have logins that integrate with gnome accounts? Can one daemon handle multiple repos? These are all no problem at all. See fd.o for example. We are already using ssh with SVN. It's the same with git. How do you see the workflow working though. This isn't simply s/svn/git/. Are you looking to implement centralised VCS powered by GIT, in effect giving you SVN but with offline/merge powers? Or do you want something else out of it. Depends on how you look at it. From far, yes, it looks like just s/svn/git, but from near, you see developers hosting their own trees for various experimental features, etc. This is how kernel works, and how cairo and other fd.o modules work. This is the central cairo repo for example: git+ssh://git.cairographics.org/git/cairo And this is my cairo tree: git://people.freedesktop.org/~behdad/cairo Carl Worth's: git://people.freedesktop.org/~cworth/cairo Chris Wilson: git://people.freedesktop.org/~ickle/cairo Mathias Hasselmann: git://people.freedesktop.org/~hasselmm/cairo and so on... If we are still using the same accounts infrastructure, then this does nothing to improve the situation RE: new accounts. Which was the whole starting point of this discussion. (You'll probably argue that the win here is that people can maintain local branches to work from if we move to git, but git-svn and bzr-svn don't rule it out either do they?) git-svn and bzr-svn are broken. They are good to get some benefits of git/bzr with svn, but shouldn't be thought of as a long-term plan. You have to flatten all the 20 micro-commits you made before pushing a branch out to SVN, and that undoes all the nice properties of micro-commits and git. Next time you track a bug down to that commit good luck figuring out what's going on... Perhaps a legitimate reason is that moving to a DSCM won't be a benefit to everyone, yet everyone will have to learn another set of tools. Even just last month someone didnt know how to link to a file in SVN. And in order to make happy The GIT Crowd (and piss off all the people that just want to get on with their project) a sugar load of infrastructure needs to be tossed away. Who was that someone? Lets say we install a web application for translators. Who else can't be bothered to learn the new tool? If they can't, they can always submit patches. It was on DDL, not too long back. And he wasn't alone. I just decided to look at some git notes on kernel.org [1]. One of the first things it advised me (in its 20 commands or so version) that i should: git fsck git count-objects git repack git gc 4 commands out of the 20 basic ones i should now are commands to make sure my repository doesnt expand and expand and then corrupt/collapse on itself? So, you looked at the wrong place. I never ran any of those commands (ok, I did git-repack a couple times, but I don't normally do it). Call me noob, whatever. Check out excellent git howtos Shaun and Federico has written for GNOME users. I don't like the syntax for reverting changes either. Which syntax? git revert commit-id doesn't look anything to not like to me. Please be specific. Quite frankly after looking at those notes (and from my previous battles with this tool, and others [git was beyond unreasonably complex to attempt to learn]), then I might be one of those people! The trick is to not look at all the scary things that is possible with git. Ask for what you need and see scream if that looks hard to handle. To me, tagging in svn
Re: Why have a ChangeLog file if you already have commit messages?
On Wed, 2007-09-19 at 01:24 +0200, BJörn Lindqvist wrote: One reason is: for previous commits. Moving to a generated ChangeLog means losing a certain piece of history because many modules have crap log in their history... Yes. Problem is solved by moving the old ChangeLog. svn mv ChangeLog ChangeLog-pre-X-Y, isn't it? Let me restate: There is no rational reason why GNOME projects would need to *update* a ChangeLog file at each and every commit to a project. Right. I don't mind it though because Perl scripts already do the hard part for me. Others use Emacs macros, etc. If depending on log message, you just need separate set of scripts. Nothing impossible about it. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: GtkGLExt for GNOME 2.22
On Sat, 2007-09-22 at 20:51 +0200, Sven Herzberg wrote: Hi, Andreas Røsdal wrote: There has also been a lot of discussion about this in bug #119189 Add OpenGL support to GTK+. My NO for including GtkGLExt in GNOME. Instead one should go integrate its functionality in Gtk+. There's been lots of discussion in bugzilla but nobody every stepped up. behdad What about Windows support? MacOS X? DirectFB? »OpenGL support fot GTK+« should be as cross platform as GTK+ is. Regards, Sven -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: gio and gvfs for gnome 2.22?
On Mon, 2007-09-24 at 10:46 +0200, Alexander Larsson wrote: So, does it make sense to add gio (standalone or in an earlier glib release) and gvfs to the Gnome 2.22 desktop module set? On one hand I like to say it should be released under another name such that it doesn't conflict with glib when integrated, on the other hand it would be nice to release them with the same library and pkg-config name that the eventual glib version would take, so adopting applications wouldn't need any change when it's finally in glib. Just use libtool versioning to change soname any time you break API/ABI, so mystery doesn't happen. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: gio and gvfs for gnome 2.22?
On Thu, 2007-09-27 at 09:22 +0200, Alexander Larsson wrote: On Wed, 2007-09-26 at 17:20 -0400, Behdad Esfahbod wrote: On Mon, 2007-09-24 at 10:46 +0200, Alexander Larsson wrote: So, does it make sense to add gio (standalone or in an earlier glib release) and gvfs to the Gnome 2.22 desktop module set? On one hand I like to say it should be released under another name such that it doesn't conflict with glib when integrated, on the other hand it would be nice to release them with the same library and pkg-config name that the eventual glib version would take, so adopting applications wouldn't need any change when it's finally in glib. Just use libtool versioning to change soname any time you break API/ABI, so mystery doesn't happen. Right now the external library is called gio-standalone, with the pkg-config file being gio-standalone.pc. I could keep the module name, but rename the pkg-config file to gio.pc. Then when we move it to glib apps would just continue to run and build. Sounds like a plan. Don't forget the library name, that should be gio too or apps need to be recompiled. I agree with the API/ABI break soname bumping idea in general, and it could save us from a lot of weird behaviour. However, right now its changing a bit too often for that to be sane. Once it settles down a bit it seems like a good plan though. Yes, only bump for releases. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed passing of the baton
On Sat, 2007-09-29 at 11:01 -0600, Elijah Newren wrote: Hi all, Recently I proposed to the release team that it's time for someone else to take the role of GNOME's Release Manager. With their agreement, I bring the proposal to the development community at large to have Vincent Untz take the reins. Rock on, Vincent. :-) Rock on Vincent! Welcome to GNOME! err... Elijah -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: swfdec-gnome
On Mon, 2007-10-22 at 11:41 +0100, Bastien Nocera wrote: Saying that, it would be nice to see some integration in there such as: - running a Flash game, and being able to click on a menu item to add the game to the applications game sub-menu - running a Flash animation, and being able to set it as a screensaver - running a Flash animation and being able to save a still image, set as a background or open that still image in an application that supports it Killer feature: save a still to SVG. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
pango branched, a while ago...
Hi, Ok, I forgot to send this earlier, but anyway. A few weeks ago Pango was branched for 1.18 retroactively. The stable branch is called pango-1-18. Please update. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: TARBALLS DUE: GNOME 2.20.2 Stable Release
On Fri, 2007-11-23 at 19:08 +0100, Vincent Untz wrote: [sending the mail for Frédéric, since his mail seems to not have reached the list] Hi fellow GNOME hackers, Did you release 2.20.1 and then realize there was this small annoying bug in your module? Or maybe people started reporting a really small issue with your application - it just crashes on every login. Perhaps there's also the fact that the user interface or the documentation was not fully translated in a very obscure language - like, say, French. Now is the perfect time to make the world a better place: by releasing a 2.20.2 tarballs for each of the modules you maintain, you'll make a lot of people happy. Take Vincent U., who wishes to stay anonymous: to celebrate this event, he will stop eating icecream for X hours, X representing total count of modules that will have a new release. Help Vincent stay thin, release new version of your modules. Tarballs are due by Monday November 19th before 23:59 UTC for the GNOME 2.20.2 Stable Release, which will be delivered on Wednesday. Nov 19 sounds like, umm, last Monday. Please make sure that your tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded later than that will probably be too late to get in 2.20.2. If you are not able to make a tarball before this deadline or if you think you'll be late, please send a mail to the release team and we'll find someone to roll the tarball for you! The schedule for 2.20 stable releases and more information about making releases can be seen on the 2.21 page on the wiki: http://live.gnome.org/TwoPointTwentyone For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule Thanks, -- Les gens heureux ne sont pas pressés. -- behdad http://behdad.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin, 1759 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring DOAP instead of MAINTAINERS file
Hi all,
I've read the entire thread. I didn't see my thoughts on this mentioned
already, so I add them here.
I don't care what the infra team does to keep an updated view of my
modules as long as it leaves outside of the module and doesn't need
manual updating regularly (even every year is considered regularly.
Sorry! More on that later.)
What I do care about is that all released modules MUST have the files
AUTHORS, README, and MAINTAINERS, some also have THANKS. Most of these
are required by GNU Coding Standards which is a really great document,
and my other reason for this is that when a user downloads and unpacks a
tarball, they don't look for a DOAP file, they look for those ol'
big-letter files.
Which brings us to the logical conclusion that either the big-letter
files should be created from DOAP file automatically, or the other way
around. I'm sure most agree that other way around is preferred at this
time. Right?
So, what I like to see is, MAINTAINERS and AUTHORS automatically scanned
for names/address/login-ids and central DOAP file updated and as a
result Bugzilla developers for the module updated. Bugzilla module for
a SVN module also can be easily extracted from configure.{in,ac}. It's
supposed to be at least.
The rest of the DOAP bits, not sure where they are supposed to be
updated from. Direct commit to the doap repo works for me. That's not
harder than updating GTK+ website with every Pango release at least...
To summarize, seems to me like most of the thread was in fact irrelevant
as I don't see any change being proposed to individual modules. It's
about gathering meta-information about GNOME in a central place, and I
don't see how that can be bad, even if the format is not perfect. We
can always write an XSL style to convert to any other one, right?
That's what's great about XML, right?
Cheers,
behdad
On Fri, 2008-01-18 at 09:49 +0100, Olav Vitters wrote:
Hello,
Summary: I'd like replace the MAINTAINERS requirement by doap files.
Comments welcome.
Currently project information is spread thoughout various systems. The
maintainers are available in MAINTAINERS files, developers in AUTHORS,
the description is possibly in either Bugzilla or some README file,
etc. I'd like to make use of DOAP files for this.
See for example the usage of DOAP on projects.apache.org:
* http://svn.apache.org/repos/asf/ant/core/trunk/doap_Ant.rdf
* http://projects.apache.org/projects/ant.html
Examples of what is in a DOAP file:
* maintainers
* long description
* releases
* homepage / download link
* bugtracker link ()
* repository info (SVN + viewvc)
And others:
* short description
* mailing lists
* various kinds of contributors
* programming language
* category
* etc
The intention at the moment is to just make these DOAP files
available. I don't plan to create something like projects.apache.org
in the near future. This for every module in svn.gnome.org. I have a
partial script that I want to expand to include as much info as I can
possibly can add automatically (everything until the 'and others'
above).
My preference is to create some new repository and include the doap
files there ('doap'). However, to make things easier I don't plan on
storing the full doap file there. It will have something like
'$module.rdf.in', that will be transformed into a $module.rdf on some
site.
After the conversion I plan on requiring such a doap file, and
removing the MAINTAINERS requirement. The current /trunk/MAINTAINERS
requirement means you cannot replace /trunk with a branch by just
using 'svn mv' (as at one moment /trunk won't exist). With having the
doap file in another repository, the problem is only restricted to
that repository.
Note: There is a plan for the new www.gnome.org to contain doap files
as well. See http://live.gnome.org/GnomeWeb/GnomeProducts. SO perhaps
at one point the doap files are used to the www.gnome.org CMS.
Things that could use doap:
* moap (https://thomas.apestaart.org/moap/trac)
* maintainer.py (http://developer.imendio.com/projects/misc/maintainer)
* Mango sync script (instead of /trunk/MAINTAINERS files)
* Bugzilla (cron job that updates e.g. homepage link)
Note:
The doap repository will have strict pre-commit checks. Ensuring a
valid doap file with enough information. Also I might restrict
changing the maintainer section to the current maintainers.
The doap files can include 'foaf' stuff to provide maintainer
information. I'm not exactly sure what to do there. If you are a
maintainer for 10 projects I don't think you'll ever update that info.
However, I cannot just put info from LDAP in there as that often
contains the full name. Doap does allow using hashing for the email
address. ATM I don't want to add anything other than the userid. Maybe
the full name taken from the MAINTAINERS file.
Perhaps I'll create foaf files in the doap respository (e.g. the doap
only contains
