Re: GNOME 2.26 Showstopper Review
On Mon, 2009-02-23 at 21:41 +0100, Gian Mario Tagliaretti wrote: On Mon, Feb 23, 2009 at 8:43 PM, Andre Klapper ak...@gmx.net wrote: Andre, * http://live.gnome.org/GtkPrintPort : gnome-games, gnome-python-desktop, gnome-devel-docs (update) * http://live.gnome.org/GioPort : PATCHES: dasher TODO: gnome-python-desktop, gnome-utils/gsearchtool I don't think that gnome-python-desktop would need removing GtkPrint and gnomeVFS, it contains GnomePrint python bindings which cannot be removed and I cannot find any reference to GnomeVFS that needs to be removed. If I'm mistaking please correct me, cc'ing Gustavo for a better opinion. Some months later, in gnome-2.28.modules file in jhbuild those two modules are still part of gnome 2.28. Someone please let me know if this changes. And anyway I am not going to bother to physically move code from one module to another for just a couple of library bindings, just not worth the trouble. I am, however, welcome to take other steps to deprecate the bindings: 1. Add a python warning every time the deprecated module is imported; 2. Not build the deprecatd bindings by default unless a --enable-deprecated-bindings option is used. -- Gustavo J. A. M. Carneiro g...@inescporto.pt gust...@users.sourceforge.net The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-common git migration problem?
Git checkout gives me an error (Object 56e99a3796075fb134a10bd0adc3afc86917b8fa not a commit), and then some files are missing and it doesn't build: g...@dark-tower:gnome$ git clone gnome:gnome-common Initialized empty Git repository in /home/gjc/projects/gnome/gnome-common/.git/ error: Object 56e99a3796075fb134a10bd0adc3afc86917b8fa not a commit remote: Counting objects: 910, done. remote: Cremote: ompressing objects: 100% (312/312), done. remote: Total 910 (delta 587), reused 910 (delta 587) Receiving objects: 100% (910/910), 291.12 KiB | 73 KiB/s, done. Resolving deltas: 100% (587/587), done. g...@dark-tower:gnome$ ls gnome-common/ autogen.sh* ChangeLog configure.in doc-build/ macros2/ MAINTAINERS Makefile.am g...@dark-tower:gnome$ cd gnome-common/ g...@dark-tower:gnome-common$ ./autogen.sh checking for autoconf = 2.53... testing autoconf2.50... not found. testing autoconf... found 2.61 checking for automake = 1.9... testing automake-1.10... not found. testing automake-1.9... found 1.9.6 Checking for forbidden M4 macros... **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. Processing ./configure.in Running aclocal-1.9... Running autoconf... Running automake-1.9... configure.in: installing `./install-sh' configure.in: installing `./missing' Makefile.am: installing `./INSTALL' Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: installing `./COPYING' configure.in:14: required file `gnome-common.spec.in' not found configure.in:14: required file `macros2/Makefile.in' not found configure.in:14: required file `doc-build/Makefile.in' not found -- Gustavo J. A. M. Carneiro g...@inescporto.pt gust...@users.sourceforge.net The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.26 Showstopper Review
On Mon, 2009-02-23 at 21:41 +0100, Gian Mario Tagliaretti wrote: On Mon, Feb 23, 2009 at 8:43 PM, Andre Klapper ak...@gmx.net wrote: Andre, * http://live.gnome.org/GtkPrintPort : gnome-games, gnome-python-desktop, gnome-devel-docs (update) * http://live.gnome.org/GioPort : PATCHES: dasher TODO: gnome-python-desktop, gnome-utils/gsearchtool Correction: GnomeVFS bindings are in gnome-python, not gnome-python-desktop. I don't think that gnome-python-desktop would need removing GtkPrint and gnomeVFS, it contains GnomePrint python bindings which cannot be removed and I cannot find any reference to GnomeVFS that needs to be removed. If I'm mistaking please correct me, cc'ing Gustavo for a better opinion. I really don't know. Does GnomePrint no longer belong in the GNOME Desktop platform? Does GnomeVFS no longer belong in the GNOME Developer platform? In case of Yes, would it be OK to keep the Python bindings where they are and just mark them as deprecated? Else they'd have to move into gnome-python-extras, I guess... -- Gustavo J. A. M. Carneiro g...@inescporto.pt gust...@users.sourceforge.net The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.26 Showstopper Review
On Tue, 2009-02-24 at 23:12 +0100, Steve Frécinaux wrote: Alberto Ruiz wrote: 2009/2/24 Gian Mario Tagliaretti gia...@gnome.org: On Tue, Feb 24, 2009 at 8:46 PM, Vincent Untz vu...@gnome.org wrote: Tomboy was using GnomePrint, the bindings provide the library, so unless GnomePrint is not going to be shipped anymore there is no point in talking about porting. That's the whole point: we don't want to ship libgnomeprint* anymore :-) Sure, is GnomePrint going to be shipped in 2.26? If the answer is yes we do there is no point in discussing it :) (and put it as a showstopper) Yes there is, if you include them, people with a 2.26 environment may end up writing new applications that use them too. Can't you just raise a warning when importing one of the deprecated modules, so it still works for older applications but warn authors that it is obsolete? Yes, we can do that. Although there is always the risk that deprecating GnomeVFS will make some users furious if there is no viable alternative to do the same thing with GIO [1]. And I mean GIO + GIO Python bindings. It could happen that an application is using a GnomeVFS API for something that GIO does not provide or for which there are no Python bindings, since coverage is probably not 100%. Maybe it's too soon to deprecate GnomeVFS? I agree GnomePrint has been replaced a long time ago, but GIO is too new IMHO. [1] See bug #434023 for an example. -- Gustavo J. A. M. Carneiro g...@inescporto.pt gust...@users.sourceforge.net The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Tue, 2009-01-06 at 21:30 +, Alberto Ruiz wrote: 2009/1/6 Alexander Larsson al...@redhat.com: On Tue, 2009-01-06 at 21:01 +0100, Loïc Minier wrote: On Tue, Jan 06, 2009, Behdad Esfahbod wrote: From what I understand, so far there has been one proposal, from Olav, who proposed that he and John implement John's idea of implementing a git-serve plugin for the bzr repo server. I wonder whether you received interesting ideas in the survey itself? As insane as it might sound, I personally wouldn't mind each module picking its VCS. I think common tasks which random contributors need to achieve can be documented for all VCS-es (checkout, do some changes and commit or create a patch). Just like various modules are using various programming languages or even build systems. Each app picking its VCS seems better than the proposed system with both bzr and git. Because with the proposal you can pick any vcs you like as a user, but if you didn't pick the one the maintainer used then he and the other developers can't pull from you and you're left out on your own development island. So, all modules would anyway need to marks out what the prefered vcs for it is and all developers would have to learn both. Am I the only one crying on how bad and confusing is this going to be for newcomers? One of the most obvious ways to contribute to free software these days it to do it on the people's most used apps, which are the desktop apps (translator as an example). There are guys out there who doesn't even get the point of VCS and their first approach to them is going to be GNOME itself. Think about them trying to browse for information on how to create my first patch, and this section saying you have to figure out which project are you gonna pick, and then, learn to use it. Welcome to the open source world. Generally open source developers are not limited to GNOME, and they eventually learn 2-3 revision control systems. I mean, they don't need to learn a lot of commands of each RCS, just the basics: 1- Checkout/clone module; 2- Update; 3- Create a diff of changes, redirecting to a patch file. With those three operations alone is enough to cover 90% of all open source developers needs when they are contributing to a project to which they have no commit privileges. And those two operations alone are dead easy to learn for a number of VCSs. Developers with commit privileges need to know just a few more commands: 1- commit 2- push (if applicable) And finally maintainers need to know a few more commands, like branching, merging, and tagging. But they only need to learn those for the modules they maintain. To be honest, I think that this discussion would just go away if we had Tortoise like apps integrated with jhbuild for Nautilus where you have a common set of graphical tools to do the most common work for 90% of the VCS users. Then, and only then, we could stop worrying about which VCS do we choose, since we won't have to fiddle with any command line (for god's sake, we're in 2009 already). Disagreed. Command line interface is often more productive than any GUI for certain things. I don't use any IDE for source code editing, and I would certainly hate to have to use Nautilus for commits. Not to say that GUIs aren't useful for some things. I have seen nice GUIs for bazaar, git, and mercurial. But they are most useful for visualizing the repository tree, rather than operations that change the repository, it seems to me. Regards, -- Gustavo J. A. M. Carneiro g...@inescporto.pt gust...@users.sourceforge.net The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Mon, 2009-01-05 at 11:23 +0100, Edward Hervey wrote: On Sun, 2009-01-04 at 20:32 +, Gustavo J. A. M. Carneiro wrote: On Sat, 2009-01-03 at 22:46 -0500, Behdad Esfahbod wrote: In December I ran a distributed version control system survey for GNOME. From the survey opening page: Thank you for taking the GNOME DVCS Survey. This survey is run on behalf of the GNOME Foundation board of directors, release team, and sysadmin team. The GNOME project is planning a possible move from SVN to a distributed version control system in 2009. The contenders for the system to use are bzr, git, and hg. The aim of the survey is to help us better understand familiarity and preferences of our active contributor base regarding the future version control system for GNOME. The survey results will be informational and will be sent to foundation-list and desktop-devel-list upon completion. GNOME contributors with an SVN account who had an SSH key installed on their account were invited to fill in the survey. A total of 1083 account holders were invited, and 579 filled in the survey. The survey results are now available to the public: http://www.gnome.org/~behdad/dvcs-survey/ Elijah Newren did an initial analysis of the data. His analysis also includes the survey questions and answers. Find it at: http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/ If you analyze the results, please reply to this thread and also leave a comment on my blog post linking to your analysis: http://mces.blogspot.com/2009/01/gnome-dvcs-survey.html Just in case I am forced to switch to git in the future (being open minded here, although I prefer bazaar), does someone have any advice how to generate a nice GNU style ChangeLog (like what emacs produces) from git commit logs? I know that some projects like Cairo auto-generate ChangeLog already, but the default git changelog format is too detailed/ugly IMHO. Heya, I wrote a python script for PiTiVi (now that we've switch to git) that does just that and which we run at (pre-)release-time to generate the ChangeLog file: http://git.pitivi.org/?p=pitivi.git;a=blob_plain;f=docs/makeChangelog.py;hb=HEAD Heh, thanks a lot. This looks nice. Nicer than the one in gnulib that Rui Tiago pointed out. Although I must say not as nice as my 'gnulog' bazaar log formatter plugin.. ;-) But I guess good enough that I'd be comfortable replacing a hand written ChangeLog with autogenerated one. Regards, -- Gustavo J. A. M. Carneiro g...@inescporto.pt gust...@users.sourceforge.net The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Sat, 2009-01-03 at 22:46 -0500, Behdad Esfahbod wrote: In December I ran a distributed version control system survey for GNOME. From the survey opening page: Thank you for taking the GNOME DVCS Survey. This survey is run on behalf of the GNOME Foundation board of directors, release team, and sysadmin team. The GNOME project is planning a possible move from SVN to a distributed version control system in 2009. The contenders for the system to use are bzr, git, and hg. The aim of the survey is to help us better understand familiarity and preferences of our active contributor base regarding the future version control system for GNOME. The survey results will be informational and will be sent to foundation-list and desktop-devel-list upon completion. GNOME contributors with an SVN account who had an SSH key installed on their account were invited to fill in the survey. A total of 1083 account holders were invited, and 579 filled in the survey. The survey results are now available to the public: http://www.gnome.org/~behdad/dvcs-survey/ Elijah Newren did an initial analysis of the data. His analysis also includes the survey questions and answers. Find it at: http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-results/ If you analyze the results, please reply to this thread and also leave a comment on my blog post linking to your analysis: http://mces.blogspot.com/2009/01/gnome-dvcs-survey.html Just in case I am forced to switch to git in the future (being open minded here, although I prefer bazaar), does someone have any advice how to generate a nice GNU style ChangeLog (like what emacs produces) from git commit logs? I know that some projects like Cairo auto-generate ChangeLog already, but the default git changelog format is too detailed/ugly IMHO. -- Gustavo J. A. M. Carneiro g...@inescporto.pt gust...@users.sourceforge.net The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
On Sat, 2008-11-01 at 19:27 +0100, Philippe Rouquier wrote: Hi, We'd be interested in having brasero integrated into the GNOME desktop. +1 Regarding n-c-b comparisons, there is at least one thing that brasero gets right and that is missing in n-c-b: a nice bar showing amount of used/free disc capacity. In n-c-b my recurrent pattern when making a backup of some files to DVD is 1. add some files, 2. press the burn button to see how much space I have used, 3. if there is space left, press the cancel file and goto 1, else press burn. Brasero definitely deserves to be in the GNOME desktop IMHO. Great work! Brasero is a standalone application to burn CDs and DVDs. We have tried to make brasero as easy to use and as simple as possible. Brasero has been developped for about 4 years now and has been actively maintained ever since. Brasero supports the basic operations: - CD/DVD creation (audio, data) - CD/DVD copy - CD/DVD blanking and formatting One of the strengths of brasero is that it can use various backends through its plugin system and can easily be extended to support some more. Currently it supports growisofs, libburn, libisofs, cdrecord/mkisofs/readcd, wodim/genisoimage/readom, cdrdao. The plugin system also allows for additional features: (on the fly) checksuming, use of remote files (FTP, samba, ...), audio normalization, video DVD copy. Other features includes: full multisession support preview of audio, video files and pictures initial support for video DVD creation audio track splitting medium cover editor projects Brasero and GNOME: - we tried to stick to GNOME HIG guidelines. - brasero has tried to integrate as tightly as possible with the rest of the desktop and in particular with nautilus - it is up to date as far as GNOME goals are concerned - it uses and has been using svn.gnome.org and bugzilla.gnome.org for quite some time now - it is well translated by GNOME translator teams (btw, thanks to all of you again) - a documentation is available It supports linux, OpenSolaris and freeBSD. As far as we know, it is used as the default burning application on Ubuntu and OpenSuse; but I was told it was also considered to be chosen as the default application for OpenSolaris. Uptodate packages are also available for Fedora and Mandriva. Dependencies: - glib and gio - gtk+ - gstreamer (for all audio and video operations) - libxml2 - HAL - dbus Optional dependencies: - totem-pl-parser - beagle - dvdcss (for video DVD copy) - all burning backends (libburn, libisofs, growisofs, wodim, cdrecord, readcd, readom, mkisofs, genisoimage, ) Short term: - get ready for GTK+ 3.0 - support DVD-RAM and BDs - improvements to the video project parts - allow full multisession media edition (file removal, file renaming, ...) through libisofs Future plans: - audio on DVDs - allow to shrink video DVDs when copying - video DVD to video CD copy - backup and automatic file update on insertion - file spanning - creation of encrypted images Site: http://live.gnome.org/Brasero http://www.gnome.org/projects/brasero/ All comments and suggestions would be of course appreciated. We are willing to do whatever needs to be done to improve brasero for it to be integrated. NOTE: after the 0.8.3 release that should take place soon, we intend to branch it and use SVN trunk for the next development version. ATM trunk is the latest stable version. Regards Philippe Rouquier ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
wOn Thu, 2008-09-18 at 22:55 -0500, Brian Cameron wrote: Stef: Is there a standard way or goal for the UI and behavior of password prompts on the desktop? Besides having as few as possible, that is. There is Trusted Path to consider. To meet Trusted Path requirements, any entry of the root password needs to be done via a trusted user. This means that the dialog would need to run as a special trusted user, and not as the user whose session is running. Much like the GDM GUI programs are run by the special gdm user. Otherwise, someone who has gained a user privilege could possibly snoop process memory space to get the root password. Someone who has gained a user privilege could possibly show a fake password input dialog that looks exactly like a real password prompt, thereby learning the root password. Same thing with VT swiching. It shouldn't be hard to make the it look like we are switching VT from a simple X11 program running as the user. If the local user account has been compromised it seems to me that all hope is lost. So I don't really see the point of all this Trusted Path complexity. But I'm no security expert; I might be missing something. Also if the dialog is running as the user and core dumps (or can be induced to core dump), then the password may be left behind in the core file readable by the user. Also the dialog would need to run with a separate Xauth connection to the Xserver to protect against snooping via X interfaces. However, to resolve this problem would require a fairly significant amount of infrastructure that does not exist today. Most people feel that the existing security is good enough, but sysadmins with strict Trusted Path requirements would likely have to disable programs from asking for root passwords in dialogs via programs like gnome-keyring, PolicyKit, or gksu. gnome-screensaver has similar Trusted Path issues. I understand Jon McCann is planning to fix this by making the screen lock program show up in a separate Xserver running as a trusted user. This would work via a mechanism similar to VT switching. Once that is done, perhaps that could be extended so programs like gnome-keyring or gksu could use a similar interface for added security and for meeting Trusted Path requirements. That would also resolve a lot of the grabbing and focus issues that plague programs asking for sensitive root passwords in a user session. So this information is probably not useful in the short term, but something to be aware of. A long-term goal should be to address these issues so that root password entry is handled in a more secure fashion in the future. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
On Fri, 2008-09-19 at 13:09 +0200, Patryk Zawadzki wrote: On Fri, Sep 19, 2008 at 12:42 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: Someone who has gained a user privilege could possibly show a fake password input dialog that looks exactly like a real password prompt, thereby learning the root password. Same thing with VT swiching. It shouldn't be hard to make the it look like we are switching VT from a simple X11 program running as the user. If the local user account has been compromised it seems to me that all hope is lost. So I don't really see the point of all this Trusted Path complexity. But I'm no security expert; I might be missing something. I believe the goal is to use some uncatchable keyboard sequence a'la Windows' secure auth (Ctrl+Alt+Del). This is kind of silly; I have to type a complex keyboard combination in order to input a password? That is annoying. Additionally, switching VTs in Linux is usually slow; more annoyance. Expect some resistance on this feature. Besides, my user account being compromised is 99% as bad as the root account being compromised, IMHO. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.24 Showstopper Review
On Sun, 2008-08-31 at 23:51 +0200, Andre Klapper wrote: GNOME GOALS not yet completed: * http://live.gnome.org/GnomeGoals/PoLinguas : atk * http://live.gnome.org/GnomeGoals/PoptGOption : GnomePython * http://live.gnome.org/GtkPrintPort : gnome-python-desktop, anjuta, gnome-devel-docs (update), GnomePython I don't understand why gnome-python-desktop or gnome-python needs to use GtkPrint. They are just wrapping libraries for Python... * http://live.gnome.org/GioPort : PATCHES: alacarte, gnome-applets, gnome-utils, gnome-build, gdl, TODO: gnome-python-desktop, gnome-utils, sabayon, anjuta Again, why gnome-python-desktop should be ported to gio? It sounds like a simpe grep-find generated list, but I doubt it applies to python bindings. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Tue, 2008-07-01 at 12:19 -0400, David Malcolm wrote: [...] Rereading, this has turned into a rant, but posting in the hope that it will be useful: It often puts me off, as an experienced C developer. When I first started looking at GNOME (and indeed Linux) I was an experienced C developer, having worked on various commercial videogames, finding ways to save a few hundred bytes here and there to get stuff to fit in RAM on the target platform... and I still have trouble with the GNU autotools: I want to spend my brainpower thinking about the problem domain of the program, my users, and my code, not having to deal with a pile of hacks upon hacks for trying to workaround obsolete platforms with a broken linker (or whatever). The vast majority of the input to this tool is mere configuration data, but we're stuck with a model where it gets run through scripts on top of scripts that generate a program that's run as the developer (how many of you audit the generated scripts for malicious content?) I added WAF support to gnome-python and gnome-python-desktop. Doing my best to improve the situation on my end :) Also, I feel that a supposed cross-platform compatibility solution that fails to integrate with Visual Studio on Windows, and with XCode on OS X is broken by definition (not that I use either of these platforms). OS X uses GCC for all compilation. Wanting the build tool to interact with the OS X IDE is too much to ask for IMHO. And you can run mingw/GCC on win32 too. And Visual Studio has command line tools for compilation, it's not just an IDE. Again, asking for the tool to also generate Visual Studio project files is too much to ask. Command line is enough. Nothing stops you from editing the source files with your favorite IDE, even if the build tool works from the command line. If a developer cannot use the command line, how is he expected to install a GNOME module, to test it? And lets not forget other IDEs. What about Eclipse, shouldn't we add IDE support for it also? Where does it stop? Also, I find it funny that people that do not actually use either XCode or Visual Studio claim that supporting them is crucial. Again, I don't trust that judgement without proof (statistics). Now, I do know a few developers that use Visual Studio and can't live without it. But among GNOME developers I have serious doubts anyone uses one of those IDEs. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
On Mon, 2008-06-30 at 15:25 +0200, Mathias Hasselmann wrote: Am Montag, den 30.06.2008, 12:30 +0100 schrieb Bastien Nocera: On Mon, 2008-06-30 at 13:14 +0200, Mathias Hasselmann wrote: Am Montag, den 30.06.2008, 10:31 +0100 schrieb Bastien Nocera: On Mon, 2008-06-30 at 01:51 +, Stef wrote: Interesting. That's a very valid concern. Although this is a decidedly different case. Vala is used to generate C code for parts of seahorse. This C code is then checked into the repository, and included in the tarballs, so that people can build it without vala. Right. Some of us have already been there with gob. I don't usually think it's worth the pain, but it's your code. I'll start complaining when I have to fix bugs in that code. Just that gob wasn't half as ambitious as Vala. gob took some kind of minimum effort approach which lead to the effect that you were mixing high-level gob and low-level C code all the time. This just felt flaky and hackish. Vala on the other hand tries to provide a complete user experience. Programming with it feels much better than it ever did with gob. Having written quite some C# and Java code I think, that writing Vala code feels as natural as with those languages. I'm not comparing featuresets. I'm saying it still feels like a pre-processor. It needs native autotools[1] support before it's considered for use in core components. While your rant has some justification Just where you saw a rant, I don't know. I'd rather you didn't attribute those kind of qualifiers to my messages in the future. Update the bug: http://bugzilla.gnome.org/show_bug.cgi?id=472048#c11 The automake maintainers received a patch ages ago: http://lists.gnu.org/archive/html/automake-patches/2007-09/msg7.html After that I've got the FSF's copyright assignment papers sent, and I've sent them back. No progress since then. An excellent reason to switch to a more modular build system, one that does not require patching the core in order to extend it. Something like... WAF :-) -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: 2008/6/30 Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: An excellent reason to switch to a more modular build system, one that does not require patching the core in order to extend it. Something like... WAF :-) Well, after some time evaluating waf, there's something that I don't quite like about it and that I don't see changing anytime soon. During its development cycle last year trunk has been broken a few times, api has changed and the Tools modules to support gnome features have stopped working. Last time I checked, it lacks a proper test suite to avoid regression on supported tools. There's no difference between well supported features and unstable ones, so people using those extensions don't know what sort of stability they should spect. As we talk, the gnome demo at trunk is broken, a situation that I've seen more times than I would like too: File /home/aruiz/src/waf-read-only/demos/gnome/wscript, line 6, in module import Params, intltool, gnome ImportError: No module named Params Yes, I think that waf has a lot of potential, and eventually it would be the way to go, but without a significant change of direction in the way it is maintained, I don't see GNOME changing to it anytime soon. Yes, I wholehartedly agree. I periodically discuss these things with the maintainer, to try to change his habits, but it's no use :( Ideally we would need a fork of WAF, with a maintainer that understands how software cycles should work. However, the current maintainer is a good developer (if not a good maintainer) and would be a shame to lose his contributions, on one hand, and no one else has time to maintain a fork of WAF, on the other hand. The solution I come up with now is to just freeze the WAF version I use. Fortunately, things like vala support can be done on top, rather than within, WAF, so it's not hard to stabilize on a WAF version for a very long time. Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. Proposal: - Decide features we need to do a migrate - Create a table of proposed build systems x features - Check the KDE build system migration and see what we can learn[1] - An obvious option will eventually appear - Start migrate some modules [1]: Tim has some notes on this: http://blogs.gnome.org/timj/2008/06/02/02062008-linuxtag-2008/ Johan -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build system alternatives (Was: Using vala in GNOME)
On Mon, 2008-06-30 at 23:45 +0300, natan yellin wrote: On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 2008/6/30 Gustavo J. A. M. Carneiro [EMAIL PROTECTED]: On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote: Gustavo J. A. M. Carneiro wrote: On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote: [..] Plus, CMake is getting more mature and stable and it already supports VisualStudio and XCode project files conversion, lack of proper extensibility being its only downside at the moment. Lack of extensibility, and use of another arcane custom made programming language (if we can call it that) for everything. No, CMake is not an answer. It is not significantly better than autotools to justify a switch to it IMHO. CMake *is* considerably better. Xcode/VisualStudio are killer features which alone would make a switch worth it. I disagree that Xcode/VisualStudio are killer features. A powerful programming language and extensibility are way better features IMHO. Does a significant percentage of GNOME developers use any of these IDEs? Without such data you can't assert that those are killer features. For the case of Vala, I don't see how CMake handles it any better than autotools. Can we please start to organize ourselves and try to move forward with switching to another build system? We can't switch to any single build system any more than we can switch to a single DVCS. Or to a single programming language, for that matter! Different developers value different features. Modern developers have to adapt to different environments. I, for example, regularly program in C, C++, and Python. I know how to use cvs, subversion, bazaar, git (poorly), and mercurial. In particular I use subversion, bazaar, and mercurial very regularly, all at the same time, git not so much only because I didn't need to. I can hack plain makefiles, autoconf/automake, waf, and scons. And is this an acceptable barrier of entry to Gnome development? Agreed. While the skills that you mentioned do come with time no matter what, you want to avoid forcing beginner developers to chew more than they can swallow. That is a moot point. A beginner chooses *one* project to hack on, that's all. All he has to know is the programming language and tools of that single project. That is an issue when a developer wants to transition to another module, at which point he is probably no longer a beginner. This is basically the same thing as with programming languages. Do you think everything should be coded in C in order to lower the required skill set of beginner hackers? What about Python, C++, Vala, C#, Perl? We ban modules written in those other languages because they force developers to learn a new programming language? Besides, making life easier beginner contributors, fine, I'm all for it. But that has to be balanced with keeping the mental sanity of the contributors we already have. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting a list of open files, the smart way?
On Wed, 2008-05-14 at 19:10 -0500, Diego Escalante Urrelo wrote: Hi, I have made a quite simple patch for bug 528559[0], it makes the quite useless drive is being used dialog into a list of applications using such drive[1]. I'm using a little hack with lsof, but it's not really reliable, like when process names are too long. I checked libgtop quickly but the lack of documentation didn't help. So, I'm writing to get some clues about this, any advice? My main problem is to do something like tell me which files in device $d are in use, and tell me the executable for the process using such file If you have time, you could go two steps further than the executable for the process using such file: 1- Try to find a .desktop file associated with the exe and display the application name and icon instead; 2- Offer options (button?) to terminate each of the applications (SIGTERM first then SIGKILL if SIGTERM does not work after a while) thanks everyone, Diego 0 - http://bugzilla.gnome.org/show_bug.cgi?id=528559 1 - http://bugzilla.gnome.org/attachment.cgi?id=109417 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sun, 2008-04-20 at 18:59 -0500, Jason D. Clinton wrote: On Sun, Apr 20, 2008 at 6:33 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: 1. It does not use Cairo; The implementation that I'm proposing will blit Cairo-rendered surfaces to textures using cluttermm. I couldn't make pretty, scalable 2D graphics without Cairo. So, they complement each other... Well, Cairo is not just a checkbox that you can check and make everyone happy; unless the entire output is Cairo, you cannot easily print the content with high quality vector graphics. You can't convert OpenGL graphics to PS or PDF... But I want to make clear that it is just a general comment I make about Clutter. In this specific case, gnome-games, it doesn't apply; I don't think people will care much about high quality printing of a chess game :) -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Sun, 2008-04-20 at 16:36 -0500, Jason D. Clinton wrote: Hi, For Gnome Games 2.24, I would like to have an optional hardware-accelerated Gnometris theme. This would be enabled by default on installations where glxinfo reports Direct Rendering: Yes. All of the old themes will continue to be present and used as fall-backs when the hardware is not there. After much research, clutter appears to be the most Gnome-friendly, stable, and active canvas-like project. Others which may come up in this discussion are largely inactive (goocanvas) or sufficiently incomplete (hippocanvas) as to make them unusable for implementation of a Tetris-like game animation. pigment is out because it's Python-only (or so I am told). I'm not saying anything bad about any of the above: just that they don't meet my requirements, right now. I considered other non-Gnome canvas options too such as QGraphicsView and Webkit canvas and decided against both due to very difficult implementation details. I suspect that this will make Gnometris more attractive for embedded use since many mobile devices now support OpenGL--though, no one has said they will use it for embedded use. I solicited objections to using clutter on our gnome-games mailing list and on my blog which is aggregated on Planet. There were no objections. Yes, it's yet another canvas. But, it appears to be widely available in distributions and no one is (yet) proposing it for inclusion in the Gnome officially. With a little work, the new rendering engine will add a lot of bling for very little coding investment. It will probably be something--at least--worth mentioning in the release notes. The fact that some drivers do not yet have OpenGL support is irrelevant as there are no plans to deprecate the existing theme engines. If Clutter is built on top of opengl exclusively (correct me if I'm wrong), then: 1. It does not use Cairo; 2. It might not work if opengl is not available; 3. It might not integrate nicely with gtk+ printing; Maybe these concerns don't apply to gnome-games. However, Gnome applications in general should be concerned about them IMHO. On the other hand, Cairo has failed to live up to the promise of hardware acceleration. After years of development with no significant results on the hardware acceleration front (when compared to pure OpenGL) perhaps it deserves this fate... Not taking sides here, just providing some comments. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing libgnomeprint* from the desktop set
On Fri, 2008-03-28 at 17:12 +0100, Vincent Untz wrote: Hi, I'd like us to finally stop shipping libgnomeprint/libgnomeprintui as part of the desktop set. As far as I can tell from the jhbuild moduleset, it's only used by: + anjuta, with the scintilla editor plugin (but there's the gtksourceview editor plugin) + tomboy: http://bugzilla.gnome.org/show_bug.cgi?id=512369 + gnome-python-desktop, for bindings I would be fine in principle with moving stuff away from gnome-python-desktop, but I was wondering, is it possible (and not too hard) to move subdirectories from one SVN module to another one without losing history, like it used to be done for CVS surgery? -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus unmount volume, also power-off?
On Seg, 2008-02-04 at 08:44 -0500, Diego Escalante Urrelo wrote: Hey On 2/4/08, Simos Xenitellis [EMAIL PROTECTED] wrote: Hi All, Currently Nautilus offers the option to either unmount or eject (if suitable) a volume, such as an external USB harddisk or flash drive. There has been discussion in user forums if it is possible to power off those external storage devices as well, http://ubuntuforums.org/showthread.php?mode=hybridt=451344 http://www.techteam.gr/index.php?showtopic=118719 A way to implement the unmount+poweroff in Nautilus is to create a Nautilus action that calls umount, then sdparm --command=stop, and there is such a script circulating the forums. Here is what I have in mind in implementing this a. An external device can have several partitions. A power-off must be attempted only when all partitions have been unmounted. Currently, the UI does not offer yet an option of the sort You have 4 partitions mounted, shall I unmount them all? but this can be done latter. b. The user should not be confronted with information on power-off; a power-off should be attempted when the last partition of a device has been unmounted. That appears to be the case in Win/OSX. c. Sending the STOP command appears not to work for some external USB devices. I think it should be ok to try it anyway after the last umount of a partition. An alternative to sdparm is sg_start --stop /dev/sdX. d. Sending STOP to a flash drive can switch off the indicator light, which is nice feedback to the user that they can unplug. You just solved one of the mysteries in my friend's linux desktop. Nice idea btw. :P As a user who recently got an external hard drive failure (had to throw it away) and whose replacement hard drive has already started showing some signs of failure, I wonder if unmounting an external USB hard drive but not sending a STOP command is harmful for the safety of the disk by preventing the disk from parking, thereby making it more prone to damage during travel. If so, then please treat the need for STOP command as something serious, not just a power saving feature; thanks. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
On Qui, 2007-12-27 at 19:20 +0100, Sven Herzberg wrote: Am Donnerstag, den 27.12.2007, 11:52 +0100 schrieb Xavier Claessens: Le lundi 24 décembre 2007 à 12:48 +, Gustavo J. A. M. Carneiro a écrit : I would just like to say that I am concerned about telepathy storing unencrypted passwords in GConf instead of GnomeKeyring. GNOME modules should be taking security more seriously, IMHO. It is not empathy's responsibility to store account parameters, MissionControl does that job but unfortunately it does not uses gnome keyring :( I think we shouldn't bless any external dependency that introduces new security risks (by having to replicate features already existing in GNOME). So until libmissioncontrol uses gnome-keyring for password management, I say -1. Agreed. Come on, it's not like GnomeKeyring API is so complicated. Coding this will take the developers no more than a couple of hours, including the time to read the API docs. Same goes for Evolution. It's kind of silly that they had GnomeKeyring support for a while, but then just dropped it. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
I would just like to say that I am concerned about telepathy storing unencrypted passwords in GConf instead of GnomeKeyring. GNOME modules should be taking security more seriously, IMHO. On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: Homepage: http://live.gnome.org/Empathy svn/git/bzr/...: http://svn.gnome.org/viewcvs/empathy/ Proposal on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00301.html Short description: == Empathy consists of a rich set of reusable instant messaging widgets, and a GNOME client using those widgets. It uses Telepathy and Nokia's Mission Control, and reuses Gossip's UI. The main goal is to permit desktop integration by providing libempathy and libempathy-gtk libraries. libempathy-gtk is a set of powerful widgets that can be embeded into any GNOME application. Requires new external dependencies: === libtelepathy, telepathy-glib, libmissioncontrol (libtelepathy will go away at some point in the future) Summary so far: === + a few -1 from people thinking it's useless duplication of pidgin/ekiga/etc. work or not wanting to use telepathy + some +1 from people thinking it's going the right way + questions about stability + questions about feature set that might not be complete yet + API documentation needed to be written (I don't know the current status) + no API stability guarantee yet + current license of the libraries is GPL [context: if the libraries are proposed for the platform later, they will need to be LGPL] Xavier can probably send an update about the feature set, the API doc status, and the license. Vincent -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: cheese
On Thu, 2007-12-20 at 13:17 +0100, daniel g. siegel wrote: On Do, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: Homepage: http://www.gnome.org/projects/cheese/ svn/git/bzr/...: http://svn.gnome.org/viewcvs/cheese/ Proposal on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00289.html Short description: == cheese is a photobooth-inspired GNOME application for taking pictures and videos from a webcam. it also includes fancy graphical effects based on the gstreamer-backend. further releases will include conduit support for exchanging pictures and videos and some opengl-love to speed things up hey you stole that! ;) Summary so far: === + there used to be a build system issue (and intltool integration issues), but it now uses waf or autotools exactly, you can find both waf and autotools in the src-tree and everyone can use his favourite. unfortunately, just autotools is supported by jhbuild at the moment. jhbuild now supports waf: http://bugzilla.gnome.org/show_bug.cgi?id=503907 -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Suggested even/odd convention for the micro version numbers (like cairo)
On Ter, 2007-12-11 at 10:37 +0200, Tor Lillqvist wrote: I humbly suggest that the versioning recommendation for the GTK+ stack and GNOME in general is amended for the third micro part of the version numbers to match the convention used in cairo. See http://cairographics.org/manual/cairo-Version-Information.html . In a nutshell, the idea is that released tarballs have an even micro version. The micro version is bumped both immediately before and after building the release tarball. The even micro number is never committed to SVN. In SVN the micro number is always odd. This has the advantage that there is never any confusion whether pre-release or post-release bump is used. Code from a SVN checkout can always be recognised by its odd micro number, and correspondingly code from a released tarball is recognised by its even micro number. One could imagine a module using a macro FOO_IS_DEVELOPMENT_VERSION() that would return true either if 1) the minor version is odd (as the convention already is in most (?) GNOME modules), or 2) the micro number is odd (a build from SVN, presumably thus intended for local hacking and not distribution). I guess one disadvantage of this is that it might take a time before people stop asking what happened to version x.y.z. Also, one probably needs to script the bump-make dist-bump sequence in order not to forget it, at least initially. I think the use of this convention is regarded as a success by people working on cairo? This sounds like a good idea. Another idea that you may consider is what I came up with for a project of mine (pybindgen), where the version is: - X.Y.Z, for stable releases; - X.Y.Z.W, for bzr snapshots, where X.Y.Z is the latest release before the snapshot, and W is the bzr revision number. For instance, at the release time the version may appear as 0.8.0, but when I commit something after the release the bzr version appears as something like 0.8.0.214. Looking at 0.8.0.214 it becomes easy to see that it is a bzr version which comes right after the official 0.8.0 release. But, anyway, your idea is simpler to implement[1], and probably good enough... [1] although in my case the version numbering is derived automatically by a hook: the 0.8.0 part comes from the nearest bzr tag, while the 214 is the current 'revno'. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-keyring has SSH, X.509 certificate and key support
On Ter, 2007-12-04 at 16:38 +, Bastien Nocera wrote: On Tue, 2007-12-04 at 16:28 +, Stef Walter wrote: Bastien Nocera wrote: On Mon, 2007-12-03 at 19:47 +, Stef Walter wrote: However I'm not sure of the correct autovoodoo to remove the soname and libtool la file. The Makefile.am file is here: http://svn.gnome.org/viewvc/gnome-keyring/trunk/pkcs11/Makefile.am?view=markup Remove the useless -version-info. Removed it. Although it still seems to default to 0.0.0 and removing it has seems to have no effect on the files created. :/ And add -avoid-version. Don't forget -module. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WAF (Was: build tools)
On Mon, 2007-12-03 at 07:48 +0100, Jaap A. Haitsma wrote: On Dec 2, 2007 11:46 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: In case anyone is interested, feel free to try out a 100% WAF-ied version of gnome-python: http://www.gnome.org/~gjc/gnome-python-2.21.0.tar.bz2 The WAF based tarball (including a self contained waf script, which is all you need to build) is 249K, while an autotools version is 424K. I could reduce the size even more if I removed configure.ac and the Makefile.am's. It also builds much faster, especially if you count the ./autogen.sh part, though I didn't to get actual numbers. When I have some more time I will see about making jhbuild use waf, to get people testing this new system. Later, if no serious problems or objections are found, I would like to switch to it. Cheers, PS: try the '-p' waf option for greater eye candy effect. Gustavo and others, In order to try out waf for your project you can have both autotools and waf build support in SVN. We did this for cheese [1]. I believe also gnome-package-kit and package-kit have this For waf you just need the waf script in your main project directory and wscript or wscript_build in all directories You will need waf from SVN to have correct localization report. You have to do the following svn checkout http://waf.googlecode.com/svn/trunk/ waf cd waf ./waf-light --make-waf And don't forget --strip, for a smaller waf :) Copy the resulting waf script to your project directory Jaap, I am well aware of this, but I am not committing a WAF script to each project repository is the best way to go. Each script is 100KB semi-binary file. Every time I update WAF I would need to essentially add 100KB to the repository. Perhaps it's better to just make jhbuild checkout WAF from svn. and then right the necessary wscript files. You can look for examples on what to put in the wscript files in the demos directory of waf or look at existing projects with waf support such as cheese. It would be great if more GNOME projects would try waf. This way we can see if it is feature complete for GNOME support. Jaap [1] http://svn.gnome.org/viewvc/cheese/trunk/ -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WAF (Was: build tools)
On Mon, 2007-12-03 at 11:43 +, Alberto Ruiz wrote: 2007/12/2, Elijah Newren [EMAIL PROTECTED]: On Dec 2, 2007 3:46 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: In case anyone is interested, feel free to try out a 100% WAF-ied version of gnome-python: http://www.gnome.org/~gjc/gnome-python-2.21.0.tar.bz2 The WAF based tarball (including a self contained waf script, which is all you need to build) is 249K, while an autotools version is 424K. I could reduce the size even more if I removed configure.ac and the Makefile.am's. It also builds much faster, especially if you count the ./autogen.sh part, though I didn't to get actual numbers. Ooh, I'd love to see timing numbers. The size differences are pretty impressive; it would likely make a noticable impact on times for building releases for garnome users, release team members, and others. Anyone want to cook up a patch for libwnck/metacity so I can see how quick and small it is on my module(s)? (Hey, if I'm too lazy to deal with autotools for my modules and almost always delegate it, I can also be too lazy to deal with any other system, right?) I might try. So far, libwnck looks pretty simple, except for the glib-mkenums which seems to call a lot of shell commands. What's exactly glib-mkenum used for? (I kind of guess from the name, but I would like to have more background of the problem that it solves). Does anyone has done this mkenum thing with waf already? I never used it (don't need it) but I think it is in waf already. PackageKit uses it. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WAF (Was: build tools)
On Mon, 2007-12-03 at 16:15 +0100, Daniel Svensson wrote: On Dec 3, 2007 4:03 PM, Daniel Svensson [EMAIL PROTECTED] wrote: On Dec 3, 2007 3:51 PM, Ross Burton [EMAIL PROTECTED] wrote: autoconf has standard support for running tests on the local machine for example to determine the word size, if the networking layer supports Ah, ofc runtime checks. Not sure actually. Haven't used it thanks to glib hiding low level stuff like that from me ;). I suggest you drop a mail to the waf-list instead, or join #waf @ freenode. That is definatly something required to build something like GLib. If such checks aren't possible yet with control host-target, it's definatly something that should be filed as a bug. http://code.google.com/p/waf/issues/list I honestly don't see the point of supporting runtime tests with cross compilation in the build tool. I mean, the most that the tool can do is give an error message saying the test cannot be run. How will that help? And how does autoconf get away with it? Last I checked, autoconf just gave an error message; but then how do people do cross-compilation if some tests cannot be run? -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
WAF (Was: build tools)
In case anyone is interested, feel free to try out a 100% WAF-ied version of gnome-python: http://www.gnome.org/~gjc/gnome-python-2.21.0.tar.bz2 The WAF based tarball (including a self contained waf script, which is all you need to build) is 249K, while an autotools version is 424K. I could reduce the size even more if I removed configure.ac and the Makefile.am's. It also builds much faster, especially if you count the ./autogen.sh part, though I didn't to get actual numbers. When I have some more time I will see about making jhbuild use waf, to get people testing this new system. Later, if no serious problems or objections are found, I would like to switch to it. Cheers, PS: try the '-p' waf option for greater eye candy effect. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: strawman (Was Re: build systems)
On Seg, 2007-11-12 at 12:42 +0100, Nicolas Trangez wrote: On Mon, 2007-11-12 at 12:32 +0100, Ali Sabil wrote: I think we should really investigate WAF Partially agree, if it gets a lot of love. Been working on the clutter port some more, here's some more thoughts: - If you add an include directory which does not exist (eg '../foo' which should be just 'foo'), waf bails out with some completely not-useful message (a Python IndexError?!?), not pointing you to where the mistake could be. Pretty frustrating. - Currently, build just does not work. I have no clue why it doesn't as I get no error messages whatsoever, it doesn't even start a compiler. I start waf and it sits there. Running with -v, -vv or -vvv doesn't give any usable output either. When running it through strace, it first does some open calls etc, then makes hundreds of brk() calls (well, I guess Python does it :-)). No clue what's going wrong. So, it most certainly needs more exception checking and usable error messages if something goes wrong. Yes, it's true. WAF needs some love in the input validation and error reporting department. Good news is that it is fixable (as in, does not take a huge ammount of effort, and waf has a maintainer willing to take patches, unlike another build system I know of). I fixed the compilation unit separation using shared libraries, I didn't check yet whether they would be installed in the end, as they shouldn't. Need to figure this out (once build works again). There are some strange things in waf too: - If you want to include clutter/pango/clutter-pango.a in the build of clutter/libclutter-glx-0.5.0.so, you need to add clutter-pango to the obj.uselib_local variable, not pango/clutter-pango, as I would have expected. You have to understand something. WAF works with build objects which are defined by a name (object name defaults to the target if not given). Object names are not hierarchical and have no relationship whatsoever with the build tree. This is a good thing because it allows WAF much more freedom to schedule object build tasks in parallel, unlike make which can only parallelize tasks within a single subdirectory. So, unlike make, waf -j2 on a dual core processor really uses both processors most of the time, while make -j2 will often have to wait for a subdir to finish building before moving on to the next subdir. Yes, this also means documention could be improved. But anyway, autotools also have tons of undocumented quirks; the only difference is that developers used to autotools have already learned those quirks. - Sometimes Python type usage is rather strange. During configure, conf.env behaves like a dict (conf.env['foo'] = 'bar'), whilst in a build function, bld.env is a function returning something which behaves like a dict (so need to use bld.env()['foo']). Rather confusing. Agreed. But I think also fixable, since WAF API is not exactly frozen ;-) Cheers, -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: build systems
On Sat, 2007-11-10 at 22:43 -0500, Braden McDaniel wrote: On Fri, 2007-11-09 at 12:27 +0100, daniel g. siegel wrote: [snip] please understand, i dont want to bring up a autotools is bad and it should die-thread, i just want to use my time to code and not to use that time and effort on a build system. It is a fact of life in software development that build systems for nontrivial projects are themselves nontrivial. Regardless of what build system is in use, it is simply unrealistic to expect that you should be insulated from it. An extremely powerful feature that you get for free with automake is make distcheck. The distcheck target builds a distribution, compiles it, runs tests (make check), installs it to a staging area, runs tests on the installed programs/libraries/whatever (make installcheck), and, if all that succeeded, declares your distribution Ready. I coded distcheck into WAF a couple of months ago. It wasn't even a difficult task... Cheers, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
On Qui, 2007-11-01 at 14:15 -0400, Hubert Figuiere wrote: On Thu, 2007-11-01 at 13:57 -0400, J French wrote: I hate OOo with a passion. It may be fine for Windows, but so many other applications are better under Linux. I was hoping there was something GTK-based for this as well. OOo is Gtk based for several years. This is not true. OOo only uses Gtk themes, not Gtk widgets. Big difference. Like the difference between firefox and epiphany. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
: the OSD that is shown when you press your volume-up/volume-down keys; the mixer applet; and gnome-volume-control. The OSD is supported fine through gst-pulse (our rocking PA plugin for gst), but for the applet and the standalone mixer i'd like to see a replacement. Right now both use the gst mixer abstraction API, which only exposes a very limited set of what our PA mixer can do and which quite frankly is a big mess. We'd have two options here: fix the gst mixer api, so that it exports the whole functionality that PA offers. Or, just make the mixer depend directly on the PA libs. I'd vote for the latter. Why? Because abstraction APIs in most cases suck, and especially if a large part of the API is only implemented in a single backend (which would be PA). That's why in F9 we will probably drop g-v-c and replace it with pa's specific mixer tool called pavucontrol, that we already ship. (I mentioned this already above). So, what I'd like to see is that pavucontrol could become a part of GNOME proper eventually, and for that to work PA would need to become a blessed dependency. While I see not much worth in developing two volume control tools in parallel, we could even keep g-v-c around for those who prefer to stick with their bare 90s-style audio systems. (Ronald, Gustavo, that's again where you should rejoice). The question of course remains, which mixer app to maintain in GNOME. My own pavucontrol is quite featureful, but I think it's not the best thing UI-wise (though some people seem to disagree with me -- and do like it). I'd be happy if someone would pick this up. If noone picks it up, I will probably hack up some pa-specific applet and stick it together with pavucontrol in GNOME SVN, and then suggest it for inclusion into GNOME proper. So far my plans. When we have dealt with these three issues, GNOME should work fine on both PA and without PA. Will take some time to implement them all. But I hope that even people like Gustavo and Ronald can live with it. Oh, and I hope that my comments on Gustavo's and Ronald's position didn't sound too harsh. It's just that I consider your positions badly-informed and a bit FUDish, it's not intended to be personal. Any questions? Yours, the stubborn Lennart -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Thu, 2007-10-11 at 20:31 +1000, Jan Schmidt wrote: quote who=Ronald S. Bultje Daemons for sound routing are not just suboptimal, they are wrong. We have better ways (at least on Linux) nowadays. Any solution based on the idea of a userspace daemon is wrong. Not just suboptimal (which is unacceptable, because ALSA directly is - for Linux users - very much so optimal, and that's 90% of your userbase), not just still somewhat acceptable (because it isn't, we've ditched esound for that very reason) and definitely not required because a small subgroup of your user population needs it (crippling for the sake of network users - yeah right). I get so sick of people saying but I don't *want* a sound daemon, ALSA can do it all!. It's so irritating because ALSA's solution for mixing on the vast majority of modern sound hardware is to have to use dmix, and *dmix is a sound daemon* - it's fundamentally doing *exactly* the same thing that pulseaudio does, except that it forks whichever process happens to open the audio device first instead of being an explicit separate binary. You are mistaken. ALSA dmix does not require any daemon. I suspect it uses SYSV IPC to make all processes do some kind of distributed mixing, with no daemon required. Plus, it traditionally hasn't even done a very good job of being a sound mixer. It does crappy resampling, gives poor feedback on the number of unplayed samples and drops out just as much as a normal sound daemon because it's just a process with normal privileges - all problems that PulseAudio doesn't have when configured correctly (configured so that it can obtain realtime privs, that is). Even if dmix is buggy, why can't it be fixed instead. And not to mention that even my desktop PC with ultra cheap motherboard has builtin sound which supports hardware mixing. I am pretty sure I'm not using any kind of software mixing at the moment: neither dmix nor esd nor pulseaudio. I just think that, by default, users should be given a chance to experience audio with hardware mixing, if the hardware supports it. But most importantly, I wouldn't mind PulseAudio too much *if it worked correctly*. As it is now, maybe it isn't PA's fault, maybe it's the linux kernel's fault for not having a good enough process scheduler, but the sad truth is that PA's sound skips (I mean I hear audio clicks when switching workspaces). I believe when people say it doesn't skip for their hardware, but I expect people to believe me when I say it does skip for me. And of course there's the things the PA can do that bare ALSA never will: * Sample caching * Low latency per-process volume control. * Graceful handling and policy for on-the-fly device removal and insertion Those are nice features, but all summed together they don't come near to skipless sound that raw ALSA provides. * Decent OSS emulation that doesn't cut software-mixing out of the loop OSS is deprecated. * Drop in esd replacement for backwards compatibility. I already do not use esd. And last, and actually one of the minor features: networked audio. That should be an extra layer *on top of* basic sound, not a replacement layer. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Ter, 2007-10-09 at 09:49 -0400, Matthias Clasen wrote: On 10/9/07, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: I am not saying Pulse Audio has these problems. I simply don't know That can easily be helped. Just try gnome 2.20 with pulseaudio in Fedora 8. It works beautifully. I just tried pulseaudio 0.9.6 on Ubuntu Gutsy, and: - Audio stuttering increased dramatically. Most of the time, when I hide/show the rhythmbox window, or when I switch to another workspace (metacity), I hear a very annoying gap in audio. The same thing with ALSA direct hardware access works perfectly with no audio gap; - I noticed when trying to switch RB back to use direct ALSA that the pulse audio server is still using the annoying behaviour of locking the sound device. I had to do killall pulseaudio before I could switch back to direct ALSA sound. And once you tried, you don't have to spread FUD anymore... I tried and I'm still not convinced. Unless there are some special kernel patches in fedora making a big difference, I still hate sound routed through a userspace daemon. I would willingly tolerate it for sound coming from network applications, but it's not a price I want to pay for simple local applications when I don't care about PNP or network sound. IMHO Pulse Audio developers are just being stubborn; I have not yet any good reason why PA and direct ALSA access cannot get along. I'm sorry for being the bad guy here, but someone has to say these things... -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
On Ter, 2007-10-09 at 01:17 +0200, Matteo Settenvini wrote: Il giorno lun, 08/10/2007 alle 23.19 +0100, Gustavo J. A. M. Carneiro ha scritto: Last time I tried PulseAudio (over a year ago) it hogged the sound device and did not let any other ALSA client produce sound. Can someone confirm the bug is still there? Just (e.g.) play some music with PulseAudio and then start an ALSA client, check that mixing is being done. If the bug is still there then I would not recommend anyone using PulseAudio. Unless you want to see for example your flash plugin sound to stop working, like it didn't usually work in the old days when it used OSS API. Pulseaudio can do much better than dmix in my opinion. The only thing you need is to tell alsa to use pulse as pcm.!default and ctl.!default, after having installed the relative ALSA plugin. The ALSA plugin is quite stable and works well for me. As for Macromedia Flash 9, it is well known it is a buggy proprietary software with quite a lot of problems. People jumped at it, anyway, and now Pulseaudio has an extra library you can install to have Flash working seamlessly. Much better than with ESD, imho. I don't care only about proprietary applications. You think for example that Second Life Linux client (which is open source) will use Pulse Audio API directly? It will take years before that happens. I remember perfectly well how much time it took for applications to switch from OSS to ALSA, after Linux declared ALSA the official blessed Linux sound API. I loved Pulse Audio when I tried it, but when I noticed it blocked the audio device I immediately had to stop using it. It's good that there's an ALSA plugin to redirect sounds to the Pulse Audio daemon, although I must confess it doesn't sound entirely satisfactory. Why be forced to use a userspace mixing program when hardware mixing would work equally well (or better) in most situations? Non-network audio should not need to be mixed by Pulse Audio on Linux, IMHO. Is there any good reason why Pulse Audio explicitly locks the audio device, unlike any other normal ALSA client? And no, making every app use Pulse Audio by force, just because you can, is not a good reason. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pulseaudio
Last time I tried PulseAudio (over a year ago) it hogged the sound device and did not let any other ALSA client produce sound. Can someone confirm the bug is still there? Just (e.g.) play some music with PulseAudio and then start an ALSA client, check that mixing is being done. If the bug is still there then I would not recommend anyone using PulseAudio. Unless you want to see for example your flash plugin sound to stop working, like it didn't usually work in the old days when it used OSS API. On Mon, 2007-10-08 at 22:26 +0200, Matteo Settenvini wrote: Hi, I'm new to this list, so sorry if I ask something already discussed. It has been a while since esound has received some attention - releases are almost stalled. Looking at the GNOME wiki, it seems that Pulseaudio is the stronger candidate between alternatives, and that it allows for quite a lot of nifty things. I'm running pulseaudio since four or five months now on two of my desktop systems, both x86 and PPC, and I must say that I'm really satisfied by it. It's quite stable and has very few compelling bugs for the normal user (e.g. when using it as an esound replacement on a machine with more than a logged in user it doesn't share the esd socket, or similar). It also seems to be actively developed, and is shipped by default with Fedora 8. Can it be eligible for inclusion in GNOME 2.22? Thanks for any answer, -- Matteo Settenvini FSF Associated Member Email : [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d--(-) s+:- a-- C++ UL+++ P?++ L+++$ E W+++ N++ o? w--- O- M++ PS++ PE- Y+++ PGP+++ t+ 5 X- R tv-- b+++ DI+ D++ G++ e h+ r-- y? --END GEEK CODE BLOCK-- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ 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 Seg, 2007-09-17 at 10:49 +0100, Emmanuele Bassi wrote: On Mon, 2007-09-17 at 11:36 +0200, Sebastien Bacher wrote: Le samedi 15 septembre 2007 à 18:19 -0400, Behdad Esfahbod a écrit : Of course no project using git maintains ChangeLog. Why? You could update the ChangeLog when commiting changes on git what's the point? a ChangeLog is useful for people that do not have access to the repository and to the history of the project. if you clone a git repository you have the full history, with the ability to see each commit complete of a diff and a summary (this is also why listing all the functions that have been touched by the commit is pretty much useless). It should also be emphasized that maintaining a ChangeLog file under version control *gets in the way* of branching and merging. That little detail seems to ellude everyone's grasp, for some reason. Having a ChangeLog file under version control not only means that you have to duplicate information in every commit (once in changelog, once in commit log message), but also that you will almost always get conflicts when merging branches. The ChangeLog therefore throws away one of the biggest advantages of DSCM, which is not only offering decentralized source control, or very fast commits, but also much more intelligent branching and merging when compared to CVS or Subversion. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ 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. The problem is that centralised RCSs make it hard (no network, or network lag) to make commits of small changes. As a consequence, developers are compelled to bundle many changes into a single commit, and the commit log message has to mention all changes. After that, even if you want to generate a decent ChangeLog from commit messages, it is very hard to produce a good looking ChangeLog since people use free-style commit messages with multiple bulleted items... In a non-GNOME project of mine [1] I use bzr and I autogenerate the ChangeLog from bzr commit logs. For obtaining a good looking gnu-style ChangeLog I developed my own bzr log plugin [2], with great results. This plugin is even smart enough to generate release markers (=== X.Y.Z ===) at appropriate places based on bzr tags. In fact, even the project version string is obtained from bzr tags, so when I want to make a release I just write NEWS, commit, then do something like bzr tag 0.7.0. Afterwards, the generated dist tarball will contain the version 0.7.0. With the ChangeLog file out of version control, and no need to manually change the project version, branching and merging is a piece of cake. :-) The only downside is that your changelog loses information regarding functions and methods changed, unlike the manual changelogs (especially if you use C-x 4 a under emacs). Although, in theory even that could be automated, but it would require looking at the diffs of each commit and source code analysis to determine the changed functions. Anyway, I can easily live without a list of changed functions. And since each changelog entry has a revision number, interested parties can fire up bzr viz and look at the diff themselves. [1] https://launchpad.net/pybindgen/ [2] http://telecom.inescporto.pt/~gjc/gnulog.py -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ 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 Qua, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: 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. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. I don't completely agree. Personally, I have a GNOME SVN account but I still want to use DSCM. It's not at all related to giving more power to 3rd party contributors (although I admit it's an advantage). It's about giving more power to _us_ GNOME developers. For me, it's about: 1- Getting rid of ChangeLog and instead do lots of micro commits and then using whatever log --format=GnuChangeLog ChangeLog 2- Really Fast commit and history vizualization without network lag; 3- Branching and merging that works correctly out of the box a) without having to learn to use band-aid tools like svnmerge b) without having to deal with conflicts in the ChangeLog file, since it is generated from log messages; 4- Oh, in one of my projects[1] I even got my package to automatically derive its own version number from the last tag registered in the branch, so that I only have to tag the source tree and make a release tarball, not update some version string in some file; how cool is that? ;-) [1] https://launchpad.net/pybindgen -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ 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 20:28 +0100, John Carr wrote: On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: 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. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? If a developer wants to use e.g. bzr, he can use it behind the scenes, but: 1. With a manually written ChangeLog file, you can't easily branch and merge even with bzr, or you can but every time you merge you'll get conflicts in the ChangeLog file; 2. Unless the bzr branch is official, you can't get rid the manually written ChangeLog file because you have to support svn users who can't easily do micro commits (due to network lag) thus need a ChangeLog file to work around this limitation; 3. It is unthinkable to make a bzr branch official branch for a project unless it's hosted in a GNOME server; 4. To host a bzr branch in a GNOME server you need official support from the GNOME admin team because: a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not appropriate for that, or so they tell us; b) You need to allow multiple commiters to the same user-neutral branch; c) you need to run a bzr smart server on the server side or else network performance is going to be rather bad. Bottom line, unless GNOME supports a DSCM, it kind of works, but things will never go very smoothly and developers will not take full advantage of the DSCM. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ 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 21:40 +0100, John Carr wrote: On Wed, 2007-09-12 at 20:47 +0100, Gustavo J. A. M. Carneiro wrote: On Wed, 2007-09-12 at 20:28 +0100, John Carr wrote: On Wed, 2007-09-12 at 10:13 +0300, Kalle Vahlman wrote: 2007/9/11, Bryan Clark [EMAIL PROTECTED]: 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. I'm not looking to argue the features of one DSCM above another or what we have now, but really the controlling of the source code isn't the problem this DSCM debate is circling. The problem which prompted this debate again was the infamous SVN accounts lag. DSCM allows people to comfortably work with their repo and easily get a subset of their current work to a patch for submitting to eg. bugzilla. Currently, you'd need to take a checkout for each line of work you start unless you want to backup your work manually with svn diff (urgh). Not so hot, specially since if you are not on the net all the time. If you can comfortably work without access to the central repo, the need for the access becomes less of an issue. Thus helping people keep patient with the accounts lag, possibly even making it unneccessary for some. So, in my opinion, GNOME does need DSCM as a *part* of the solution for the current problems. Both Git and Bzr have svn interoperability. Are these implementations so broken as to not be useable by the DSCM-desiring people? I've had a quick play with bzr-svn and it feels like quite a natural step up from svn. It has the advantage that people who want DSCM get it, it doesn't involve learning lots of new commands (very similar to svn commands wise). And of course, for those of us that don't need it, we don't have to use it. Finally, no infrastructure changes are needed to take advantge of it either. I presume the same is true with git-svn, thus avoiding git/bzr wars? If a developer wants to use e.g. bzr, he can use it behind the scenes, but: 1. With a manually written ChangeLog file, you can't easily branch and merge even with bzr, or you can but every time you merge you'll get conflicts in the ChangeLog file; 2. Unless the bzr branch is official, you can't get rid the manually written ChangeLog file because you have to support svn users who can't easily do micro commits (due to network lag) thus need a ChangeLog file to work around this limitation; 3. It is unthinkable to make a bzr branch official branch for a project unless it's hosted in a GNOME server; 4. To host a bzr branch in a GNOME server you need official support from the GNOME admin team because: a) hosting on www.gnome.org/~user/ ? Nah.. www.gnome.org is not appropriate for that, or so they tell us; b) You need to allow multiple commiters to the same user-neutral branch; c) you need to run a bzr smart server on the server side or else network performance is going to be rather bad. Bottom line, unless GNOME supports a DSCM, it kind of works, but things will never go very smoothly and developers will not take full advantage of the DSCM. I don't see the problem with creating your Changelog and attaching it to the revision log with svn ci -F SomeChangelogFile. With this you can build up a revision log message as you go. And your changelog data is now in the revision log (where it belongs IMHO) and doesn't conflict anymore. Pretty easy. It's not the same. You don't want your ChangeLog messages to have bulleted items including a list of changed files, because if you do that then when you generate a full ChangeLog from the stored commit messages things will appear all unaligned. Once the Changelog is removed, or no longer updated, this argument goes away. Like I tried to explain, no maintainer will want to give up on manually written ChangeLog files because: 1- bundling lots of changes in a single commit log message will make the generated changelog look really bad; 2- not bundling lots of changes in a single commit log message implies making lots small commits (i call it micro commits), which is very slow with subversion due to network roundtrips. So what other problems are there with bzr-svn / git-svn? Cloning from svn to bzr (or git or whatever) takes ages, so you want to have an official bzr branch version of your project to make branching fast and easy for everyone else. Hence you want hosting of bzr branches in a GNOME server, and all my remaining reasons still apply. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http
Re: quick question regarding bonobo-activation-server-ior file
On Dom, 2007-09-02 at 13:09 +0100, Gustavo J. A. M. Carneiro wrote: On Sáb, 2007-08-25 at 10:39 -0700, Gabriel M. Elder wrote: My apologies if this is the wrong list. Would someone be so kind as to tell me what executable and/or library is responsible for handling the corba object reference file /tmp/orbit-$USER/bonobo-activation-server-ior that gets created when a user starts a gnome desktop session? I'm assuming that this would be a higher-level executable calling bonobo and/or orbit library functions. I'm looking for the program responsible for handling this file during the login process, where it creates the file if it doesn't exist, and where it decides to read in the file if it does (to retrieve the object reference). BTW - what is the relationship between this object reference and the X virtual terminal number/assignment, and whence is this relationship/association established and stored? Is it stored in the bonobo-activation-server-ior file itself, or is it handled by ORBit and/or bonobo? OK, so maybe these weren't such quick questions after all... But it'd be a real time-saver and a big help if someone would answer these. If you answer on this list, or prefer that i redirect my question elsewhere, please also cc: my personal email account, so i get the message right away. Gabiral, quite simply /tmp/orbit-$USER/bonobo-activation-server-ior is created when bonobo-activation-server is started, which is a daemon that is automatically launched the first time a bonobo-activation API is called by any bonobo client. It really could be just about any program, but most likely the first bonobo client to use bonobo is probably gnome-session; if not, gnome-panel or nautilus are other likely candidates. I forgot to answer some questions. There is no relationship at all between bonobo-activation-server and an X session; bonobo-activation-server sometimes even keeps running after your X session ends. The code that launches bonobo-activation-server is in libbonobo/bonobo-activation/bonobo-activation-fork-server.c. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ 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 Sex, 2007-08-31 at 19:55 +0200, Olav Vitters wrote: On Sun, Aug 12, 2007 at 01:55:35AM +0200, Olav Vitters wrote: On Wed, Aug 08, 2007 at 12:36:28AM +0200, Olav Vitters wrote: Note that the userid is really important. Otherwise ensure that the E-mail address is the one your @svn.g.o alias forwards to. I've made an pre-commit script which detects if a module has a valid /trunk/MAINTAINERS file. This currently isn't activated, however I might do this in future. This has now been enabled. Means you cannot commit to modules without a proper MAINTAINERS file. The rejection message points to an URL explaining this. It is not nice to do this like this; you should make the pre-commit script give only a warning, for a few months, but still allow commit. Only after the warning period should commit be denied. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic -- Frank Herbert ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Qui, 2007-06-21 at 23:39 -0300, Johan Dahlin wrote:
Joseph Sacco wrote:
The currently available version of pygtk is the stable branch. I would
expect the development branchof pygtk to adapt.
I'm ready to adapt but only if the general consent is that API changes
are okay.
My personal opinion is that the API shouldn't be allowed to change, once
an API is added it should stay stable until the major version is bumped
(3.0 in the case of gtk+).
I'm 100% with Johan on this one. Gtk+ 2.11.x broke API and ABI.
Before 2.11.x, the structure is:
struct _GtkTooltips
{
GtkObject parent_instance;
GtkWidget *tip_window;
GtkWidget *tip_label;
GtkTooltipsData *active_tips_data;
GList *tips_data_list;
guint delay : 30;
guint enabled : 1;
guint have_grab : 1;
guint use_sticky_delay : 1;
ginttimer_tag;
GTimeVal last_popdown;
};
None of these fields is marked private, therefore they are public.
Public fields are part of the API and cannot be changed as per GNOME
Developer Platform. Probably there is a way to introduce the new
tooltips without having to break the old tooltips API!
Just because pygtk _can_ adapt doesn't mean that it _should_.
In fact there are at least a couple of other changes in gtk+ 2.11.x that
break the API; we should really be more careful about these things...
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
The universe is always one step beyond logic. -- Frank Herbert
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop sounds in Gnome
On Seg, 2007-03-19 at 17:48 +, Richard Hughes wrote: On 19/03/07, Étienne Bersac [EMAIL PROTECTED] wrote: So, will gnome 2.20 play nice sound when disk is burn, sound volume increased, mail received/sent, new RSS item available, etc. ? Would the system sounds be themable like icons are ? It would be great to theme these like we can icons. gnome-power-manager just needs to play a battery low chime, and linking to gstreamer seems very heavyweight. I think we need three things: * A system sounds freedesktop standard (ala, tango) * An easier way to plug in configuration to the existing sound capplet * A sound server that works, i.e. works with the user theme, and we can just play (low-power); How many of these things already exist and are usable in one form or another? We also need said sound server to not suck. On Linux systems it must 1) use ALSA, and 2) work well with dmix and allow other applications (e.g. flash plugin) to use ALSA directly. Pulse Audio at least doesn't qualify for the second point. Esound doesn't qualify for either. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.20 Python version
On Qua, 2007-03-14 at 13:18 +0200, Fernando Herrera wrote: On 3/14/07, Murray Cumming [EMAIL PROTECTED] wrote: On Tue, 2007-03-13 at 12:52 -0500, Shaun McCance wrote: If a program works correctly with Python 2.4, is there actually a danger of it not working correctly with 2.5? That sounds broken. Python 2.4 and 2.5 install in parallel so already-built applications will not be broken. In the past, when we included python 2.4 in the jubuild bootstrap module I had lot of problems when building/running python programs on FC. I think that different compilation options resulted in binary incompatible python modules (some UCS size or something like that) 1) when running my jhbuild session, trying to run a system python program like yum didn't work, because it was using python from jhbuild and tried to load a module (.so) from system python, that where incompatible 2) For building some apps under my jhbuild environements I had to compile a lot of external python modules to make the app build, because python from jhbuild refused to use my system dir modules. Some of them were pyrex, twisted, numeric, etc... So, questions: a) Is the binary incompatibility depending on configure options stills present? Yes, but that has nothing to do with different python versions, just different python builds. b) if yes, could we build python 2.5 in jhbuild autodetecting and matching system python configuration? It could be done; just remove python from the bootstrap modules (and let people remove any /opt/gnome-devel/bin/python* that they have, or whatever). But then people have to define PYTHONPATH correctly. Or let jhbuild shell/run do it.. Personally I prefer to have a custom built python, for better debugging. But I would understand if people want to use the system python instead. In fact, using the system python by default would allow GNOME to be tested with multiple Python versions at the same time; I think it may be a very good idea just because of that... -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.20 Python version
On Ter, 2007-03-13 at 09:42 +0100, Loïc Minier wrote: On Mon, Mar 12, 2007, Gustavo J. A. M. Carneiro wrote: I'd like to suggest updating jhbuild to install Python 2.5 instead of 2.4 for GNOME 2.20, because: * I don't think Python 2.4 will continue to be maintained; * Distributions that will receive GNOME 2.20 will most likely make python 2.5 the default (ubuntu already does for GNOME 2.18); * We could really use the testing of GNOME on Python 2.5, especially on 64-bit systems. My understanding is that you're trying to do some Python QA in the jhbuild moduleset, but what's the point of testing Python in GNOME? Shouldn't the focus be on the GNOME stack instead of its dependencies? My point is to test GNOME modules when built against (or running on top of) Python 2.5. As you know, the Python API for extensions changed substantially for python 2.5 and amd64, and I'm tired of always being the one to find all the bugs in extensions derived from this change because not many people seem to test GNOEM modules with Python 2.5 in a 64 bit system. (While we're at it: Debian still has Python 2.4 as default.) When the time comes for Debian to receive GNOME 2.20 packages, do you expect it to still be using Python 2.4, considering that Python 2.4 is already now deprecated upstream? -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.20 Python version
On Ter, 2007-03-13 at 16:57 +0100, Loïc Minier wrote: On Tue, Mar 13, 2007, Elijah Newren wrote: Unlike GNOME and Linux, Python does not use odd version numbers for development versions. Thus 2.5 is the latest production version of Python, rather than the latest development version. I know 2.5 is a stable release; my point is that this needlessly raises the bar to build GNOME: anyone is free to build GNOME with whatever version of libc6, gcc, or python that one wants to catch some bugs (in GNOME or in these projects), but imposing the python version to be so high by default seems a gratuitous change. 3 out of 5 Ubuntu releases do not have Python 2.5 by default, no Debian release has it and the next one wont have it. I am not proposing that GNOME modules using Python should require a minimum Python version of 2.5. I am only proposing that jhbuild bootstrap install the python 2.5 tarball instead of python 2.4. The effect of this change is: 1. We start putting more emphasis on testing GNOME-over-python2.5 rather than GNOME-over-python2.4 (the latter has already been extensively tested over the years, while the former hasn't); 2. We require that GNOME modules using Python make an effort to work on Python 2.5, in addition to Python 2.4. I think primarily it's a matter of which version of python we prefer to test. I say we test GNOME with python 2.5 because it's the new stable version of python and python 2.4 is not maintained any more. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.20 Python version
On Ter, 2007-03-13 at 12:52 -0500, Shaun McCance wrote: On Tue, 2007-03-13 at 17:38 +, Gustavo J. A. M. Carneiro wrote: On Ter, 2007-03-13 at 16:57 +0100, Loïc Minier wrote: On Tue, Mar 13, 2007, Elijah Newren wrote: Unlike GNOME and Linux, Python does not use odd version numbers for development versions. Thus 2.5 is the latest production version of Python, rather than the latest development version. I know 2.5 is a stable release; my point is that this needlessly raises the bar to build GNOME: anyone is free to build GNOME with whatever version of libc6, gcc, or python that one wants to catch some bugs (in GNOME or in these projects), but imposing the python version to be so high by default seems a gratuitous change. 3 out of 5 Ubuntu releases do not have Python 2.5 by default, no Debian release has it and the next one wont have it. I am not proposing that GNOME modules using Python should require a minimum Python version of 2.5. I am only proposing that jhbuild bootstrap install the python 2.5 tarball instead of python 2.4. The effect of this change is: 1. We start putting more emphasis on testing GNOME-over-python2.5 rather than GNOME-over-python2.4 (the latter has already been extensively tested over the years, while the former hasn't); 2. We require that GNOME modules using Python make an effort to work on Python 2.5, in addition to Python 2.4. I think primarily it's a matter of which version of python we prefer to test. I say we test GNOME with python 2.5 because it's the new stable version of python and python 2.4 is not maintained any more. If a program works correctly with Python 2.4, is there actually a danger of it not working correctly with 2.5? That sounds broken. Yes, there is a lot of danger of it not working with 2.5 in particular in 64 bit systems. Python does not guarantee strict API/ABI compatibility; that issue has been discussed extensively in the past in this very mailing list. Python changes API and ABI of extension modules and even the language itself, albeit very slowly so as to not cause too many headaches. In this case, however, Python in 2.5 decided to change the extensions API to use long int rather than int in a lot of places. In LP64 systems that represents a major ABI change. This change, however, only gives few compilation warnings for some cases, or in other cases not even a compilation warning is given (like the s# convertion specifier in PyArg_ParseTuple) and the programmers have to pay attention to the code. Sometimes, only in runtime can errors be caught. I worry that this move would result in programmers using 2.5-only features. Our intrepid testers wouldn't notice, because they're building from jhbuild. But we'd create an effective 2.5 dependency that our distributors would have to deal with. 1. Distributions that are bleeding edge enough to include GNOME 2.20 but still using Python 2.4 are just... crazy :| 2. For the N-th time, I am not advocating dropping support for Python 2.4. I am saying that it is important that we test Python 2.5, more so than testing Python 2.4. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 2.20 Python version
I'd like to suggest updating jhbuild to install Python 2.5 instead of 2.4 for GNOME 2.20, because: * I don't think Python 2.4 will continue to be maintained; * Distributions that will receive GNOME 2.20 will most likely make python 2.5 the default (ubuntu already does for GNOME 2.18); * We could really use the testing of GNOME on Python 2.5, especially on 64-bit systems. Comments? -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: pulseaudio vs gnome
On Sex, 2007-02-02 at 14:19 +0100, Murray Cumming wrote: Just an fyi, but In embedded systems running Gtk+, you don't want to have to spend the time to initialize/start up Gstreamer just to play bling. The time lag is far too great. You limit Gstreamer use to items like movie and music playback - not system pings. But on systems that will want to do more impressive audio/visual stuff sometimes anyway, such as the Nokia N770/N800, wouldn't you want gstreamer to be loaded and initialized already anyway? Then there shouldn't (theoretically) be any delay in playing a system beep. Systems do not want to do impressive audio/visual stuff; it's applications that want that. It makes no sense for all applications to initialize GStreamer if only one or two of them need to do audio or multimedia stuff. If you want to avoid delay when playing a beep, then all apps will have to initialize GStreamer and precache an audio sample. Startup time and memory costs pile up. It's much better to have a simple sound server (which can use GStreamer) and a simple client API; a full fledged GStreamer library is overkill for most apps IMHO. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: seahorse
On Seg, 2007-01-08 at 18:05 -0500, Adam Schreiber wrote: On 1/8/07, Vincent Untz [EMAIL PROTECTED] wrote: You can learn about seahorse here: http://www.gnome.org/projects/seahorse/ +1 from me, but I'm biased as I'm a developer. However, I would like to note that several of the concerns posted when Seahorse was first proposed have been addressed. +1 from me too. I had already voted for its inclusion in GNOME 2.16, so... :) Wouter Bolsterlee suggested integration with gnome-keyring. gnome-keyring items are now loaded on the passwords tab of the seahorse application. This is cool; it almost replaces gnome-keyring-manager... could it replace it completely one day, I wonder?... Thanks, great work. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing control center menus
On Ter, 2006-12-12 at 11:51 -0500, Jonathan Blandford wrote: On Tue, 2006-12-12 at 15:26 +0100, Étienne Bersac wrote: A menu longer that 10 entry is very painful. Often, Gnome properties menu is about 20 entry when you install some additionnal softwares. Gnome is the only desktop which keep using this outdated control-center. A control center is far more usable and accessible (especially if it provide search). This also could mean that we have too many capplets. Agreed. But even if we can't get away from a multitude of capplets, there's an alternative solution: add an extra level of preferences categories, as we do for the applications menu. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing control center menus
On Ter, 2006-12-12 at 17:31 +, Andrew Sobala wrote: Jonathan Blandford wrote: On Tue, 2006-12-12 at 15:26 +0100, Étienne Bersac wrote: A menu longer that 10 entry is very painful. Often, Gnome properties menu is about 20 entry when you install some additionnal softwares. Gnome is the only desktop which keep using this outdated control-center. A control center is far more usable and accessible (especially if it provide search). This also could mean that we have too many capplets. Every single time we have this discussion, someone points out that we have too many capplets. Despite some good efforts at annihilating and assimilating various silly ones, there are still too many for a usable menu. In the real world, outside of Pure GNOME, distributor and 3rd-party (Java springs to mind) added capplets make the menu more unusable. Given that a) GNOME still has too many capplets, and b) there are additional ones that will always be added to the menu, I think making access to them as usable as possible is a laudable goal. Reducing the number of capplets is still a laudable goal, but hasn't solved this problem in the past. I see a _lot_ of room for merging capplets with a single glance. For instance (i'm sure there's others I missed): 1- keyboard, keyboard shortcuts, SCIM input method, and mouse could be merged into a single input devices 2- menus toolbars, fonts, theme = applications aspect 3- sreen resolution, screensaver, desktop background = Display 4- PamOS devices, and removable drives and media = external devices (or something) 5- *Everything non-GNOME*, move into a separate Other submenu. Else if you want searchable capplets we already have deskbar. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Document font preference
In my font preferences I see a Document font option. It affects the gconf key /desktop/gnome/interface/document_font_name, which is documented as Name of the default font used for reading documents. However, changing this font seems to have no effect on any GNOME application. Two question: 1- why does this preference exist if not used? 2- Can I use it in my application, or is it deprecated? Thanks, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Document font preference
On Qua, 2006-11-01 at 18:26 +, Gustavo J. A. M. Carneiro wrote: In my font preferences I see a Document font option. It affects the gconf key /desktop/gnome/interface/document_font_name, which is documented as Name of the default font used for reading documents. However, changing this font seems to have no effect on any GNOME application. Sorry, someone on IRC pointed out bug #160454; it appears that Yelp uses this (I forgot to check it). By the way, wouldn't it be nice if gtk+ GtkTextView widgets used this font by default? -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
jhbuild failing due to cvs conflicts
Congratulations to the build team; nowadays gnome is more buildable than before! However, there's one more major problem standing in our way to smooth jhbuilding. It seems that many modules are still producing cvs conflicts in po files. For example: RCS file: /cvs/gstreamer/gst-plugins-base/po/en_GB.po,v retrieving revision 1.42 retrieving revision 1.43 Merging differences between 1.42 and 1.43 into en_GB.po rcsmerge: warning: conflicts during merge cvs update: conflicts found in po/en_GB.po C po/en_GB.po I am _sure_ I didn't personally change any gstreamer po file; logic dictates that I should not therefore be penalized by cvs conflicts. What's happening here? Can it be fixed? -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild failing due to cvs conflicts
On Seg, 2006-10-30 at 00:22 +0800, Davyd Madeley wrote: On Sun, 2006-10-29 at 12:43 +, Gustavo J. A. M. Carneiro wrote: However, there's one more major problem standing in our way to smooth jhbuilding. It seems that many modules are still producing cvs conflicts in po files. For example: I am _sure_ I didn't personally change any gstreamer po file; logic dictates that I should not therefore be penalized by cvs conflicts. What's happening here? Can it be fixed? (At a guess) They're being changed when you build. Something is running an intltool merge. I thought we had stopped this behaviour from happening (it used to always happen with make dist). Of course, this is GStreamer, so their build system probably runs a little differently. You're probably right that something during build is changing the po files, but two things to note: 1. I'm not completely sure, but I think this happened also with another package, not gst*, though I don't remember the name; 2. I certainly never did a make dist on any gst package. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: integrating python applications in the gnome desktop
On Dom, 2006-10-15 at 12:32 +0200, Alfonso wrote: I hope this is the right place for this question, sorry if it is not. I have googled quite a lot, and couldn't find any tutorial or information related with how can I install my python programms in the gnome desktop. I'm making programs using python and pygkt. What I would like to do is installing them, so that they can be executed just like any other application in the applications menu. If I try to execute a python program by double click in gnome it appears the dialog asking if I you want to show the content of the file or executing it. I know this behaviour can be changed using gconf-editor, but I would prefer not to change it, and still having my application integrated in the applications menu, and executable by double click without intermediate messages. Make a .desktop file for your program; it is double-click executable without the annoying dialog. Plus, you can install it to /usr/share/applications to make it visible in the GNOME menu. Any information or links to articles or docs, would be very appreciated. http://freedesktop.org/wiki/Standards_2fdesktop_2dentry_2dspec Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-python-desktop branched
gnome-python-desktop branched (tag gnome-2-16) for GNOME 2.16; the HEAD branch will follow GNOME API changes and will possibly accept new APIs. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ 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]
Dom, 2006-09-24 às 16:57 +0100, Alex Jones escreveu: On Sun, 2006-09-24 at 09:43 -0600, Elijah Newren wrote: GUnique already uses D-Bus (with bacon as a backup). So, how is your proposal different than GUnique? (Other than startup-notification not being mentioned in your proposal yet?) It's different because it separates the process starts the service from the process that invokes methods on the service (i.e. LaunchNew(), OpenURI(), etc.). I completely agree that separating the client interface from the main app is beneficial. Witness Rhythmbox that recently started shipping a lightweight rhythmbox-client program that allows one to control RB without loading a very large binary in the process. Now I can bind my multimedia keys to control RB without having to wait a few seconds before pressing a key takes effect. It also gives us the ability to pre-load applications without showing any interface. I am totally willing to spare a chunk of my RAM if it means I don't have to keep warm-starting Epiphany every time I open a web page. It would make my entire desktop use a whole lot more responsive. +1 -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for LAT inclusion in GNOME 2.18
On Qui, 2006-09-14 at 04:11 +0100, Sander Vesik wrote: --- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: Ter, 2006-09-12 às 14:26 -0400, Hubert Figuiere escreveu: I would like to propose LAT 1.2.x for inclusion in GNOME, specifically to the Admin Suite. What was meant to happen is now happening. Now that Mono has been blessed for note taking application, people try to push their own tools written for Mono into Gnome. My vote is NO. You are voting no because it's written in Mono, with no further explanation; sorry, you are not allowed to do that. Why not? The language and needed dependencies, including runtime, is just an other parameter of teh software. What'sw wrong with disliking Mono or Python or C++? Disliking Mono or Python or C++ is too subjective. You have to characterize the program as a whole, like does it takes too much memory, is it slow, is the code is hard to maintain by 3rd parties because it uses an esoteric language, etc. etc. Programming language can have an effect on these characteristics, sure, but ultimately it is not the programming language that matters per se. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dbus-launch and gnome-session
On Ter, 2006-09-12 at 23:22 -0500, Scott J. Harmon wrote: Hello all, I just wanted to save some people out there, who may be trying to build gnome, some of their hair... In gnome 2.16 gnome-session now starts gnome-settings-daemon through dbus. So you probably know that you need dbus-launch running now in order to start gnome...no problem. Following the man page of dbus-launch, we decided to run dbus-launch upon login on the system (i.e. in the profile). This seemed to work fine for gnome 2.14. But last night I was pulling my hair out trying to figure out why gnome-settings-daemon was not launching in gnome 2.16. I realized it was being started by dbus, but didn't see why it was failing. After much hair pulling and such. We realized that dbus-launch didn't know anything about the X session and was trying to start gnome-settings-daemon, which needs the X session environment variables set. Do-oh! So, it was working fine with gdm (since it started X before logging the person in, but not with startx, since you logged in before you started X). Just thought I'd share this if anyone else happened to run into it. Been there myself. http://mail.gnome.org/archives/desktop-devel-list/2006-March/msg00102.html -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for LAT inclusion in GNOME 2.18
Ter, 2006-09-12 às 14:26 -0400, Hubert Figuiere escreveu: I would like to propose LAT 1.2.x for inclusion in GNOME, specifically to the Admin Suite. What was meant to happen is now happening. Now that Mono has been blessed for note taking application, people try to push their own tools written for Mono into Gnome. My vote is NO. You are voting no because it's written in Mono, with no further explanation; sorry, you are not allowed to do that. For stuff that has to stay resident in memory, like applets or daemons, I can understand people thinking twice before using them. For an admin tool like LAT that reason has 90% less weight. Next thing you know, you're going to ask to kick out epiphany because it embeds firefox which uses an automatic garbage collector, just like mono... Finally, since there is no C equivalent to LAT, we don't have much choice. No, GQ is not the same. From what I saw of GQ 1.0 and LAT 1.0, LAT is much better because 1) GQ is GTK2 based but very far from HIG compliant, 2) LAT is more than a simple LDAP client, it has views and dialogs for managing users, not just simple LDAP entries. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for Seahorse inclusion in GNOME 2.18
Sáb, 2006-09-09 às 22:04 +, Nate Nielsen escreveu: Seahorse is a encryption key manager for GNOME. It currently 'manages' PGP and SSH keys (work has been done on X.509 certificates [1]). The Seahorse developers would like to propose Seahorse 0.9.x for inclusion in GNOME. +1 I've been using seahorse for a long time; IMHO it certainly deserves a place in GNOME. The Seahorse developers' long term goal is to make encryption easy to use within GNOME. Besides filling a need for a key manager, inclusion in GNOME would help us realize that goal. For example: * EDS Address book integration I was going to suggest that too :P * About-me: 'my' encryption key selection * More intelligent trust metrics based on frequency of use Suggestions for how Seahorse can improve are welcome, as are ideas for making encryption easier for users. Once X.509 support is completed, I would love to see Evolution use searhorse for managing all keys. Right now Evo's key management is really very poor: you can't change the pass phrase of your keys DB, and there's even no option to export your own keys to a file; it's like a black hole, once you import a key, you won't get it back, ever. Anyway. Keep up the good work! -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
Sáb, 2006-09-09 às 04:55 +0200, BJörn Lindqvist escreveu: On 9/8/06, Don Scorgie [EMAIL PROTECTED] wrote: Doc people do not have enough time. Its as simple as that. As shaunm pointed out, this release we got 4 weeks to update the documentation. This included 3 new modules needing docs, as well as lots of updates to lots of other docs. The doc team has been on skeleton staff ever since I've known it. Most of the docs are now pretty out of date. Add in a desire to have translated docs and basically, the doc team has negative time to do the required work. The great part about it is that for the other 5 months, the doc team is pretty much sitting around, twiddling thumbs and thinking up plans for world domination [1]. The writers can't really do their thing with a moving target. Then lets stop the target! If I understand you correctly, the development process from the documentors point of view is kind of like this. * Five months were developers play and pretty much destroy all the docs we make. * Four weeks were we can undo the damage caused and make GNOME understandable. Maybe this problem can be solved by elevating the documentations and the translations status in the project? For example, patches are very seldom accepted if they introduce regressions in the software. But regressions in the docs aren't counted in the same way. New code very often changes applications behaviour so that the manual becomes invalid. What if the documentation and translation regressions were counted in the same way as code regressions? To me, that makes sense. An untranslated string is just as annoying as a frequently segfaulting program. So lets treat the problems the same. Code that changes behaviour shouldn't be committed unless the documentation is updated. User visible strings shouldn't be changed unless the translations are updated. Something like that? 1. Code truly is more important than documentation, that's why it's treated more importantly; 2. If you raise the bar for accepting contributions, making contributors update documentation at the same time, you'll surely have less contributions; 3. Documention doesn't destabilize the program, it can go on for a much longer time after code/feature freeze. If you want to delay the official GNOME .0 release for documentation, that's another matter. But delaying or forbidding contributions because of lack documentation is unthinkable. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
On Sex, 2006-09-08 at 01:00 -0500, Shaun McCance wrote: On Thu, 2006-09-07 at 19:32 +0100, Don Scorgie wrote: Hi, On Thu, 2006-09-07 at 11:24 -0700, David Trowbridge wrote: What in particular isn't possible with the 6-month cycle? For one thing: the documentation gets squeezed. We (the doc team) have, basically, 3 month to document all the changes, update all the docs and add any new documentation needed. The doc team is currently running at skeleton staff and is working right up until the tarball submission deadline. This knocks on and means that the doc translations (if present) are invariably a release behind. Don /me now waits to see if shaunm will release his top-secret plan for world domination... Here is my much-anticipated MASTER PLAN: Your master plan implies branching early and heavily committing to both branches for a long time. Reality check: we are still using this archaic software called C.V.S.! Branching with that software is incredibly complex. Your master plan is blocked by bug #: migration to subversion. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome desktop integration library
On Qua, 2006-09-06 at 15:26 -0400, David Zeuthen wrote:
Hi Havoc,
On Tue, 2006-09-05 at 21:16 -0400, Havoc Pennington wrote:
Hi,
To be slightly more constructive, I was thinking on the drive home, why
wouldn't there be something like:
interface GdkSession {
signal online-changed
signal screensaver-changed
signal idleness-changed
signal logging-out
/* plus getters for all those states */
}
GdkSession* gdk_display_get_session(GdkDisplay *display);
This seems to cover lots of the issues raised. It would obviously have
platform-specific backend, which could be dbus, or anything else that works.
Ideally you'd just wrap the interfaces exported by the Power Manager and
the Screen Saver [1] when running on GNOME. That shouldn't be too hard
provided you don't have to dlopen libdbus.so.*.
Not sure how this fit into the Win32 / Mac OS X / etc. story of GTK+
cross platform - last thing I want is GTK+ trying to abstract the
o.g.PowerManager and o.g.ScreenSaver abstractions. Rather, let's review
said D-BUS interfaces and make sure they work on e.g. Win32 too.
And don't forget xscreensaver. I once added support in one of my
programs monitoring screensaver through D-BUS. It was very neat and
worked, but then I got a bug report asking for xscreensaver support.
And the xscreensaver maintainer refuses to use D-BUS, and asks us to use
xscreensaver-command -watch instead, like in [1].
So getting proper screen saving notification abstractions is not
trivial, and I agree we could use a common library for that.
[1]
http://telecom.inescporto.pt/~gjc/gnome-osd/hg/gnome-osd/?cmd=file;file=gnomeosd/xscreensaver.py;filenode=35463d1d41b70b7be4d795cc3abf6e1094609b6e
--
Gustavo J. A. M. Carneiro
[EMAIL PROTECTED] [EMAIL PROTECTED]
The universe is always one step beyond logic.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: hal and jhbuild
On Sáb, 2006-08-19 at 18:57 -0600, Brent Smith wrote: I'm going to commit a change to freedesktop.modules to checkout hal from the tag HAL_0_5_7_1 and add a patch to jhbuild to fix the two instances where dbus_connection_close() should be used. Unless anyone has any objections... I think GNOME developers that are maintaining modules listed in the GNOME moduleset should have a clear obrigation to keep their modules buildable at all times, no matter what. I don't mean maintainers need to constantly build the whole GNOME stack, but if someone offers a patch to make it build in GNOME it is just irresponsible if the maintainer doesn't apply the patch or equivalent fix in a timely fashion, because the failure of one module often makes the whole GNOME stack unbuildable and blocks the work of potentially dozens of developers. I'm not sure what happened in this particular case, but this failure has existed for a long time (weeks?); it should have been fixed a long time ago. Maybe we need a set of written policies for this sort of thing... -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
BTW, I just noticed baobab is not HIG compliant: * File-Preferences should be Edit-Preferences; * The file search dialog uses a frame, and has a separator; * Not sure HIG says anything about this, but having an Exit button in the toolbar is weird; also having a check button instead of a toggle button is weird. Cool program otherwise. Regards. On Sex, 2006-07-28 at 11:01 +0200, Fabio Marzocca wrote: On 7/27/06, Jeff Waugh [EMAIL PROTECTED] wrote: I *definitely* think Baobab is a cool tool. But I don't see why it should be (or needs to be) on every user's desktop. Jeff, maybe following links could help in answering your question? http://www.ubuntuforums.org/search.php?searchid=7050176 https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue6 (see Feature of the Week) http://roozeec.over-blog.com/article-2937003.html http://ubuntu.wordpress.com/2005/10/25/baobab-graphically-analyze-file-trees/ http://www.gnomefiles.org/app.php?soft_id=1002 (see user ratings and downloads) http://forums.gentoo.org/viewtopic-t-379230-highlight-baobab.html http://forums.fedoraforum.org/showthread.php?t=102127 Consider that baobab is not a simple replacement of du, but it can scan also remote folders on remote servers thru ssh,ftp,smb,http or https, and gives graphical representation of the disk usage by means of a TreeMap graph and (in the next future) a Pie Chart. Fabio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: consistency (or lack thereof)
On Sex, 2006-07-21 at 13:42 -0400, Matthias Clasen wrote: Most of the control-center capplets are immediate-apply (except for ones which have very good reason not to be), and all of then have a Close button. All ? No, not all. The background capplet considers it better to have a Finish button instead... I have asked to fix this, but I have been told that user testing showed that Close is wrong there... So, what now ? Do we suddenly change all our close buttons to finish buttons ? Or do we embrace inconsistency in the name of user testing ? No, please let's fix this. Besides the lack of consistency with other capplets, it makes absolutely no sense at all to have a Finish button, especially since it uses the stock icon for Apply. This is very confusing even for me because I think this is an apply button with a different wording: I have to click on it for settings to be saved; or, if I don't click on it, my changes are reverted. Of course none of those are true. The Finish button only makes sense in a task-oriented interface. It makes some sense when using the Change Desktop Background desktop popup menu, because it is worded like a task description. It makes no sense when accessing the same preference through Preferences-Desktop Background. This highlights another inconsistency: Change Desktop Background in the desktop popup menu should be Desktop Background Properties instead. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus! (was Re: Focusing on innovation re: mono, python et al)
On Ter, 2006-07-18 at 13:08 -0400, Dan Winship wrote: [...] But regardless, if we want to be cohesive, we have to *integrate*, not keep a wall between the applications and the rest of the system. IMHO, GNOME doesn't need to integrate apps onto itself. On the contrary, apps need to integrate with GNOME. For that to happen, GNOME needs: 1- Framework for desktop extensibility, in the line of some of the things we already have: ability to register new MIME types, install menu items, register new applets with the panel; some others are missing, like notifications (libnotify, hopefully some day part of gnome); also nautilus/epiphany/gedit extensions.. 2- A sound developer platform. glib/gtk+; hopefully gnome-vfs lower in the stack... GStreamer... 3- GNOME integration guidelines: the HIG is an excellent start, but not enough; I don't remember if there are others... And BTW, nautilus supports search folders, which can be optionally powered by beagle already. Nautilus _optionally_ depends on beagle. That means beagle integration without GNOME depending on beagle. If beagle were part of GNOME, would things really be any different? I think not. IMHO, GNOME should be _open to integration_, not assimilate all good gtk+ based applications. Regarding the focus issue, perhaps the distribution needs to drive this, not GNOME. I'm thinking for example of ubuntu vs edubuntu (education oriented variant of ubuntu). They're basically the same distribution, with different default colors and different default set of apps. _Maybe_ we could go one step further and have apps customize the level of complexity of the UI (like very early nautilus had as preference, like RB has a compact mode). Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono/GTK#/Tomboy
On Sex, 2006-07-14 at 10:50 +0200, Murray Cumming wrote: On Fri, 14 Jul 2006, Murray Cumming wrote: And while there were almost no objections to Python, there are clearly many objections to Mono. What objections? So far, the only two objections I've heard are: 1. Performance -- I feel that I've addressed this in other emails. I don't believe that you've adressed the memory problems, though these are not specific to Mono. We maybe can handle one highlevel runtime, but 2 highlevel runtimes seems to be getting silly. The argument that we can fix performance later is not going down well with lots of users, though it makes sense in many ways. What do we say now to the people who say The sticky notes applet now takes up XX megabytes more than before and makes GNOME start up much slower. Those people don't care about anybody's favorite programming language. We want to have it both ways, but we can't right now, so we must make the difficult decision between these pros and cons. It's not helpful to pretend that the decision doesn't exist. Also, Tomboy is an applet, intended to replace the commonly-used sticky notes applet, so it's likely to take up memory all the time. (I haven't had a response to my notes-tomboy transistion questions [1] but that's a non-mono issue.) deskbar-applet has the same problem, of course. When we approved python I don't think we necessarily approved this particular use. That was a separate thing. I don't think deskbar is a problem because: 1. deskbar is a kind of power user tool; 2. deskbar is not loaded by default; the user has to explicitly find it and loaded. So the fact that python apps are acceptable to the GNOME desktop doesn't not imply that the GNOME desktop is more bloated. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Totem branched for GNOME 2.14
On Sáb, 2006-04-29 at 16:41 +0100, Bastien Nocera wrote: On Fri, 2006-04-28 at 07:27 -0500, Travis Watkins wrote: On 4/28/06, Bastien Nocera [EMAIL PROTECTED] wrote: Usual gnome-2-14 branch name. Plans for 2.16? Hey Lui^WTravis ;) Not any specific plans I'm afraid. More bug fixing as time permits. The obvious comment (someone has to say it), You shouldn't need to branch just for bug fixing... -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ 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]
said it better already http://mail.gnome.org/archives/desktop-devel-list/2005-May/msg00142.html I drafted the first version of this message before I saw the comments on planet gnome but it seems I'm not the only one thinking about 3.0: http://blogs.gnome.org/view/newren/2006/04/18/0 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. smime.p7s Description: S/MIME cryptographic signature ___ 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 Qua, 2006-04-19 at 16:35 +0200, Olav Vitters wrote: On 4/19/06, Kalle Vahlman [EMAIL PROTECTED] wrote: On 4/19/06, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: Please, don't take the 3.0 version lightly, only as a way to improve GNOME marketing. The jump to 3.x version is invaluable in helping developers figure out which library versions break API and can be parallel installed, and which versions are simple upgrades that retain old API compatibility. If we change the GNOME version to 3.0 but don't break the API it is going to be very confusing for developers. Hey, don't forget the applications. GNOME is more than just an API. You guys make it sound like three-point-oh would be all about the platform things. I do not care about 3.0. If there are great ideas, why not do them during 2.x Agreed. and at some time perhaps call a 2.x version 3.0. Disagreed. Let's not call it 3.0 just because we feel like it. 3.0 should mean API breakage point. I still think that 3.0 should be a number for developers to care about, and project Ridley is a different thing. GNOME still lacks (good and tightly integrated the GNOME way) applications in various day-to-day things like IM. Getting a good set of applications should be a goal for 3.0 (in addition to things like making the platform legacy-free). Why is IM so special that we cannot add it during 2.x? There already is a plan to add office/productivity apps. People seem to think that 3.0 should be some sort of ideal desktop where everything is nice perfectly integrated. That's an utopia, it will probably never happen. But it's cool to have a Ridley vision, so that we can gradually work towards it. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About-me-password backend
Note that glib already has g_child_watch_add, which is a lot simpler
and safer to use than signal(). In the callback you can see what status
the child returned and if it received a signal instead.
Regards.
On Ter, 2006-04-11 at 09:42 +0100, Darren Kenny wrote:
Hi Johannes,
The most correct way to handle the status of a child process is to catch
the unix signal 18 - SIGCHLD - this should be fired by the OS (assuming
unix based) should the fork/execed process exit.
So you need to set up a signal handler for SIGCHLD, before you enter the
processing loop, and have this signal handler store the pid of the
passwd process so that later you can check if this is the one that exited.
Meanwhile, a loop with a read on an file descriptor (e.g. waiting for
the Password: string from passwd) will be interrupted due to the
SIGCHLD and return -1, and errno will be set to EINTR - if you check for
these conditions and then call the child_exited call then you should
know if passwd exited.
For example:
signal( SIGCHLD, reapChildProcess );
while ( ! done ) {
if (read(...) 0 ) {
if ( errno == EINTR child_exitied( passwd_pid) == TRUE ) {
done = TRUE; /* or whatever you want to do to exit gracefully
*/
continue; /* or break if you want to force exit of the loop */
}
}
/* normal processing */
}
(BTW, I'm assuming you don't have multiple processes forked, if you do
you probably need to store the last N processed exited for check to work).
There should be loads of examples of this type of thing on the net...
Darren.
Johannes H. Jensen wrote:
Dear almighty GNOME hackers, I'm in need of some pointers!
I'm currently hacking on the about-me password dialog (see #321567),
which is spawning /usr/bin/passwd to authenticate and change the
password. In the new dialog, I'm dividing the process in two, so that
the user has to authenticate with his current password first (which
spawns passwd to verify). If passwd doesn't complain and prompts for
the new password, he can enter his new password, retype it and hit
Change password. When he hits the button, some time has elapsed
since he first authenticated (and thus passwd was spawned).
Now my question is, what happens if passwd suddenly dies during that
time period? Is it likely it will? If so, what's the best way to
periodically(?) ensure that the process is running? Check every n
seconds with waitpid() in the main loop? As far as I can see, this is
how it's done in the current version - wait_child() is called every 4
seconds to check what the backend is doing...
Any pointers greatly appreciated :)
Btw, a more detailed mockup of the program/process flow can be found
at http://joh.deworks.net/password-dialog/GnomeAboutMePassword.html
Best regards,
Johannes H. Jensen
deworks
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
--
Gustavo J. A. M. Carneiro
[EMAIL PROTECTED] [EMAIL PROTECTED]
The universe is always one step beyond logic.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applications launched from dbus missing SESSION_MANAGER env. var.
On Seg, 2006-03-13 at 10:55 -0600, Federico Mena Quintero wrote: On Sun, 2006-03-12 at 19:44 +, Gustavo J. A. M. Carneiro wrote: I have a problem with a program that behaves badly when launched from dbus[1], as opposed from starting manually from terminal, run dialog, or deskbar applet. To see what was going on, I extracted the environment of the process in both situations. The attached diff shows how the environments differ (env2.good = launched from deskbar, env2.bad = launched by dbus). Besides the difference in DISPLAY (from 1.0 to 1), the missing SESSION_MANAGER variable jumped to my attention, as well as missing GNOME_KEYRING_SOCKET. Don't reinvent the wheel. See how bonobo-activation-server handles this --- it has a mechanism to pass interesting environment variables to spawned children. I am aware of that. First I wanted to raise awareness of the problem, without suggesting any solution. But since we are discussing solutions... I think the bonobo-activation mechanism can be very useful, but on the other hand it requires a lot of intelligence on the part of the clients. They need to be aware of which env. vars. are important to pass to the factory. But why should my application need to be aware that GNOME_KEYRING_SOCKET is important? One could put the list of interesting variables in the dbus client library, but then the same question could be asked: why should the dbus client library be aware of gnome keyring variables? Considering this, I see only two good alternatives: 1. Havoc's proposal to add a remote API to dbus session to set environment variables in the session; 2. Automatically copy _all_ environment from client to the activated server, always. But then we should perhaps also consider another bonobo activation feature: you can mark some variables as special for determining uniqueness of service instances. For instance, bonoboui marks i18n variables (LC_*, LANG*) as special, and multiple factories for the same component may be activated if different clients with different LANG variables request them. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Applications launched from dbus missing SESSION_MANAGER env. var.
I have a problem with a program that behaves badly when launched from dbus[1], as opposed from starting manually from terminal, run dialog, or deskbar applet. To see what was going on, I extracted the environment of the process in both situations. The attached diff shows how the environments differ (env2.good = launched from deskbar, env2.bad = launched by dbus). Besides the difference in DISPLAY (from 1.0 to 1), the missing SESSION_MANAGER variable jumped to my attention, as well as missing GNOME_KEYRING_SOCKET. I think I can explain what happens: 1. 1- dbus-session is executed first, which sets DBUS_SESSION_BUS_ADDRESS for children; 2. 2- gnome-session is executed next, as a child of dbus-session, and it sets SESSION_MANAGER for children. So, it's easy to see that processes launched by gnome-session inherit both DBUS_SESSION_BUS_ADDRESS and SESSION_MANAGER. However, processes launched by dbus only receive DBUS_SESSION_BUS_ADDRESS, because dbus doesn't notice the SESSION_MANAGER variable set inside gnome-session and its children. So I reckon we may have a potencial problem in the future, with increasingly more applications using D-BUS for automation. I don't know the solution, but it seems like a cross-product interaction problem and so I write here in hope to raise awareness for the issue, at least... [1] dbus.SessionBus().start_service_by_name(...) -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic --- env2.good 2006-03-12 19:02:35.0 + +++ env2.bad 2006-03-12 19:02:41.0 + @@ -1,12 +1,12 @@ DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-HCEB013jC1,guid=0bfe134459053cb4f3867b0277d10f00 +DBUS_STARTER_ADDRESS=unix:abstract=/tmp/dbus-HCEB013jC1,guid=0bfe134459053cb4f3867b0277d10f00 +DBUS_STARTER_BUS_TYPE=session DESKTOP_SESSION=gnome -DISPLAY=:1.0 +DISPLAY=:1 GDM_LANG=en_US.UTF-8 GDMSESSION=gnome GDM_XSERVER_LOCATION=local -GNOME_KEYRING_SOCKET=/tmp/keyring-6ub554/socket GPG_AGENT_INFO=/tmp/gpg-iLCOc7/S.gpg-agent:5027:1 -GTK_RC_FILES=/etc/gtk/gtkrc:/home/gjc/.gtkrc-1.2-gnome2 HOME=/home/gjc LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 @@ -16,7 +16,6 @@ LOGNAME=gjc PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games PWD=/home/gjc -SESSION_MANAGER=local/emperor.homelinux.net:/tmp/.ICE-unix/4940 SHELL=/bin/bash SHLVL=0 SSH_AGENT_PID=5036 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver
On Tue, 2006-02-07 at 12:10 +0800, Davyd Madeley wrote: I see that both Ubuntu Dapper and Fedora Core 5 test 2 are shipping with gnome-screensaver now. Having now used both of them, does it seem slow for anyone else? It seems that something has gone astray once or twice and forced me to have to change vt and kill the process to get my session back. I didn't manage to get anything useful debugging-wise from it, does anyone know the story here? If we have a screensaver that you can't get away from, we should consider not including this module during this release cycle. I tested a couple of days ago. At first I thought it was awesome. Then one time, when I came back from lock screen, my whole X server suddenly started becoming extremely slow. I mean, _really_ slow, like taking 5 seconds to draw a window. During the process I kept an eye on CPU usage and it seemed the X server was not consuming any CPU (unless the system monitor applet was not redrawing), not disk IO either, it was just slow for some other reason. Eventually I had to kill the X server. I tried restarting metacity first but it didn't help. I am not sure gnome-screensaver is to be blamed for the above problem, but I strongly suspect it, and have since then uninstalled it. --d -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: G_MODULE_BIND_LOCAL broke nautilus-python extension
On Wed, 2006-02-08 at 20:02 +, Mike Hearn wrote: On Wed, 08 Feb 2006 16:22:08 +, Gustavo J. A. M. Carneiro wrote: So it seems that the desktop wide decision to load all modules with G_MODULE_BIND_LOCAL, for performance reasons, may break python extensions. So far, nautilus-python was affected by this. Do people have any suggestions? Clearly Python has to be fixed, but that is a long term fix; how to fix things _now_? Try calling dlopen(libpython.so.whatever, RTLD_GLOBAL) before calling into the interpreter. If you're lucky that'll force the symbols into global scope. If you're unlucky then you need to not link against libpython yourself but instead dlopen and dlsym the APIs you need, and hope that they actually exist (libpython does not have a stable ABI). This worked perfectly; thanks a lot! :-) -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
On Wed, 2006-02-08 at 11:09 +, Jamie McCracken wrote: Rodrigo Moya wrote: On Wed, 2006-02-08 at 12:57 +0800, Davyd Madeley wrote: This course of action will create a time when GNOME goes the way of propriortary UNIX: Tru64, Solaris, AIX, HP-UX, IRIX... imagine a world with Novell Desktop, Topaz, Java Desktop, the Hatrack Environment: all competing products... where is GNOME? not if the changes are not kept proprietary and sent upstream sooner or later. perhaps but the real question is why isn't this a branch in CVS? Why is there a need for clandestine development? Maybe because CVS branches are inherently complicated. And maybe because you have to ask permission of the maintainer before creating a branch on a module. And maybe because if everyone starts making lots of branches, your namespace of CVS branches/tags starts to get polluted very quickly. I know some very wise people have decided, apparently without much discussion with the community, that GNOME would switch to Subversion. But I keep thinking that, although Subversion is much better than CVS, maybe we would benefit more from a distributed version control system, like mercurial, bzr, git, monotone, etc. I keep wondering whether the decision to switch to Subversion is due to the large number of similar looking alternatives and lack of courage from the GNOME leadership to pick one, while in the centralized version control systems Subversion is becoming _the_ alternative to CVS, so it's easier to pick Subversion rather than _choose_ one of the distributed control systems. There's a very interesting thread in the cairo list regarding a potential switch from CVS to git. I commend Carl Worth for the courage of proposing this; maybe the GNOME project should take cue from him. [1] http://lists.freedesktop.org/archives/cairo/2006-February/006255.html -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
On Wed, 2006-02-08 at 15:10 +, Ross Burton wrote: On Wed, 2006-02-08 at 14:20 +, Gustavo J. A. M. Carneiro wrote: I know some very wise people have decided, apparently without much discussion with the community, that GNOME would switch to Subversion. But I keep thinking that, although Subversion is much better than CVS, maybe we would benefit more from a distributed version control system, like mercurial, bzr, git, monotone, etc. I've seen lots of discussion about Subversion vs Arch vs Bazaar (in various forms) on gnome-hackers. I keep wondering whether the decision to switch to Subversion is due to the large number of similar looking alternatives and lack of courage from the GNOME leadership to pick one, while in the centralized version control systems Subversion is becoming _the_ alternative to CVS, so it's easier to pick Subversion rather than _choose_ one of the distributed control systems. Correct. Subversion means that existing developers can pick it up in no time, so from a developer PoV its a pretty painless operations (obviously from the cvs admin PoV its trickier, but not as hard as migrating to arch and training all developers). As was bought up in the original thread on this topic, bazaar.ubuntu.com contains daily-synced Bazaar archives of the GNOME CVS modules, so if you want to do a remote branch of a module to hack on it, you can. That's not entirely helpful. First, you still have to master CVS to commit. We'd end up using two different CLIs for the same thing. Also, bazaar.ubuntu.com contains archives in the old bazaar 1.x format, while they recommend bazaar-NG now (bzr). Finally, the archive only mirrors a few (24) GNOME modules, not the entire CVS tree. I did the ICC work on Eye Of Gnome this way, and it was very useful. Yes, it has drawbacks, but without forcing everyone to learn an completely new tool, migrating to svn and providing bazaar mirrors covers pretty much all cases. There's a very interesting thread in the cairo list regarding a potential switch from CVS to git. I commend Carl Worth for the courage of proposing this; maybe the GNOME project should take cue from him. I know kernel developers that think git is over-complicated and confusing... Well, then at least mercurial or bzr; they at least are not over-complicated from my experience. I can't comment on git since I never used it. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: G_MODULE_BIND_LOCAL broke nautilus-python extension
So it seems that the desktop wide decision to load all modules with G_MODULE_BIND_LOCAL, for performance reasons, may break python extensions. So far, nautilus-python was affected by this. Do people have any suggestions? Clearly Python has to be fixed, but that is a long term fix; how to fix things _now_? On Wed, 2006-01-25 at 13:41 +, Gustavo J. A. M. Carneiro wrote: On Wed, 2006-01-25 at 10:15 +0100, Alexander Larsson wrote: On Wed, 2006-01-25 at 00:22 +, Gustavo J. A. M. Carneiro wrote: Regarding this change (after 2.13.3): 2005-12-13 Alexander Larsson [EMAIL PROTECTED] * libnautilus-private/nautilus-module.c (nautilus_module_load): open modules G_MODULE_BIND_LOCAL It has broken nautilus-python. See bug #327739. The problem is that python modules expect to find some standard python symbols in the global scope, but since nautilus is loading the nautilus-python extension module---and consequently libpython24.so itself---in a private scope, all python extension modules fail to load. Any thoughts? The whole move to BIND_LOCAL is a gnome-wide thing we're doing for performance reasons. All other places loading modules were changed similarly. Maybe we should discuss this in a wider scope? I understand and generally agree with this. Python itself loads all modules in a local scope. I remember how this used to affect some gtk engines until they were fixed to link explicitly to gtk. How can python module look up things in the global scope only? Surely the nautilus-python library links to libpython, and thus all the symbols in that should be availible to all code that nautilus-python loads? nautilus-python library links to libpython, but both nautilus-python library and libpython are bound to a local scope. libpython then loads python modules, but python modules never explicitly link to libpython (because many times there is no python dll available, only the exe). Apparently, modules loaded by a library don't automatically use that library's scope, but instead try to rely on the global scope. Clearly python is broken in this respect. The python shared library should always be available, and all python extension modules should link to it. Then we would not have this problem. But as it is, there's nothing we can do. I wish there was some way to open an exception just for nautilus-python, make it load with global symbol visibility instead? Maybe some metadata xml file. Or some special naming convention for the library name? Yes, it's a bit hackish, I'm ashamed to suggest it :P (Clearly I'm not an expert in these things...) Me neither. James, maybe you can help us? :) Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
On Wed, 2006-02-08 at 23:57 +0800, Davyd Madeley wrote: On Wed, Feb 08, 2006 at 02:20:15PM +, Gustavo J. A. M. Carneiro wrote: perhaps but the real question is why isn't this a branch in CVS? Why is there a need for clandestine development? Maybe because CVS branches are inherently complicated. And maybe because you have to ask permission of the maintainer before creating a branch on a module. And maybe because if everyone starts making lots of branches, your namespace of CVS branches/tags starts to get polluted very quickly. There is a saying here about poor workmen and tools. Perhaps CVS is not the best revision control system invented by man, but by the same token it works pretty good, has enabled us to create an excellent product, and seems to work for most of what we want to do 90% of the time. Interestingly, if you ask to create a development branch, most maintainers will say yes. If you create a branch like novell-development, you get the power to use it over and over again. A CVS branch has limited use. If you create a branch at some point in time, you can work on your stuff all you want, but as side effect you suddenly stop tracking HEAD development. From time to time you need to 1) extract a patch with changes from branch; 2) create a new branch based on HEAD; 3) reapply your patch to the new branch. At least, I don't think you can 'move' a branch, although it could be the case of my lack of CVS expertise. And if you can't move a branch you have create a new one, thus starting to pollute the tag/branch namespace. 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 :-/ CVS branches are hard, you have to admit it ;-) -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Fri, 2006-01-20 at 13:35 -0700, Elijah Newren wrote: On 1/20/06, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: Sex, 2006-01-20 às 09:10 -0700, Elijah Newren escreveu: I make a best effort (which is sometimes lacking, in particular I just realized I've always forgotten to notify the bindings people -- which is perhaps why you see it as no different) to at least notify apps that I know are affected and often also provide patches. Note the above parenthetical comment... I wouldn't bother notifying anyone if I broke ABI of libmetacity-private (other than control-center), even if it was during a micro point release during the stable cycle. This already happened once with wnck, with nasty results: http://www.daa.com.au/pipermail/pygtk/2006-January/011660.html But we understand the limitations of API guarantees and live with it. Yup, this was an example of where I sucked as mentioned in the previous comment. I probably should have notified bindings in the past of wnck API/ABI changes. Would it make sense to do so in the future? Would a mail to language-bindings@ be sufficient for that purpose? I think that API/ABI changes will be noticed after a while and fixed. But if library authors change API/ABI very near the GNOME release date, the errors could go unnoticed until too late. I propose the following: if there's an API/ABI break after the GNOME API freeze deadline (which only applies for gnome devel platform modules, of course), then desktop library maintainers are strongly advised to notify bindings authors by sending an email to the language-bindings list. This should be enough, I think. So I've finally released the split g-p-e/g-p-d packages, leaving metacity in g-p-e and untouched. I almost thought about renaming to you mean g-p-d? ;) Yes, of course. Sorry. :) metacity.private, but it's ugly, and I thought this discussion had died out with no much concern. At the time I received this email, I had already uploaded the packages. I hope this will not cause much concern, but I guess renaming the module or issuing a warning during import is still a viable option. Nah, don't worry about the renaming or giving a warning. As you've pointed out, this really is not different for you than how you've had to deal with wnck in the past; since you're fine with that, I don't see any problems. Thanks. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Seg, 2006-01-16 às 19:13 -0700, Elijah Newren escreveu: [4] gnome-python-desktop hasn't yet been split from gnome-python-extras but it was a very recent proposal (caused by requirements of other modules), so it may be a few more days yet before Gustavo is able to make the split. I would have done it already if some caring gnome cvs admin would have found time to answer my cvs surgery request[1].. :-) Regards. [1] Your message about CVS surgery request for gnome-python-extras/gnome-python-desktop split has been received and assigned a ticket ID [gnome.org #863]. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Ter, 2006-01-17 às 11:43 -0200, Guilherme de S. Pastore escreveu: Em Ter, 2006-01-17 às 13:24 +, Gustavo J. A. M. Carneiro escreveu: I would have done it already if some caring gnome cvs admin would have found time to answer my cvs surgery request[1].. :-) The Sysadmin Team cares, believe me. Sorry for the delay, looking at it now. Yeah, I know, I don't mean to criticize; I asked for it on a saturday, so I shouldn't expect it so soon... :P PS: please add 'metacity' to the list of subdirs to copy into gnome-python-desktop. Thanks! Yours, Guilherme de S. Pastore The GNOME Sysadmin Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Trying to reach consensus on g-p-e
Qui, 2006-01-12 às 10:52 +0100, Paolo Maggi escreveu: Hi guys, since Gustavo (g-p-e maintainer) is willing to split g-p-e in two parts: 1. modules wrapping gnome desktop libraries (let me call it gnome-python-desktop), Yes, gnome-python-desktop is exactly the name I had in mind. :-) 2. modules wrapping other libraries, That would remain to be called gnome-python-extras. can we reach consensus on allowing desktop applications to depend on what I called gnome-python-desktop and so on including gnome-python-desktop itself in desktop modules set? This is importart for several reasons: - we will be able to include python-based applets in desktop, - we will be able to add python-based plugins to desktop applications (e.g. gedit), - in general, we will be able to write new python applications that can use desktop libraries such as gtksourceview, gnomeprint, gnomeprint.ui, etc. gnome-python-desktop will follow the same rules of the other desktop libraries, i.e. API/ABI backward compatibility is desirable, but not strictly required. We don't recommend desktop libraries for usage by ISPs. If needed, I think we could further reduce the set of bindings to include in gnome-python-desktop to the ones actually used by desktop applications: - gnome-applet (if a python-based applet will be included in desktop) - gnomeprint, gnomeprint.ui, gtksourceview (conditionally required for gedit python plugins) Sorry, I don't agree at all with this third alternative. While for gnome 2.14 maybe only gnomeapplet, gnomeprint, and gtksourceview maybe needed, maybe in gnome 2.XY other modules might be needed, and I don't like constantly shifting modules left and right. Please, let's stick to the plan of splitting in desktop/extras, where desktop is all dekstop libraries, not just the ones used by current desktop apps. Cheers. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Trying to reach consensus for the proposed modules
Hi Paolo, On Thu, 2006-01-12 at 00:45 +0100, Paolo Borelli wrote: [...] The naive way to go at this would be splitting g-p-e in two (things that could go in the desktop like pygtksourceview, pyapplet etc and things that are not required for the desktop). However this distinction sounds extremely artificial to me and would double the workload of making releases etc. Gustavo made clear that he does not want to maintain two packages instead of one just because of bureaucratic issues and I totally agree with him. It's true. Especially due to the nature of CVS, moving files around from module to module is painful.. However, I'm willing to make an effort and split g-p-e in two, but only if it has to be included in gnome desktop (otherwise it's wasted effort). In fact, after seeing the discussion, I realize that if g-p-e is included in the desktop, it has to follow the gnome schedule, therefore wrapping libraries that do not follow the gnome schedule will create problems; i've experienced them already in the past. Let's see. If I'm not mistaken, the modules wrapping gnome desktop libraries are: - gnomeapplet - gnomeprint, gnomeprint.ui - gtksourceview - wnck - totem.plparser - gtop - nautilusburn - mediaprofiles Leaving out: - gtkhtml2 (didn't this use to be in the desktop?...) - egg.trayicon (egg.* these are copy-pasted, not wrapping anything, actually) - egg.recent - gtkspell - gtkmozembed - gdl - gda - gksu, gksu.ui That would be a near perfect split. I guess it would involve some CVS surgery work, but the end result wouldn't be so bad... Cheers. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SCons'ified PyGTK
On Sat, 2006-01-07 at 07:22 +0100, Hongli Lai wrote: Gustavo J. A. M. Carneiro wrote: Behold! A SCons'ified PyGTK is now available: http://www.gnome.org/~gjc/pygtk-2.8.3.tar.gz http://www.gnome.org/~gjc/pygtk-scons.diff It needs scons 0.96.91, instead of make. I had to invest a lot of effort and time to make this happen, due to missing functionality in base scons. However, I tried to be careful to split out generic functionality into a separate 'scons tool' that could potentically be reused outside of PyGTK. I didn't test it on win32, but in theory it should work, with more or less adjustments. Features of this tool include 'dist' and 'distcheck' support, along with configure checks for pkg-config modules, python version, python headers, etc. It should be noted that the scons-based tarball is only 595K vs the 919K autotools tarball. The difference is 324K, while the scons-0.96.91.tar.gz full source takes 343K. Good stuff! Scons is an interesting build system but unforunately it lacks some standard autoconf/automake features. I've written my own extension for 'make dist' support but I look forward to taking a look at your 'scons tool'. Thanks. I have now added DESTDIR support, which was also missing. It monkey-patches the regular env.Install and env.InstallAs, so as to need changes in apps. This and future changes I make will be available in a mercurial tree published at http://telecom.inescporto.pt/~gjc/hg/pygtk-scons/ Next I'll try to make 'scons distcheck' verify that DESTDIR is respected for all installed files. Cheers. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: SCons'ified PyGTK
Qui, 2005-12-29 às 18:35 +, Gustavo J. A. M. Carneiro escreveu: Behold! A SCons'ified PyGTK is now available: http://www.gnome.org/~gjc/pygtk-2.8.3.tar.gz http://www.gnome.org/~gjc/pygtk-scons.diff It needs scons 0.96.91, instead of make. I had to invest a lot of effort and time to make this happen, due to missing functionality in base scons. However, I tried to be careful to split out generic functionality into a separate 'scons tool' that could potentically be reused outside of PyGTK. I didn't test it on win32, but in theory it should work, with more or less adjustments. Features of this tool include 'dist' and 'distcheck' support, along with configure checks for pkg-config modules, python version, python headers, etc. It should be noted that the scons-based tarball is only 595K vs the 919K autotools tarball. The difference is 324K, while the scons-0.96.91.tar.gz full source takes 343K. Also some interesting timing statistics: pygtk build method time (real) === scons 1m8s ./configure make 1m28s ./autogen.sh make1m34s This is on a AMD64 3000+ system with 512 MiB of RAM. Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
SCons'ified PyGTK
Behold! A SCons'ified PyGTK is now available: http://www.gnome.org/~gjc/pygtk-2.8.3.tar.gz http://www.gnome.org/~gjc/pygtk-scons.diff It needs scons 0.96.91, instead of make. I had to invest a lot of effort and time to make this happen, due to missing functionality in base scons. However, I tried to be careful to split out generic functionality into a separate 'scons tool' that could potentically be reused outside of PyGTK. I didn't test it on win32, but in theory it should work, with more or less adjustments. Features of this tool include 'dist' and 'distcheck' support, along with configure checks for pkg-config modules, python version, python headers, etc. It should be noted that the scons-based tarball is only 595K vs the 919K autotools tarball. The difference is 324K, while the scons-0.96.91.tar.gz full source takes 343K. Some basic instructions: 1- to compile, type 'scons prefix=/foo/bar' 2- to run unit tests, type 'scons check' 3- to install, type 'scons install' 4- to uninstall, type 'scons -c install' 5- to make a new tarball, type 'scons dist' This is only an experiment; therefore, feedback is appreciated. Cheers. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
For the sake of this discussion, I've been trying to get pygtk to build with scons during this weekend. Yes, it took me many hours of fun work to get pygtk minimally converted. And it's not finished. Equivalents to 'make dist' and 'make distcheck' are not implemented, and I suspect they will take some effort. So, definitely scons is not ready for GNOME yet; it provides basic infrastructure, but lacks some high-level features (eg. I had to reimplement PKG_CHECK_MODULES, AM_PATH_PYTHON, and AM_CHECK_PYTHON_HEADERS) and policy (eg. no concept of prefix, bindir, datadir, etc.). Nonetheless, it is clear to me now that scons is an order of magnitude more clean (detection+build logic are placed together, one language instead of m4/make/sh mix) and maintainable than autotools, and if we strive to build a more constrained build system on top of it like the KDE guys did, it will serve GNOME much better in the long term, IMHO. Just though I'd let you know of my weekend research... :) Patch: http://www.gnome.org/~gjc/pygtk-scons.diff -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposing PyORBit for GNOME Bindings
Hello, I would like to propose PyORBit for GNOME Bindings. PyORBit was written by James Henstridge, providing Python bindings for ORBit2. Gnome Python, which is already part of GNOME Bindings, depends on pyorbit. My commitment towards pyorbit is to maintain it (review patches, fix small bugs, make releases), but I cannot promise any significant development on it. I believe this should not be a problem, since pyorbit is already very complete and stable. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Denoting Remote Machines (Re: Custom Icons for GNOME Terminal Profiles)
Ter, 2005-11-22 às 10:05 +0800, Davyd Madeley escreveu: On Mon, 2005-11-21 at 11:42 -0600, Shaun McCance wrote: To clear things up, there are two things being talked about here: First, changing the title of a gnome-terminal window based on some information, possibly the host you've logged into with your shell. And second, changing the title of any random window, based on which machine that window is actually running on. It looks a whole lot like this: http://davyd.ucc.asn.au/images/xclocks.png If you could use pango markup, I think it would be better if the (on ) part had a different style, to not confuse with the regular application title. I'm thinking along these lines: span size=\smaller\ style=\italic\(on %s)/span % host Anyway, nice work! -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing gobby?
Ter, 2005-11-15 às 10:21 -0800, Corey Burger escreveu: On 11/15/05, Chris Ball [EMAIL PROTECTED] wrote: Hi, I'm not the author of gobby[1], but I'd like to hear thoughts on whether gobby should be proposed for inclusion in Gnome 2.14. Gobby is a collaborative text editor using GtkSourceView/GTK 2.6, with external dependencies of libgmp, gtkmm and libxml++. There are two libraries that are maintained by the gobby authors used: libobby and libnet6. Collaborative editing is an application many people don't seem to have realised is possible with their computers; I think having it available such that two GNOME users can easily start a collaborative session together would be massively beneficial. Gobby is a lot of fun and a great piece of work, but having used this extensively at UBZ (along with the rest of the people there), we found some bugs[1] that might need to be addressed before we foist it on the unsuspecting user. I subscribe the good opinion about Gobby, generally, but the security of its network protocol leaves a lot to be desired. I captured the protocol stream with ethereal and, while there is a password based authentication scheme at session setup time, the remaining of the traffic passes essentially in clear text: neither authenticated nor encrypted. That is a potencial security hole. I wouldn't dare to do collaborative editing across the internet with Gobby, yet gobby allows this easily and doesn't even warn users of these dangers. Why can't the session passphrase be used to cypher the whole TCP stream? Surely that isn't so hard to do, these days. I'm sure there are ready made functions in openssl or gnutls libraries. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing gobby?
Qua, 2005-11-16 às 09:24 -0500, Eric Larson escreveu: On Wed, 2005-11-16 at 12:17 +, [EMAIL PROTECTED] wrote: On 11/16/05, Ross Burton [EMAIL PROTECTED] wrote: On Wed, 2005-11-16 at 11:54 +, Gustavo J. A. M. Carneiro wrote: I subscribe the good opinion about Gobby, generally, but the security of its network protocol leaves a lot to be desired. Agreed: whilst I'd like to use Gobby, the fact that the data is sent in plain-text isn't good. Some way of authenticating the servers/peers are who they say they are (think ssh host key fingerprints), and encrypted transport streams would be required before I'd use it for work. It seems to me that a collaborative editing feature in GNOME would be a really killer feature, but it should really happen in the applications that we all know and love. I would much prefer to use a GEdit, Abiword and ultimately OOo plugin to do this. What Gobby could offer is a library to handle this and a standard UI for establishing and maintaining connections. This would sacrifice Gobby for inclusion, but open the possibility for a general GNOME feature - Live Collaboration. It seems that the Gobby developers should provide a better idea regarding the intended use cases for Gobby. The argument that one would rather edit in something like GEdit may not really address the purpose of Gobby. Following the same logic, this potentially makes the lack of security features more understandable as well. I say this because one tool that addresses a specific collaboration need is better than forcing users to understand applications like Abiword, X-Chat and GEdit out of their original scope. To put this another way, why sacrifice the usability of something like Abiword or GEdit to support a corner case when Gobby can handle it more gracefully. This is the same for security concerns. Why force Gobby to deal with security when it may never really be needed. When it was used at GNOME summit, I don't believe that anyone would have any problems if someone was listening in on collaboration. This may be the primary use case (collaboration under a locally controlled network) they may merely need to be emphasized. Yes, I totally agree the security is sufficient for a local controlled network. OTOH, the software doesn't warn about potential security vulnerability when running over a WAN. I can picture this already (IM conversation): joe hey, we need to finish that lab report from the last class.. andy it's raining a lot... I'd rather stay at home... :| joe hey, I have an idea, let's use gobby and work this online andy great idea!.. here, connect to 194.117.99.11 port 12345 andy pass phrase 'secret' joe ok, i'm in! let's do this, then! [... half an hour later ...] andy WTF are you doing, you're deleting all our work! joe I'm not doing anything, I swear! andy sh*t, what's all this garbage? I've been hacked! :-/ joe crappy GNOME software, doesn't even have decent security :| You get the picture... :) This happens because the home user doesn't have any feeling for the limitations of the security of the protocol. Sure, the security can be adequate in some cases, but the end user doesn't know which cases, and just uses it even when not secure. Regards. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
