I should keep images sorted to find them better and such.


Images should probably be sorted by type first, so that black and white images appear before color ones for example. Although it really does not matter much. If I request a ARGB image and there are monochrome images, then one could be virtually created and used instead.


In the image loading, I need a way to specify the color mask or similar. Or just change the XPM color name to None instead of having magenta.


It would probably be simpler, albiet a bit slower if all the display elements used a single lock which matches the display manager. This means that the entire state of the display would be very stateful.


Well, perhaps I do not.


Well, perhaps I should, especially in the future when it comes to the IPC and such. There could quite possibly be a state where an action of one messes up a result of another command, which would be difficult to debug. So for simplicity, a single lock on the entire display.


I suppose I shall do something similar to swing and have a UIMenuItem which can be given a picture and a label of text.


Once I have a basic user interface, I can go into finding archives and determining which applications I could launch for example.


Probably going to clean up the NARF code some, move things around so that everything does not start with "native-compiler".


Menus can contain sub-menus, so I need to either extend JMenu off JMenuItem or have a new base class. Having JMenu be a JMenuItem might be the easiest. However, I would run into the base class issue. A SwingMenuItem would not be a SwingMenu which is problematic.


However, the adding code would handle these cases. I would have to do something similar for components also. So the base class for SwingMenu and SwingMenuItem would likely contain duplicate code.


Actually, the how the UI and Internal elements are managed will not work very well with this current layout. After writing the menus I would likely go into the component code next. The current means of doing things works, but the class hiearchy can be a bit complicated. Right now most of my internal code is just abstract methods. The concrete methods are helpers such as getting the associated external element. So the only way to move forward and fixing my stuff would be if all of the Internal classes became interfaces. Then the internal stuff would just extend InternalElement which has those helpers and the locks.


However, taking what I have and changing it to interfaces would be a bit ugly. Right now there are two sets of classes. The Internal classes are layered on top of the external ones. With a slight re-engineering with the usage of protected and such I can have base classes to extend. However I still run into the single base class issue.


I have grown used to the clouds visible outside my window moving from right to left, however now they are moving from left to right. What I can do instead is completely remove the Internal family of methods and then have a kind of adapter attached to the UI classes. Basically the UI is the state of the the user interface with icons, menus, and more. Then the code which provides the UI to the end user duplicates that state. However an issue with this route is that generic functionality (for example if menus are not supported) would be lost and the provider would have to simulate the standard behavior in a duplicated means. Another thing is if the UI is updated, there will need to be a series of callbacks made in order for the state to be updated.


Actually, I can do something similar to what I am doing now. There would be the UI elements which do everything and can handle many things. However, there would instead of InternalElement, it would be StateTracker<U>. This would be an interface and not an abstract class. The display manager would have a factory which can create state trackers and such for the given U. Then when an element changes and such, methods can call into the StateTracker. For certain elements, there would be variants of the StateTracker for example a MenuStateTracker. Then a SwingMenu would implement this interface. I could also just use the term NUI instead for native user interface. So it would be very similar to my existing classes. There would be binding for the native UI elements which control what things do. The mapping of internal and external or getting the display manager would be the same except the NUI implementations would handle all that information. So the UI code would just map and call into the interfaces.


Then when it comes to base classes, since everything is an interface it would not really matter much and SwingMenu could extend SwingMenuItem easily now.


Perhaps a better prefix instead of NUI. Well, I suppose it does not really matter much. Another alternative is instead just PI for platform interface, but that can work.


Also, PIBase will not have a generic type attached, it will be handled by a class cast instead.


PIImage does not make much sense, UIImage could just use the manager to create the right kind of native image to be displayed. So the PIManager would keep track of native forms of the image for example.


Also the managers being actual elements themselves is a bit ugly, so that is a no go.


Then this means that instead of the PI* classes linking back in their base constructors, the UIManager performs the linking after the objects are constructed.


The factory is ugly, I will just do a bind to the native platform kind of thing.


Right now I have an object based lock, however when it comes to the platform interfaces, they need to extend some base class to provide some lock. However that might not be an issue at all.


Definitely can feel the code being much cleaner now.


Then images could just be managed internally and such rather than requiring a PIImage as I have previously stated.


The only error which remains is: error: incompatible types: Reference<CAP#1> cannot be converted to Reference<? extends UIMenuItem>.


But UIMenu was not extending UIMenuItem, so now it is fixed. Now I just hit TODOs similar to before.


Then for the images, they will be cached and managed by mapping the ImageData to a BufferedImage before they are used for example.


So that refactor is done. Now that it is finished I can continue and work on adding menu items to a menu.


I see a bright object in the sky. It is in the southern direction, has a slight twinkle, is between beige and orange. It is possible that it is Jupiter, although it could also be Mars.


Looking at a star map, the light is Jupiter. I remember seeing a similar light around last week or so also. So Jupiter shines on me while I program, although at its distance very dimly.


When I do the actual collections and such, I should program it in a way that albiet it would not be thread safe, that in the event of failure the resulting state would be at least consistent. This would also help when it is used by multiple threads which modify an unsynchronized list.