i would like to create a reworked settings.html to experiment with the
abilities and limitations of the current webapi, but i need some hints
for the cornerstones.
background: while reading about the lxle distribution i saw they lack a
rework of the discontinued lxde control panel to have more options for
the desktop environment like changing the soundserver for example.
https://www.bountysource.com/issues/25936437-lxde-control-panel-for-all-platforms
since there are a lot of desktop environments lacking a good control
panel and i already wanted to start experimenting with xulrunner or
graphene i thought such a project would be nice for
- easier configuration in lightweight (or any) environments
- add missing configuration options (gnome's control panel for example
is intentionally stripped down for usability reasons, requiring the user
to work with several other tools too, like gnome-tweak-tool)
- testing the environment (platform, root window, window manager, etc.)
and automatically adjusting the control panel (and settings api for
other webapps) to the current configuration. having a modular system
somewhere around the gecko-hal would be great.
- having (signed) add-ons would be a great deal to extend the control
panel with more specific advanced settings – and eliminate the problem
that users often need to copy a bunch of lines of bash code into a root
terminal (which they probably don't understand)
- thinking of webvr or 3d in general, we could model virtual devices
with indicators, knobs and switches and have the design of the object
itself explain its functionality (and i totally would like to work with
webvr, btw)
- reworking the design of the webapi, where it has limitations in this issue
particularly there is one example (where i would try to start): since
many years, firefox on desktop offers the possibility to set the desktop
wallpaper via the context menu of images. this is a platform dependent
feature, which requires support by the browser vendor for the specific
operating system or desktop environment (or file manager used, in case
of lxde). having a settings architecture somehow outsourced from the
gecko-hal and modularly designed, this could cover an indefinite number
of platforms and desktop environments (at least if someone writes an
add-on implementing a settings engine for this). any webapp would then
be able to access settings of the users environment, without maintaining
all of the specifics inside mozilla's codebase.
thinking of uncountable other configuration options, many of them only
available to certain platforms, it is unlikely to cover them all
individually within the webapi. maintaining a single huge permissions
table for all possible configurations probably is also not desired. a
settings engine could bundle a set of structured keywords for an
environment with a corresponding permission table.
e.g. "appeareance.desktop.wallpaper.position" (which is fine for
desktops but not an option on android)
another example: webapps should be able to access the network
configuration, be it settings.html or any third-party app. when a user
on linux has wicd instead of network-manager, some webapps may break.
but, because we want to use webstandards for a reason, no one should be
required to use gonk for that particular app to work (unless, of course,
the user's platform does not support that feature). so, if the stock
settings engine does not know about how to talk with wicd, an add-on
(being shipped with wicd or via marketplace) may do the job.
for the practical part i am still uncertain about the implementation.
thinking of lxle, which ships seamonkey by default, i would reuse its
gecko-runtime, but it has no -app switch like firefox. on the other hand
it (or a build target of it) should still work as settings.html
replacement on b2g.
are there reasons to require graphene?
can someone point me to the right direction? i would like to minimize
the compatibility issues between seamonkey, firefox and b2g. are there
any examples how to maintain a webapp that work on these targets
(without needing any xul)?
greetings, stefan.
_______________________________________________
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
