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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,470860aa3e635a7 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: GNAT for MS Visual Studio References: <13duou81kg3sd1c@corp.supernews.com> <13f3e0vbb05s47c@corp.supernews.com> <13f6eg0te46m2a3@corp.supernews.com> From: Markus E L Date: Fri, 28 Sep 2007 11:23:54 +0200 Message-ID: <4xsl4zw3bp.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:BYzb+sjwA9f3t4eKfaU/oYVip98= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.204.37 X-Trace: news.arcor-ip.de 1190971123 88.72.204.37 (28 Sep 2007 11:18:43 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.freenet.de!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:2212 Date: 2007-09-28T11:23:54+02:00 List-Id: "Steve" wrote: > "Markus E L" > 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