having X11+matchbox (http://projects.o-hand.com/matchbox/), how should we focus the porting of applications? To follow the maemo scent, aiming even for binary compatibility? To hang on the GPE roadmap (http://www.handhelds.org/moin/moin.cgi/GPERoadmap)? Or simply wait and see?

I see no real use in porting all the software for {qtopia|opie|gpe|qpe|familar|my grandmother}.

Playing with the device, I'd say that every minimally interactive application will be a pain in the ass on the iliad. Simply typing in username + password was no fun at all.

The iliad is great at displaying mostly static content, and we'll need clever applications for that.


However, I'm sure people will port applications, it will be a bad experience with ultra-slow screen updates, and another situation where linux-newbies get to see the worst a linux can perform, as usual.

Actually you get the hang of typing stuff and not seeing what you typed. Thats not so bad. Even draging windows across the screen is fun :) And i think attaching a usb keyboard and then typing with updates every few seconds could be nice.

So i would still like to see some pda functionality. Mainly calendar, maybe addressbook.

calender would be cool...you don't need a fast display for that...

me too...plus

*Outlook synchronization

I opt for the meomo scent...although I am no expert at all.

A sequential image viewer would be good. (particularly one that can cope with the images in a cbr or cbz format)

@Riocaz:

OT: Do you have any news on the whereabouts of your Iliad yet?

Yup!

I've just (well since I left work) received the tracking number.

It's in the vicinity of Onceways' device and still in Germany...

It's not so bad now that I know it's enroute.

I see no real use in porting all the software for {qtopia|opie|gpe|qpe|familar|my grandmother}.

Playing with the device, I'd say that every minimally interactive application will be a pain in the ass on the iliad. Simply typing in username + password was no fun at all.

The iliad is great at displaying mostly static content, and we'll need clever applications for that.


However, I'm sure people will port applications, it will be a bad experience with ultra-slow screen updates, and another situation where linux-newbies get to see the worst a linux can perform, as usual.


Perhaps we should first to keep an eye in the wishlist (http://wiki.mobileread.com/wiki/ILiad_Software_Wishlist), see what we can port, and what needs to be done.

Perhaps we should first to keep an eye in the wishlist (http://wiki.mobileread.com/wiki/ILiad_Software_Wishlist), see what we can port, and what needs to be done.


Yup, there is more than enough to do ;)

Greetings,
Frank

Sorry for the frustration, but I've seen this before. I have a Zaurus, and initially it was fun to port all kinds of software to it.

In the end, all the efforts turned the thing into a bad subnotebook and not a good pda, at the cost of a cheap real subnotebook. It's somewhat cool to run freeciv on it, but that doesn't help at all when there's no real calendar and my laptop runs freeciv just so much better.

I would like to see the Iliad becoming the device for reading -- which means blazingly fast rendering times and low energy consumption.

However, the disappointing truth is that the software on the Iliad is just a cheap collection of desktop software ports. You can easily port freeciv. But I cannot imagine that powersaving will ever really work. And the pdf renderer is just xpdf (which uses a lot of fpu operations, right?).


Frustrated:
ali

Sorry for the frustration, but I've seen this before. I have a Zaurus, and initially it was fun to port all kinds of software to it.


Yep, we need something more creative than simple porting. For instance the high view angle of eink, plus wireless ability, should let for multiplayer games more interesting than crimson or freeciv.

Our funnier work in the Zaurus was a mouse interface. We captured a light with the camera and translated its moves to mouse moves, which in turn we sent via USB to the host computer. So yes, creative work is more satisfying in the long run.

And the pdf renderer is just xpdf (which uses a lot of fpu operations, right?).

Hmm sure? There is not a fixed point mode (just guessing)?

which part of power saving shouldn't work, in your opinion?

Clocking down the processor, check, making the whole thingie hibernate, check. Both i can even do on my notebook running linux. Anything else? Ok, switching wlan off. Here i trust in iRex.

And concerning the pdf renderer: what's easier to do: write your own alternative pdf viewer for a running linux with an X server or do everything from scratch on a new device with strange new custom-built OS which most probably would never receive a proper SDK?

what's easier to do: write your own alternative pdf viewer for a running linux with an X server or do everything from scratch on a new device with strange new custom-built OS which most probably would never receive a proper SDK?

Not easy to answer. Nobody has done a more decent xpdf for decades.

Still, we have a machine three times faster than the Nokia 770 (according the bogomips loop) and four times faster than a librie. We could do something creative.

My own intention, primary, is to be able to read .tex documents and djvu scans from the P2P network. So I am sorry I am not going to be creative :-(

However, the disappointing truth is that the software on the Iliad is just a cheap collection of desktop software ports.

That's indeed very disappointing. I haven't followed the many Iliad discussions going on recently, so this is news to me. I can imagine developers sitting on the fence on whether to develop Iliad-specific software. I presume their API is not cross-platform.

which part of power saving shouldn't work, in your opinion?

Clocking down the processor, check, making the whole thingie hibernate, check. Both i can even do on my notebook running linux. Anything else? Ok, switching wlan off. Here i trust in iRex.
You can write software that does things efficiently. keep filesystem access low. do not spread things among processes that need inter-process communication protocols. Do not use a windowmanager that checks all the time if some window decorations have to be drawn, windows have to be moved or updated, if you don't intend to actually show some windows. Write applications that *know* that the device is single-user and essentially single-task, so they can throttle the processor when there's no user interaction - as opposed to when some heuristics notices there's no processor load.


And concerning the pdf renderer: what's easier to do: write your own alternative pdf viewer for a running linux with an X server or do everything from scratch on a new device with strange new custom-built OS which most probably would never receive a proper SDK?
I don't know. I remember someone describing a commercial Zaurus pdf viewer (should be easy to port) that was written from scratch for this cpu and unbelievably fast. For 670 Euros I'd expect a little bit more than xpdf. But it looks to me like they took the easy road everywhere. As if everything was temporary dirty hacks that became permanent.

I don't know. I remember someone describing a commercial Zaurus pdf viewer (should be easy to port) that was written from scratch for this cpu and unbelievably fast.

Picsel Browser. Seeing is believing:

little review with video (http://www.oesf.org/forums/index.php?showtopic=12436&hl=)

EDIT:

The interesting thing was, that it did open huge PDF, all it needed was enough memory...