This section is inspired by part of Dyalog's 2014 conference and initially
targeted at discussions of the 24 October 2014 BAA. Topics and
discussions are on the Dyalog User Forum.
A Day At The Beach...
If WPF's so wonderful, why isn't everybody using it?
The aim of the discussion and online preamble is to find out whether these
are true statements.
If WPF/APL is wonderful and everyone's using it, then do we want to see
examples of successful use documented?
If WPF/APL isn't wonderful, or everyone isn't using it, should we try to
change things - if so, what needs to change and how do we (the worldwide
population of APL users) change it.
Wednesday 24 September:
John Daintree presents Data Binding, which looks wonderful but is
syntactically alien to APLers.
Morten Kromberg tells us about using WPF and the extras bundled into Dyalog
14 which let us make richer/flasher GUIs (apparently there is a lunatic
writing pages of examples that show how some things are done in APL)
Mike Hughes presents a WPF-based successor to the traditional APL/W Grid
Claus Madsen shows us an application built with the goodies bundled into
Dyalog 14 and hints at an approach which simplifies use of WPF
Stephan Possberg reminds us that all our old enemies are still sniping away
I've been using WPF to build user interfaces for APL applications for a
couple of years - I'm not alone, and others have certainly done more.
But - at least two very established APL programmers have said things like
"why bother?" and "it all looks too complicated".
Things that people can try out and ten minutes later say "I can build
application GUIs using WPF, quicker/better than with APL/W Native, and it's
worth taking time to find out more".
Topic B - Do We Need XAML?
On the one hand XAML as a way of defining window layout and content has a
lot going for it - there are visual design tools that make XAML, lots of
examples to copy/paste when we're too preoccupied to think and we might even
be able to hire people to do make XAML for us.
But on the other hand, it's - to my mind - a nasty syntax, complex windows
seem to require massive monolithic definitions and it's one more thing to
learn and/or go wrong.
We can indeed do quite a lot with .New and .NET/WPF controls. What I'm
not quite clear about is whether/how we can do Binding (another topic)
outside of XAML. But committing to a XAML-free existence might be
cutting us off from a lot of non-APL resource.
Topic C - Do We Need A Visual Design Tool?
Prototyping a look-and-feel with VS EXpress is very handy, and it's not too
much effort to either use the XAML files directly or to copy/paste into APL
code. But there's a problem...
As I understand it (and experimentally confirmed), the licensing agreement
between Dyalog and Syncfusion doesn't let us add the Syncfusion controls to
our VSE projects. And Syncfusion is letting us add a lot of eye-candy
(at least) to applications.
How much do we care about this? Do we want to make our own visual
design tool? If we do, where's the labour going to come from?
From personal experience, I never felt it was an issue with APL/W Native -
there was WSDESIGN, but I only ever tried it in jest (jest did, and
remembered my frustrations). So we might make something people don't
like and won't use.
Building up XAML with XML Notepad 2007 remains my method of preference - it
offers a tree-like model of what you're making which seems a reasonable
half-way between full visuals and text-only XAML.
Better tools out there? I like "free" as in bus-passes.
Four types of resource in mind here...
a) Scripts/namespaces/etc. that "we" write and are happy to share, even
working in the open-source spirit
b) Books/pages written by the rest of the computing world that give useable
(concise) recipes we can follow. Two bad things in this category -
forum wranglings where people argue with each other and never get to the
point, and over-elaborate examples where fluff hides the essentials
c) Books/pages written by "us", showing code exclusively in APL terms
d) People willing to share their knowledge/experience (not sure about this
one because it feels a bit one-to-one and doesn't have that
do-once-use-many-times thing going for it). Maybe this includes
Topic E - Is APL "different"?
Looking at applications and development environments we might conclude that
there are some aspects where APL is distanced from the IT norm, including...
Applications which are nimble in the sense that requirements change quickly
and the code must follow.
Development groups which are smaller, with less specialisation within the
Developers more oriented toward the application world than the computing
Less "distance" between developers and users.
The question of Topic E is whether these (and others?) are significant and
suggest that the tools of the mainstream are not necessarily
directly/productively useable in APL development.
Topic F - Binding, is it Compulsory?
The good thing about Binding (some might say "a" good thing) is that it
makes magical things happen - that we can achieve data changes without
executing a single line of APL code.
The bad thing - to my simple mind - is that Binding takes away that explicit
cause-effect relationship intrinsic to APL and which is so essential when
chasing down errors.
The other bad thing is that - especially on the XAML side - the syntax to
achieve binding might most kindly be described as rococo-gothic.
The ugly thing about Binding - especially if we want to use Syncfusion's
controls is that there's no consistency; some controls work without Binding,
others make it compulsory.
So - seeking the simple life, my sense is that we need to use Binding but
we're going to have to do something about syntax and terminology. I'm
thinking along the lines of hiding it under something (yet to be invented)
called "association" (or something like that).
Topic G - EzWPF
Which I think is something Claus Madsen has already achieved.
Taking the "80% of the gains for 20% of the price" line (although this might
understate) the question is whether we can make some tools to hide away a
lot of WPF (and .NET) complexity and offer simple ways to build GUI
interface/interaction. In some ways this echoes what Dyalog themselves
did years ago when the built the APL/W GUI on top of whatever it was on top
of. It also has echoes of tools I built myself on top of APL/W Native
(mumbled about this at Dyalog 2008).
A few suggestions/outlines/proposals...
- No XAML - at least not visible to the "normal" programmer/user.
- Hide ⎕USING.
- A tree view of the GUI (as shown by XML Notepad 2007) could obviate
the need for a visual designer.
- Hide the technicalities of Binding, saying nothing more than "this
data belongs to this data" and vice-versa.
- Probably ought to be a set of Dyalog Class scripts/definitions.
- Need to be extensible, so that the base Classes can be adapted for
more complex requirements (failing that - a smooth transition to
full-fat WPF controls)
- Define a starter set of essential controls.
- Open source (in APL) so that people can extend without penalty
Pierre Gilbert's thoughts
Mike Hughes' thoughts
Page updated 20 October 2014
Copyright © Dick Bowman,
2006-2014. Material from these pages may be freely redistributed, but
copyright is retained and attribution to Dick Bowman is required.