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
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
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
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
when an element changes and such, methods can call into the
For certain elements, there would be variants of the
StateTracker for example
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
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.
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
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
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
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>.
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
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.