Re: Menu in window

[Banlu Kemiyatorn]

Wonder how possible it is to replace gdk window's cairo context (or as
a separated process if we can't unify the runloops) so all drawing may
occur directly on our window instead. Still need a way to route back
the x events or simply just convert NSEvents to a gdk event or call
the drawing code directly. In the other sense may be it's cleaner and
easier (than above) to just port gdk to our x11 window and preload
that.

On Sat, Jan 8, 2011 at 11:12 PM, Gregory Casamento
<address@hidden> wrote:
> I'm wondering right now if what's not needed here is a GTK backend.
>  This would solve the problems indicated below.
>
> GC
>
> On Fri, Jan 7, 2011 at 3:12 PM, Gregory Casamento
> <address@hidden> wrote:
>> Riccardo,
>>
>> Unfortunately in order to use native GTK menus our Windows need to be
>> GtkWindow instances instead of raw XWindow instances as they are now.
>>
>> The problem with this is two fold:
>> 1) Currently the backend does not take the theme into account... that
>> is to say... there are no theme specific methods in the backend.   not
>> that these couldn't be added...  the reason this is important is that
>> it would be necesary for the backend to return a GtkWindow as
>> described above.
>> 2) Additionally, since a GTKWindow cannot become an XWindow or vice
>> versa, it would make it impossible to switch to or from the theme in a
>> manner which would make it convenient.
>>
>> So, with those two issues in mind, it's probably better to improve the
>> existing in-window menus to the point where they are acceptable under
>> GNOME.
>>
>> Later, GC
>>
>> On Fri, Jan 7, 2011 at 1:59 PM, Riccardo Mottola <address@hidden> wrote:
>>> Hi Gregory,
>>>
>>> I think that at the end we probably need native GTK menus like on windows.
>>>
>>> However in-window menus are problematic and they should work, sicne ti is a
>>> theme feature. If you have a menu which opens a modal panel and the modal
>>> panel gets over the menu the sub-menu displays "above" the panel, pretty
>>> ugly.
>>>
>>> AS far as your issue goes, I'f say it is better not to "not allow the
>>> window". If you check what GTK does, when you open a menu and subsequently
>>> try to move the window, you will discover that the first click outside the
>>> window will close the menu (implicitly not allowing to move the window).
>>> Subsequent clicks will do what intended.
>>>
>>> Riccardo
>>>
>>> Gregory Casamento wrote:
>>>>
>>>> All,
>>>>
>>>> One other issue that needs to be solved is that we should close any
>>>> open menus when the window is moved or, alternatively, stop the user
>>>> from moving the window if a menu is open.
>>>>
>>>> GNOME uses the latter behavior.
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
>> yahoo/skype: greg_casamento, aol: gjcasa
>> (240)274-9630 (Cell)
>>
>
>
>
> --
> Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
> yahoo/skype: greg_casamento, aol: gjcasa
> (240)274-9630 (Cell)
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>



-- 
    .----.     Banlu Kemiyatorn
  /.../\...\   漫画家
 |.../  \...|  http://qstx.blogspot.com (Free Software Advocacy & Development)
 |../    \..|  http://feedbat.blogspot.com (Studio Work For Hire)
  \/      \/   http://groundzerostudiocomplex.blogspot.com (Studio Research)