Re: File Transfers in Shell Panel
Le dimanche 22 janvier 2012 à 12:56 -0600, Jason Simanek a écrit : If the new transfers design is this: https://live.gnome.org/GnomeOS/Design/Whiteboards/Transfers that seems to explicitly exclude the use of a file manager. Which is nice and all, but the reality is that file managers are still very useful and necessary tools. My little mockup addresses a problem that exists with how Nautilus currently presents file transfer information. See also https://live.gnome.org/Design/Apps/Transfers It says the goals include File copy/move operations within the system. There's a screenshot of the current Nautilus file copy dialog in the Relevant art section there. Should I be talking directly to the Nautilus developers? Are the Gnome developers more focused on this, er, future with no file manager desktop model? I think you'd rather discuss this with designers on #gnome-design first. I don't think integrating with Nautilus is really contrary to the goals of the Transfers idea. It's just that Nautilus isn't the main objective in the designers' mind: the design will be driven by other concerns, and Nautilus will have to fit into that. About the mockup, I think the idea is definitely good, but I suspect designers will tell you to put this as an icon in the messaging bar at the bottom, which is designed for this kind of temporary task, rather than in the top panel. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
David Zeuthen wrote: @David: could you confirm this? And do you have any ETA for a udisks2 tarball? There is one at http://udisks.freedesktop.org/releases/ http://www.freedesktop.org/wiki/Software/udisks still points to http://hal.freedesktop.org/releases/, could you update that page? Thanks! Fred ___ 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
Le 20/01/2012 23:08, Lennart Poettering a écrit : You know, your complaining would be a bit more believable if Google wouldn't find this for us: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit So, the problem set has been known for a while, a number of Canonical desktop team members have been subscribed to that page, the documentation for the interfaces is all available, some code has already been written by Canonical. So I really don't see what went wrong here, except maybe that Canonical's internal communication didn't work out so well? Hi, Why do you guys insist in making that a Canonical,Ubuntu issue? I've replied previously that it's not an issue for us and I will tell it again: the change is not really a surprise and not an issue for Ubuntu since we are staying on GNOME 3.2 this cycle and we will have solutions in place before we upgrade next cycle. That said I wrote the emails on that list as a GNOME contributor (would it help to not focus on Ubuntu if I was written using my debian email rather than the Ubuntu one?) because I think GNOME as a project could do better. This example might also not be problematic but who knows about other changes that will happen in the next years, it would still help if GNOME was settling on an improved communication for the platform requirements. Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On 01/22/2012 06:45 AM, Zeeshan Ali (Khattak) wrote: While it is true that ideal scenerio would be for Vala to simply use gir/typelib but gir is missing features supported by vala and its bindings for many years now. Nested namespace is one of them. Another example is default values for parameters. Nested namespaces would be nice for other bindings as well. There is a bug for it. https://bugzilla.gnome.org/show_bug.cgi?id=576327 Default values are asked for by pygobject guys as well. There is a bug for it as well: https://bugzilla.gnome.org/show_bug.cgi?id=558620 Both just need some more thought and a patch. ___ 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 Mon, Jan 23, 2012 at 10:14:32AM +0100, Sebastien Bacher wrote: Why do you guys insist in making that a Canonical,Ubuntu issue? Only that distribution is affected by the functionality change right (relying on API that atm is only provided by systemd)? All the other distributions have systemd, so they didn't need to be made aware (though we should've). Am I missing something? I guess Debian? Didn't see anyone raise that up to now. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
On Sat, Jan 21, 2012 at 04:13:58PM -0500, David Zeuthen wrote: Not that I know of, no. But I expect that they will make use of their abstraction layer thingies. I assume they're aware that it is changing? -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Fwd: systemd as external dependency]
The email has been sent on the gnome desktop-devel-list today: http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html Not sure if people there read GNOME list but since the topic is interesting for the distribution I figured I would just share the info Cheers, Sebastien Bacher ---BeginMessage--- Heya, I'd like to propose systemd (GPL2+, http://www.freedesktop.org/wiki/Software/systemd) as blessed external dependency for GNOME 3.2. Currently the interfacing between GNOME and systemd is minimal. Bastien has been implementing a UI for changing the host name via a configuration UI in the control center which uses a tiny mechanism daemon included in systemd as backend. GLib already exposes g_get_user_runtime_dir() which is a frontend for XDG_RUNTIME_DIR whose only implementation I know right now is in systemd. In the future I expect more interfacing with GNOME however, and I'd thus like to see the discussion regarding acceptance as blessed dependency started early. In the long run I expect the following additional interfaces used by GNOME or one of its components: - I am working on two more mechanisms generalizing control of the system locale and system clock/timezone for use in the control center and by other UIs. - gdm will interface with the new CK-replacing code I am working on. http://lwn.net/Articles/441328/ - gnome-session will be augmented by a per-user systemd instace, leveraging the benefits that systemd gives you for system startup also for session startup. - Later on I hope that we can use per-application cgroups to create reliable mapping between desktop files and processes. (i.e. place each app in a cgroup and name it after the .desktop file), integrated into the systemd cgroup hierarchy, so that this can be used for g-s and other UIs to relate desktop files to processes. And I expect a couple of more interfacing points, however things get more and more into vaporware areas with those. With these interfaces I hope to bring the speed improvements we are providing for the system also to the session. Also it brings a ton of new user-visible features with it, like automatic multiseat, or the ability to change the system locale. systemd is Linux-only. That means if we still care for those non-Linux platforms replacements have to be written. In case of the timezone/time/locale/hostname mechanisms this should be relatively easy as we kept the D-Bus interface very much independent from systemd, and they are easy to reimplement. Also, just leaving out support for this on those archs should be workable too. The hostname interface is documented in a lot of detail here: http://www.freedesktop.org/wiki/Software/systemd/hostnamed -- we plan to offer similar documentation for the other mechanisms. Not all Linux distributions currently use systemd. The majority of the big and small distributions however has switched by now or is planning to switch in their next versions, or at least provides packages in the distribution. The one exception is Ubuntu. While I have hopes this will be resolved next year, there is no official statement from Ubuntu on this. Distributions not interested in systemd which however are looking into having some of its features could probably compile systemd but remove all but the mechanism daemons. Integration between gnome-session and systemd I expect to be very lose, and can probably easily be #ifdef'ed out for conservative distros or other OSes. The closest integration I expect in gdm. Ideally I'd like to rip out the current CK support completely and replace it entirely by the more low-level systemd specific code. However, that I can only do if the outcome of this discussion is clear. systemd itself has very minimal external dependencies. You need Linux, udev, D-Bus, and that's it. (there are a couple of additional optional deps however). The first version i'd like to see blessed is systemd 26. Comments? Lennart -- Lennart Poettering - Red Hat, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ---End Message--- -- ubuntu-platform mailing list ubuntu-platf...@lists.canonical.com https://lists.canonical.com/mailman/listinfo/ubuntu-platform ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Sat, 2012-01-21 at 06:58 +0200, Zeeshan Ali (Khattak) wrote: On Fri, Jan 20, 2012 at 2:30 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On 01/19/2012 10:32 PM, Colin Walters wrote: But others (folks at least) fail to compile with 0.15. This question might seem a little naive, but could someone highlight me why the vala compiler can't stay backward compatible from release to release? Indeed. Until vala grows up a little more, its increasing use in the desktop is a growing problem. Being a maintainer of 2 vala projects in GNOME, I can tell you that valac itself is pretty stable these days and it gets more and more stable all the time. The issue is the bindings usually. There are way I'm in charge of maintaining the bindings distributed with Vala, and I completely agree. Historically, most of the backwards incompatible breaks in bindings come from fixing things that kind of worked but were really sub-optimal (for instance, using string + size_t arguments for binary data instead of a single uint8[]). We have been working hard this cycle to switch to generating our bindings from GIR, which is fixing a *lot* of problems but some B.C. breaks are pretty much unavoidable. Future cycles should be much less tumultuous. too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. Wow, this post was very well timed. I've been working on that lately (since it was brought up on vala-list in the context of Clutter about a week ago) and I just pushed a patch to Vala which provides autotools integration similar to what GObject introspection offers. If anyone out there would like to distribute Vala bindings with their project instead of with Vala please let us know (preferably either through Vala mailing list or #vala on irc.gnome.org). I'm willing to help integrate Vala bindings into your build system and assist with maintenance. -Evan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[gnome-online-accounts] Flickr backend
Hi,
I'd like to let you know that I've started work on Flickr support for
GOA [1] (based on the Twitter backend).
One thing that slightly bothers me is that I probably have to request
the full permission scope ('perms=delete' [2]), instead of giving users
the option of giving GNOME partial access.
How does this work with OAuth2 in GOA? I can see it may be possible to
request full scope at the authorization endpoint, and partial scope
(based on switches in the UI) at the token endpoint to obtain a scoped
access token. This wouldn't work with OAuth1 though.
Regards,
- Willem
[1] https://github.com/wvengen/gnome-online-accounts
[2] http://www.flickr.com/services/api/auth.oauth.html#authorization
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Fwd: systemd as external dependency]
On Wed, May 18, 2011 at 06:19:44PM +0200, Sebastien Bacher wrote: The email has been sent on the gnome desktop-devel-list today: http://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html Oops. Didn't notice it was in the queue for that long. I didn't read the contents before approving. -- Regards, Olav ___ 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
2012/1/23 Olav Vitters o...@vitters.nl: On Mon, Jan 23, 2012 at 10:14:32AM +0100, Sebastien Bacher wrote: Why do you guys insist in making that a Canonical,Ubuntu issue? Only that distribution is affected by the functionality change right (relying on API that atm is only provided by systemd)? All the other distributions have systemd, so they didn't need to be made aware (though we should've). Am I missing something? I guess Debian? Didn't see anyone raise that up to now. Or maybe people aren't very happy of the tone of the discussion and don't want to be dragged into it (and that is why I didn't reply when openSUSE was mentioned). This change is also problematic for people who might not be using the last version of their distribution or who have issue with systemd which aren't fixed yet and are forced to use sysvinit. -- Frederic Crozat ___ 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 vie, 2012-01-20 at 22:56 +0100, Lennart Poettering wrote: On Fri, 20.01.12 08:47, Ryan Lortie (de...@desrt.ca) wrote: 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. Note that The Ubuntu folks have been well aware of all of this coming. How I know that? Because at their last UDS they scheduled a session about rewriting those mechanisms for Ubuntu, and they even have a project page up on launchpad: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-systemd-packagekit as I already said, this is all implemented, except for the datetime interface, which wasn't used in GNOME when I implemented the other systemd services. ___ 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 Mon, 2012-01-23 at 10:54 +0100, Frederic Crozat wrote: 2012/1/23 Olav Vitters o...@vitters.nl: On Mon, Jan 23, 2012 at 10:14:32AM +0100, Sebastien Bacher wrote: Why do you guys insist in making that a Canonical,Ubuntu issue? Only that distribution is affected by the functionality change right (relying on API that atm is only provided by systemd)? All the other distributions have systemd, so they didn't need to be made aware (though we should've). Am I missing something? I guess Debian? Didn't see anyone raise that up to now. Or maybe people aren't very happy of the tone of the discussion and don't want to be dragged into it (and that is why I didn't reply when openSUSE was mentioned). This change is also problematic for people who might not be using the last version of their distribution or who have issue with systemd which aren't fixed yet and are forced to use sysvinit. Requires: systemd-services And have a Provides: systemd-services in the systemd RPM. The problem isn't exactly insurmontable. ___ 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 Mon, Jan 23, 2012 at 10:54:30AM +0100, Frederic Crozat wrote: 2012/1/23 Olav Vitters o...@vitters.nl: On Mon, Jan 23, 2012 at 10:14:32AM +0100, Sebastien Bacher wrote: Why do you guys insist in making that a Canonical,Ubuntu issue? Only that distribution is affected by the functionality change right (relying on API that atm is only provided by systemd)? All the other distributions have systemd, so they didn't need to be made aware (though we should've). Am I missing something? I guess Debian? Didn't see anyone raise that up to now. Or maybe people aren't very happy of the tone of the discussion and don't want to be dragged into it (and that is why I didn't reply when openSUSE was mentioned). Just let me know privately. I was focussing on improving release-team bits and I don't like to think (or speak) about tone if I have participated in the discussion. Not good to hear though, I need to understand the openSUSE viewpoint as well. This change is also problematic for people who might not be using the last version of their distribution or who have issue with systemd which aren't fixed yet and are forced to use sysvinit. Mageia 2 will have an optional sysvinit (default is systemd). I don't really see the problem for Mageia. In case of sysvinit, some minor stuff might not work or might not work (perhaps daemons would still work under sysvinit, don't care). For me, if you choose the fallback, don't expect things to work perfectly. Is this the openSUSE viewpoint? -- Regards, Olav ___ 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
Bastien Nocera wrote: And have a Provides: systemd-services in the systemd RPM. The problem isn't exactly insurmontable. Of course it's not insurmontable, but this thread came to be more about proper communication than technical solutions. So far we had 1) the update of the portability matrix, and 2) the acknowledgment a mail should have been sent to distributor-list@; I believe this is satisfactory. Ideally we'd also have earlier notifications, and a list of D-Bus API we depend on (like we had the external dependencies page), but that's more work, and not always feasible. Fred ___ 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, Le lundi 23 janvier 2012, à 13:02 +0100, Olav Vitters a écrit : On Mon, Jan 23, 2012 at 10:54:30AM +0100, Frederic Crozat wrote: 2012/1/23 Olav Vitters o...@vitters.nl: On Mon, Jan 23, 2012 at 10:14:32AM +0100, Sebastien Bacher wrote: Why do you guys insist in making that a Canonical,Ubuntu issue? Only that distribution is affected by the functionality change right (relying on API that atm is only provided by systemd)? All the other distributions have systemd, so they didn't need to be made aware (though we should've). Am I missing something? I guess Debian? Didn't see anyone raise that up to now. Or maybe people aren't very happy of the tone of the discussion and don't want to be dragged into it (and that is why I didn't reply when openSUSE was mentioned). For reference, I feel the same. I originally wanted to reply to the thread, but got distracted. When I came back to it, it was full of negative comments, bad feelings, etc. And I'm tired of the bad atmosphere on d-d-l. FWIW, here's what I wanted to say at first: in openSUSE, we're not affected as downstream, but as this mechanism could be considered as a public API, I'd have preferred to learn about the change a bit earlier to check it's all fine for us (and yes, I understand it's not always possible). With my upstream hat: I think we could keep this for one cycle and mention somewhere in NEWS that it's deprecated and will disappear in the next cycle. It doesn't cost us much to do that, and it's nice to our downstreams. [...] This change is also problematic for people who might not be using the last version of their distribution or who have issue with systemd which aren't fixed yet and are forced to use sysvinit. Mageia 2 will have an optional sysvinit (default is systemd). I don't really see the problem for Mageia. In case of sysvinit, some minor stuff might not work or might not work (perhaps daemons would still work under sysvinit, don't care). For me, if you choose the fallback, don't expect things to work perfectly. Is this the openSUSE viewpoint? This is similar to what we're doing for openSUSE. Still, I think it's better to nicely handle the case where systemd is not what is being used. It enables a smoother migration. Another systemd-related change was already mentioned earlier: the new --enable-systemd configure flag that removes ConsoleKit support when it's used. It cannot really be used for openSUSE (and Mageia, I'd say). I want to thank Matthias for his extra effort of reworking the gnome-session patch after my concern, though. Cheers, Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
On Mon, Jan 23, 2012 at 4:50 AM, Olav Vitters o...@vitters.nl wrote: On Sat, Jan 21, 2012 at 04:13:58PM -0500, David Zeuthen wrote: Not that I know of, no. But I expect that they will make use of their abstraction layer thingies. I assume they're aware that it is changing? I think so. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
On Mon, Jan 23, 2012 at 4:14 AM, Frederic Peters fpet...@gnome.org wrote: David Zeuthen wrote: @David: could you confirm this? And do you have any ETA for a udisks2 tarball? There is one at http://udisks.freedesktop.org/releases/ http://www.freedesktop.org/wiki/Software/udisks still points to http://hal.freedesktop.org/releases/, could you update that page? Done, thanks. David ___ 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 Mon, Jan 23, 2012 at 03:03:36PM +0100, Vincent Untz wrote: Another systemd-related change was already mentioned earlier: the new --enable-systemd configure flag that removes ConsoleKit support when it's used. It cannot really be used for openSUSE (and Mageia, I'd say). I want to thank Matthias for his extra effort of reworking the gnome-session patch after my concern, though. I have notified Mageia of --enable-systemd a while ago, but didn't discuss it yet. I know Mageia will be full systemd only in version 3, but not sure regarding version 2. I haven't made my mind up regarding version 2, perhaps easier to just rely on ConsoleKit in v2, then --enable-systemd in version 3. Leaning to not think and fully let the other people at Mageia investigate. Note: Only have been doing packaging since Aug 2011, I don't consider myself knowledgeable. I'll present to the development list and see what they say. The Mageia GNOME team is really small though; once you do something, you're basically considered in charge :P (somewhat scary) -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, Jan 23, 2012 at 9:53 AM, Emmanuele Bassi eba...@gmail.com wrote: hi Zeeshan; Hi Emmanuele, On 23 January 2012 02:14, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau t...@gnome.org wrote: 2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org: There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. I don't agree with this assessment. you're just deferring the issue to every library under the sun, and this is very much problematic in a variety of reasons: - as a maintainer, now I'd have to care not only about introspection, but also about a vapi file - which is another redundant format that expresses the library's API; so the first thing I'd look at would be generating the latter in terms of the former, which introduces a build dependency (albeit optional) on Vala. so it's my library that now has to deal with the compiler and generator bugs. yeah, right: not going to happen. What I was proposing wasn't so different from what you are saying here. Vala bindings should still be generated out of gir bindings but since gir doesn't support some of the essential features that vala apps have been depending on for some time now, we'll need to have *some* vala-specific metadata, at least until gir supports those features. If having any vala-specific metadata in a few libraries isn't acceptable to maintainers, yeah we should first separate out the bindings into another package and then push the bindings that are purely generated from gir to their respective libraries. BTW just for the record, It should be noted that gir is the cause of the problem here not vala. - I have used Vala, but I'm not an expert on figuring out its quirks, nor am I using it for my day to day work; this means that I'll have to rely on Vala developers to update the Vala bindings. this means that Vala developers and users will now need to go through various bugzilla products and git repositories to fix the Vala bindings in each and every project that ships one. They'll have to go through the same procedures as python and javascript users so I don't think this is an issue. Actually this will give good motivation to vala developers to fix/improve your gir annotations for you. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
On Sat, 2012-01-21 at 13:33 -0500, David Zeuthen wrote: And gvfs will continue to support the existing gdu and hal backends. Ideally we would like to deprecate the hal backend but I learned other Unix systems are still using it. Looking at the recently discussed https://live.gnome.org/PortabilityMatrix the FreeBSD platform is one example. Any idea if this could change soon? David, any plans for extending udisk2 support to non-udev/non-linux systems? -- Tomas Bzatek tbza...@redhat.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]
Hey, On Mon, Jan 23, 2012 at 10:31 AM, Tomas Bzatek tbza...@redhat.com wrote: David, any plans for extending udisk2 support to non-udev/non-linux systems? No plans. In fact, I would recommend that non-Linux simply writers their own GVfs volume monitors instead if the 'unix' backend isn't good enough - much easier for everyone. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, Jan 23, 2012 at 10:12 AM, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: BTW just for the record, It should be noted that gir is the cause of the problem here not vala. I think this argument doesn't hold any water, tbh. gir was invented to expose the bindable features of C apis to higher level languages, not to force (somewhat questionable) constructs like nested namespaces back into the descriptions of C apis which really don't have these concepts. Anyway, we don't need to assign blame here; I think we all agree that requiring two descriptions of each bindable api is problematic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
Any objections to this patch for the moduleset? From 93b05f15f3cd218dab7517e798ca3daf2e05bfc1 Mon Sep 17 00:00:00 2001 From: Colin Walters walt...@verbum.org Date: Mon, 23 Jan 2012 16:44:55 -0500 Subject: [PATCH] 3.4: Switch to building from git for vala, libgee, and folks jhbuild should always be building from actual source code (i.e. git) for modules we expect GNOMErs to possibly hack on. This set definitely includes vala and folks, but probably not e.g. SQLite. --- modulesets/gnome-suites-core-deps-3.4.modules | 23 +-- 1 files changed, 9 insertions(+), 14 deletions(-) diff --git a/modulesets/gnome-suites-core-deps-3.4.modules b/modulesets/gnome-suites-core-deps-3.4.modules index 25bb7bd..d655df3 100644 --- a/modulesets/gnome-suites-core-deps-3.4.modules +++ b/modulesets/gnome-suites-core-deps-3.4.modules @@ -379,9 +379,8 @@ /dependencies /tarball - tarball id=folks version=0.6.6 autogenargs=--enable-eds-backend -source href=http://ftp.gnome.org/pub/GNOME/sources/folks/0.6/folks-0.6.6.tar.xz; -hash=sha256:3dd6a2983969a6369c6b0e25f28ec92415b5570dd6c89b25385807ecc4aeb0a8/ + autotools id=folks autogenargs=--enable-eds-backend +branch revision=wip/vala-0-15/ dependencies dep package=dbus/ dep package=dbus-glib/ @@ -394,7 +393,7 @@ suggests dep package=telepathy-logger/ /suggests - /tarball + /autotools tarball id=fontconfig version=2.8.0 pkg-configfontconfig.pc/pkg-config @@ -758,18 +757,16 @@ /dependencies /autotools - tarball id=libgee version=0.6.2.1 + autotools id=libgee +branch revision=0.6/ pkg-configgee-1.0.pc/pkg-config -source href=http://download.gnome.org/sources/libgee/0.6/libgee-0.6.2.1.tar.bz2; -hash=sha256:e177be887727c9c214bd41f46063e386a7292ba207f586930148190580c829ad -md5sum=9c95ab9462179610d39df3c5a0911f3b size=477230/ dependencies dep package=glib/ /dependencies suggests dep package=gobject-introspection/ /suggests - /tarball + /autotools autotools id=libgnomekbd branch/ @@ -1234,15 +1231,13 @@ /suggests /autotools - tarball id=vala version=0.15.0 + autotools id=vala autogenargs=--enable-vapigen +branch/ pkg-configlibvala-0.16.pc/pkg-config -source href=http://download.gnome.org/sources/vala/0.15/vala-0.15.0.tar.xz; -hash=sha256:828f7341a3c4fc14b6d0f5a14ce3bdf4c40f5eae3e7ccf11c2b49061df9d2e23 -md5sum=2bffc49985cc790f0a9522b159ef935b size=2618360/ dependencies dep package=glib/ /dependencies - /tarball + /autotools autotools id=WebKit makefile=GNUmakefile autogenargs=--enable-introspection -- 1.7.6.5 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, Jan 23, 2012 at 10:48 PM, Colin Walters walt...@verbum.org wrote: Any objections to this patch for the moduleset? jhbuild should always be building from actual source code (i.e. git) for modules we expect GNOMErs to possibly hack on Great to read that jhbuild should preferably build over vcs and not tarballs. If people want to stick to a particular tag or branch, they can still specify it and keep using the vcs. The tarballs aren't developers friendly at all. regards -- Marc-André Lureau ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, Jan 23, 2012 at 4:48 PM, Colin Walters walt...@verbum.org wrote: Any objections to this patch for the moduleset? Looks right to me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple vala versions in 3.4
On Mon, 2012-01-23 at 17:12 +0200, Zeeshan Ali (Khattak) wrote: On Mon, Jan 23, 2012 at 9:53 AM, Emmanuele Bassi eba...@gmail.com wrote: hi Zeeshan; Hi Emmanuele, On 23 January 2012 02:14, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Sun, Jan 22, 2012 at 11:50 PM, Christophe Fergeau t...@gnome.org wrote: 2012/1/21 Zeeshan Ali (Khattak) zeesha...@gnome.org: There are way too many of the libraries to take care of and on top of that they change all the time. Ideally each library should be providing vala bindings and take care of keeping it up2date. So its really not a fault of vala itself. I don't agree with this assessment. you're just deferring the issue to every library under the sun, and this is very much problematic in a variety of reasons: - as a maintainer, now I'd have to care not only about introspection, but also about a vapi file - which is another redundant format that expresses the library's API; so the first thing I'd look at would be generating the latter in terms of the former, which introduces a build dependency (albeit optional) on Vala. so it's my library that now has to deal with the compiler and generator bugs. yeah, right: not going to happen. What I was proposing wasn't so different from what you are saying here. Vala bindings should still be generated out of gir bindings but since gir doesn't support some of the essential features that vala apps have been depending on for some time now, we'll need to have *some* vala-specific metadata, at least until gir supports those features. I've been putting together a guide for people wanting to maintain bindings upstream, and it includes an incomplete list of discrepancies between GIR and Vala (and how to work around them): https://live.gnome.org/Vala/UpstreamGuide#Using_Metadata_Files If having any vala-specific metadata in a few libraries isn't acceptable to maintainers, yeah we should first separate out the bindings into another package and then push the bindings that are purely generated from gir to their respective libraries. I think it's worth pointing out here that most libraries aren't going to have a lot of metadata. Clutter's API is pretty large (the vapi is 7283 lines) and it only has 158 lines (including comments and whitespace, less once bug #667840 is resolved) of metadata, but most libraries will only have a few lines. BTW just for the record, It should be noted that gir is the cause of the problem here not vala. That's not really fair. It's true that there is some stuff that GIR doesn't support that we would like them to, but Vala's GIR parser has bugs too. Up until fairly recently Vala's GIR parser was definitely the bigger problem. - I have used Vala, but I'm not an expert on figuring out its quirks, nor am I using it for my day to day work; this means that I'll have to rely on Vala developers to update the Vala bindings. this means that Vala developers and users will now need to go through various bugzilla products and git repositories to fix the Vala bindings in each and every project that ships one. They'll have to go through the same procedures as python and javascript users so I don't think this is an issue. Actually this will give good motivation to vala developers to fix/improve your gir annotations for you. Yes! After the initial work to get bindings working properly, most of the stuff we do is actually fixing things in the metadata file that could/should really be fixed in annotations within the upstream project. This means that currently my workflow often looks something like this: 1. Tweak the metadata to fix the issue in the vala repository and regenerate the bindings. 2. Create a patch against the upstream library to resolve the issue with annotations. 3. File a bug report with the patch and wait for upstream to resolve the issue. Example: clutter bug #667840 4. Undo the changes to the metadata file in the vala repository and instead regenerate the bindings using the updated GIR. My offer to help with maintenance for libraries wanting to move bindings upstream wasn't entirely selfless; I could eliminate steps 1 and 4. It also means that you get those annotation fixes sooner rather than later (sometimes much later since I sometimes don't get around to #2 for a while, and sometimes someone else does #1 doesn't worry about the rest), which fixes the GIR-based bindings for other languages as well. The other obvious advantage is that users don't have to wait for a new Vala release to get updated bindings. Finally, we can stop worrying about a whole class of issues where the bindings are too new. Say a library has a virtual function and they decide they want to add a method which invokes it (a pretty common scenario). After you regenerate the Vala bindings valac will start using the invoker automatically instead of calling the vfunc directly, which works great for
