From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6A1007EE34 for ; Sat, 2 Apr 2016 13:39:04 +0200 (CEST) IronPort-PHdr: 9a23:+0VeaxzAJCz9ZlXXCy+O+j09IxM/srCxBDY+r6Qd0e4UIJqq85mqBkHD//Il1AaPBtWLrakYwLGH+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuSt6U1Jj8jLH60qaQSjsLrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGwD884mosVJVKG/e6UjUZRZCi4nOiY7/p7Frx7GGCSI/WQdVC0IlRwAKRLI4BzgWpDu+n/1sfFi2S/fI4j8Za85U3Ku4vE4G1fTlC4bOmthoynsgctqgfcDrQ== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=goswin-v-b@web.de; spf=Pass smtp.mailfrom=goswin-v-b@web.de; spf=None smtp.helo=postmaster@mout.web.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of goswin-v-b@web.de designates 212.227.15.14 as permitted sender) identity=mailfrom; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.14; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BtAQAfrv9Wkw4P49RdhQezKIMAhHUBDYFyhH2BEAKBJjgUAQEBAQEBAQERAQEBAQcNCQkhL0ESAYFZghQBAQEDAScTRAsLGAklDwUoNB6HcwEDCggEvlcfKyKFAgELHopqhBmDUYIrBY1NijSHIIZeiTYKhVmPGh4BAYJXgVRqhis+gT0BAQE X-IPAS-Result: A0BtAQAfrv9Wkw4P49RdhQezKIMAhHUBDYFyhH2BEAKBJjgUAQEBAQEBAQERAQEBAQcNCQkhL0ESAYFZghQBAQEDAScTRAsLGAklDwUoNB6HcwEDCggEvlcfKyKFAgELHopqhBmDUYIrBY1NijSHIIZeiTYKhVmPGh4BAYJXgVRqhis+gT0BAQE X-IronPort-AV: E=Sophos;i="5.24,431,1454972400"; d="scan'208";a="211762032" Received: from mout.web.de ([212.227.15.14]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Apr 2016 13:39:03 +0200 Received: from frosties.localnet ([134.3.242.84]) by smtp.web.de (mrweb001) with ESMTPSA (Nemesis) id 0MFLMa-1aY01L0pQS-00EKg5 for ; Sat, 02 Apr 2016 13:39:03 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.84) (envelope-from ) id 1amJt3-0007xV-Bs for caml-list@inria.fr; Sat, 02 Apr 2016 13:38:41 +0200 Date: Sat, 2 Apr 2016 13:38:41 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20160402113841.GB30016@frosties> References: <20160323105016.GA2235@frosties> <56F2CFD4.4000401@cea.fr> <20160324102559.GB32689@frosties> <20160325112839.GA27075@frosties> <20160329222912.GI9386@darkstar> <20160331102118.GA17174@frosties> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:eb/Vafq5eLxyVE5t4/z8LhuuQ3n9PCbc4ZYD6RI3dEEuKejPM8P s9DbGNEXEH0NiGlj+6yS48G5Wh3ARKifnKh896VsC2tlSuCu9f7qot5O/AUxBhGbN9HZhZB 0OqK8ShjxhkFC6s9liJC1AfVn+UAoZ9QlUN4o+sIaXkpzalqXKmhQjLpVIjVNc0BgHpieAI Da+HBmJPIuy9pg7WG4a7Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:2JIQqIJ/pJs=:mfXGubQZV/IG8ezIseCTX4 IgnXevXe9kXMKcDqVzDgkkEmPl9mUwy4mh7oDpi8u5DFMWLBDnu0POq24GF/6N9mL9u9bJNU2 rdSHcHAnCQYhI49vYviSetW9j7hLxBNnKZiJX3Jg8R+802pNmIRYeP6+8G+IQPrav3P4Z/iqB meYyfEyQyb19JD9j8+zDwabDq89JPG3vF61CaMxOeWLBYs5ZvZApGafAQ31CakNNYmHkNsprn ReSrT0/XCfdRtIxKsiBkfbMPFYj2e36BJV44bbNJH57C4T2UeIsh+dcQZ2B8CX14HTi+j3J1I aqkKNnHFQ/3xhJ9jhCSm1lG3KDRDE9z4mPzKYhDpYjPGm4kLslT7WNoRvdiLYG+RSGULF/FVj rUXrBZpdSN+Dh574LVApK3h7bcSs1urIyICkmLVD7cpvrPnsExQXRzMYzLQbh4yzg/KY3ftVe +zBAiOwcYeOXE9CpXefnSwnSLMROMjEZAmo7PjyYVK3uWCACcC0Apky3KVeGHtXa6m7/36eIw m6gtVQMjiDCEI3rTiC1Mt8oXxeoRp7A19sLrdFvxX6w+dHXPshbY53ZeSCA8jg0HI4l2h9L+0 zBtY2eEzw68OIAdVIH+7encCFKczfVnXENF7VnEjTdpn3c38W5qHoa3fiaJh4OjL2WhcYVXSE ast0i5VxnbOEqZncxaY4LL28las8Dv9OVGUt6+AZ5F5JE2p0wQYJKvExbmCQT1qyh2smy8GKx nunDJMErZ/dtTvBmrBajO0x8shzEZot4/oaUiR3TWsu22Joef81tI95z9j4= Subject: Re: [Caml-list] RFH: can't figure out why my QT5 widget bindings segfault On Thu, Mar 31, 2016 at 01:00:31PM +0200, Jonas Jensen wrote: > On 31 March 2016 at 12:21, Goswin von Brederlow 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