Re: GNAT for MS Visual Studio

[Markus E L <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

"Steve" wrote:

> "Markus E L" <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> 
> wrote in message news:ltfy11y10v.fsf@hod.lan.m-e-leypold.de...
>> Steve,
>>
>> I'd like to press my point: Have you ever seriously considered not
>> using a GUI builder but building a GUI "by hand", just instantiating
>> and inserting the widget where needed? It might seem tedious at the
>> beginning, but, in my experience doesn't make much more work in the
>> long run. Furthermore it provides opportunities too, because if highly
>> dynamic GUIs are required (e.g. Widgets being replaced or removed
>> dependent on the state of the program or editing process), GUI
>> builders can't provide that (whereas "manual instantiation" has no
>> problems), and there is also the opportunity to tweak layout,
>> alignment, colours and inserting modified custom widgets.
>>
>
> To me that's too much like asking the question:
>   Have you seriously considered not using a programming language and 
> compiler and just programming in machine code?

I thought so. Hence (a) my comment that you're caught in this
Microsoft mind set and (b) my attempt to make you reconsider: The
relationship between a Toolkit and a GUI builder, IMHO, is not
analogous to that between assembler and a ("high level") programming
language.

But, as I see it, at the moment there are few things to convince you
otherwise. So please understand my comments as comments, not as an
attempt to convince you.

>   When you have a visual tool for creating a user interface, you can do 
> things like restructure a window to meet new requirements with very little 
> effort.  In some cases you don't have to edit the code at all to bring about 

The thing that comes into my mind is, that (a) the requirements should
have been fixed much earlier and (b) restructuring is handled by
moving constructor calls.

Furthermore the very situation that is difficult to handle, that you
have integrated widgets into an abstraction (like "customer data
browser") cannot be handled with GUI builders at all and in this
situation it is improbable that you will move widgets over the
abstraction boundary.

So then w/o a GUI builder I'm only moving a call

   New_Cusomer_Browser(...)

to another place, with a GUI builder I haven't built an abstraction
from the very beginning.

That is perhaps the main point in my slightly jumbled commentary: GUI
builders don't allow you to build abstractions. Using GUI builders
doesn't scale and doesn't promote reuse (of GUI subsystems).

> a significant change in appearance.

If editing code is a pain for you, then you have a point. Only that I
personally, don't trust programmers that have a difficult relationship
to editing code -- it's their business. 

>   Yes I have built up windows the hard way.  I have done so using GWindows. 
> If you have a fairly static application, where the user interface changes 
> infrequently, it isn't a very big deal.  But if you have an application that 
> is revised frequently then if you don't have a visual tool for updating the 
> UI after a relatively short time the UI degrades to something that is 
> functional but just doesn't look good or is awkward to work with.


W/o knowing the details it's hard to say what went wrong. Of course
structuring GUIs so that they stay maintainable is an art on itself,
very much like structuring programs so that they stay maintainable
(the key is modularization).

With GUIs the GUI builders don't help you in the task. They just help
the GUI keeps looking nice. The business logic behind will get jumbled
anyway.

Furthermore: I'd be surprised if, even with a GUI build you could just
pick an element out of context and move it to some far away place.

That _only_ works, if you're having something that resembles paper
forms, which in turn IMHO hardly deserve the name GUI. But if you
e.g. have a browser for status records for network nodes, you'll
hardly ever move GUI elements from there into some other context,
since you need access to the network nodes status to show the widget
element.

Which gives me the idea that GUI builders tend to promote spaghetti
code in the underlying application.

>> GUI builders are fine if you're programming for paper-shufflers:
>> Everything is a "form" than, as it was in the time of paper forms.
>>
>> But interactive software needs to be smarter -- and that is what GUI
>> builders can't provide in my (admittedly limited and perhaps dated
>> experience). So if I end up anyway not being able to use the GUI
>> builder, I could as well learn how to use the tool kit in the language
>> proper.
>
> If the components that are placed on forms are dynamic, and there is 
> automatic interaction between the components on a form (like there is with 
> .NET) then things can be very dynamic.

If you define this as "dynamic", yes. I doubt really complicated stuff
can be specified by interacting with the mouse.


> Most of the applications I work on have to do with sawmill automation. 
> Scanning logs at various stages of processing and optimizing the breakdown 
> decisions and process.  The application requires a lot of configuration to 
> describe the machinery, the products being produced, and rules on how to cut 
> things.  There are dozens of dialogs in the system.  

Dialogs. Complicated, sequential forms. No direct inteaction
interface. There you are.

> Trying to maintain these using hand coded windows is just plain
> silly.  Parts of the system are very dynamic... displaying 3d images
> of material being processed, diagnostic information, etc.

This is not what I call dynamic.

BTW: Nobody asked you to maintain your system "using hand coded
windows". If you don't want and have a GUI builder, please don't. But
you asked for a GUI builder that isn't there, implicating live is to
complicated w/o one. I still doubt it is.


Regards -- Markus