[racket-dev] while resizing drawing into a canvas is off

On Fri, Oct 21, 2011 at 3:55 AM, Marijn <hkBst at gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 10/20/11 20:30, Robby Findler wrote:
>> On Thu, Oct 20, 2011 at 11:34 AM, Marijn <hkBst at gentoo.org> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> Hi Robby,
>>>
>>> On 10/20/11 18:15, Robby Findler wrote:
>>>> Generally, the <menukey>-c, <menukey>-v, keybindings (and
>>>> friends) come about via the menus, not via a keymap% object.
>>>> And those menus come in via a frame. I'm not sure how you're
>>>> using your library, but you might want to consider some of the
>>>> mixins in the framework whose names start with "frame:".
>>>
>>> I'm actually trying to create something spreadsheet-like. I'm
>>> using editors to manage(display/edit) cell contents. Although
>>> each cell(-editor) individually doesn't have a menu, when used in
>>> a complete application there probably will be menus, and I'm
>>> planning to check out what the framework provides.
>>>
>>> However, I don't understand the logic of menus that bring about
>>> key bindings for editors.
>>
>> I'm not sure how to respond here, except to say that that's what
>> the GUI designers of the world seem to have come up with. The
>> keybindings that you asked for earlier (control-c and control-v for
>> copy and paste under windows, for example (command-c and command-v
>> on the mac)) are there because they are shortcuts for menu items,
>> not because they are keybindings at the level of the editor.
>
> So you're saying this is something that is inherited from Gtk and the
> Windows and OSX graphics layers?

Roughly, yes.

You can, of course, make keybindings (via a keymap%) that would cover
standard bindings such as these, but it would be confusing to users of
your library (assuming you package this up as a library) and you'd be
duplicating a bunch of code.

Robby