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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 29 Dec 2012 11:39:08 +0100, Yannick Duchêne (Hibou57) wrote:

> 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.

There are two different sort of interfaces the components of a GUI
application have:

1. Interfaces of its functional components

2. Interfaces of its GUI components.

These interfaces have nothing or very little in common which is why
standard means of decomposition do not work well. When you decompose having
the application domain (functionality) in mind, you lose UI, when you focus
on UI, you lose much of functionality.

>> You don't own the main task it will belong to the GUI.
> Not necessarily.

How so? Most GUI frameworks simply require this.

> 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.

The main task runs the messages loop. Which means that it is blocked most
of the time waiting for incoming messages.

>> 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.

No way. If you have, say, a DB and want to show its contents in a list
control, the DB client must be a list store (the model deployed by the list
control). If the DB client was designed in a way that does not support
delivery of the result set incrementally, in portions, the UI will block
when rendering large result sets. If the DB client delivers each row
separately, that will choke the UI with a flood of events etc. You can do
nothing about it. You have to change the client [or write new list widget].

The point is, one influences another and if you consider the GUI framework
fixed, then the application must adapt = you build around the GUI.

>> 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.

It is very simple to [dis]prove your theory. Take (RM G.3.1)

function Solve (A : Real_Matrix; X : Real_Vector) return Real_Vector;

The objective is to start it on a button click, show a modeless dialog with
a progress bar and a cancel button inside.

>> 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.

Direct or not, the model influences the view and you have to decide which
policy to deploy.

> 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.

It just does not answer the question. It is a pattern to decompose UI.
Evidently, it is not a pattern to solve linear equations, is it?

The problem of GUI software design is how to decompose UI *and* the problem
space.

> Also, may be there's some confusions between application interface and  
> user interface in this topic (some comments make me feel that; see above).

Oh, yes. Fancy papers about GUI design consider UI the problem space. They
already took for granted that applications are built around the GUI. And
all GUI frameworks I know require no less.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de