Re: Air traffic control system in Java

[Shark8 <onewingedshark@gmail.com>]

On Mar 5, 2:01 am, "Vinzent Hoefler"
<0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote:
> Shark8 wrote:
> > On Mar 5, 12:15 am, "Vinzent Hoefler"
> > <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote:
> >> Shark8 wrote:
> >> > On Mar 4, 10:15 pm, "Vinzent Hoefler"
> >> > <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote:
>
> >> > Interesting you should mention Oberon; I just installed it into a VM
> >> > to play with.
> >> > {VirtualPC is free now, so if you're using Windows there is little
> >> > disincentive
> >> > to throwing odd/interesting OSes into a VM.}
>
> >> I'm happy user of VirtualBox sind a couple of major versions. ;)
>
> > And that diminishes my pointing out that VirtualPC is free how?
>
> Not at all. Just wanted to point out cross-platform alternatives. ;)
>
> > {You're just making my point that it is *easy*/*cheap* to have VMs.}
>
> Precisely.
>
> >> > Delphi's VCL is actually one of the best GUI-builders I've seen...
> >> > there was
> >> > also the Kylix port of the VCL to the Linux environs which fizzled
> >> > out, but
> >> > iy *WAS* there.
>
> >> Well, FreePascal has Lazarus, that's probably more cross-platform. :)
>
> > Possibly, Though I wasn't able to get it to work last time I tried it.
>
> I hear that a lot. Never used it and there are people actually using it,
> so it must work under certain conditions.
>
> >> > Given that the VCL is basically an object-oriented wrapper of the
> >> > Windows [graphics] API
>
> >> And still, a lot of regular users are /not/ satisfied with what the VCL
> >> offers. And it's already huge (thus, nothing I would put in a standards
> >> document).
>
> > I didn't say we should enshrine the VCL as a standard. I *DID* say
> > that the VCL presents us with an intriguing possible opportunity to
> > implement a GUI hierarchy.
>
> So did Turbo-Vision. ;)

Interesting you should mention TurboVision, I actually have a copy
(for
BP7, of course)... I was contemplating incorporating it [or something
similar] into the  UI for my OS.

IMO, an OS should have an uniform API such that a text-bases UI like
Turbo-Vision *AND* a bit-mapped UI like Windows/Macintosh are both
usable.
{I hate it when I can't use a utility-program because [say] the mouse
is
out because of some problem I could fix with that utility had they
actually
implemented keyboard functionality.}

IMO, assuming that the user has a [operational] mouse [or keyboard] is
a
bad assumption -- that the MS Windows installers nor have a virtual
keyboard is a good thing which should be standard (yes, it *IS*
somewhat
tedious clicking in what would be a quick entry using a keyboard),
IMO.

>
> >> Yes, it is surely *possible*. But it also means that you probably have to
> >> trade look-and-feel against the portability. And that means, users of
> >> your Ada-GUI will complain about the differences, will not use it or
> >> "patch" it according to their specific needs.
>
> > True enough. However, the lack-of-GUI may be more weighty than a
> > GUI-I-Have-To-Tweak, especially in the minds of Ada-newbies.
>
> So use GtkAda? It may not be in the ISO-standard (neither is Qt which a
> lot of C++ programmers seem to prefer), yet it is _available_. And I
> think, especially "newbies" care less about standard than we oldtimers
> (although for an Ada programmer, I'm probably one of the younger ones.)

I'm thinking that a rather uniform look-and-feel, for general desktop
OSes,
could be constructed if it were based on a [VERY] thick OpenGL binding
--
that way we would have control over the primitives used to build/
display
the UI.

> >> IMO, there's no point in standardizing such a beast, if you can't get it
> >> right.
>
> > Ah, but I believe that you *can* "get it right."
> > Scroll-bars should scroll; edit-boxes should be editable; spin-edits
> > should
> > constrain themselves to valid [numeric] values which are modified by
> > the
> > attached arrow-buttons.
>
> Yes, they should. Unfortunately, the precise semantics one might require
> for one particular control can not be standardized without trading it for
> implementation effort or portability.

I understand what you're getting at; but I'm not sure that it is a
problem.
One could have a screen-shot and say "" this is how a 'progress-bar'
it to
look." A bit draconian, but valid.

> Minor example, but I remember a simple progress bar (pygtk). It was cross-
> platform in the sense, that it worked on ever supported system. Yet, its
> precise look depended on the window manager/platform. On one only the
> progress bar was shown, on another one the percentage was shown inside
> the bar, on the other one below it.
>
> We could live with those differences, yet many users won't like it.
>
> >> Wasn't there a standard GUI description language (based on XML?) a couple
> >> of years ago? What happened to it?
>
> > Hopefully it died a slow and horrid death.
>
> I didn't think the basic idea of having a standard GUI description languge
> was stupid.

Oh, don't get me wrong, I don't think having a GUI-description
language is
stupid/bad/misguaded... I *DO* think that XML is the wrong choice for
such
a language. {IMO, Delphi's DFM files are much better; the DFM-file
contains
a sort of object-layout where a) only non-default values are supplied,
and
b) children-objects are indeed components within their parent-object.}

As a simple DFM example:
http://rafaelromao.blogspot.com/2009/08/parsing-delphi-dfm-file.html

> And before they invent another language just for that purpose,
> I'd rather see an XML description for it.

I rather dislike XML; not because of what it can do, but because
of precisely how it is abused; I see it becoming the C/C++ of data
formats. (Which is pretty damn sad.)

> >> And as mentioned above. To put something like that into a language standard,
> >> you have to keep minimalistic (remember that the vendors need to implement
> >> it and cost of implementation is also an issue in terms of standardization).
> >> But being minimalistic also means, that nobody will use it due to lack of
> >> (necessary) features.
>
> > That's where the beauty of the VCL shines: a 'minimal' implementation
> > may
> > be extended as needed. {And these extensions are how more complex
> > types are
> > introduced/elaborated to the user.}
>
> Have you ever taken a look at a GUI class hierarchy. Even a minimal one
> would be quite large, I'd say.

Yes; I have.
I think the sheer sizes are the one reason for my trepidation on GUIs.

> >> IME, if a minimalistic GUI is needed, embed a webserver into your application
> >> and let it start up the browser. This served me well so far. Virtually everybody
> >> knows how to use a browser, and in the days of Web 2.0 such an approach is
> >> probably even "en vogue".
>
> > I think Ada could get the upper hand if a) the embedded webserver was
> > standard,
>
> Hmm. Standardizing a thing like AWS might turn out to be easier than standardizing
> a whole cross-platform GUI library.
>
> > b) the events [server-side] were easy-to-handle,
>
> I don't think that's a problem once you solved the issue of getting the events
> back to the server.
>
> > and c) Ada programmers encouraged/evangelized the method.
>
> Well, I'd do that. I have always been bad when it came to GUI design,
> but spitting out XHTML was easy. :)
>
> Vinzent.
>
> --
> A C program is like a fast dance on a newly waxed dance floor by people carrying
> razors.
>      --  Waldi Ravens

I'm liking this discussion; you're quite intelligible and, if I may
say, just
the proper amount of 'adversarial'* to really spark debate.

* Not exactly the right word, but close enough.