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

From: Marijn (hkBst at gentoo.org)
Date: Fri Oct 21 04:55:49 EDT 2011

-----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?

Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6hM5UACgkQp/VmCx0OL2yxQACdEN5pStXBxVEwKIZJFwpu+nvx
P84AoIap2s2eG2cm8VLLR/A/sMSc5XzQ
=O+19
-----END PGP SIGNATURE-----


Posted on the dev mailing list.