e in framebuffer?

[Tilman Baumann]

Michael 'Mickey' Lauer wrote:

>> > with e providing a
>> > reasonable
>> > windowing environment,
>>
>> Window management on plain framebuffer? Are you sure?
>> I would be very interested in learning more about this.
>> My expectation would be that you still need some fb multiplexer that
>> needs
>> to be relatively smart.
>
> This solely depends on your usecase. If you're in for
> single-window-single-app
> paradigm, combined with some clever logic to always show a panel, then you
> don't really need window management.

Yes, but this really means always only one app _running_. (or drawing)

This would require some extensive framework and very specialised code in
the apps. (Apps need to free the fb and save the screen state and there
would be some supervision needed for managing accesses to screen
resources/and switching windows.)

I don't think we have the resources for that.
I mean, we just barely manage to make a working phone. :)

And just forget about porting apps from any other environment.

I could imagine doing this all with a evas (that rendering thingy of E, i
always confuse the names) frontend which gets instructed to draw some
scenario and connects the signals via rpc to a client...

>> Probably by rendering into a shared mem that gets composed to a fb frame
>> by some central daemon.
>
> If you do that, you quickly reinvent X ;)

My point exactly.

> Seriously though, some projects have gone that way (evoak, picogui, ...),
> but
> dropped the ball. If you really do need window managment, use X. If not,
> fb-
> only could be a very viable alternative -- if only we had illume's
> softkeyboard working...

If there is no swap out solution. I would just don't bother.

-- 
MFG
 Tilman Baumann