08:03
One thing I should add to the readme is how to actually obtain the repository. Also perhaps a tarball or ZIP of the latest trunk.
08:24
I should also put the non-code resources under the CC-BY-SA 4.0 since that makes sense.
09:07
And now that is cleaned up. As for all the header files, since they are source code I will not be putting down the CC-BY-SA 4.0 in them at all since it would not make any sense.
09:43
Well the label works outside of the list, which is nice.
11:09
GridBagLayout is a pain to use when it does not work as one desires. I want
the components to stretch horizontally and be stacked on each other.
11:15
Actually, gridwidth/gridheight are the number of cells that are used for
the component, not the total number of items in the table.
16:11
Even before events are handled, I now have enough to be able to search for programs to be executed by the launcher. So as such I now need to write the archive finder interface and such, similar to before but better. I can use the service loader to provide all possible JARs that could be used. Ones that are internal to ones which are on a filesystem.
18:32
Once I get an application list of sorts, potentially the first idea which I have is for an interpreter that is deterministic especially when it comes to cycles and threads. I can also have it so everything is deterministic for the most part, except for UI access. I could provide a GUI for internals of threads such as which objects are allocated. I can also potentially have the ability to record and replay execution. This would be for debugging purposes to make sure programs run correctly and such.
18:40
What I need however, is a name for the archive system. Effectively though the code would be used as a classpath and consist of class path elements and such. They would be class path providers. So I suppose class path is the way to go.
18:46
The classpath would also in a way replace the locator bits. There can also be
verification in actual existing class paths. So basically, I will have class
path element providers which provide singular class path units. Then these
units would be combined into multiple class paths. So for standardness, I
would say ClassUnit being a single collection of classes while ClassPath
being multiple ClassUnits which make up a class path. Also, if multiple
programs are using a shared but not exactly the same set of ClassUnits then
they can share commonly cached information and basic class verification. If
two programs have the same exact class path they can share the same ClassPath
object.
22:42
With the way the program will work and UIs may be written, having UIList be
a container which contains UILabels is going to be very ugly. What I need to
do is make UIList not a container for one. Then after that I need a kind of
list data view which can be assigned to a UIList or created from it. The
data storage would be of the actual list class so it can be used like a normal
collection. If the list changes, then it tells the UIList that it changed.
Another consideration is giving it the ability to generate an icon possibly
along with the text to be displayed. So instead of a ClassUnitInterface it
is just a specialized version of the list data, which can extract the icon and
program name from the code. When all the programs are read in, they would
be stored into this list. The number of elements in the list would
automatically be determined and rendered accordingly.