emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xwidget branch


From: Jan Djärv
Subject: Re: xwidget branch
Date: Thu, 01 Jul 2010 17:52:30 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1



address@hidden skrev 2010-06-30 15.09:
Jan Djärv<address@hidden>  writes:

This sounds like fun.  How do you handle multiple windows, that is the
same buffer with widgets displayed in different frames/windows?

There are some notes in the readme. I paste it below so we can discuss it
and improve it. This is as you might imagine the really tricky part.



I guess it takes some kind of proxy object that keeps track of creating the real widget for each window. GtkAction:s can help here. You can have a GtkAction instead of the real widget. When redisplay is done, check all proxy widgets for the GtkAction, and if no one is present for the window, create one. The window can be saved in the real widget as widget data.

I think the "don't display cursor over widget"-problem should have some precedence, it really looks awful :-).

I see lots of redisplay-problems with widgets, but that is to expected as Emacs doesn't use the Gtk+ event loop. It took a while before Gtk+ scrollbars displayed nicely, and even now bugs show up. You have to request redraw on widgets and flush the Gdk event queue manually at appropriate places.

Does the widgets always flow with the text or can you anchor them at
fixed positions?  I was thinking of per window toolbars.

They work like images. It ought to be possible to bind them to a margin
or something like images, but I havent tested this. Also like images
they are not tied to a window but to a buffer. OTOH xwidgets have,
unlike images, their own identity, and I have been thinking of letting
an xwidget be able to replace an entire window, etc.


I'll give it a try.

        Jan D.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]