Re: Feedback from downstreams presentation from DX hackfest 2015
hi, On Mon, Feb 2, 2015, at 10:10, Michael Catanzaro wrote: FWIW, if you run devhelp with jhbuild, you will get documentation for the version of the library in jhbuild. This is only true if the docs are actually built, which is not the case by default (and, unless we dramatically improve performance, shouldn't be). Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
a request from a friend in KDE
hi all, A couple of years ago I got the chance to meet Mario Fux at a KDE technical summit that I was invited to (which he organised and put quite a lot of work into). He's doing a thesis that requires input (a survey) from as many free software contributors as possible. Since he didn't want to randomly spam our lists, he asked for me if I could pass this letter on to as many GNOME hackers as I could. I apparently don't have his restraint when it comes to not randomly spamming. Sorry for that. If you want to ignore this message, feel free. Otherwise, if you have some spare time before Sunday, please consider helping out a friend. His message follows. Thanks, and sorry for the noise. From: Mario Fux m...@ife.uzh.ch Dear Free Software contributor* I'm currently in the process of writing my diploma thesis. I've worked hard during the last few weeks and months on a questionnaire [1] which shall collect some data for my thesis. Furthermore the data of this survey will be interesting for the Free Software communities as well. So please take some time or add it to your todo list or, even better, go directly to my questionnaire [1] and help me make a great diploma thesis and improve the Free Software community in some ways. The questionnaire [1] takes some 20 to 30 minutes. At the end of the questionnaire you'll find a way to participate in a draw where you can even win something nice. In a first round I got the feedback that the length of the questionnaire [1] and that some questions (mostly the ones at the beginning of the questionnaire about the 12 different tasks) are quite abstract and difficult. But please try it, try your best and take the time and brain power. The remaining part of the questionnaire [1] (after these two pages with the tasks questions) is quite easy and quickly done. And you have the possibility to come back to where you have left filling in the questionnaire [1] after a shorter or longer break. And if there are any questions, feedback or you need help don't hesitate a moment to write me an email or ping me on IRC (freenode.net and oftc.net) as unormal. This survey will be open till Sunday, the 9th of March 2014, 23.59 UTC. Thanks to all for reading and helping and towards the summer of 2014 you can read here what all the data you gave me showed us and where we can learn and improve. Thanks in advance and best regards Mario Fux [1] http://survey.kde.org/index.php/783182/lang-en * By contributor I mean not just developers but translators, artist, usability people, documentation writers and many more. Everybody who contributes in one way or the other to Free Software. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: hard systemd dependency?
On 12-11-12 08:39 AM, Matthias Clasen wrote: On Sun, Nov 11, 2012 at 9:46 PM, Ryan Lortie de...@desrt.ca wrote: I'll keep an eye on the bugs. It appears both patches have landed now. Does g-s-d build again for you ? No. Colin's patch to gnome-settings-daemon removed the libsystemd-login pkg-config dependency from one line but added it again to another (for 'power') where I'm pretty sure it's not needed (as it wasn't there before). I commented on the bug about that. This can definitely wait until everyone is awake and has had their coffee. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
hard systemd dependency?
hi, I'd open a bug for this but it's going to turn into an annoying metadiscussion in any case, so let's just start here. http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a1ab95fae75dd61fd50165b4d8a08b5588245273 As of that commit, gnome-settings-daemon has a hard hard[sic] dependency on systemd. Before that, at least you could jhbuild GNOME on Ubuntu or non-Linux platforms. There was even some hope that GNOME would be fully functional on those platforms if they implemented the proper D-Bus interfaces. I don't really care one way or another if systemd is a hard dependency of GNOME or not. I'd actually sort of prefer that it was, so that we could stop wasting time on maintaining crusty code and (perhaps more importantly) stop having these discussions. It seems like this is the sort of thing that should be discussed before just doing it, though. I don't really agree with the justification in the commit message that this doesn't really add any new dependencies because the effect is quite real: it's currently not possible to jhbuild GNOME on Ubuntu[1]. This is particularly worrying in light of the discussion we had at Boston Summit where we decided that keeping jhbuild working on Ubuntu would be one of our goals... Anyway... if we are really entering into a strong systemd-only world (and not merely communication with standard systemd D-Bus interfaces) then I'd prefer if we did that with an explicit declaration by the release team and not a commit with a misleading log message made by a single maintainer. Cheers [1] Those who want to try jhbuilding GNOME on Ubuntu can always get the libsystemd-login-dev packages from Debian and install them on their system. jhbuild will be successful but you'll be left with a PolicyKit compiled against systemd and, as a result, a gnome-shell that aborts on login: https://bugzilla.gnome.org/show_bug.cgi?id=687556 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: hard systemd dependency?
hi Matthias, On 12-11-11 09:45 PM, Matthias Clasen wrote: We are not, at least in 3.8. The current g-s-d build failure is temporary. Thanks for the quick reply and sorry for not doing a bit more research first. I'll keep an eye on the bugs. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
hi Bastien, On Fri, 2012-01-20 at 12:36 +, Bastien Nocera wrote: No, the distributions/systems that choose not to use systemd will have to provide a compatible D-Bus service. This is what I guessed you'd say. It can be something extracted from systemd, or something new and revived from the old date and time mechanism, but it won't be something we support and maintain in gnome-settings-daemon. And I'm glad I have 3000 less lines code to maintain. I'm just a little bit concerned about how this looks. I love when we can delete code, but we're doing it by disabling a previously-working feature for a portion of our users. If we introduced new optional features that depended on a particular systemd functionality in order to operate, it would be one thing. We do that often. This change is a regression of existing functionality in the name of I don't feel like maintaining it anymore. I'd also feel a bit better if I thought you had made efforts to get in touch with those that would be affected by this regression. Ubuntu isn't shipping GNOME 3.4 g-s-d/g-c-c, this cycle, for example, but for the last week I've been trying to convince them that they should. If I had succeeded (which I am now glad I didn't) then this change would have been a royal pain, creating a whole lot of new work to fit into an already full schedule. Many of our own end-users will still want to install GNOME 3.4 onto their Ubuntu systems (myself included). I look forward to the mention in our release notes about how they can no longer change their time because we wanted to delete a bit of code. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 08:59 -0600, Ted Gould wrote: I think that this would be more apparent if the DBus interface descriptions were maintained outside of the systemd codebase. http://www.freedesktop.org/wiki/Software/systemd/timedated I won't comment on if you accept this as being sufficiently divorced from systemd or not... Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
On Fri, 2012-01-20 at 14:30 +, Bastien Nocera wrote: This particular change was mentioned nearly a year ago on this very same list. It's not my fault Ubuntu (in this particular case) didn't take the hint to start packaging the relevant D-Bus services, or rewriting them to fit their use. If you are referring to the discussion that happened last May, I would consider it a mention, certainly... but nothing like any sort of a notification. You said that you wouldn't mind making use of the interfaces, but would prefer if Lennart could make more efforts to split them out so they could be used on other platforms. Lennart replied that he would do no such thing, and as far as I know, that was the end of the conversation. This doesn't fit my idea of effective communication of intent. You're making a fuss because you (Ubuntu) Are you attempting to annoy me... Stop this us vs. them thing ...or just set up for a double-take? and get them to package up the missing bits. An afternoon's work, and no need to scream bloody murder. As mentioned above -- Lennart has no intention of making it easy to use his code outside of systemd (and I don't blame him). This is not a matter of some simple packaging -- more like reimplementing a D-Bus interface in a new code base (which could originally be copied out of systemd, but then would have to be maintained separately). This is not an afternoon's work. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
hi Bastien, On Thu, 2012-01-19 at 22:38 +, Bastien Nocera wrote: commit 27fa171efe4179c0a42ec79e0dc501077f042a08 Author: Bastien Nocera had...@hadess.net Date: Thu Jan 19 22:33:21 2012 + datetime: Remove datetime D-Bus mechanism Now that gnome-control-center uses systemd's date time mechanism[1], we don't need to ship our own mechanism for that purpose. This also removes the last user of dbus-glib in gnome-settings-daemon [2]. Are there plans to provide a systemd-compatible backend for those systems that cannot run systemd? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gobject/gthread linking problems
hi all, Due to the recent threading changes in GLib it is no longer necessary for gobject to be linked against libgthread and therefore we removed that dependency. Unfortunately, libgthread was accidentally added as a *public* dependency of libgobject. The result of this is that for quite some time, applications have been able to get away with calling g_thread_init() without actually listing gthread among their dependencies. Since we have now dropped that dependency, these applications will start breaking. There are two approaches to solving this: 1) If you care about working with truly ancient versions of GLib (from before gobject started depending on gthread in 2.24) then you can explicitly declare your dependency on gthread and continue to call g_thread_init(). In this case you probably don't have this problem anyway, though, since you would have had this problem when building against those old versions already. 2) Stop calling g_thread_init(). It is completely redundant in 2.31 and if you are calling g_type_init() already then it has been redundant since 2.24. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
hi Murray, On Fri, 2011-09-16 at 10:05 +0200, Murray Cumming wrote: No packager has mentioned any problem with gtkmm and friends. This is not about reducing problems for packagers. It's about reducing problems for those who try to build your module via jhbuild. If you jhbuild a maintainer-mode-disabled module, then later on someone does a commit that introduces a new file (and updates the Makefile.am to add it) then on next build, the build is broken. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Use of maintainer mode in GNOME modules
hi, On Wed, 2011-09-14 at 12:22 +0100, Ross Burton wrote: Because maintainer mode existing is really annoying when you are a packager, and tying arbitrary unrelated changes to an option that is documented as only changing the make rules is just wrong. --enable-maintainer-mode enable make rules and dependencies not useful (and sometimes confusing) to the casual installer Options should do one clearly defined thing. What if a packager needs maintainer mode off but wants the GTK+ integration? I really agree with this point. We're currently suffering because gnome-common also ties maintainer mode to the enabling of deprecation checks and we're not sure we want these to be enabled by default for casual tarball downloaders. My suggestion to anyone affected by any issues tied to side effects of maintainer mode is to either create a new flag to control these effects directly or, if unable to do so now, to temporarily revert the '([enable])' patch until such a time as it is practical. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: G_CONST_RETURN
(replies to gtk-devel-list please) hello desktop-devel and gtk-devel lists, On Sat, 2011-03-12 at 22:47 -0500, Ryan Lortie wrote: The current plan is to remove uses of the macro from glib and gtk+ and add a notice about the pending deprecation to the documentation. The next few months will serve as a 'grace period' for other libraries to clean up their headers. After that, we will introduce the deprecation in the usual way and deal with the (hopefully reduced) fallout. It's been a few months. I've committed removal of use of G_CONST_RETURN to GLib (fixing a few problems in GObject) and added the deprecation notice to the documentation. Javier, Emmanuele and myself have been fixing various libraries and applications. We've filed bugs and committed a lot of fixes to various low-level things like atk, pango, gdk-pixbuf, gtk+, clutter and many others. It's been a few months, and there have been no objections, so we're just about ready to go ahead with the next stage of the plan. If you haven't already done so, please check your modules for G_CONST_RETURN and replace it with plain const. If you're using G_DISABLE_CONST_RETURNS then please take the time to fix your code not to depend on this hack. http://people.gnome.org/~fpeters/reports/g_const_return.html Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
G_CONST_RETURN
(replies to gtk-devel-list please) Greetings, I just opened bug #644611 about deprecating G_CONST_RETURN. After discussing this with Matthias on IRC, it is our intention to phase out use of this macro in our platform. The usual way that we would do that is by removing our own use of it and marking it as deprecated (and guard its definition with the usual G_DISABLE_DEPRECATED check). Unfortunately, the macro appears very widely in the headers of many of our platform libraries. If an application using G_DISABLE_DEPRECATED #includes one such header, their build is broken. That would impact... well, just about everyone. For this reason, we've decided to 'take it slowly'. The current plan is to remove uses of the macro from glib and gtk+ and add a notice about the pending deprecation to the documentation. The next few months will serve as a 'grace period' for other libraries to clean up their headers. After that, we will introduce the deprecation in the usual way and deal with the (hopefully reduced) fallout. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GSettings best practice
Hi everyone, We were sitting around at the Boston summit today (me, vuntz, tedg, and pbor via IRC) noticing that we have a mix of people using /apps/gedit/ sort of paths and /org/gnome/evince/ sort of paths in GSettings. We all prefer /org/gnome/evince/ type of paths. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings best practice
On Sun, 2010-11-07 at 11:24 -0500, Ted Gould wrote: Uhm, yes. :) I think they're just going to have to migrate. It should be a relatively straight forward transition. One way or another, one group of app developers will be burned here. At the same time, gsettings - gsettings migration sounds like a particularly horrible proposition. I'm sorry, and I'm open to suggestions. :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings best practice
On Sun, 2010-11-07 at 14:02 -0500, Diego Escalante Urrelo wrote: Btw, are caps allowed in schema names? We should state it a bit louder to prevent future chaos too. yes. I feel the current compromise about this that we see in DBus bus names is about the right balance for schema names. Paths should probably always be all-lowercase. Keys must be. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Session DBus protocol
hi, Vincent and I are sitting on a couch here at UDS reviewing the DBus protocol used by gnome-session. I am interested in adding support to GtkApplication. My biggest concern is that the emit signal and wait 1 second approach for checking which clients want to stop the logout from happening is really bad. 1) Some clients might miss the deadline (if they are swapped, or the system is really bogged down). Data loss here. 2) We may end up waiting for 1 second completely unnecessarily. I was wondering if maybe we could improve this interface to work more like the following: 1) Clients that may want to block the logout register themselves with gnome-session. 2) gnome-session does a AddMatch on their NameOwnerChanged so it can tell if they exited (and unregister them). 3) At logout time, gnome-session makes a method call to each registered app and *waits for a reply*. The length of time to wait should be much longer than 1 second. Similar to the close button on unresponsive windows, we could pop up a this application is stuck dialog in that case allowing the user to kill it if they explicitly choose to (but never assuming that no reply equals no data to save). Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Session DBus protocol
On Mon, 2010-10-25 at 20:16 -0400, Matthias Clasen wrote: I fail to see any difference ?! All this is already happening with the way things currently are... Two situations combined to confuse me: 1) I guess we don't have enough bugs because I've never seen the current you have apps not responding dialog. 2) I only read the spec which doesn't mention that this might exist. Matthias set me straight on IRC. In short, I actually have absolutely no complaints about how it works now. Please disregard. :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: G/tkApplication
On Tue, 2010-10-19 at 12:05 +0100, Luis Medinas wrote: So now it's safe for us to use GApplication again :) ? Or there is any possibility things will change a lot during this release cycle ? We ported Brasero on 2.31 cycle and almost at the end we had to move back to unique (mostly copypaste code). Minor changes are likely as I receive feedback on the API. Major changes are unlikely. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
G/tkApplication
Hi, While I wasn't looking, Cody Russell gained access to my laptop and pushed the GApplication branch to glib master. He admits to it, even: http://twitter.com/bratschegnome/status/27779385082 Shortly afterward he redeemed himself (and fixed the GTK build) by pushing the new GtkApplication code. The upshot, though, is probably that quite some application that were making use of the old GApplication have stopped working. My recommendation is to check out this small example application that I've included in Gtk: http://git.gnome.org/browse/gtk +/tree/gtk/tests/gtk-example-application.c The actions stuff is not implemented in the new GApplication yet, but it will be coming soon (probably this week, since we're all at the hackfest together). I don't think anybody is currently heavily depending on that for functionality at this point... The docs could probably also use some love at this point. I'll be on that tomorrow, probably. If you need any help with fixing your apps, please ping me on IRC or ping someone else you know is at the hackfest and have them give me a poke. Sorry for the disruption. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GLib 2.26 release plans (and GApplication)
hello everyone This is, in part, a followup to my earlier mail about how we are planning to drop the existing GApplication API and in part an announcement of our plans for the release of GLib 2.26. We came to fairly solid agreement during the Gtk meeting today. Here's a rough idea of what the GLib 2.26 release will look like: - we have a few small remaining issues to fix up: - some possible GDateTime changes - some probable GDBus changes - maybe something for GSettings too all of these changes have the potential of introducing API/ABI breaks, but they will likely be changes to relatively infrequently used APIs. - we will then create the glib-2-26 branch - we will remove GApplication from the branch, without replacement GApplication will remain on master for the time being - we will do a 2.25.x release from the glib-2-26 branch after GApplication has been removed - we will release 2.27.0 from master (with today's GApplication) - glib-2-26 branch will freeze for a short while followed by the release of 2.26.0 (with no GApplication) All of that will be done this month, in the order above. In the future, master (and some unspecified 2.27.x release) will see GApplication replaced with a new implementation thereof. We aim to release GLib 2.28.0 in December alongside Gtk 3.0. Applications tracking the 3.0 platform API should continue using GApplication until the replacement version arrives. Applications preparing for a release to go into GNOME 2.32 should consider one of the following options: - go back to libunique (which is GDBus-enabled these days) - copy-paste today's GApplication code into your application - something else We're very sorry for the disruption caused by removing API at such a late date in the cycle. The reason that we want to delay the introduction of the new GApplication is so that it can be properly reviewed in a non-rushed way -- precisely to prevent this sort of thing from happening again. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GApplication is going away
hi Andre, On Thu, 2010-09-02 at 17:15 +0200, Andre Klapper wrote: As hardcode freeze starts on September 13th, which / how many modules use GApplication and are affected by this? According to Seb (who did a quick grep) he knows of 4: totem, gnome-color-manager, eog, nautilus These apps are using GApplication without GtkApplication in their 2.31.x releases. Of course, there may be others that he missed -- the masses need access to fredp's big-hammer uber-grep! cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GApplication is going away
Hello GApplication is going to be removed from GLib soon. This was decided at GUADEC, but due to some external factors (vacation and other projects at work) the task of replacing it has proceeded slowly. Add to that that it's really a difficult task to get right. The short story is this: anyone who is using GApplication right now is going to have a bumpy ride in the near future. You may want to consider going back to libunique for this cycle. I am going to try hard to get the replacement in a state that it can be merged before the glib release (still planned for this month) but I may not succeed. In fact, I'm not sure that I want to succeed -- we're planning a glib release for December already and a few more months of review might produce a better product in the end. If we decided to remove GApplication support entirely then we will probably also remove the related classes that were added for it. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GApplication is going away
On Thu, 2010-09-02 at 15:47 +0100, Bastien Nocera wrote: Define this cycle. GNOME 2.32 as it will be released in September. I see a lot of details about it going away, but at no point do I see anything about _why_. It was discussed, implemented, then used by applications. Why the sudden change of heart? What did we do wrong in the process that we need to remove it and replace it now? The old API has some warts and significant limitations. In particular, we wanted to address these issues: - the weirdness of a constructor that sometimes exit()s your program - actions can't have parameters - GApplication as it stands is incapable of implementing the mockups we saw for the shell -- its support for putting actions on the application menu is extremely limited - the gedit as $EDITOR use case - the way that application lifecycle was defined was not sufficiently flexible - it didn't do some things that almost every app would want to have done for it - the missed chance to implement the use dbus to launch apps ability - etc. The decision to change the API was made by Colin, Emmanuele and myself. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings migration status
hi Vincent, On Fri, 2010-07-23 at 22:15 +0200, Vincent Untz wrote: Ryan, I'd like to relicense the module to LGPLv2.1+ instead of GPLv2+, since LGPL makes more sense now that we have a header. Are you happy with this? Not LGPL3+? :) Of course. No problem from me. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
hi On Wed, 2010-07-07 at 15:15 -0400, Shaun McCance wrote: But if you provide an API with GFile, I suppose people will expect to be able to hand it all sorts of GFiles, so storing the URI would be preferable. I think this is getting ridiculous. As it stands, I made recent modifications to GVariant, adding support for 'bytestring's (which are arrays of bytes 'ay') and 'bytestring arrays'. GVariant * g_settings_new_bytestring (const gchar *); const gchar * g_settings_get_bytestring (GVariant *); There's currently no GSettings convenience API for those, but I could add it if there are requests. I doubt I will ever add an API for GFile. Storing a filename into GSettings isn't done *that* often, and when it is done there are clearly very different ideas about the way it should be done. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
hi Matthias, On Thu, 2010-07-08 at 14:01 -0400, Matthias Clasen wrote: I think any attempts to relicense the bigger platform libraries like gtk or glib would end like the dbus relicensing efforts. We don't need anyone's permission to change the licence when the current licence includes or at your option, any later version. We can keep existing code like that and go 3 or later for new code, effectively making the combined codebase available under the terms 3 or later. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
hi Vincent, On Tue, 2010-07-06 at 09:26 +0200, Vincent Untz wrote: Do you feel okay with the idea of allowing proprietary apps to use our platform but not GPLv2 apps? In short, yes. Anybody who has an application that is GPLv2-only and has accepted enough contributions that it has become an unreasonable proposition to relicense has made a significant mistake. I don't want to punish them or anything, but they are the ones who picked a licence that prevents them from linking against just about anything. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
On Tue, 2010-07-06 at 13:12 +, j...@jsschmid.de wrote: Well, while I guess all my modules are LGPL/GPLv2+ would that still prevent me from linking against LGPLv3 things if I don't convert them to GPLv3? No. At the point that your application is used with a LGPLv3 library then it would conceptually be 'upgraded' to GPLv3 at that time (so that the GPLv2 clause preventing linking with LGPLv3 disappears). This doesn't mean that you have to change the licence of existing code -- you just keep it v2 or higher. Also, am I right that GPLv2+ means that I have GPLv2 in the COPYING but every file include the or (at your option) any later version clause? That's pretty much the view of most people, yes -- and certainly the common practice. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
hi Ted, On Tue, 2010-07-06 at 12:12 -0500, Ted Gould wrote: IANAL but I'm curious if a standard exception couldn't be drafted for LGPLv3 to allow linking with GPLv2 programs. Perhaps with work, that could be GNOME policy going forward? I like v3, but I think we need to be able to link to v2 programs. As I mentioned it my earlier emails, it's not a term in the LGPLv3 that prevents you from linking GPLv2 programs to it. It's the GPLv2 in the program code that states you can't link this against anything other than GPLv2 code. Nothing we could add to the library licence (other than dual-licensing under GPLv2) could fix this. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
(L)GPLv3
hi Everyone, I recently received an email from a company in our ecosystem asking me to relicense a smallish piece of code from GPLv3 to (L)GPLv2. I'm not really interested in inciting a flamewar on the topic or anything, but I'm wondering how people feel, in general about the licensing direction of the GNOME project. 1) Go freedom-warrior GPLv3 style and make the world a better place (potentially at the cost of our own relevance). 2) Be pragmatic GPLv2 style and make the world a better place (potentially at the cost of reduced end-user freedoms). One thing in particular I want to mention is that I asked about this topic a couple of years ago in relation to Gtk and was told at that time that we can't reasonably relicense Gtk 2.0 since the licence could almost be considered as being part of the API/ABI contract. We have 3.0 upon us now, so I guess we should make a choice one way or another. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
hi Vincent, On Mon, 2010-07-05 at 17:18 +0200, Vincent Untz wrote: It's worth thinking really hard before moving to LGPLv3 (at least; not sure about GPLv3): LGPLv3 is incompatible with GPLv2, according to the FSF; that's a major issue, and, IMHO, this doesn't go well with our philosophy of having our platform LGPL. Just a note: the LGPLv3 is incompatible with GPLv2 not because of the LGPLv3 but because of the GPLv2 (which is incompatible with almost everything). I'm not sure this should be counted as a point against LGPLv3, in general. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings migration status
On Fri, 2010-07-02 at 02:24 +0200, Vincent Untz wrote: Le mercredi 30 juin 2010, à 17:16 +0200, Vincent Untz a écrit : Here we go: http://cgit.freedesktop.org/~vuntz/gsettings-desktop-schemas/ Since packages will be depending on this, it's fair to ask: What's your stability guarantee, if any? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote: Finally, I'd like to suggest that gsettings-desktop-schemas install a header file containing #define's for each schema ID, schema, path and all the key names. I tried to discuss this on IRC because I believe it's a good idea. It's nice to have the compiler yell at you because you typed G_DESKTOP_BACKROUND instead of silently allowing org.gnome.desktop.backround. I was even considering one step farther, defining macros like: #define g_desktop_background_settings_new() - g_setting_new(...) That then leads to g_desktop_background_settings_get_style() macros and such. That might be going too far. Opinions? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote: This is a common error. Filenames need to be stored as ay and *NOT* s (since s is UTF-8). (I think this needs some enhancement in glib-compile-schemas to be able to still put a string in default.) I'm not sure I buy into your hardline stance on this one. I think it's not unreasonable to require that all filenames specified in the settings be in a valid encoding (whatever that encoding is) on their own filesystem (where in a valid encoding means converts correctly to and from unicode). In that case, utf8 is appropriate here. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
On Sat, 2010-07-03 at 13:37 +0200, Christian Persch wrote: Coincidentally, taking a look at all the summary and description strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping summary from gschema and only provide for the one description strings. I'm of a mixed mind on this. On one hand I'm sort of sick of coming up with 3 strings (of slightly increasing verbosity) to describe my GObject properties and the same sort of logic comes into play here. On the other hand, I notice that the typical format for git commit messages is actually extremely helpful. Just because we presently don't have any tools that take advantage of the summary (ie: by showing it somewhere that the full description is not showing) doesn't mean that it's pointless as a concept. One thing I'd like to point to: https://bugzilla.gnome.org/show_bug.cgi?id=620562 The intention is that everything that interacts with the description will do whitespace handling similar to the way Owen described in the bug. As implemented, in intltool for example: description This is a description. Woo. Multiple paragraphs. /description will end up as This is a description.\n\nWoo. Multiple paragraphs. which should end up being shown reasonably well in UIs. ((note the folding of the spaces between Woo. and Multiple)) So as a matter of style, I recommend writing summary and description like so: key summaryThis is a short summary (50 char rule, anyone?)/summary description Even short one-paragraph descriptions should be done like this. Wrap at 72, please. /description /key Since we're discussing style, I'll also mention that I'm a fan of vertical whitespace and that each key should probably have a newline between: ... /key key name='next' type='s' ... and schemas definitely. Maybe even two newlines there. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
dconf/GSettings namespace
11:00 shaunm btw, gnome as a project should probably decide on a policy w.r.t. /apps/yelp/ vs. /org/gnome/yelp/ for paths, for consistency ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GSettings migration status
Hi everyone, I recently edited the TwoPointThirtyone wiki page, removing these no-longer-true items from the high risk section: * GSettings/dconf: [[https://bugzilla.gnome.org/show_bug.cgi?id=600271| GVariant]] and GSettings merge completely '''blocks''' porting apps from gconf to [[http://live.gnome.org/GnomeGoals/GSettingsMigration| GSettings/dconf]]. * GSettings/dconf: User settings migration from gconf to GSettings/dconf unclear * GSettings/dconf: Missing gconf to [[http://live.gnome.org/GnomeGoals/GSettingsMigration| GSettings/dconf]] porting documentation for module maintainers GVariant is merged. GSettings is merged. dconf is making regular unstable-series releases along-side glib unstable releases (usually at almost exactly the same time). User settings migration is handled by the gsettings-data-convert(1) tool included in GConf. All that (and more) is documented in the GConf-to-GSettings migration documentation here: http://library.gnome.org/devel/gio/unstable/ch27.html One sore spot remaining is the lack of support for GVariant in language bindings -- but that need not affect simple uses of GSettings (since there are easily-bound convenience accessors for common types). According to http://live.gnome.org/TwoPointThirtyone the schedule as of June 28 says that we should have no fewer than 20 modules depending on GConf. http://live.gnome.org/GnomeGoals/GSettingsMigration indicates that we are quite behind on this goal. 55 modules in 'desktop' are marked as 'to do' or various states of in-progress (the vast majority are flatly 'to do'). To be clear: GVariant and GSettings are totally ready for application author consumption at this point -- at least from C, but also from other languages for uses that don't involve complicated types. You should be using dconf as your backend, which is also working in its role as a GSettings backend. Please port your modules! Thanks :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings migration status
hi Łukasz, On Wed, 2010-06-30 at 16:50 +0200, Łukasz Jernaś wrote: Also may I have one question? Do GSettings support internationalisation of the schema files like gconf did? There certainly are no intltool or m4 macros for that. The internationalisation of schema files in GSettings works slightly differently. It's mentioned in the porting guide that I linked to in my last email, but I'll provide a brief recap here: Translation is supported via gettext for the summary and description text fields in the schema file (ie: for display in the editor). Translation is also supported via gettext for the default values for keys. Support here is not entirely complete: there is remaining the issue of how to get the source strings for translation from the schema files and into the .po file template. I've written a patch for intltool but so far I've not had luck in getting it reviewed. That's here: https://bugs.launchpad.net/intltool/+bug/580526 Until that is merged, some people are doing their own solutions. gedit, for example is using _summary and _description to mark translations, and having the generic XML support in intltool work based on that. I don't encourage this approach, but it might be a suitable stop-gap. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings migration status
hi Bastien, On Wed, 2010-06-30 at 16:03 +0100, Bastien Nocera wrote: On Wed, 2010-06-30 at 10:43 -0400, Ryan Lortie wrote: http://live.gnome.org/GnomeGoals/GSettingsMigration This list seems pretty out of date... Thanks for noting this. everyone else: If you've already ported, please check the list and make sure you're in the green. :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using GSettings to set for all users
On Thu, 2010-06-03 at 10:30 -0400, Matthias Clasen wrote: On Thu, Jun 3, 2010 at 5:15 AM, Richard Hughes hughsi...@gmail.com wrote: The only remaining bits to port is the set default button which sets the per-user settings for all users. I'm unsure on how to port this in a GSettings/dconf world. This was being discussed between Ryan and David just yesterday. I'm sure Ryan can shed some light on the current plans. So first of all, a little bit of knowledge about how dconf and GSettings handle access to the system defaults database: Both systems support the concept of context to allow you to access something other than the user's normal database of settings. You can give a context of default to access the system default settings, for example. My current thinking for the write-to-defaults API is along these lines: GSettings exposes via is_writable() if a key is writable at this moment. In the case that the key may become writable in the future, given proper policy kit authentication then this function still returns FALSE. This allows preferences dialogs with unlock buttons to work properly and show the controls as insensitive while the dialog is locked. Probably I will add a new API: gboolean g_settings_canhasprivs(GSettings *); This will return TRUE if it's possible that the user might gain additional privileges from authenticating against PolicyKit. also: void g_settings_gimmeprivs(GSettings *); Will actually go and try to get those privs. This function is non-blocking -- all it does is send a request to PolicyKit to give the privs and return immediately. If and when the privs are successfully granted this will be reflected by the is_writable() property returning TRUE (and the application will be notified by the writability-changed signal). The same thing would happen if the privileges were requested by another application but affected this one. I like this approach. So that's the story for the unlock this dialog case, but I understand that there is another case for copy some setting to the defaults. Given the API that I plan to add for the previously mentioned case, you could almost do this for yourself: GSettings *prefs = g_settings_new (my.prefs); ... you are doing stuff with prefs, then the user clicks Make Default GSettings *def = g_settings_new_with_context (my.prefs, default); if (!g_settings_is_writable (def, key) g_settings_canhasprivs(def)) g_settings_gimmeprivs(); g_settings_set_value (def, key, g_settings_get_value (prefs, key)); this could work, but the problem is that gimmeprivs() won't block until you have the privs, so the set_value() call that you try to do too quickly will fail. What is needed is three new calls implementing a variant of gimmeprivs(). These three calls are of course the traditional _sync(), _async() and _finish() calls. In this case, the application will be able to detect when the authentication has succeeded (or failed) and go ahead with the write (or bail out) accordingly. Probably I will add these. Finally, it might be useful to have a helper to do all of this: gboolean g_settings_push (GSettings*settings, const gchar *key, const gchar *context, GError **error); that does all of the above internally. you would use it like this: g_settings_push (prefs, my-key, default, NULL); which would block your app, pop up a PolKit dialog and do its thing, returning TRUE on success. of course, there would be a _sync/_finish version too. So, 8 new functions: - canhasprivs - gimmeprivs - gimmeprivs_sync - gimmeprivs_async - gimmeprivs_finish - push - push_async - push_finish It's possible that i don't expose the _sync/_async/_finish versions of gimmeprivs because with _push() there is no real use case for having these. That's it. Bye :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
Hi Andre On Thu, 2010-01-21 at 14:24 +0100, Andre Klapper wrote: Currently the (challening) plan is to move completely from gconf to dconf in the 2.31 cycle. If I get it right (probably not, so feel free to correct me), this requires GDbus, GVariant and GSettings to be included in a glib release that should happen before GNOME 2.30 release in March. ... Is it still realistic to get these requirements in very soon as a preparation for the dconf move in 2.31? Or can we bury the dconf plan for GNOME 3 because there's not much progress in glib? Matthias and I are currently making good progress at getting GVariant reviewed. Some parts of it are already ready to go. I have no reason to believe that progress won't continue to be made and I'm currently of the mindset that it will make it in time for this cycle. David told me that he's currently busy with other day job work and is having trouble finding time for GDBus. That's a shame, because I wanted to use GDBus for dconf, but I can probably survive without it. I'll let David speak to the likelihood of its inclusion this cycle, though. GSettings obviously goes into glib *after* GVariant. It's a much smaller API compared to GVariant so I assume it will take far less time to review. Even so, at this point, I'm no longer sure that it will make it this time around. If it doesn't, it would be possible to roll a standalone GSettings tarball. That would likely preclude its use in GTK, for example, but would provide a good way to get apps ported before 3.0 (by which time I assume we'll have had another glib release that *will* include GSettings). Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Tue, 2009-10-13 at 13:57 +0200, Cosimo Cecchi wrote: I think having GSettings merged in GLib is the blocker here for starting ports of application to the new infrastructure, as it happened with GIO. So the question about whether we should migrate all at once or not (for 2.30) depends on how soon this will be available in released packages of GLib. We came up for a roadmap for this in Boston. We have no fixed times, but it's well in-progress. I'd guess a month or so. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Tue, 2009-10-13 at 19:22 -0400, Alex Launi wrote: How far away are mono/python bindings? Can I use raw dbus is there are not client helper libraries? You can use raw DBus to interact with the dconf database -- there is a DBus service included in the release. For GSettings, it's not really a DBussable API, so no. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Tue, 2009-10-13 at 13:34 +0200, Rodrigo Moya wrote: I think it makes sense to do the migration for all the apps at once. Also, the migration from gconf can be done directly from dconf, the first time it starts, or even it could be clever enough to synchronize changes from gconf every time it starts, to cover apps that migrate to dconf later. That would remove the apps' responsibility to do the migration, which would be a lot of code to have that in all applications. I personally think migration is less critical than a lot of people think. Here's why (for me at least): - I often reinstall my distro when the new release comes out - GConf (and GSettings) are not used to store important things like emails, bookmarks, contacts, cookies, passwords, ... - we're changing how our entire desktop looks/feels at the same time anyway, so the user will need to reconfigure that stuff (if they please) - it never takes me more than a few minutes of fiddling to get stuff back to how i like it in terms of settings. - doing some sort of automated migration encourages application developers to base their new settings schemas on the way they did things with GConf, rather than giving them a chance to have a 'clean break' and take full advantage of the new API (and also remove years of cruft). It certainly makes sense to provide some mechanism for applications using GConf to continue to function (note: this mechanism might be continue using GConf). For applications that get ported, though, *shrug*. I'm open to disagreement on this point :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Wed, 2009-10-14 at 14:00 +0200, Rodrigo Moya wrote: if dconf listens to changes in gconf, 3rd party apps would just need to link to glib/GSettings instead of libgconf, and their migration would be done automatically, right? dconf won't be made to listen to GConf. One alternative, though, is that a GSettings backend could be written that uses GConf (and its existing database) instead of dconf. This would allow applications to use the new API to access their existing settings in the existing database. dconf could be brought in later. I'm not sure this makes sense. You get (some of) the benefits of the nice new API but no performance improvements. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Wed, 2009-10-14 at 15:22 +0200, Matěj Cepl wrote: How is reading binary data faster than reading text data? (note, I don't fight for 570 tiny XML files at all). Using a binary file allows for the file to be mapped into the memory space of all client processes and read from directly in an efficient way, without locks. No roundtrips to get your config settings. You can't do that with text. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Thu, 2009-10-15 at 17:04 +0100, Michael Meeks wrote: So - at this point, I'd like to advertise FUSE gratuitously[1]; what with the ease of writing a FUSE filing-system, and the fact that we have a GVFS fuse mount already; it should be near-trivial to write a 'vi compatible' FUSE plugin there, that would show the configuration data as .ini style or fugly verbose gconf XML style or whatever ;-) At least, that's ok for the user XML, perhaps for the system, it's necessary to type some unbelievably verbose mount command-line to get the same effect - but hey; sysadmins are good at that right ? :-) That way we can have a sane data format, and the appearance of a text storage (and backup / restore / whatever) as well. Of course this should also take a clueful hacker all of - oh an hour or two to write ;-) Thanks for cutting to the core of the issue. This made me smile :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 07:35 -0700, Sandy Armstrong wrote: That doesn't fix anything; it just delays an identical migration. Ya. I'm not particularly in favour of doing this either. It's just theoretically possible :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, 2009-10-16 at 15:13 +, Colin Walters wrote: So the question isn't do we migrate or not, but how much do we migrate. Let pragmatism win the day :) -- Colin, who long ago wrote the first bits of those scripts, but if tasked with it this time would probably write them in something better than Perl Are you suggesting that you might want to be tasked again with something along these lines? :) Seriously, though -- help in this regard would be very much appreciated. I have a whole lot of stuff on my plate right now. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Tue, 2009-10-13 at 13:59 +0100, Michael Meeks wrote: In terms of migration, is there any reason why we cannot re-implement most of the gconf client library layered on top of dconf - with presumably some automagic schema conversion in place of the gconftool-2 --makefile-foo-install-baa ? There is a project to bridge dconf's backend to the libgconf API. It works for some *very* simple applications like gucharmap and the calculator. It was only made as a very simple proof of concept -- it will need a lot of work before it has wide usability. Help is massively appreciated here. Otherwise, it sounds like a good idea to me; though - can you confirm that the latest implementation does not scatter data we need to read on login / app launch across tens of tiny files, and that the authoritative data store is somewhat human readable ? :-) yes and yes (but probably you meant no). Data is in a single file, and humans can read it with the right tools. 'cat' is not one of those tools. :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
External dependency proposal: Vala
Hi I'd like to propose Vala as an official external dependency for GNOME 2.30. Some GNOME modules are already using Vala, but they are placing generated .c/.h files into version control to avoid the need for other contributors to have Vala installed. That's just ugly. :( Using Vala to compile a program introduces no additional run-time dependencies (Vala produces straight-up GLib-based C code). In its typical use, Vala also introduces no additional dependencies for building tarballs; distributions will have no additional burden placed on them. This is because 'make dist' typically includes the generated .c and .h files into the tarball, making 'valac' only required for building from git (or, of course, if you change .vala files). This is therefore a 'special' external dependency: it would only be required when building from git (or hacking on the code). It makes sense that we depend on the most recently available version at this point -- 0.7.7. Thanks for your consideration Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
Hello On Mon, 2009-10-12 at 17:30 +0200, Vincent Untz wrote: Le lundi 12 octobre 2009, à 11:27 -0400, Ryan Lortie a écrit : I'd like to propose the inclusion of dconf for GNOME 2.30 in the desktop release set. No. Pretty please? Ryan (live from Boston, where Vincent is currently being pummelled with fists :)) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Havoc Pennington wrote: This should be designed out; the schema install silliness in gconf was just not a good idea. The way I think dconf works (and the recommendation on http://projects.gnome.org/gconf/plans.html) is that schemas are basically part of the app, much as glade files are, though in this case they may be shared among apps. Anyway, hopefully installing schemas just dist_schemas_DATA = foo.schemas in Makefile.am and that's it. That is approximately correct. It's an open question if there will be a update-dconf-schema-cache program that you should run for optimum performance (compare: font cache, icon cache, etc). Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Alberto Ruiz wrote: Another question that I'm curious about is, how hard would it be to implement configuration snapshots? I think it would be quite useful to be able to make snapshots of the configuration for failsafe sessions or plain backup/rollbacks. Is this something that would require big changes on the current dconf's architecture/roadmap? The single backend database file is maintained in such a way that it's always completely safe to make a copy of it and have the latest contents of the database. It would also be possible to make a very slight modification to the code that causes every single write to the database to create a new tree (git style) and store all of the old copies of the tree. This is close to how it already works, except currently there's an optimisation that allows directories to be reused if they can be atomically updated (ie: only one word-sized value needs to be changed). Some mix could be possible: only write the totally new copies of the tree sometimes (every nth write, or once a day?). Did you have something more specific/better in mind? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Callum McKenzie wrote: Can current gconf settings be easily loaded into dconf? e.g. can someone launching into a gnome 3.0, dconf-based, system for the first time still have the same wallpaper settings as they did before? I'm assuming that a) the settings still make sense and b) that the application can provide a mapping between old and new settings. Yes, but currently this would have to be completely manual and would require the application to link to both dconf and GConf. This sucks. I guess a good solution would be to provide some easy-to-use framework by which applications could have migration scripts in python or something. That way the application itself doesn't need to do GConf, but the python script can if GConf is still installed. Ideas are definitely welcome in this direction. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Hi Havoc Pennington wrote: On Fri, Apr 3, 2009 at 8:27 AM, Vincent Untz vu...@gnome.org wrote: Schemas are nice, IMHO, so it'd be nice to have people (not necessarily you) explore this problem space ;-) s/nice/essential/ It is true that dconf has no schemas, and I don't want for it to have schemas. GSettings contains schemas. These schemas are considered to be part of the application (in the same sense that you would consider a GtkBuilder file, for example) and therefore do not appear in any way in the underlying settings database (that's dconf). Don't worry -- I'm not totally insane :) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Behdad Esfahbod wrote: But that still doesn't solve the problem of using the same key from two totally different applications, which is not quite uncommon these days. Say, font size, colors, default applications, etc. How does that work? Some library or service or core component would be responsible for installing the schema for these things. The schemas are name-spaced like 'org.gnome.whatever', and installed in a central location, so applications can easily use schemas provided by other libraries. I guess this violates the strict idea of 'part of the application' per se. What I meant by that is to say 'definitely not part of the database'. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Josselin Mouette wrote: Is it possible to have several layers of settings? Being able to override a GConf schema or provide a mandatory value at different levels is a popular feature among derived distributions and users with large parks. Yes. Of course. The concept of mandatory keys is actually being cribbed from the way that KDE does it more or less. ie: you have an ordering of databases. The user one being on one extreme end and the distro default or whatever being on the other. In between maybe you have site default host default, however, as you please. distro site host user default default default settings The setting is taken from the rightmost database that has the key set. However, if there is a 'mandatory' key set somewhere, then the leftmost takes precedence. This allows the 'site' admin to set mandatory keys that even the 'host' defaults cannot override, for example. Lockdown is essentially a list of patterns (stored in the same tree structure as the keys). Each pattern has one of the following forms: /one/specific/key/to/lock /path/to/lock/ with the following rule: if a lockdown list item exactly matches a key name then that key is locked down. If a lockdown list item ends in '/' and is a prefix of a key then that key is locked down. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
dconf
Hello, d-d-l. I'm a long-time listener, first time caller. Many of you are probably aware of two things about me: 0) I'm that guy who is working on that weird cloud of dbus-ish stuff involving GVariant and dconf and GSettings, etc. 1) A few months ago I started working for Codethink This email is a statement of status, of direction and of intention. A lot of people have been asking what is going on, so this is an update. It's not really an attempt to start a discussion, but if that happens, then I'm happy to answer any questions. :) first: GVariant. GVariant has been in an essentially-complete state for quite a long time now. I recently rolled a tarball of it and announced it to the announcement list. It is available here: http://www.gnome.org/~ryanl/src/ GVariant is currently hosted as a totally separate project in a git repository on git.desrt.ca: https://desrt.ca/gitweb/?p=gvariant The intention is that it be merged with glib (into the base libglib library). Now that glib is in git I will be making a branch and performing the merge. This should be complete within a couple of days. I will then propose it for inclusion in the next release of glib. GVariant is reasonably well-tested and is being used in a number of other projects that I'm working on. Of course, it surely has some bugs hiding in it. I believe that the API is more or less stable at this point, but I welcome constructive criticism and feedback. There are plans to add more functionality (such as the ability to print/parse pythonic text strings). You can read more details about how GVariant works in the release announcement here: http://mail.gnome.org/archives/gnome-announce-list/2009-March/msg00103.html second: dconf and GSettings For some time I've been talking about these pair of projects as a proposed replacement for GConf. The reasons that we might want to replace GConf are well understood and widely documented and I won't talk about them here. A while ago there was even a reasonably-working implementation of dconf. This was based on a different value system (ie: before I started writing the more-generally-useful GVariant). I stopped working on dconf when I shifted focus to GVariant and when school started consuming a lot of my time. Recently, sponsored by Codethink (now my employer), I have resumed work on dconf. This has come in the form of a total rewrite (and simplification) based on GVariant. This rewrite (along with another project, GBus) is doing a lot to convince me of the stability and usability of GVariant. Briefly, dconf is a simple untyped hierarchy of keys. It is used as the backend storage for GSettings which is a very strictly typed high-level settings system intended to be used by GNOME applications. The API is much nicer than GConf. dconf is very efficient. The majority case in accessing settings is reading (think about desktop login: 1000s of settings read, none written). Reading in dconf is done directly from a memory-mapped file containing the settings in an efficient tree format and doesn't require an extra service to be running. The service is only needed for writes. Communication occurs over DBus, of course. :) The rewrite of dconf is currently extremely unstable and incomplete, but it is currently being hacked on (along with GSettings) full-time. Progress is good. In a week or two I will have something to show for this and I intend to have a stable release to go along with 2.28. Stay tuned. :) Ideally, I'd like to see GNOME using GSettings for 3.0. Rob Taylor (my boss) has indicated that I will definitely be able to spend time addressing issues that may arise with dconf and GSettings in the lead-up to 3.0. So that's it. That's what I'm up to. Have a good day :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Ross Burton wrote: Is a GConf compatibility layer possible, or are there too many semantic differences? The type system of dbus (and therefore GVariant and dconf) is a superset of the type system of GConf -- any value that can be stored in GConf can be stored in dconf. Due to the simple nature of GConfValue, making this bridge would be trivial. The namespace is also essentially the same: a hierarchy of keys with no particular restrictions. It would be very easy to use dconf with the GConf API with a very thin client-side compatibility layer. One thing that dconf is missing that GConf gives you, however, is schemas. You could get this by using dconf as a backend from the gconf daemon. It seems like this is sort of missing the point, though. It might be possible to come up with a temporary hack to deal with schemas. Something like having the compatibility layer insert responses from the schema files where appropriate and dealing with dynamic application-installed schema entries (think: panel) with extra keys in the dconf database. Like if you add a schema for some foo key maybe you could get a .foo.schema extra entry that contains all of the information required... This is honestly a problem space that I haven't spent too much time exploring, but there are certainly possibilities here. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Wed, 2006-18-01 at 23:14 +0800, Davyd Madeley wrote: pragmatism, before we commit to path that none of our vendors or any other desktops want to share. In all fairness, I know that at least Ubuntu Dapper is using g-p-m. No idea about Edgy. Cheers. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Wed, 2006-18-01 at 10:32 -0500, William Jon McCann wrote: How is a system daemon more secure than a user session daemon? A system daemon runs as root (or some other 'special' user) and can be given special abilities without giving them to the user. A system daemon is also immune to user tampering. g-p-m doesn't require any additional privileges. HAL is doing most of the work. This is exactly the problem. In order for g-p-m to do its stuff we have to add to HAL the ability for any user to say suspend the system now (since g-p-m needs to do this and it's just running as a normal user). If any user can say suspend now then I can be logged in as a background user and play nasty tricks on the console user. HAL currently has no mechanism for making a distinction between background users and the user that currently 'controls' the machine. When you add additional privileges to HAL you also increase the chance that someone is able to exploit a security hole in HAL itself. Martin Pitt, for example, has ranted about this at length because it's not a good idea (and even found some security problems to validate his concerns). Can you please provide some reasons why g-p-m is very Gnome-centric? It uses the system tray standard and provides a DBUS interface that any application can use. This DBUS interface could be standardized with freedesktop.org once we figure out what works for us. Yes, it has GNOME in its name and uses Gconf and GTK+. You provided my reasons for me. You could say that all Gnome applications are sufficiently cross-desktop because they connect to the X server through the standard protocol. They do not, however, have the Qt look and feel so they stick out like a sore thumb. KDE users are also not interested in having Gconf and GTK+ installed. For this reason, you can't honestly expect KDE to use g-p-m. Adding an application to the Desktop release doesn't make too many guarantees about its API availability. We talked about this in #gnome-hackers a bit before I wrote my mail listing my concerns. Jeff (I think!) brought up the example of esd and said that it's very hard to remove something once it's included. Once apps start to depend on it it -does- become difficult to remove. Another issue is that right now some distributions are using power management systems that are vastly different from how g-p-m works. If we include g-p-m we are encouraging people to depend on it and making life difficult for those distributions that do not want to ship it. I think it is the interface that counts. As long as the DBUS interface is sane then you should be able to plug whatever you want in to provide that service. g-p-m is a session daemon. It uses the D-BUS session bus and does not listen on the system bus. Most distributions have power management systems that run at the system level. It's difficult for things not running as part of the user's session to connect to the user's session bus (in fact, the default policy is to reject non-user connections - even those from root). You also have to somehow 'snoop' the bus location out of the environment of another process. You also assume they use D-BUS for their systems at all (or want to). The question comes down to: is there sufficient reason not to use the best solution we have in favor of one that hasn't been spec'd, reviewed, or developed in the community or at all? For what it's worth, Davyd Madeley spec'd this imaginary system out a long time ago. Of course, nobody has coded on it. A lot of your argument has been along the lines of including g-p-m now doesn't limit the choice of distributors or our future choices. Based on what I've been told, I think that in a very real way it limits both of these things. This makes sense -- if Gnome applications start to use g-p-m then it becomes hard to remove (both for distributions and for us in the future). This is really the crux of the argument and honestly I'm not in a position to really comment on if it's true or not since I've not been around on the Gnome scene for very long. Cheers. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
On Wed, 2006-18-01 at 17:16 +0100, Mark Rosenstand wrote: Without actually using the stuff, I think this sounds pretty much like what HAL does (and g-p-m uses.) Definitely not. HAL is incapable of acting on its own (ie: making policy decisions). This is exactly the part that needs to be pushed down into being a system daemon. Cheers signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New modules in 2.14
Hello. On Mon, 2006-16-01 at 19:13 -0700, Elijah Newren wrote: Ok, here's what I'm guessing is the rough module consensus after having re-read or skimmed a ton of emails: In: - gnome-power-manager I don't think it's appropriate to include gnome-power-manager at this point. There are a number of reasons for this. First, I don't think that g-p-m itself and the technologies that it depend on are mature enough that we should standardise on any particular solution yet. g-p-m is one way of cracking the power management egg and I think there are a lot of better possibilities. Certainly, at the current time, it appears to be the best offering. However, after discussing this at length at Ubuntu Below Zero, I believe, that we'd be better served by a system with the two following key properties: 1. Based on system daemon. This would make the system more secure as a normal user process wouldn't be given the ability to 'suspend now' as g-p-m (and any system which makes policy decisions at user privilege) currently requires we provide it with. This (and other privileges that g-p-m need to be provided with) have serious security implications. Having a system daemon would also mean that the policy system runs when the user is not logged in without resorting to hacks like gdm invoking a private copy of g-p-m. 2. More platform-neutral approach. The technologies on which g-p-m is based have seen wide acceptance from other desktops. We should try and create a power management system that has the same acceptance. g-p-m is very Gnome-centric. With a faceless system daemon doing all the real hard work we could have multiple configuration front-ends (Gnome, Qt, etc). Of course, this wonderful system does not exist. Again, gnome-power-manager is the best offering we have at this time. This does not mean, however, that we should put include it in Gnome proper. Once things are in, they have a tendency to stay around forever. Applications form hard dependencies on them. If we are going to standardise on a solution it should be the best possible solution -- not just the best thing that we have right now. If we aren't sure that the thing we have now is the best possible solution then it's appropriate to wait. Another issue is that right now some distributions are using power management systems that are vastly different from how g-p-m works. If we include g-p-m we are encouraging people to depend on it and making life difficult for those distributions that do not want to ship it. Essentially, I think that (a) we should not rush into this and (b) we should, at the current time, leave this up to distributions to decide. We do them no harm by not including it since they can include it anyway. I'm not subscribed to the list so please cc: me on any replies. Cheers. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Blocker bugs for GNOME 2.14
Hello. Over the past few days I've been working with a few people on the release team and bugsquad to increase the quality of the blockers list for GNOME 2.14. We've moved most of the less severe bugs off of this list leaving bugs that are real candidates to block the release. I've compiled a list of these bugs with summary information. I intend to compile such a list semi-regularly and send it to d-d-l to ensure that these bugs are getting the attention that they need (so that they don't creep up on us at the end and delay the release). An open bug is considered a blocker if it has its Gnome target: field set. As such, this field should only ever be used on bugs which might be worth holding up the release for (usually as decided by a senior bugsquad member or the release team themselves). On the other hand, if you have a bug that you think might be worth holding up the release for, please get in contact with the bugsquad or the release team and make sure they know about it. If you have some spare time or are looking for something to do then please take a look at the bugs on this list. Given many eyes the bugs here should become shallow and disappear rapidly. Here is the list: #122688: modal dialog popup + drag in progress = mouse freeze If the user is dragging an icon or rubberbanding in nautilus at the time that a modal window pops up then the entire desktop freezes. The only way to unfreeze the desktop is to kill off nautilus. mclasen says that GTK has a mechanism to recognise and avoid this situation but nautilus doesn't use it. Huge user impact and no reason it can't be fixed. #157941: Help browser content is inaccessible [REGRESSION] The screenreading software can't see the text in the help browser. You can make a reasonable argument that if the help isn't accessible then the desktop itself is not accessible. #310153: crashes on attempt to use in libgnomeui Somehow an invalid URI is getting into the bookmarks file and causing libgnomeui to crash on reading it. At the very least we can work around this problem very easily and hopefully it will be easy to fix properly. #317312: [CAN-2005-0023] gnome-pty-helper writes arbitrary utmp records We have an open security advisory and nobody has even touched it. Even though the results of this attack are minimal (faked log files) this needs to be looked into and fixed ASAP. #319308: Accessibility: Folder name does not exist in canvas Evolution accessibility bug. The contacts folders are not as accessible as they could be. Has a patch so it should be a quick fix. #319549: gnome.ui.icon_lookup() segfaults on weird filenames This bug causes segfaults when rendering icons for odd filenames. I've tried to trigger this by creating some of these weird filenames and wandering into a directory containing them with nautilus. In my tests, this does *not* trigger the crash. #320217: recoursive copy replace fails and all files are deleted 'gnomevfs-copy foo foo' erases foo. This is a disaster but it is being actively looked into. #325737: Nautilus crashes after adding files to burn area Nautilus crashes when you drag files into the burn folder on Solaris. This is obviously a big problem for Solaris users and a fix is attached. #325762: Alarm notification icon is always visible The Evolution alarm notification daemon places an icon on the notification area that never goes away reducing the usability of the notification area. Evolution needs to be modified to only display this icon if actively notifying of a specific event. #325861: gnome_vfs_async_xfer reports wrong GnomeVFSXferProgressInfo in the callback for http method I don't really understand this problem but it affects end-user applications in a visible way and is well on its way to being fixed. #325988: text files listed as application/octet-stream on non local system This is a fairly significant problem for people who are browsing files on a SMB (or some other) remote filesystem. Many thanks for reading this far. Good luck :) Cheers. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
