This post is going to be a volume in and of itself, skip to the end if you find yourself bored (not you Meltrax, you gave me a ton to read, now you must read what I have to say
)
Meltrax, I agree with ~90% of the things you say.
I think we need to work on some sort of merge project, as it sounds like our systems are very similar. Here's some minor corrections/rebuttals to your previous two posts.
- My window system is object-oriented as well, though it isn't handled as nicely as your stuff is.
- I was planning on overwriting the widget handler at some future point. If we can merge our projects, this effort would be redundant.
- I have an objection to SVN-only releases, because many people (myself included) don't have the effort to dedicate to getting the SVN version to build. Currently I've spent 2 hours working on it and still am plugging along when I have time.
With these general comments aside, I have some comments pertaining to a possible future merge project. Upon cursory examination of your latest released code, I have several comments on what I think you did well, and what I think you did poorly.
==CONS==
- As a fish-out-of water c programmer, the most confusing initial problem was the lack of an entry point in some of your files. i.e. it took me a bit to realize that the entire text of your widgets is run like an initialization function. I'm used to all code in a file being wrapped in at least one function (main, WinMain, widget:Init, etc). I really think you should change this in your next release.
- The second problem I have is the apparent lack of child windows. I know you have frames, but imo my child window system is better because it allows for better compartmentalization.
- I don't think you have co-existing absolute and relative coordinates fleshed out in your system. It is important to be able to define both so you can have, for example, a title bar of fixed height 18px attached to a window with variable height 0.5.
- In the sample below I have some minor syntactic changes that imo will make the code more intuitive to the untrained eye. I'm not trying to get in a religious debate over bracket placement here, so comment on what you see.
==PROS==
- I think your class-based implementation is much better than my table system, though we could work a bit to reach a happy medium between the elegance of the former and the simplicity of the latter.
- Your different components are much more well-defined than mine.
- Your dedicated window manager is an obvious plus
Without further ado, I present a possible merged code sample. Everyone who's made it this far, chime in on your opinion of how intuitive the code looks:
Code: Select all
local wCamera = window:New(
"CameraWidget", -- name
{0.5, 0.8, 0, 0}, {0.0234375, 0.046875, 0, 0}, -- vPos, vSize
DefaultStyle( ), -- window style
frame:New( -- children
{1.0}, {0.66667, 0.333333}, -- xcell, ycell
button:New("cam", "camera.png"),-- add a button to switch cameras
text:New("label", "str") -- add a small text pane at the bottom
)
)
function wCamera:Init( )
InitCamera( )
LoadWindowPosition( self )
end
function wCamera:Shutdown( )
SaveWindowPos( self )
end
function wCamera.cam:Press( button, state )
NextCamera( )
end
function wCamera.lable:Update( )
self.text=CurCameraStr( )
end
The dud functions here (NextCamera, etc.) are just to save space and would be replaced w/ real code in the actual widget.
The best code is its own documentation.
PS: To everyone posting here, I HAVE ALREADY RESOLVED THE KEYBOARD F11 bug. The keybinding in the next version is now SHIFT-F11 (overwriting the edit mode key binding). The problem was the keyboard handler was unconditionally capturing the F11 event, meaning that it was never passed back to the widget manager for handling. Really a rather silly oversight by me
.
Thanks for bearing with me to the end, those that did.
.
).
.. I go with an object-oriented approach which allows more flexibility but doesn't have the performance yet that your system probably has (haven't tried 0.2 yet)..
..