|
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.
[Prev in Thread] | Current Thread | [Next in Thread] |