Re: Minutes of the gtk+ team IRC meeting - 2010-05-25
- From: Kristian Rietveld <kris gtk org>
- To: Emmanuele Bassi <ebassi gmail com>
- Cc: gtk-devel-list gnome org
- Subject: Re: Minutes of the gtk+ team IRC meeting - 2010-05-25
- Date: Mon, 31 May 2010 15:30:27 +0200
On May 31, 2010, at 12:37 PM, Emmanuele Bassi wrote:
> well, since I am the proposer of the removal:
>
> • TearoffMenuItem does complicate the Menu code - with the contents
> being copied inside a new GtkWindow, and the window mangled to appear as
> a menu but managed by the window manager.
Yes, there's a bunch of hooks in the gtkmenu.c needed for this to work properly as far as I know.
> • the user interaction context of having a menu floating around as a
> tool box is a clear indication of a problem in the overall user
> interaction design. I can probably ask designers to chime in here, if I
> can get them stop laughing about it.
Agreed; also one would wonder why not to use keyboard shortcuts instead.
> • and even if we remove GtkTearoffMenuItem and the tear-off support in
> gtk+, those aren't *really* gone. gtk+ 2.* will still have them, and it
> should be possible to implement a TearoffMenuItem outside of gtk+. if
> it's not possible, we should expose the API to do so.
This is the main point really -- I would say that when the main code empowering the tear off menus that's in gtkmenu.c is removed, then there's likely to be no (easy/proper) way to get this implemented outside of GTK+ for people that really cannot live without this in their applications. So it would be good to expose the API to do so as you suggested and leave any code in that's required for implementing that API. But then, in the end, doesn't the most complex/tricky code stay in GTK+ anyway?
regards,
-kris.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]