From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b6df8f8501cf7275 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 X-Received: by 10.180.96.231 with SMTP id dv7mr8046944wib.6.1356777552571; Sat, 29 Dec 2012 02:39:12 -0800 (PST) X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 78.192.65.63 Path: i11ni330015wiw.0!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!nntpfeed.proxad.net!news.muarf.org!news.ecp.fr!aioe.org!.POSTED!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: Easiest way to build Qt/Gtk interfaces for Ada programs Date: Sat, 29 Dec 2012 11:39:08 +0100 Organization: Ada @ Home Message-ID: References: <1gda5kzj50h3l.jzmq13s0hw74.dlg@40tude.net> <1uzqolxxpmz0v.jea876uzf4tc$.dlg@40tude.net> NNTP-Posting-Host: aWaWeUaBdaj2Zzc04J1v5A.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.12 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2012-12-29T11:39:08+01:00 List-Id: Le Sat, 29 Dec 2012 10:26:04 +0100, Dmitry A. Kazakov = a =C3=A9crit: > On Sat, 29 Dec 2012 01:18:34 +0100, Yannick Duch=C3=AAne (Hibou57) wro= te: > >> Le Fri, 28 Dec 2012 16:32:09 +0100, Dmitry A. Kazakov >> a =C3=A9crit: >> >>> Ignoring casual applications, it is unfortunately so, that whatever >>> framework you use, and what the application is supposed to do >>> functionally, you have to build it around the GUI. >> >> On the opposite, this is the least recommended way to do. One should >> create the UI around the application. The cleanest in my opinion, is = to = >> go >> for a Model View Presenter (MVP), preferably with a passive view. > > In order to deploy MVC, you must make your application providing the "= M" = > in > the MVC (model). The application must be designed with this in mind. T= his > is why you build it around the GUI. May be not: what about substituting =E2=80=9CGUI=E2=80=9D to =E2=80=9Cse= rvice interface=E2=80=9D? The = application may be better designed in term of what you can get from it a= nd = what you will feed it with. Can designate it as an abstract interface, = perhaps. > You don't own the main task it will belong to the GUI. Not necessarily. With MVP (which is not the same as MVC), the presenter = = starts everything (it is the supervisor), and it's the presenter which o= wn = the main task, and it it may launch the application and the UI as two = others distinct tasks. > You have to design all > vital data structures as models compatible to the GUI framework at > hand. You may do this way, while you are as much free to adapt the UI to an UI= = specification, a specification which specify a human interface to a = computation or service interface. > You have to place inspection/rollback/abort check points in all > lengthy operations to be able to add progress bars, cancel buttons etc= . You may, if you designed the application. But you may as much have to ad= d = an interface to an already existing application which does not provide = these facilities. In which case, the presenter will either not provide a= ny = progress data, or else will fake it or try to guess or derive it. Same = comments for inspection, undo/redo, and others. I know that's bad, but = that happens, and even if that features are suggested by what a user = expects from an UI, these are not UI features, these are application = features. The UI is just an interface to what the application provides. = = The application may be required to provide such features, but it don't d= o = so to please the UI, it do so by specification, to please the user (whic= h = may not be human, by the way). > You > have to rework all tasks making them compatible to single-threaded GUI= , > preventing events floods, event generators, deadlocking in signal = > handlers. With the MVP, that's the presenter's job (it is the middle man responsib= le = for the coordination and interpretations). As above, things may differs = = depending on whether or not you are giving an UI to an application = designed with a good interface in mind or not. Sometime, it is not. > You have to decide polling vs. event-driven policies along the M-V pat= h = > and > design the tasks involved correspondingly. In MVP with a passive view, there is no direct path from the model to th= e = view. All paths, from the model to the view and the reverse, pass throug= h = the presenter (which is responsible for the interpretation of user = gestures to the model and for the model states to the view). > And so on and so forth. And you > honestly believe in a tool which would allow you to do all this lazily= > dragging and dropping icons? I don't. Me neither. But a tool can help in designing the UI, proper, as a = standalone specific component. I know my comments does not help a lot, and above all does not offer any= = magic recipes, I'm sorry for that :P . I also guess the MVP may not look= s = so much appealing at first sight, as it requires more work (and in some = = context, like the web, it may present challenges with communication and = = separation); but the benefit is to be more solid and more composite. = Visiting Fowler's website (or getting a copy of its book), will learn = more. I won't tell more on the topic (which may be subjective), and firs= t = wanted to give this pointer to prospective people. Also, may be there's some confusions between application interface and = user interface in this topic (some comments make me feel that; see above= ). = I indeed tend to be disappointed with entanglement of applications matte= rs = and UI matters, at least as seen in some open=E2=80=91source software (t= ry to = fix/update one, and you break the other, the same with understanding how= = it works). -- = =E2=80=9CSyntactic sugar causes cancer of the semi-colons.=E2=80=9D [1] =E2=80=9CStructured Programming supports the law of the excluded muddle.= =E2=80=9D [1] [1]: Epigrams on Programming =E2=80=94 Alan J. =E2=80=94 P. Yale Univers= ity