iRex Releases iLiad Source Code

[uso]

Originally Posted by jharker

Hardware buttons are handled via GTK/X as key presses. So you should be able to get that pretty easily from within Java. See my extensive discussion in this thread. All hardware buttons except the special folder buttons ("books", "news", etc.) are handled this way.

That thread also discusses how buttons are handled at a more basic level.

Ah.. thanks for the info. That will simplify matters.... - I´ll go looking at that thread :-)

Uso

[Shaggy]

Originally Posted by uso

I doubt they will release the Mobipocket viewer... but depending on how they have structured their code, they may be able to release the code for interacting with the hardware buttons.
This code would be a library for use from other programs, not a complete program by itself.

That code isn't java though. I thought the button driver was written in C.

[axel77]

Originally Posted by uso

It won´t be the best choice for new development, but easier porting of existing java-applications could potentially be useful :-)

Uso

Sure, if "run everywhere" should be included the iLiad, its nice to have quick porting, that was what java was about. But

The framework for buttons/pagebar/refreshing could be quite useful for those of us who prefer programming in java...

It strongly advice against picking java for the iLiad, just because the dev for an Iliad dedicated application "prefers it", probably because of its development comfort, or beacuse he didn't yet went through that C tunnel.

[ericshliao]

Originally Posted by uso

Hi

Any chance that some of the iliad java-code could be released as well?
The framework for buttons/pagebar/refreshing could be quite useful for those of us who prefer programming in java...

Uso (so this i what delurking feels like )

There is a java sdk jar (I forgot its exactly name) in your iLiad. Everything about refreshing, toolbar, pagebar, button are over there. Use a java decopiler and then you can see them.

There are also a few 3rd party java based viewer for iLiad. Decompile and you can see how java works on iLiad. It's quite simple. I think its more easy to program in java than in gtk+ for iLiad. But java class on iLiad is quite limited. So you can't do some fancy design on iLiad in java. C (or C++) and Gtk+ are more capable for sophisicated application on iLiad.

[ericshliao]

I must add that refreshing is never a problem in java code for iLiad platform. In comparison to GTK+, java code works well just as you program on PC. It makes developing a iLiad java app more easy. Besides, based on my experience, on iLiad, java seems to provide better memory management than C. For an experienced C programmer, it's not a problem. For a medicore C programmer, like me, it's hard to implement perfect memory management.
In addition to limited java class on iLiad, there is another drawback for java on iLiad, that is, you can't hide toolbar and pagebar. In contrast, it's easy to do it with GTK+.

[ericshliao]

Originally Posted by uso

I doubt they will release the Mobipocket viewer... but depending on how they have structured their code, they may be able to release the code for interacting with the hardware buttons.
This code would be a library for use from other programs, not a complete program by itself.

Uso

Use java decompiler and you can see source code of mobipocket viewer. But I think few people can figure it out how does it work. The code is hard to read.

[joelypolly]

just found this i the powerManagement in content lister
// TODO: More powerManagement functionality needs to be implemented here...

made me laugh and cry a little

[axel77]

Originally Posted by joelypolly

just found this i the powerManagement in content lister
// TODO: More powerManagement functionality needs to be implemented here...

made me laugh and cry a little

The tradegy is, in the 1000 is the same TODO....

[jharker]

Actually... I'm not sure what that comment is talking about. It may be a holdover from when we were implementing power management (CPU scaling) in each application simultaneously....?

Now there's a single program that automatically does CPU scaling for everything, all the time. They probably just never took the comments out. I think it's kind of cool to see the thought process on how some of this stuff was developed.

[zerospinboson]

Originally Posted by jharker

Actually... I'm not sure what that comment is talking about. It may be a holdover from when we were implementing power management (CPU scaling) in each application simultaneously....?

Now there's a single program that automatically does CPU scaling for everything, all the time. They probably just never took the comments out. I think it's kind of cool to see the thought process on how some of this stuff was developed.

..which already works at maximum efficiency? (ie. why is it also in the DR then?)

[jharker]

Originally Posted by zerospinboson

..which already works at maximum efficiency? (ie. why is it also in the DR then?)

Well, I would guess that quite a bit of the code from the iLiad was copied when writing the code for the DR. If the DR's hardware is based on the iLiad's then some of the same code would be quite useful.

At the same time, I was wrong to imply that CPU scaling is the only kind of power management. Depending on the hardware it may also be possible to turn various things off when they're not needed; it's possible that some of that has yet to be implemented.

Also, iRex is talking about implementing suspend-to-RAM on the DR in the future, so maybe it has something to do with that?

[DigiDirk]

Just to reuse this thread and in case nobody has noticed before

Part 2 of the sources have been released roughly an hour previously.

Dirk