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 94518820A1 for ; Wed, 11 Sep 2013 20:43:24 +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: Ap8AAEa5MFJbeUeTl2dsb2JhbABbhzu8WIEcFg4BAQEBAQgWBzyCJQEBBSNWEAsYAgIFEw4CAg8FGDGIGa4vkXeBKY5BB4JpNIEAA5d4AZUWOg X-IPAS-Result: Ap8AAEa5MFJbeUeTl2dsb2JhbABbhzu8WIEcFg4BAQEBAQgWBzyCJQEBBSNWEAsYAgIFEw4CAg8FGDGIGa4vkXeBKY5BB4JpNIEAA5d4AZUWOg X-IronPort-AV: E=Sophos;i="4.90,885,1371074400"; d="scan'208";a="32483358" 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:43:23 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id 481B8C009; Wed, 11 Sep 2013 20:43:24 +0200 (CEST) Date: Wed, 11 Sep 2013 20:43:24 +0200 From: Adrien Nader To: Kakadu Cc: David MENTRE , OCaml mailing list Message-ID: <20130911184324.GC3764@notk.org> References: <20130910230928.2d51cd39@atmarama.noip.me> <20130911052437.GA9514@notk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] OCaml vs Ada and/or GUI options On Wed, Sep 11, 2013, Kakadu wrote: > Hi! > > I think that QtQuick team have solved problems with decalrativity and > business-logic. For example, you can declare _states_ which your > application can have and declaratively specify how properties of your > elements change after switching to every state. > > You can also declare some action for your menu items and toolbar > buttons declaratively. You can declaratively join actions in exclusive > groups to be sure that only one is enabled on every moment. > > And, of course, you can do some simple things like element borders and > gradient filling declaratively. > They copied that from the EFLs. :) Anyway, there's something important to keep in mind. If you have states and build an application with some bells and whistles, you'll have transitions between the states and you'll need to synchronize them and synchronize the logic too. This can create many many switches between themes and logic code, spaning several files. That's one new issues. I believe it can be improved a lot (if not solved completely) by providing type-safety (i.e. state identifiers are variants, not strings) and putting all the transition and synchronization logic in a single place. That's something for which OCaml would be a good language. -- Adrien Nader