Make extern class hierarchy match wxWidgets

[ianharrigan]

hxWidgets needs to do a better job of matching he wxWidgets class structure. This means using things like wxComponent, etc. And having the correct function, say getLabel, in the correct place.

[ibilon]

I'm going to make a pull request today to extract the extern classes into their own package, could do that at the same time if you want.

[ianharrigan]

Perfect, if you fancy doing it greatly appreciated of course. I was also going to move the classes about also, so good that were on the same page.

I also think the style classes, say RadioButtonStyle should be in their own .hx files also so you can use RadioButtonStyle.GROUP rather than hx.widgets.RadioButton.RadioButtonStyle.GROUP

What do you think?

[ianharrigan]

I also think now is certainly the best time to lock down this structural stuff before it gets too big.

[ibilon]

Forgot about the style classes, but yeah I agree.

[tienery]

How about hx.widgets.styles.RadioButtonStyle as an example?

And perhaps remove the hx. prefix because I'm sure people know what widgets means ;)

[ianharrigan]

Im not fussed personally, either in a hx.widgets.styles package or in the hx.widgets, the main point is to move them out of the RadioButton module so you can reference them much easier, ie, dont need to use the full dot path, which gets to be a pain.

[ianharrigan]

PS: hx.widgets.styles might better just to stop there being so many classes in the main package

[ibilon]

Everything in wxWidgets is in the main package, so the question is more of: do we keep everything in there or are we making some choices for subpackages (like styles, maybe components ...)

[ianharrigan]

I feel like styles are a little different to classes though as in the cpp the are just #defines

[ibilon]

True, so I think the rule if it's in this list http://docs.wxwidgets.org/3.0/annotated.html then go into the main package otherwise group them by type/theme in a subpackage isn't bad.

[ianharrigan]

Agreed. And in general defines and enums go into their own .hx module so we get easy access.

[ibilon]

Question on the theme of easy access, for the file wx.widgets.App which should be the main type App or AppRef (which would be App in that case and App would be something else).

Since I don't think these files should adhere to the "one type per file rule", and the Ref type is the main one (only one?) used.

[ianharrigan]

Yeah, i agree also that the extern class X and XRef should both live in the same file, and i think that the ref is the only one that should be used. I wonder if we should also change the naming convention?

something like XRef becomes X and X becomes XImpl or something like that? Not sure, might be too confusing? What do you think?

[ibilon]

XImpl isn't bad, and it's only used internally anyway, so the change should make it less confusing, my first thought wouldn't be to import and use wx.widgets.X.XRef;

[ianharrigan]

The only reason i dont like loosing the "Ref" bit on the pointer is it has semantic meaning. But thats probably just me - sort of feels safer to be explicit about the fact that you are essentially passing pointers around. That said, its not a massive mind shift to simply remember that "WxWindow" is the pointer.

Im not totally sure what you mean about the import and using bit. You would have to use the XRef extern in the wrapper classes, surely?

[ibilon]

I meant for someone using the extern classes before the change, he'd have to use a sub class, but would probably simply use X at first and get a lot of errors, which is confusing.

And that after we change to X and XImpl he wouldn't get these errors, making it simpler when you're not using the wrapper.

[ianharrigan]

Right, yeah, i see what you mean. So yeah, i think you are right. If i looked at the lib i would generally look at the WxWindow classes first, so i does make sense to the user:

"WxWindow.createInstance" makes more sense that "WxWindowRef.createInstance"

[tienery]

Just an update, how has the structuring been going? Any progress?

[ibilon]

In progress https://github.com/ibilon/hxWidgets/tree/extract, there are still several classes that need work and I haven't tested the c++ compilation part yet.

[tienery]

Cool, I'd like to start implementing a few more controls into the extern which I'm sure would be useful to many people.

[ibilon]

I started on the actual hierarchy part https://github.com/ibilon/hxWidgets/tree/hierarchy For now only the externs are done, although the functions aren't moved yet.

Some classes use interfaces to mimic multiple inheritance.

[ianharrigan]

I think this can be closed now. In general we are use the class structure more, not totally, but when we do implement the functions we are putting them in the correct class (rather than just say having a huge Window class that also contains Control functions).

The important part now is just to stick with it. If there is a function that belongs to a class that isnt yet implemented then its important to implement it in that class and modify the hierarchy accordingly (in both the externs wx.* and the wrappers hx.*)