07:30
I wonder if I can get much work done today also.
07:38
I suppose for element cleanup, the display manager is concrete and in memory
while all of the internal display elements are concrete also. Then they just
reference to their display owners and such. The display manager would have
internal elements referenced for everything and not the outside container. The
external elements could not be placed in a WeakHashMap because it auto
manages references. I can however, send links as references already to the
internal element details.
10:05
The internal and external displays should share locks.
11:06
One thing which I can use virtually for the first time so to speak is the system tray and icons. This is after I get some more basic things working. So for example if a UI does not support the system tray natively then the display manager will just create a new display which acts as a virtual system tray. This would then give me all the needed functionality for every platform. However, for specific platforms they would have to implement some kind of system tray. For PalmOS, I can just add a tray to the top right of the application so to speak, so when icons are tapped on they perform their required action and such.
11:17
Actually, the launcher can become the display manager for applications. That is the launcher hosts the IPC server which clients connect to. The launcher wraps some of the client requests into its own thing. This way the launcher can setup a display list so that application views can just be switched to rather than just having unmanaged windows and just hoping the window is made visible. This would also mean that the display manager does not need to create its own window list somehow. Then the launcher can create a system tray icon which also provides a list of displays to be switched to. For limited systems such as Palm OS, I believe there is a limit to the number of entries that are visible in a menu, so I will need to have a "More..." so to speak at the end of the menu so that all entries can still be accessed as desired.
16:53
The selection of JARs which are available for running can just be a list of icons. On Swing this would just be a list, while on other systems it would try to match the native means for showing icons and such if it cannot directly be used and such.
21:20
An idea for a demo program, a RPG which is like The Legend of Zelda: Link's Awakening. Except this would be proceduraly and randomly generated levels and dungeons, item order, shops and towns, trade sequences, etc. There would just be a basic set of generally non-random monsters which may have a specific randomized trait that they all share.
21:32
Using a binary search to find colors will increase speed a bit because a image an could be quite large with a large number of colors. A linear search would be at least O(w * h * c) while binary search for colors means just O(w * h * log2(c)) searches. What I can do next though is have a cache of the last color, so if the same color is used for awhile then it could quickly be found. I should also move the color table reading and the pixel reading to other methods to make it easier on the compiler to compile the XPM reader effectively.