Tuomo Valkonen writes:
It is not currently easy to simply replace a part of the drawing engine, but
with small modifications inheritence should allow for that; see a part of
a discussion I had with Andreas Happe below.

This is very promising.


- provide a much high level interface, something like:
draw_frame(<dimensions>, <list-of-tabs>, ...)
do_minibuffer(<prompt>, <completion-func>, ...)
do_menu(<location>, <menu-items>, ...)

No. In the current implementation drawing engines don't have to know
anything about the objects they're used to draw (but they do have that
information), and that's how it should be. With your proposed method the
drawing engines would have to have specific support for all possible objects and extended always when a new object is added, and that is a
maintenance nightmare.

Yes, but realisitically how many objects are there to draw? Look at your ion workspace now. I count:
- ionws-frames
- ionws-frame-tabs
- tabs-being-dragged
- floatws-frames
- floatws-frame-tabs
- minibuffers
- menus


IMHO, the frame/tab code should be merged to a single call, and floatws-frames are really just small ionws-frames, so I think that makes four function calls:
- draw_frame
- draw_dragged_tab
- do_minibuffer
- do_menu
What have I missed?


Something gtk-based would not be a drawing engine but a reimplementation
of all of Ion's policies into something totally different.

I don't understand why this should be the case.


Cheers,
--
Tom

Reply via email to