Re: Proposal: Replace all references to master/slave in GNOME modules
On Thu, 25 Apr 2019 at 06:21, wrote: > This should go without saying, but master branches are not a reference > to slavery, rather to canonicity. What Michael said. Replacing Master/Slave terminology is a worthwhile task, but that doesn't mean doing a blanket search-and-replace for 'master'. Note that Django, Python, and Rust have all removed master/slave terminology where they use it, but all still have a 'master' branch in git. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab CI runners for non-Linux systems
On 6 June 2018 at 15:38, wrote: > Le mercredi 06 juin 2018 à 15:33 +0100, Ross Burton a écrit : > > On 18 May 2018 at 10:52, Philip Withnall wrote: > > tl;dr: Want to provide us with a GitLab CI runner for a non-Linux > platform? > > There’s been a surge of interest recently, from various directions, in > getting GLib better tested on non-Linux architectures. This is great, > and we’ve got various people to thank for doing the thankless work of > porting and testing. Particularly: > • macOS: Ryan Schmidt, Patrick Griffis, Michael Lauer, John Ralls > • Windows/MinGW/MSYS2: LRN, Christoph Reiter, Xavier Claessens, Chun- > wei Fan > • Android: Xavier Claessens > • *BSD: Ting-Wei Lan > > > Would you be interested in extending the Linux coverage to include > cross-building to proper Linux? > > https://gitlab.gnome.org/rburton/glib/-/jobs/42792 is a bit hacky but > demonstrates that using a Yocto-built toolchain with autotools, glib will > cross-build successfully to aarch64. Next step is to try with Meson, but > auto* was easier as we exercise that in our own QA. > > > We already have android aarch64 and mingw64 cross build on our linux > docker images using meson. More cross build could be added of course. > How about mips64 proper Linux (not Android). Actually, MIPS64/musl would be an interesting combination given the patches we've previously had to carry. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab CI runners for non-Linux systems
On 18 May 2018 at 10:52, Philip Withnall wrote: > tl;dr: Want to provide us with a GitLab CI runner for a non-Linux > platform? > > There’s been a surge of interest recently, from various directions, in > getting GLib better tested on non-Linux architectures. This is great, > and we’ve got various people to thank for doing the thankless work of > porting and testing. Particularly: > • macOS: Ryan Schmidt, Patrick Griffis, Michael Lauer, John Ralls > • Windows/MinGW/MSYS2: LRN, Christoph Reiter, Xavier Claessens, Chun- > wei Fan > • Android: Xavier Claessens > • *BSD: Ting-Wei Lan > Would you be interested in extending the Linux coverage to include cross-building to proper Linux? https://gitlab.gnome.org/rburton/glib/-/jobs/42792 is a bit hacky but demonstrates that using a Yocto-built toolchain with autotools, glib will cross-build successfully to aarch64. Next step is to try with Meson, but auto* was easier as we exercise that in our own QA. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Google Hangouts support
On 18 October 2017 at 16:52, Diane Trout wrote: > I thought the biggest reason Telepathy stalled was Nokia stopped > funding the work at Collabora after they were acquired by Microsoft, > and there weren't enough non-Collabora people involved to keep the > project healthy. > There's more than just politics and paying people. Rob (original co-author) wrote this recently: https://mail.gnome.org/archives/desktop-devel-list/2017-September/msg00047.html. It's a very interesting read. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Slowness problem with GTK-Doc
On 18 February 2017 at 18:40, Shaun McCance wrote: > But in the short term, switching to yelp-xsl would make builds faster. > Is this just a matter of pointing at a different set of stylesheets, or is there more to the port than that? Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Librsvg 2.41.0 is released
On 5 January 2017 at 18:25, Emmanuele Bassi wrote: > As for Continuous, we should be able to add Rust to the Yocto base. > Unfortunately, the build bot is still not running (and it hasn't been > building images since early December), and I don't have access to it > to check why. > There's a meta-rust layer already, although I've not actually used it yet to vouch for how good/bad it is. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK+ plans for 3.22
On 26 April 2016 at 21:23, Emmanuele Bassi wrote: > Is this going to be opt in, or is GL going to be a hard dependency for >> GTK+ in the future (and what sort of time line are we talking here). >> > > I have a Cairo based fallback renderer which does not do any 3D transform, > and there's always Mesa's software rasteriser if you feel so inclined. > Moving forward, if I'm allowed to be absolutely blunt, I'm not going to > care about non-GL or non-GLES targets because if I didn't care *that* much > 7 years ago with Clutter, I'm not going to magically care more with > the much, much better stack we have these days. Having said that, if > somebody wants to submit patches to get fake 3D transforms with Cairo, I'm > going to review them gladly and quickly. > Well if the toolkit doesn't do 3D then that cairo fallback is just fine I guess, and hopefully encourages someone to write some 3D math. Just curious, with my "what if my platform is arse?" hat on. :) Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK+ plans for 3.22
On 26 April 2016 at 21:14, Emmanuele Bassi wrote: > The main consumer is GTK itself; the idea is to have GTK render to Cairo > surface, as it does now, and then blend/blit with OpenGL (or OpenGL ES). In > the future we want to move to a model where we do most of the rendering on > GL itself, a la Servo. > Is this going to be opt in, or is GL going to be a hard dependency for GTK+ in the future (and what sort of time line are we talking here). Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 feature: polari
On 11 October 2013 10:21, David Woodhouse wrote: > > Why stop at IRC? Given that the engine is Telepathy, we could use it > > for named rooms on any protocol, like XMPP MUCs for instance. Is there > > some limitation somewhere that makes it only suitable for IRC? > > So this would be a replacement for Empathy? Given my recent experience > of trying to get users to use GNOME3+Empathy (before giving up and using > pidgin), that probably wouldn't be a bad thing... > Or be a better alternative to Empathy for rooms, leaving Empathy (or eventually, Contacts + Shell, I guess) for IM. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How long should it take to fix a obvious memory leak?
On 4 April 2013 16:04, Ma Xiaojun wrote: > On Thu, Apr 4, 2013 at 11:01 PM, Debarshi Ray wrote: > > Did you ask for your money back? > > No, I prefer paying some money rather than writing stupid E-mails as > the way to ask for support. Sound good. There are numerous companies that provide paid support around GNOME, you'll be able to contract any one of those to fix this bug for you. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Porting GNOME to Wayland
On Monday, 18 March 2013 at 14:58, stefan skoglund(agj) wrote: > I wont be able to run wayland on my machine (old nv20-based graphical > card.) Anyone with a spare agp card with really good support in current > day X.org (http://X.org) ? Weston can composite with pixman, you don't need accelerated GL drivers. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Porting GNOME to Wayland
On 18 March 2013 05:10, Martyn Russell wrote: > Is this likely to cause regressions or be problematic with OpenGL or Wine > based aps/games running on the GNOME shell desktop? I understand vaguely the > relationship between GTK+ and Wayland, but not how a raw GL based > application or how a Wine based app would work with Wayland? Actually for applications that do full-screen GL, expect them to work faster in Wayland/Weston, as it can use the application surface as the output and just flip buffers - no compositing required. For Wine, you'd have to speak to the Wine maintainers as whether they do a Wayland port or Xwayland is required. Again, xwayland isn't the performance hit you'd expect from a nested environment. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Preserved Window Placement
On 24 October 2012 14:28, Jason Simanek wrote: > Is it an issue of the complexity of the problem being too great and the > interest in solving it being too small? Basically, yes. Restoring the location of arbitrary windows from outside of the application is hard. Applications where it's useful for window location to be restored (i.e. they implement the rest of state persistence) can simply restore the co-ordinates too. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Preserved Window Placement
On Wednesday, 24 October 2012 at 00:13, Luis Menina wrote: > > > Do you know the "geometry" option in X11? > > > http://en.wikibooks.org/wiki/Guide_to_X11/Starting_Programs#Specifying_window_geometry > > > > > > > > Thanks for the link. Seems a bit backwards that I would have to do this > > via each program's launch command, but at least it's an option. Course, > > in Gnome 2 this would have been easier to create custom launchers > > Not sure how to go about doing that in Gnome Shell. > > Maybe devil's pie still works with Mutter ? > http://burtonini.com/blog/computers/devilspie Devil's Pie works with Mutter, but it doesn't have any way to save and restore sizes without specifying them directly. You could try Devil's Pie 2 which has a proper scripting engine at the core, so you could probably write a save/restore script that doesn't need explicit sizing. You'll then see how hard this is to do properly. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: finding and rediscovering shared links
> http://getpocket.com > > Or Instapaper. Instapaper. I'm having to explain to the pocket engineer that this isn't a valid XML document: ... ... :/ Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
On 27 April 2012 05:51, Jasper St. Pierre wrote: >> FWIW on some of my machines, the screensaver is already pretty funny >> security-wise. When coming back from sleep. It shows the desktop screen >> for several seconds before locking the screen. Sometimes it only locks >> one monitor. Sometimes the lock dialog isn't visible. I haven't started >> to try and debug these issues. > > If I remember correctly, this was a SELinux policy issue. It should be > fixed in upgrades-testing. I'm seeing this on Debian Unstable with GNOME 3.2.1, so it's not a SELinux issue. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prevent screen from going to sleep
On 1 March 2012 10:07, Marco wrote: > I sometimes have a PDF that I want > to display without the screen being turned off. That would be View->Presentation in Evince, I believe. Ross ___ 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 20 January 2012 12:25, Maciej Marcin Piechotka wrote: > It's included by default in new automake: > > AM_PROG_VALAC([0.14.0]) > > (checks for valac >= 0.14.0). Does that also check for valac-0.14 when valac doesn't exist? Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using Bugzilla for freeze break requests?
On 23 September 2011 10:58, Olav Vitters wrote: >> For what it's worth this is exactly what we do in MeeGo for >> distribution freezes and we find it works very well. > > Do you have multiple freezes? Do you use one flag or multiple? How do > you handle multiple teams and e.g. one flag? We have a single freeze which does make things easier. There is a group of people who can approve the flag, they all have rights to it and we rely on clue so e.g. the netbook approver doesn't approve tablet requests. > My idea would be: > * 1 flag, freeze_break > * 3 teams having access to grant/deny (i18n+docs+r/t) > with a limited amount of people we'd just rely on awareness instead of > technical solutions. E.g. i18n team should not mark a break as > 'approved' if we're in hard code freeze > * only people marked as developers being able to request (simply to avoid > confusing random users with a flag option) Agreed that this alternative would be more sensible than presenting multiple flags. If you require that people explain what their change does so the approvers understand what freezes are being broken, then it should become automatically peer reviewed if say the i18n team approved a code change. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using Bugzilla for freeze break requests?
On 23 September 2011 08:40, Olav Vitters wrote: > The Bugzilla way of doing this is to use flags. A flag is either defined > for attachments _or_ (not and) bugs. This is possible on our currently > bugzilla; we just do not use them. For what it's worth this is exactly what we do in MeeGo for distribution freezes and we find it works very well. Ross ___ 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
On 14 September 2011 11:43, Milan Crha wrote: > why is that? I can imagine couple useful things being tight to the > maintainer mode, also those aforementioned deprecated stuff being in use > only for maintainers, not for regular users, like is done here [1]. > Other users in this thread gave also reasonable examples of a usage of > the maintainer mode, not only for a makefile generation. 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? Ross ___ 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
On 14 September 2011 08:19, Milan Crha wrote: > By the way, your change has a side-effect where DBus factories of > evolution-data-server (e-addressbook-factory and e-calendar-factory > processes) depend on gtk+ by default, because I did a change couple > weeks ago to do that *when compiled with the maintainer mode*, which is > the default after your change. "maintainer mode" shouldn't mean anything else apart from changing how the makefiles generate, and certainly shouldn't change what code is being compiled. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Full screen color management
On 6 September 2011 12:26, Richard Hughes wrote: > So, basically, is this something we want? Yes. That is all. Seriously, excellent work on getting this together and making the dream of proper colour management on Linux achievable. We *need* this. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enabling GConf-over-DBus in GNOME 3.2 jhbuild
On Wednesday, 20 July 2011 at 20:29, Matthias Clasen wrote: > Obviously, the best solution is to complete > http://live.gnome.org/GnomeGoals/GSettingsMigration ... And obviously I should have won the EuroMillions lottery last weekend... ;) Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Enabling GConf-over-DBus in GNOME 3.2 jhbuild
On Wednesday, 20 July 2011 at 19:41, Colin Walters wrote: > On Wed, Jul 20, 2011 at 2:14 PM, Ross Burton (mailto:r...@burtonini.com)> wrote: > > Hi, > > > > So the DBus port of GConf landed recently and there haven't been any > > totally serious problems reported so far... would anyone object if I > > changed jhbuild to use --disable-orbit in the GNOME 3.2 suites? > > The general principle I see here is that we want partial builds to > work on at least the most recently released versions of widely-used[1] > distros. So check whether they work in this configuration? In this > case, that'd be new libgconf talking to system gconfd. Actually we've had reported breakage from jhbuild's gconf-over-orbit trying to use Ubuntu Oneiric's gconf-over-dbus, so I suspect we're going to get some problems either way. Not sure what the best solution here is to be honest. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Enabling GConf-over-DBus in GNOME 3.2 jhbuild
Hi, So the DBus port of GConf landed recently and there haven't been any totally serious problems reported so far... would anyone object if I changed jhbuild to use --disable-orbit in the GNOME 3.2 suites? If that works out well I may well decide to change the default so you have to --enable-orbit otherwise DBus is the default, but that can be decided later. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf port to DBus
On 1 July 2011 15:41, Vincent Untz wrote: > Le vendredi 01 juillet 2011, à 14:17 +0100, Ross Burton a écrit : >> On 1 July 2011 13:56, Ross Burton wrote: >> >> If you intend this to be part of 3.1.3, merging it before the weekend >> >> would be nice. That will give us a few more days to deal with possible >> >> fallout and find a volunteer to roll a gconf tarball. >> >> Okay, I've just merged it to master. >> >> As I said it defaults to using ORBit so hopefully this is a no-op for >> most people. Please report any breakage to me! > > So what's the recommendation for downstreams? :-) Should we try to > switch to the dbus port, or stay with the old stuff? If you're currently in a development cycle, feel free to switch to the DBus port. It should work fine... (famous last words) I also just re-released as 3.1.3 and am trying to get 2.32.5 removed from the servers. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf port to DBus
On 1 July 2011 14:24, Matthias Clasen wrote: > Do you want to go the extra mile and roll a tarball ? That would be > appreciated... 2.32.5 rolled and released. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf port to DBus
On 1 July 2011 14:29, Andre Klapper wrote: > On Fri, 2011-07-01 at 14:17 +0100, Ross Burton wrote: >> On 1 July 2011 13:56, Ross Burton wrote: >> >> If you intend this to be part of 3.1.3, merging it before the weekend >> >> would be nice. That will give us a few more days to deal with possible >> >> fallout and find a volunteer to roll a gconf tarball. >> >> Okay, I've just merged it to master. > > As gconf does not have a gnome-3-0 branch this commit broke the string > freeze for 3.0.x. Branching before the commit is welcome... Apologies, I forgot that there were a few new strings. Branch created. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf port to DBus
On 1 July 2011 13:56, Ross Burton wrote: >> If you intend this to be part of 3.1.3, merging it before the weekend >> would be nice. That will give us a few more days to deal with possible >> fallout and find a volunteer to roll a gconf tarball. Okay, I've just merged it to master. As I said it defaults to using ORBit so hopefully this is a no-op for most people. Please report any breakage to me! Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf port to DBus
On 1 July 2011 13:44, Matthias Clasen wrote: > On Fri, Jul 1, 2011 at 7:02 AM, Ross Burton wrote: >> On 29 June 2011 18:20, Emmanuele Bassi wrote: >>> On 2011-06-29 at 15:51, Ross Burton wrote: >>>> Any comments? >>> >>> just merge the blasted thing already. :-p >> >> If nobody has any comments I do intend to merge this branch on Monday. > > If you intend this to be part of 3.1.3, merging it before the weekend > would be nice. That will give us a few more days to deal with possible > fallout and find a volunteer to roll a gconf tarball. I'll take that as approval to merge now. :) I've just got one niggle to sort out (a stray orbit mention in the pkgconfig file) and then I'll merge. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GConf port to DBus
On 29 June 2011 18:20, Emmanuele Bassi wrote: > On 2011-06-29 at 15:51, Ross Burton wrote: >> Any comments? > > just merge the blasted thing already. :-p If nobody has any comments I do intend to merge this branch on Monday. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GConf port to DBus
Hi, As you may be aware (for most people, probably not) there has been a long-standing branch of GConf to DBus. CodeFactory did the initial port back in the DBus 0.x days for Maemo and more recently we've (Intel) have been rebasing and enhancing it for MeeGo. Rob Bradford and myself have just finished rebasing it against GConf master and bravely pushed it to a branch (port-to-dbus) at git.gnome.org. Our proposal is that the branch is merged into GConf master. (At this point you could say "why bother? GConf is dead". For the GNOME Platform that's a worthy goal, and it might even happen in 3.2. But the larger ecosystem isn't going to be as quick to switch to GSettings as this, so GConf is going to hang around for quite some time. Merging this branch means that for the typical GNOME 3 desktop there is no more ORBit involved, hurray!) The ORBit support is still present and active by default. To use DBus IPC pass --disable-orbit. I'll admit that the DBus port is rather archaic, using raw libdbus instead of anything modern like dbus-glib or (gasp!) GDBus. The core code hasn't changed much since the last DBus API break, but it does work as we've been shipping it in Moblin 2/MeeGo onwards (and Nokia have been shipping something in all Maemo releases). Whilst I think that spending the time to merge this branch is worth the effort, I don't think porting it to GDBus would be an effective use of time. The big question is who is willing to review the branch... GConf doesn't have any real maintainers any more. Various respected people in the community have been involved in this fork and it's been around for a fairly long time so it's not entirely crazy, but still... What we do have in our favour is that the DBus support is optional and disabled by default. Any comments? Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: HTTP REST library ??
2011/6/1 Erick Pérez : > Question: Which is the method/standart component you recommend to make > HTTP REST requests in gnome ? > I read the PlatfromOverview of Gnome 2.32 and there libsoup was > mentioned, as the same document for Gnome 3.0 isn't ready yet I wonder > libsoup is still the way Gnome should connect to HTTP services ? libsoup is certainly a good choice. If you want something working at a higher level, then have a look at librest (also in gnome git). Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
On 18 May 2011 14:49, Josselin Mouette wrote: > I don’t have anything against requiring systemd, since it is definitely > the best init system out there currently, but the Linux dependency is an > absolute no-no for us. Having optional Linux-only functionalities is OK; > requiring Linux is not. I do have to wonder how many people are actually using GNOME on Debian on BSD, or even (ahah) Hurd... Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would easonably want to add]
On Monday, 16 May 2011 at 19:20, Lennart Poettering wrote: AFAIK (and I may be wrong), but that's part of its "am I really > > online" ping to connman.net, which acts as a captive portal detection. > > The response packet contains a continent, or something. > > Oh my. Conmann phones home? This gets more and more interesting... http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=plugins/portal.c Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On 16 May 2011 18:22, Lennart Poettering wrote: > conmann also does geoloc? Is there something it doesn't do? Sounds > almost as crazy as systemd ;-) AFAIK (and I may be wrong), but that's part of its "am I really online" ping to connman.net, which acts as a captive portal detection. The response packet contains a continent, or something. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On 16 May 2011 00:09, Lennart Poettering wrote: > Ah, very interesting. This is good to know. Interesting place though, in > connman. Yeah, it is "interesting". I discovered this because I'd floated the idea of a tiny TimeKit daemon, mainly to deal with setting the system timezone and emitting signals when it changes. It's almost like we've all got the same problem. :) IIRC, the rationale was that connman is already doing a fair amount of time manipulation: it has a NTP client and can also (or will, can't recall) auto-set the timezone based on your geo-IP. From that it's just a matter of allowing the user to manually set the timezone. Personally I'd hope that if a cross-desktop DBus interface was proposed, that connman would implement it as a wrapper. > Hmm, do you happen to know where connman stores the high-level timezone > name? i.e. "Europe/Berlin"? We'd like to standardize some place for this > in the systemd context, and I am currently figuring out if we can just > adopt an existing solution. http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=src/timezone.c;h=263ee4efe619e7f59a4844477131b09fb0e2cca1;hb=HEAD#l292 It takes the contents of the zoneinfo file and writes it to /etc/localtime. It also reads /etc/sysconfig/clock at startup, but doesn't appear to write that file. I can't seen where the name is written though. This support is pretty new so might have some missing pieces. Obviously for more details the connman list is the place to go. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
On Sunday, 15 May 2011 at 22:14, David Zeuthen wrote: If only you'd use the standard org.fd.DBus.Properties interface here > then it would be a lot easier to use via e.g. GDBusProxy and other > bindings. And it's a lot easier to inspect with tools like gdbus(1) or > d-feet(1). Not saying it's impossible to write the code to get the > properties and watch for changes - but it's something that _most_ > people get wrong or they block the main thread or they end up with > proxies where half the properties is from the old owner and the other > half is from the new owner. Things like that. > > (I also see this is using an object exported at / - that's wrong too > but it's a lot harder to get this point across to people.) > > I'll follow up anyway :) with yes, I know, but you'll have to tell Marcel. Just the messenger etc. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: language/locale selector [was: Re: Settings downstream would reasonably want to add]
Let's try that again... On Sunday, 15 May 2011 at 20:10, Lennart Poettering wrote: > (Background: I am > working on cleaning up all those little services that can change > locale/clock/timezone/hostname/... in the context of systemd) > In case you were not aware, in MeeGo 1.2 we've added a "clock" interface to connman. This mainly handles NTP client functionality but can also control (manually or automatically) the system timezone. http://git.kernel.org/?p=network/connman/connman.git;a=blob;f=doc/clock-api.txt Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
On Friday, 13 May 2011 at 20:17, Alexander Larsson wrote: I think we should focus on automatic login into a locked session. There > are various issues here, like: > > * Must add keyring unlocking to unlock screen > * keyrings are only availible once you're unlocked, which means some > things need to wait for some signal that the keyring is up before doing > stuff. > * Encrypted homedirs are problematic since we can't e.g. read the users > preferences before we unlock. > * Don't want to start autostart apps or start the session before we've > authenticated, as there might be security issues. MeeGo for Netbooks does this. It's not perfect and we've made several design choices that ease the implementation, but it does work -- we login to the session with a locked screen. We even support encrypted home partitions, not sure what happens the though... Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Settings downstream would reasonably want to add [was: long thread with no resolution]
On 13 May 2011 09:56, Dave Neary wrote: > What preferences do you think you'll want to add to GNOME CC which > aren't currently planned, and how would you like to add them? I happen to have a MeeGo 1.2 beta netbook on my desk, so this is what's currently in our gnome-control-centre (2.30-based) shell: - Wallpaper and fonts (upstream Appearance, patched) - System Tray (custom, option to enable the legacy systray) - Myzone (custom, options for the MyZone panel) - Language (based on system-config-language, IIRC) - E-mail Settings (Evolution's settings) - Toolbar Settings (custom, options for the top toolbar - Security and Passwords (custom, toggle for lock-on-boot and ability to change your password) - My Web Accounts (custom, configure social accounts) - IM Settings (Empathy settings) - Date & Time (system-config-datetime, IIRC) - Trackpad and mouse (upstream with patches, I think) - Printing (system-config-printer) - Network Proxy (upstream) - Keyboard (upstream) - Sound (upstream) - Power and Brightness (custom minimal power management interface, just the timeouts) - Monitors (based on the upstream but heavily patched) If we ported to GNOME 3 platform but wanted to keep our experience mostly the same then we'd be able to drop several entirely (e.g. Background & Fonts, Printing, Date & Time), remove some others and move to patches (i.e. Power, just hide a few settings that we enforce instead). We'd still want the settings that control *our* desktop shell (i.e. MyZone, Toolbar) and there are some that are still sufficiently different that we'd still need custom capplets (i.e. Monitors). Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On 13 May 2011 09:49, Sergey Udaltsov wrote: >> capplet only supports clone) and are very pleased that we can drop in >> new capplets because it installs the library headers... > Thanks, Ross, for illustrating the real downstream POV. Do I understand it > right that gnome3 approach to g-c-c extension (patching only) is going to > make your life harder but would not stop you from putting your bits into > g-c-c? Hypothetically speaking, we'd have to patch g-c-c to install the headers so that the out-of-tree capplets that we have could be built. As someone who works on a platform heavily based on GNOME technologies, the ability to build capplets out-of-tree is incredibly useful. I can understand the desire for the preferences panel to not be a random collection of apps, but I'd be surprised if any distribution that does real customisation of the platform will get by without patching g-c-c at all. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
On 12 May 2011 20:52, Sergey Udaltsov wrote: >>> For something like this, I have a feeling we may only get one chance. If >>> you don't allow any differentiation on top of GNOME, there is at least >>> one distribution that will just do preferences differently & ignore >>> control-center. And I can imagine that future environments along the >>> lines of moblin, MeeGo, Maemo, etc will end up redoing the preferences >>> from scratch, rather than building on the gnomecc work. >> >> They are doing that anyway, and there is nothing we can do to stop them. > Why are they doing that? Isn't that a very important question? Is just > just because of them - or is it about GNOME as well? > If distros tend to ignore the things that GNOME provides - perhaps, > GNOME provides something that is not easy to use/customize? (moblin + maemo == meego, so you've really only got one example there) FWIW, the netbook spin of MeeGo uses gnome-control-center. We patch some capplets and replace others (i.e. display settings, our display capplet only supports clone) and are very pleased that we can drop in new capplets because it installs the library headers... Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 11 May 2011 13:24, Michael Terry wrote: > When disk space is low, the oldest backup is already deleted to make > room. I just meant it is hard to implement 'telescoping' backups > where we only keep monthly backups from 1 year ago, weekly backups > from a month ago, etc. FWIW, that's what Time Machine does. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On 11 May 2011 12:03, Bastien Nocera wrote: > Administrators aren't a magic people. When you have a personal machine, > you're the administrator. > > Time Machine has shown how to do backups in a sane way. I'd hope that we > can achieve the same level of integration, and ease of setup. > > Right now, making backups requires too much work, and people don't do > it. I'd really like it to be much simpler and straight-forward. As someone who has several Macs at home, I endorse the message that Time Machine is serious magic and should be cloned as soon as possible. :) Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: First release of geocode-glib available
On 9 May 2011 17:21, Bastien Nocera wrote: >> What are the terms of service on this API? If they are in any way >> restrictive, can you document them in the API docs? > > 50k requests per day, and the fact that the data gathered doesn't > "belong" to you. > > See rate limits and terms of use, as linked from the API docs: > http://developer.yahoo.com/geo/placefinder/ > > We (me, with GNOME Foundation Board hat on) are still in touch with > Yahoo!, and we should be able to increase the rate limits. > > Right now, I'm taking a "we'll see" approach. If it turns out that using > Yahoo!'s APIs is not manageable, we'll probably start using Nominatim > from OpenStreetMap instead. But I'd rather force the issue with them, > showing what advantages their APIs could provide us. Sounds like a good plan, good luck. :) Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: First release of geocode-glib available
On 9 May 2011 16:52, Bastien Nocera wrote: > This is the first release of geocode-glib, a small library on top of the > Yahoo! Place Finder API. What are the terms of service on this API? If they are in any way restrictive, can you document them in the API docs? Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
On 27 April 2011 14:18, David Zeuthen wrote: > We probably want to embed a web browser engine for the Online Accounts > panel - e.g. I don't think it's not good enough to rely on the users > browser with the way e.g. OAuth2 works -- you really want to intercept > the redirect URL and not have to scrape the authorization code out of > a window title (as the Google OAuth2 docs humorously suggests) or have > the user copy/paste it to the panel. In this case we want to use > WebkitGTK+ which has > WebKitWebView::navigation-policy-decision-requested signal to solve > this. Some services such as Fire Eagle recommend that you use the default web browser and don't embed a HTML widget on the grounds that the user will then see the URL and other security information that they are used to, and not just random HTML that could well be faked. They then recommend to redirect back to the application by registering a new URL protocol (say, x-myapp-auth) and redirecting there. These rationales seemed really sensible so we tried this in MeeGo and discovered that Fire Eagle is the only service we found who doesn't mandate that the redirect URL is "valid", meaning a http: URL. Some even refused to redirect to localhost after the settings app started a private HTTP server on the loopback interface. So yes, I'd say that embedding a HTML engine is fairly important. Being able to support the user's own browser is probably a good idea too though. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On 19 April 2011 11:56, Tomasz Torcz wrote: > Just recently there were some comment on sad state of sync: > http://www.happyassassin.net/2011/04/13/the-continuing-state-of-contact-calendar-synchronization-suck/ > http://luther.ceplovi.cz/blog/2011/04/synchronization-sucks/ > > Can we make synchronisation not suck? Patrick actually went to the bother of replying to those posts in blog form: http://syncevolution.org/blogs/pohly/2011/state-syncing-open-source A good read, I recommend it. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ThreePointOne: Contacts
On 19 April 2011 11:27, Alexander Larsson wrote: > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: >> another very important point is synchronisation. together with salomon >> sickert we thought about how to solve this problem. basically we came up >> with the idea of a self-replicating backend, like couchdb. if we then >> could add support to the contact apps of other computer/devices like a >> n900 or android, we would get synchronisation and conflict management >> for free. >> >> then there is also the idea of having a webservice for the gnome >> contacts app, where you can access your contacts over the internet. >> >> we are very interested in your opinions about this! > > I don't know really. Synchronization is a tricky subject, with complex > protocols and risk for merge problems. Its almost always a source of > weird problems. I don't think we want to have synchronization as some > core part of the design. > > On the other hand, its important that there is some level of support for > synchronizing contacts with e.g. phones. So, I guess we need to think > about where it fits in. If you start to talk about synchronisation, please talk to Patrick Ohly . He maintains SyncEvolution that is probably the only working PIM syncing tool that I know of, and it's totally non-trivial. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.91.1 status
On 20 October 2010 20:29, Zeeshan Ali wrote: > Vincent pointed this issue out two weeks ago and it has been fixed in git > master ever since. I asked if a release with fix is needed but I was told > that that its not (at least by Vincent) so I didn't release. Now I'm sick so > I asked Ross to roll it out. I've just release gupnp-av 0.6.2 to gupnp.org. Ross ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using AS_ALL_LINGUAS instead of po/LINGUAS
On Fri, 2010-07-16 at 18:21 +0200, Christian Persch wrote: > With the current scheme, we have po/LINGUAS which is disted > automagically. With your scheme, we need po/LINGUAS.ignore (which you > have to dist manually). It's probably possible to get LINGUAS.ignore added to the dist automatically. > Also, if you add a new po/xx.po file, configure isn't re-run > automatically so the new entry isn't added to ALL_LINGUAS. This works > with the current po/LINGUAS file (since inltool's Makefile.in.in > evaluates the LINGUAS file at build time, not configure time). Might be possible to inject some rules... or we propose this as an option for intltool. The use-case for this was that with transifex the translators translate and submit .po files, but LINGUAS is never touched. Obviously this often leads to tarballs shipping with lots of translations that are disabled... Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Module Proposal: GNOME Shell
On Tue, 2010-04-06 at 08:44 -0700, Sriram Ramkrishna wrote: > Maybe I missed it but why are we only concentrating on Nvidia? Are > ATI graphics cards okay vis-a-vis xrand support and others on free > drivers? What about Intel? The foundation should probably take a > holistic approach to this issue if we want a uniform experience for > GNOME 3. Focusing on nVidia in this example because both ATI and Intel have open source drivers that are actively maintained with the features that we need (GL, xrandr, etc). I suggest you read the parent messages. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Module Proposal: GNOME Shell
On Fri, 2010-04-02 at 23:57 +0100, Alan Cox wrote: > > maintained for people without the correct hardware support. As of now, > > all intel, amd/ati and nvidia cards sold in the last five years should > > > I don't believe that is correct for any of the listed vendors even on > Linux. On BSD the situation is even more patchy. > > Is Gnome dropping support for these operating systems ? "The gnome-panel will still be available in GNOME 3.0 and will still be maintained for people without the correct hardware support" Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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 external dependencies for 2.32: telepathy-logger
On Fri, 2010-03-19 at 11:39 -0300, Jonh Wendell wrote: > I know we have gains, but we also have cons, with the desktop full of > processes. Perhaps we should only activate the daemon when needed by > some application, and deactivate it when the application closes? Pretty much all of the per-user daemons are started on demand, and if they don't kill themselves when not in use for a while then that is generally a bug. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Module Proposal: Rygel
On Mon, 2010-02-22 at 14:29 +, Sergey Udaltsov wrote: > > Just because others do it in a particular way, doesn't make it > > right. Although Rygel can be run as a system-wide service, the main > > target use-case is that of providing services per-user[1] so for > > example each user can choose to share his media on the network > rather > > than every user's media. > That use case is perfectly served by samba - having ONE system-level > daemon and multiple per-user shared directories (controlled by users) I wasn't aware that my Bravia TV or Roku SoundBridge could play from CIFS shares, I thought they were DLNA players, but thanks for informing me of this fact. Yes, I'm being sarcastic. Rygel is a DNLA media server, not a generic file server, samba doesn't "perfectly" serve the role of media server. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Module proposal: dconf
On Fri, 2009-10-16 at 10:07 -0400, Ryan Lortie wrote: > I personally think migration is less critical than a lot of people > think. Migration is important. An average user won't be too happy when they update their distro and find all of their settings have disappeared. Any arguments involving developers are basically irrelevant IMHO when it comes to migrations. Not providing a migration path will probably delay adoption of dconf/gsettings into Debian because Debian tries it's hardest to preserve user configuration, even during an update. There are long and scary scripts which can migrate gnome-panel 1.x to 2.x in Debian... Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Module proposal: dconf
On Wed, 2009-10-14 at 19:17 +0200, Rodrigo Moya wrote: > e-d-s stores the data in GConf, so it needs to be migrated indeed. Also, > even though the desktop-wide settings might be obsoleted > (/desktop/GNOME, for instance), apps still need their /apps/$app > configuration tree to be migrated, since they would probably keep using > the same conf entries Actually eds doesn't store anything in gconf, but it does read a few keys that Evolution stores there. It's "only" the location of the files on disk, not real user data. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Module proposal: dconf
On Wed, 2009-10-14 at 12:59 -0400, Jamie McCracken wrote: > The important thing is the ability of an admin to easily copy a branch > of config settings. Thats trivial in gconf and I use it for copying > settings between machines (cp ~/.gconf/blah) I disagree that it's trivial with cp. It's only possible with old installs of GConf, if you wiped your settings you'll find that the entire configuration is written to a single file (because it's much faster to load). Anyway, as has been said before it's the tools that matter and gconftool support this. > So whats needed is perhaps some import/export branches of settings to > xml that would enable something similar Yes, there needs to be a tool which imports and exports settings. I think this already exists. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30
On Thu, 2009-10-01 at 14:12 +0200, Rodrigo Moya wrote: > > If there is a local couchdb exepected for the common case then maybe > > the mozilla js dependency needs a mention. > > > it is not required for evo-couchdb to work, so I don't think it needs > any mention, apart from saying that if you want to run a local > CouchDB, > you need to install CouchDB and all its dependencies. Do you expect anyone to run it against a remote server? If connected to a remote server does evo-couchdb support offline operation and replaying of offline events, or does it fail if you are offline? I always thought the entire point was that you ran a local couchdb server so that you could then sync with other servers "in the cloud". Sure, you can run it against a remote server, but how much will that be used? > So it's quite lightweight $ sudo aptitude install couchdb Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done The following NEW packages will be installed: couchdb erlang-asn1{a} erlang-base{a} erlang-corba{a} erlang-crypto{a} erlang-docbuilder{a} erlang-edoc{a} erlang-eunit{a} erlang-ic{a} erlang-inets{a} erlang-inviso{a} erlang-mnesia{a} erlang-nox{a} erlang-odbc{a} erlang-os-mon{a} erlang-parsetools{a} erlang-percept{a} erlang-public-key{a} erlang-runtime-tools{a} erlang-snmp{a} erlang-ssh{a} erlang-ssl{a} erlang-syntax-tools{a} erlang-tools{a} erlang-webtool{a} erlang-xmerl{a} libsctp1{a} lksctp-tools{a} 0 packages upgraded, 28 newly installed, 0 to remove and 7 not upgraded. Need to get 20.2MB of archives. After unpacking 35.6MB will be used. Do you want to continue? [Y/n/?] CouchDB on Debian takes up 35MB of disk space. Not exactly lightweight. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: External Dependency Proposal: Berkeley DB (libdb)
On Tue, 2009-09-29 at 19:15 +0200, Jan de Groot wrote: > At Archlinux, we've been linking it dynamic since this blog post was > made. We have a db4.1 package for this, to keep compatibility with > evolution binaries that use the shipped binaries. We would be happy to > drop this db4.1 package and just depend on the latest version we ship in > our distribution, which is 4.8 at this moment. Debian happily builds e-d-s against whatever the "default" libdb in the archive is, which is currently 4.8. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: social services as a desktop service?
On Mon, 2009-09-21 at 14:54 +0100, Bastien Nocera wrote: > On Mon, 2009-09-21 at 13:34 +0100, Ross Burton wrote: > > > Anyway, if anyone wants to see what we're doing to solve this, have a > > look at the mojito (social data aggregator) and bisho (web services > > settings UI) modules on git.moblin.org. > > Might be time for some cross-pollination and have some Moblin services > trickle back into GNOME itself. Mojito itself has no dependencies other than librest (a layer on top of libsoup) that are not part of GNOME already, so we totally welcome people adding Mojito support to existing GNOME applications. If anyone has any ideas for social integration and would like some help in using Mojito, just ping me. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: social services as a desktop service?
On Mon, 2009-09-21 at 13:33 +0200, Rodrigo Moya wrote: > During the development of Ubuntu Karmic, I discussed with some people > about having social services accounts (facebook, twitter, etc) > configured in one place, about-me specifically. Since it was a bit late > for GNOME 2.28, I postponed the discussion, but now that 2.28.0 is > almost out, I'd like to start it here. > > So, the idea is to have a central place where all those accounts are > configured, so that applications using those services (gwibber for now, > not sure if there are some others?) can just use that instead of having > to ask the user in every application his/her credentials for those > social services. Storing a username and password, or even just a username, isn't that useful any more: MySpace, Facebook and Flickr don't allow programmatic login with a username at all, and instead do a web-based authentication which gives the application a session key. Whilst Twitter currently does allow username/password they'll be phasing that out with the migration to OAuth. Some services such as jaiku/qaiku use "api keys" which are actually just random 128-bit integers the user copies and pastes from the web site into their desktop application. In Moblin we're using gnome-keyring to store session token and secrets for services which use them (with the server and and API key as the attributes). We have a web services UI which lets people login to their service and then stores the resulting API key in the keyring for the application to use at a future point. The big problem of this approach is that when you login you effectively authenticate *an application* to access your account and not a generic login, so whilst this works well for us (we have a Moblin key and at the moment the web services integration is centralised into Mojito) this isn't a general solution (and probably violates every service's terms). http://www.wafaa.eu/index.php?/archives/206-Guide-To-Goblin-Part-2.html is a visual guide to the web service settings in Goblin (although now Twitter uses the Login button approach). We're looking at extending this in the future so that you can login to multiple applications for each service from one UI, but at this point the UI starts to look a bit pants... Something like this wouldn't be unusual: Flickr - Postr [login] - F-Spot [login] - Mojito [login] Twitter - Mojito [login] - Gwibber [login] Last.fm - Mojito [login] - Rhythmbox [login] Anyway, if anyone wants to see what we're doing to solve this, have a look at the mojito (social data aggregator) and bisho (web services settings UI) modules on git.moblin.org. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Tracker, Zeitgeist, Couchdb...where is the problem ?
On Wed, 2009-08-19 at 11:23 -0400, Jamie McCracken wrote: > i also think there is some mileage in using couchdb as the primary store > and just have tracker index that. one of the strengths of couchdb is its > mvcc architecture which means its completely corruption proof as updates > are always appended to the db and therefore cannot cause corruption of > existing data. that in itself makes it an excellent storage medium and > with all querying left to tracker and sqlite you can get the best of > both As couchdb only appends, would it be trivial to layer CouchDB on top of a VCS such as Monotone to get historical data for free? I can't think of any use-cases for this straight away but I'm sure someone can. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Signalling when the desktop is loaded
On Wed, 2009-08-12 at 14:57 +0100, Emmanuele Bassi wrote: > Neil, have you seen bug 579574? I left a comment on bug 541262 but I > wanted to mention it here as well: Moblin uses Nautilus to handle > automounting but we don't use it to draw the desktop as well, since... > well, we don't have a "desktop" but a neutral background. Actually Moblin uses a gnome-settings-daemon to do automounting. At the moment it just mounts and then spawns Nautilus, but extending that to do autorun and so on shouldn't be too hard (mostly taking code from nautilus). #585545 has our patches to g-s-d. The latest suggestion is to split out nautilus's automount code as a g-s-d module but keep it in the nautilus source tree. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: GNOME 3 cleanup status update
On Wed, 2009-07-29 at 20:50 +0200, Andre Klapper wrote: > * We have gconf-dbus in the Mobile set, but it looks dead, plus > gconf itself has much better stats. So is this officially > dead? I've a repo on github[1] which has started merging all of the recent changes to GConf, with the aim of making it equivalent to the current GConf. This isn't quite complete but it's been making good progress. If I were braver I'd propose swapping gconf for gconf-dbus as part of GNOME 3, for apps which don't switch to GSettings. Ross [1] g...@github.com:rossburton/gconf-dbus.git -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: GNOME 3 cleanup and .gnome2* directories
On Fri, 2009-07-03 at 08:01 +0200, Luca Ferretti wrote: > I've found this Empathy bug[1] about the usage of XDG directories. > Xavier comment is "I use XDG dirs for everything but not for storing > user data. Empathy is a GNOME program so I use ~/.gnome2 like all > other GNOME programs... I'm not against changing to ~/.local/ but I > would like to see a GNOME decision on this before. Is there a > conversation on gnome devel list about that topic?" > > So, could/should we plan to make official and complete this[2] > GnomeGoal for GNOME 3.0? I'm a big fan of migrating from .gnome2/ (or even worse, top level dot files) to .local/ .config/ and .cache/. Glib has functions to get these directories, so I'd be in favour of deprecating .gnome* for GNOME 3. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Controlling the window manager
On Mon, 2009-06-01 at 02:58 -0400, Richard wrote: > I was reading the gnome docs at the URL: > > http://library.gnome.org/devel/platform-overview/stable/window-manager.html.en > > It was explaining how applications can use the libwnck library to > control the window manager such as the placement of other windows. > Does anyone know of any tutorial about using libwnck ? Or could > someone suggest any example code or existing applications I could look > at to get a feel of how to control the gnome window manager. Devilspie uses libwnck to control various window properties. http://git.gnome.org/cgit/devilspie Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Platform
On Thu, 2009-05-21 at 11:36 +, Matej Cepl wrote: > Stefan Kost, Mon, 18 May 2009 22:39:21 +0300: > > Now that apple has closed the whole bonjour stack, I would prefer to > > build on upnp. We have gupnp, which is actively developed and fitting > > nicely here. > > a) Nothing can be more closed than closed ... which Microsoft's UPNP IIRC. IIRC, UPnP is as closed as Zeroconf: not at all. Both are implementatations of open specifications. Unless someone can produce pantents there is no reason to consider either protocols closed. > b) UPNP is known security threat and the only sensible advice to anybody > caring a bit about security is to switch it off (on Windows, don't know > the situation on Linux). Well, it's a security threat if you use it for things which should be secure. Don't. (this means turning off upnp on your router if you care about this). Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Platform
On Mon, 2009-05-18 at 22:39 +0300, Stefan Kost wrote: > Now that apple has closed the whole bonjour stack, I would prefer to build on > upnp. We have gupnp, which is actively developed and fitting nicely here. I'm very curious as to what this "closing" of the bonjour stack is: even if they closed their Bonjour implementation the specifications are public (interestingly the Internet Draft expired yesterday): http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt Whilst I'm a maintainer of GUPnP and think it's the best solution we have for interoperating with other UPnP devices (of which they are many in the wild), I really do think it's an ugly specification which hasn't had any recent development. I also notice that Windows Vista includes something I've forgotten the name of which they basically call the successor to UPnP... The two technologies are pretty different. mDNS gives you name resolution and by extension (via cunning use of DNS) service lookups, i.e. "what printers are here". At this point it stops caring and you use application-specific protocols: XMPP for link-local chat, IPP/HTTP for printing, and so on. Generally mDNS is used to announce an existing service, such as the location of an existing IPP print queue, or SSH server, or HTTP server. Because mDNS doesn't care what you do after discovery, security is not it's problem. UPnP doesn't do name resolution, but does do service discovery. Introspection of services and invocation of remote method calls is also part of UPnP, invocation is done via everyone's favorite RPC protocol, SOAP. The UPnP specifications cover a large number of services (internet gateway devices, media servers, scanners, printers, security cameras, lighting and so on) but I've only ever seen IGDs and media servers in the wild. Security is non-existent, any process (including Flash in a web page) can make UPnP calls and (say) open ports on your router. Personally speaking, if you want to do basic service announcement/discovery and you already have a good protocol which works (say HTTP or XMPP) then I'd recommend starting with mDNS. If you want to interoperate with existing devices (such as routers and media servers) then using UPnP is the only solution, because I don't know of a mDNS equivalent for the IGD magic and Apple are working very hard at stopping you from using DAAP/DPAP on a Mac. This mail turned out to be a bit longer and rambling than I was hoping, but the executive summary is this: at present, both are required, depending on the situation. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: krb5-auth-dialog propsal
On Wed, 2009-05-13 at 15:20 +0100, Philip Withnall wrote: > Surely programmer errors should be protected against with g_assert() and > friends? g_return_*, please, but lets not turn this into a flame about how best to handle programmer errors. The one thing we can all agree on I hope is that strings which indicate programmer errors shouldn't be translated. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: 'social desktop'/open collaboration project?
On Sun, 2009-05-10 at 09:18 -0400, Luis Villa wrote: > I've not seen anyone here talking about this: > http://www.freedesktop.org/wiki/Specifications/open-collaboration-services > (discussed here: > http://dot.kde.org/2009/05/01/social-desktop-starts-arrive ) Has > anyone from GNOME talked with them/looked at this/etc.? I should also point out that if you want your application to have social web integration, have a look at Mojito: http://moblin.org/projects/mojito It's basically a D-Bus service which reads "stuff" from your social web (currently supported: flickr, twitter, lastfm, myspace) and exposes the content in a generic manner over D-Bus with live updates. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: 'social desktop'/open collaboration project?
On Sun, 2009-05-10 at 09:18 -0400, Luis Villa wrote: > I've not seen anyone here talking about this: > http://www.freedesktop.org/wiki/Specifications/open-collaboration-services > (discussed here: > http://dot.kde.org/2009/05/01/social-desktop-starts-arrive ) Has > anyone from GNOME talked with them/looked at this/etc.? From a quick glance it's almost but not quite the same as OpenSocial but with the only implementation being opendesktop.org (which is basically a cross-desktop theme+app index). Looks like a hell of a lot of wheels got reinvented just to add a "new applications" plasmoid to KDE. Of course if you think that having "people near you with this printer" in the printer configuration UI is a good thing then you may disagree with me. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: fast-forward only policy
On Wed, 2009-05-06 at 23:15 +0300, Felipe Contreras wrote: > Are you going to argue that this branch is desirable to keep alive for > all eternity? > http://git.gnome.org/cgit/gedit/log/?h=CORBA_ENABLED I think most reasonable people will say that there is a difference between branches which were used for development forks and have been merged (such as this, "feature branches" in git), and maintenance branches such as gnome-2-26. Feature branches which have been merged can and probably should be killed from the repository unless there is a reason to keep them, but long term maintenance branches should be preserved. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: fast-forward only policy
On Wed, 2009-05-06 at 12:27 +0200, Vincent Untz wrote: > Le mercredi 06 mai 2009, à 02:21 +0300, Felipe Contreras a écrit : > > Debian patches are debian patches, they control them, and they make > > debian releases. If GNOME decides to remove those commits the > > distributions will not loose their patches. > > I think this summarize well the whole thing: we do not want to remove > commits. Agreed. All the way through this thread I've been wondering what possible reason there would be for throwing away a commit on a historical branch. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Adding module descriptions
On Fri, 2009-04-17 at 16:38 +0200, Patryk Zawadzki wrote: > I'd love to see an extension that lets you also list build- and > runtime dependencies per release so I don't have to constantly re-read > configure.am in vim every time a package is updated ;) No, you'd have to re-read the DOAP file instead... I don't really see what the gain here is considering the extra effort the maintainers would have to put into keeping the DOAP in sync with configure.ac. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Adding module descriptions
On Fri, 2009-04-17 at 10:21 +0100, John Carr wrote: > I think its a post push hook to poke the git module settings and wasnt > run as part of the import. Sounds reasonable. Editing the file and pushing updated the site. Next I tried to clean up the tags in devilspie: $ git push --tags Total 0 (delta 0), reused 0 (delta 0) --- You are trying to push the lightweight tag '0.20-tag'. You should use a signed tag instead. See: http://live.gnome.org/Git/Help/LightweightTags That URL on live.gnome.org doesn't exist. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Adding module descriptions
On Thu, 2009-04-16 at 16:58 -0400, Owen Taylor wrote: > The great migration to git.gnome.org is now underway. Once your module > shows up on http://git.gnome.org/cgit/, you'll notice that it is > described as: > > Unnamed repository; edit this file to name it for gitweb. > > Since you want something better than that, what you are going to do to > fix is add a file in the toplevel of your module named: > > .doap Devil's Pie already had a DOAP file: http://git.gnome.org/cgit/devilspie/tree/devilspie.doap But I still see "unnamed repository" :/ Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: dconf
On Thu, 2009-04-02 at 11:37 -0400, Ryan Lortie wrote: > 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. Is a GConf compatibility layer possible, or are there too many semantic differences? Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, 2009-04-02 at 14:26 +0100, Alberto Ruiz wrote: > Well, at this point we have someone willing to write a piece of > software with loads of benefits and some code available over GConf and > none volunteering on doing the merge. Unless you are volunteering > yourself :-) Actually, looking at the state of gconf vs gconf-dbus was on my todo list. But if dconf is more than vapourware then I'm all for deprecating gconf! Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, 2009-04-02 at 13:41 +0100, Alberto Ruiz wrote: > My understanding on this after talking with Richard Hult, is that > there is no GConf maintainer, and the DBus port is a huge hack and not > really suitable for the main branch, and that a proper merge would > need a lot of work. There being no GConf maintainer makes this easy for a suitably willing person to do the merge. I prefer the phrasing "needs cleaning up" to "a huge hack" myself though. :) Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, 2009-04-02 at 13:20 +0200, Andre Klapper wrote: > * Still to discuss: dconf vs gconf. This is not yet covered by > this plan, but crucial to discuss (as gconf depends on > Bonobo) There is gconf-dbus, the long-standing port of GConf to DBus that Imendio did for Maemo. Moblin also ships it and it shouldn't be *too* difficult to merge it back[1]. Ross [1] I may regret saying this -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Metacity, Mutter, GNOME Shell, GNOME-2.28
On Tue, 2009-03-24 at 19:42 +0100, Xavier Bestel wrote: > Eh, for now compiz is working and is the reference WM for linux (and > more) Interesting point of view. I thought that the reference window manager for GNOME was Metacity, what with it being the only window manager which is in the GNOME release. Linux, being a kernel, doesn't have a reference window manager. If you are talking about X I believe the reference window manager is twm. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: RSS engine
On Wed, 2009-01-28 at 10:23 +0100, Cosimo Cecchi wrote: > There's also a GObject-based RSS parser [1] that could help with your > project. I never used it myself, but it looks quite nice. > > [1] http://github.com/chergert/rss-glib/wikis As someone who tried using rss-glib before, the problem with it is that it is a wrapper around libmrss which fails to parse Atom correctly. Planet feeds contain multiple s but libmrss simply takes the first (or was it last, I can't recall) link, which isn't at all useful. feedparser ftw. It does mean using Python, but it is an excellent feed parser. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Pleasantness [was: Re: Sound effects]
On Wed, 2009-01-07 at 20:31 +0200, Natan Yellin wrote: > It's probably best _not_ to handle that in a UI. What's the point in > "automatic" context detection if you need to set a huge list of > settings first? One of the many use cases for Shackleton is "when I'm in the office, set my default printer to foo" or "when I'm at home, mount my NAS". If you can come up with a UI-free solution for doing this then I'm all ears. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Pleasantness [was: Re: Sound effects]
On Wed, 2009-01-07 at 17:24 +, Calum Benson wrote: > > On Fri, 2008-12-12 at 19:08 +0100, Patryk Zawadzki wrote: > >> Then we can build on top of that to provide locations so you can > >> switch the usage profile, the proxy configuration, VPN settings and > >> other stuff basing on where you sit (and get bonus points for > >> detecting locations basing on stuff like current wireless network). > >> Anyway that's a whole different story and does not belong in this > >> thread. > > > > This sounds a lot like Marco Polo for MacOS, which I started cloning > > as > > Shackleton (http://burtonini.com/bzr/shackleton/). > > And FWIW, it's also what NWAM does (well, will do shortly) in > OpenSolaris. > <http://opensolaris.org/os/project/nwam/p1spec/Location_Spec/> Interesting. Is this going to be open source? Note that Shackleton is more than network location, contexts can be keyed on: day of week, time of day, wireless network, gconf key, power source, mounted volumes, connected devices, machines on the local network or bluetooth devices in range. This does make a UI somewhat tricky to write though. :) Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Pleasantness [was: Re: Sound effects]
On Sat, 2008-12-13 at 20:15 +0200, natan yellin wrote: > This sounds a lot like Marco Polo for MacOS, which I started > cloning as > Shackleton (http://burtonini.com/bzr/shackleton/). > Thats very neat. Is there a project website or mailing list yet? No, it only just works at present and doesn't have any users. :) Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Pleasantness [was: Re: Sound effects]
On Fri, 2008-12-12 at 19:08 +0100, Patryk Zawadzki wrote: > Then we can build on top of that to provide locations so you can > switch the usage profile, the proxy configuration, VPN settings and > other stuff basing on where you sit (and get bonus points for > detecting locations basing on stuff like current wireless network). > Anyway that's a whole different story and does not belong in this > thread. This sounds a lot like Marco Polo for MacOS, which I started cloning as Shackleton (http://burtonini.com/bzr/shackleton/). Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: Sound effects
On Fri, 2008-12-12 at 11:33 +, Iain * wrote: > [1]http://c.skype.com/i/legacy/images/soundsetup/macosx_sound_pref.png > (Actually, I have no idea how up to date this is) Fairly up to date, Apple arguably made it worse in Leopard: http://burtonini.com/temp/leopard-sound.png Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
On Fri, 2008-12-12 at 02:00 +, Iain wrote: > Some thoughts on sounds. [snip] Hear hear. I turned off sounds in GNOME when I first started using it because hearing six clicks when I change a radio button was somewhat irritating. I understand the recent work has worked towards solving this but 125 event sounds is 124 too many. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com 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: External dependencies, DeviceKit-power and GNOME Power Manager
On Tue, 2008-11-25 at 17:43 +0100, Josselin Mouette wrote: > Le mardi 25 novembre 2008 à 10:47 -0500, Joe Marcus Clarke a écrit : > > At some point, we will catch up. However, it would be better if we > > could have a transition period where both the new and legacy > > technologies work together to allow us to stay current, and give us the > > extra time to port the new modules. > > And don’t forget the Hurd! They haven’t ported HAL yet, and now there is > need for another layer! Clearly the solution here is Solid[1]. Ross [1] http://solid.kde.org/ -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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 module proposal for GNOME 2.26: evolution-mapi
On Thu, 2008-11-20 at 17:34 +0530, Srinivasa Ragavan wrote: > > Is there anything that the new one does that the old one doesn't do? > > > > The new one can do much more, but we haven't done much of that stuff. > NSPI based GAL is a big thing. Kerberos/Smartcard authentication support > should be much easier to do. Push email is possible now. But yeah, all > these are yet to be implemented. We are now pretty much focusing on > stability/performance, feature parity with the old provider. But these > should be on the cards anytime, once we are in some good shape. It also works with the current Exchange version, where the old code doesn't. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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 module proposal for GNOME 2.26: Libgda
On Mon, 2008-11-17 at 11:56 +0100, Vivien Malerba wrote: > I would like to propose Libgda as a new external dependency for GNOME > 2.26. Shouldn't something in the Desktop suite use, or be proposing to use, libgda first? Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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: gtk-doc doesn't handle multiple tags
On Sun, 2008-10-26 at 22:18 +0100, BJörn Lindqvist wrote: > I have gtk-doc documentation with an SGML structure like this: > > > blah > ... > bla bla > ... > > > This used to generate HTML like this: > > blah > ... > bla bla > ... > > But gtk-doc doesn't seem to do that anymore. It only generates a > tag for the first tag and suppresses the other tags > which makes me sad. Is it a bug in gtk-doc or something? That was a bug in gtk-doc. See http://www.docbook.org/tdg/en/html/refsect1.html, a refsect1 can only have a single title. What you want is a refsect1 with multiple child sections. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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: libproxy as external dependency
On Fri, 2008-10-24 at 11:09 +0100, Rui Tiago Cação Matos wrote: > In this specific library case, since the API is so simple and you > don't know you need it until you somehow check your app's settings > it's a no-brainer really. You could lazy-load the library when you need to access a URL, but the point is that your app shouldn't have to know how to handle proxies or check settings: it just asks the library to handle them. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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: libproxy as external dependency
On Tue, 2008-10-21 at 10:30 -0400, Nathaniel McCallum wrote: > I'd like to propose libproxy (LGPL 2.1+; > http://code.google.com/p/libproxy/) as a blessed external dependency for > GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and > webkit are considering adopting it. I'd happily use this in both Sound Juicer and Postr. libproxy has Python, Java, and C# bindings, so I'm very much a +1. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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: Idea about creation of a new app for launching remote apps using ssh
On Thu, 2008-09-18 at 18:38 +0200, Pacho Ramos wrote: > I need them, if I skip 1 and 3 I get: > > $ xterm > xterm Xt error: Can't open display: > xterm: DISPLAY is not set (using localhost as my other linux machines are packed up at the moment) $ ssh -X [EMAIL PROTECTED] [EMAIL PROTECTED]'s password: Last login: Thu Sep 18 17:26:02 2008 from localhost blackadder:~# echo $DISPLAY localhost:10.0 localhost:10.0 is an X tunnel created by ssh. You probably don't have xauth installed on the remote machine. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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: Idea about creation of a new app for launching remote apps using ssh
On Thu, 2008-09-18 at 18:14 +0200, Pacho Ramos wrote: > Now, I usually run remote apps doing the following: > 1. I run "xhost + `remote ip`" > 2. "ssh -X `remote ip`" > 3. "export DISPLAY="`local ip`:0.0" > 4. And I run remote app Do you realise that steps 1 and 3 are not required, because you enabled X tunnelling in step 2? Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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
Sound Juicer branched
SJ is branched for GNOME 2.24. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://burtonini.com 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