Hi!
Sebastian Spaeth wrote:
> On 01/07/10 21:18, Zoff wrote:
>> i've been saying this for a long time, shr is not trying to get the basics
>> working. just more and more features,
>
> Which more features are you referring to? Like the ability to make and
> receive a phone call? ;-P Or to actually be able to save a phone contact
> with a name? Other than that I don't see us implementing the highly
> advanced smartphone features that we could potentially have on such a
> phone (unfortunately).
i mean buttons in call,dialer,messages and phonelog are still at random place.
there is no consitant "close"-button with those apps, some have close-button
some dont.
those things seem rather basic to me.
and that the "new" shr is crashing all the time has not changed. also i found
that other people also have this
problem. so this seems to be worth finding out. but i dont get any hints how to
do this. and i tried stuff
but with no results, so i dont know what to do anymore.
thats seems also rather essential stuff to me. when i cant keep the damn thing
running long enough to
test anything. i am hoping for kernel 2.6.31 but i will not come that soon :-(
>> but no stability. the only reaction to this is that i get flamed. well so be
>> it.
>
> No, you won't get flamed. Why? We all know that stability and
> SHR-unstable are not 2 things that go together.
maybe i like getting flamed :-)
>
> > JaMa has got his way with those 2 icons, my god. they are not even
> the same size or color, why?
> I can't comment on the 2 icons decision, but if you don't like the icons
> why don't you check in better ones?
well i think i said enough about the "2-icon-solution"
whats really crazy is that JaMa's argument was installing 2 packages is sooo
complicated.
but now you have to install navit by hand anyway, and you have to install 3
packages now!
navit, navit-locale-*,navit-icons
what should be done (and i have done with patches and all) is:
you install ONLY 1 package -> (example): navit-austria-car
dependencies are:
navit-austria-car (the icons and some .xml files are in this package)
-> navit-locale-de_at
-> navit-icons
-> navit
-> espeak
or
navit-austria-bike (the icons and some .xml files are in this package)
-> navit-locale-de_at
-> navit-icons
-> navit
-> espeak
or
navit-germany-car (the icons and some .xml files are in this package)
-> navit-locale-de_de
-> navit-icons
-> navit
-> espeak
there cant be a simpler way than this.
also this kind of packaging would conform more to other navi's you can buy.
you normally buy D-A-CH or "alpen" or somehting.
then you could make a package "navit-DACH-car" or "navit-scandinavia-train" or
what ever
for all others there should be a default package:
lets call it "navit-default-car", dependencies would be again:
navit-default-car (the icons and some .xml files are in this package)
(this time no locale, its just en_US)
-> navit-icons
-> navit
-> espeak
> > the navit.sh script has been dropped, now locales and countries won't
> work, wow thats great.
>
> It has been dropped because it did 2 things:
> Setting the /sys/proc/vm/overcommit to 1 which can cause mysterious
> crashes which we don't want in SHR as they are impossible to debug.
overcommit was dropped from the script long ago (by me and also by JaMa)
>
> and second unset LC_ALL,
http://wiki.openmoko.org/wiki/Navit:
"Make sure, that LC_ALL ist not set though.
Otherwise navit fails to interprete gpsd output and you end up with strange gps
coordinates."
from ./navit/main.c (current svn version!):
if (getenv("LC_ALL"))
dbg(0,"Warning: LC_ALL is set, this might lead to problems
(e.g. strange positions from GPS)\n");
so i think we should not try to be smarter than the navit devs :-)
>
> SHR does export a LANG=en_US.utf8 setting in /etc/profile (or somewhere
> else in /etc, I forgot). No need to always call a script to set it
> again, right. Change it in the correct place if you want. If we unset
> LC_ALL and it works for you, it won't work for others. I am all for
> accepting patches, but just calling more wrapper scripts because the
> correct environment is not set up properly in the first place, does not
> sound very appealing to me.
>
> Ususally, an app that has to touch LC_ALL, is pretty much broken.
> If you convince us that it is actually useful and needed, then let us
> simply add it to our .desktop file.
here you are wrong, i wrote about this maybe 10 times. but nobody will listen.
e17 sets the LC_* vars wrong! (when you dont use en_US)
if you install de_AT locale, and then you change language setting in e17 you
can only choose from:
de_AT
or
de_AT.ISOxxxx something
but de_AT.UTF8 is NOT selectable, and also you cannot enter a custom string.
some time ago i could overwrite this with
enligthenment_remote, but language setting feature was removed with the new
d-bus (shitty) version.
so my conclusion is/was to use a wrapper script. because waiting for some guy
to fix e17 will take a long time.
>
> > flite it still installed as a dependency, but its not needed.
>
> I made those optional now (espeak and flite were RECOMMENDed before,
> which means that package manager would install it by default, now they
> are SUGGESTed which means they won't be installed by default. But if
> already installed, they will not be uninstalled.
i used the image from 2 days ago and opkg install navit, and flite got
installed automatically
i think filte dependency maybe is in "espeak" package also?
>
> > the default config style wastes so much display space it hurts.
> AFAIK it is based on the upstream default config. What changes do you
> propose? The best is not just to post a wholesale navit.xml, but to
> propose small patches that we can apply that fix display issues.
if i think that my changes will be dropped then i wont send more patches.
maybe i will just create an "navit-austria-car.bb" and "navit-germany-car.bb"
what is the opinion on that?
>
> > and (for reasons i dont know yet) display redrawing is terrible slow.
> Neither do we.
we should find out then :-)
> _______________________________________________
> Shr-devel mailing list
> [email protected]
> http://lists.shr-project.org/mailman/listinfo/shr-devel
--
"My malpractice insurance doesn’t cover alien autopsies."
_______________________________________________
Shr-devel mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-devel
