Gnome-shell has limitations (like all desktop environments) and these
limitations can be covered with extensions which, among other things,
causes this desktop environment is a good choice. But after 4 years it
seems incredible that there isn't yet complete and updated documentation
about the Gnome libraries available for javascript: Is really this page (
https://wiki.gnome.org/Projects/GnomeShell/Extensions) the best
documentation available?
This search shows nothing about extensions development:
https://developer.gnome.org/search?q=extensions
The native tools to obtain such documentation doesn't even work:
$ g-ir-generate /usr/lib/gnome-shell/St-1.0.typelib > st.gir
$ g-ir-doc-tool --language gjs st.gir -o st
st.gir: Incompatible version 1.0 (supported: 1.2)
I edit the generated .gir file and change to version 1.2 in this line:
<repository version="1.0"> but:
$ g-ir-doc-tool --language gjs st.gir -o st
Caught exception: <type 'exceptions.TypeError'> TypeError("'NoneType'
object has no attribute '__getitem__'",)
>
/usr/lib/gobject-introspection/giscanner/docwriter.py(826)field_is_writable()
-> if isinstance(resolved, ast.Compound) and node.type.ctype[-1] != '*':
.....
There isn't documentation and I can't generate it... :-(
--------------------
Regarding the disabling of the extensions when the session is idle. I don't
find any logical reason for this. This complicates the programming of
extensions and limits their functionality.
Regards.
2016-03-17 21:16 GMT+01:00 Jasper St. Pierre <jstpie...@mecheye.net>:
> The main reason wasn't actually security -- an extension can simply
> have a dummy disable() function if it wants. The main reason was that
> a lot of the extensions simply weren't designed for the lock screen in
> mind. The initial set of extensions that were uploaded were things
> like a new Apps Menu, or a Bottom Panel, or a custom status icon and
> top bar button.
>
> These extensions didn't handle the case when the screen was locked,
> and exposing the top bar button during that time would have been a
> major information leak. It also seems like an easy thing to miss as an
> extension author, so I didn't want to risk it.
>
> It might be possible to extend the extension metadata format to
> support a new "handlesLockScreen" key and not turn it off when that
> happens.
>
> On Thu, Mar 17, 2016 at 12:56 PM, Jay Strict <jay.str...@posteo.de> wrote:
> > On 17.03.2016 16:04, Emmanuele Bassi wrote:
> >>> But the worst is that it was a futile effort because when the screen is
> >>> idle, gnome-shell disables the extensions. Why?
> >>
> >> It's a security measure.
> >
> > Hmm, is that so?
> >
> >
> >> Since an extension can do whatever it wants with the UI, it can also
> >> read the user's credentials from the session unlock screen;
> >> alternatively, it could take over the whole thing, and impersonate the
> >> user.
> >
> > Since an extension can do whatever it wants with the UI, it can also
> > simulate a fake session unlock screen and read the user's credentials
> > from there;
> > alternatively, it does not need to take over the user's session, because
> > it already runs as the user's UID and can spawn new processes as the
> > user with GLib.spawn_async().
> >
> >
> > There may be sound arguments for disabling extensions on session lock,
> > but I doubt that those reasons are security. But maybe I am missing a
> > point here?
> >
> >
> > Kind regards,
> > Jay
> > _______________________________________________
> > gnome-shell-list mailing list
> > gnome-shell-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
>
> --
> Jasper
>
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
