Re: Easiest way to build Qt/Gtk interfaces for Ada programs

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Sat, 29 Dec 2012 10:26:04 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Sat, 29 Dec 2012 01:18:34 +0100, Yannick Duchêne (Hibou57) wrote:
>
>> Le Fri, 28 Dec 2012 16:32:09 +0100, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de> a écrit:
>>
>>> 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. This
> is why you build it around the GUI.
May be not: what about substituting “GUI” to “service interface”? The  
application may be better designed in term of what you can get from it and  
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 own  
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 add  
an interface to an already existing application which does not provide  
these facilities. In which case, the presenter will either not provide any  
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 do  
so to please the UI, it do so by specification, to please the user (which  
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 responsible  
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 path  
> and
> design the tasks involved correspondingly.
In MVP with a passive view, there is no direct path from the model to the  
view. All paths, from the model to the view and the reverse, pass through  
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 looks  
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 first  
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 matters  
and UI matters, at least as seen in some open‑source software (try to  
fix/update one, and you break the other, the same with understanding how  
it works).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University