Re: [Eiffelws-list] EWS

[Raphael M. <rm...@st...>]

Am Montag, den 25.09.2006, 20:20 -0300 schrieb Daniel F Moisset:
> Tell me about your success and your problems... I designed EWS thinking
> about other possible backends, but never implemented one It should not
> be hard to do so (note that everything outside driver-sdl is SDL
> independant, or should be); you should implement a driver-arm (or
> whatever you like to call it) redefining proper children classes for
> DISPLAY, and IMAGE at least

I played a bit with driver-fb, and succeeded displaying a bitmap button.

One bigger task will be the implementation of an image library
respectively wrappers for existing libs. Does anyone know about some
efforts for this? Would an eiffel-imaging library be appropriate to
provide some classes for color and images, like

deferred class IMAGE
feature
	width, height: INTEGER is deferred end
	pixel (x, y: INTEGER): COLOR is deferred end
	as_pixel_image: PIXEL_IMAGE is deferred end
end

class PIXEL_IMAGE inherit IMAGE
	pixels: NATIVE_ARRAY[COLOR]
end

expanded class COLOR
feature
	red, green, blue, alpha: INTEGER_8
end

Then wrappers can provide subclasses e. g. PNG_IMAGE which wrap the
images loaded by the lib or convert it to a PIXEL_IMAGE.

What do you think?


I don't understand the internals of input handling redrawing and the
eventloop completely. I had problems, that the screen was not drawn
until the first event occured, for now I just generated artificial mouse
moves.
In the end I'd like to have a bunch of INPUT_DEVICEs, with each having a
file descriptor and the eventloop should do a select syscall to wait for
input on any of these (and something equivalent on non-unix boxes). I
didn't study the LOOP_STACK in se's lib in detail, but it seems to do
exactly that...


Rapha