eiffelws-list

Re: [Eiffelws-list] EWS

[Daniel F M. <dmo...@ex...>]

On Sat, September 16, 2006 12:34 pm, Raphael Mack wrote:
> Hello Daniel,

Hi,

> what do you think of EWS? I'm doing a project with an embedded system
> and think about using ews for it.

Cool! Hope you don't mind I also send this answer to the ews mailing list at
https://lists.sourceforge.net/lists/listinfo/eiffelws-list

> So far I write directly to the framebuffer and render text using
> freetype. This works fine and is fast. I don't know yet whether I want
> to use SDL with EWS or whether I will write a second backend (shouldn't
> be that hard, I think) or stay with my own thing and implement windowing
> there. E. g. I'd also need the possibility to poll other inputdevices in
> the event loop.

It depends. If you just need some drawing, Just using SDL in a more direct
interface is enough. If you need windowing, widgets, complex event
handling, focus and that probably EWS is for you, and will save you some
time solving some tricky interaction issues. Adding other input devices is
not very hard (I've got a project where I put network messages into the
event loop, for example), more if they are already supported by SDL.

If you just need SDL, some classes in EWS (like SDL_SURFACE) are direct
SDL wrappers and can be used without depending on EWS.

EWS should not give you a large performance disadvantage (most of the time
in EWS apps is spent inside SDL, doing blitting/rendering); freetype fonts
are supported in the CVS version.

> Since my project is se2.3 based ews would have to be ported. Do you have
> any plans here?

I have not commited every change, but just changing the name of the
external methods (like SDL_UpdateRects to sdl_update_rects) solves all the
portability issues needed to run EWS on SE2.2. Let me know if something
else is needed to move to 2.3

> Do you think a 2.3 aware version should also work with
> 1.2? - e.g. on my system I do not have set SmartEiffelDirectory anymore
> and such configuration would be more complicated if we support both...

I am using EWS with some 1.2 projects (that eventually will move to 2.x,
but I have not time for hta yet), so I strongly prefer keep it compatible
with both. Let me know which configurations problems you have and I will
try to fix them, at EWS or at SE1.2

Regards,
     D.

Re: [Eiffelws-list] EWS

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

Am Samstag, den 16.09.2006, 13:22 -0300 schrieb Daniel F Moisset:
> > So far I write directly to the framebuffer and render text using
> > freetype. This works fine and is fast. I don't know yet whether I want
> > to use SDL with EWS or whether I will write a second backend (shouldn't
> > be that hard, I think) or stay with my own thing and implement windowing
> > there. E. g. I'd also need the possibility to poll other inputdevices in
> > the event loop.
> 
> It depends. If you just need some drawing, Just using SDL in a more direct
> interface is enough. If you need windowing, widgets, complex event
> handling, focus and that probably EWS is for you, and will save you some
> time solving some tricky interaction issues.

This is exactly what I want. Concerning SDL the thing is that I do not
like additional dependencies and I just tried it out: SDL does not just
compile for my target (arm based) and I am not very enthusiastic in
getting it work. The idea is to implement another backend for ews, which
does not use SDL, but directly writes to the framebuffer.

Rapha

Re: [Eiffelws-list] EWS

[Daniel F M. <dmo...@ex...>]

On Sat, 2006-09-16 at 20:27 +0200, Raphael Mack wrote:
> > 
> > It depends. If you just need some drawing, Just using SDL in a more direct
> > interface is enough. If you need windowing, widgets, complex event
> > handling, focus and that probably EWS is for you, and will save you some
> > time solving some tricky interaction issues.
> 
> This is exactly what I want. Concerning SDL the thing is that I do not
> like additional dependencies and I just tried it out: SDL does not just
> compile for my target (arm based) and I am not very enthusiastic in
> getting it work.

Oh, I did not understand that in your first email

>  The idea is to implement another backend for ews, which
> does not use SDL, but directly writes to the framebuffer.

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

Regards,
	Daniel

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

Re: [Eiffelws-list] EWS

[Daniel F M. <dmo...@ar...>]

On Sat, 2006-10-07 at 13:50 +0200, Raphael Mack wrote:

> 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

I know imageMagick provides a lot of imaging functionality, and there
are several libraries for this embedded in some other places (some for
SDL, others like GDK-pixbuf).

> 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?

It would be cool, but doing this in Eiffel is probably reinventing the
wheel.

> 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.

It is somewhat copied from GTK. Please let me know if I can help with
it...


> 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...

You should plug that into the "wait_event" method of the display. If you
redefine correctly wait_event and poll_event, you should not need any
special loop handling

Otherwise, it is a bug :)

Regards,
	D.
-- 
"Why program by hand in five days what you can spend five years of your
life automating."
            -- Terrence Parr, ANTLR author