[Pkg-e-devel] [Debian] E17 on the FreeRunner

[Carsten Haitzler (The Rasterman)]

On Fri, 27 Feb 2009 01:16:57 +0100 Luca Capello <luca at pca.it> said:

> Hi Carsten!
> 
> On Thu, 05 Feb 2009 23:47:19 +0100, Carsten Haitzler (The Rasterman) wrote:
> > On Thu, 05 Feb 2009 03:39:35 +0100 Luca Capello <luca at pca.it> said:
> >> I cc:ed the pkg-e-devel mailing list since they maintains E17's
> >> packages.  Please keep at least me cc:ed, TIA.
> 
> Still valid, even if I would say that everyone should at least keep the
> smartphones-userland mailing list cc:ed ;-)
> 
> >> E17 requires too much space (8.5MB) compared to Matchbox (m-w-m + m-kbd
> >> need 568kB), because of the e17 package itself (4.2MB) and the e17-data
> >> package (4.3MB).  Together with its dependencies, E17 requires 14.4MB:
> >
> > e isn't going to be small. but it does pretty much include everything you
> > need to run stuff, manage it, configure it, enter text, etc. etc. so it's
> > your baseline gui. matchbox+matchbox-kbd only do a fraction of that.
> >
> > you of course can separate out all the modules and only package up those you
> > want etc. there's a lot of modules.
> 
> My point was only to show that IMHO the current packaging of E17 in
> Debian should be rethought, exactly because on embedded devices disk
> space matters.  By default, E17 should install everything is strictly
> necessary to have a bare window manager, nothing more, nothing less.

thats not the way upstream (ie e development) sees it. e17 should install
everything for your ui to be functional and useful and get you to the point of
running apps to.. install more stuff. thats how we see it. :) you should
install it (from source as we deilver it) and have a functional desktop shell
ready to go without needing yet more companion apps just to get there. :)

> BTW, as I have already stated, I will help rethinking the E17 packaging
> in Debian, but this could take time, since this is not the only thing in
> my life (both Debian and real).
> 
> >> FYI, I have already started to think about a way to reduce E17 size
> >> and I will come back to it after FOSDEM.
> >
> > 1. use something up to date from svn helps
> 
> Please read below about this solution.
> 
> > 2. dont build every possible feature in :)
> 
> Fully agree if the feature can be available as "plug-in".

efl and e is very pluggable and flexible.  a tonne of stuff is modules. though
the point is to make them runtime enabled or disabled. a lot is built into the
binary itself so one way or another the feature is there tagging along. :)

> >> - there is no language choice (but this is the same on FSO-MS5), because
> >>   the default Debian installation does not install the locale package.
> >>   However, some locales have no icons associated to it (e.g. fr_CH),
> >>   thus they cannot be chosen from the wizard, but only in the
> >>   preferences panel
> >>     http://bugs.debian.org/514182
> >
> > e only offers language choice in its wizard for languages e has
> > translations for. icons are only offered for these as a result :)
> 
> It seems that I was not clear, I will better explain myself on the
> Debian BTS and I will cc: you and this list as well (not today,
> however).

no - i understood. the wizard doesnt offer fr_CH (for example). that is because
of the reason above. it is not considered a bug by me. it is precisely how the
code was designed to work as offering a language/locale e doesn't even have a
translation for means that e itself will not obey your request - it will not be
translated at all. also going and adding in flag icons for every possible
country etc. etc. is a tonne of work and just not going to happen. if someone
else wants to submit patches with that work - that's another matter. but
language support in the wizard will be added organically as translations for e
appear. :)

> >> - the top shelf gadgets are not clickable, but in netbook profile they
> >>   work as expected (on FSO they works as well)
> >>     http://bugs.debian.org/514185
> >
> > works for me... default out of the box. as above - try something
> > recent.
> [...]
> >> - when changing keyboard model or dict, the window has scrollbars
> >>   (vertical left and horizontal bottom, not present in FSO)
> >>     http://bugs.debian.org/514191
> >
> > again - up to date... :)
> 
> At least for me this is mostly a no-op, sorry.
> 
> I have never touched the full E17 packaging stuff, but it seems that
> because of constant API breakages in E libs, most of the time a new
> update means new names for the library packages, thus that these
> packages need to go through the NEW Debian queue again.  This is not
> only time consuming for both the Debian maintainer(s) and the Debian
> FTPmasters, but also annoying and prone to errors.

then.. you are in trouble. your distro policy basically goes entirely against a
fast development model. we are not able to help you with your own distro's
policies that slow down the rate you can adapt to changes :( there is a reason
we haven't stamped out a release - we know we change api's. more rapidly than
most places. in fact is is our plan to make lots of them to make sure once we
stamp a 1.0 on libs - it wont break much in future. do all the breaks now -
while we can.

> >> - there is no 'logout' button, but I guess this is because we do not
> >>   use the E17 Xsession file yet
> >
> > if u press "X" in the shelf while looking at the home screen you get
> > the syscon panel - and there you won't see a logout - the illume
> > profile anyway won't have it - it will have suspend, power off and
> > lock. no logout.
> 
> Thank you for the explanation, but I would still consider this a bug,
> since there is no way to terminate the session, which is something I
> expect from a window manager, being it for embedded devices or not.

that's up to you and your config. upstream (me) considers it intent/design.
there is no login session. you boot to x directly and run - you never end the
session unless you shut down. it is up to you to do your own config if you feel
otherwise. the default is much more appropriate for all the current uses of e
+illume outside debian. so forcing your policies onto everyone else by changing
a default thats already "fine" is not going to be useful :)

> >> - a button to close the virtual keyboard without passing through the
> >>   Illume panel top would be nice
> >
> > the problem is space. every control like this eats up a lot of
> > space.
> 
> I do not think that a small X somewhere next to the keyboard requires "a
> lot of space", sorry.

a small x is not able to be hit. to make it able to be hit by a finger on a vga
screen it needs to be about 80x80 pixels. that's is not a small space. you
can't do guessing like u can with actual letter keys.

> > as such in theory applications should handle this via hints - the
> > qwerty controls are there as a backup when apps get it wrong.
> 
> I consider the keyboard something which I want to control: if some
> applications show it to me when they think it is needed, well, thank
> you.  But what happens if I have a real keyboard and thus the virtual
> one just eats space on the screen?

code already detects this and disables it. if it finds a usb device attached of
the type keyboard that isnt in its ignore list file - it auto-disables. plug a
usb keyboard in and see. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com