Home > Archive > APL > February 2008 > A question to the APL vendors on Windows GUIs ...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
A question to the APL vendors on Windows GUIs ...
|
|
| aleph0 2008-01-13, 7:58 am |
| AFAIK, most APL vendors interface to the standard Windows GUI objects.
Is there a possibility of using "Java GUI Modules" instead ?
i.e. Java Classes etc etc.
.... and if so, is it possible without much effort ?
The reason I'm asking ?
Well, a recent example :
.... a friend of mine recently recieved his personal copy of APL and
his very first comment was....." the GUI interface looks wrong ; is it
(APL) installed properly?"
( he meant the APL-Window, not anything he himself had written .. and
it was of course installed properly )
When you see the software on the market today, their GUIs are more
than pleasing to the eye... ... which is of course a major selling
factor .. rightly or wrongly !
I myself have written over the last few years a couple of larger sized
APL apps which I intended to sell. In the end, I decided not to
bother, as the GUI just didn't look "nice" enough ! ...... not because
of my own work,but because the GUI simply wasn't "slick"enough ... ..
as is the case in most Java apps , for example !
I also did a lot of exploratory work on internet interfacing ( Browser
DOM models etc. etc. ) as well as reporting loads of bugs ( 100's of
Emails ) in the latest verions of my APL interpreter . I discovered
( from the vendor ) that not many Users have been as far as I have in
those domains ! This surprised me "very" much !!
I am well aware that most APL Vendors (apart from IBM) probably don't
have the resources to expend on GUIs especially when there are more
important outstanding jobs on the table. OTOH, I seem to remember
Sharp APL doing a Java interface !
PS:
Don't flame me for being critical .. but I would like to see some
constructive discussion on this topic !!
Also, I am not trying to discourage the small Vendors, and consider
they have "all" done more than excellent jobs.
| |
|
| Which APL interpreter are you using?
I am not aware of the issues you raise. As far as I know, APL uses
standard Windows controls via some mechanism to enable APL syntax.
Therefore, I'd expect all controls to look the same whether hosted by
APL or not. As far as I can tell, they do.
However, because of the custom bridge, some controls/behaviours are
not available e.g the autosizing features of controls in .Net GUIs,
for instance.
Is it possible that it is your APL GUI design that is the culprit? APL
does not have a GUI designer to speak of, certainly not one that comes
close to even the VB6.0 designer, let alone the much better VS2005
one.
If you still hold your conviction, you can do your presentation tier
in (exclusively) Java (or whatever else) and use APL for your buiness
tier. You will need to use something like COM for allowing the two
tiers to communicate. As far as I know, COM and Java present
nightmares of unimaginable complexity ...
| |
| aleph0 2008-01-13, 6:58 pm |
| I've used the VB GUI designer as well as various JavaDKs.
I still stand by my conviction .. it's not the Vendor's fault, but
simply the fact that they stick to the STD Windows rules for obvious
reasons , e.g. for maintainability etc. etc.
I also agree that there is no comparable (to VB etc. ) GUI designer
for APL. I disagree completely that my "own GUI work" is the
problem !
The "problem" is the "look and feel" is basically boring STD windows,
whereas the Java developers have the ability to buy and use thousands
of "programming modules/classes" etc. etc. for making the appearance
of their Apps much more "swish" and "ergonomically appealing".
We (APL users) do not have that choice !
| |
|
| The whole point of "is basically boring STD windows" is that is
consistent no matter what development environment deploys them. This
ensures that users are presented with a consistent look and feel i.e.
like controls behave identically irrespective of whether it is APL or
anything else that presents them.
The Java stance is to be different i.e this renders users acquired
experience to date with GUI interfaces next to useless ... if they are
that different.
As I said, you can do the user interface in JAVA and have it talk to
the APL business interface. OR, find someway to define the JAVA
controls as custom controls that can be put on APL GUI forms. I know
that this approach is viable with VB6.0 and .NET dontrols.
You did not mention which APL you are using!
| |
| aleph0 2008-01-13, 6:58 pm |
| > The whole point of "is basically boring STD windows" is that is
> consistent no matter what development environment deploys them.
Yes, I'm well aware of that !
On the GUI side, you must yourself have noticed that many new software
Apps are using new GUI ideas ... made avaible via Java and similar,
i.e. no longer sticking to STD WIndows GUI standards.
Take the Ububtu "Look and Feel" or MAcBook's Leopard for example.
There are various "new" and IMO better L&Fs out there.
My original question was aimed at those !
.....like, are we APlers destined to become stuck with the "old"
Windows L&F which I personally do not consider superior to the others
I mentioned !
> You did not mention which APL you are using!
..... my question was general !
| |
|
| Since
1. there are more Windows developers than Linux or Mac developers
taken together
2. there is no organisation (in the world) using Linux or Macs who do
not ALSO use Windows
I'd say that it is Windows that defines the standard; this is far from
being "stuck with the "old"
Windows" ... it is abiding by the most ubiquitous standard.
You said: "I also did a lot of exploratory work on internet
interfacing (Browser DOM models etc. etc. ) as well as reporting loads
of bugs ( 100's of Emails ) in the latest verions of my APL
interpreter." ... note "my APL interpreter". So your question was
hardly general. PS. I have used web forms & DOM from APL without any
problems.
| |
| aleph0 2008-01-13, 6:58 pm |
| Maybe we can get back to the original question ?
<<<AFAIK, most APL vendors interface to the standard Windows GUI
objects.
Is there a possibility of using "Java GUI Modules" instead ?
i.e. Java Classes etc etc.
.... and if so, is it possible without much effort ?[color=darkred]
As to you saying ""I am not aware of the issues you raise""
then I would simply reply that I beg to differ !
From what you have said so far, I take it that the task is by no means
"easy to do " !
Thanks for you effort all the same !
| |
| Jan Karman 2008-01-13, 6:58 pm |
| You might remember Stephen Taylor's comment on "creolisation" in APL.
Just take those features that are useful, not more. The K-GUI philosophy
is a good example
But there are more. Several (mainly internal) applications have made very
efficient use of a scarce extraction of the (Windows) GUI-features (but showed
on diverse APL-conferences, some extensively explained and even distributed
by way of a diskette - too bad if you weren't there).
"aleph0" <apl68000@tiscali.co.uk> wrote in message
news:fb1c2638-a6c2-484f-871b-1a3bda6d419d@l32g2000hse.googlegroups.com...
>
> Yes, I'm well aware of that !
>
> On the GUI side, you must yourself have noticed that many new software
> Apps are using new GUI ideas ... made avaible via Java and similar,
> i.e. no longer sticking to STD WIndows GUI standards.
>
> Take the Ububtu "Look and Feel" or MAcBook's Leopard for example.
> There are various "new" and IMO better L&Fs out there.
>
> My original question was aimed at those !
> ....like, are we APlers destined to become stuck with the "old"
> Windows L&F which I personally do not consider superior to the others
> I mentioned !
>
>
>
>
>
>
> .... my question was general !
>
| |
| aleph0 2008-01-13, 6:58 pm |
| > The K-GUI =A0philosophy is a good example
> But there are more. Several (mainly internal) applications
> have made very> efficient use of a scarce extraction of
> the (Windows) GUI-features (but showed on diverse APL-
> conferences, some extensively explained and even
> distributed by way of a diskette
That sounds interesting ... could you supply a link for me to read
please ?
PS:
The A+ GUI I found extremely innovative .. just a shame they couldn't
implement it under Windows .. too complex to integrate AFAIK ( not
surprisingly ).
| |
| Jan Karman 2008-01-13, 6:58 pm |
| yes, several
http://www.ganuenta.com/annuity.exe
http://www.ganuenta.com/bonds.exe
http://www.ganuenta.com/stocks.exe
http://www.ganuenta.com/mortality.exe
and more at http://www.ganuenta.com/ under samples
APL, J & K (including workspaces & scripts)
"aleph0" <apl68000@tiscali.co.uk> wrote in message
news:658bab0e-4e18-4876-a680-6cbe93b47e9b@f10g2000hsf.googlegroups.com...
> The K-GUI philosophy is a good example
> But there are more. Several (mainly internal) applications
> have made very> efficient use of a scarce extraction of
> the (Windows) GUI-features (but showed on diverse APL-
> conferences, some extensively explained and even
> distributed by way of a diskette
That sounds interesting ... could you supply a link for me to read
please ?
PS:
The A+ GUI I found extremely innovative .. just a shame they couldn't
implement it under Windows .. too complex to integrate AFAIK ( not
surprisingly ).
| |
| Jan Karman 2008-01-14, 3:58 am |
| the K-GUI is only one single command away: `show$`.k
"aleph0" <apl68000@tiscali.co.uk> wrote in message
news:658bab0e-4e18-4876-a680-6cbe93b47e9b@f10g2000hsf.googlegroups.com...
> The K-GUI philosophy is a good example
> But there are more. Several (mainly internal) applications
> have made very> efficient use of a scarce extraction of
> the (Windows) GUI-features (but showed on diverse APL-
> conferences, some extensively explained and even
> distributed by way of a diskette
That sounds interesting ... could you supply a link for me to read
please ?
PS:
The A+ GUI I found extremely innovative .. just a shame they couldn't
implement it under Windows .. too complex to integrate AFAIK ( not
surprisingly ).
| |
| Morten Kromberg 2008-01-14, 7:58 am |
| On Jan 13, 2:15=A0pm, aleph0 <apl68...@tiscali.co.uk> wrote:
> AFAIK, most APL vendors interface to the standard Windows GUI objects.
> Is there a possibility of using "Java GUI Modules" instead ?
> i.e. Java =A0Classes etc etc.
> ... and if so, is it possible without much effort ?
>
> The reason I'm asking ?
>
> Well, a recent example :
> ... a friend of mine recently recieved his personal copy of APL and
> his very first comment was....." the GUI interface looks wrong ; is it
> (APL) installed properly?"
I'm not sure which APL system(s) you are referring to. As far as
Dyalog is concerned, you have access to the same fancy ActiveX
and .Net "custom controls" that users of any language can use. Those
of our customers who spend effort on designing GUI well have state-of-
the art applications which are indistinguishable from anything else
out there. It IS true that APL developers in general tend to focus
more on content that wrapping, and that many APL applications look a
bit rough, but that has little to do with the capabilities of the
interpreter.
We don't do Java, simply because the VAST majority of our customers
are more interested in the Windows platform. We don't have anything
against the platform, it is simply a matter of priorities. We might
well support Java in the future. The Microsoft.Net platform does have
one big advantage, which is that it is "Language Agnostic". Java is a
single-language platform and I think this makes it significantly less
attractive as a framework.
I was not aware that people considered Java to be ahead of Windows in
terms of "look and feel" of the applications.
Regards,
Morten
| |
| David Liebtag 2008-01-14, 7:58 am |
| The APL2-Java interface supports both calling Java from APL2 and APL2 from
Java. You can build APL2 applications with a Java UI if you so desire. It
works on AIX, Linux, Sun Solaris, and Windows.
David Liebtag
IBM APL Products and Services
| |
|
| In article <478b1272$0$25487$ba620dc5@text.nova.planet.nl>,
Jan Karman <*axy*@planet.nl> top-posted:
>the K-GUI is only one single command away: `show$`.k
Plus several dozen settings so it looks and acts the way you want.
Seth
| |
| Jan Karman 2008-01-14, 6:59 pm |
|
"Seth" <sethb@panix.com> wrote in message news:fmg6df$9u5$1@reader2.panix.com...
> In article <478b1272$0$25487$ba620dc5@text.nova.planet.nl>,
> Jan Karman <*axy*@planet.nl> top-posted:
>
> Plus several dozen settings so it looks and acts the way you want.
>
> Seth
eh, yes, but mainly a matter of assignments and ORDER in your script, but quite
limited. The GUI-definitions are in the .dll (I guess). The Causeway
implementation is quite different but also a limited set of GUI-functions
(according to Adrian - "just the useful things"). What both are missing is the
MSWindows functions LOCATOR, but it is in Dyalog. It's a magic thing, to be used
as a ZOOM-IN control. I used it in my APL-version of the graduation function
(but lost it along the road with some other things - must be somewhere around).
In K you make a work around with RANGE buttons.
| |
| Morten Kromberg 2008-01-14, 6:59 pm |
| On Jan 14, 11:19=A0am, Morten Kromberg <mk...@dyalog.com> wrote:
> The Microsoft.Net platform does have
> one big advantage, which is that it is "Language Agnostic". Java is a
> single-language platform and I think this makes it significantly less
> attractive as a framework.
=2E.. but maybe this is about to change, see e.g.
[url]http://www.ew .com/c/a/Application-Development/Sun-Brings-JRuby-InHouse/[/url]
| |
| Ibeam2000 2008-01-15, 3:58 am |
| On Jan 13, 2:15 pm, aleph0 <apl68...@tiscali.co.uk> wrote:
> AFAIK, most APL vendors interface to the standard Windows GUI objects.
> Is there a possibility of using "Java GUI Modules" instead ?
> i.e. Java Classes etc etc.
> ... and if so, is it possible without much effort ?
I haven't tried it myself, but I read that somewhere that MicroAPL
supports Java connectivity. Possibly IBM APL2.
> Well, a recent example :
> ... a friend of mine recently recieved his personal copy of APL and
> his very first comment was....." the GUI interface looks wrong ; is it
> (APL) installed properly?"
With some notable exceptions, such as Swing for Java, the underlying
software to build the gui comes from the operating system (Windows,
Vista, Mac, etc.) or framework (.Net), and in principle you should be
able to build components which have a family resemblance. Swing has a
distinctive look to it, and if that's what you're used to, something
else will look different.
GUI design and ergonomics is an art and science of its own, it's a
fair bit of work to build something which is both visually pleasing
and easy to work with. Dyalog and the others give you the tools to
put the various controls down on a form, but it is another matter to
arrange them well.
Dyalog and Manugistics started releasing their GUI stuff around 1992.
At the time, the alternative was to do GUI development in C, which was
comparatively dreadful and tedious. Today, some 16 years later, the
low-level details are much the same, while lots of software, possibly
of disinterest to the APLer, have emerged, such as Visual Studio,
Eclipse, Swing, and so on. These aid in the initial composition of
the interfaces, but integrating APL computation in these is not
trivial. In a sense, APL computation and the GUI need to be somehow
disconnected, but the very nature of an APL interpreter requires the
two to be too close together.
One thing I would like to look at some day soon is Mozilla, the engine
behind the Firefox browser. Evidently it is possible to build
comprehensive GUIs with .XUL files, handle callbacks, and so on.
| |
| Morten Kromberg 2008-01-15, 3:58 am |
| On Jan 15, 5:39=A0am, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> ... =A0Today, some 16 years later, the
> low-level details are much the same, while lots of software, possibly
> of disinterest to the APLer, have emerged, such as Visual Studio,
> Eclipse, Swing, and so on. =A0These aid in the initial composition of
> the interfaces, but integrating APL computation in these is not
> trivial.
Actually, it IS pretty easy, Visual Studio allows you to build
projects
which consist of bits of Dyalog (in script form) which you call from
your C# application. But VS just isn't an environment which is
condusive
to the kind of work/thinking that APL'ers tend to do. It is a very
very
good "Software Engineers Workbench".
We need another round of GUI work on the APL side soon. Problem right
now is that there are SO many paradigms floating around and new tools
being invented every minute, that it is hard to pick one to use as
the
basis for your nicely integrated tool. APLers don't tend to enjoy
switching platform every couple of years just to play with new
technology.
The design of so many of these tools is also aimed at ultra simple
transactional web apps, and often not appropriate to analytical
computing.
It is only a matter of time, though - we'll get there. In the mean
time,
a little extra work is required to hook the components up if you want
to go beyond Windows or .Net GUI and Web front ends. Note that this
DOES
include a vast array of custom controls etc, these are all usable from
APL.
One fundamental problem is that regardless of the tools you use,
designing a good GUI is a very different skill from writing good APL
code.
Some customers just don't want to train the guys who are good at GUI
and are even less keen on having the good APL programmers to use fancy
GUI
design tools. Of course, one of the main benefits of using APL is the
rapid prototyping that results from a very small team (often one
person)
doing everything. So there is a bit of a Catch-22 situation here.
| |
|
| On Jan 15, 8:36 am, Morten Kromberg <mk...@dyalog.com> wrote:
> design tools. Of course, one of the main benefits of using APL is the
> rapid prototyping that results from a very small team (often one
> person)
> doing everything. So there is a bit of a Catch-22 situation here.
Often this one guy ruins a big project that has been going for a long
time with many people.
They have been spending months of trying to prepare design goals when
he is invited to join in.
During the first meeting this guy produces a complete workable system
and the whole team has no reason to meet again.
The customer loves it but the design team hates this APL guy.
| |
|
| On Jan 14, 11:39 pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
In a sense, APL computation and the GUI need to be somehow
> disconnected, but the very nature of an APL interpreter requires the
> two to be too close together.
I strongly agree with the first phrase and ask what are the minimum
requirements of an APL interpreter and a GUI to be close? As an APL
user, my needs are computation not GUI development. Sure I want some
way to interactively write and execute APL code, but honestly my
minimum requirements don't include a GUI. On my old, old machine
where
APL2 runs under msdos6.1, all of my work was done without windows.
I
can browse, or edit, tranfer-form files with my dos browser or editor.
Seems to me that an APL interpreter has to talk to the operating
system,
but the need to be tied to a GUI .... I'm just not seeing it. Help
me
see what missing here.
Thanks,
Marv
>
> One thing I would like to look at some day soon is Mozilla, the engine
> behind the Firefox browser. Evidently it is possible to build
> comprehensive GUIs with .XUL files, handle callbacks, and so on.
| |
| Jan Karman 2008-01-15, 6:59 pm |
|
"Marv" <smoak@mis.net> wrote in message
news:c260a19b-56bc-459b-a322-92117f7d6eeb@f3g2000hsg.googlegroups.com...
> On Jan 14, 11:39 pm, Ibeam2000 <Ibeam2...@gmail.com> wrote:
> In a sense, APL computation and the GUI need to be somehow
>
> I strongly agree with the first phrase and ask what are the minimum
> requirements of an APL interpreter and a GUI to be close? As an APL
> user, my needs are computation not GUI development. Sure I want some
> way to interactively write and execute APL code, but honestly my
> minimum requirements don't include a GUI. On my old, old machine
> where
> APL2 runs under msdos6.1, all of my work was done without windows.
> I
> can browse, or edit, tranfer-form files with my dos browser or editor.
> Seems to me that an APL interpreter has to talk to the operating
> system,
> but the need to be tied to a GUI .... I'm just not seeing it. Help
> me
> see what missing here.
>
> Thanks,
> Marv
>
nothing, just a slick way to present your results (fortunately the results won't
change with a GUI, although you have to wait a bit longer to see them);
creolization is my advice (please, have a look at the carmakers from Somerset
UK).
>
>
>
>
>
| |
| Morten Kromberg 2008-01-15, 6:59 pm |
| On Jan 15, 6:35=A0pm, Marv <sm...@mis.net> wrote:
> but the need to be tied to a GUI .... =A0I'm just not seeing it. =A0Help
> me see what missing here.
Marv, I don't think you are missing anything. You do not have this
requirement, don't worry about it - I don't think there is anything
wrong with you :-). APL systems will hopefully continue to support
your way of working for ever (certainly, this is a goal that we
constantly remind ourselves of at Dyalog).
But some people want to use APL to deliver solutions to people who do
need an interface to help them enter arguments to the APL functions,
and these people have developed expectations about what these
interfaces should look like. If you want to "compete" in a commercial
marketplace, you sometimes need to pander to these expectations.
Morten
| |
| aleph0 2008-01-15, 6:59 pm |
| <<< But some people want to use APL to deliver solutions to people who
do need an interface to help """them enter arguments to the APL
functions,""" >>
?
Please expand on this one !
You can't be serious I hope !
| |
|
| On Jan 15, 10:14=A0pm, aleph0 <apl68...@tiscali.co.uk> wrote:
> <<< But some people want to use APL to deliver solutions to people who
> do need an interface to help """them enter arguments to the APL
> functions,""" =A0>>
>
> ?
> Please expand on this one !
> You can't be serious I hope !
I would guess he means you make GUI interface to APL functions instead
of letting the customer type in the names of the APL functions.
| |
| Bob Cain 2008-01-16, 3:59 am |
| aleph0 wrote:
> <<< But some people want to use APL to deliver solutions to people who
> do need an interface to help """them enter arguments to the APL
> functions,""" >>
>
> ?
> Please expand on this one !
> You can't be serious I hope !
Think sliders, knobs and meters. When appropriate they are more than just
useful. Their abstraction allows a closer approach to the deep nature of many
an application than does the entering of numeric arguments.
Bob
--
"Things should be described as simply as possible, but no simpler."
A. Einstein
| |
| Morten Kromberg 2008-01-16, 7:57 am |
| On Jan 15, 11:28=A0pm, Gosi <gos...@gmail.com> wrote:
> I would guess he means you make GUI interface to APL functions instead
> of letting the customer type in the names of the APL functions.
Yes, sorry if I was a bit too metaphoric there. I see a the GUI as a
way to feed the APL functions at the core of the system with
arguments. I frequently long for the "open systems" that we used back
in the good old days before both GUI and "Full Screen" character
applications. Paying customers would log on to the APL system and type
things like:
1 3 5 DAILY, DATED 1 70 TO 12 79
PUT CURRENCY 'CBUSB,CBGBP'
TITLE 'COPENHAGEN BUY'
PLOT ABOVE
Today, this type of design is in the process of being rediscovered,
they call it an "Embedded Domain Specific Notation" and it is one of
the hot new ideas that "agile" people talk about when they discuss
solving the software productivity crisis :-)
| |
| Ibeam2000 2008-01-17, 3:58 am |
|
Morten, I find this statement particularly appropriate, as I myself am
coming to grips with
what I like (not a lot) and not like (lots) about VS.
> But VS just isn't an environment which is condusive
> to the kind of work/thinking that APL'ers tend to do. It is a very
> very good "Software Engineers Workbench".
Generally, in many ways, I find returning to VS like returning to the
stone age, er, the days of Fortran. Although the interface is slick
and appealing, I find that it's still a very tough slog to get
something rather simple to work. The fact that the editor provides
not only syntax colouring but "intellisense", plus instant syntax
checking, is nice, but there is no hiding from the fact that this is
really an interface to a compiler and that any interactive debugging
as we know it from APL is long gone. VS tries to polish up the
miserable language underneath, C# or VB or whatever. It does a good
job.
Having said that, I think that VS excels at what it was designed to do
- gui composition and single user code management.
| |
| Stephen Taylor 2008-01-17, 7:58 am |
| I've hestitated to enter this discussion because of my limited
experience writing GUIs. On the other hand, that is arguably why many
of us took up APL: to minimise attention to implementation details.
With GUI, as with so much else, I want usable results, not to master
its ten thousand aspects.
Jan Karman referred to things I've said about 'creolised technology'.
The term is not mine but David Edgerton's "The Shock of the New:
Technology and Global History since 1900". Edgerton describes how
African mechanics simplify sophisticated western cars to run in rugged
conditions, replacing complex parts with simple, locally-made ones.
Applications for use by very large numbers of unskilled people, such
as Excel, or Amazon.com, can justify investing heavily in GUI code for
even small improvements in usability. The applications I work on
cannot. Chrome, as they say, is for customers.
Worse: code volume and complexity harden software, reducing its
authors' ability to adapt it. In the systems I work on, that
adaptability is valued. Care must be taken to conserve it, to keep the
software soft. In principle there are usability gains available that
would justify the cost of writing more GUI, but not the added 'drag'
on further development. (The 37signals software team, that produced
Rails, writes eloquently on this theme. The Somerset car makers were
featured in their blog "Signal vs Noise".)
I've had a little prior experience with a Windows GUI. The developers
migrated the application from a mainframe in early PC days, and worked
out a framework for relating GUI forms and data records; it is
unlikely to represent the best that could be done now. Still, and
leaving aside the inherent difficulties of writing GUIs, clearly a
deep art, I was dismayed by the volume and complexity of the GUI code.
In particular I was concerned by:
-- extensive mapping between GUI controls and arrays representing
'records', with much explicit translation between enumerators and
corresponding text
-- flow of control obscured through callbacks defined far apart in the
code
-- extensive use of names to refer to parts of the GUI, making it hard
to move or adapt GUI code
-- names of controls unrelated to domain semantics, eg an Edit control
called E3 rather than Postcode
I missed the simplicity and brevity of punching arrays in the session.
Could GUI code not be more like that?
My current development project in V11 has given me a chance to try, as
I found no precedents for writing GUI in Dyalog using classes. I've
been able to derive fairly simple subclasses for Forms and controls in
which
-- controls manage their own labels
-- controls bound to database tables translate enumerators
-- form layout is defined by readable program code, not gestures with a
design tool
-- the application GUI is defined (1 large callback excepted) in a
single script
-- classes corresponding to business objects (eg Company) support their
own Edit and Display methods
This last gets me close to the session interface Morten remembers so
fondly. My prior GUI experience felt like working in a house of cards;
I daresay I'm clumsy. All the GUI structure had to be set up and set
running then interrupted before anything could be tested or used.
Disturbing parts of the structure meant patching it or rebuilding it.
In contrast I can now, in the session and with an empty stack type:
([]NEW Company 87).Edit
and a form pops up on which I can edit the record for that company and
save changes to the database. Similarly
({[]NEW Company w}=A887 92 105).Display
returns 3 HTML DIVs from which to compose a display.
The readable code for layouts -- no form designer tool used -- looks
like this:
Postcode.Posn <- 20 0 + 'BL' cnr Address
The Postcode edit field appears 20px below the bottom left corner of
the Address field.
With this kind of modularity I was able recently to rewrite the entire
outer GUI for the application in a day.
This is still a work in progress. I don't have experience in C# or VB
with which to contrast it. But the forms look sharp. The application
code is short, readable and makes minimal use of conventions. My only
devt tool is the code. This feels like creolised technology for the
first time since I left the session.
I expect much of this to appear in the programming cookbook we're
working on at Dyalog this year. In the meantime I'd be glad to hear
from anyone interested in this line of development.
Stephen Taylor
sjt@dyalog.com
On Jan 15, 6:00 pm, "Jan Karman" <*a...@planet.nl> wrote:
> "Marv" <sm...@mis.net> wrote in message
> nothing, just a slick way to present your results (fortunately the results=
won't
> change with a GUI, although you have to wait a bit longer to see them);
> creolization is my advice (please, have a look at the carmakers from Somer=
set
> UK).
On Jan 16, 10:36 am, Morten Kromberg <mk...@dyalog.com> wrote:
> On Jan 15, 11:28 pm, Gosi <gos...@gmail.com> wrote:
>
>
> Yes, sorry if I was a bit too metaphoric there. I see a the GUI as a
> way to feed the APL functions at the core of the system with
> arguments. I frequently long for the "open systems" that we used back
> in the good old days before both GUI and "Full Screen" character
> applications. Paying customers would log on to the APL system and type
> things like:
>
> 1 3 5 DAILY, DATED 1 70 TO 12 79
> PUT CURRENCY 'CBUSB,CBGBP'
> TITLE 'COPENHAGEN BUY'
> PLOT ABOVE
>
> Today, this type of design is in the process of being rediscovered,
> they call it an "Embedded Domain Specific Notation" and it is one of
> the hot new ideas that "agile" people talk about when they discuss
> solving the software productivity crisis :-)
| |
| Jan Karman 2008-01-17, 9:59 pm |
| Once (I think it was 1997) I visited a plenary session for a presentation on J
(it said) by Chris Burke. I remember it was a bit disappointing - my neightbour
had the same feelings, he said: "I thought this was about J". It was just about
Windows GUI's.
"Stephen Taylor <editor@vector.org.uk>" <StephenTaylorFRSA@googlemail.com> wrote
in message
news:0d6d0d69-d79d-436f-a5c0-4b3c2d858fe2@u10g2000prn.googlegroups.com...
I've hestitated to enter this discussion because of my limited
experience writing GUIs. On the other hand, that is arguably why many
of us took up APL: to minimise attention to implementation details.
With GUI, as with so much else, I want usable results, not to master
its ten thousand aspects.
Jan Karman referred to things I've said about 'creolised technology'.
The term is not mine but David Edgerton's "The Shock of the New:
Technology and Global History since 1900". Edgerton describes how
African mechanics simplify sophisticated western cars to run in rugged
conditions, replacing complex parts with simple, locally-made ones.
Applications for use by very large numbers of unskilled people, such
as Excel, or Amazon.com, can justify investing heavily in GUI code for
even small improvements in usability. The applications I work on
cannot. Chrome, as they say, is for customers.
Worse: code volume and complexity harden software, reducing its
authors' ability to adapt it. In the systems I work on, that
adaptability is valued. Care must be taken to conserve it, to keep the
software soft. In principle there are usability gains available that
would justify the cost of writing more GUI, but not the added 'drag'
on further development. (The 37signals software team, that produced
Rails, writes eloquently on this theme. The Somerset car makers were
featured in their blog "Signal vs Noise".)
I've had a little prior experience with a Windows GUI. The developers
migrated the application from a mainframe in early PC days, and worked
out a framework for relating GUI forms and data records; it is
unlikely to represent the best that could be done now. Still, and
leaving aside the inherent difficulties of writing GUIs, clearly a
deep art, I was dismayed by the volume and complexity of the GUI code.
In particular I was concerned by:
-- extensive mapping between GUI controls and arrays representing
'records', with much explicit translation between enumerators and
corresponding text
-- flow of control obscured through callbacks defined far apart in the
code
-- extensive use of names to refer to parts of the GUI, making it hard
to move or adapt GUI code
-- names of controls unrelated to domain semantics, eg an Edit control
called E3 rather than Postcode
I missed the simplicity and brevity of punching arrays in the session.
Could GUI code not be more like that?
My current development project in V11 has given me a chance to try, as
I found no precedents for writing GUI in Dyalog using classes. I've
been able to derive fairly simple subclasses for Forms and controls in
which
-- controls manage their own labels
-- controls bound to database tables translate enumerators
-- form layout is defined by readable program code, not gestures with a
design tool
-- the application GUI is defined (1 large callback excepted) in a
single script
-- classes corresponding to business objects (eg Company) support their
own Edit and Display methods
This last gets me close to the session interface Morten remembers so
fondly. My prior GUI experience felt like working in a house of cards;
I daresay I'm clumsy. All the GUI structure had to be set up and set
running then interrupted before anything could be tested or used.
Disturbing parts of the structure meant patching it or rebuilding it.
In contrast I can now, in the session and with an empty stack type:
([]NEW Company 87).Edit
and a form pops up on which I can edit the record for that company and
save changes to the database. Similarly
({[]NEW Company w}¨87 92 105).Display
returns 3 HTML DIVs from which to compose a display.
The readable code for layouts -- no form designer tool used -- looks
like this:
Postcode.Posn <- 20 0 + 'BL' cnr Address
The Postcode edit field appears 20px below the bottom left corner of
the Address field.
With this kind of modularity I was able recently to rewrite the entire
outer GUI for the application in a day.
This is still a work in progress. I don't have experience in C# or VB
with which to contrast it. But the forms look sharp. The application
code is short, readable and makes minimal use of conventions. My only
devt tool is the code. This feels like creolised technology for the
first time since I left the session.
I expect much of this to appear in the programming cookbook we're
working on at Dyalog this year. In the meantime I'd be glad to hear
from anyone interested in this line of development.
Stephen Taylor
sjt@dyalog.com
On Jan 15, 6:00 pm, "Jan Karman" <*a...@planet.nl> wrote:
> "Marv" <sm...@mis.net> wrote in message
> nothing, just a slick way to present your results (fortunately the results
> won't
> change with a GUI, although you have to wait a bit longer to see them);
> creolization is my advice (please, have a look at the carmakers from Somerset
> UK).
On Jan 16, 10:36 am, Morten Kromberg <mk...@dyalog.com> wrote:
> On Jan 15, 11:28 pm, Gosi <gos...@gmail.com> wrote:
>
>
> Yes, sorry if I was a bit too metaphoric there. I see a the GUI as a
> way to feed the APL functions at the core of the system with
> arguments. I frequently long for the "open systems" that we used back
> in the good old days before both GUI and "Full Screen" character
> applications. Paying customers would log on to the APL system and type
> things like:
>
> 1 3 5 DAILY, DATED 1 70 TO 12 79
> PUT CURRENCY 'CBUSB,CBGBP'
> TITLE 'COPENHAGEN BUY'
> PLOT ABOVE
>
> Today, this type of design is in the process of being rediscovered,
> they call it an "Embedded Domain Specific Notation" and it is one of
> the hot new ideas that "agile" people talk about when they discuss
> solving the software productivity crisis :-)
| |
| David Liebtag 2008-01-17, 9:59 pm |
| I too hesitate to enter this fray, but I do have two comments:
First, I really like Stephen's approach.
Second, I think we should give some credit where credit is due. Yes, adding
a GUI front-end to APL applications usually frequently adding a bunch of
stuff that can obscure the elegance of the underlying application. However,
it would be much, much, much worse in most other languages. In general, the
APL development teams have done a wonderful job of simplfying the interfaces
to the operating systems' GUI facilities. Writing GUI code in languages
like C typically requires at least an order of magnitude more code than in
APL. And, most operating systems' GUI APIs are so inconsistent as to be
nearly impenetrable. The APL development teams have done a lot of good work
to build consistent interfaces to the OS's GUI APIs so developers have to
learn much less than they might otherwise have to. Of course, there's room
for improvement, but I for one am glad whenever I can write GUI code in APL
rather than C.
David Liebtag
| |
| aleph0 2008-01-17, 9:59 pm |
| "Second, I think we should give some credit where credit"
Agree , and as I originally stated, the small APL vendors have all
done an excellent job IMO !
BTW... Have you tryed the A+ GUI-solution under Unix ?
The ".s" context feels very natural .. like APL.
No fuss, no tens of parameters that need tweaking, mostly defaults
that get your data onto the screen in an efficient way. You can then
use "geometry" to then tweak it around if you want.
Also, didn't Soliton do something along the lines of a Java (GUI-
server) interface .
Has anyone here used it at all ?
Getting back to my original question ...
Sure the current APL GUI interfacess are excellent, but basically
limiting one to using the STD Windows modules ...
Here's just a small ( some might say "unimportant" ) example.
Suppose you use the BCol property to set the background colour of a
SubForm to pastel green.
If you want to set a "Push" Button to for example a darker shade of
green , you simply can't , you are stuck with the standard Windows
color (e.g. grey ... or the underlying color-scheme set by the user)!
Same applies to Tab Controls and probably a few others.
FWIW
| |
| Jan Karman 2008-01-17, 9:59 pm |
| if I remember correctly (it has been more than ten years) you can easily set any
color on any button, untouched, before, after being pushed, anything. There's a
"colormap" which you can pick from e.g. the Clipboard, at your choice 16 colors,
256 colors &c. I had an application with patterns of colors on each buttons -
only you need to know how to do it. (BTW I used Causeway, that was just filling
out tables - the famous EAT)
"aleph0" <apl68000@tiscali.co.uk> wrote in message
news:abbff2f2-94a1-4951-9397-b823f10bfd01@q77g2000hsh.googlegroups.com...
> "Second, I think we should give some credit where credit"
>
> Agree , and as I originally stated, the small APL vendors have all
> done an excellent job IMO !
>
> BTW... Have you tryed the A+ GUI-solution under Unix ?
> The ".s" context feels very natural .. like APL.
> No fuss, no tens of parameters that need tweaking, mostly defaults
> that get your data onto the screen in an efficient way. You can then
> use "geometry" to then tweak it around if you want.
>
> Also, didn't Soliton do something along the lines of a Java (GUI-
> server) interface .
> Has anyone here used it at all ?
>
>
>
>
>
> Getting back to my original question ...
> Sure the current APL GUI interfacess are excellent, but basically
> limiting one to using the STD Windows modules ...
>
> Here's just a small ( some might say "unimportant" ) example.
>
> Suppose you use the BCol property to set the background colour of a
> SubForm to pastel green.
> If you want to set a "Push" Button to for example a darker shade of
> green , you simply can't , you are stuck with the standard Windows
> color (e.g. grey ... or the underlying color-scheme set by the user)!
> Same applies to Tab Controls and probably a few others.
>
> FWIW
>
>
>
| |
| aleph0 2008-01-17, 9:59 pm |
| Thx Jan, I am aware of that. It is simply that I prefer to reduce the
amount of work involving the GUI rather than increasing it. i.e. A
working BCol on "Push" would have sufficed , rather than having to add
and maintain bitmaps etc.
| |
| aleph0 2008-01-17, 9:59 pm |
| BTW .. using Bitmaps still doesn't actually solve the problem.
Take the TabControl and TabButton objects just for example.
Correct me if I'm wrong, but neither have a BCol or Bitmap
possibility.
So if your SubForm (or Form) has a coloured background, your
TabControl and TabButton will still appear STD (e.g. grey).
Or maybe you have a solution that I have missed ?
| |
|
| In article <9e6eb8e0-df46-4064-b2fc-981d9d1c561e@s19g2000prg.googlegroups.com>,
aleph0 <apl68000@tiscali.co.uk> wrote:
><<< But some people want to use APL to deliver solutions to people who
>do need an interface to help """them enter arguments to the APL
>functions,""" >>
>
>?
>Please expand on this one !
>You can't be serious I hope !
The user wants to type an instrument ID and get all the data fields
filled in.
Then he changes a few of them (or none) and hits a button to price
it. Then he fiddles with the data a little more and tries again.
What CLI interface would you use for that? Remember, users are slow
and bad at typing, and make mistakes.
Seth
| |
| Jan Karman 2008-01-17, 9:59 pm |
|
"aleph0" <apl68000@tiscali.co.uk> wrote in message
news:c212ce0a-7acb-4714-b81f-d7f0a3755d63@x69g2000hsx.googlegroups.com...
> Thx Jan, I am aware of that. It is simply that I prefer to reduce the
> amount of work involving the GUI rather than increasing it. i.e. A
> working BCol on "Push" would have sufficed , rather than having to add
> and maintain bitmaps etc.
>
then, use K
| |
| Jan Karman 2008-01-17, 9:59 pm |
|
"aleph0" <apl68000@tiscali.co.uk> wrote in message
news:404ff488-4c9f-411e-9d61-1a2b906e1163@m34g2000hsf.googlegroups.com...
> BTW .. using Bitmaps still doesn't actually solve the problem.
>
> Take the TabControl and TabButton objects just for example.
> Correct me if I'm wrong, but neither have a BCol or Bitmap
> possibility.
> So if your SubForm (or Form) has a coloured background, your
> TabControl and TabButton will still appear STD (e.g. grey).
> Or maybe you have a solution that I have missed ?
>
>
no, no Bitmaps, please ...
| |
| Jan Karman 2008-01-17, 9:59 pm |
|
"Jan Karman" <*axy*@planet.nl> wrote in message
news:478f8d7f$0$25496$ba620dc5@text.nova.planet.nl...
>
> "aleph0" <apl68000@tiscali.co.uk> wrote in message
> news:c212ce0a-7acb-4714-b81f-d7f0a3755d63@x69g2000hsx.googlegroups.com...
>
> then, use K
>
btw, you can do seamless APL in K. I once showed a friend, experienced APL-er. I
had copied several functions of his, just by replacing the primitives; he said:
I don't see any APL! (when in APL he would have seen in it in a glance - he is
dreaming in APL ...)
| |
| aleph0 2008-01-17, 9:59 pm |
| "then, use K"
I would love to try K !
Where can I get a "personal" copy ?
The only prices I've seen are corporate prices !
| |
| Stephen Taylor 2008-01-18, 3:58 am |
| On Jan 17, 7:33 pm, aleph0 <apl68...@tiscali.co.uk> wrote:
> "then, use K"
>
> I would love to try K !
> Where can I get a "personal" copy ?
> The only prices I've seen are corporate prices !
You might be able to arrange this. I'm unsure of Kx's current policy,
but they are generally supportive of people willing to invest time in
learning either K or Q. Just ask them.
| |
| Jan Karman 2008-01-18, 7:58 am |
| there's also still a kx forum (albeit read-only)
http://www.kxforums.com/kxf/index.php
and maybe you can find somewhere the contents of the earlier kx-listbox with
myriads of k-algorithms (and you'll get the taste of the atmosphere between
users of K/Kdb for free!)
"Stephen Taylor <editor@vector.org.uk>" <StephenTaylorFRSA@googlemail.com> wrote
in message
news:385397a8-0a91-4b1e-abe5-e36fc443d36c@l1g2000hsa.googlegroups.com...
> On Jan 17, 7:33 pm, aleph0 <apl68...@tiscali.co.uk> wrote:
>
> You might be able to arrange this. I'm unsure of Kx's current policy,
> but they are generally supportive of people willing to invest time in
> learning either K or Q. Just ask them.
| |
| Morten Kromberg 2008-01-19, 7:58 am |
| On Jan 17, 6:16=A0pm, "Jan Karman" <*a...@planet.nl> wrote:
> "aleph0" <apl68...@tiscali.co.uk> wrote in message
>
> news:c212ce0a-7acb-4714-b81f-d7f0a3755d63@x69g2000hsx.googlegroups.com...
>
>
> then, use K
There are some interesting conflicts here:
1) You want to do as little as possible, but
2) Have access to high level widgets provided by the platform, like
Windows TabControls, yet
3) Have complete control over colours etc (although the high level
widgets use "Themes" and explicitly try to deny you access to low
level control - changing the colour of individual elements of a
TabContol would be considered VERY BAD UI by the "experts")
Well, you can't have it all at once... :-)
And, while I think K is a really  and ultra fast "reduced
instruction set" APL, expecially if you want to work with large
quantities of inverted data, I don't think it would be my choice of
GUI programming platform. Besides which, I believe that recent
versions of K no longer include the GUI, as it did not satisfy clients
well enough to be worth the effort (most customers have other
requirements for GUI than doing as little as possible). Today, I think
the Kx folks recommend using K for the computational engine and
something else like Java, VB, or Dyalog (I was invited to present at
the Kx User Meeting last year) for the frontend.
Morten
| |
| aleph0 2008-01-19, 7:58 am |
| I agree , but I would hope you'd agree that the ".s" context in A+ is
more than sweet ! .. probably impossible to implement under Windows
without massive resources ! The Dyalog GUI and APLX implementations
under WIndows are both excellent, apart from the limitations imposed
by having to stick to STD Windows GUI of course !
While we're on the subject of Windows interfacing, here is a small
collection of []NA functions that I use occasionally under Dyalog ...
[]NA'I user32.C32|SetCapture I'
[]NA'I user32.C32|ReleaseCapture'
[]NA'I user32.C32|WindowFromPoint I I'
[]NA'I user32.C32|GetCursorPos >I[2]'
[]NA'I user32.C32|SetCursorPos I I'
[]NA'I user32.C32|ScreenToClient I =3DI[2]'
'smgih' []NA'I4 user32.C32|SendMessageA I4 U I4 =3D{U U U U I4 I4 I4 I4
I4 I4}'
[]NA'I2 user32.C32|GetKeyState I'
'smht'[]NA'I4 user32.C32|SendMessageA I4 U I4 =3D{I[2] U I4}'
'smsh'[]NA'I4 user32.C32|SendMessageA I4 U I4 U'
[]NA'I2 user32.C32|GetKeyboardState >I1[256]'
[]NA'u kernel32|GetDiskFreeSpaceExA <0T >u[2] >u[2] >u[2]'
'beep'[]NA'user32=1DMessageBeep i'
[]NA'U4 user32|GetCaretPos >{I I}'
=2E.. some of which were supplied in the Dyalog "help" , others I found
elsewhere.
Also, on using Drag-and-Drop ..
Someone donated an excellent little Drag-and-Drop tool-suite for use
within Dyalog which utilzed
the following []NA items ( amongst others) GetCursorPos,
WindowFromPoint, ScreenToClient etc.
( concerning Drag-and-Dropping single items from/to various List-types
etc. )
Something that I found very useful , enlightening and timesaving !
The use of the CGView.dll for managing various Image-types should IMO
be online for APlers to see as well !
There are certainly many more []NA functions and other little tid-bits
that would be more than useful to developers !
I would have liked to have seen a larger "Collection" made available
online , e.g. the Dyalog website,
to assist APL developers in their work, rather than each of us having
to "search for them ourselves" !
Maybe such a collection already exists ????
| |
| Jan Karman 2008-01-19, 7:58 am |
| I don't think this is a conflict - it's more of a choice. While with K (as I
know it from a couple of years ago; first, I admit I'm not quite up to date) you
can present your results in a fast but DECENT view, with Dyalog (and others) you
may really compose Windows GUI applications in a PROFESSIONAL view, properly
balanced between the underlying language for data processing and the GUI.
For instance, for major applications from a users point of view I'd pick Dyalog
with Causeway, an unmatched combination! (less pain than one would think; maybe
a steep learning curve, but that pays off)
"Morten Kromberg" <mkrom@dyalog.com> wrote in message
news:6b5c0afe-2f8b-48d9-b563-69e541058094@u10g2000prn.googlegroups.com...
On Jan 17, 6:16 pm, "Jan Karman" <*a...@planet.nl> wrote:
> "aleph0" <apl68...@tiscali.co.uk> wrote in message
>
> news:c212ce0a-7acb-4714-b81f-d7f0a3755d63@x69g2000hsx.googlegroups.com...
>
>
> then, use K
There are some interesting conflicts here:
1) You want to do as little as possible, but
2) Have access to high level widgets provided by the platform, like
Windows TabControls, yet
3) Have complete control over colours etc (although the high level
widgets use "Themes" and explicitly try to deny you access to low
level control - changing the colour of individual elements of a
TabContol would be considered VERY BAD UI by the "experts")
Well, you can't have it all at once... :-)
And, while I think K is a really and ultra fast "reduced
instruction set" APL, expecially if you want to work with large
quantities of inverted data, I don't think it would be my choice of
GUI programming platform. Besides which, I believe that recent
versions of K no longer include the GUI, as it did not satisfy clients
well enough to be worth the effort (most customers have other
requirements for GUI than doing as little as possible). Today, I think
the Kx folks recommend using K for the computational engine and
something else like Java, VB, or Dyalog (I was invited to present at
the Kx User Meeting last year) for the frontend.
Morten
| |
| Jan Karman 2008-01-19, 7:58 am |
|
"aleph0" <apl68000@tiscali.co.uk> wrote in message
news:7b4208bd-1ac6-45f1-bdec-b575d7aad22a@i72g2000hsd.googlegroups.com...
>I agree , but I would hope you'd agree that the ".s" context in A+ is
> more than sweet ! .. probably impossible to implement under Windows
> without massive resources ! The Dyalog GUI and APLX implementations
> under WIndows are both excellent, apart from the limitations imposed
> by having to stick to STD Windows GUI of course !
[...]
> Maybe such a collection already exists ????
I thought Causeway offers such a collection
| |
| Veli-Matti 2008-01-19, 7:58 am |
| aleph0 wrote:
> While we're on the subject of Windows interfacing, here is a small
> collection of []NA functions that I use occasionally under Dyalog ...
....
Any hope to get some instructions/documentation what those []NA's are
used for, and how? Being a non-English, non-kernel guy who doesn't like
exploring msdn, and having experienced pretty many Dyalog crashes when
trying to find out the usage with guess-and-try methods, is not really
encouraging... For example, you have three separate SendMessageA calls,
and that's enough to make me at least curious.
Actually what I'd like to have, is both a collection of usable,
documented and exampled []NA routines, and a similar collection of
useful OLE controls - when my friend showed me how easily he could
search and view videos from YouTube in a small Dyalog GUI, I was (and
still am) astounded.
> Also, on using Drag-and-Drop ..
> Someone donated an excellent little Drag-and-Drop tool-suite for use
Sounds like Stefano (Lanzavecchia), and if I recall it right, it was
published in Vector some years ago.
> Maybe such a collection already exists ????
Ray Cannon has collected a huge workspace (dllsp.dws) which might be
downloadable from Vector site, and Konrad Hoesle-Kinzlen had a similar
free workspace, too.
- Veli-Matti
| |
| Dick Bowman 2008-01-20, 3:57 am |
| aleph0 <apl68000@tiscali.co.uk> wrote in news:7b4208bd-1ac6-45f1-bdec-
b575d7aad22a@i72g2000hsd.googlegroups.com:
>[... deleted ...]
>
> There are certainly many more []NA functions and other little tid-bits
> that would be more than useful to developers !
>
> I would have liked to have seen a larger "Collection" made available
> online , e.g. the Dyalog website,
> to assist APL developers in their work, rather than each of us having
> to "search for them ourselves" !
>
> Maybe such a collection already exists ????
Why don't you either add what you have as a page to the APL Wiki, or put
your stuff onto a site of your own and let people know where it is?
| |
|
| In article <47908510$0$25476$ba620dc5@text.nova.planet.nl>,
Jan Karman <*axy*@planet.nl> wrote:
>there's also still a kx forum (albeit read-only)
>http://www.kxforums.com/kxf/index.php
>
>and maybe you can find somewhere the contents of the earlier kx-listbox with
>myriads of k-algorithms (and you'll get the taste of the atmosphere between
>users of K/Kdb for free!)
The listbox still exists. They tried moving to the web forum, but
that didn't get enough posters to be very useful.
Seth
| |
| aleph0 2008-01-20, 6:59 pm |
| >>> Maybe such a collection already exists ????
>
> Why don't you either add what you have as a page to the
> APL Wiki, or put your stuff onto a site of your own and
> let people know where it is?
LOL! .. I was expected this response sooner or later.
;-)
Well, I have no problem with that, except that I expected this
initiative from the Vendors themselves ... and I'm sure that there are
people out there that could immediately provide bigger lists than I
have.
Let's see if any Vendors volunteer ? !
I think the correct "place" for holding such Collections is the
Vendor's Website ! If they don't want to do this , then maybe I'll do
so !
PS:
I would also hope that the readers would then also "contribute" any
additions they themselves might have !
PPS:
One could also add a series of APL code examples in terms of how to
implement certain things.
Visual examples as well as tool-WS downloads !
| |
| Morten Kromberg 2008-01-21, 3:59 am |
| On Jan 20, 11:07=A0am, aleph0 <apl68...@tiscali.co.uk> wrote:
>
>
> LOL! =A0.. I was expected this response sooner or later.
> ;-)
>
> Well, I have no problem with that, except that I expected this
> initiative from the Vendors themselves ... and I'm sure that there are
> people out there that could immediately provide bigger lists than I
> have.
>
> Let's see if any Vendors volunteer ? !
We do intend to write GUI code samples and publish them on the
APLWiki, our own web site and other places this year (just need to get
v12 out first, and as usual it is resisting our attempts to close the
lid on the box). But I did NOT envisage Dyalog publishing []NA calls
which are workarounds for what people perceive to be missing features
in our GUI. The main reason for this being that if WE publish them,
people will expect us to have verified that they have no bad side-
effects etc when used with our GUI, and I don't think we are able to
do that. It would be easier for us to add the missing functionality,
probably.
We WOULD be very interested in seeing the functions, as they will be
good inspiration for new features to add to the product (several such
functions HAVE been catalysts for new Dyalog GUI features in the
past).
So this is a good time to remember JFK: "Ask not what your APL Vendor
can do for you... etc".
Morten
| |
| aleph0 2008-01-21, 8:00 am |
| > So this is a good time to remember JFK: "Ask not what your
> APL Vendor can do for you... etc".
;-)
> if WE publish them, people will expect us to have verified
OK.. I see your point !
BTW, in Dyalog Versions 11 and 12 ..
....are ColTitles in ListView now available as "multiline" by any
chance ?
e.g. having a nested rather than a "simple text" column-title ? ... or
simply a CR embedded and EOL breaker for example !
Also, it would be nice to have a single Overview (comparison) page on
your website showing the "detailed" differences between the various
Released versions.
| |
| microapl@microapl.demon.co.uk 2008-01-22, 8:00 am |
| I saw this interesting thread when I got back after a vacation. In
response to the original questions/comments:
> AFAIK, most APL vendors interface to the standard Windows GUI objects.
> Is there a possibility of using "Java GUI Modules" instead ?
> i.e. Java Classes etc etc.
> ... and if so, is it possible without much effort ?
As far as APLX is concerned, yes we interface directly to the
underlying OS GUI objects under both Windows and MacOS. This is a
deliberate design decision, as we want the GUI objects to have the
'correct' look-and-feel for the platform. At the same time, we try
very hard to make the programming interface to the GUI objects both
portable and easy-to-use (and if possible also compatible with APL
+Win's []WI). Clearly there are trade-offs in this, but I hope we've
got the balance about right.
Of course, we can't provide natural APL interfaces to every possible
feature of every possible GUI element of a modern operating system;
there are simply too many even to document, let alone implement! If
something which you need is missing, you can often get access it using
low-level programming ([]NA, for example). But this shouldn't
normally be necessary, and we ask our users to let us know if they
need to resort to low-level programming, so that we can look at the
possibility of providing the missing feature in a portable, easy-to-
use way.
An interesting development of the last couple of years (at least in
APLX and Dyalog) is the possibility of programming the user interface
under Windows using the .Net frameworks directly from APL, using the
new object-oriented APL language features. It is easy to do, and has
the advantage that all the features available to (say) a C# programmer
are immediately available to the APL programmer, without the APL
vendor having to do anything, and with an easy-to-use syntax. The
di vantages of this approach are:
(a) it is more complex than using the built-in APL GUI objects (which
we now call 'System Classes'). This is mainly because programming
the .Net classes tends to require an understanding of huge numbers of
small utility classes, and you often end up burrowing down lots of
documentation to find out how to do something very simple.
(b) it is Windows-specific (although the open-source Mono frameworks
are developing nicely and in the near future should provide fully-
functional, portable equivalents to all of the most important .Net GUI
classes).
My hunch is that most of our users will continue to use the built-in
APLX System Classes for GUI programming, but a few who really need to
take full advantage of the .Net GUI frameworks will think it
worthwhile to put in the extra programming effort to use them
directly.
As for Java, APLX v4 also allows you to make direct use of Java
classes, just as you can use .Net classes. So in theory, you can use
Java GUI classes directly if you want to. (There are some issues with
event handling, which for complex technical reasons is easier
in .Net). It will be interesting to see if our users want to explore
this option. I believe that Java implements all of its own GUI
elements, in the interests of portability; for example, it draws its
own buttons. As a result, many people think that Java applications
often do not look very good. (I'll admit it, I'm one of them. In
fact, my heart sinks when I see the Java logo on an application, as in
my experience it often seems to mean that the application is slow and
clunky. Just my personal opinion, you understand...). The strength
of Java is more, I believe, at the Server end, where it is very
heavily used in 'enterprise' applications, and this is the area where
we expect our users to want use Java classes from APLX. But if people
want to use Java GUI classes from APLX, that's fine, and we'll provide
help and support if necessary.
The other thing I would say is that I believe that (at least for
simpler applications) APL is an excellent language for designing and
programming GUI applications. Of course, Visual Studio and other
modern development tools have very good interactive design tools,
which we lack. I have been using such tools from many different
vendors in many different programming languages for around twenty
years, and I fully recognise their usefulness. However, the
interactive nature of APL provides an alternative apporach which, on
balance, I often prefer. In APL you can just write a function (or
class) to create, display, test, amd tweak a dialog directly, without
having to run the whole application as you typically have to do in
other environments, and I find that a big advantage. Just varying the
position or size of a button (by typing into the session window) until
the dialog looks right is often easier than using the design tool,
especially if you're trying to align a set of controls or adjust their
sizes. It's also often easier to make stuctural changes (for example,
if you decide to move a set of buttons, list boxes and text fields on
to a new Tab control).
Richard Nabavi
MicroAPL Ltd
| |
| J. Goff 2008-01-22, 7:01 pm |
| In the GUI arena, I don't think that the way forward is that complicated or
mysterious. Here some choices:
1) An APL vendor with large resources and a better idea can make the
substantial investment required to create a superior way to handle GUI, or
they can
2) Use industry standard techniques for creating GUIs, which in the Windows
world is Visual Studio. VS has the added advantage that it's a free
download (in the form of VB or C# Express). Dyalog has demonstrated the
ability of their .Net interpreter to work in concert with VS, but hasn't
given much publicity to the actual techniques involved. The gist is that
you use the Visual Studio WYSIWYG forms designer to call APL callback
functions. I've successfully created simple applets using this approach,
but haven't subjected it to the rigors of a sophisticated GUI. Initially
there are sure to be limitations and awkward aspects to the marriage.
However, if these could be overcome then forms design skills learned in the
non-APL world would be interchangeable with those required in the APL world,
which to my mind at least would be a highly desirable situation.
3) Or both can be done. However I'm not sure how one can sensibly avoid
the 2nd approach since it requires so many fewer resources than the first.
-jim goff
| |
|
|
|
|
|