LunaSuite Pro Logo


Home

Announcements

Features

Documentation

Download

Support

Registration

Developers:
    Overview
    Requirements
    Architecture
    To-Do
    CVS Repository

LunaSuite Pro
Developers : To-Do



Obviously I have forgotten about many of the issues we still had with the LunaSuite, below are some of them that should give you an idea of the plans we still had for future versions:

License codes:
Currently users need to get a (free) license code in order to use the LunaSuite. Lunatech no longer wants to run this database but we have to until there's a LunaSuite version without the license codes. This could be as simple as removing the checks for it. A more thorough way would be to simply remove the entire license manager...

Unicode HTML parser:
The email stationary and coder systems supports unicode without any problems. One of the first steps in decoding an email (or one of the last steps in encoding an email) is character set conversion and tagging. The external character string is converted to an internal unicode string. The problem is that the HTML parser could so far only work with 8-bit character strings with iso-latin-1.
I started working on an HTML parser that could handle unicode characters. So, instead of working on an 8-bit string, it worked on newton unicode strings (2-byte chars). I wrote all the code for the parser but I don't think I ever compiled it because of strange casting problems with the NCT. Also the code that generated the HTML source code from the parse tree (called by 'View Source') still needed work.
The alternative HTML can be found next to the regular HTML parser at Sources:Libraries:LibHTML:C++ LibHTML UniCode.

HTML Stationary:
The HTML stationary (the display for HTML) had some problems with scrolling in some cases. This thing is awfully complicated, perhaps too complicated. Behind the scenes it hacks around bugs in the protoTXView and other bugs in the Newton, while staying within the limits of the Newton memory management. This means that we could not render ahead much.
The solution we picked was to only render to the end of the page. When a user scrolls we adjust the views. All sorts of problems pop up when you start scrolling down. Things get even more complicated when you start dealing with tables.
In a perfect world this thing would be implemented in C++, however, Apple would never give us access to the API's for this.