Re: Web-UI for Ada applications

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

Le Wed, 28 Aug 2013 13:32:43 +0200, Simon Clubley  
<clubley@remove_me.eisner.decus.org-earth.ufp> a écrit:

> On 2013-08-28, Gour <gour@atmarama.net> wrote:
>> On Wed, 28 Aug 2013 11:35:36 +0200
>> Jacob Sparre Andersen <jacob@jacob-sparre.dk> wrote:
>>
>>> The problem with this is that you both add an extra "OS" layer (the
>>> browser) _and_ require GUI operations to be interpreted (to some
>>> extent) rather than executed as binary code.
>>
>> I'm not sure I get the 2nd part?
>>
>
> When a program which uses, say, the GTK toolkit wants to draw a text box
> on the screen, it does it by making a direct subroutine call to the
> GTK function from the program itself.
>
> OTOH, if you use HTML input to render a text box in the browser, then the
> HTML code is treated as source code input to the browser's rendering
> engine and needs to first be translated to a internal format before the
> rendering engine can process the HTML code.
>
> IOW, every time the rendering engine reads the HTML input, it needs to
> treat it in the same way as, say, a Python or bash interpreter would
> treat it's input.

Not an issue if the page's content is kept reasonably small. No UI is  
handy when it presents a too big page or too many things anyway. There is  
an issue with, as an example, long text documents (I did such an  
application in the past, an XML editor, but with FPK, not Ada), but I  
believe the issue here is the editor specification (the editor is just an  
example), which should not be expected to display a  
mega‑characters/mega‑bytes document as a single piece, and something is  
broken in what we expects from some UI. The issue was not the browser in  
such, it was my lack of proper analysis at design time (well, I was aware  
of this potential issue, but had to save time… that was the real reason  
why).

Software components should always be designed like Ada types are designed,  
I mean, with real world constraints and limitations in mind, and that's  
applicable to UI too. If you design an UI as naïvely as most programming  
languages let you “design” numeric types, letting you believe there is no  
limitation and you don't have to bother about it, you will get some  
issues, inevitably (*). If you do the Ada way, and think bounds and  
constraint when designing the UI, you may get ride of parts of the issue  
you are pointing.

Computation cost of a typical, is ridiculously small (I don't count  
multimedia rendering, which is not part of the UI to me, although it may  
be a component hosted in an UI).


(*) Although I my self did the same error at one time, it always been  
astonishing to me, all editors I known, tries to open a thousand  
mega‑bytes document with no proper handling or limitations, and that's  
obviously even more an issue in an UI running in a web‑browser, but that  
still not the real issue to me, as I feel the real issue, is to believe it  
can be expected to work fine this way. It can't.

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