[Geany-devel] Resetting menu accels - Re: Super modifier in keybindings - Re: Strange Geany behavior

[Lex Trotman]

2009/8/16 Enrico Tröger <enrico.troeger at uvena.de>:
> On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote:
>
>
>>but I think the following should make it into a menu (actually a
>>submenu, since I don't think they are commonly used enough to go in a
>>top level menu) and I have suggested which new submenu to put them in.
>>
>>Ctrl-K          delete current line       popup-edit
>>Ctrl-T          transpose current line    popup-edit
>>Ctrl-Shift-X    cut line                  popup-edit
>>Ctrl-Shift-C    copy line                 popup-edit
>>Alt-Shift-W     select word               edit-select and popup-select
>>Alt-Shift-P     select para               edit-select and popup-select
>>Alt-Shift-L     select line               edit-select and popup-select
>>               insert alt whitspace      popup-edit
>>               indent space              popup-indent
>>               undent space              popup-indent
>>               prev indent               popup-indent
>>Ctrl-B          matching brace            edit-goto  popup-goto
>>Ctrl-M          toggle marker             edit-goto  popup-goto
>>Ctrl-.          next marker                  "          "
>>Ctrl-,          prev marker                  "          "
>
> Cool, thanks for this list.

Note that this is only for 0.17, I'm not sure how many more 0.18 will add.

> However, I fail to make any sense of the third column. Could you give
> some hint about what exactly "popup-edit", "popup-select" and the others
> mean? Thanks.
>

My apologies, I was trying to suggest adding a new submenu of either
the edit menu or the right click popup menu, so the third column
legend is:

popup-edit means new edit submenu of right click popup
popup-indent means new indent submenu of right click popup
popup-goto means a new goto submenu of right click  popup
edit-select means a new select submenu of the main edit menu
edit-goto means a new goto submenu of the main edit menu

Where more than one is listed on the same line I am suggesting putting
the item in both.
I was running out of time at the end so the quote marks mean "as above"

>
>>We better be careful, this could spark another GUI discussion ;-)
>
> I guess it's already too late, haha.
>
>
>>I have been toying with the idea of adding a simple action
>>recorder/replayer by recording key presses (in on_key_press_event
>
> Maybe it's best to try realising this as a plugin from the beginning.
> There are certainly things missing in the API right now but missing
> bits could be added.
> As a plugin, your new code wouldn't affect the core, so reduces the
> risk of serious bugs (keybinding management is somewhat essential for
> an editor :D) and keeps independent.

Yeah sure.

>
>
>>function) and capturing menu activations by a signal emission hook on
>>the activate signal.
>
> How do you mean that? Do you want to connect to the activate signal of
> each single menu item? Maybe this can be avoided by connecting to the
> "button-press-event" or maybe better "button-release-event" of the main
> window ('main_widgets.window') and inside the handler determine which
> widget actually was activated. Not completely sure whether this will
> work but I think so. This way you don't need to modify any or at least
> not much code in Geany itself. Just an idea.

I thought about just recording keypresses, thats simple, but means the
user can only record things that have keypress shortcuts and they have
to use the keypress.

I don't think that it is necessary to explicitly connect to each
widget's activate, I havn't tried it yet, but
g_signal_add_emission_hook claims to add one handler to catch all
signals of a specified type, (ie "activate") to a specified *type* of
widget (ie menu_item), it then tells you which menu-item widget was
the target, so it could successfully be added in a plugin to monitor
the main application.  I'm not sure if it would work for keypresses
too, maybe hooking into "key-press-event" for type widget would work.
It would need trying.

Then in playback I can emit activate signals to the particular
menu-item widgets or key-press event signals so I don't care how they
are processed in Geany.

The problem would be if a user key-press emitted an activate signal on
a menu-item I would see it twice :-P  hence the question below.  Since
that is the case, it is going to be very messy trying to "know" which
are repeated so they can be ignored.

This is just me thinking out loud ...
In general the handlers don't know that they are activated by keypress
or menu click so they can't do anything about it.  In general
key_press_event doesn't know that the closure it calls for a key
sequence is going to emit an activate signal so it can't do anything
about it.
If every key press was processed by GTK's accelerator code then a
signal is always emitted and can be recorded.  Mostly then the handler
would not need to issue another signal, but if it did, it would know
to tell the recorder that it was not to be recorded (how? merely an
implementation detail ;-).   Those key sequences that are not
associated with a menu item can have all their closures associated
with some sort of g_object that isn't visible, a widget that isn't
added to a visible parent should do, and then they can be activated by
signals like the rest.

Of course changing the internal operation of Geany keybindings makes
the whole exercise much more intrusive than just adding a plugin, but
then keybindings.c still needs to be fixed to update the menu accel
labels without having to close and re-open Geany, and that will
require some work.

Hmmmm... Maybe just recording keypresses is the way to go, at least at
first. It shouldn't need any more plugin interface so long as
emission-hooks on keypresses work, replay can just emit keypress
events & call gtk_main_iteration_do.  As I said maybe I'll try after
build-system is in the trunk.

That raises the question of what functions can't be assigned to
keypresses? AFAICT there are not many editing type actions not
available via keypress even if they may not have a default binding.
There are some settings type menu items (eg set encodings) but then
they are not likely to be used in record replays.

I don't know how likely activating other plugins during recording is
going to be or if their actions can be bound to keys?

In build-system branch some of the build commands can't be bound to
keypresses but again unlikely to be used in record/replay.

Does menu->edit->delete do any thing different to pressing the delete
key?  It isn't in the keybinding menu.

Have I missed any?


>
>
>> My question is, are there any actions that don't use one of these
>>paths, and are there any that use both, for example any key presses
>>that go to GTK and activate menus rather than call the callbacks
>>directly in on_key_press_event or any other actions that are invoked
>>directly without an activate signal?
>
> Hmm, probably :(. Some keybindings call "activate" in callbacks.c of
> the corresponding menu items, other keybindings have their own code to
> do something and some other keybindings call other Geany functions
> directly which are also called from "activate" handlers. This certainly
> can be improved and unified but so far it just worked.
> For details, just have a look in src/keybindings.c and walk through the
> various handlers.
> But in general, all key presses should go first into
> on_key_press_event(), mouse actions are not that easy to handle I think
> as described above.

Mouse events, or at least mouse clicks, are easy to catch with
emission-hooks, thats actually the example in the doc.  But for
record/replay, I don't think clicks are much use, each replay would be
to exactly the same position, but if arrow keys were used for
navigation the replay would be "relative" to the position where it
started.

My initial use-case is when I declare a class in C++ I then copy the
member function prototypes to the .cpp file to define them and have to
add qualifiers (namespace::class_name:: sequences) in several places
on each declaration.  This is boring and repetitive but not so
repetitive that search/replace can do it, but a replay could, since
the general form of the changes is "insert some text, forward a couple
of words, and insert some more text, go to end of line, backup over ;
insert \n{\n} go to start of next line" and repeat.  Now if only it
could fill in between the braces too ;-)


Thanks for your thoughts so far.

Cheers
Lex

>
>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>