Re: How do I use global.display.add_keybinding?



I suspect that since 'Alt' on its own is not a valid keybinding for meta you might be able to just listen to the 'captured-event' signal on the global stage, and detect a keypress event with Alt. This would lose you mutter's inbuilt ability to parse the keybindings from the string in gsettings though (you'd have to parse the string yourself and match it in the captured-event signal as opposed to a convenient global.display.add_keybinding).

On 10 February 2013 16:14, Jason Heeris <jason heeris gmail com> wrote:
I've successfully set up a "hello world" style extension that responds
to a keybinding, thanks in part to the docs posted here, and also to
some code I found in the "brightness control" extension[1].

I can create a GSettings schema that has a default key for my
extension to bind, like so:

    <key type="as" name="showhw">
        <default>
            <![CDATA[['<Alt>x']]]>
        </default>
        <summary>
            The keyboard shortcut to show "Hello World"
        </summary>
    </key>

That works fine. But if I change "<Alt>x" to just "<Alt>", I get the
following message in .xsession-errors:

    Window manager warning: "<Alt>" found in configuration database is
not a valid value for keybinding "showhw"

Binding to Alt might be intrusive if unexpected, but if a user wanted
such a thing, how would it be possible?

(I can't really search the web for this, since it's a very common
error message for users to see.)

— Jason

[1] http://gitorious.org/gnome-shell-brightness-extension/gnome-shell-brightness-extension/trees/master/brightness_control lmedinas org

On 5 February 2013 10:58, Amy <mathematical coffee gmail com> wrote:
> On 5 February 2013 09:02, Jason Heeris <jason heeris gmail com> wrote:
>>
>> Alan Knowles - Thanks for that, it looks very useful.
>>
>> On 3 February 2013 21:33, Jasper St. Pierre <jstpierre mecheye net> wrote:
>> > You can find some (albiet limited) documentation for the Shell toolkit
>> > here:
>> >
>> > http://developer.gnome.org/shell/unstable/
>>
>> I notice that the docs for ShellGlobal don't specify any signals or
>> properties - is that by design (as in, they shouldn't be used) or is
>> it an accidental omission?
>>
> I don't think ShellGlobal has any signals which is why they're not
> specified.
> Most the signals are attached to objects *in* ShellGlobal. For example,
> `global.display` is a `Meta.Display` so you have to check out the Mutter
> documentation for what signals it has.
>
> As to why the properties are not specified, I'm not sure - perhaps you're
> meant to use `global.get_display()` rather than `global.display` etc??
>
> (BTW, you can do
>
>     g-ir-doc-tool /usr/lib/mutter/Meta-3.0.gir -o /path/to/some/folder
>
> to generate the documentation for mutter in that folder. Then do
>
>     yelp /path/to/that/folder
>
> to look at it in a help browser.
>
> If it complains "Couldn't find include 'XYZ.gir'", then you have to generate
> that gir via
>
>     g-ir-generate /usr/lib/girepository-1.0/XYZ.typelib >
> /usr/share/gir-1.0/XYZ.gir
>
> before running g-ir-doc-tool on Meta-3.0.gir again. At some point I had a
> plan to generate the documentation and put it somewhere online for
> convenience until the "new documentation system" is up and running, but I
> guess I forgot about it...
>
> Unfortunately g-ir-doc-tool seems to crash when I try to do the same on
> Shell-0.1.gir.)
>
>
>>
>> > Note that there is currently work on a new documentation system that can
>> > generate native JS documentation instead of C
>>
>> I eagerly await such a thing :)
>>
>> - Jason
>>
>> _______________________________________________
>> gnome-shell-list mailing list
>> gnome-shell-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]