Re: Proposal: Replace all references to master/slave in GNOME modules

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

On 11 October 2013 10:21, David Woodhouse dw...@infradead.org 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?

[Ross Burton]

On 4 April 2013 16:04, Ma Xiaojun damage3...@gmail.com wrote:

 On Thu, Apr 4, 2013 at 11:01 PM, Debarshi Ray rishi...@lostca.se 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

[Ross Burton]

On 18 March 2013 05:10, Martyn Russell mar...@lanedo.com 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: Porting GNOME to Wayland

[Ross Burton]

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: Preserved Window Placement

[Ross Burton]

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: Preserved Window Placement

[Ross Burton]

On 24 October 2012 14:28, Jason Simanek jsima...@gmail.com 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: Feature Proposal: finding and rediscovering shared links

[Ross Burton]

 http://getpocket.com

 Or Instapaper.

Instapaper.  I'm having to explain to the pocket engineer that this
isn't a valid XML document:

?xml version=1.0?
user.../user
list.../list

:/

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

[Ross Burton]

On 27 April 2012 05:51, Jasper St. Pierre jstpie...@mecheye.net 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

[Ross Burton]

On 1 March 2012 10:07, Marco net...@lavabit.com 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

[Ross Burton]

On 20 January 2012 12:25, Maciej Marcin Piechotka uzytkown...@gmail.com 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?

[Ross Burton]

On 23 September 2011 08:40, Olav Vitters o...@vitters.nl 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: Using Bugzilla for freeze break requests?

[Ross Burton]

On 23 September 2011 10:58, Olav Vitters o...@vitters.nl 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: Use of maintainer mode in GNOME modules

[Ross Burton]

On 14 September 2011 08:19, Milan Crha mc...@redhat.com 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: Use of maintainer mode in GNOME modules

[Ross Burton]

On 14 September 2011 11:43, Milan Crha mc...@redhat.com 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: Full screen color management

[Ross Burton]

On 6 September 2011 12:26, Richard Hughes hughsi...@gmail.com 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

Enabling GConf-over-DBus in GNOME 3.2 jhbuild

[Ross Burton]

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: Enabling GConf-over-DBus in GNOME 3.2 jhbuild

[Ross Burton]

On Wednesday, 20 July 2011 at 19:41, Colin Walters wrote:
 On Wed, Jul 20, 2011 at 2:14 PM, Ross Burton r...@burtonini.com 
 (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

Re: Enabling GConf-over-DBus in GNOME 3.2 jhbuild

[Ross Burton]

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: GConf port to DBus

[Ross Burton]

On 29 June 2011 18:20, Emmanuele Bassi eba...@gmail.com 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

Re: GConf port to DBus

[Ross Burton]

On 1 July 2011 13:44, Matthias Clasen matthias.cla...@gmail.com wrote:
 On Fri, Jul 1, 2011 at 7:02 AM, Ross Burton r...@burtonini.com wrote:
 On 29 June 2011 18:20, Emmanuele Bassi eba...@gmail.com 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

[Ross Burton]

On 1 July 2011 13:56, Ross Burton r...@burtonini.com 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

[Ross Burton]

On 1 July 2011 14:29, Andre Klapper ak...@gmx.net wrote:
 On Fri, 2011-07-01 at 14:17 +0100, Ross Burton wrote:
 On 1 July 2011 13:56, Ross Burton r...@burtonini.com 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

[Ross Burton]

On 1 July 2011 14:24, Matthias Clasen matthias.cla...@gmail.com 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

[Ross Burton]

On 1 July 2011 15:41, Vincent Untz vu...@gnome.org wrote:
 Le vendredi 01 juillet 2011, à 14:17 +0100, Ross Burton a écrit :
 On 1 July 2011 13:56, Ross Burton r...@burtonini.com 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

GConf port to DBus

[Ross Burton]

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 ??

[Ross Burton]

2011/6/1 Erick Pérez erick@gmail.com:
 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

[Ross Burton]

On 18 May 2011 14:49, Josselin Mouette j...@debian.org 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 reasonably want to add]

[Ross Burton]

On 16 May 2011 18:22, Lennart Poettering mzta...@0pointer.de 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 easonably want to add]

[Ross Burton]

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]

[Ross Burton]

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: language/locale selector [was: Re: Settings downstream would reasonably want to add]

[Ross Burton]

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.)
 
 /random_rant_no_need_to_follow_up
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: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]

[Ross Burton]

On 12 May 2011 20:52, Sergey Udaltsov sergey.udalt...@gmail.com 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: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]

[Ross Burton]

On 13 May 2011 09:49, Sergey Udaltsov sergey.udalt...@gmail.com 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: Settings downstream would reasonably want to add [was: long thread with no resolution]

[Ross Burton]

On 13 May 2011 09:56, Dave Neary dne...@gnome.org 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: GNOME Feature Proposal: Backup

[Ross Burton]

On 11 May 2011 12:03, Bastien Nocera had...@hadess.net 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: GNOME Feature Proposal: Backup

[Ross Burton]

On 11 May 2011 13:24, Michael Terry m...@mterry.name 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: First release of geocode-glib available

[Ross Burton]

On 9 May 2011 17:21, Bastien Nocera had...@hadess.net 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: Online Accounts panel for 3.2

[Ross Burton]

On 27 April 2011 14:18, David Zeuthen zeut...@gmail.com 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

[Ross Burton]

On 19 April 2011 11:27, Alexander Larsson al...@redhat.com 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 patrick.o...@gmx.de.  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: ThreePointOne: Contacts

[Ross Burton]

On 19 April 2011 11:56, Tomasz Torcz to...@pipebreaker.pl 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: GNOME 2.91.1 status

[Ross Burton]

On 20 October 2010 20:29, Zeeshan Ali zee...@gmail.com 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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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: Module proposal: dconf

[Ross Burton]

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: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Ross Burton]

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)

[Ross Burton]

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?

[Ross Burton]

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: social services as a desktop service?

[Ross Burton]

On Mon, 2009-09-21 at 14:54 +0100, Bastien Nocera wrote:
 On Mon, 2009-09-21 at 13:34 +0100, Ross Burton wrote:
 snip
  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: Tracker, Zeitgeist, Couchdb...where is the problem ?

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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?

[Ross Burton]

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: 'social desktop'/open collaboration project?

[Ross Burton]

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: fast-forward only policy

[Ross Burton]

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: fast-forward only policy

[Ross Burton]

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: Adding module descriptions

[Ross Burton]

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:
 
  modulename.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: Adding module descriptions

[Ross Burton]

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

[Ross Burton]

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: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Ross Burton]

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: GNOME 3.0 Schedule draft; Streamlining of the Platform.

[Ross Burton]

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.

[Ross Burton]

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: Metacity, Mutter, GNOME Shell, GNOME-2.28

[Ross Burton]

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

[Ross Burton]

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 links 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]

[Ross Burton]

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]

[Ross Burton]

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]

[Ross Burton]

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: Pleasantness [was: Re: Sound effects]

[Ross Burton]

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: Sound effects

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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 title tags

[Ross Burton]

On Sun, 2008-10-26 at 22:18 +0100, BJörn Lindqvist wrote:
 I have gtk-doc documentation with an SGML structure like this:
 
 refsect1
   titleblah/title
   para.../para
   titlebla bla/title
   para.../para
 /refsect1
 
 This used to generate HTML like this:
 
 h2blah/h2
 p.../p
 h2bla bla/h2
 p.../p
 
 But gtk-doc doesn't seem to do that anymore. It only generates a h2
 tag for the first title tag and suppresses the other title 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

[Ross Burton]

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

[Ross Burton]

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

[Ross Burton]

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

Re: Idea about creation of a new app for launching remote apps using ssh

[Ross Burton]

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

Sound Juicer branched

[Ross Burton]

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

Re: libcanberra as an external dependency

[Ross Burton]

On Thu, 2008-08-07 at 12:25 -0400, Joe Marcus Clarke wrote:
 While esd may be considered old, it's not exotic.  It is THE sound 
 server for GNOME right now.

It is the *deprecated* sound server for GNOME.  We don't complain when
applications stop linking to libgnomeui because they can use modern
replacements, so I don't see the problem here.

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: Proposal: enable accessibility by default for GNOME

[Ross Burton]

On Thu, 2008-07-31 at 13:47 +0100, Alexander Jones wrote:
 I mean, disabled users don't just land at a PC and have to use it
 without any help. And if you operate PC's in which that is the case,
 you should just turn this on by default.

I think the point is that if the installer was accessible (say, used GTK
+ and enabled a11y by default), then a user who requires a11y *can*
install a distro and start using it without any trouble.

These users just need a11y turned on, having to get someone else to do
that is just stupid.

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: Composition [was Re: gnome-session proposal]

[Ross Burton]

On Thu, 2008-06-26 at 20:09 +0300, Karl Lattimer wrote:
  I'm assuming you've turned on the appropriate xorg configuration
  options to enable the correct acceleration
  and none of that helped? I forget what they are, but I'm sure someone
  will chime in.
 
 ching
 
 Section Extensions
   Option  Composite Enable
 EndSection

That simply turns on the Composite extension, without which the
compositor will (obviously) fail to start.

Iain is talking about options like MigrationHeuristic, AccelMethod, and
one I can't remember which controls offscreen pixmaps under XAA.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



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: Should GNOME apps support a --geometry option?

[Ross Burton]

On Wed, 2008-06-18 at 18:38 +0300, Kalle Vahlman wrote:
 2008/6/18 Matthew Barnes [EMAIL PROTECTED]:
  I think I'm correct in saying the GConf approach is preferred, but are
  there use cases for supporting a --geometry option as well?  Perhaps
  just for consistency across apps?
 
 I can't think of any reason why that couldn't be a part of gtk_init(),
 that way it'd be supported not only in GNOME but in every GTK+ app.
 After all, the ability to define initial window size can be quite
 handy for any application. Specially in scripting situations.
 
 Maybe this should be proposed on gtk-devel?

Apart from that it would be impossible to do in gtk_init because no
windows have been created of course. :)

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



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: Should GNOME apps support a --geometry option?

[Ross Burton]

On Wed, 2008-06-18 at 18:15 +0200, Patryk Zawadzki wrote:
 For one gconf won't let you store this per running instance (for
 example have 3 instances of the same app running side by side).

Neither will a key file or any other method unless you have some way of
uniquely identifying the window, and that window identifier can be used
when creating gconf keys.

Ross
-- 
Ross Burton mail: [EMAIL PROTECTED]
  jabber: [EMAIL PROTECTED]
 www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF



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