proposal: how to the unify the user interface
marc.zonzon at gmail.com
Tue Jul 6 18:17:19 EDT 2010
On Mon, Jul 5, 2010 at 11:49 PM, Rafael Ignacio Zurita
<rafaelignacio.zurita at gmail.com> wrote:
> But it was not a work of a couple of weeks, the Vargstas main developer has tested
> and configured a lot of applications on X, so we found the best ones.
> So I would say that X is pretty nice if you set properly the
> environment/applications to use few resources and the little screen, and people
> here, who have tried Jlime before, in HP Jornadas, would say the same I guess.
> I thinkt that the challenge in nn is NOT CPU/RAM, but the tiny screen, and a huge
> list of X applications is waiting to be tested and set properly, so we
> can find the best ones.
> But, of course, Nokia has tried (surely) to use the latest versions of many
> applications perhaps, and that could be hard in embedded systems. For example,
> I would say, from our previous work on Vargtass, that gtk2 applications is not
> a good idea neither, for HP Jornadas, nor NN. Maybe if the program is just too
> simple works well. But we have seen/tested that these never worked nice.
> Regards, Rafa
> Qi Developer Mailing List
> Mail to list (members only): developer at lists.qi-hardware.com
> Subscribe or Unsubscribe: http://en.qi-hardware.com/mailman/listinfo/developer
For my Debian-nano experience I agree with Rafa, while I found the
full Xorg very slow on Nano, Xfbdev run nicely, with a low memory
footprint and processor load.
After some window manager trials I have mainly used Ratpoison and it
also run well with modest resources.
And they are in Debian-mipsel as in Jlime dozens of apps that run
nicely under Xfbdev+ratpoison.
Some could probably be ported to framebuffer, and some may be lighter
or quicker, but it seems that we have to wait quite long before fb
support the same software than X.
I suppose that even the use of input methods, is not so simple in frame buffer.
But I love and use framebuffer when available, and it is can be very
nice even with very complex applications, on my desktop I have used
vlc, xine, mplayer in framebuffer.
Of course on nano, they are too big, but a frame buffer pdf or image
viewers are nice and I use them.
I like a lot the console too, but I'm not a console extremist that
look only to pictures or video when displayed in ascii!
I also agree with Rafa in saying that the challenge of nano is not
cpu, and if nano is ram challenged, it mainly suffers from its 320X240
screen, we surely need to display lines of 80 cars, on nano it lets
you 4 pixel by car cell, so with 1 pixel border your glyph must be 3
I am developing presently a 4x8 console font, but I must say that it
is not as legible as I want, and It will not include all unicode
blocks that I wish.
Nano is also challenged by the lack of pointing device and a touch
screen will be welcome.
So my wish for my next Christmas Yanano is "please QI brings me more pixels"
and also along with the Yanano provide also a second device with
exactly the same hardware but a big screen and it will be a marvelous
reader on wich to port openinkspot, but not a reader-only device as
most e-ink readers today but a multipurpose device.
Of course the price of Yananoreader will be higher than Yanano due to
the screen, but it will not add any development cost but the screen
More information about the discussion