Re: Using the Unicode ellipsis (…) instead of three periods
on., 05.12.2012 kl. 09.56 -0500, skrev Shaun McCance: On Tue, 2012-12-04 at 17:24 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 1:48 PM, Philip Withnall phi...@tecnocode.co.uk wrote: On Tue, 2012-12-04 at 09:51 -0500, Matthias Clasen wrote: On Tue, Dec 4, 2012 at 9:21 AM, Shaun McCance sha...@gnome.org wrote: Is this really the right thing to do. Even the Microsoft page uses the rather wishy-washy Consider using the ratio symbol, as if they're not quite sure this is a good idea. It does look nicer, but it's semantically wrong. A time is not a ratio. How does Orca read it? I don't really have an answer to the philosophical question of what a 'ratio' really is and whether 9-colon-49 is any more correct than 9-ratio-49 when it comes to representing time. But I can say that Orca reads the one like the other: nine fortynine. Perhaps more importantly, the ratio character behaves differently in RtL locales than the colon character does. See: http://blogs.msdn.com/b/michkap/archive/2012/02/09/10265712.aspx If I write 09:53 with a colon, it’ll remain left-to-right in RtL locales because the colon is a Unicode number separator. If I write 09∶53 with a ratio character, it’ll appear as 53∶09 in RtL locales. (Tested in gedit.) Is this the behaviour we want? I'd say its up to the translators of each locale to say what format is most appropriate for their language. Date and time formats are translatable for a reason... It hadn't occurred to me to make the time display on audio/video controls translatable in yelp-xsl. I used to mark a lot more for translation, but I scaled back on the formatting stuff when I saw nobody did legitimate translations of them. I looked at the po files in totem and gnome-shell. Nobody seems to actually translate how times are formatted. Date format, yes. And there's the difference between using 12- or 24-hour clocks. But when it comes down to the format HH:MM:SS, nobody translates it. It's always the same. I always try to translate time to HH.MM.SS for Norwegian. Maybe I missed that in yelp-xsl, but then it's just a bug in the translation. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3.7.3
Hi all. GNOME 3.7 development is well underway, with the 3.7.3 snapshot that is marking the third release of this development cycle [1]. To compile GNOME 3.7.3, you can the jhbuild [3] modulesets [4] (which use the exact tarball versions from the official release). A slight complication is that gnome-control-center 3.7.3 does not build against network-manager-gnome 0.9.6.4 (you need current master), so the network panel can not be built. [1] http://live.gnome.org/ThreePointSeven/Features [2] https://live.gnome.org/ThreePointSeven/Features/DropOrFixFallbackMode [3] https://live.gnome.org/GnomeGoals/PortToGstreamer1 [4] http://library.gnome.org/devel/jhbuild/ [5] http://download.gnome.org/teams/releng/3.7.3/ The release notes that describe the changes between 3.7.2 and 3.7.3 are available. Go read them to learn what's new in this release: core - http://download.gnome.org/core/3.7/3.7.3/NEWS apps - http://download.gnome.org/apps/3.7/3.7.3/NEWS The GNOME 3.7.3 release is available here: core sources - http://download.gnome.org/core/3.7/3.7.3 apps sources - http://download.gnome.org/apps/3.7/3.7.3 WARNING! WARNING! WARNING! -- This release is a snapshot of early development code. Although it is buildable and usable, it is primarily intended for testing and hacking purposes. GNOME uses odd minor version numbers to indicate development status. For more information about 3.7, the full schedule, the official module lists and the proposed module lists, please see our colorful 3.7 page: http://www.gnome.org/start/unstable For a quick overview of the GNOME schedule, please see: http://live.gnome.org/Schedule -- Kjartan Maraas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Re: GNOME 2.91.90 build issues (tracker, network-manager-applet, libpeas))
ti., 08.03.2011 kl. 14.31 -0600, skrev Jason D. Clinton: On Tue, Mar 8, 2011 at 13:22, bsquared bwcod...@gmail.com wrote: regarding the response here: http://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00022.html where it indicates that these tarballs should be used. http://ftp.acc.umu.se/pub/gnome/sources/NetworkManager/0.8/NetworkManager-0.8.995.tar.bz2 http://ftp.acc.umu.se/pub/gnome/sources/network-manager-applet/0.8/network-manager-applet-0.8.995.tar.bz2 Is there a patch available for the moduleset(s) in http://ftp.gnome.org/pub/GNOME/teams/releng/2.91.90/? With a little luck, 2.91.91 will be out tomorrow and it should have the moduleset change you're looking for. I've put up smoketesting modulesets at http://ftp.gnome.org/pub/GNOME/teams/releng/2.91.91/ for those of you who want to test the upcoming release. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
sø., 06.02.2011 kl. 15.39 +0100, skrev Gendre Sebastien: [SNIP] And remember: People have no problem with the default behavior of the laptop when you close the lid, but with the absence to change this behavior. I thought it was said early on in this thread that users can change this in dconf using dconf-editor[1]? Cheers Kjartan [1] dconf-editor crashes when trying to do this right now sadly https://bugzilla.gnome.org/show_bug.cgi?id=640089 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization vs. L10N
ti., 12.10.2010 kl. 16.03 +0200, skrev Vincent Untz: Le mardi 12 octobre 2010, à 12:10 +0200, Claude Paroz a écrit : b) we enforce a GNOME stats/translation tool, and we make the necessary steps so as it supports distributed development. For example, that could mean that the tool on l10n.gnome.org hosts an i18n version of each tracked branch where translations are committed by GNOME teams, and the modules have to merge regularly this branch into main repositories (at least before each release). ++ single location for translators - enforcing a special workflow for maintainers - risk that maintainers omit to merge i18n branch My preference is for b) as it is easier for translators: only one workflow has to be handled. b) sounds good, indeed. Note that you can make it easy for maintainers if we provide some Makefile rules that they can use to update the translations during make dist. But it should also be easy for testers to compile the package with updated translations without having to do make dist I guess. Perhaps documenting how to add an updated translation by just copying the file with the right name into the po/ dir is good enough? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
fr., 08.10.2010 kl. 13.35 +0200, skrev Johannes Schmid: Hi! On Fri, Oct 8, 2010 at 3:13 AM, Johannes Schmid j...@jsschmid.de wrote: Hi! So reminder: We need to fix that BEFORE making any moduleset reorganisation! No, we are not going to let moduleset reorganization held hostage in this way. Do you mean we will release GNOME 3.0 without working module translations? Probably easier to just not accept applications into GNOME 3.0 before this is solved. Then we can reorganize the existing moduleset without worrying about this issue in that respect. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME + MINIX
ti., 22.06.2010 kl. 06.59 -0700, skrev Mohammed Rashad: Hi devs, I would like to port gnome to minix3. will anyone help me with these. I will be happy if anyone mentor me? I am ready to whatever coding necessary to have my final output of gnome for minix any help will be greatly appreciated I guess a good start would be to try to get glib to compile and work on minix since everything in GNOME depends on that. You will probably end up missing lots of bits and pieces when it comes to hardware support and so on because neither udev, upower, udisks, hal, or any of the other support libraries are ported. Does XFree/Xorg even run there? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and desktop-wide keys
ma., 31.05.2010 kl. 00.56 +0200, skrev Vincent Untz: Le dimanche 30 mai 2010, à 23:13 +0200, Felix Riemann a écrit : Hi! I started to migrate Eye of GNOME to GSettings and found that we use several keys that live in GConf's /desktop/gnome path. These are specifically the lockdown settings and the desktop background which are defined in a schema currently shipping with the deprecated libgnome. Are there already any plans to move them to other packages or should they be buried with their package (and things should be done differently instead)? We've been discussing this on gnomecc-list. My understanding is that those shared keys will be moved to a new module specifically created for those; let's say we'll do it this week ;-) Is there a plan for the keys that live in libgnome as well? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
fr., 16.10.2009 kl. 09.37 -0600, skrev Tom Tromey: Ryan == Ryan Lortie de...@desrt.ca writes: Ryan I personally think migration is less critical than a lot of people Ryan think. Ryan Here's why (for me at least): Ryan - I often reinstall my distro when the new release comes out [...] Ryan - it never takes me more than a few minutes of fiddling to get stuff Ryan back to how i like it in terms of settings. I'd like to ask that you also consider the needs of people for whom it is more work to reconfigure. I've had to reconfigure Gnome too many times already. This is a bad user experience! For one thing it has left me with the impression that Gnome assumes that my time is worth little. I fully agree with this. I don't see how we can even consider not migrating configuration when switching to a new configuration system. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hard code freeze break request for gvfs
to., 17.09.2009 kl. 14.59 +0200, skrev Frederic Peters: Carlos Garcia Campos wrote: Bug 595356 - query_writable_namespaces() doesn't return metadata even though it's supported In order to know whether metadata is supported for a given file we call g_file_query_writable_namespaces() so that if metadata is in the list of writable namespaces we can safely get/set metadata on that file. That doesn't work for non local files in this moment due to bug #595356. Attached to the bug there's a trivial patch that has been already approved by alex. Trivial and already approved by maintainer, +1 from me. Second approval from me. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Searching for patches in bugzilla
ti., 01.09.2009 kl. 16.14 -0400, skrev Owen Taylor: Finding patches in your component that haven't been reviewed is a pretty common operation. Our previous ways of doing it (emblems, links from browse.cgi) aren't working at the moment, so I thought I'd mention here how to do it with the boolean charts feature, since I had trouble figuring it out. A screenshot is attached that demonstrates. Note that it's important that this is all in one boolean chart - because it's in one boolean chart, all the checks that are anded together have to match on the *same* attachment. Since you don't want to have to do this frequently, you should set up the search once for your module, than save it as a named query. Note that the right patch status would be accepted-commit_now and accepted-commit_after_freeze with underscores instead of hyphens. Other options are: reviewed, needs-work, rejected, commited. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
ma., 04.05.2009 kl. 12.43 -0500, skrev Brian Cameron: Kjartan: gnome-games stopped building in jhbuild for me since we still have clutter-0.8.8 there and the games want to use 0.9.x from what I can see in the logs. Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? clutter-gtk 0.9 is not yet available. Yet gnome-shell requires clutter-gtk 0.9 to build, so you currently have to build it from git master. Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? Won't clutter-0.9.x work with clutter-gtk-0.8.x? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
sø., 03.05.2009 kl. 15.59 -0500, skrev Jason D. Clinton: On Sun, May 3, 2009 at 2:39 PM, Kjartan Maraas kmar...@broadpark.no wrote: gnome-games stopped building in jhbuild for me since we still have clutter-0.8.8 there and the games want to use 0.9.x from what I can see in the logs. The request was made Mar. 17th with no objections. So, it's mandatory now. Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? It's up to whoever is using it. 0.8 and 1.0 are co-installable. I got the impression the only other user was gnome-shell. gnome-shell developers are you ok with bumping the requirement to 0.9.2? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-games requires clutter 0.9.x
Hi. gnome-games stopped building in jhbuild for me since we still have clutter-0.8.8 there and the games want to use 0.9.x from what I can see in the logs. Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new dependencies in gvfs
fr., 01.05.2009 kl. 19.16 -0400, skrev Matthias Clasen: David just merged the DeviceKit backend into gvfs, which means that gvfs will now depend on gnome-disk-utility and DeviceKit-disks. David will hopefully post something about some of the cool things we get with this. This mail is more about the dry bureaucratic aspects of this change... The new dependencies are only conditional. The hal backend is still there, so nobody will be rushed to switch to DeviceKit. Currently, the new backend is built automatically when configure finds the necessary dependencies, but there is a --en/disable-gdu option to force things. I'd like to add the new dependencies to our list of external deps (and to the jhbuild external-deps moduleset). Comments ? Sounds perfectly allright to me. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modules needing a release for 2.26.0
on., 04.03.2009 kl. 20.51 +0100, skrev Vincent Untz: Hi all, Here's a list of modules that didn't see a release since quite some time. It'd be nice to be sure that they either had no change at all, or that someone rolls a tarball for 2.26.0 in 10 days. Note that if there's no news for a module before March 16th, the release team will roll tarballs for those modules. Volunteers to help roll tarballs are welcome. No new release since 2.24.0 === libbonobo 2.24.0 2.24.0 libbonoboui 2.24.0 2.24.0 libgnome 2.24.1 2.24.1 libgnomeprint 2.18.5 2.18.5 libgnomeprintui 2.18.3 2.18.3 libgnomeui2.24.0 2.24.0 ORBit22.14.162.14.16 I've done these today. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GDM version used for GNOME 2.24?
fr., 19.09.2008 kl. 00.34 +0200, skrev Vincent Untz: Le mercredi 17 septembre 2008, à 17:23 -0400, Willie Walker a écrit : Well...hmm...if I read the answers correctly, I think what I'm hearing is that there are a lot of great ideas, but they aren't done yet. If this is the case, then I think this sounds like a regression. I see nobody jumping in to say it's not a regression. So, we're going with GDM 2.20, I guess... Is there any objection? I see people saying it's a regression, but what does it mean in practise? Is a11y busted? Is it a minor inconvenience affecting only login? Can someone please post a list of pros and cons for this specific issue wrt 2.22 vs 2.24? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
fr., 19.09.2008 kl. 00.36 +0200, skrev Vincent Untz: Le jeudi 18 septembre 2008, à 21:53 +0200, Kjartan Maraas a écrit : [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size You should look for glade files too, I guess. None of the glade files in /usr/share on my machine has a page_size attribute. Am I missing something? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK adjustement changes create incompatible behaviour between versions?
to., 18.09.2008 kl. 10.36 +0200, skrev Sebastien Bacher: Hello, The new GTK 2.14 changed the way GtkAdjustements are working: * GtkAdjustment now enforces that values are restricted to the range [lower, upper - page_size]. This has always been the documented behaviour, and the recommended practice is to set page_size to 0 when using adjustments for simple scalar values, like in a slider or spin button. That's the GTK readme stating that the new behaviour is documented but the GTK API example use non null values in its example and lot of applications seem to be in this case too. That creates a collection of bugs, http://bugzilla.gnome.org/show_bug.cgi?id=551740 has a small discussion on the topic, basically the gtk_spin_buttons limits are broken in lot of applications (some example are on the bug, gnome-panel has similar issues too). That also means that applications need source code changes to be adapted to the new GTK behaviour. Would it be possible to reconsider this change? That's somewhat a compatibility breakage and will create issues in lot of softwares. If the change is right it would be nice to let a cycle for applications to be updated to the new behaviour before using it, there is thousand of GTK applications around and reviewing those for incorrect adjustement usages is going to take a while. Here's the list from my fedora rawhide install: [EMAIL PROTECTED] share]$ find . -name *.ui | xargs grep page_size ./totem/mozilla-viewer.ui:property name=page_size0/property ./gnome-terminal/profile-preferences.ui:property name=page_size0/property ./gnome-terminal/profile-preferences.ui:property name=page_size0/property ./gnome-applets/builder/mini-commander.ui:property name=page_size10/property ./gnome-applets/builder/stickynotes.ui:property name=page_size100/property ./gnome-applets/builder/stickynotes.ui:property name=page_size100/property ./gedit-2/ui/gedit-print-preferences.ui:property name=page_size10/property ./gedit-2/ui/gedit-preferences-dialog.ui:property name=page_size10/property ./gedit-2/ui/gedit-preferences-dialog.ui:property name=page_size8/property ./gedit-2/ui/gedit-preferences-dialog.ui:property name=page_size10/property ./gedit-2/plugins/sort/sort.ui:property name=page_size10/property And from my jhbuild install I get these in addition: ./gnome-system-tools/ui/time.ui:property name=page_size10/property ./gnome-system-tools/ui/time.ui:property name=page_size10/property ./gnome-system-tools/ui/time.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-system-tools/ui/users.ui:property name=page_size10/property ./gnome-applets/builder/battstat_applet.ui:property name=page_size5/property So for our own release this affects at least three modules it seems. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: enable accessibility by default for GNOME
ma., 08.09.2008 kl. 21.39 +0300, skrev Claudio Saavedra: El mié, 30-07-2008 a las 15:56 -0500, Diego Escalante Urrelo escribió: On 7/30/08, Bastien Nocera [EMAIL PROTECTED] wrote: On Wed, 2008-07-30 at 12:00 -0400, Willie Walker wrote: Hi All: I recently had a nice discussion with the release team about the viability of enabling accessibility (i.e., the AT-SPI infrastructure) by default for GNOME. As a result of that discussion, I'm approaching the broader GNOME community with a proposal to do this. :-) I'd agree if you can show that there's little to no performance hit from enabling it. I'd go even further and say that we should not make it possible to disable it within the UI if you can show that it won't have adverse effects on most users (that don't need a11y...). I have froze my whole session by getting the at-spi stuff to crash. More concrete examples include eog not loading images anymore after crashing at. And I gotta say my crashes were random, happened in 2.20, 2.22. That's http://bugzilla.gnome.org/show_bug.cgi?id=547373 There's also this ugly emacs+metacity+a11y lock, that makes my computer unusable. I think I hadn't noticed this before because I was using some emacs snapshot, but now I switched laptops and haven't got the time to compile it... http://bugzilla.gnome.org/show_bug.cgi?id=392889 I haven't experienced more issues so far, but that's enough for me. I'm disabling it. I was forced to do the same last time I tried it, and that was a good while ago. We should definitely spend some time figuring that one out. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GDM version used for GNOME 2.24?
on., 10.09.2008 kl. 14.49 +0200, skrev Vincent Untz: Le mercredi 03 septembre 2008, à 22:27 +0200, Andre Klapper a écrit : We'd like to have a decision made by this weekend so there's two weeks left for translators. Comments highly welcome, so you can't blame release-team only in the end. ;-) Thanks everybody who jumped in the discussion. From what I see, there's no consensus in this thread. An important thing for GDM is that in most cases, really, it's the distributors that decide what gets shipped and I don't know a lot of people using GDM from jhbuild. So keep in mind that the message that we want to send is mainly to distributors (FWIW, some already chose to stay with the old GDM, and some chose to go with the new one). I don't see us ignoring a good bunch of the comments (there are good points on each side), so there are two ways to go forward: + use GDM 2.24, and mention that it is not ready for all uses (listing the use cases where it needs work would help), and that GDM 2.20 is still available and working. + stay with GDM 2.20, and mention that we have a new GDM coming soon. We kind of did solution b for 2.22, but it turned out not a lot of people stepped up to fix the remaining issues in the new GDM. It could be because the community was not aware of all this, though. Right now, I'm leaning towards solution a (assuming the new GDM works fine and there's no major non-regression bugs). I'm not happy with regressions (I'd say this is a good example to keep in mind when reworking a module -- do not ignore the old feature set or clearly explain why your remove some features), but I would think that without sending a clear message, people will still stay with GDM 2.20 in 2.26, and so on. I'm leaning in the same direction. Having used the new GDM since it landed in rawhide (was that before even Fedora 9?) I must say that I've had no problems with it so far. None that haven't been fixed within a reasonable amount of time at least. ObFutureVision: How about making GDM just be the gnome-screensaver unlock dialog and let everything else start in the background? :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using vala in GNOME
sø., 29.06.2008 kl. 22.02 +, skrev Stef: 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. That is, obviously if someone wants to get involved in those portions of seahorse that are written in vala, they'd need to build vala (which is easy to do). I believe this is an acceptable tradeoff, since seahorse and gnome-keyring have most of their code contributed by a small number of people ... and using vala speeds up development for that small number of people. Barring any objections, the next release of seahorse will contain some vala code. Well the objections were raised and still the code is in svn. This hit me today when trying to build with jhbuild and we need to make a decision whether vala is blessed as a dependency or not. I don't personally have anything against this but I think the vala maintainers need to chime in with some kind of guarantees for stability etc. Frederic added vala as a tarball to the modulesets so people can build it to make seahorse build, but didn't add the dep yet. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild, dbus and gnome-session
sø., 25.05.2008 kl. 21.35 +0200, skrev Frederic Peters: Kjartan Maraas wrote: From what I see now there's more than one issue here since I get the same warning and defunct processes in my normal account with the standard system session on fedora devel/rawhide. Is anyone else actually running 2.23.x? :-) I am running some parts of it, but not the new gnome-session (neither the new gdm). FWIW I first experienced a crasher bug with the new gnome-session, that had already been reported, but after it had been fixed it was still non functional; and I didn't have time to investigate that further. This is likely related to the problems we're seeing: http://www.redhat.com/archives/rhl-devel-list/2007-October/msg00034.html Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild, dbus and gnome-session
sø., 25.05.2008 kl. 10.18 +0200, skrev Luca Ferretti: Il giorno sab, 24/05/2008 alle 18.14 +0200, Kjartan Maraas ha scritto: Hi. Btw, I have set $prefix/var/run/dbus to be a symlink to /var/run/dbus Try starting the session using jhbuild run dbus-launch gnome-session This is how it's done according to the OnlineDesktop jhbuild instructions and it doesn't make a difference. From what I see now there's more than one issue here since I get the same warning and defunct processes in my normal account with the standard system session on fedora devel/rawhide. Is anyone else actually running 2.23.x? :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
jhbuild, dbus and gnome-session
Hi.
I'm trying to figure out how to use a jhbuild session toghether with the
system provided dbus, hal, cairo etc. I'm running fedora development
snapshots most of the time and I have the latest vesions of the external
dependencies so I don't see the need to build these again in jhbuild.
The problem is that this isn't working out as great as I planned :-)
I can log in and everything looks ok, but some programs fail to
communicate with the session manager apparently. I tried running
gnome-session-properties and was rewarded with this:
(gnome-session-properties:17959): GnomeUI-WARNING **: While connecting
to session manager:
Could not open network socket.
strace says:
connect(10, {sa_family=AF_FILE, path=@/tmp/.ICE-unix/17444}, 23) = -1
ECONNREFUSED (Connection refused)
I think this also is what's leading to a hang when I log out. The panel
seems to quit and after that the desktop just hangs there. Nautilus is
usable, but the logout process seems to have stopped and I have some
defunct processes hanging around.
I'll gladly provide more information if someone can point me in the
right direction. That is if this is supposed to work at all.
Btw, I have set $prefix/var/run/dbus to be a symlink to /var/run/dbus
Cheers
Kjartan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild, dbus and gnome-session
lø., 24.05.2008 kl. 12.52 -0500, skrev Diego Escalante Urrelo: On 5/24/08, Kjartan Maraas [EMAIL PROTECTED] wrote: Hi. I'm trying to figure out how to use a jhbuild session toghether with the system provided dbus, hal, cairo etc. I'm running fedora development snapshots most of the time and I have the latest vesions of the external dependencies so I don't see the need to build these again in jhbuild. The problem is that this isn't working out as great as I planned :-) I followed this guide and had no problems last time: http://live.gnome.org/OnlineDesktop/Jhbuild I tried this now and removed all my .xinitrc, .basrc and .Xclient stuff from earlier experiments, but still no dice. I get defunct processes (gnome-volume-manager, gnome-at-visual, gnome-power-manager) on login and the same warning about not being able to connect to the session manager. Maybe stuff is just broken in the devel snapshots... Cheers Kjartan ___ 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
ma., 19.05.2008 kl. 18.22 -0400, skrev Claudio Saavedra: El mar, 20-05-2008 a las 00:15 +0200, Kjartan Maraas escribió: I tried building everything with jhbuild today and noticed a few things that need attention: Add to that gnome-python having problems to be detected by modules depending on it due to waf 1.3.2 being used. I already fixed that by upgrading waf to 1.4.2 in bootstrap.modules. Also found out that intltool from trunk doesn't play well with older intltool releases on the system at the same time. Build broke because autoconf/automake created an aclocal.m4 file which had a line using awk to check for intltool-update.in but the latest intltool doesn't ship the .in files any more. This is probably because the generated aclocal.m4 file picks up some stuff it shouldn't from the system prefix... Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
jhbuild status for 2.23.x
Hi. I tried building everything with jhbuild today and noticed a few things that need attention: - glib trunk has changed the _() macro to take a const char * now and some modules break because of this. Most notably nautilus, ekiga, dasher and probably a few more. Other modules will have a bunch of new warnings that need fixing. - 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. - epiphany and yelp don't build on fedora rawhide because of xulrunner issues and haven't built for me for quite a while (2.22.x even). A roadmap for html rendering engines and porting to them for various modules in 2.23.x would be nice - ekiga should be tracking trunk (3.0 to be) for 2.23.x according to damien Granted, this is building from scratch with a very raw fedora hide so some of my issues could stem from that. I have patches for nautilus and dasher to make them build and will file them in bugzilla Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problem with thumbnail mamagement for image files
lø., 15.03.2008 kl. 17.13 -0400, skrev David Zeuthen: On Sat, 2008-03-15 at 13:40 -0500, Diego Escalante Urrelo wrote: On a side-note, it looks like nautilus doesn't generate thumbnails for trash:/// obex:/// and others, no matter the preferences set in nautilus. Regression or intentional? It's because someone didn't apply the patch here http://bugzilla.gnome.org/show_bug.cgi?id=517276 Sorry for not catching this before the release. I went looking for it at some point but got distracted it seems... It's in svn now and will be in the next release. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Low memory hacks
fr., 29.02.2008 kl. 14.39 +0200, skrev Kalle Vahlman: 2008/2/29, Nickolay V. Shmyrev [EMAIL PROTECTED]: Heh, I also would like to delete all .po files if only I knew how to keep translations :) Deleting .po:s would be futile as those are just the sources from which the actual (binary) files loaded are compiled ;) Even so, you only have the translations of your current locale loaded into RAM so by deleting all the others you only save disk space. AFAIK that should be safe to do though. Would be interesting to see how much building without translations affect memory usage wrt loading generated files with translations in them (.schemas, .desktop etc) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reintroducing critical warnings?
ma., 25.02.2008 kl. 22.23 +0100, skrev Kjartan Maraas: ma., 25.02.2008 kl. 13.47 -0500, skrev Owen Taylor: On Mon, 2008-02-25 at 09:30 +, Benjamin Otte wrote: Havoc Pennington hp at pobox.com writes: Wait, that's the whole point is to crash the app The issue is that if it just prints stuff, people don't fix the bug (in part, perhaps, because nothing goes through bug-buddy). Maybe the fix is to bug-buddy the warning, but don't crash the app. Not sure how hard that would be to code. I guess this is the age-old question of How should we treat a non-critical bug during development? And I guess it is equivalent to Should we enable gcc's -Werror switch for svn builds? which is the question I regularly clash about with Behdad. In the end it's a tradeoff. A tradeoff between forcing users to make you care about potentially harmless stuff that's not a real bug (to quote Behdad) and missing real bugs because users don't care about bugs that don't bite them. It's also a tradeoff between allowing you to be lazy and not fix warnings immediately - or at least until the next gcc comes around that makes them real bugs - and having to fix obscure warnings on weird platforms immediately because they break the build or prevent the application from running. Jumping in late on this conversation ... running from JHBuild I had to patch out the fatal warnings, because all sorts of apps I normally use *not from JHBuild* (Eclipse, Firefox, Pidgin, etc.) were dying from critical warnings caused by the application code, rather than bugs in the JHBuild built things. Filed a bug for pidgin: http://developer.pidgin.im/ticket/4917 And now it's been fixed :-) http://developer.pidgin.im/ticket/4917#comment:2 Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reintroducing critical warnings?
ma., 25.02.2008 kl. 13.47 -0500, skrev Owen Taylor: On Mon, 2008-02-25 at 09:30 +, Benjamin Otte wrote: Havoc Pennington hp at pobox.com writes: Wait, that's the whole point is to crash the app The issue is that if it just prints stuff, people don't fix the bug (in part, perhaps, because nothing goes through bug-buddy). Maybe the fix is to bug-buddy the warning, but don't crash the app. Not sure how hard that would be to code. I guess this is the age-old question of How should we treat a non-critical bug during development? And I guess it is equivalent to Should we enable gcc's -Werror switch for svn builds? which is the question I regularly clash about with Behdad. In the end it's a tradeoff. A tradeoff between forcing users to make you care about potentially harmless stuff that's not a real bug (to quote Behdad) and missing real bugs because users don't care about bugs that don't bite them. It's also a tradeoff between allowing you to be lazy and not fix warnings immediately - or at least until the next gcc comes around that makes them real bugs - and having to fix obscure warnings on weird platforms immediately because they break the build or prevent the application from running. Jumping in late on this conversation ... running from JHBuild I had to patch out the fatal warnings, because all sorts of apps I normally use *not from JHBuild* (Eclipse, Firefox, Pidgin, etc.) were dying from critical warnings caused by the application code, rather than bugs in the JHBuild built things. Filed a bug for pidgin: http://developer.pidgin.im/ticket/4917 I don't see any warnings from firefox with a breakpoint in g_log(). Any particular sites that cause this? Don't have eclipse installed so I can't reproduce those. So, I'm not sure that the fatals warning has the intended effect of catch problems, it may just have the unintended effect of driving people away from testing the unstable code at all. One could just clear the environment variables on the command line and run the unstable stuff that way to avoid the problems. Or just file bugs. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Just change release date (Was Re: State of gvfs in Gnome 2.21)
ti., 12.02.2008 kl. 16.32 +0100, skrev Andre Klapper: Am Dienstag, den 12.02.2008, 17:11 +0200 schrieb Peteris Krisjanis: So I suggest - delay the release. Delay Ubuntu LTS. Delay also other distro releases. Why? Because not release date matters. What matters here is a _product_. It should be usable, it should be documented, it is *definitely* possible to fix the showstoppers in the next four weeks and release GNOME 2.22.0 in a sane state. so there's no need at all to discuss a delay currently. How big an issue is ftp support in nautilus btw? I for one never have never used it for much more than testing it. Does the bug count indicate the size of our userbase for example? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: adding guile and autogen as external dependencies?
to., 17.01.2008 kl. 13.41 +0100, skrev Frederic Peters: Hello, I got a bug report today against jhbuild, as gnome-games is missing a dependency on guile (this is #510066). I also found autogen, which is required by anjuta, had not been added to external deps. They are both defined in gnome-2.22.modules: tarball id=guile version=1.8.0 source href=ftp://ftp.gnu.org/gnu/guile/guile-1.8.0.tar.gz; size=3691677 md5sum=3f47443602f93e94bf43218d9b86099d/ /tarball I think we have to use guile 1.8.3 since I was getting compiler errors with the current one during jhbuild and those were mentioned as fixed in 1.8.3. tarball id=autogen version=5.8.4 source href=http://internap.dl.sourceforge.net/sourceforge/autogen/autogen-5.8.4.tar.bz2; size=931015 md5sum=b65d4b9e3ddbcfd5418b708858c05b66/ dependencies dep package=guile/ /dependencies /tarball What to do about them ? Should they be moved to external deps, or do they have some kind of special status ? I think they should definitely be in external deps or maybe even bootstrap for guile. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Adding schema entries to libgnome
Hi. I've got a few bugreports in bugzilla asking to add more schema entries for various stuff in libgnome and wanted to check whether this still is considered the place to do that or if we should avoid adding more API/ABI to these libs. I guess we need to migrate the lot of them if we are to get rid of libgnome some day anyway so adding a few more doesn't really add that much of a burden. Other than that it would be nice to get some feedback on the patches themselves just so I don't add stuff prematurely. - lockdown: Restrict Application Launching, default schema ... http://bugzilla.gnome.org/show_bug.cgi?id=395887 - Add schemas for search tool preferred application http://bugzilla.gnome.org/show_bug.cgi?id=491647 - Add default application keys for calendar and tasks http://bugzilla.gnome.org/show_bug.cgi?id=497180 - need schemaentry for gtk-modules xsetting http://bugzilla.gnome.org/show_bug.cgi?id=507385 Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Adding more schema entries to libgnome ok?
Hi. I've got a few reports in bugzilla with patches to add more schema entries in libgnome. Is it ok to keep adding API/ABI to these deprecated libs or should we seek to put them elsewhere? I guess we'll have to migrate the whole lot to some other place at some point anyway if we are to get rid of libgnome so adding a few more won't add much to the burden. - lockdown: Restrict Application Launching, default schema ... http://bugzilla.gnome.org/show_bug.cgi?id=395887 - Add default application keys for calendar and tasks http://bugzilla.gnome.org/show_bug.cgi?id=491647 - need schemaentry for gtk-modules xsetting http://bugzilla.gnome.org/show_bug.cgi?id=507385 - Add schemas for search tool preferred application http://bugzilla.gnome.org/show_bug.cgi?id=491647 Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacement for GNet
ma., 24.12.2007 kl. 02.12 +0100, skrev Piotr Gaczkowski: Hi! I am interested if somebody is currently working on a GNet-like library based on GObject? In a recent project I would like to have an embedded ftp server and since I couldn't find any C libraries of this kind I thought it would be nice to write one. The basic problem is I couldn't find any modern networking library that is GObject-based. On Vala list there were suggestions about writing one using GIO. The idea seems nice enough, but I have no experience with writing anythning of that sort and wanted to know if it wouldn't be reinventing the wheel. So does anybody know about possible network library for GNOME either stable or in development? Not sure how far along they got but I seem to recall this is what libgnetwork was about: http://svn.gnome.org/viewvc/libgnetwork/trunk/ Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.22 module inclusion discussions heat up.
to., 20.12.2007 kl. 03.29 +0100, skrev Vincent Untz: Le mercredi 19 décembre 2007, à 11:48 -0600, Shaun McCance a écrit : On Wed, 2007-12-19 at 16:04 +0100, Andre Klapper wrote: [SNIP] I'd like to send some documentation analysis along to the list, but I'd rather do it as replies to official threads for each module. Cool, great! Analysis from a i18n perspective could be great too! I can take care of that. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
ons, 03.10.2007 kl. 19.23 -0400, skrev Matthias Clasen: On 10/3/07, Kjartan Maraas [EMAIL PROTECTED] wrote: All this should just come from libc. I don't think we should do anything special here at all. I think all the needed data is available in the locale data. That is where GtkCalendar takes it from. Unfortunately, the week-start-data in glibc locales is somewhat unreliable, and corrections are not exactly easy to get in. Tell me about it. I've just gotten this fixed for nn and nb. A little over a year after the bug was filed. And a couple other locales among others danish and estonian were fixed at the same time. Maybe it's time we push for an audit of this in glibc? That won't help for other platforms though... Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
ons, 03.10.2007 kl. 12.28 -0400, skrev Hubert Figuiere: On Tue, 2007-09-25 at 14:55 +0100, Ross Burton wrote: On Tue, 2007-09-25 at 09:41 -0400, Luis Villa wrote: New d-d-l rule: no one gets to say 'it is useful' without explaining their use case :) Luis (I believe you that you use it, but I can't for the life of me figure out why) Because project plans at work are often based on week number. Task foo has to be completed in week 38, this image was built in week 36, etc. But then you have to make sure week start right. Some consider week 1 starting January 1st (eventually being less than 7 days), some consider week 1 starting the first Sunday or Monday (oh another exception) of January. This is a major source of confusion that has to be taken into account for the design. All this should just come from libc. I don't think we should do anything special here at all. I think all the needed data is available in the locale data. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libgnome/libgnomeui branched
Hi. I've branched libgnome and libgnomeui. Branch name is gnome-2-20 as expected. Thanks to Frederic for updating the jhbuild moduleset already. Cheers Kjartan (who loves icecream) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libgnome/libgnomeui branched
tir, 02.10.2007 kl. 21.12 +0200, skrev Kjartan Maraas: Hi. I've branched libgnome and libgnomeui. Branch name is gnome-2-20 as expected. And now I branched libgnomecanvas as well. Same name. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
tir, 25.09.2007 kl. 09.41 -0400, skrev Luis Villa: On 9/25/07, Ross Burton [EMAIL PROTECTED] wrote: On Tue, 2007-09-25 at 09:20 -0400, Matthias Clasen wrote: The screenshot of the calendar does not show the week number (it's useless clutter, relaly). I think the week number is there in the released versoin due to the way the GtkCalendar widget works. Those can (and should be) be turned off. The calendar should maybe be made a bit more useful in general, maybe adding some decorations to show which days have appointments, deadlines or birthdays, Currently, it is just a field of numbers that takes up quite a bit of room. Nooo, please keep week number. For some people it's actually really useful! New d-d-l rule: no one gets to say 'it is useful' without explaining their use case :) Luis (I believe you that you use it, but I can't for the life of me figure out why) That's just because you americans don't use week numbers for anything :-) Seriously though, this comes up every so often in a lot of different situations. Europe and probably many other parts of the world actually depend on week numbers to plan their day to day activities. You might want to try it some time :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Orca hard code freeze break request to handle impending Firefox changes
tor, 13.09.2007 kl. 17.06 +0200, skrev Vincent Untz: Le jeudi 13 septembre 2007, à 10:33 -0400, Willie Walker a écrit : We've been testing this patch pretty heavily, and are continuing to do so today. All is looking well, and I will only check things in on two conditions: 1) you guys say this is OK, and 2) continued testing shows that the patch works with the new and improved Firefox without introducing any regressions. OK to commit? Looks safe to me, and it's great you've been testing the patch a lot to be sure it doesn't break things. Approval 1 of 2. 2 of 2 Cheers Kjartan ___ 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
man, 03.09.2007 kl. 08.09 +0200, skrev Olav Vitters: On Sun, Sep 02, 2007 at 11:42:44PM -0400, Behdad Esfahbod wrote: On Sun, 2007-09-02 at 21:39 -0600, Elijah Newren wrote: I'm with Jeff and Vincent on this; I'm worried about the adverse affect this could have on the release, given how close it is. Can we consider delaying it until after 2.20 is out? I can delay; just tell me so clearly. Then it will be Dec/Jan ish for the new system. However, based on the current account creation speed, I don't think that is advisable. How hard would it be for someone to intersect all the modules in the GNOME release with the list of those missing a correct MAINTAINERS file and add the missing ones? Assuming 'jhbuild list' gives the SVN name (might not be true): gnome-doc-utils, nautilus, gnome-themes, libxml2, zenity, gnome-netstatus, libart_lgpl, gnome-backgrounds, nautilus-cd-burner, gnome-devel-docs, sabayon, libcroco, gnome-common, libglade, gnome-mime-data, gtk-doc, fast-user-switch-applet, gamin, gnome-media, libgnomekbd, libsigc++2, gtkmm, libgnomecanvas, libxslt, libgnomecups I've taken care of all the modules containing translations in this list at least. The others can be handled by the maintainers themselves if the module is still maintained that is :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requesting UI Freeze break for gnome-panel and gnome-utils
tir, 28.08.2007 kl. 10.55 -0500, skrev Shaun McCance: On Tue, 2007-08-28 at 00:40 +0200, Sebastian Pölsterl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jaap Haitsma schrieb: Hi, The gnome-searchtool icon got removed from gnome-icon-theme because it got replaced by the system-search icon. Good to know. Deskbar-Applet uses the icon as well. So the icon should get replaced there, too. This is starting to sound like a disaster waiting to happen. Is there any way to grep for a string in the trunk of all our SVN repos, short of checking them all out? That way we could find all references to an icon before it gets removed. codesearch.google.com? Other than that I still miss the LXR setup we had back in the day. It was very useful. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.20.0 beta 1
fre, 17.08.2007 kl. 20.31 +1000, skrev Jeff Waugh: quote who=Kjartan Maraas Added on f.g.o now and updated the md5sums. I put acceriser in desktop and gnome-devel-docs in devtools. Accerciser is really a developer tool. /me kicks back another gallon of coffee... Right you are. Fixed it again :-) I also updated the tarball-conversion.config file so we should be good for the next release now. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.20.0 beta 1
tor, 16.08.2007 kl. 18.01 -0600, skrev Elijah Newren: On 8/16/07, Kjartan Maraas [EMAIL PROTECTED] wrote: tor, 16.08.2007 kl. 12.18 +0200, skrev Frederic Peters: Hello, Kjartan Maraas wrote: I'm still in the process of building the release and have uploaded the modulesets and versions file to the ftp server so far. Hit a few snags here and there so it has taken me longer than I wanted. gnome-suites-2.19.90.modules is missing tarballs for new modules, accerciser and gnome-devel-docs, tarball id=gnome-devel-docs version=2.19.1 source href=http://download.gnome.org/sources/gnome-devel-docs/2.19/gnome-devel-docs-2.19.1.tar.bz2 md5sum=6615ea643ec27c41f97858d874bc4eb8 size=818514/ branch/ dependencies dep package=gnome-doc-utils/ /dependencies /tarball tarball id=accerciser version=0.1.90 source href=http://download.gnome.org/sources/accerciser/0.1/accerciser-0.1.90.tar.bz2; md5sum=043def58d64eb693c9b7c04c193c1f23 size=829834/ branch/ dependencies dep package=pygtk/ dep package=gnome-python/ dep package=gnome-python-desktop/ dep package=libglade/ dep package=at-spi/ /dependencies /tarball Damn. Thanks for the heads up. Maybe we should add these manually for this release? Yeah, that'd be easiest. :-) I should probably make the comment about updating tarball-conversion.config[1] more prominent; it's too easy to miss. Added on f.g.o now and updated the md5sums. I put acceriser in desktop and gnome-devel-docs in devtools. [1] 6th step of http://live.gnome.org/ReleasePlanning/MakingARelease Ahh, I did overlook that one yes. I'll have a look to see if I can add the two missing modules then. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.20.0 beta 1
tor, 16.08.2007 kl. 12.18 +0200, skrev Frederic Peters: Hello, Kjartan Maraas wrote: I'm still in the process of building the release and have uploaded the modulesets and versions file to the ftp server so far. Hit a few snags here and there so it has taken me longer than I wanted. gnome-suites-2.19.90.modules is missing tarballs for new modules, accerciser and gnome-devel-docs, tarball id=gnome-devel-docs version=2.19.1 source href=http://download.gnome.org/sources/gnome-devel-docs/2.19/gnome-devel-docs-2.19.1.tar.bz2 md5sum=6615ea643ec27c41f97858d874bc4eb8 size=818514/ branch/ dependencies dep package=gnome-doc-utils/ /dependencies /tarball tarball id=accerciser version=0.1.90 source href=http://download.gnome.org/sources/accerciser/0.1/accerciser-0.1.90.tar.bz2; md5sum=043def58d64eb693c9b7c04c193c1f23 size=829834/ branch/ dependencies dep package=pygtk/ dep package=gnome-python/ dep package=gnome-python-desktop/ dep package=libglade/ dep package=at-spi/ /dependencies /tarball Damn. Thanks for the heads up. Maybe we should add these manually for this release? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.20.0 beta 1
ons, 15.08.2007 kl. 01.05 -0500, skrev Brian Cameron: I just noticed on the 2.19 schedule that we were supposed to release 2.19.90 this past Monday and today was supposed to be the 2.20 beta1 release? There wasn't any announcement on this list, so I haven't yet spun a version of GDM. Is this release being delayed? I'm still in the process of building the release and have uploaded the modulesets and versions file to the ftp server so far. Hit a few snags here and there so it has taken me longer than I wanted. I really don't understand how we were supposed to do two releases in three days though? That must be wrong. The normal procedure has always been tarballs due on monday before the release on wednesday. And looking at the schedule again I now see that GNOME 2.20.0 Beta1 really is just another name for 2.19.90 :-) I will have it out by the end of today hopefully. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Generating excitement in GNOME
ons, 25.04.2007 kl. 22.42 +1000, skrev Jeff Waugh: quote who=John (J5) Palmieri The point is not a conformity to the 6 month cycle but a forward moving process that would eventually get the project into the more formal releases. Most of it is just getting all the information into one spot so projects can start to work together even before they become part of the release. It's also a great way of signalling not only that the developer wants it to be part of one of the production release suites, but that the community also wants it to be. I tend to think that gnome-scan, for instance, would receive community support right now for entering the Desktop suite *at some point in the future*, but isn't quite ready. Maybe we could just revive 5th toe and set some real criteria for inclusion this time around? I seem to remember that a lot of the modules in 5th toe ended up in the core release after some time. stickynotes, gucharmap, gok, seahorse, zenity, totem, gnomemeeting/ekiga etc. Having a home for these efforts is a fine way of pimping stuff to contribute to. We could start doing GNOME Love projects around this set of modules, so new hackers have something cool to work on but won't be stressed about their work impacting production modules. This is a very good idea and lack of this is probably what turned 5th toe into everything in SVN that isn't in a real release set, or maybe my memory of all this is starting to fade :-) Anyway, I'm all for this regardless of branding details :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild and dbus started services
ons, 25.04.2007 kl. 23.11 +0200, skrev Wouter Bolsterlee: 2007-04-25 klockan 17:47 skrev Kjartan Maraas: I just rebuilt my jhbuild environment the other day and when I logged in I noticed that my keyboard layout was set back to 'us' from norwegian. After more investigation I see that gnome-settings-daemon is started from /usr/libexec/ instead of $prefix/libexec and I guess that's causing these problems. Can anyone tell me how to set up the jhbuild environment so that dbus starts the right programs in this case? If you built DBUS yourself as well, executing something like this from your .xinitrc might work: jhbuild run dbus-launch --exit-with-session seahorse-agent gnome-session Hope this helps. See [1] for some related information. Thanks for the suggestion. How does this play along with the suggestion in jhbuild/README that you create a .desktop file containing something similar to the above as the Exec line? I mostly use gdmflexiserver to start a new jhbuild session, and have created the .desktop file like the README suggests to get the menu entry in gdm. Not that it matters much anyway whether I pick it from the menu or edit a dot file since I only pick it the first time I log in to a test account anyway. I just feel that we need to put some of these tips and tricks into the docs somewhere or maybe the wiki. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: jhbuild and dbus started services
tor, 26.04.2007 kl. 08.30 +0200, skrev Kjartan Maraas: ons, 25.04.2007 kl. 23.11 +0200, skrev Wouter Bolsterlee: 2007-04-25 klockan 17:47 skrev Kjartan Maraas: I just rebuilt my jhbuild environment the other day and when I logged in I noticed that my keyboard layout was set back to 'us' from norwegian. After more investigation I see that gnome-settings-daemon is started from /usr/libexec/ instead of $prefix/libexec and I guess that's causing these problems. Can anyone tell me how to set up the jhbuild environment so that dbus starts the right programs in this case? If you built DBUS yourself as well, executing something like this from your .xinitrc might work: jhbuild run dbus-launch --exit-with-session seahorse-agent gnome-session Hope this helps. See [1] for some related information. Thanks for the suggestion. How does this play along with the suggestion in jhbuild/README that you create a .desktop file containing something similar to the above as the Exec line? I mostly use gdmflexiserver to start a new jhbuild session, and have created the .desktop file like the README suggests to get the menu entry in gdm. Not that it matters much anyway whether I pick it from the menu or edit a dot file since I only pick it the first time I log in to a test account anyway. I just feel that we need to put some of these tips and tricks into the docs somewhere or maybe the wiki. I tried this now and still have the same problem: [EMAIL PROTECTED] ~]$ ps axu | grep settings kmaraas 2527 0.0 1.0 84408 10480 ?Sl Apr25 0:03 /usr/libexec/gnome-settings-daemon jhbuild 6253 0.7 1.4 50432 14900 ?Sl 08:32 0:00 /usr/libexec/gnome-settings-daemon [EMAIL PROTECTED] ~]$ cat .xinitrc jhbuild run dbus-launch --exit-with-session seahorse-agent gnome-session [EMAIL PROTECTED] ~]$ ls -l .xinitrc -rwxrwxr-x 1 jhbuild jhbuild 74 2007-04-26 08:30 .xinitrc I also tried running gdmflexiserver out of the jhbuild prefix to see if that had anything to do with this, but that gave the same result. This has been a problem for some time now. IIRC ever since gnome-session was made responsible for starting gnome-settings-daemon via dbus. Maybe gnome-session could be enhanced to help get things right in the case of non system prefix builds? Any ideas? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
jhbuild and dbus started services
Hi. I just rebuilt my jhbuild environment the other day and when I logged in I noticed that my keyboard layout was set back to 'us' from norwegian. After more investigation I see that gnome-settings-daemon is started from /usr/libexec/ instead of $prefix/libexec and I guess that's causing these problems. Can anyone tell me how to set up the jhbuild environment so that dbus starts the right programs in this case? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: broken bug-buddy support in applets
fre, 30.03.2007 kl. 19.25 -0400, skrev Matthias Clasen: Hey, I noticed today that for virtually every applet I shot down with kill -BUS, bug-buddy claimed to not know it and did not offer to send out a bug report. The .server files of the applets did have the necessary bugzilla information, and debugging bug-buddy showed that it actually reads all this information. Looking into this a bit further, I found that the problem is most likely caused by the GOption conversion that was done a while ago... The bugzilla data in the the .server files has the binary name in other_binaries, but libgnomeui uses g_get_prgname() when passing the appname to gnome_segv and then on to bug-buddy. E.g for the fish applet, the .server file has fish-applet-2, but bug-buddy gets That-stupid-fish as appname, because that is the string passed in to PANEL_APPLET_BONOBO_FACTORY(). The options for fixing this are a) adding these other names to all the .server files or b) fixing libgnomeui/gnome_segv to pass the binary name down to bug-buddy. opinions ? Fixing libgnomeui/gnome_segv sounds like the easiest route, and avoids bloating the server files too? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
tor, 08.03.2007 kl. 01.06 -0500, skrev Behdad Esfahbod: On Wed, 2007-03-07 at 12:58 +, Iain * wrote: Seeing as this is the only real reason for having this (I mean, who else has ever run the about program and looked at all the names in it) I'm not sure what the purpose of this message of you was, but anyway, I've done that a few times. Mostly when I was not maintaining anything in GNOME. So yes, there are people who do that (and yes, they are probably all geeks). So what are we going to do? Add 1000 new names? Where to put the cut? A simpler solution is to remove it. Or make it a pointer to a webpage somewhere on @gnome.org where this is maintained by whoever is in charge of the list of active contributors, cvs account holders, foundation members and so on. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: D-Bus vs jhbuild
man, 19.02.2007 kl. 11.50 -0500, skrev John (J5) Palmieri: On Mon, 2007-02-19 at 17:42 +0100, Alexander Larsson wrote: [snip] The original mail said that a system installed version of dbus was used, not one built with jhbuild. This is fine but you can still start up a new instance and point it to a correct configuration file. This is unless someone wants their JHBuild stuff to work with their installed desktop in which case setting XDG_DATA_DIRS to point to the correct directories should work though I never tested this particular usage. Maybe someone with the needed knowledge could update jhbuild/README? Nudge, nudge :-) Cheers /kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cairo-1.2.6 required
tir, 23.01.2007 kl. 10.33 -0700, skrev Elijah Newren: On 1/23/07, Kjartan Maraas [EMAIL PROTECTED] wrote: tir, 23.01.2007 kl. 00.00 +, skrev Chris Wilson: Hi, today I had the misfortunate to experience a crash with gnome-terminal. Fortunately Carl Worth was on irc at the time and was able to diagnose the problem as a known crash with cairo-1.2.4 and forwarding an X display across a heterogeneous network. To quote, Oh, this isn't the stupid -= 4 bug is it? If it's the bug we're thinking, then 1.2.6 should fix it. The suggestion is to update them minimum version of cairo required to 1.2.6 in http://live.gnome.org/TwoPointSeventeen/ExternalDependencies I think we're really aiming to use cairo 1.4.x for GNOME 2.18.x so it would make more sense to update the dep to 1.3.12 which is the latest snapshot. We are? If the timeline is far enough ahead of GNOME 2.18.0 and doesn't introduce any big issues for us, I'm all in favor of it, but I just hadn't heard what the timeline for cairo 1.4.x is or heard anyone proposing it? (Did I miss it during those weeks I was gone trying to finish my dissertation and somehow missed it when trying to catch back up on things? If so, could someone point me to the thread I missed?). Maybe Carl could comment? From cairo/ROADMAP: Targets === ... Gnome 2.18 - http://live.gnome.org/TwoPointSeventeen Looks like early January would be a great time to get cairo 1.4 out. I don't know how they're progressing towards this goal though. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RTL support in Gnome
ons, 17.01.2007 kl. 10.17 +0200, skrev Yair Hershkovitz: Hi, 1) I want to start a mailing list for RTL support discussions ( [EMAIL PROTECTED] ???) I don't think it's quite necessary. One reason is that only people directly interested in RTL support will be there, while most of the time one wants comment from main developers of modules or other interested hackers. You don't get it there. There are some issues with RTL supports that needs to be discussed. For example: Should window decorations switch sides when in RTL? Should desktop icons be aligned to the right in RTL (bug #397395)? When such a list exists, developers would also be able to use it to get help on how to support RTL in their applications. We can't leave the decisions of how RTL support should work to module developers and maintainers. I do think that GNOME should have an RTL group. Isn't this really just a specialized group within the i18n team? Can't it be solved there without creating yet another list, keyword in bugzilla etc etc? We (or you reallly) should also educate the maintainers through documentation and discussion over time to raise awareness on these issues from the design stage and up. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: accessibility enhancement need attention
ons, 10.01.2007 kl. 13.06 -0600, skrev George Kraft IV: The accessibility enhancement for Preferred Applications as discussed at the GNOME Summit in Boston is code complete, but it is only half way checked in. The rest of the bugs listed in the below referenced wiki need to be committed, or the two commits already done need to be backed out. I need advice on how to proceed. http://live.gnome.org/GAP/ScratchPad/PreferredApplications I have a question about how enabling/disabling a11y will work after these patches have gone in. As I understand it the keys for that along with the old preference dialog are scheduled for retirement? Will the patched gnome-session just do the right thing wrt atk-bridge and at-spi-registryd from now on based on whether you have enabled any ATs? What about moving Enable assistive technologies to the gdmgreeter? Then people wouldn't have to log out and back in to get it up and running (if it is still needed that is). Cheers Kjartan (who commited the schemas to support this ;-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: devhelp
man, 08.01.2007 kl. 19.40 +0100, skrev Vincent Untz: (Note: let's suppose we have a developer tools suite) Information about devhelp: http://developer.imendio.com/projects/devhelp Danilo's evaluation (i18n point of view): = DevHelp = No objections. I agree. This should really go in if we create a developer suite. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME subversion migration
tir, 26.12.2006 kl. 17.24 +0100, skrev Mikael Hallendal: 18 dec 2006 kl. 13.35 skrev Ross Golder: Hi Ross, Is there a way to submit modules that you don't want in the move? I have a module called 'loudmouth' that I will move to git as the old CVS repository renders obsolete. Maybe we should consider setting up a formal git infrastructure so that projects that want to use git will have a way to distribute their repositories in a more standard way across GNOME? git.gnome.org anyone? With a gitweb interface? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 2.17.3 Released!
GNOME 2.17.3 Development Release This is our third development release on the road towards GNOME 2.18.0, which will be released in March 2007. You all know what you have to do now. Go download it. Go compile it. Go test it. And go hack on it, document it, translate it, fix it. To compile GNOME 2.17.3, you can use GARNOME (http://www.gnome.org/projects/garnome/, which supports users and has additional/different modules available), or the jhbuild (http://www.gnome.org/~jamesh/jhbuild.html) modulesets (which use the exact tarball versions from the official release) available at: http://download.gnome.org/teams/releng/2.17.3/ The release notes that describe the changes between 2.17.2 and 2.17.3 are available. Go read them to learn all the goodness of this release: platform - http://download.gnome.org/platform/2.17/2.17.3/NEWS desktop - http://download.gnome.org/desktop/2.17/2.17.3/NEWS admin- http://download.gnome.org/admin/2.17/2.17.3/NEWS bindings - http://download.gnome.org/bindings/2.17/2.17.3/NEWS The GNOME 2.17.3 release is available here: platform sources - http://download.gnome.org/platform/2.17/2.17.3/ desktop sources - http://download.gnome.org/desktop/2.17/2.17.3/ adminsources - http://download.gnome.org/admin/2.17/2.17.3/ bindings sources - http://download.gnome.org/bindings/2.17/2.17.3/ WARNING! WARNING! WARNING! -- This release is a snapshot of development code. Although it is buildable and usable, it is primarily intended for testing and hacking purposes. GNOME uses odd minor version numbers to indicate development status. For more information about 2.17, the full schedule, the official module lists and the proposed modules list, please see our new shiny 2.17 page: http://www.gnome.org/start/unstable/ We hope you'll love it, The GNOME Release Team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Liboobs versions
tir, 05,.12.2006 kl. 03.13 -0300, skrev Mariano Suárez-Alvarez: Hi all, gnome-system-tools now depends on liboobs 2.17.4 while http://cvs.gnome.org/viewcvs/*checkout*/jhbuild/modulesets/freedesktop-2.18.modules?rev=1.8, which is used by the GNOME 2.18 moduleset, still lists 0.6.0. http://live.gnome.org/TwoPointSeventeen/ExternalDependencies would need a bit of liboobs love too. It seems the released tarball only requires 0.5.0, and we have 0.6.0 so we should be good. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GEdit wants enchant
tir, 05,.12.2006 kl. 01.51 -0300, skrev Mariano Suárez-Alvarez: Hi all, nowadays (http://bugzilla.gnome.org/show_bug.cgi?id=365899#c20), gedit depends on Enchant for its spell checker plugin. This dependency can be eliminated by passing --disable-spell to configure, but as spell checking is a rather important thing this sounds like a bad idea. I agree. But I'm not sure about Enchant and how widespread that is in various distros. Anyone? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: TARBALLS DUE: GNOME 2.17.3 Development Release
fre, 01,.12.2006 kl. 10.12 +0100, skrev Kjartan Maraas: Tarballs are due on Monday November 4th of December before 23:59 UTC for That is December 4th of course :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I apology
tor, 26,.10.2006 kl. 19.15 +0400, skrev Maxim Udushlivy: I want to apology about what I said recently on this list. I feel very bad about that, and please read why that happened. This is off topic for this list, but please don't laugh, I need to be listened. You seem to have more than enough self-insight to help you overcome your situation though. I wish you all the best and a speedy recovery and thanks for meaning well and trying to help even though it may have come out the wrong way. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
fre, 22,.09.2006 kl. 12.03 +0200, skrev Rob Bradford: On Thu, 2006-09-21 at 16:51 -0600, Elijah Newren wrote: On 9/11/06, Matthias Clasen [EMAIL PROTECTED] wrote: The topic came up earlier, and I think there was a general consensus that it is a good idea to freeze the versions of external dependencies, and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. Due to the feedback received so far, I've modifed the exact wording of the proposal and the list of versions a couple times so far. I thought it'd be worth posting the most recent version and asking if there was any further feedback on it or objections to it being adopted: Ace. I created and populated: http://live.gnome.org/TwoPointSeventeen/ExternalDependenciesDistroAnalysis for Debian. And I added two columns for FC 5 and FC devel Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
tor, 21,.09.2006 kl. 16.51 -0600, skrev Elijah Newren: On 9/11/06, Matthias Clasen [EMAIL PROTECTED] wrote: The topic came up earlier, and I think there was a general consensus that it is a good idea to freeze the versions of external dependencies, and use tarball modules for them in the gnome-2.18 moduleset in jhbuild. Due to the feedback received so far, I've modifed the exact wording of the proposal and the list of versions a couple times so far. I thought it'd be worth posting the most recent version and asking if there was any further feedback on it or objections to it being adopted: The basics: The versions of external dependencies that Gnome module may depend upon are listed on a link from the release schedule (http://live.gnome.org/TwoPointSeventeen/External Dependencies, for this release). It may be updated at any time by the release-team. Looks very good. Getting the list updated: If you want to add a new dependency or want one of the versions updated, make a good case for it on desktop-devel-list. In particular, provide reasons why it is important to bump the version number, explain any impact (compile and run time) on other modules, and list any additional external dependencies it would pull in. Be prepared for others to take a few days to test it (in particular, to ensure it builds) before giving a thumbs up or down. I'd like to see fontconfig updated to 2.4.1 since 2.4.0 lost API by accident. Also GnuTLS seems to have had a few releases with fixes for security issues in the 1.4.x series that we might want to look at. Other possible updates: - dbus: 0.93 contains a bunch of bugfixes and we probably want to help push dbus along towards a quality 1.0 release. - libgpg-error: 1.4 has some changes but nothing that is compelling enough to bump it I guess - libgcrypt: 1.2.3 has some minor bugfixes, not needed IMO - libmusicbrainz: 2.1.4 fixes buffer overflows and memory leaks so I would want to use that - libtasn: 0.3.6 has a bunch of bugfixes over 0.3.4, but I don't know if this is something we actually use or if it's just pulled in by gnutls. - opencdk: 0.5.9 has a few minor bugfixes and build fixes it seems - poppler: 0.5.4 fixes a bunch of bugs including crashes, build fixes, rendering issues, etc My impression is that we should bump fontconfig, dbus, poppler, libmusicbrainz and possibly gnutls at least. Available enforcement mechanism: If a module depends on either a new external dependency not listed here or a newer version of an external dependency than one listed here, we may revert to an older version of that module for Gnome 2.17.x (which may result in reversions of other modules too). The development version of that module can again be used once either this page is updated by the release-team or the new(er) external dependency is made optional. Or we could make it a prerequisite for module maintainers to go through the petition to get the dependency version bumped before adding the dep in the module? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: external dependencies; trolling for more feedback, pushing to make it official ; -)
fre, 22,.09.2006 kl. 10.34 -0400, skrev Joseph E. Sacco, Ph.D.: I believe that liboil-0.3.9 has a number of bug fixes. It appears to have been released a day after 0.3.8 was released: [ ] liboil-0.3.7.tar.gz 02-Feb-2006 23:06 804K [ ] liboil-0.3.8.tar.gz 21-Mar-2006 18:22 815K [ ] liboil-0.3.9.tar.gz 22-May-2006 21:41 814K That's two months and a day... Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
tor, 17,.08.2006 kl. 14.03 +0200, skrev Fabio Marzocca: On 8/12/06, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Chipzz was voicing a likely question of someone who hasn't seen Baobab before upon encountering Open in Baobab, not being a clueless user him-/her-self. We have just discussed on this sasme thread about that, and we agreed to use : Analyze Folder Usage, or something similar. Why discuss this again? Because that might not be the best string to use? :-) To me Analyze Folder Usage doesn't necessarily mean how much space the files in this folder takes. And it translates badly to norwegian at least... Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
fre, 14,.07.2006 kl. 13.22 -0400, skrev Dan Winship: Joseph E. Sacco, Ph.D. wrote: Rodrigo gently raises the seminal question, What is so different?. The answer is known: It is that enormous elephant standing in the corner that folks have been politely tip-toeing around, trying to ignore. Tiptoeing around the issue is NOT polite at this point. We are talking about letting mono into GNOME. This is it. This is the fork in the road. This is the part where we have the argument. Whatever your objections are, speak now or forever hold your peace. Had decided to keep quiet about this since it's more of a vendor/distro issue than anything else... But here goes... I think that one of many strenghts of our project is that it embraces many different technologies and development platforms if you will. It *has* to be up to the individual companies who have put their stake in the GNOME camp to define what subset/part/release of GNOME is right for their use of it. Clearly we've had a lot of innovation within the Python/Mono/gtk# camps lately, and if we had the same amount of innovation from the rest of the stakeholders we would all be better off from it IMO. GNOME should be less about what's in and what's not and more about *real* choice. GNOME should be about a uniform user experience stemming from apps that act the same and look the same more than about what development platform/base libraries the apps were made with. It's up you guys to decide which language/platform you want to use to get there, and I sincerely think that the end user doesn't give a damn about whether the app is mono based, java based, python based or an app made from whatever C libraries are in the core. We've grown up a lot since this discussion came up last and I still don't think we have to bless any one language/platform as *the* GNOME development platform. Time will tell if I'm right though. Godspeed to y'all and may the best app win :-) This broadcast has in no way been coloured by the taint of Single Islay Whiskey. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: LINGUAS file support in po directories
tir, 18,.04.2006 kl. 13.29 +0200, skrev Stanislav Brabec: Kjartan Maraas píše v Pá 14. 04. 2006 v 15:51 +0200: tor, 13,.04.2006 kl. 14.49 -0400, skrev Rodney Dawes: Looks OK to me. Perhaps you could add a note about the no/nb thing too, so that we can ensure all the modules are using nb now as the locale name. That would help alleviate the concerns that Joe Shaw brought up yesterday in his blog entry about po/LINGUAS. I'll start removing the no.po files and references during 2.15.x. Hopefully we'll have them all removed before 2.16.0. That doesn't fix it for all the non-GNOME packages in a normal distro though. Maybe teaming up with the GNU translation project on that task would be best. It seems to be my fault I did many years ago in the CVSROOT/commitinto script. But now I don't have any access to it. It's been fixed by Guillermo by now so don't worry :-) I did a review of all po files in projects included into SuSE Linux and I fould many problems: - Non dialect translations in dialect-specific directories. - Translations provided but locale not present in glibc. - Translations with invalid locale codes. I'm currently going through my Fedora Core setup and I'm trying to fix the issues I see for the norwegian variants at least. Hopefully that will result in fewer problems in all distros. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: LINGUAS file support in po directories
tor, 13,.04.2006 kl. 14.49 -0400, skrev Rodney Dawes: Looks OK to me. Perhaps you could add a note about the no/nb thing too, so that we can ensure all the modules are using nb now as the locale name. That would help alleviate the concerns that Joe Shaw brought up yesterday in his blog entry about po/LINGUAS. I'll start removing the no.po files and references during 2.15.x. Hopefully we'll have them all removed before 2.16.0. That doesn't fix it for all the non-GNOME packages in a normal distro though. Maybe teaming up with the GNU translation project on that task would be best. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: LINGUAS file support in po directories
fre, 14,.04.2006 kl. 15.51 +0200, skrev Kjartan Maraas: tor, 13,.04.2006 kl. 14.49 -0400, skrev Rodney Dawes: Looks OK to me. Perhaps you could add a note about the no/nb thing too, so that we can ensure all the modules are using nb now as the locale name. That would help alleviate the concerns that Joe Shaw brought up yesterday in his blog entry about po/LINGUAS. I'll start removing the no.po files and references during 2.15.x. Hopefully we'll have them all removed before 2.16.0. That doesn't fix it for all the non-GNOME packages in a normal distro though. Maybe teaming up with the GNU translation project on that task would be best. Sorry for replying to my own mail, but I'm having problems removing the files because the pre-commits script kick in on cvs rm of the files and complains because it's impossible to run msgfmt on a non-existing file. Could someone fix that please? I couldn't even check out the CVSROOT module since I'm not in the right group it seems. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: critical warnings; turn them off now?
tir, 07,.03.2006 kl. 15.39 +, skrev Bill Haneman: Hi; Since we're now in code freeze for 2.14, shouldn't we turn off the critical warnings behavior in gnome-session now? There are lots of places where this causes unnecessary crashes, particularly in gail and at-spi. While we want to fix them eventually, it's made accessibility pretty much DOA in 2.13 so far. I think the easy thing would be to branch gnome-session for 2.14.x and put the change in there. That said, I've been running with a11y enabled and G_DEBUG=fatal-criticals since it was added and the only app I've found it necessary to run with G_DEBUG='' is evolution. I've filed a bunch of bugs for the things that have popped up there and I think most of the a11y specific ones have been fixed or are under investigation, so things are definitely improving. We should definitely continue this through the next cycle and keep it as the default for every development cycle in the future in my opinion. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
ons, 08,.02.2006 kl. 23.20 +1100, skrev Jeff Waugh: quote who=Alan Cox It isn't about Design by community but Design IN the community. *Exactly* - and it's so easy to fall to laziness in the face of all the challenges Dan so eloquently explained in his email... and that's what has been happening in GNOME for a long time now. Let's break the cycle! While the Linux process has its warts, there are two things it is great at that we should mention here: First, a fairly easy to understand technical and social leadership - decisions get made. Second, a pretty uncompromising approach to design in the community - it's really hard to drop a pre-cooked hairball (cat hair *or* angel hair) into the kernel process without getting roasted, spanked and harshly reviewed. I think the main difference here is that most of the design/review/audit process for the linux-kernel happens on the mailing list[s] and we tell people to go argue about it in bugzilla. The reason we point people to other lists/bugzilla is exactly that we have the problem of too few eyes/minds and too many mouths on desktop-devel-list for example. We're not going to get around that by creating yet another mailing list every time we get annoyed by some thread that propelled into a useless semantic discussion or whatever. I think we'd be served well by making desktop-devel-list be *the* place for discussion about development and design issues and use other tools like bugzilla etc to complement this where that makes sense. If we compare ourselves to the linux-kernel we're seeing ridiculously small amounts of mail to our list compared with them. Use your power to delete a thread or a message if something is of no interest to you. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
ons, 08,.02.2006 kl. 10.55 -0500, skrev Dan Winship: Alan Cox wrote: So if Fedora, Ubuntu and every other Gnome using distribution also start doing tons of private development (Excluding Xgl, there was hardly tons of private development.) then trying to jam it all in CVS afterwards how do you expect Gnome to develop when all these variants suddenely try and get merged and all overlap and clash. We don't. A lot of people have assumed that we're expecting to force the new menu code into the GNOME mainline at some point, which I guess is a reasonable assumption given what happened with Ximian Desktop, etc, but that was never the plan here. At the moment we're not even planning to ship it in SUSE 10.1 (which is 90% the same codebase as NLD10). The new menu is something we did for NLD, and if the community wants it too, then great, but we didn't do it with the expectation that they necessarily would. It's like Industrial was. In a sense, but a theme is more self-contained and wouldn't need review in full the samme way that an extension to the panel menu code would. Nor does the committee argument stand up. It is perfectly possible to post in advance that we are going to do this, we've created a temporary alternate repository for the work and if you want to join in or help merge stuff back as it meets acceptability please sign up Yes, I shouldn't have suggested that secrecy was a necessary part of the mix. The secrecy doesn't necessarily help. But how does it actually *hurt*? Yes, there are integration issues in some cases, but not in this case. Yes, there are code review issues as you mentioned in another message, but it's not like the GNOME community and/or Red Hat is reviewing the work we do on YaST or iFolder or any of dozens of other non-GNOME things, so that argument also feels weak. Novell has also been doing tons of GNOME work in the open, so it's not like we're trying to get a free ride off GNOME. So what exactly have we done wrong? I don't think you've done anything wrong. Nothing that isn't weighed up by the great contribution this is to making linux on the desktop succeed. It just happens to stomp on a sore foot, so to speak. This is a community problem and it's the community that has to solve it if we want to avoid this kind of thing happening in the future. Good thing Novell is part of the community too :-) Looking forward to seeing some of this incredibly cool technology pop up on my desktop too one of these days. I think also that we sometimes put too much emphasis on never duplicating code or effort. I really think that it gives the community as a whole more experience in how to approach a certain problem and that both sides can learn from each other's mistakes when this happens. I'm sure there are lessons to be learned from metacity/libcm/compositor vs. Xgl/compiz that will benefit both projects long term. There are probably other examples of the same. I do mostly agree that you could have achieved the same step forward codewise without the secrecy, but it would have created a fuss and you would have lost the fun of announcing something entirely new to the world :) Cheers and thanks to everyone involved for doing all the work this must have been. Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
ons, 08,.02.2006 kl. 12.09 -0500, skrev Rodney Dawes: On Wed, 2006-02-08 at 17:43 +0100, Kjartan Maraas wrote: In a sense, but a theme is more self-contained and wouldn't need review in full the samme way that an extension to the panel menu code would. It's not an extension to the panel menu code. It's not even a patch. It's a completely separate applet. This is in fact, in no way different than a theme engine in terms of integrating it upstream, into a larger conglomerate package. Why do people keep assuming every change someone does, is a patch? There are much better ways to do a lot of this stuff, than patches, with the architecture we have. I'm all the more pleased to hear this. Maybe if this had been communicated more clearly from the outset we would have avoided this kind of confusion :-) (or maybe I didn't do my homework before commenting). Anyway, this wasn't really the important part of my reply to Dan so don't read too much into it. And frankly, we need to show ISVs that it can be done, so they will start doing it too. We need their support, if we're going to succeed at actually getting Linux and GNOME to be usable and on desktops in the Real World (TM). I agree fully. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver
tir, 07,.02.2006 kl. 14.55 +0800, skrev Davyd Madeley: On Tue, Feb 07, 2006 at 07:53:15AM +0100, Kjartan Maraas wrote: tir, 07,.02.2006 kl. 12.10 +0800, skrev Davyd Madeley: 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've seen the lock screen dialog taking 20-30 seconds to give me a username entry and ended up disabling locking. That is certainly unacceptable I think. I tested again now and the bug is gone here at least. 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 think there were some problems with fontconfig recently that caused slowness in many apps, could this be one of them maybe? AFAIK it has been fixed in the latest updates. Don't seem to be having problems with other applications (in fact many things are quite snappy, large Cairo-exposes excluded of course). I've also noticed this on Dapper, which did not have fontconfig issues that I noticed. These issues should be addressed before we consider including this as a blessed Desktop module. Do you have the latest fontconfig stuff for Ubuntu? I think they have updates there that should fix it *if* it is the same problem I was seeing. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New schemas aren't picked up by running gconfd-2 [was Re: rawhide report: 20060125 changes]
tor, 26,.01.2006 kl. 13.51 +0100, skrev Josselin Mouette: Le jeudi 26 janvier 2006 à 13:37 +0100, Alexander Larsson a écrit : We have been doing this in Mandriva for about one year now (using the patch at http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/GConf2/GConf-2.8.1-reload.patch ) and I didn't get any complain nor bug report for it. killall as root kills all processes on the system on solaris, I think. So this might not be a perfect patch for upstream. :) It does the same on Linux. The purpose is to signal all running gconfd-2 processes in user sessions. What Alex was trying to say was that killall kills *all processes on the system* on solaris. Not just all gconf daemons. Definitely not what you want upstream Cheers Kjartan ___ 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
fre, 20,.01.2006 kl. 09.39 +0800, skrev Davyd Madeley: Quoting Elijah Newren [EMAIL PROTECTED]: On 1/18/06, Davyd Madeley [EMAIL PROTECTED] wrote: I'm with Ryan on this. I think we should give vendors a choice for the time being. It looks like the vendors have already jumped on and chosen g-p-m. Once again, I ask the question, what about our non-Linux vendors? Status quo? Or they can start working on creating the same kind of interfaces that g-p-m or the mythical PowerManager can use on the platforms where HAL doesn't work? Having it must work on all platforms as a criteria for inclusion is not going to work when we're talking about stuff that is this close to the hardware IMO. At least not in the near future. As for creating another ESD I don't know what all the fuss is about. I think the problems caused by us using ESD are greatly exaggerated, both in techical terms and wrt maintainability. The package has needed close to zero work the last few years and I don't see a lot of people complaining about it in bugzilla at least. What they do in the various forums is a different issue, but some people will disagree no matter what choices we make. Cheers Kjartan ___ 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
tor, 19,.01.2006 kl. 15.19 -0700, skrev Elijah Newren: On 1/18/06, Davyd Madeley [EMAIL PROTECTED] wrote: I'm with Ryan on this. I think we should give vendors a choice for the time being. It looks like the vendors have already jumped on and chosen g-p-m. I'm in favour of this too. Most of the main distros already use it and I think going back to the design stage for the ultimate power manager will just serve to drag this issue out. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glib 2.10 / Pango 1.? for GNOME 2.14?
ons, 18,.01.2006 kl. 10.21 -0600, skrev Federico Mena Quintero: Sorry that I dropped the ball on this, and haven't followed all the discussion. Other than Pango optimizations and and GSlice in Glib, is there a compelling reason to use the new Glib/Pango in GNOME 2.14? I think the pango optimization work is what prompted the move to Glib 2.9.x. Not sure the other stuff is really compelling, but... - Was the ABI issue resolved with respect to GObject floating references? Changing the object hierarchy sounds like a definite break to me. Leaving this for others to answer. - There is no way yet to disable GSlice, so we can't valgrind apps. We can't? I've been valgrinding apps successfully with jhbuild + glib HEAD for some time now, what's broken? - Are there any apps using the new Glib APIs now? I know gnome-utils started using g_slice_* from this release on and I saw Christian and Alex discussing the use of it in gnome-vfs before the release too, not sure whether any of that actually happened. Other than that I don't know if anyone started using any newly added api's from Glib/Pango. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
ons, 18,.01.2006 kl. 12.44 -0700, skrev Elijah Newren: On 1/15/06, Vincent Untz [EMAIL PROTECTED] wrote: Hi all, So, the release team messed up and didn't keep close enough tabs on everything, resulting in discovering an issue pretty late. We need to try to find rough consensus in the community. So, here's my understanding of this thread and the alternate one[1] (feel free to correct anything I got wrong; I am not an expert in this area by any means): - There is no good or optimal solution; all choices have multiple drawbacks. :( We still have to pick one, though. - 0.10 is more stable in the doesn't-crash sense, but has a less complete set of plugins and thus cannot handle as many formats - The regressions that exist from the less complete set of plugins are limited to totem - these regressions are for formats we can't ship anyway, though they do limit what can be played in totem for those non-tree-hugging-lefties[2] who would otherwise be able to just download extra plugins. - 0.8 has very little development or maintenance effort and has unfixable problems due to inherently problematic API (causing various crashes, as noted above) - 0.8 and 0.10 can be installed simultaneously, though actively depending on both is a bigger maintenance load that would probably be better spent fixing stuff, and it may also be more annoying to users since preference applets only affect settings for one of the two versions (granted, this will only affect the users who don't want to use the defaults and who are able to understand those dialogs) - Those actively working on gstreamer now recommend 0.10, Ronald (who has done *huge* amounts of gstreamer work in the past and is volunteering to continue to work on 0.8 as his time permits) prefers 0.8 - most distros appear to be moving to 0.10 (JDS, Ubuntu, Fedora; Fedora is shipping both versions, but 'gstreamer' is 0.10 while there's also a 'gstreamer08') - not knowing what we're using is holding up the 2.13.5 release So, here's my proposal: Ship with 0.10. Have everything default to it. Also include 0.8 in the ftp directory, but not used. Include a big old section in the release notes explaining the situation and letting people know that they can recompile totem or compile a second version of totem against 0.8 if they wish. I'm with you on all points. I would like to see the GStreamer hackers fix as many of the known issues ASAP though. Not that I expect them to get to them all, but it would be nice to make stability and feature parity priority #1 in the remaining time before the final release. I know you can do it! :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
ons, 18,.01.2006 kl. 00.22 +1100, skrev Jeff Waugh: quote who=Frederic Crozat Le mardi 17 janvier 2006 à 10:48 +0100, Andy Wingo a écrit : Hi Vincent, On Mon, 2006-01-16 at 22:42 +0100, Vincent Untz wrote: Well, the question is: is GStreamer 0.8 totally unmaintained? Yup. Thanks for all the people running deployed software running Gstreamer 0.8 :( Is GNOME 2.10 maintained? Perhaps the even more relevant analogy is that by the time GNOME 2.14 is out GNOME 2.12.x won't be maintained if you interpret it like this. Sure, if there are critical things that pop up people will commit the fixes to the stable branches and maybe even do a release, but that's about it from my experience. Maintenance happens on *one* stable branch at the time and that's more than enough work to keep us busy. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Update from libegg now!
Hi. It would be nice if everyone remembered to update code they've cut'n'pasted from libegg so we make sure that any improvements there are available in the next development snapshot. I know the egg-recent code has had fixes lately at least. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: autotools gives autopain
fre, 16,.12.2005 kl. 18.13 +0100, skrev BJörn Lindqvist: Gnome currently uses the GNU Autotools for building all projects. Autotools is hard to work with and complicated and there are lots of techically superior build systems out there. Therefore, I suggest that GNOME should gradually replace Autotools with scons (www.scons.org). I'd suggest that this would not be a very interesting topic of discussion on this list *unless* you converted one of the existing GNOME modules to scons Right. That's the easy part. Any GNOME modules wanna sign up for a FREE conversion to scons? Limited supply, order now! How about gnome-hello? It's supposed to be the template for any gnome module... Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] Re: Enable accessibility by default in development releases?
ons, 30,.11.2005 kl. 23.15 +0800, skrev Davyd Madeley: On Wed, 2005-11-30 at 01:33 +0100, Kjartan Maraas wrote: I've commited the patch along with a minor cleanup of mine. Maybe we need to get a new vte release out the door soon too? While people are reviewing patches and things. Did someone want to have a read of http://bugzilla.gnome.org/show_bug.cgi?id=98715 so that we can commit that fix? I took Havoc's word for it and commited the fix. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enable accessibility by default in development releases?
fre, 11,.11.2005 kl. 12.20 -0500, skrev David Malcolm: Currently, a11y is not enabled by default in GNOME, as it has a performance cost (CPU and memory usage). But that means that there's a huge amount of code that isn't being exercised by most testers and developers. So here's a (possibly crazy) suggestion: during development releases, enable a11y by default, and during stable releases, disable it by default. That way people running jhbuild, GARNOME etc would be running all of the a11y code, and any bugs in that layer would be discovered more quickly. I'm all for it. Maybe we can get a11y stuff profiled as well and close the few performance related bugreports for it along the way too. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Sign up here to embark on a quest to kill CRITICAL warnings
Hi all. A couple of days ago we experimented with adding G_DEBUG=fatal_warnings to the default session, but it turned out that everything started crashing then since it bombs out on simple g_warning() calls etc. Vincent then made a patch for glib that adds G_DEBUG=fatal_criticals This can be found here: http://bugzilla.gnome.org/show_bug.cgi?id=320017 If you are brave please apply this patch to glib and add a line like this: putenv (G_DEBUG=fatal_criticals); to gnome-session/gnome-session/main.c at the beginning of main(). I ran into a problem with bug-buddy crashing after doing this on my rawhide system and filed a bug for that here: http://bugzilla.gnome.org/show_bug.cgi?id=320062 Not sure if that will cause problems on other systems, but it made it hard for me to file bugs against anything... There's also an issue where bonobo-activation-server needs to redirect debug output for components to separate pipes so that this ends up in .xsession-errors or the equivalent file for every user. Maybe Federico can chime in with the details on that issue. Happy crashing :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Sign up here to embark on a quest to kill CRITICAL warnings
Hi all. A couple of days ago we experimented with adding G_DEBUG=fatal_warnings to the default session, but it turned out that everything started crashing then since it bombs out on simple g_warning() calls etc. Vincent then made a patch for glib that adds G_DEBUG=fatal_criticals This can be found here: http://bugzilla.gnome.org/show_bug.cgi?id=320017 If you are brave please apply this patch to glib and add a line like this: putenv (G_DEBUG=fatal_criticals); to gnome-session/gnome-session/main.c at the beginning of main(). I ran into a problem with bug-buddy crashing after doing this on my rawhide system and filed a bug for that here: http://bugzilla.gnome.org/show_bug.cgi?id=320062 Not sure if that will cause problems on other systems, but it made it hard for me to file bugs against anything... There's also an issue where bonobo-activation-server needs to redirect debug output for components to separate pipes so that this ends up in .xsession-errors or the equivalent file for every user. Maybe Federico can chime in with the details on that issue. Happy crashing :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome-utils branched
tor, 06,.10.2005 kl. 20.10 -0400, skrev Vincent Noel: On 10/6/05, Luis Villa [EMAIL PROTECTED] wrote: _ 2.13? (everyone play 'fill in the blank' first, then when vincent responds, play 'fill in the wiki') I have no idea what you're talking about. What is a wiki anyway ? This is Luis's way of asking you to fill in plans for 2.13 in the wiki on live.gnome.org. Maybe you were kidding, but I thought I'd answer anyway :) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Opportunity for participation in Gnome releases
tor, 06,.10.2005 kl. 14.08 +0530, skrev Harish Krishnaswamy: On Wed, 2005-10-05 at 16:55 -0600, Elijah Newren wrote: - Creating an ical file for the 2.13 srelease cycle Please find attached an ical file for the 2.13 release cycle. You can import this into your Evolution calendar. I find it slightly amusing that Evolution gives me the choice between saving the file to disk or opening it in Korganizer :-) Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Valgrind logs off a fresh jhbuild of 2.12
Hi. I tried building HEAD off jhbuild last night and today and the result of logging in doing some small tasks in the panel and opening a terminal etc. I filed one bug against gdk with a cairo related leak already, and I found another one that I have a patch for in gnome-screenshooter. Other than that I had some redraw problems on the desktop. It seemed to draw text and icons repeatedly over the existing one without refreshing the desktop, the new text and icon also moved up slightly for each iteration so it looked really bad after a while. Possibly som cairo issue? Screenshot of this is here: http://www.gnome.org/~kmaraas/skewed-desktop.png I had very few problems building this. The ones I remember are - gst-plugins not building because of some gcc4 warning - gnome-media needed a build fix (now in CVS) - eel doesn't build unless you pass it --enable-more-warnings=no when using gcc4 - probably some other issues I forgot :-) Hope someone finds this useful Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
We need working docs
Hi. It seems that a lot of the help buttons in various apps/applets/panel aren't hooked up correctly. This would (hopefully) be a nice and easy task to complete before 2.10.2 goes out. My testing shows that the following help buttons are broken: (this is on a FC4 test release with gnome-user-docs installed) - panel context menu - add to panel dialog - show desktop button context menu - window chooser applet context menu - panel properties dialog - nautilus backgrounds and emblems dialog - nautilus properties dialog - nautilus file properties dialog - nautilus-cd-burner opens the top level nautilus manual instead of the section about burning cds gnomecc: - sound preference dialog - ui preference dialog - mouse preference dialog . These are just examples, and opening the nautilus user manual and trying to click on anything in the left hand index also produces the same kinds of errors where it can't find the section in question... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: We need working docs
tor, 12,.05.2005 kl. 09.21 -0400, skrev Matthias Clasen: On Thu, 2005-05-12 at 14:57 +0200, Kjartan Maraas wrote: Hi. It seems that a lot of the help buttons in various apps/applets/panel aren't hooked up correctly. This would (hopefully) be a nice and easy task to complete before 2.10.2 goes out. My testing shows that the following help buttons are broken: (this is on a FC4 test release with gnome-user-docs installed) - panel context menu - add to panel dialog - show desktop button context menu - window chooser applet context menu - panel properties dialog - nautilus backgrounds and emblems dialog - nautilus properties dialog - nautilus file properties dialog - nautilus-cd-burner opens the top level nautilus manual instead of the section about burning cds gnomecc: - sound preference dialog - ui preference dialog - mouse preference dialog . These are just examples, and opening the nautilus user manual and trying to click on anything in the left hand index also produces the same kinds of errors where it can't find the section in question... This is a yelp problem. Links which point to anchors in entities other than the main document seem to be broken. That's good to hear, but I think the main point still stands. A lot of the links in the code are non-existant, or pointing to the wrong part of the manual. We should review this and make sure all help buttons open the right document starting in the right paragraph. Is the yelp issue filed in bugzilla btw? Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Attempt to clean up gconf usage in gnomecc some...
tor, 21,.04.2005 kl. 16.23 +0800, skrev James Henstridge:
Kjartan Maraas wrote:
@@ -1107,15 +1113,20 @@ peditor_numeric_range_widget_changed (GC
GtkAdjustment *adjustment)
{
GConfValue *value, *value_wid, *default_value;
+GConfClient *client;
if (!peditor-p-inited) return;
/* We try to get the default type from the schemas. if not, we default
* to a float.
*/
+client = gconf_client_get_default();
+
default_value = gconf_client_get_default_from_schema
(gconf_client_get_default (),
peditor-p-key,
NULL);
+g_object_unref (client);
+
if (default_value)
value_wid = gconf_value_new (default_value-type);
else {
This bit doesn't look like it leaves the reference leak -- instead of
calling gconf_client_get_default() once and g_object_unref() zero times,
it calls gconf_client_get_default() twice and g_object_unref() once.
Fixed this one and a couple of others mentioned in this thread. Updated
patch is in bugzilla now:
http://bugzilla.gnome.org/show_bug.cgi?id=301945
In a lot of these cases, wouldn't it be easier to just get the
GConfClient once at application startup, store it in a global variable
and use that each time? It looks like this patch adds a bit of clutter
for only theoretical gains -- since the default GConfClient is
essentially a singleton, the only thing you really need to worry about
is reference count wrap around (which is not likely to happen and could
be solved by just getting the client at startup).
Sounds like a good plan, but I didn't have time to rework all the uses
to follow this...
Cheers
Kjartan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
CALL FOR TARBALLS: 2.10.1
Hi there. The time has come for the first stable point release of GNOME 2.10.x. Tarballs are due end of monday, and hopefully the release will go out as planned after that. Get 'em rolling... Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: vte [was Re: houston, we have a problem- 2.10 showstoppers]
fre, 04,.03.2005 kl. 18.01 +, skrev Bill Haneman: Kjartan Maraas wrote:... I went ahead and commited the fedora patches today, and included a couple of patches from bugzilla that other distros have been shipping with for some time. Can we leave it at that for now and drop the fork? ... What about the a11y patches? Am I wrong, or did all this do nothing to improve that situation? I concentrated on the Fedora patches because I knew they were there since I use them every day. Nobody has raised the a11y patches as something that is critical for 2.10.0 until now, if that was what you meant my this? We can always roll a new tarball if the patches have been tested in JDS for a long time...or wait for 2.10.1 Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
