SquirrelJME/SquirrelJME

# 2016/05/26

## 00:14

I would suppose that each list is unique for every `UIList` in a way. I could
also have the ability to dynamically relist lists just by changing their
entire state at once for example however.

## 09:11

I actually never stored `BufferedImage` into the image cache, so for each image
request it recreated a new image always.

## 11:45

Appears that Java generics are Turing complete, however it would be a feature
of the compiler for the most part. One thing that is a downfall is that during
compilation there is no real way to get the output of the program and it uses
an immense amount of memory to calculate.

## 12:15

Having an `Iterator` for the `ClassUnit`s would require complex locking to be
performed with the potential for there to be partial states and such. So I
believe it should just return an array so that there is no need to constantly
acquire locks to iterate through the units.

## 13:05

It might be best for the Jar provider implementations to also use arrays or
similar collections. Collections may be safer however.

## 15:45

Today has been a bit of a slow day.

## 16:00

I should move the program list manager and such to another class rather than
having it in the main launcher code and such.

## 18:42

Next would be having a selection callback in the list. If the callback is made
on a selected item, a new display is created which shows the many ways that the
given program could be launched. Basically it would be another list saying:
_MIDlet Launch_ (if it uses a midlet main) or _Classic Launch_ (if it has a
main class). Additionally one that will always appear would be a custom launch
which basically allows a user to input a class that has a main method to be
started for example.

## 19:32

It somewhat feels like the UI code how it is will not work out quite too well.
Everything is arbitrated through the manager and bounced off that. Component
creation and linkage is done by the manager itself. Instead of using the
manager to create components and such, they can just be `new`ed with the
display manager to use. Then that has the appropriate communication with the
native code and such. So all of the manager `createFoo` methods would be
removed and the UI classes would be instantiated directly by code that uses it.
I can however still use a similar model for cleanup and such which would not
be affected. The instantiation of components would instead just be done in
the UI fragments.

## 19:38

Another issue is the future shared state of display managers. Essentially with
the current design, every program that runs would use the same exact display
manager. Although there would be a memory reduced shared state, there would be
a problem with separation.

## 19:42

So, there would be a display manager which could potentially run in the kernel
space which is used by the launcher to run programs. Any vulnerability in the
way the manager works and the IPC backends which clients would use to access
the display would be quite bad. There still has to be a kind of integration
between them however. For example, on limited systems where there is a single
screen and all components must be laid out, multiple display managers would
have to fight to stay around for the user. Some global resources such as
system tray icons would have to cooperate in a native interface and such.

## 20:25

So I need to rethink some things.

## 20:34

I believe I will go back to the compiler, writing some of the UI interfaces
and the class unit stuff has given be the information I need for a refactor
of that code to fit better with the code I would end up with.