01:51
Having all of the static fields for key indexes is going to be very messy for the most part. It also will consume a bunch of the class space code and such as well.
01:53
I really just need a better way to map keys and such, perhaps with scan codes and whatnot. Then additionally a scan to keyname kind of thing.
12:24
I have command buttons on the side, but honestly that would be hard to draw with vertical text, so back to horizontal.
13:32
I need an enforced drawable area graphics which forces a given clip to be used no matter what. This is for canvases and such. It has to handle the clip and also additionally as well translation.
20:59
I am seeing a need for a scrollable area that I will have to act on and such. I am going to be writing the scrolling code over and over again so I think the best thing to do is to make a scrollable drawable area. That can simplify and pass through events. Also the scrolling code will be shared by lots of other code as well. So I suppose what I need is a virtual draw slice which it just manages and such. What I have now works though although it is pretty ugly and rigid. Although it is much better than what it was before. Implementing alot of the widgets is going to be ugly since LCDUI is not really the best.
20:56
Perhaps I am conflating event handling with drawables. The only thing is that LCDUI is just super messy and it is really cracked and hacked together for the most part. I do not even think I can write a sane looking implementation with the way that it works.
20:59
The good thing is that I actually have the event code and such. The event code is fine and so is the wrapped VM code. It is just that drawing everything is a huge pain. It might be best if the drawing specific code were separated into its own place, that might make things easier. LCDUI is a big part of the interface and I have already rewritten it a number of times. Actually, this may be the thing. I know I had problems with object oriented stuff because I tried to design the stuff this way. But honestly I do not think this will work. I am going to need a class which is basically an abstract class but it provides me direct access into all of the LCDUI internals of everything that is thrown at it. Then I might be able to get rid of some widgets and such. But it will be a class which provides access to the internals. That is really the only way I think it will be clean.
21:38
What I need for the array graphics is a permanent clipping rectangle because the buffer would overflow and it would be a bit complicated to do some things by adjusting all the parameters and such.
21:41
Also this means that accelerated graphics has changed because it operates on access to a single framebuffer object, but we kind of need it to allow for multiple drawable views per UI element drawn. Or just completely get rid of. But no, I do not even need this because I made the enforced drawing area graphics so I do not even need to worry about this. I just need a base drawable that goes into things. I just need a way to sub-clip enforced drawing areas without having it nested so much.
21:56
Now with the state count tracker, there will be no need to manage it ourselves so whenever there is a framebuffer resize we just have a single counter now.
21:57
Display as well also does not need to have certain conditions where the framebuffer is re-created, so easier to use and more optimal.
23:58
I need to unify the chain drawing stuff and simplify it so it is not a giant mess.