09:29
I should keep images sorted to find them better and such.
09:41
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.
12:18
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.
14:51
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.
14:53
Well, perhaps I do not.
14:54
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.
15:18
I suppose I shall do something similar to swing and have a UIMenuItem which can be given a picture and a label of text.
15:25
Once I have a basic user interface, I can go into finding archives and determining which applications I could launch for example.
16:11
Probably going to clean up the NARF code some, move things around so that everything does not start with "native-compiler".
16:13
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.
16:17
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.
16:19
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.
16:59
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.
17:05
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.
17:12
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.
17:18
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.
18:12
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.
18:19
Also, PIBase
will not have a generic type attached, it will be handled by
a class cast instead.
18:24
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.
18:26
Also the managers being actual elements themselves is a bit ugly, so that is a no go.
18:27
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.
18:32
The factory is ugly, I will just do a bind to the native platform kind of thing.
18:54
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.
19:08
Definitely can feel the code being much cleaner now.
19:15
Then images could just be managed internally and such rather than requiring
a PIImage
as I have previously stated.
19:17
The only error which remains is: error: incompatible types: Reference<CAP#1>
cannot be converted to Reference<? extends UIMenuItem>
.
19:19
But UIMenu
was not extending UIMenuItem
, so now it is fixed. Now I just
hit TODOs similar to before.
19:36
Then for the images, they will be cached and managed by mapping the ImageData
to a BufferedImage
before they are used for example.
20:44
So that refactor is done. Now that it is finished I can continue and work on adding menu items to a menu.
22:01
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.
22:05
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.
22:11
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.