Objectives for Oneiric - Brainstorming

[Shaun McCance]

On Thu, 2011-04-28 at 10:54 -0400, Kyle Nitzsche wrote:
> On 04/28/2011 10:51 AM, Shaun McCance wrote:
> > How critical is it that you be able to turn off auto-detection and
> > just set a static page instead? I could have a GSettings key for
> > that, if necessary.
> Very helpful indeed. I have explained why.

Not really. You've said that you want to support customized
versions of Ubuntu, but I don't understand what that entails
or why you think a settings key is the right way to handle it.

The point of auto-detection is that you can have one version
of Yelp installed on one computer, and it can do the right
thing for different users running different desktop sessions.

So let's say when Yelp detect Unity it loads ghelp:ubuntu-help
by default. Now you create some customization that's based on
Unity. Yelp sees Unity and defaults to that. Now, presumably,
your customization involves swapping out pieces and patching
applications and such. So if you have a separate help document
for that, why can't you just install it as ghelp:ubuntu-help?

The reason not to do this would be if you anticipate people
being able to run a stock Unity desktop parallel to the
customized experience. Then you've got conflicts. But if
that isn't the case, why not just reuse the help URI?

My concern with a settings key is that it's persistent. It's
not tied to the session at all. So somebody comes along and
creates a new desktop environment, the Really Uber Desktop
Environment ("RUDE"). They decide to use Yelp to show their
help. Yelp doesn't have auto-detection for RUDE, so they
have their session startup scripts set a Yelp settings key

/org/gnome/yelp/always-default-uri = "ghelp:rude-help"

A user tries out RUDE. The key gets set. The user goes back
to using Unity. The key is still set. The user sees the RUDE
help in Unity. Kind of rude.

You could argue that the RUDE developers are misusing the
key, but I would argue that we invited them to do so by
misusing GSettings. If there needs to be an override for
customized environments (and I'm not convinced there does),
then I would favor something stateful like an environment
variable or an XSettings property.

--
Shaun