iamaboringperson wrote:
...
I think if we were to look at the similarities between the different systems we could map out which functions can be used in common between them.
That's the basic idea, yes. However, by designing an API 'from scratch', we can get away with matching up slightly less compatible classes from each system since we define what access level the end user has. Additionally, in each specific implementation, we can fill in the gaps to make the overall behaviour consistent.
Realistically we need to get the common buttons, menus, lists, scrollers, choosers and other gui elements under our umbrella. Support for more exotic classes (and for MUI this is quite a lot, I guess) is of lesser importance to the target audience.
Data structures might need to be unique to this new gui thing.
Well that's an implentation detail and is probably inevitable as most abstraction layers need to track data not belonging to the layer beneath.
Such things should, wherever possible, be hidden from the end user. What most people want are simple methods for opening windows, creating gadgets, binding them and suchlike. Our handles to said gadgets can be abstract (a pointer or whatever) that is given as an argument to our functions.
A C++ version would simply use a wrapper class for this instead.
Eg C interface
OGWindow* guiWindow;
guiWindow = OGWindow_Create( ... );
if (guiWindow!=NULL && OGWindow_Open(guiWindow) == TRUE)
{
/* stuff here */
}
A C++ version could look a little different, depending on how OOP you want it to be...
OGWindow* guiWindow;
guiWindow = OGWindow::Create(..); // factory method
if (guiWindow!=0 && guiWindow->Open() == TRUE)
{
// ...
}
Both versions would offer the same abilites, just differ in how they are presented to the programmer.
I imagine compareing two string gadget(as an example) classes, and looking for similar methods etc. and then writing new functions that will in turn call either of the MUI or ReAction functions.
It might be a bit inefficient to begin with, but with faster machines in the futre it shouldn't matter too much.
Well, the overhead is far smaller than you might think and it's usually not time critical either. How many people would notice a delay of an additional hundred clock cycles after clicking something for a forwarding function that does a little interim work?
