Re: [Caml-list] RFH: can't figure out why my QT5 widget bindings segfault

[Goswin von Brederlow <goswin-v-b@web.de>]

On Thu, Mar 31, 2016 at 01:00:31PM +0200, Jonas Jensen wrote:
> On 31 March 2016 at 12:21, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> >
> > I think it is the only sane way. GUI widgets are full of inheritance
> > and you have tons of functions that can take any widget. Without
> > objects you would have to use recursive types like
> >
> >     type t = unit pushButton AbstarctButton.abstractButton Widget.widget Object.oObject OCLass.oClass
> >
> > (and how do I say that a widget is both an oObject and paintDevice?)
> >
> > or phantom types like
> >
> >     type t = [`PushButton | `AbstractButton | `Widget | `Object | `PaintDevice ] OClass.oClass
> >
> > And that is just for a simple button. Other types would get a lot
> > longer, not to mention the type for methods taking other widgets where
> > you have multiple of those types.
> 
> The phantom-types approach looks attractive. What would be the problem
> with it? Obviously, those long types should not be written by hand but
> could be aliases, like
> 
> type widget = [ `Widget | `Object | `PaintDevice ]
> type abstractButton = [ `AbstractButton | widget ]
> type pushButton = [ `PushButton | abstractButton ]

Didn't remember that. :)
 
> And then a handle to a push button would have type "pushButton
> oClass". A function taking any widget would have type "[> widget ]
> oClass -> ...".

At the start I tried a modular based binding and I didn't like it.

   win#show

becomes

   Qt5.OWidget.show win

where you have to know in which subclass the show function was defined. Or

   Qt5.OMainWindow.show win

when OMainWindow includes all the functions from OWidget (which needs
some more submodules in each module for inheriting purposes).

One can open Qt5 to shorten that a bit but different Qt5 classes have
the same methods with different argument types. So the module name for
the class has to be typed in a lot. Even local open is of limited use
because you never know when 2 modules will have diverging functions.
But yeah, if you like typing more then you could use this.


On the technical side you have the problem that I think needs true
inheritance at least internally. A pushButton is not just an abstract
type pointing to the Qt5 c++ class. It needs additional data tracking
of other objects. You can't see much of that yet but I want to do the
tracking on the ocaml side if possible and not in the c stubs.

The most common example would be signals and slots. Every time you
connect to a signal something has to keep the closure called by the
signal alive. At least until you disconnect from the signal or the
object dies. And since you can connect many closures to a single
signal I was thinking of tracking them in a Hashtbl in the ocaml
object, one per signal.

With objects each class inherits all the data of the parent while
alowing the child to be used with methods of the parent. You can't do
that with records or tuples. And if I have one class definition per
Qt5 class anyway I might as well expose that to the user instead of
hiding it in modules.

The other thing, which you can already see in the event handler, is
overloading virtual functions. The TetrixBoard class inherits the
paintEvent, keyPressEvent and timerEvent mixins. There are a lot more
virtual functions that can be overloaded in Qt5 widgets and the list
grows and grows as you go down the inheritance tree. Would be harder
to keep track of them with a record data structure.


Now that I figured out enough to have the tetrix example working I
should try again to make a modular interface for comparison. Writing
my arguments above I can already think of ways to work around them. My
goal is to have generated code from a API description (basically the
C++ header file with some more annotations thrown in about ownership
and in a simpler to parse format [ocaml code?]). Maybe it wouldn't be
to hard to generate both objects and modules from that.

MfG
	Goswin