Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
1997
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 1997

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: GUI for Mma

  • To: mathgroup at smc.vnet.net
  • Subject: [mg7165] Re: [mg7108] GUI for Mma
  • From: Mark Evans <evans at gte.net>
  • Date: Tue, 13 May 1997 01:58:04 -0400 (EDT)
  • Organization: None
  • Sender: owner-wri-mathgroup at wolfram.com

David,

Thank you for posting your remarks.  I am in agreement.

I think that the fundamental decision was made to turn all notebooks
into Mathematica expressions.  This decision fixed in place the nature
of the new user controls.  They had to be defined as expressions.  I
have mixed feelings about the notebook-as-expression concept, but I can
see a lot of good reasons for it, and I think it has been implemented
well.

Even under the present situation, I think WRI could at least give us
different types of controls such as list boxes, radio buttons,
checkboxes, and so on.  I have sent in suggestions for them to look at
LabVIEW as an example of such an environment.  Delphi and others have
similar capabilities.

You have to give the company credit for 3.0.  This version is an amazing
achievement, and includes technology that the world has not seen
before.  Relatively speaking, I think that it will be easier for
Mathematica to evolve in the directions you want than it was to climb
the hill of releasing 3.0.  For example, you now have a program that
evaluates integrals more accurately than some of the handbooks of
integrals.  That strikes me as a much harder problem to solve than
defining more user controls, and for a symbolics package, a more
important one.  The issues of typeset equations as kernel input are also
highly nontrivial, but these have been resolved.

Nonetheless, what you say is valid.  Another issue with Mathematica is
that one cannot develop code without the expectation of the end user
also owning a copy of this now $1300.00 program.  The workaround here is
an "application builder" that converts raw MMA code into some kind of
binary executable, probably by bundling it with a kernel that will only
respond to the bundled code.  Then you can distribute the binary result
freely and the end user will not need a copy of Mathematica.  This idea
is a good marketing tool for WRI as well, because this way more people
will see what MMA can do.

Maybe what WRI could do for now is give us a development tool for Visual
Basic, Visual C++, Delphi, or what have you, that can build the required
MathLink expressions to talk to the kernel.  Maybe what I am thinking of
here is a "front end builder".  Actually, Delphi or VB would build the
front end, but you could tell the tool what kinds of input/output are
expected for each "event" in your front end, and the tool would write
the MathLink code.  So maybe the term for this product should be "data
pipeline builder".  It would be similar in spirit to the mprep tool for
MathLink.  Just an idea.

The answer to your concept of a free-roaming cell might be similar to
the use of "frames" in Microsoft Word.  In this program, you normally
type line after line, much as you do in Mathematica.  Yet you can
instruct the program to deposit some objects anywhere on the page,
inside a frame, and they will stay there no matter what you type around
them.  Another approach might be an altogether different type of
notebook -- still an expression, but a non-standard notebook
expression.  I think we are close to this already with the palette
concept.  Such a notebook might accept input only from the defined
controls, and render output only in designated plot areas.

I have my own concerns about Mathematica that are totally unrelated to
all these interface issues.  Efficiency of execution is a major problem
in Mathematica when you are dealing with long arrays of data.  This
statement applies both to disk I/O, storage, and execution time.  I,
too, would like to see Mathematica become a general purpose programming
language, but I think that as an interpreted system, these efficiency
issues must be dealt with for WRI to achieve that goal.

I disagree with your comments about the Option Inspector.  For one
thing, you can select the scope you want with the list box at the top: 
global, notebook, cell, etc.  For another, I would rather have access to
everything and not always know what I'm looking at, than have access to
just those things that WRI decides I need to know about.  Their decision
will invariably conflict with mine, and with yours, and with the next
guy's.  I do wish that the help files would give a more unified
discussion of all the options.

I am a little concerned about all the hype that the world wide web has
been given.  I now have Visual C++ 5.0, and every time I try to access
my help file, the program wants to get on the web.  I don't want to get
on the web at the drop of a pin.

Mark Evans
evans at gte.net




  • Prev by Date: Re: graphics data in unevaluated cell
  • Next by Date: Re: Copy-protection
  • Previous by thread: Re: GUI for Mma
  • Next by thread: Re: Re: GUI for Mma