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 0DDD7820A1 for ; Wed, 11 Sep 2013 20:17:39 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; 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@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8AADSzMFJbeUeTl2dsb2JhbABbgz+DfLxYgRwWDgEBAQEBCBYHPIIlAQEEASMPATIJCwULCxgCAgUTDgICDwUYMRMUh2gKCK4ekXeBKYtsglUHgmk0gQADlB2DWwGVFjo X-IPAS-Result: Ap8AADSzMFJbeUeTl2dsb2JhbABbgz+DfLxYgRwWDgEBAQEBCBYHPIIlAQEEASMPATIJCwULCxgCAgUTDgICDwUYMRMUh2gKCK4ekXeBKYtsglUHgmk0gQADlB2DWwGVFjo X-IronPort-AV: E=Sophos;i="4.90,885,1371074400"; d="scan'208";a="32481340" Received: from nautica.notk.org ([91.121.71.147]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 11 Sep 2013 20:17:37 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id 506E5C009; Wed, 11 Sep 2013 20:17:37 +0200 (CEST) Date: Wed, 11 Sep 2013 20:17:37 +0200 From: Adrien Nader To: Gour Cc: caml-list@inria.fr Message-ID: <20130911181737.GA3764@notk.org> References: <20130910230928.2d51cd39@atmarama.noip.me> <20130911052437.GA9514@notk.org> <20130911101457.3f756b68@atmarama.noip.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130911101457.3f756b68@atmarama.noip.me> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] Re: OCaml vs Ada and/or GUI options On Wed, Sep 11, 2013, Gour wrote: > On Wed, 11 Sep 2013 07:24:37 +0200 > Adrien Nader wrote: > > > I'm trying to get a list of things that people find bad in (labl)gtk. > > Would you be able to put clear words on what you dislike? > > I can't say much about lablgtk, but as far as gtk is concerned, I > believe there is no future for it multi-platform wise. > > Have you read/seen: > > http://lwn.net/Articles/562856/ > http://www.superlectures.com/guadec2013/gtk-to-infinity-and-beyond I hadn't, thanks for the link. I skipped the video and went a bit quickly through the lwn article (hopefully, lwn articles are well-written and you only need to read a few words of a paragraph to kwow whether you want to skip it or not). I'm going to quote or paraphrase 3 paragraphs of the lwn.net article and comment them. I think it's the ones that matter the most for the current topic. > People often ask why they should port an application from GTK2 to GTK3, > Otte said. His answer historically was that GTK3 is awesome and everyone > should port, but he said he has begun to doubt that. The truth is that > GTK2 is stable and unchanging, even boring—but that is what some > projects need. [...]. The real reason someone should port to GTK3 > today, he concluded, is to take advantage of the new features that > integrate the application with GNOME 3—but doing so means committing to > keeping up with GNOME 3's pace of change, which is intentionally bold in > introducing new features. I've been meaning to work on GTK+3 support lablgtk for a while but each time I look at it, it's a lot of work. A lot has changed many things are better, even if only under the hood. However that means work to get lablgtk3 and the more the changes are under-the-hood, the less their counterpart in lablgtk can be automatically generated (binding a new widget function or a new signal in lablgtk is trivial). > Eventually, he said, he hopes that GTK+ will reach a point where the > bold experiments are done. This will be after the scene graph and > gesture support, but it is hard to say when it will be. Afterward, > however, Otte hopes to make a GTK4 major release, removing all of the > deprecated APIs, and settling on a GTK2-like stable and unchanging > platform. The project is not there yet, he said, and notably it will > keep trying to be bold and add new things until application developers > "throw enough rocks" to convince them to stop. The rapidly-changing > nature of GTK3 is a headache for many developers, he said, but it has to > be balanced with those same developers' requests for new features like > gesture recognition and Clutter integration. I don't think many people will disagree with the above. Benjamin Otte is one of the leading devs of the GTK+ ecosystem and I usually agree with him: his opinions are well-thought and his decisions are balanced. It's fairly reassuring that they plan to make something stable after that. I hope for everyone that this holds. By the time they reach the end of GTK3, they should notice that it's necessary; again, I hope. > Otte's statements that GTK+ was a "GNOME first" project were frequently > a topic for debate at the rest of GUADEC. One audience member even asked > him during his talk whether this stance left out other major GTK+-based > projects like LXDE and Xfce. Otte replied that he was not trying to keep > those projects out; rather, since GNOME developers do the majority of > the GTK+ coding, their decisions push GTK+ in their direction. If other > projects want to influence GTK+, he said, they need to "participate in > GTK+ somehow," at the very least by engaging with the development team > to communicate what the projects want. I've had troubles engaging with the GTK+ community. Maybe I should have tried the mailing-lists instead of only IRC but they are active on IRC and I'd expect to get at least some reaction but I had lots of troubles getting any. If I'm trying to work for free, don't make me work more in order to do the work. I left with the strong impression that they all know each other and that if you're not already part of the circle, you're going to have troubles communicating with them. (note that the same can apply to Qt even though it seems to be a bit better) On Wed, Sep 11, 2013, Gour wrote: > Otoh, Qt project is strongly positioned with many devs, actively > developed, no problem with the license etc. and my humble suggestion is > to put lablgtk into maint. mode and focus, as community, on providing > lablqt to attract new users to write GUI apps in such a fine language as > OCaml. Well, no. I'm going to mostly repeat what I wrote on IRC (I was at work; I leave my laptop along with my SSH keys and passwords at home). I think you can easily understand that not many people would drop a project they're working on (even infrequently) and switch to some kind of "competitor". But apart from that, I dislike Qt. - I don't want to use moc or anything similar - I dislike their deep class hierarchy - their deep class hierarchy is a difficulty for bindings (how do you make it possible to implement from OCaml the virtual protected method in super^5? see the timers for example) - I dislike their API - I dislike the "automatic" widget placement and (re)sizing; GTK+'s hbox/vbox are much easier to use, with a result that I prefer - I dislike qmake - I feel like I'm using a framework when I use Qt I'll skip the part where I'm tempted to mention being gagged with a smurfette while using several of the things mentionned above (I'm sure you can look it up if you want). I'm much more interested in bindings to the EFLs[1]. It's C and the direct result is that you already have bindings even though fairly little time has been spent on them. It's much smaller, it's fast, the API is fairly small and, at least for the EFLs 1.7, the typing used on the C side is so inexistant that I'm sure it will be easy to provide an awesome high-level layer bindings on top of it. Oh and the community is welcoming, with many French people, i.e. that you can actually threaten with a baseball bat. :) [1] https://forge.ocamlcore.org/projects/ocaml-efl/ (there's also GraphicsPP, an implementation of the Graphics module but with the Evas library instead) -- Adrien Nader