[Freeze break request] Nautilus: do not put a frame around images that have an alpha plane
Hi,
Attached a patch that makes sure that images don't get a frame.
Currently larger images than 128 pixels will always get framed, but
this can look ugly (see attached screenshot)
Patch has been approved by Alexander Larsson (Nautilus Maintainer).
Can this patch still go in? It's a trivial change and it makes the
desktop look better.
Regards,
Jaap
From bd97abd6133b8400493611052ccb0d0f83b35848 Mon Sep 17 00:00:00 2001
From: Jaap A. Haitsma
Date: Sat, 5 Sep 2009 12:34:22 +0200
Subject: [PATCH] Don't show frames around images with alpha plane
---
libnautilus-private/nautilus-file.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libnautilus-private/nautilus-file.c b/libnautilus-private/nautilus-file.c
index cfe5c5b..84d99ac 100644
--- a/libnautilus-private/nautilus-file.c
+++ b/libnautilus-private/nautilus-file.c
@@ -4165,8 +4165,8 @@ nautilus_file_get_icon (NautilusFile *file,
w * scale, h * scale,
GDK_INTERP_BILINEAR);
- /* We don't want frames around small icons */
- if (!gdk_pixbuf_get_has_alpha(raw_pixbuf) || s >= 128) {
+ /* We don't want frames around images with an alpha plane */
+ if (!gdk_pixbuf_get_has_alpha(raw_pixbuf)) {
nautilus_thumbnail_frame_image (&scaled_pixbuf);
}
g_object_unref (raw_pixbuf);
--
1.6.3.3
<>___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: Clutter core
On Mon, Aug 10, 2009 at 17:37, Emmanuele Bassi wrote: > hi everyone; > > I'm proposing to move Clutter (core) from the external dependencies to > the Desktop modules. > > I guess that, by now, everyone on this list knows what Clutter is; but > for the record: > > """ > Clutter is an open source software library for creating fast, visually > rich, portable and animated graphical user interfaces. > > Clutter uses OpenGL (and optionally OpenGL ES for use on Mobile and > embedded platforms) for rendering but with an API which hides the > underlying GL complexity from the developer. The Clutter API is intended > to be easy to use, efficient and flexible. > """ > > The dependencies: > - GLib and GObject > - Cairo > - Pango > - GDK-Pixbuf (optional, though strongly suggested on Linux) > > Current projects in GNOME 2.x that (optionally) depend on Clutter: > - GNOME Games > > Future projects in GNOME 3.0 that already depend on Clutter: > - Mutter > - GNOME Shell > > Clutter is API stable since 1.0.0, and will remain so for the duration > of the 1.x cycle. > > All major distributions package Clutter already. > Hi, Are you planning on using GNOME resources? (git, bugzilla, ftp on gnome.org) http://live.gnome.org/ReleasePlanning/ModuleProposing says that you need to do this Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugzilla Upgrade Scheduled For August 15-16
> > > If you have any questions about the upgrade in general, feel free to > respond on desktop-devel-list. > Maybe a good idea to tell everyone which features have not been ported yet. Otherwise you get a lot of mails which say something is not working which used to work I noticed that http://bugzilla-test.gnome.org/reports/weekly-bug-summary.cgi is not working Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A not about GtkBuilder conversion
On Fri, Jul 17, 2009 at 22:31, Christian Persch wrote: > Hi; > >> This is not how things are supposed to be done ! gtk-builder-convert >> is not something you should or can rely on as a build tool. It is >> purely a one-time conversion help, with the assumption that the >> generated .ui files are manually checked and used as the primary >> source afterwards. > > However it is not always feasible to do this. E.g. the module in > question, gnome-terminal, still keeps the original glade files since at > least at the time of its gtkbuilder conversion glade-3 was unable to > work with the converted .ui files. And it's not much use to use > gtbuilder files natively if one can't edit them afterwards! > .ui files can now perfectly be edited in glade-3 I attached a patch here http://bugzilla.gnome.org/show_bug.cgi?id=588945 OK to commit? Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Partial) GNOME 3 status update
On Tue, Jul 14, 2009 at 12:29, Felix Riemann wrote: > Am Montag, den 13.07.2009, 23:43 +0300 schrieb Marc-André Lureau: >> Hi >> > Hey! > >> On Mon, Jul 13, 2009 at 11:24 PM, Andre Klapper wrote: >> > Less than 5 modules with non-low Gtk-Deprecated-Symbols. >> > = >> > NOT COMPLETED (Progress compared to 2.27.3: 9->7). >> > complex: 2 (gnome-games, gnome-media) >> >> By getting rif of libglade in gst-properties, Felix Riemann also >> helped to drop some deprecated symbols. >> >> Felix can probably tell us better how far we are from having all the >> maintained part of gnome-media free of deprecated symbols. I have the >> feeling we are close to be clean. >> >> See http://bugzilla.gnome.org/show_bug.cgi?id=572353 >> > > Well, with gst-properties fixed, the default gnome-media install builds > fine with deprecated symbols disabled here. > > Regarding the non-default / deprecated widgets I'll take it like Thomas > Andersen in comment 9 in above bug: it makes no sense fixing them. > > * gst-mixer doesn't need any fixing and works with deprecated > symbols disabled already. (Note, this seems to be used at least > in Gentoo when building your system without PA) > * vu-meter would be doable but was written for ESD. Alternatives > already exist for PulseAudio, eg. with Lennart's own > pavumeter[1]. > * gnome-cd could be doable as well but AFAIR was replaced already > (not sure by whom right now, Sound-Juicer?, Rhythmbox?, Totem?) > * cddb-slave2 is from what I can see only left as a dependency of > gnome-cd. I guess most cd-player apps today use Musicbrainz > anyway, so there's probably not much use in fixing it. > Why don't we remove gst-mixer, vu-meter, gnome-cd and cddb-slave2 completely from gnome media 2.27. People that want to keep on building them can use the 2.26 branch Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3 status update
On Mon, Jun 22, 2009 at 20:20, Matthias Clasen wrote: > On Mon, Jun 22, 2009 at 2:06 PM, Vincent Untz wrote: >> Hi, >> >> Le lundi 22 juin 2009, à 13:30 -0400, David Zeuthen a écrit : >>> FWIW, Matthias done a great job both porting apps as well as creating / >>> maintaining this page >>> >>> http://fedoraproject.org/wiki/Features/PolicyKitOne >>> >>> which is useful for both distributors and the GNOME project itself. >>> >>> I guess all this means that PolicyKit doesn't even need to be an >>> external dependency anymore; e.g. basically no apps need to be aware it >>> even exists. >> >> So do we need to migrate all of GNOME at once (ie, commit all the >> patches at once)? Or is it possible to have both old and new PK at the >> same time on the system? > > It is possible. In fact, that is what we have in rawhide currently. > But we really want to have the migration completed before the release, > because it just completely breaks the experience if you have two > separate policies, two different policy editors, etc etc... > ___ Shouldn't the external dependency of policykit be bumped to 0.92 it's now at 0.9 Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On Wed, May 13, 2009 at 20:38, Owen Taylor wrote: > I wanted to provide some gnome-shell perspective here. > > In quick summary, we'd see including libseed in the GNOME-2.28 desktop > set as a positive step toward heavier use of Javascript in GNOME in the > future. > > Porting gnome-shell to Seed would certainly not be a big deal; I would > sigh in regret over losing const and let and destructuring assignment > (most over the last), but in the end, they don't determine the overall > feel of programming with Javascript; or whether Javascript is a good or > bad idea. > > (And conversely, if libseed didn't work out for some unforseeable > reason, we could easily port GNOME modules using it to gjs post 2.28, > with at most a week or two of feature work on gjs.) > > Quick comparison from my perspective between the two sets of systems: > > Spidermonkey: Mature, good API for extensibility. Nice language > extensions. (JS 1.7.) Mostly packaged as part of xulrunner, which is > a problem. Maintained by an organization that has a thorough > commitment to open source. (That doesn't mean that we have more > influence over the direction, necessarily, but is worth noting.) > > JavascriptCore: Newer, not used much outside of WebKit so far. > > GJS: Fairly limited set of features, but those that are there are > done well. > > Seed: More features, common features are quite compatible with GJS. > I'm not delighted with how GObject subclassing was done, but if we > have better proposals, we can certainly lobby and submit patches > to change things :-) > > (The big caveat from the above is that I haven't worked with Seed or > JavascriptCore at all.) > > Speed comparisons just don't matter for anything we are doing, and it's > not going to be long-term accurate either; what's faster now may not be > faster in 6 months. I'm more concerned about garbage collection, but > honestly both of the engines have garbage collectors that are tuned for > web page usage and not for the desktop. From discussions with Rob > earlier, Spidermonkey may have a slight lead in flexibility in this > area. > > The more important differences really are: > > - Alignment with HTML components in GNOME. The apparent trend towards > WebKit in Epiphany, Yelp, etc certainly gives a strong impetus to > going towards JavascriptCore and avoiding a Gecko dependency. > > - Activity of maintainership. Rob and Tim are appear committed to > libseed as a GNOME component and interested in it as a project > in its own right. The people at litl have done a good job with > gjs, but the work that they do on it is features that their code > needs. The work that we've done it from the gnome-shell side > are features that gnome-shell needs. > > Are we going to switch gnome-shell to libseed if it gets accepted as a > desktop module for 2.28. Not sure - it certainly would make it simpler > to compile gnome-shell as an add-on to a 2.28 distribution of GNOME. On > the other hand we're more comfortable with the gjs/SpiderMonkey codebase > at this point, and moving over might not be a good use of time. > Robert has offered to do the porting so that should not really eat up time. You only need to get used to libseed a bit after the port has been committed. To me that sounds like a fair price to pay. Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On Wed, May 13, 2009 at 03:18, Sandy Armstrong wrote: > On Tue, May 12, 2009 at 5:46 PM, Hubert Figuiere wrote: >> On 05/12/2009 08:01 PM, Robert Carr wrote: >>> >>> For 2.28, it may make sense to have both gjs and Seed as modules, and >>> try and keep code somewhat compatible. >>> >>> It's still not entirely clear which JavaScript engine is going to end >>> up being better long term, so we might not want to completely commit >>> to one yet. >> >> >> With that plan, it is -1 from me. 2 engines is one too many IMHO. > > We'll have two engines if Epiphany moves to webkit and gnome-shell > sticks with gjs. > > If the only user of gjs in GNOME is gnome-shell, and the gnome-shell > developers are happy with a move to Seed (have we heard from them on > this yet?), then I am +1 for Seed's inclusion and gjs' exclusion. > > I agree with Hubert that sending mixed messages about browser/js > engines is not a good idea. > I agree +1 for seed. Robert, Can you commit to put in the few days work to make a patch for gnome-shell to use libseed? I think that makes it easy for the gnome-shell developers to go to libseed Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mailto: now all of a sudden necessary in DOAP file
On Sun, Apr 26, 2009 at 00:58, Philip Withnall wrote: > On Sat, 2009-04-25 at 17:08 -0500, Shaun McCance wrote: >> On Sat, 2009-04-25 at 23:58 +0200, Ruben Vermeersch wrote: >> > On Sat, 2009-04-25 at 15:46 -0500, Shaun McCance wrote: >> > > Any rdf:resource should always be a URL. An email address >> > > is not a URL. The correct thing to do is to use a mailto: >> > > URL. >> > > >> > > The fact that Pulse didn't have mailto: in its templates >> > > and that we put bogus info on live.gnome.org just shows >> > > that we messed up. >> > > >> > > Sorry for the confusion. >> > >> > Does this mean we should all update our doap files? >> >> That would be preferable. At the moment it's not >> breaking anything that I know of. For our internal >> tools, we can account for this hiccup. But if other >> parts of the world consume these files, they might >> not understand it. > > Let's not put hacks in our tools barely a week after they're first > introduced, please? > Is it possible to put something in the pre-commit script that checks the doap file whenever there is a push to git.gnome.org and gives a warning when the doap file is not correct. Currently it only checks commits of a doap file. What I'm proposing is to do it for all commits. Otherwise existing incorrect doap files probably won't get updated Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Correcting a typo on gnome websites
Hi, My understanding is that for updating a gnome website I need to checkout the gnomeweb-wml module. However a clone of this module is about 500MB. Cloning such a repo on a slow internet connection takes quite some time. Isn't there a handier way to do this? Thanks Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
mailto: now all of a sudden necessary in DOAP file
Hi, I've just tried to add a doap to netspeed. However pushing failed. --- ERROR: netspeed.doap is not valid: Invalid foaf:mbox property should be a mailto: URL Please see: http://live.gnome.org/MaintainersCorner#maintainers --- error: hooks/pre-receive exited with error code 1 If you go the wiki page there is no mailto: URL just an email address in foaf:mbox property So what's the rule does there have to be a mailto: and the wiki page needs to be updated or is it a bug in the commit script. Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bumping telepathy-glib to 0.7.27 (Empathy needs that version)
Hi, I just noticed when using jhbuild that empathy needs 0.7.27 of telepathy-glib. OK to bump the version in jhbuild and http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: R: git migration - svn:externals
Hi, I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it uses ffmpeg which is in svn. Jaap On Thu, Apr 23, 2009 at 09:55, Matteo Settenvini wrote: > Hi Owen, > > I'm not entirely sure (bazaar user here), however I think > that git has the notion of submodules: > http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html > > Matteo > >> > Messaggio originale >>Da: j...@jsschmid.de >>Data: 23-apr-2009 8.06 AM >>A: "Owen Taylor" >>Cc: "desktop-devel-list" devel-l...@gnome.org> >>Ogg: git migration - svn:externals >> >>Hi! >> >>svn:externals are not migrated at all. That breaks anjuta-extras module >>(b.g.o #579867) and gtkmm (fixed by duplicating files now). >> >>Is there anything we can do to fix it? Duplicating files is a quite weak >>and ugly solution. >> >>Regards, >>Johannes > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to remove remote branch with git?
On Sat, Apr 18, 2009 at 22:28, Frederic Peters wrote: > Jaap A. Haitsma wrote: > >> I just did my first commit with git (Yay!!). However I first made a >> mistake and made a new remote branch called jaap in the cheese >> project. >> I now want to remove that branch because it was a mistake. How do I do this? >> What I read from the web I need to do the following >> >> git push ssh://jhait...@git.gnome.org/git/cheese origin :jaap > > What about "git push origin :jaap" ? > This works when I have a clone of ssh://jhait...@git.gnome.org/git/cheese . So now I removed it :-) However I had a checkout of jhbuild which does public clones. Is there a way to do it when you have a public clone Thanks Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
How to remove remote branch with git?
I just did my first commit with git (Yay!!). However I first made a mistake and made a new remote branch called jaap in the cheese project. I now want to remove that branch because it was a mistake. How do I do this? What I read from the web I need to do the following git push ssh://jhait...@git.gnome.org/git/cheese origin :jaap However I get the following error messages. fatal: refs/remotes/origin/HEAD cannot be resolved to branch. fatal: The remote end hung up unexpectedly What do I do wrong? Thanks Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependencies, DeviceKit-power and GNOME Power Manager
> interaction e.g. for device locking). If a few core modules (gvfs, > nautilus, gnome-mount) are ported to hal, we should be in good shape > for 2.26. > You probably mean migrated to DeviceKit (or migrated away from hal) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
Hi, It's overhere http://svn.galago-project.org/trunk/ Jaap 2008/11/16 natan yellin <[EMAIL PROTECTED]>: > Where is the code currently hosted? > > I'd like to play around with this if I have time. > > -Natan > 2008/11/6 Christian Hammond <[EMAIL PROTECTED]> >> >> I can assure you that this hasn't bit-rotted. It has been in development, >> but my work on Unity at VMware this past year basically took up all my free >> time. >> >> I would be happy to have people who want to contribute and fix bugs. I >> plan to keep the roll as maintainer, and have a couple people in mind for a >> co-maintainer. If people really want certain things in or fixed, by all >> means, submit patches. Nobody has done so in a while and nobody's really >> been complaining about anything to my knowledge, so I haven't felt that a >> release was that urgent. Still, there are some important fixes in SVN, some >> of which were waiting for additional patches that I never got and only >> recently had time to finish up. I should be in a good position to do a >> release soon. >> >> Christian >> >> -- >> Christian Hammond - [EMAIL PROTECTED] >> VMware, Inc. >> >> >> On Thu, Nov 6, 2008 at 8:46 AM, Patryk Zawadzki <[EMAIL PROTECTED]> >> wrote: >>> >>> On Thu, Nov 6, 2008 at 5:30 PM, A. Walton <[EMAIL PROTECTED]> wrote: >>> > There are other maintenance-related issues to bring up as well, like >>> > the duplicated functionality in having both >>> > notification-daemon+libnotify and libcanberra doing sound >>> > notifications (tiny amount of code we could drop from the n-d >>> > implementation, since it seems libcanberra is/will be better taken >>> > care of, at least for now). Either way, it would be nice to at least >>> > see the notification stuff imported into GNOME's tree, where more >>> > people are likely to put eyes on it and be able to do things such as >>> > roll releases, squash a couple of tiny leaks Ubuntu is shipping >>> > patches for, etc. It would be a big step forward just to get that far. >>> >>> Hell, I know almost nothing about its internals but still would be >>> willing to become a maintainer if needed (maybe I wouldn't do much in >>> terms of real programming time but I sure can review and commit >>> patches). It's just too useful to let it bit-rot. Over time we can >>> adjust the feature set and/or the API (should not be a huge problem as >>> long as we update libnotify as well). >>> >>> -- >>> Patryk Zawadzki >>> ___ >>> 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 > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal GNOME Goal: Replace gnome_help and gnome-open calls with gtk_show_uri
I've added gtk_widget_get_screen to the example code Jaap On Sat, Nov 15, 2008 at 23:54, Thomas H.P. Andersen <[EMAIL PROTECTED]> wrote: > On Sat, Nov 15, 2008 at 3:59 PM, Jaap A. Haitsma <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Quite some people already are implementing this goal >> >> http://live.gnome.org/GnomeGoals/RemoveGnomeOpenGnomeHelp >> >> What about making it an official goal for GNOME 2.26? > > Would it make sense to have an official policy to accept goals > proposed on d-d-l after a few days without protests? It seems to me > that a lot of goals never took off because they were never officially > blessed. > > Comments on the gnome help goal: > We might as well set the screen correctly rather than just pass NULL. > The goal might as well suggest to use gtk_widget_get_screen on the > window to get the screen. The window is used later in the example > anyway. > > This is the definition of the gnome goals taken from l.g.o/GnomeGoals: > "Setting small concrete goals that we should all try to achieve could > definitely help with our work in integration and consistency. The > goals may vary a lot, don't need to be ambitious, don't need to be > about code. But they need to be achievable in a small timeframe. They > are the GNOME goals." > In light of this I would suggest to narrow the scope of this > particular goal to only handle modules using C. This would make it > both more concrete and easier to achieve in a small timeframe. > > Lastly, while on the topic of gnome goals, I hate the ambiguous "to > do" status. Currently I am not able to tell if it means that no one > has investigated if the module is affected by the goal or if it means > that there is work to be done for that module. > > - thomas > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposal GNOME Goal: Replace gnome_help and gnome-open calls with gtk_show_uri
Hi, Quite some people already are implementing this goal http://live.gnome.org/GnomeGoals/RemoveGnomeOpenGnomeHelp What about making it an official goal for GNOME 2.26? Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Goal: Remove gnome-open and gnome_help calls
Hi, Since 2.13.1 GTK+ has a call called gtk_show_uri which can open all kind of files and can be used as a replacement from call to to gnome-open and gnome_help which are in the deprecated libgnome library. I was wondering if we now can make this [1] an official GNOME goal. Jaap [1] http://live.gnome.org/GnomeGoals/RemoveGnomeOpenGnomeHelp ___ 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, Jun 30, 2008 at 1:50 PM, Vincent Untz <[EMAIL PROTECTED]> wrote: > Le dimanche 29 juin 2008, à 22:02 +, Stef a écrit : >> I've been implementing some parts of seahorse (and maybe soon >> gnome-keyring) in Vala. >> >> http://live.gnome.org/Vala >> >> I'm assuming this is an acceptable thing for a gnome module to do, as it >> adds no new dependencies (build-time or run-time). >> >> However it does add a 'hacking' dependency. > > Hrm, how do you do the hacking dependency without the build dependency? > make dist results in a tarball with the C files, so you don't need a vala compiler to build the tarball Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: defunct processes in 2.23?
On Mon, Jun 23, 2008 at 1:26 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > On Mon, Jun 23, 2008 at 12:13 AM, Claudio Saavedra <[EMAIL PROTECTED]> wrote: >> I did some quick tests and it seems like the checks in GVFS's >> configure.ac for libhal_get_all_devices_with_properties succeed if you >> have installed libhal-dev 0.5.11 from your distro. Removing libhal-dev >> caused gvfs to disable the "fast init path" thing: >> >> Use HAL for volume monitor: yes (with fast init path: no) >> >> I guess that what happens otherwise, is that gvfs is linked against >> libhal in /opt/gnome-2.24 (currently 0.5.10), which doesn't have >> libhal_get_all_devices_with_properties, and then we have the resulting >> processes dying. > > My system does not have hal 0.5.10 anywhere (I'm using 0.5.11) yet I > still get the zombie processes on login. I have 2.23 installed as my > main desktop, not via jhbuild or anything else (I package and install > GNOME 2.23 rpms as modules get released). > What's in your ~/.xsession-errors file? Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: defunct processes in 2.23?
On Sun, Jun 22, 2008 at 3:00 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > On Sun, Jun 22, 2008 at 1:51 AM, Claudio Saavedra <[EMAIL PROTECTED]> wrote: >> Ajoh, >> >> I'm still experiencing some processes dying upon startup and being left >> as defunct: >> >> [EMAIL PROTECTED]:~$ ps ax | grep defun >> 6688 tty1 Z 0:00 [gnome-session-s] >> 6701 tty1 Z 0:00 [gnome-power-man] >> 6702 tty1 Z 0:00 [gnome-volume-ma] >> 6703 tty1 Z 0:00 [nm-applet] >> 6708 tty1 Z 0:00 [gnome-user-shar] >> 6709 tty1 Z 0:00 [bluetooth-apple] >> 13583 pts/1R+ 0:00 grep defun >> >> Any hint on what to do, who to poke, or which bug report to subscribe me >> to? > > Same here since 2.23.1 but since 2.23.3 or .4 they at least go away > once you logout ;) > > -- I also had this when rebuilding building GNOME from source. It now works again :-) What happened was the following. GVFS was somehow compiled with HAVE_HAL_FAST_INIT equals 1. This meant that libhal_get_all_devices_with_properties was available. However jhbuild installls hal 0.5.10 and libhal_get_all_devices_with_properties is only available in 0.5.11. My ~/.xsession-errors contained an error of gnome-panel which made a call where libhal_get_all_devices_with_properties was not found. Upgrading to hal 0.5.11 fixed everything for me Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild status for 2.23.x
> - gnome-session doesn't seem to work. When logging in it just hangs and > I see a zombie gnome-login-sound(?) process. Tried running gconf-editor > to turn off the sound server but that didn't help. > I also had this when rebuilding building GNOME from source. It now works again :-) What happened was the following. GVFS was somehow compiled with HAVE_HAL_FAST_INIT equals 1. This meant that libhal_get_all_devices_with_properties was available. However jhbuild installls hal 0.5.10 and libhal_get_all_devices_with_properties is only available in 0.5.11. My ~/.xsession-errors contained an error of gnome-panel which made a call where libhal_get_all_devices_with_properties was not found. Upgrading to hal 0.5.11 fixed everything for me Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild status for 2.23.x
Kjartan, > - gnome-session doesn't seem to work. When logging in it just hangs and > I see a zombie gnome-login-sound(?) process. Tried running gconf-editor > to turn off the sound server but that didn't help. > Did you manage to solve this? When I start my jhbuild gnome session I don't see the desktop but just the background color of GDM (In my case brown because I run ubuntu) My account has the following processes running avahi 5377 0.0 0.1 2880 1512 ?Ss 11:11 0:00 avahi-daemon: running [guzzi.local] guzzi12455 0.0 0.4 7484 4540 ?S13:48 0:00 /usr/lib/libgconf2-4/gconfd-2 4 guzzi12457 0.0 0.2 14340 2056 ?S13:48 0:00 /usr/bin/gnome-keyring-daemon -d --login guzzi12459 0.0 0.6 30748 6500 ?Ssl 13:48 0:00 gnome-session guzzi12599 0.0 0.6 22604 6196 ?Ss 13:48 0:00 /usr/bin/seahorse-agent --execute /usr/bin/jhbuild-session guzzi12609 0.0 0.0 2924 676 ?S13:48 0:00 dbus-launch --exit-with-session guzzi12613 0.0 0.1 2760 1176 ?Ss 13:48 0:00 /opt/gnome2/bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session guzzi12614 0.0 0.3 14580 3440 ?S13:48 0:00 /opt/gnome2/lib/gnome-session/helpers/gnome-keyring-daemon-wrapper guzzi12620 0.1 0.8 42088 8968 ?Ssl 13:48 0:00 /opt/gnome2/libexec/gnome-settings-daemon guzzi12623 0.0 0.0 0 0 ?Z13:48 0:00 [gnome-login-sou] guzzi12691 0.0 0.0 0 0 ?Z13:48 0:00 [gnome-volume-ma] guzzi12692 0.0 0.0 0 0 ?Z13:48 0:00 [gnome-power-man] guzzi12693 0.0 0.4 15744 4860 ?S13:48 0:00 /opt/gnome2/libexec/gnome-user-share guzzi12694 0.0 0.4 22684 4784 ?Ss 13:48 0:00 /opt/gnome2/libexec/gnome-volume-manager --sm-disable guzzi12695 0.0 0.0 0 0 ?Z13:48 0:00 [pk-update-icon] guzzi12696 0.0 0.7 18248 7376 ?S13:48 0:00 gpk-update-icon guzzi12699 0.0 0.1 4896 1840 ?S13:48 0:00 /usr/bin/obex-data-server --no-daemon guzzi12700 0.0 0.1 3768 1220 ?S13:48 0:00 /bin/bash /usr/bin/conduit -i guzzi12702 0.2 1.1 32612 11712 ?SNl 13:48 0:01 trackerd guzzi12705 0.0 0.0 0 0 ?Z13:48 0:00 [gnome-at-visual] guzzi12708 0.0 1.1 47724 11680 ?Sl 13:48 0:00 empathy guzzi12710 0.0 0.0 0 0 ?Z13:48 0:00 [nm-applet] guzzi12711 0.3 2.8 92096 29364 ?Sl 13:48 0:01 /usr/bin/python /usr/bin/conduit.real -i guzzi12712 0.0 0.6 29000 7052 ?S13:48 0:00 bluetooth-applet --singleton guzzi12713 0.0 0.5 16956 5704 ?S13:48 0:00 tracker-applet guzzi12717 0.0 0.8 25868 9152 ?Ss 13:48 0:00 gnome-power-manager guzzi12786 0.0 0.3 5604 3324 ?S13:48 0:00 /opt/gnome2/libexec/mission-control guzzi12792 0.0 0.3 24164 3140 ?Ssl 13:48 0:00 /opt/gnome2/libexec/bonobo-activation-server --ac-activate --ior-output-fd=20 guzzi12797 0.1 0.4 7600 4804 ?S13:48 0:00 /opt/gnome2/libexec/telepathy-gabble guzzi12799 0.0 0.2 15856 2236 ?Ss 13:48 0:00 gnome-screensaver guzzi12817 0.0 0.5 27744 5812 ?Sl 13:49 0:00 /opt/gnome2/libexec/evolution-data-server-2.24 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_BookFactory:1.2 --oaf-ior-fd=17 guzzi12827 0.0 0.3 9760 3652 ?S13:49 0:00 /opt/gnome2/libexec/gnome-vfs-daemon Thanks Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changing bookmarks file location
2008/6/1 Philip Withnall <[EMAIL PROTECTED]>: > On Sun, 2008-06-01 at 20:20 +0100, Don Scorgie wrote: >> This has been brought up for a number of projects in GNOME [1]. I >> wonder if we could / should reach some consensus on the best way to do >> this across all modules? I've been holding off doing this in yelp >> because I can't think of a good way to go about it. > > I would suggest adding the changes for all the modules to some script > which would get run either when you upgrade GNOME, or just once on > session start. However, this does have the problem of moving > module-specific changes out of the module and into an aggregate area, > which may or may not work. > This will lead to all kind of problems if you don't upgrade all the packages or are just building some stuff from SVN Best solution is my opinion the suggestion of Patryk 1) Check new location for conf file 2) If not found copy from old location to new location (do not move the file because their might be an old version of the app on the machine) 3) Put in the NEWS file that new location is used. This has a couple of advantages. 1) No performance overhead 2) Old apps don't break In the end the old files will just dissappear because users reinstall their OS or just remove the file if they have read the NEWS file People who don't know the reason why migration to ~/.config should read http://live.gnome.org/GnomeGoals/XDGConfigFolders Can this goal be promoted to an official GNOME goal? Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Something wrong with SVN access?
On Thu, May 15, 2008 at 10:00 PM, Sandy Armstrong <[EMAIL PROTECTED]> wrote: > http://tinyurl.com/56vsoa > I see that I received the mail but didn't read it. A better subject would have helped here I think "Developer/SSH Access to GNOME servers has been disabled!!! (Please check your ssh keys)" as a subject would have increased the probability that I had read the mail Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Something wrong with SVN access?
Hi, When I check out code with my gnome account I get prompted for a password and I don't have a clue which password it needs to be. svn co svn+ssh://[EMAIL PROTECTED]/svn/vala/trunk vala-trunk [EMAIL PROTECTED]'s password: Normally I always got prompted for my ssh passphrase. Anybody knows what's wrong? Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkLove/PatchTriaging
On Wed, Apr 16, 2008 at 9:19 AM, Diego Escalante Urrelo <[EMAIL PROTECTED]> wrote: > Hey! > > I took some minutes to try a bunch of the patches in the bottomless > pit of GTK+ bugzilla, I put the results of my triaging in > live.gnome.org: > > http://live.gnome.org/GtkLove/PatchTriaging > > Most of what I checked can be solved quickly since there are a lot of > one-liners and nice useful patches. About 6 patches are available in > docs section, and I think you can agree with me that they can be just > downloaded, read, committed. > I consider that the 15 patches I marked as "Small action required to > close" in the wiki can be reviewed and closed in a matter of minutes. > > So you can imagine the purpose of this email: gtk+ maintainers, please > commit patches/mark commit_now/close such bugs :). > > I marked some of the trivial patches I triaged as reviewed, I left > more complicated stuff as-was. All the bugs I triaged are commented in > the wiki. > > Sorry if I broke something or disturbed the order of universe for > someone, as always it's all with the best of intentions :). > > Hopefully more people will join the triaging. > Nice work, but what about having keyword (trivial-patch ?) in bugzilla for these patches. It's easier than listing it on a wiki page Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Why do GNOMEdevelopers almost exclusively use git mirrors and for example not bzr mirrors
Hi, I was just wondering why many GNOME developers are using git mirror and for example not a bzr mirror? If I for example read http://live.gnome.org/DistributedSCM I have the feeling that bzr would also be a very good fit. However I haven't seen any gnome.org project in a bzr mirror while of many projects there exists git mirrors. Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Icon Theme Testing
On Sun, Mar 30, 2008 at 9:17 PM, Rodney Dawes <[EMAIL PROTECTED]> wrote: > Holas, > > As you may have read in the minutes for the recent Artwork Meeting, > at http://live.gnome.org/ArtMeeting080329 , we have decided that the > best way to improve the usage of the Icon Naming Spec throughout the > desktop, is to avoid having the compatibility symlinks installed by > icon-naming-utils, during the development period. > > This works similar to how we disable fatal criticals for applications > via gnome-session. I have committed the changes to gnome-icon-theme > trunk to make this work. It simply checks that the minor version number > is not an even value, and disables the requirement and usage of the > icon-naming-utils script for odd valued minor version numbers. > > What this means for you, as a developer, is that your application may > "break" by having no icon, or showing the missing icon image from GTK+ > instead. If this occurs, you should file a bug against YOUR APPLICATION > and NOT AGAINST gnome-icon-theme. You may, however, add one of use > gnome-icon-theme developers to the CC: list for the bug, so that we may > help assess the problem, and provide direction and feedback for what > icon name to use instead. Before and after crops of screen shots will > be helpful attachments to the bug as well. > > This is to help expose problems in the desktop during the development > cycle in the same way we do with fatal critical errors now. The > compatibility links will be re-enabled in the final stable releases, > just as fatal criticals are disabled for them. > Good idea. * A possible improvement Setup a mailing list for icon artists on gnome.org and let people put that email address on the cc of the bugreport. Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Goal: Use GtkBuilder i.s.o libglade?
Hi, What about making this [1] an official goal? Jaap [1] http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Disabling building of gnome-cd and cddb-slave in gnome-media. Any objections?
On Mon, Mar 24, 2008 at 7:13 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote: > > > On Mon, 2008-03-24 at 19:04 +0100, Jaap A. Haitsma wrote: > > On Mon, Mar 24, 2008 at 6:26 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, 2008-03-24 at 16:57 +0100, Jaap A. Haitsma wrote: > > > > > > > > > > Hi, > > > > > > > > We would like to disable building of gnome-cd and cddb-slave by > > > > default in the gnome-media package, because there are much better > > > > alternatives such as sound juicer and rhythmbox. Furthermore gnome-cd > > > > and cddb-slave use the deprecated libgnome libraries. So it also helps > > > > with the goal of not using these deprecated libraries anymore. > > > > > > > > Does anybody have objections against disabling gnome-cd and cddb-slave > > > > by default? > > > > > > Same here, disabled in Fedora as well. > > > > > > > Maybe we should even remove it from SVN, since it seems that almost > > nobody is shipping it. Furthermore gnome-cd and cddb-slave haven't had > > any significant commits for a long time. > > Sound-juicer isn't up to scratch for proper CD playback (ie. not just > looking for which track to rip), and we don't have a replacement in the > desktop yet (Rhythmbox or other). > > So it should stay in but disabled for now. > Based on the feedback we committed a patch that disables gnome-cd and cddb-slave by default Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Disabling building of gnome-cd and cddb-slave in gnome-media. Any objections?
On Mon, Mar 24, 2008 at 6:26 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote: > > On Mon, 2008-03-24 at 16:57 +0100, Jaap A. Haitsma wrote: > > > > Hi, > > > > We would like to disable building of gnome-cd and cddb-slave by > > default in the gnome-media package, because there are much better > > alternatives such as sound juicer and rhythmbox. Furthermore gnome-cd > > and cddb-slave use the deprecated libgnome libraries. So it also helps > > with the goal of not using these deprecated libraries anymore. > > > > Does anybody have objections against disabling gnome-cd and cddb-slave > > by default? > > Same here, disabled in Fedora as well. > Maybe we should even remove it from SVN, since it seems that almost nobody is shipping it. Furthermore gnome-cd and cddb-slave haven't had any significant commits for a long time. Opinions? Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Disabling building of gnome-cd and cddb-slave in gnome-media. Any objections?
Hi, We would like to disable building of gnome-cd and cddb-slave by default in the gnome-media package, because there are much better alternatives such as sound juicer and rhythmbox. Furthermore gnome-cd and cddb-slave use the deprecated libgnome libraries. So it also helps with the goal of not using these deprecated libraries anymore. Does anybody have objections against disabling gnome-cd and cddb-slave by default? Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Recommended way to cleanup your own gobject types in a desktop app (finalize and/or dispose)
Hi, When I look at projects like gnome-screensaver and gnome-power-manager I see that for their own created gobject types only the finalize function is implemented to cleanup the resources in the end of the application. gnome-volume-control uses only implements the dispose function I understand from [1] that the two cleanup function dispose and finalize exist to make bindings to languages with garbage collection easier. So I guess for libraries for which other language bindings might be written it's a good thing to follow the recommendation in [1] of what to do in finalize and dispose. So what is recommended for applications? 1) implement dispose and finalize as recommended 2) only finalize 3) only dispose Jaap [1] http://library.gnome.org/devel/gobject/unstable/gobject-memory.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help sanity check the release notes
On Sun, Mar 2, 2008 at 2:48 AM, Shaun McCance <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-02-27 at 22:04 +0900, Davyd Madeley wrote: > > > All, > > > > Because my GNOME 2.22 isn't actually working very well, the release > > notes currently contain a lot of FIXMEs and XXX entries. This is > > suboptimal. > > > > What this means is that if you think you have a stake in the release > > notes, you should sanity check them for me. It's really easy to do: > > > > Step 1. Check them out from SVN: > > svn co > svn+ssh://svn.gnome.org/svn/gnomeweb-wml/trunk/www.gnome.org/start/2.22/ > release-notes-2.22 > > > > Step 2. Load release-notes.xml in Yelp > > > > Step 3. Read, make notes or send patches. Pay special attention to > > anything marked XXX or FIXME (could be in a comment). > > > > Andreas Nilsson has volunteered to do the screenshots this time round. > > Thanks Andreas! > > I would like to do a final pass for language stuff, but only > after the maintainers have all had their say. Just let me\ > know when you're ready to freeze for the translators. > FTP support has been added to GVFS SVN in the last couple of days. So I think the remark in rndevelopers.xml that FTP is not supported is obsolete. Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal?:Using g_app_info_launch_default_for_uri instead of deprecated gnome_help* functions
On Feb 3, 2008 7:55 PM, Jaap A. Haitsma <[EMAIL PROTECTED]> wrote: > On Feb 3, 2008 4:00 PM, Christian Kirbach > <[EMAIL PROTECTED]> wrote: > > On Sun, 03 Feb 2008 17:27:37 +0400, Jaap A. Haitsma <[EMAIL PROTECTED]> > > wrote: > > > > > gnome_help is however part of the deprecated libgnome > > > library. Another approach that programs currently use is launching > > > help or other programs with gnome-open or xdg-open > > > > > What about starting a wiki page tracking progress on this? (I'm > > > volunteering to set it up) > > > > Sounds like a real GnomeGoal to me. Feel free to set up a new (proposed) > > GnomeGoal and > > its associated wiki page at [1]. > > I've set it up: > http://live.gnome.org/GnomeGoals/RemoveGnomeOpenGnomeHelp > > What's needed to make it a real GNOME Goal? > GTK 2.15 As Christian Persch mentioned on the wiki is that we GdkAppLaunchContext which is in GTK 2.15. So better to wait for this goal for GNOME 2.24 Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal?:Using g_app_info_launch_default_for_uri instead of deprecated gnome_help* functions
On Feb 3, 2008 4:00 PM, Christian Kirbach <[EMAIL PROTECTED]> wrote: > On Sun, 03 Feb 2008 17:27:37 +0400, Jaap A. Haitsma <[EMAIL PROTECTED]> > wrote: > > > gnome_help is however part of the deprecated libgnome > > library. Another approach that programs currently use is launching > > help or other programs with gnome-open or xdg-open > > > What about starting a wiki page tracking progress on this? (I'm > > volunteering to set it up) > > Sounds like a real GnomeGoal to me. Feel free to set up a new (proposed) > GnomeGoal and > its associated wiki page at [1]. I've set it up: http://live.gnome.org/GnomeGoals/RemoveGnomeOpenGnomeHelp What's needed to make it a real GNOME Goal? Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Goal?:Using g_app_info_launch_default_for_uri instead of deprecated gnome_help* functions
Hi,
Currently many gnome programs use gnome_help* functions to show the
help functions. gnome_help is however part of the deprecated libgnome
library. Another approach that programs currently use is launching
help or other programs with gnome-open or xdg-open
I just patched cheese to use g_app_info_launch_default_for_uri
("ghelp:cheese", NULL, NULL) for launching help.
What about starting a wiki page tracking progress on this? (I'm
volunteering to set it up)
Jaap
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Where to put X-GNOME-Bugzilla-ExtraInfoScript?
On Jan 28, 2008 12:15 AM, Bastien Nocera <[EMAIL PROTECTED]> wrote: > > On Sun, 2008-01-27 at 18:45 +0100, Vincent Untz wrote: > > Le dimanche 27 janvier 2008, à 18:31 +0100, Jaap A. Haitsma a écrit : > > > Hi, > > > > > > Is there a recommended place, where you should install a bugreport > > > script specified in X-GNOME-Bugzilla-ExtraInfoScript? > > > > > > 1) gnome-power-manager installs it in /usr/bin > > > 2) gedit installs it in /usr/lib/gedit-2 > > > > I think that the gedit way is better (since the script is not something > > that should be runned by users, and the FHS recommends /usr/lib in such > > cases). > > Make that $(libexecdir) in the Makefile, and Debian will be happy as > well as the rest of us ;) > I'd like to make you and the rest happy but as somebody who just copies Makefiles and configure scripts of other projects I'm afraid I need a bit more explanation Thanks Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Where to put X-GNOME-Bugzilla-ExtraInfoScript?
Hi, Is there a recommended place, where you should install a bugreport script specified in X-GNOME-Bugzilla-ExtraInfoScript? 1) gnome-power-manager installs it in /usr/bin 2) gedit installs it in /usr/lib/gedit-2 Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: cheese
> > > 4) And as Shaun is mentioning, we need a manual > > there is a bug! ehm somewhere... hmm.. > http://bugzilla.gnome.org/show_bug.cgi?id=480628 > > jaap: should we forward that to the doc team? I've filed an issue at GNOME GHOP http://code.google.com/p/google-highly-open-participation-gnome/issues/detail?id=81 Let's see if we can get new contributors. If that doesn't work we can ask GNOME doc team > 5) vincent needs some more ice to be convinced ;) > > > > > I think it's better to wait for 2.24 > > i dont want to take that decision. but in my opinion its getting close: > feature freeze is on january 17th. that means we would have to finish > our feature list by that date. is that possible? > A lot is possible, but realistically I don't know. Problem I set is that by that time we won't have had widespread testing Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: cheese
On Dec 21, 2007 9:06 PM, Shaun McCance <[EMAIL PROTECTED]> wrote: > On Thu, 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 > > > This is an analysis of the documentation, made on behalf of the > Gnome Documentation Team. It does not necessarily reflect my > personal opinion of the module or its suitability for inclusion > in Gnome. In many cases, I have not made extension use of the > applications or libraries provided. Further insufficiencies in > the documentation may become more apparent with more use. > > > Cheese has a manual, though it is largely a stub, and it hasn't > seen any commits in two weeks. The Cheese developers have not > approached the Gnome Documentation Team about the documentation. > > (Reminder: proposing an undocumented module is not a problem. > Hackers are often not good writers, and we don't expect that > people bring fully documented programs to our doorstep. But > if you need documentation help, you need to contact us early.) > I'm one of the developers of cheese and feel that cheese is not ready yet for inclusion because 1) We completely refactored the gstreamer backend and haven't had a release since. So I'm not sure if it works well for every webcam 2) Cheese needs more HIG love 3) Also feature wise it needs some more things for it to be 1.0 material (preference dialog, ability to select multiple items in the icon view 4) And as Shaun is mentioning, we need a manual I think it's better to wait for 2.24 Jaap ___ 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 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 Copy the resulting waf script to your project directory 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/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bumping avahi requirement for GNOME to 0.6.21
On Nov 12, 2007 11:20 PM, Olav Vitters <[EMAIL PROTECTED]> wrote: > On Sun, Nov 11, 2007 at 02:21:32PM +0100, Jaap A. Haitsma wrote: > > Vinagre which is proposed for the desktop needs at least 0.6.17 > > because it contains new functionality. In the meantime the avahi > > developer already released newer versions which according to the > > website are bugfix versions [2] > > > > Because many distros are already shipping 0.6.20 or 0.6.21 I propose > > to bump the minimal requirement to 0.6.21 (released in august 2007). > > and thus changing the requirement to be higher than what is available in > many distros?!? > > Why not just bump to the minimum workable version? Meaning, 0.6.17? Why > aim for 0.6.21? > > If these are just bugfix versions, then I do not see the point of > requiring anything newer than 0.6.17. OK, I think I had the wrong understanding of it. I guess it's necessary to keep the version as low as possible so that many people can compile it from SVN by just installing developing packages from their distro. Correct? In that case I ask to bump it to 0.6.17 Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bumping avahi requirement for GNOME to 0.6.21
Hi, Currently the minimum requirement for avahi is 0.6.16 in GNOME [1]. Vinagre which is proposed for the desktop needs at least 0.6.17 because it contains new functionality. In the meantime the avahi developer already released newer versions which according to the website are bugfix versions [2] Because many distros are already shipping 0.6.20 or 0.6.21 I propose to bump the minimal requirement to 0.6.21 (released in august 2007). Because of the version bump also libdaemon needs to be bumped to 0.12 but it's only used by avahi. I've attached the jhbuild patch already in bugzilla [3] Can I apply the patch? Jaap [1] http://live.gnome.org/TwoPointTwentyone/ExternalDependencies [2] http://avahi.org/ [3] http://bugzilla.gnome.org/show_bug.cgi?id=446075 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Only one instance of a capplet should be allowed
Hi, Currently it is possible to fire up a capplet multiple times. This can be confusing for users [1]. It would be better if a capplet was launched for the second time that the window of the currently running applet was raised. In [1] it is suggested to use a dbus server for this, but this seems overkill to me. Is there another easy way to do this? Jaap [1] http://bugzilla.gnome.org/show_bug.cgi?id=331826 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
