On Tue, 2003-05-06 at 18:05, Carsten Haitzler wrote:
> On 06 May 2003 19:08:08 -0300 pirata <pirata@...> babbled:
> > Forget existing apps by now (I think that having ewl interface similar
> > to gtk it's not a big mindroaster problem have a gtk to ewl port, most
> > of the work can be done by eg: #define
> > gtk_button_new()-->ewl_button_new() )
> > My point is this: E can, with not so much effort, run in the fb, it can
> > CREATE windows (can't it?), so it can be written an evas protocol that
> evas can run in the fb, e cannot. and no - it would be a lot of effort. we'd
> need to create a windowing system within ecore_x - and still make evas use it. E
> is an X11 window manager. what you want is a new/different application
> alltogether. it may use evas, eet, edb, ewl, ecore etc., but its not a window
> manager and it's not E.
> > communicates with E only to create the MAIN window (E creates it & pass
> > a pointer to evas, it is not so far to what E does in X, it doesn't
> > creates main windows, but really manipulates them, I'm think I'm not
> > soooo crazy), then the rest of the work is done by evas itself in the
> > window's pointer created by E, as it would be created by evas.
So it can definitly be done. The question is, would it be worth it... Is
evas fast enough that if it were to take over X's responsibilities
things would be faster? If that's true, it might be worth the effort to
at least keep this in mind for the future.
As far as I can tell, Evas is the only library that accesses X directly,
right? If that's true, then it would be easy (but a lot of work) to
change things around to make evas do all the window drawing if that's
what people wanted later down the road.
Speaking of speed, is anyone familiar with benchmarking that kind of
> > Can or can't be? That is the question!!
> > Pirata
> > If that is totally imposible, I'm very sorry to be so ignorant, I know
> > nothing about low-level programming, but it was an idea very pleasing
> > to me.
Wesley Leggette <wleggette@...>