Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal...

Tuesday, 21 March 2000

        Ben Wing <ben(a)666.com&gt; writes:

...
 You wrote to me awhile ago about this and asked about documentation,
and I
 dictated a response but never got it sent, so here it is:

 I don't think there's any more documentation on how things work under Xt but it
 should be clear. The EmacsFrame widget is the widget corresponding to the X
 window that Emacs draws into and there is a handler for expose events called
 from Xt which arranges for the invalidated areas to get redrawn. I think this
 used to happen as part of the handler itself but now it is delayed until the
 next call to redisplay.

 However, one thing that you absolutely must not do is remove the Xt
 support.  This would be an incredibly unfriendly thing to do as it would
 prevent people from using any widget set other than Qt or GTK. Keep in
 mind that people run XEmacs on all sorts of different versions of X in
 Unix, and Xt is the standard and the only toolkit that probably exists on
 all of these systems. 
this is the main reason I suggested getting rid of the
(menubar|toolbar)-as-part-of-the-frame paradigm we have now.  If we went to
just using gutters to hold those things, and had device methods for
creating the widgets/etc, all would be well with the world.  I think.

...
 Pardon me if I've misunderstood your intentions w.r.t. this.

I'd never remove it completely.  It would just be in the gtk-aware version
that Xt wouldn't be an option.  Which is unfortunate.

...
 As for how you would implement GTK support, it will not be very hard
to
 convert redisplay to draw into a GTK window instead of an Xt window. In
 fact redisplay basically doesn't know about Xt at all, except in the
 portion that handles updating menubars and scrollbars and stuff that's
 directly related to Xt. 
It looks like redisplay-x.c is fairly 'clean' in that respect.  I imagine
what I'll end up having to do is reimplement event-Xt.c as event-gtk.c
(making sure to handle both gtk and tty events) and probably introduce
device-gtk.c, but still use x- as the prefix for everything to avoid
rewriting the world to deal with gtk- prefixed equivalents.  Xt and gtk are
going to be mutually exclusive, so... its not the pretties though.

...
 What you'd probably want to do is create a new set of event
routines to
 replace the ones in event-Xt.c. On the display side you could conceivably
 create a new device type but you probably wouldn't want to do that
 because it would be an externally visible change at the Lisp level. You
 might simply want to put a flag on each frame indicating what sort of
 toolkit the frame was created under and put conditions in the redisplay
 code and the code to update toolbars and menubars and so forth to test
 this flag and do the appropriate thing. 
Hmm... I'm going to have to start writing all this up and circulate it.
Ahhh, design documents. :)

-bp

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998