3 This is an experimental branch to enable embedding of GTK widgets
4 inside an Emacs window. The Emacs abstraction is called an Xwidget,
5 for eXternal widget, and also in reference to the Xembed protocoll.
7 There is a demo file called xwidget-test.el which shows some of the
8 possibilities. There are some screnshots at the emacswiki.
10 Currently its possible to insert buttons, sliders, xembed widgets, and
11 webkit in the buffer. It works similar to the support for images in
12 Emacs. Adding more types of widgets should be fairly straightforward,
13 but will require adapter code for each type.
15 A difference from images is that xwidgets live their own life. You
16 create them with an api, get a reference, and tie them to a particular
17 buffer with a display spec.
19 Each xwidget can have several views. In MVC terms, an xwidget is the
20 model, and an xwidget-view is a view of the xwidget in a particular
23 The xwidget code attempts to keep the visual appearance of the views
24 in sync with through an Observer pattern implementation. This is
25 necessary to support the Emacs window paradigm.
28 bzr co bzr+ssh://bzr.savannah.gnu.org/emacs/xwidget/
29 #the below compiler flags shouldn't be strictly necessary
31 ./configure --with-xwidgets --enable-asserts --with-x-toolkit=gtk3
36 If you have GTK3 and gtk-webkit installed, you should be able to
37 start the embedded webkit browser now:
39 M-X xwidget-webkit-browse-url
41 If that didnt work out try the minimal demonstration instead:
43 (load-library "xwidget-test")
44 (xwidget-demo-a-button)
46 It looks unimpressive, but it's a gtk button inside an Emacs buffer!
48 If you got webkit working, great! Please note, though, that the
49 current support is far from a full fledged browser. My focus is on
50 delivering a component that can be used to build a full emacs based
51 browser on. Since I implement a browse-url function you can get quite
54 (setq browse-url-browser-function 'xwidget-webkit-browse-url)
56 then all Emacs browser interface systems work to a degree.
57 heres stuff I use currenly
59 - m-x anything-surfraw interfaces to search engines
60 - C-o in org mode opens links inside org
61 - m-x ffap opens links anywhere in a buffer
62 - m-x gtk-lookup-symbol searches gtk docs
66 I'll add more examples as I go along.
68 However theres lots of support missing, see TODO list for
71 - keyboard field navigation
74 - sites that use flash. I dont really care about this issue so its
75 unlikely to be fixed. Just a heads up.
78 Beginning with Summer 2011 I am now able to use Xwidget Emacs as my
79 primary Emacs. That is good for the project and the stability of the
82 At the time of writing I have 24 hour Emacs uptime with several
83 embedded webkit browsers, Gnus, org-mode, tramp, etc. etc.
85 That said, there are still many improvements that needs to be done,
86 particularily in memory management. Expect xwidget emacs to leak
89 ** timeline for inclusion in trunk
90 The Emacs 24 feature freeze is passed, so xwidgets won't probably be merged
91 until Emacs 25. OTOH since I now use xwidget emacs as my primary
92 emacs, I will merge from trunk much more often than in the past.
95 emacs-devel@gnu.org. There are very helpful people there. When I
96 started the xwidget project I had no clue about the Emacs internals.
98 * Brief overview of how xwidgets work
99 Xwidgets work in one way like images in Emacs. You bind a display spec very
100 similar to an image display spec to buffer contents. The display engine will
101 notice the display spec and try to display the xwidget there. The display engine
102 prepares space at the right place for the xwidget and so on for free, as long as
103 we provide proper sizes and so on back to the redisplay engine.
106 The problem is that Emacs cant actually draw the widgets, as it can with
107 images. Emacs must notify GTK about where the widgets should be, and how they
108 should be clipped and so on, and this information must be given to GTK
109 synchonous with Emacs display changes. Ok, so why is that difficult then?
111 - How do we know when a widget is NOT to be drawn? The only way I found so far
112 is having a flag for each xwdiget, that is reset before a redisplay. When an
113 xwidget is encountered during display, the flag is set. After redisplay,
114 iterate all xwidgets and hide those which hasnt been displayed.
116 - The gtk socket type for embedding external applications is desirable
117 but presents a lot of difficulties of its own. One difficulty is
118 deciding which input events to forward, and when and how to do it.
120 ** placement and clipping
121 the entire emacs frame is a gtk window. we use the fixed layout
122 manager to place xwidgets on the frame. coordinates are supplied by
123 the emacs display engine. widgets are placed inside an intermediate
124 window, called the widgetwindow. the widgetwindows are placed on the
127 this way was chosen to simplify clipping of the widgets against emacs
131 ** different strategies
132 Integrating toolkit widgets(gtk in this case) and the emacs display
133 engine is more difficult than your plain average gui application, and
134 different strategies has been tested and will continue to be tested.
136 There was a distinction between live xwidgets and
137 phantom xwidgets, previous to the change to MVC.
139 - the first aproach was to have the live xwidget on-screen, and move
140 them about. the phantoms were generated by snapshoting the live
143 the drawback of that aproach was that the gtk toolkit is admirably
144 lazy and doesnt draw the widget if its not actualy shown, meaning that
145 the snapshots for the phantoms will show garbage.
147 - the second aproach was to use composition support. that tells gtk
148 that the widget should be drawn in an off-screen buffer and drawn on
149 screen by the application.
151 this has the primary advantage that the snapshot is always
152 available, and enables the possibility of more eye-candy like drawing
153 live and phantom widgets in different colors.
155 the drawback is that its our own responsibility to handle drawing,
156 which puts more of the display optimization burden on us.
158 this is aproach worked so-so.
160 - another aproach is to have both live and phantom widgets drawn
161 on-screen by proxy gtk objects. the live xwidget will be entirely
162 handled in an off-screen window, and the proxy objects will redirect
165 - combine on-screen and off-screen aproaches. maybe composition is the
166 way to go for most cases, but on-screen xembeding is the way to go
167 for particular special cases, like showing video in a
168 window. off-screen rendering and whatnot, is not efficient in that
169 particular case, and the user will simply have to accept that the
170 phantom of a video widget isnt particularily beautiful.
172 - The current and seemingly sanest aproach implements a MVC pattern.
176 ;; cd /path/to/xwidgets-emacs-dir
177 ;; make all&& src/emacs -q --eval "(progn (load \"`pwd`/lisp/xwidget-test.el\") (xwidget-demo-basic))"
180 The MVC approach appears to be at least in principle robust for plain gtk
181 widgets. For the interesting case of gtk sockets which implements an
182 xembed host widget that allows for embedding other applications inside
183 an Emacs window, the story gets more complex.
185 The problem is that xembed is designed to plug an application window
186 inside a a secket and thats it. You can't move a plug between
187 sockets. I tried numerous hacks to get around this but there is
188 nothing that works realy well.
190 Therefore the Emacs part of the code will only expose well-defined
191 interfaces. cooperating applications will be able to use the interface
192 in a well defined manner. The problem is that there is no known xembeddable
193 application that implement the needed type of functionality, which is
194 allowing for creating new windows on the fly that plug into new
197 Therefore I will attempt to provide an external application that wraps
198 another application and through hacks attempts to provide the needed
199 multi view xembed function. That way Emacs is sane and the insanity
202 This app will work by providing a socket that an app plugs into. The
203 socket window is copied efficientlp by means of composition to a
204 number of other windows, that then are plugged into the different
206 ** old notes from x_draw_xwidget_glyph_string
208 BUG it seems this method for some reason is called with bad s->x and s->y sometimes.
209 When this happens the xwidget doesnt move on screen as it should.
210 This mightbe because of x_scroll_run. Emacs decides to scroll the screen by blitting sometimes.
211 then emacs doesnt try to actualy call the paint routines, which means this here code will never
212 run so the xwidget wont know it has been moved.
214 Solved temporarily by never optimizing in try_window_reusing_current_matrix().
216 BUG the phantoming code doesnt work very well when the live xwidget is off screen.
217 you will get weirdo display artefacts. Composition ought to solve this, since that means the live window is
218 always available in an off-screen buffer. My current attempt at composition doesnt work properly however.
220 //allocation debugging. the correct values cant be expected to show upp immediately, but eventually they should get to be ok
221 // this is because we dont know when the container gets around to doing layout
222 //GtkAllocation galloc;
223 //gtk_widget_get_allocation(GTK_WIDGET (xv->widgetwindow), &galloc);
224 //printf("allocation %d %d , %d %d\n", galloc.x,galloc.y,galloc.width,galloc.height);
227 *** old notes about the old live/phantom scheme
230 // 1) always draw live xwidget in slected window
231 // (2) if there were no live instances of the xwidget in selected window, also draw it live)
232 // 3) if there was a live xwidget previously, now phantom it.
236 //ok, we are painting the xwidgets in non-selected window, so draw a phantom
237 //printf("draw phantom xwidget at:%d %d\n",x,y);
238 //xwidget_composite_draw_phantom (xw, x, y, clipx, clipy); //TODO MVC there will be very few cases of phantoming
242 atm this works as follows: only check if xwidgets are displayed in the
243 "selected window". if not, hide them or phantom them.
245 this means valid cases like xwidgets being displayed only once in
246 non-selected windows, does not work well. they should also be visible
247 in that case not phantomed.
250 ** TODO optimize drawing off large offscreen widgets
251 Currently I just allocate as large an area as the offscreen widget
252 desires. This works well most of the time. But a HTML page might in
253 principle be of infinite height so there will probably be cases where
254 this doesn't work too well.
255 ** TODO again a trace
257 the hunch is that since I still hand-wave the view storage the array
258 can get out of synchronous. so maybe switching to a lisp structure
259 will help as it did for the model. Anyway, doesnt happen at all often.
262 #0 0x0000000000685304 in xwidget_touch (xv=0x0) at xwidget.c:1225
263 #1 0x00000000006853e7 in xwidget_end_redisplay (w=0x11b42ca0, matrix=
264 0xff9bf40) at xwidget.c:1272
265 #2 0x000000000041cc31 in update_window (w=0x11b42ca0, force_p=0)
267 #3 0x000000000041c0e5 in update_window_tree (w=0x11b42ca0, force_p=0)
269 #4 0x000000000041be8b in update_frame (f=0x1682a50, force_p=0,
270 inhibit_hairy_id_p=0) at dispnew.c:3258
271 #5 0x000000000045066f in redisplay_internal () at xdisp.c:12931
272 #6 0x000000000044e210 in redisplay () at xdisp.c:12110
273 #7 0x0000000000567e65 in read_char (commandflag=1, nmaps=7, maps=
274 0x7fffffffc040, prev_event=12708226, used_mouse_menu=0x7fffffffc254,
275 end_time=0x0) at keyboard.c:2447
276 #8 0x000000000057613c in read_key_sequence (keybuf=0x7fffffffc4a0, bufsize=
277 30, prompt=12708226, dont_downcase_last=0, can_return_switch_frame=1,
278 fix_current_buffer=1) at keyboard.c:9299
279 #9 0x0000000000565d45 in command_loop_1 () at keyboard.c:1448
280 #10 0x0000000000601008 in internal_condition_case (bfun=
281 0x565962 <command_loop_1>, handlers=12760466, hfun=0x565259 <cmd_error>)
283 #11 0x0000000000565659 in command_loop_2 (ignore=12708226) at keyboard.c:1159
284 #12 0x0000000000600992 in internal_catch (tag=12873826, func=
285 ---Type <return> to continue, or q <return> to quit---
286 0x565633 <command_loop_2>, arg=12708226) at eval.c:1247
287 #13 0x00000000005655bd in command_loop () at keyboard.c:1124
288 #14 0x0000000000564da7 in recursive_edit_1 () at keyboard.c:759
289 #15 0x0000000000564f43 in Frecursive_edit () at keyboard.c:823
290 #16 0x000000000060444f in Ffuncall (nargs=1, args=0x7fffffffca20)
292 #17 0x00000000006507f8 in exec_byte_code (bytestr=145172929, vector=145179445,
293 maxdepth=116, args_template=12708226, nargs=0, args=0x0) at bytecode.c:785
294 #18 0x0000000000604eec in funcall_lambda (fun=140575909, nargs=2, arg_vector=
295 0x7fffffffcfe8) at eval.c:3220
296 #19 0x000000000060467e in Ffuncall (nargs=3, args=0x7fffffffcfe0)
298 #20 0x00000000006035fc in Fapply (nargs=2, args=0x7fffffffd0b0) at eval.c:2494
299 #21 0x0000000000603b43 in apply1 (fn=12874242, arg=301666310) at eval.c:2732
300 #22 0x00000000005feb25 in call_debugger (arg=301666310) at eval.c:220
301 #23 0x0000000000601ca9 in maybe_call_debugger (conditions=9431542, sig=
302 12761282, data=301666742) at eval.c:1893
303 #24 0x0000000000601785 in Fsignal (error_symbol=12761282, data=301666742)
305 #25 0x0000000000601898 in xsignal (error_symbol=12761282, data=301666742)
307 #26 0x0000000000601926 in xsignal2 (error_symbol=12761282, arg1=102756373,
308 arg2=0) at eval.c:1770
309 ---Type <return> to continue, or q <return> to quit---
310 #27 0x0000000000604d6e in funcall_lambda (fun=102756373, nargs=0, arg_vector=
311 0x7fffffffd398) at eval.c:3189
312 #28 0x000000000060467e in Ffuncall (nargs=1, args=0x7fffffffd390)
314 #29 0x00000000006507f8 in exec_byte_code (bytestr=54783137, vector=109656229,
315 maxdepth=12, args_template=12708226, nargs=0, args=0x0) at bytecode.c:785
316 #30 0x0000000000604eec in funcall_lambda (fun=109656517, nargs=0, arg_vector=
317 0x7fffffffd890) at eval.c:3220
318 #31 0x000000000060467e in Ffuncall (nargs=1, args=0x7fffffffd888)
320 #32 0x0000000000603b08 in apply1 (fn=109656517, arg=12708226) at eval.c:2725
321 #33 0x00000000005fc8c9 in Fcall_interactively (function=109656517, record_flag=
322 12708226, keys=12754549) at callint.c:379
323 #34 0x00000000006044c2 in Ffuncall (nargs=4, args=0x7fffffffdc60)
325 #35 0x0000000000603c57 in call3 (fn=12893554, arg1=109656517, arg2=12708226,
326 arg3=12708226) at eval.c:2789
327 #36 0x00000000005784cd in Fcommand_execute (cmd=109656517, record_flag=
328 12708226, keys=12708226, special=12708226) at keyboard.c:10290
329 #37 0x00000000005661fb in command_loop_1 () at keyboard.c:1575
330 #38 0x0000000000601008 in internal_condition_case (bfun=
331 0x565962 <command_loop_1>, handlers=12760466, hfun=0x565259 <cmd_error>)
333 ---Type <return> to continue, or q <return> to quit---
334 #39 0x0000000000565659 in command_loop_2 (ignore=12708226) at keyboard.c:1159
335 #40 0x0000000000600992 in internal_catch (tag=12756258, func=
336 0x565633 <command_loop_2>, arg=12708226) at eval.c:1247
337 #41 0x000000000056560c in command_loop () at keyboard.c:1138
338 #42 0x0000000000564da7 in recursive_edit_1 () at keyboard.c:759
339 #43 0x0000000000564f43 in Frecursive_edit () at keyboard.c:823
340 #44 0x0000000000563052 in main (argc=1, argv=0x7fffffffe678) at emacs.c:1711
343 "recursive-edit" (0xffffca28)
345 "image-bol" (0xffffd398)
346 0x68939c0 PVEC_COMPILED
347 "call-interactively" (0xffffdc68)
351 ** DONE new annoying trace
352 CLOSED: [2011-08-13 Sat 16:16]
353 maybe related to scroll inhibiting or cursor inhibiting code.
354 It appears actually to be related to GLYPH_DEBUG=1. this flag is no
357 Breakpoint 1, abort () at emacs.c:383
358 383 kill (getpid (), SIGABRT);
359 Missing separate debuginfos, use: debuginfo-install hunspell-1.2.15-2.fc15.x86_64 nss-mdns-0.10-9.fc15.x86_64
363 #0 abort () at emacs.c:383
364 #1 0x0000000000418f01 in matrix_row (matrix=0xac29400, row=-1)
366 #2 0x000000000046e113 in draw_glyphs (w=0x18235c0, x=198, row=0xa3af100, area=
367 TEXT_AREA, start=17, end=18, hl=DRAW_CURSOR, overlaps=0) at xdisp.c:22550
368 #3 0x000000000047869f in draw_phys_cursor_glyph (w=0x18235c0, row=0xa3af100,
369 hl=DRAW_CURSOR) at xdisp.c:24882
370 #4 0x00000000005083bb in x_draw_window_cursor (w=0x18235c0, glyph_row=
371 0xa3af100, x=180, y=361, cursor_type=0, cursor_width=1, on_p=1, active_p=1)
373 #5 0x00000000004790cd in display_and_set_cursor (w=0x18235c0, on=1, hpos=17,
374 vpos=19, x=180, y=361) at xdisp.c:25098
375 #6 0x00000000004fa31f in x_update_window_end (w=0x18235c0, cursor_on_p=1,
376 mouse_face_overwritten_p=0) at xterm.c:644
377 #7 0x000000000041ccb9 in update_window (w=0x18235c0, force_p=0)
379 #8 0x000000000041c165 in update_window_tree (w=0x18235c0, force_p=0)
381 #9 0x000000000041beee in update_frame (f=0x1658460, force_p=0,
382 inhibit_hairy_id_p=0) at dispnew.c:3258
383 #10 0x0000000000450a2e in redisplay_internal () at xdisp.c:12983
384 #11 0x000000000044e2a6 in redisplay () at xdisp.c:12099
385 #12 0x000000000056a60d in read_char (commandflag=1, nmaps=6, maps=
387 ** DONE allow xwidgets to report their size
388 CLOSED: [2011-07-19 Tue 14:26]
389 now we just hard code sizes. but webkit widgets for instance can
390 report sizes that suit the content. support that.
391 ** TODO BUG xwidget view ghosts
392 - xwidget-webkit-browse-url somewhere
394 now theres 2 webkit views
396 now theres 2 views but one is a ghost!
397 one should have been deleted when its window died but that didnt work
398 for some reason here.
400 - m-x xwidget-cleanup
402 the ghost goes away because we killed explicitly but this is just a workaround.
404 xwidget_view_delete_all_in_window(w); in delete-window-internal is not sufficient.
405 delete-other-windows-internal
406 delete_all_subwindows
409 Added cleanup those window configuration hook which works in practice
412 ** DONE BUG annoying backtrace
413 CLOSED: [2011-07-19 Tue 14:28]
414 (this no longer seems to happen even under heavy usage. seems merging
415 from trunk helped. lots were happening in redisplay at this time in trunk.)
418 - happens even with no initialized xwidgets
419 - + row->glyphs[area][i].face_id
420 or similar code, so row is invalid for some reason.
421 xwidgets currently disable some redisplay opimizations so it might be
422 an actual emacs bug manifesting without optimizations.
425 /* Compute the width of this line. */
426 row->pixel_width = row->x;
427 for (i = 0; i < row->used[TEXT_AREA]; ++i)
428 row->pixel_width += row->glyphs[TEXT_AREA][i].pixel_width;
431 #0 0x000000000045c340 in compute_line_metrics (it=0x7fffffff8a20)
433 #1 0x00000000004603da in display_line (it=0x7fffffff8a20) at xdisp.c:18792
434 #2 0x0000000000457646 in try_window (window=23403045, pos=..., flags=1)
436 #3 0x00000000004559c9 in redisplay_window (window=23403045, just_this_one_p=0)
438 #4 0x0000000000450247 in redisplay_window_0 (window=23403045) at xdisp.c:13152
439 #5 0x00000000005fdcd9 in internal_condition_case_1 (bfun=
440 0x450208 <redisplay_window_0>, arg=23403045, handlers=12691046, hfun=
441 0x4501d9 <redisplay_window_error>) at eval.c:1538
442 #6 0x00000000004501ba in redisplay_windows (window=23403045) at xdisp.c:13132
443 #7 0x000000000044f19c in redisplay_internal () at xdisp.c:12706
444 #8 0x000000000044f9f2 in redisplay_preserve_echo_area (from_where=7)
446 #9 0x0000000000568525 in swallow_events (do_display=1) at keyboard.c:4197
447 #10 0x0000000000422554 in sit_for (timeout=40, reading=1, do_display=1)
449 #11 0x000000000056512c in read_char (commandflag=1, nmaps=8, maps=
450 0x7fffffffd3f0, prev_event=12720514, used_mouse_menu=0x7fffffffd604,
451 end_time=0x0) at keyboard.c:2689
452 #12 0x0000000000572c59 in read_key_sequence (keybuf=0x7fffffffd850, bufsize=
453 30, prompt=12720514, dont_downcase_last=0, can_return_switch_frame=1,
454 ---Type <return> to continue, or q <return> to quit---
455 fix_current_buffer=1) at keyboard.c:9291
456 #13 0x0000000000562897 in command_loop_1 () at keyboard.c:1446
457 #14 0x00000000005fdb52 in internal_condition_case (bfun=
458 0x5624b4 <command_loop_1>, handlers=12772898, hfun=0x561dab <cmd_error>)
460 #15 0x00000000005621ab in command_loop_2 (ignore=12720514) at keyboard.c:1157
461 #16 0x00000000005fd4ce in internal_catch (tag=12768770, func=
462 0x562185 <command_loop_2>, arg=12720514) at eval.c:1247
463 #17 0x000000000056215e in command_loop () at keyboard.c:1136
464 #18 0x00000000005618f9 in recursive_edit_1 () at keyboard.c:757
465 #19 0x0000000000561a95 in Frecursive_edit () at keyboard.c:821
466 #20 0x000000000055fba2 in main (argc=1, argv=0x7fffffffe188) at emacs.c:1704
471 ** DONE Examine using XComposite rather than GTK off-screen
472 rendering. This would make xembed widgets work much better. This
473 would probably be rathter difficult, but could open up other
474 interesting possibilities for Emacs. There is an early attempt in
475 xwidget.c, but the X call to redirect to offscreen rendering fails
478 the attempt was further worked on, and the xlib calls replaced with
479 gdk calls, this works better.
481 In the end I abandoned this aproach. Xwidget-osr is the new aproach.
483 ** TODO make the keyboard event code propagation code work.
484 There is an attempt to provide an api to send keyboard events to an
485 xwidget, but it doesnt currently work very well.
487 *** TODO try gtk event creation instead
488 since that works fine in the webkit osr code.
489 but, oh no, that didn't work for some reason.
490 the widgets seems to receive the event but then the embedded widgets
493 http://kegel.com/gtk/button.c
495 *** TODO examine some library to synthesise events
500 ** DONE remove the special-case for when the minibuffer is
501 active. I added some code to reduce the annoying problem display artefacts
502 when making the minibuffer the selected window. This made xwidgets in the
503 buffer go grey or black whenever one did m-x to activate the minibuffer. The
504 coded tried to handle the minibuffer as a special case. That simply wasnt a
505 good idea. Special-casing will never work properly. It is much better to spend
506 time finding solutions that work acceptably in the general case.
508 ** DONE disable emacs cursor drawing on top of an active xwidget.
509 This ought to be rather simple and should improve the visuals a lot.
511 ** TODO improve the xwidgets programming interface
512 so its less of hand-waving affair. This shouldnt be too hard, but I
513 have deliberatley not spent any time on it, since getting the
514 visuals right is much harder. Anyway, I sort of think the interface
515 should be somewhat like it is, except symbols is used instead of
517 *** DONE use symbols for xwidget types rather than ints
518 CLOSED: [2011-06-27 Mon 12:52]
521 *** TODO better lisp based structure for xwidgets
522 the lisp interface woud be like this:
523 - make-xwidget returns an xwidget object, similar to a process
524 object. this object is used when creating the display spec(instead of
525 the user defined id now used)
527 the data structure would be something like this:
528 - a "process" like aproach to create the xwidgets. xwidgets are
529 coupled to buffers, somewhat like processes, except a buffer can
530 hold several xwidgets
531 - an xwidget has a plist to hold the model, like a process
532 - an xwidget has an assoc list of xwidget views
534 there are some things that arent clear:
535 - an xwidget doesnt necessarily need to be coupled to a buffer but it
536 seems to be the clearest model. xwidgets would be buffer local
537 - xwidget-views are by necessity coupled to a emacs window so it might
538 be better to store them window locally rather than in an assoc
539 coupled to the xwidget model
540 - for some gtk widgets that resist an mvc approach, like the webkit
541 widgets, special operations are needed, similar to the old phantom
542 widgets aproach. so we need to differentiate live and phantom
543 instances for these troublesome widgets and let lisp manage all the trickery.
545 stuff that needs to work:
546 - do something for all views of a xwidget(resize, value change)
547 - do something for all xw-views in an emacs window(deletion etc)
548 - lookup xw-view for xwidget in emacs window(during redisplay)
549 (- do something for all siblings of a xw-view. not atm)
551 *** DONE xwidget creation interface
552 CLOSED: [2011-07-18 Mon 01:59]
553 xwidgets are a little bit like emacs processes but also a little bit
554 like emacs images. Therefore its not perfectly obvious how to handle
555 creation. Currently I just use hardcoded identifiers. the real scheme
556 needs to be something else.
558 Heres a tentative approach:
559 - xwidget-create returns a xwidget object, like process creation
560 functions. the xwidget will be largely uninitialized until
561 discovered by redisplay. an xw belongs to a buffer
562 - xwidget-insert inserts the xwidget in a buffer. when discovered by
563 redisplay it will be initialized and a xwidget-view allocated
564 - an event will be emitted when initialization is finished when
565 relevant like for sockets
567 the problem with this aproach is that its not really legal to reuse
568 xwidget objects by writing several display specs who reference the
569 same xwidget. It could presumably be done but it would just become
570 weird for no real benefit. the big preblem is that the display spec
571 decides the on-screen size, and its not sane to have xwidget views
572 with different sizes. therefore such display specs would need to be
573 catched and dissallowed. Except it is hard because AFAIK the specs
574 don't have an identity as such. A flag in the structure could be set
575 by lookup so the first display attempt would win. but then you can't
576 rewrite the spec to change the size. hmmm. A third approach would be
577 to just allow the 1st spec refering an xw during a redisplay to take
578 effect, the rest are signaled as errors. this wouldnt be too bad.
580 the other aproach would be to work more like images:
582 - write the display spec with all information needed to create the
584 - retrieve the xwidget objet from the spec with an xwidget-at-point function. It
585 can be uninitalized which client code must handle. Unlike
586 assynchronous process creation we dont get back a handle, because
588 - emitted event on initialization, when needed. Many widgets don't
589 need this. for instance, a button sends an event when pressed. but
590 you can't press it unless its on screen, and then its initialized
593 This approach seemed good, but how do I know which instance
594 generates an event if I cant set the id beforehand?
596 so, therefore, the first two aproach is used.
599 *** DONE xwidget creation interface actually
600 CLOSED: [2011-07-18 Mon 01:59]
601 conclusion of above ramblings:
602 - should be similar to make-text-button
603 - don't init from display spec, instead during make-xwidget call
604 *** TODO callbacks would be nice
605 but they need to be handled initially with events for technical
606 reasons. C code can't call Lisp easily. The event handler can call the
609 ** TODO more documentation
610 There should be user docs, and xwidget contributor docs. The current README
611 is all contributor docs there is now, apart from the code.
615 ** CANCELLED look into more ways of displaying xwidgets, like binding them to a
616 CLOSED: [2011-07-05 Tue 11:34]
617 window rather than a point in a buffer. This was suggested by Chidong.
618 This would be a useful addition to Emacs in itself, and would avoid nearly all
619 display issues. I still think the general case is more interesting, but this
620 special case should also be added. The xwidget would then be bound to
621 replace the view of a particular window, and it would only show in
624 I got the webkit xwidget to work well enough so I dont see the need
625 for this now, except for sockets and I think it can better be dealt
626 with at the lisp level.
628 ** DONE MVC mode for xwidgets
629 CLOSED: [2011-06-27 Mon 12:53]
630 It appears unfruitful to chase using the same display mode for all
631 types of xwidgets. Composition is fun but not robust the way I
634 Instead there should be a set of MVC xwidgets. Each on-screen instance
635 of an MVC widget would be a real GTK widget. The instances would
636 communciate state using signals.
638 There are drawbacks. There is no inbuilt support for MVC in GTK, so we
639 have to roll our own, which is tedious if not much work for the few
642 MVC for xembedded application will need support from the applications
643 themselves. Inkscape supports multiple views to the same document,
644 other programs don't. In practice it might not be a big drawback.
647 *** DONE figure out what to do with the multiple frames case.
648 CLOSED: [2011-06-27 Mon 12:52]
649 This should be easier to solve with MVC.
650 Surprisingly, this just worked!
651 *** DONE how to propagate changes in views to other views?
652 CLOSED: [2011-06-27 Mon 12:53]
653 I used gtk signals, the implementation for sliders works well!
655 ** TODO canvas support
656 heres an interesting comparision of gtk canvases
657 http://live.gnome.org/ProjectRidley/CanvasOverview
659 goocanvas is a gtk canvas implemented using cairo. investigate.
662 - it has a MVC model aproach out of the box which is nice.
664 http://developer.gnome.org/goocanvas/unstable/goocanvas-model-view-canvas.html
666 export CFLAGS="`pkg-config --cflags goocanvas` -DHAVE_GOOCANVAS"
667 export LDFLAGS=`pkg-config --libs goocanvas`
671 I made a hello goo world xwidget so seems doable.
672 I wanted to load a SVG which wasnt immediately straightforward, so I
673 tried clutter. but it turns out the exact same strategy could be used
677 maybe clutter can be used as a canvas?
679 - seems to have a lot of traction atm. many examples
680 - potentialy fast and cool vector graphics
682 - no out of the box MVC support, but seems doable. no worse than the
683 other home brew mvc support I have in xwidgets
684 (media-explorer in an application that employes the MVC pattern)
686 http://www.openismus.com/documents/clutter_tutorial/0.9/docs/tutorial/html/sec-stage-widget.html
688 there is also cool stuff like this:
689 http://gitorious.org/webkit-clutter/webkit-clutter which is an webkit actor for
692 I want to render svg. aparently:
693 librsvg rsvg_handle_render_cairo(h, cr);
697 export CFLAGS="`pkg-config --cflags clutter-gtk-1.0` -DHAVE_CLUTTER"
698 export LDFLAGS=`pkg-config --libs clutter-gtk-1.0`
703 Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in
704 the same process is not supported
706 export CFLAGS="`pkg-config --cflags clutter-gtk-0.10` -DHAVE_CLUTTER"
707 export LDFLAGS=`pkg-config --libs clutter-gtk-0.10`
713 expose the DOM to lisp or something. The webkit xwidget works pretty
714 well now, so this might be the way ahead.
715 ** DONE mvc code crashes after a while
716 CLOSED: [2011-07-12 Tue 18:52]
717 seemingly only when compiling with optimizations.
720 Doesn't seem to happen after some code cleanups.
721 ** DONE xwidget-resize-at
722 CLOSED: [2011-07-19 Tue 14:28]
723 reimplement so display spec is not involved
724 ** DONE display spec validation
725 CLOSED: [2011-07-19 Tue 14:44]
726 it is an error to reuse xwidgets in several buffers or in the same
727 buffer. how do we catch these errors?
728 - showing the same xwidget twice in a buffer is no more wrong than
729 showing in several emacs windows, just conceptually wrong, so ignore
731 - xwidgets now store a reference to the buffer they were created in,
732 so use that to invalidate xwidget references in oher buffers. but
733 thats not really an error either
734 - xwidgets should now be proper lisp objects so you dont delete them
735 you await their garbage collection. so therefore there can never be
736 invalid disploy specs
738 so turned out this got solved by using proper lisp objects for
741 ** DONE clipping of controllers
742 CLOSED: [2011-07-05 Tue 11:33]
744 Emacs uses a big GTK window and does its own clipping against Emacs
745 windows inside this area. So, in order to layout gtk widgets in emacs
746 windows we must clip thim ourselves.
748 The following method worked well for a long time:
749 - make a gtk widget, say a button, xw
750 - make a clipping area, of type gtkfixed(many types have been tested)
751 - put the clip area in the main emacs gtk window
752 - figure out clip area changes during emacs redisplay
754 the only weirdness was that one has to tell gtk the clip area has a
755 window in order to get clipping. This is weird because all gtkwidgets
756 are windows in a sense and a window is almost by definition also a
759 Anyway, in GTK3 the gtk_widget_set_has_window(GTK_WIDGET (
760 xv->widgetwindow), TRUE); call is ignored.
762 The gtkeventbox which is documented to have its own window doesnt work
765 http://www.lanedo.com/~carlos/gtk3-doc/chap-drawing-model.html
767 anyway clipping is rather complicated but seems to finally work okay.
769 *** DONE subclass my own clipping widget
770 CLOSED: [2011-07-04 Mon 16:55]
771 http://www.lanedo.com/~carlos/gtk3-doc/GtkWidget.html#gtk-widget-set-has-window
772 mentions that it has_window can only be called inside a widget
775 this wasnt really the issue. allocation was the problem
776 *** DONE try scrolled window
777 CLOSED: [2011-07-01 Fri 10:56]
778 clipping does in fact work with
779 gtk_scrolled_window_add_with_viewport (xv->widgetwindow, xv->widget);
782 I get unwanted scrollbars in the widget though.
784 gtk_scrolled_window_set_policy ( xv->widgetwindow,
785 GTK_POLICY_NEVER, GTK_POLICY_NEVER);
787 stops clipping from working!
790 *** DONE try viewport
791 CLOSED: [2011-07-01 Fri 10:56]
792 gtkviewport is used in scrolled window so in order to remove
793 scrollbars it should be possible to use viewport directly. however,
794 viewport ignores size requests. or rather the container does.
797 *** DONE debug allocation
798 CLOSED: [2011-07-04 Mon 16:56]
799 the container determines how much size to allocate to child widgets.
801 GtkAllocation galloc;
802 gtk_widget_get_allocation(GTK_WIDGET (xv->widgetwindow), &galloc);
803 printf("allocation %d %d , %d %d\n", galloc.x,galloc.y,galloc.width,galloc.height);
805 after my clipping attemp shows that my size request is ignored! this
806 might be logical, since the container provided by emacs is a
807 gtkfixed. gtkfixed might choose to heed the widgets size desires and
808 allocate the entire widget size. but we want clipping!
810 since i cant reasonably expect to change the emacs main container, i
811 can maybe overide the setallocation method in gwfixed, and adjust
812 allocation to clipping if its an xwidget asking for allocation.
814 **** DONE subclass gtkfixed
815 CLOSED: [2011-07-04 Mon 16:56]
816 possibly i need to subclass gtkfixed and override
818 void gtk_widget_size_allocate (GtkWidget *widget,
819 GtkAllocation *allocation);
821 http://developer.gnome.org/gobject/stable/howto-gobject.html
823 turns out emacs already does this for gtk3 according to jan D:
824 >>For GTK3, Emacs already subclasses GtkFixed, see emacsgtkfixed.[ch].
826 - widgets may not be underallocated, aparently
827 http://mail.gnome.org/archives/commits-list/2011-April/msg10950.html
829 - how to call base class method/chain up
830 http://developer.gnome.org/gobject/stable/howto-gobject-chainup.html
832 - the allocation modification could happen in the container or the
833 child. it feels more apropiate in the container
835 it is however unexpectedy inconvenient to modify allocation because
836 the needed data is private to the base class. to overcome this:
838 - run base class method 1st.
839 - then, iterate all children, and modify allocation for xwidget
840 children only. x y will then be set.
842 JanD pointed out the GTK3 port already has its own subclass, so I
846 CLOSED: [2011-07-05 Tue 11:30]
847 there are four controller edges that potentialy need clipping. I begun
848 with right and bottom edges. clipping them is just a matter of setting
849 the right size of the widgetwindow and also ensure it gets the right
850 allocation from the container.
852 clipping top (and left) is not equally straightforward. I'm using a
853 viewport now and scroll it the amount that needs to be clipped.
854 however, the viewport is sensitive to changes in allocation, which
855 makes it harder to use the allocation workarounds.
858 - gtk_widget_set_size_request
861 I returned to using a simple gtkfixed for the widgetwindow. with
862 allocation hack and set_has_window it works. Idea prefer not to have
863 the allocatien hack and it wasnt needed it gtk3 only gtk2. needs
864 furthi investigation,
866 ** various code cleanups
867 There are many cleanups necessary before any hope of inclusion in
868 Emacs trunk. To begin with, the part of the patch that touches other
869 parts of emacs must be very clean.
870 *** DONE use FRAME_GTK_WIDGET (f)
871 CLOSED: [2011-07-20 Wed 20:02]
874 *** DONE support configure
875 CLOSED: [2011-07-12 Tue 18:48]
876 *** DONE ifdef all xwidget code
877 CLOSED: [2011-08-13 Sat 16:19]
878 so you can reliably disable the code at compiletime
879 ** DONE translate clicks
880 CLOSED: [2011-07-03 Sun 22:12]
881 on onscreen webkit peer to offscreen
884 http://developer.gnome.org/gdk/stable/gdk-Windows.html#GdkWindow-from-embedder
886 turned out to be not so hard, captured events, copied them and
887 forwarded them offscreen!
889 ** TODO investigate gdk_window_redirect_to_drawable
890 http://developer.gnome.org/gdk/stable/gdk-Windows.html#gdk-offscreen-window-set-embedder
891 maybe could be used in place of my own copy hacks? to work it must
892 support a chain of redirects, which seems unlikely. the benefit would
893 be that I dont have to spend time optimizing redrawing.
896 ** DONE remove xwidget_views when emacs window is deleted
897 CLOSED: [2011-07-05 Tue 11:29]
898 removing xwidget views when an Emacs window closes is not reliable.
900 - switching buffers in a window seems to hide the corresponding
901 xwidget-views properly, but they might as well be deleted.
903 - patching delete-window-internal could be used to delete the xwidget-views
908 although embedding a browser is not my primary concern many are
909 interested in this. some suitable browser component needs to be found
913 CLOSED: [2011-07-03 Sun 22:13]
914 there is a webkit gtk port. there is no obvious mvc support.
915 http://live.gnome.org/WebKitGtk
916 http://webkitgtk.org/
918 it might be possible to keep a set of webxits in artificial
919 synchronisation by recursive deep copy of the DOM from one webkit to
920 another. This will be error prone at best though. Another way might be
921 to just use bitmap copy of the "live"instance to the "phantom"
922 instances. the problem of transfering the live view remains though.
924 export CFLAGS="`pkg-config --cflags webkit-1.0` -DHAVE_WEBKIT -g"
925 export LDFLAGS=`pkg-config --libs webkit-1.0`
929 **** off screen rendering
930 export CFLAGS="`pkg-config --cflags webkit-1.0` -DHAVE_WEBKIT_OSR -g"
931 export LDFLAGS=`pkg-config --libs webkit-1.0`
935 works a little bit but i get errors like:
937 (emacs:8362): GLib-GObject-WARNING **: invalid cast from `GdkOffscreenWindow' to `GdkDrawableImplX11'
939 set a breakpoint in g_log, backtrace seems to indicate
940 webkitViewportAttributesRecompute is the offender.
942 maybe try gtk3 variants?
944 export CFLAGS="`pkg-config --cflags webkitgtk-3.0 ` -DHAVE_WEBKIT_OSR "
945 export LDFLAGS=`pkg-config --libs webkitgtk-3.0 `
946 ./configure --with-x-toolkit=gtk3
949 crash in gtk_window_get_size instead. great.
951 http://gtkplus-p3.0.sourcearchive.com/documentation/2.91.5-0ubuntu1/testoffscreenwindow_8c-source.html
953 after many atempts, the basic issue remains. for some reason the
954 offscreen widget isnt ok when I want to snapshot it, so i simply get
955 emptiness. the surface is only ok someimes.
957 here is a useful debugging snippets:
960 // - the bg colors always change, so theres no error in signal handling
961 // - i get this error now and then:
962 //(emacs:7109): GLib-GObject-WARNING **: invalid cast from `GdkOffscreenWindow' to `GdkDrawableImplX11'
963 // seems to happen in webkit actually. see README
965 if(0){ //redraw debug hack. helped a lot in fact. use the with alpha painter below also
966 cairo_set_source_rgb(cr, osr_dbg_color, 1.0, 0.2);
967 cairo_rectangle(cr, 0,0, xw->width, xw->height);
970 if(osr_dbg_color>1.0)
975 you need to terminate drawing like this:
977 //cairo_set_source_surface (cr, src_pixmap, 0,0);
978 //cairo_set_operator (cr, CAIRO_OPERATOR_OVER);
980 //cairo_paint_with_alpha (cr, 1.0);
984 the snippets change background color on oach redraw.
986 **** on-screen rendering to separate window
987 an alternative might be to open a separate window and snapshot it. the
988 idea is that whatever oddness webkit does so that offscreen rendering
989 doesnt work, doesnt happen on-screen. the window could be opened
990 somewhere not in the way.
992 *** CANCELLED firefox
993 CLOSED: [2011-07-03 Sun 22:13]
994 http://www-archive.mozilla.org/unix/gtk-embedding.html
995 seems to be severly bitrotted
997 heres a newer aproach
998 http://hg.mozilla.org/incubator/embedding/file/29ac0fe51754/gtk/tests/test.cpp
1000 while webkit clearly has the best traction as an embeddee, the
1001 offscreen rendering issues makes it interesting to see what ff brings
1004 turned out webkit has as good offscreen support as anyone, see I went
1005 with that in the end.
1008 *** DONE text field support
1009 CLOSED: [2011-07-20 Wed 20:05]
1010 Emacs captures all keyboard events so text field support isn't super
1013 **** propagate keyboard events
1014 I have some old hacks for this and they are not good.
1015 **** use the DOM model
1016 expose document.activeElement to lisp. This is potentially more
1017 interesting than just forwarding keyboard events.
1019 webkit_web_view_get_dom_document ()
1021 this is hard it seems. an idea might be to hack elisp support for swig
1022 to machine generate the bindings.
1023 **** DONE inject javascript
1024 CLOSED: [2011-07-03 Sun 22:50]
1025 webkit_web_view_execute_script ()
1028 (xwidget-webkit-execute-script 5 "document.activeElement.value='test'")
1030 so it should be possible to do some interesting stuff.
1031 execute-script does however not return anything at the interface level
1032 so satisfaction is not total:
1034 http://markmail.org/message/4yowmdgras73z3x5
1037 https://launchpad.net/gnome-seed
1040 <jave> im trying to understanh how to interact via javascript to an embedded
1041 webkit gtk instance [23:38]
1042 <jave> i use webkit_web_view_execute_script() which is nice but doesnt return
1043 a value, by design aparently [23:39]
1045 <lucian> jave: afaik, webkit still doesn't have full gobject bindings [23:48]
1046 <lucian> jave: you can hack it up by making the JS modify the title, and read
1047 the title from gtk-side
1048 <jave> lucian: that was a pretty cool idea!
1051 *** webkit_web_view_load_string ()
1052 I would like preview of html in a buffer rather than from uri.
1056 *** DONE simple xwidget-webkit wrapper
1057 CLOSED: [2011-07-22 Fri 11:01]
1058 so that it could be used for actual browsing :)
1059 I dont want to reinvent too many wheels so i'd like to use existing
1060 emacs facilities here possible. use bindings similar to w3m(or info)
1062 - m-x xwidget-webkit starts a session
1064 - use bookmark-jump i suppose. I mostly use org for bookmarks myself
1065 - browse-url support so webkit can be the default browser
1066 - some way of getting around the quirky keyboard interaction since
1067 xwidgets dont receive keyboard events because I hawe no idea how to
1068 do that in a sane way
1070 ... and one can of course go on bikeshedding forever. lets keep it
1071 simple and extensible, and compatible with other Emacs packages.
1073 the really cool ideas would need Emacs DOM integration, which is not
1077 *** TODO webkit support webkit signals
1079 **** DONE particularily document-load-finished
1080 CLOSED: [2011-08-01 Mon 22:34]
1081 http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#WebKitWebView-document-load-finished
1082 because one might need tell set a title and sizes and things when it loads.
1084 Debugger entered--Lisp error: (error "Two bases given in one event")
1086 hapens sometimes with xwidget events. appears to be when the
1087 originating xwidget is offscreen so that the event doesn't get caught
1088 by the correct emacs event map.
1090 maybe I need to set the originating window in the event structure.
1091 event.frame_or_window = Qnil; //frame; //how to get the frame here? //TODO i store it in the xwidget now
1093 since its an offscreen xwidget the buffer local keymap isnt the right
1094 place for the handler. some global map should be used.
1096 onscreen widgets don't have the same issue.
1098 anyway, seems it'll turn out like this:
1099 - xwidget-osr stores a callback and user data
1100 - the event is an implementation detail only and get caught in the
1102 - the event map calls the callback in the xw with the right args.
1104 we need the event handler at some level because we can't call lisp
1107 *** TODO console messages
1108 http://webkitgtk.org/reference/webkitgtk-webkitwebview.html#WebKitWebView-console-message
1109 http://getfirebug.com/wiki/index.php/Console_API#console.count.28.5Btitle.5D.29
1110 because maybe we can make a simple JS REPL that way.
1111 (xwidget-webkit-execute-script ( xwidget-webkit-last-session)
1112 "console.log('hello')")
1113 prints hello to stdout but theres no way to catch stdout from webkit I
1114 think other than receiving the signal.
1116 *** TODO webkit flashkiller by default
1117 while its possible to support plugins in the webkit xwidget, flash has
1118 issues on 64 bit, and slows down emacs to a halt with off screen
1119 rendering, and of course is not free software. its in the way for real
1120 world usage even if its interesting to watch flash animations inside
1121 emacs. which should be achieved with Gnash or other free software
1124 http://stackoverflow.com/questions/4885513/prevent-flash-in-cocoa-webview
1126 simply use this api:
1127 http://webkitgtk.org/reference/WebKitWebPluginDatabase.html
1129 theres an implementation now but it's not robust enough webkit often
1130 crashes taking emacs with it.
1132 *** TODO webkit downloads
1133 when clicking a download link in Webkit Emacs should take over and handle it
1134 from there. Probably need signals. There are Emacs libraries to
1135 download things, with wget etc. an url.el facility should be made.
1136 "download-requested"
1137 *** TODO webkit alt-text not handled
1138 XKCD use image-title to display a cartoon comment. These mysteriously
1139 don't work ATM. Other mouseovers work though. Maybe webkit tries to
1140 open a new window or something, which wont work.
1142 *** TODO webkit isearch in webkit buffers
1143 have a look at how docview solves it
1144 webkit_web_view_search_text ()
1145 *** TODO webkit relative references doesn't work
1146 probably because we handle scrolling in a non-standard way. It does
1147 work sort of when theres a html frameset and webkit scrolls by itself.
1149 *** TODO webkit width adjustment handling issue
1150 since there are so many levels of clipping and whatnot in xwidgets
1151 sizing issues are difficult.
1153 - an xwidget is told how large it can be by emacs. thats the end of
1154 it. if the xwidget thinks otherwise it will be clipped.
1155 - but emacs can ask the xwidget how large it wants to be. it can then
1156 resize the reserved area and inform the xwidget thusly.
1158 That should have been enough. but webkit never reports less than what
1159 it already has. So currently a webkit view will only growth and not
1160 adjust to smaller sizes.
1162 This is not a big problem in practice but is still annoying.
1164 to see the problem surface to http://www.slashdot.org
1165 - xwidget-webkit-adjust-size
1166 - xwidget-webkit-adjust-size-to-content
1168 and then compare by resizing in Epiphany, which is also webkit based.
1170 *** TODO xwidget webkit allow loading from string from emacs
1171 *** DONE xwidget-webkit-last-session
1172 CLOSED: [2011-08-01 Mon 22:38]
1173 was rather hurried. end result is that the lisp layer only really
1174 allows for one webkit session.
1175 *** TODO extract DOM to lisp
1176 then the SHR html renderer from Gnus could render the DOM as created
1179 made a simple oxperimental DOM tree traverser. It can be expanded to
1180 return a lisp representation, LDOM.
1182 in order to bring lisp and DOM closer together the LDOM can include a
1183 mapping to the originating DOM node. so, find a node in LDOM, and the
1184 cell maps to the original DOM. but since the LDOM is a copy it can get
1185 out of sync. DOM events might help.
1186 *** DONE C-X b in other buffer from webkit
1187 CLOSED: [2011-08-12 Fri 22:20]
1188 bafflingly resets the webkit view to the top. Maybe the window
1189 reconfiguration hook code? further mystification is added because it
1190 only seems to happen with ido mode enabled.
1192 in comparison with image-mode which does the right thing, I discovered
1193 that image-mode has special code to handle scrolling. the browser mode
1194 and image mode has some similarities.
1196 I made some delegation code frrom webkit mode to image mode.
1197 ** TODO xwidget image display spec compatibility
1198 some history: the first version of the xwidget display spec was
1199 the same as an image spec. This turned out not to be fantastic because
1200 an xwidget is both like a process and like an image. it has a separate
1201 existence from display. So now the xwidget display spec is just a
1202 pointer to a xwidget. But then some useful functionality in Emacs
1203 can't be reused for xwidget, in particular image-mode.
1205 Maybe a new image type could be added that was a wraper on an
1206 xwidget. Then image mode could be reused for webkit mode.
1208 I tried some adaptor code in xwidget.el so webkit mode now delegates
1209 to image mode buh its a kludge.
1212 *** TODO some flickering during redisplay of sockets
1213 with gtk3 an size allocation workaround is used.
1214 this seems maybe to result in flickering sizewize y-axis with the
1215 xwidget socket type. The webkit xwidget doesn't seem similarily
1218 the size allocation workaround works by 1st running the ordinary
1219 allocation then modifying the results. its done this way to minimise
1220 the copy paste index from the base class. it might be that the
1221 original allocation has a brief time window to show itself.
1223 tried to modify the allocation hack so it doesn't call allocate
1224 twice. this doesn't seem to help flicker at all aparently so the
1225 hypothesis falls. Maybe then a socket simply doesn't lke being clipped
1228 *** TODO xwidget view reaping too agressive
1229 hide an emacs window for a while and return to it. the xwidget might
1230 get reaped and a new socket thus created.
1231 *** DONE try out OSR for sockets
1232 CLOSED: [2011-07-25 Mon 21:30]
1234 didn't work too well in the inkscape case. it might be that some other
1235 bitmap copy method works better though.
1237 basically sockets doesn't like to be offscreen because they want their
1240 ** DONE synchronise emacs background with xwidget color
1241 CLOSED: [2011-08-11 Thu 11:04]
1242 fine-tuning to reduce flicker.
1244 isn't needed if emacs bg erase disabled
1246 ** DONE xwidgets doesn't work during bootstrap all of a sudden
1247 CLOSED: [2011-08-01 Mon 22:33]
1248 might be some annoying local issues with my install because it is not
1249 reliably reproducible. (went away during merges)
1251 ** TODO low impact xwidget based image viewer
1252 for instance to render SVG using webkit, or some other canvas.
1253 that way it would be possible to merge to trunk in stages.
1255 so, webkit could be used to display the SVG. the display spec for
1256 images would be used. multiple webkits would be used rather than
1257 offscreen rendering, so it would be GTK2 compatible.
1258 ** DONE xwidget movement doesn't work all of a sudden
1259 CLOSED: [2011-08-11 Thu 11:03]
1260 this used to work great. now it doesn't.
1264 - x_shift_glyphs_for_insert
1265 - x_scroll_run. this is run by the try_window* functions, and
1266 inhibiting them dösnt help. but also callid in scrolling_window.
1269 - try_window_reusing_current_matrix
1270 - I used to enable GLYPH_DEBUG which I currently don't. it disables
1271 many optimisations. this was fixed.
1272 - lookup_xwidget then produce_xwidget_glyph gets called always but not
1273 x_draw_xwidget_glyph_string probably because of scroll optimization.
1274 movement detection could possibly be moved to produce_xwidget_glyph(not)
1277 (setq inhibit-try-window-id t)
1278 (setq inhibit-try-window-reusing t)
1281 (run-with-timer 1 1 'redraw-display)
1284 inhibiting scrolling_window(). and this seem to be enaugh to restore
1285 old behaviour, GLYPH_DEBUG doesn't seem needed.
1288 ** DONE GLYPH_DEBUG doesn't work
1289 CLOSED: [2011-08-08 Mon 17:30]
1290 was stupid accidental line removal that was hard to spot
1291 ** TODO osc xwidget example
1292 a couple of xwidget sliders that control a csound/supercollider song with osc.
1293 so, for that to work we need slider callbacks to work. when a slider
1294 changes send an osc message. use ocssend:
1296 oscsend localhost 7777 /sample/address iTfs 1 3.14 hello
1299 http://delysid.org/emacs/osc.el
1301 sliders could be defined in csound comments or something to illustrate
1302 the point. or if real fanciness is desired parse the csound source
1303 with Semantic and provide a control buffer corresponding to the
1308 Added: [2011-08-11 Thu 10:53]
1312 the SEB site does something funny so I can't insert text in
1313 fields. aparently document.activeElement.value doesn't work with framesets.
1316 for (var i=0; i<frames.length; i++)
1318 frames[i].document.activeElement.value
1322 ** TODO support downstreams
1323 http://aur.archlinux.org/packages.php?ID=48230