Re: Kiosk mode

[Marco Pesenti Gritti <marco gnome org>]

> > > enable_toolbar_editing
> > > default: true
> > > Usage: If false the user will not be able to edit the toolbars.  I would
> > > prefer not to have this key and simply have the ability to lock down the
> > > tree of gconf keys for toolbars and have epiphany notice that said tree
> > > is locked down, but I'm not sure if that's possible.  This would cause
> > > all menus involved in toolbar editing to disappear.
> > Why not simply immutable_ui, which disables tb editing as well as chrome
> > changes from js?
> 
> Well, firstly chrome changes from js are a separate issue, as someone
> brought up.  I'd be fine with immutable_ui for this.  I see this as
> separate from disabling toolbar editing.
> > > enable_menus
> > Why? There are useful things in the menus even when locked down, like
> > changing page encoding. Also I think menus/menu items/dialog elements
> > should _never_ disappear, but simply made insensitive when the
> > corresponding action is unavailable. The user may use Epiphany also in
> > other environments where no or different lockdown prefs are applied, and
> > nothing is more frustrating for users than knowing where sth is in the
> > menus but having it disappear...

Maybe a list key for defining the default chrome and a boolean one to
ignore js settings ?

> > > enable_arbitrary_url
> > > default: true
> > > Usage: If false, the user would not be able to browse to an arbitrary
> > > URL.  This would include making the location bar disappear and disabling
> > > C-l.
> > The location bar is also there for the user to _see_ where he is, why do
> > you want to take that away? Also, how is this differentiated from
> > allow/deny_url?
> 
> For a kiosk this makes total sense.  The difference between this and
> allow/deny_url is that in this case the user doesn't even have UI for
> typing in a URL.

This could give some conflicts with toolbar editing. Considering that
the same result can be achieved providing a custom toolbar
configuration, do we need a gconf key ?

> > > enable_navigation
> > > default: false
> > > Usage: If false, no navigation other than clicking on links would be
> > > allowed.
> 
> I added this because of some notes about Privacy in the bug about kiosk
> mode.  They said one of the things they wanted was the ability to turn
> off back/forward, for instance, so as to not be able to see what a
> previous user was browsing.
> > > Ideally, these should all be active keys.  If they change, then the UI
> > > should immediately change.  This is important so someone setting up
> > > their kiosk wouldn't have to keep restarting epiphany.  Not sure how
> > > difficult that would be for some of them.
> > Not worth it IMHO.
> 
> For me it would depend on which key and how much work.  When it's a huge
> amount of work, I agree it's not worth it, but when we can, it'd be cool
> if we made it work.  Not super attached to this.

Well I guess the two cases would look more or less like this:

if (pref1_set)
{
...
}
else if (pref2_set)
{
...
}

---------------------

pref1_notifier
{
}

pref2_notifier
{
}


on startup you attach the listeners and call all notifiers.

In the notifier case you will be forced to show menus also if they are
already visible.
If we have a lot of keys it's possible that the kiosk stuff will affect
perf on startup a bit in both cases.

> > > Not a key, but we should add a reset session command.  Probably in a
> > > menu and also available as a toolbar button.  The sysadmin could then
> > > set up reset session in their toolbar.
> > Yes.
> > 
> > ----
> > 
> > You completely forgot the user's privacy: In a shared environment, we
> > need to not save passwords, disable cookies or re-set their lifetime to
> > a short time (~1h), not persist history, make history items lifetime
> > short too, make it a 1-click operation for the user to clean out all his
> > trails.
> 
> Ah, this is why I put reset session there.  But you make good points
> about that reseting history and trails and cookies and so forth.

Christian, is there mozilla api for this ?

In general I think we should consider the idea of reusing the Action
stuff instead of single gconf keys to disable menus.
See
http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg00184.html, first item.
I see the value of having groups like save, esp at system level, but for
single keys I think using actions is the way to go. (less mainteinance
required, no slow down on startup etc...).

Marco