Re: Re: Getting a pure text widget?
- To: mathgroup at smc.vnet.net
- Subject: [mg61421] Re: [mg61384] Re: [mg61355] Getting a pure text widget?
- From: Chris Chiasson <chris.chiasson at gmail.com>
- Date: Tue, 18 Oct 2005 02:45:41 -0400 (EDT)
- References: <NDBBJGNHKLMPLILOIPPOAEIIELAA.firstname.lastname@example.org> <200510170629.CAA16332@smc.vnet.net>
- Sender: owner-wri-mathgroup at wolfram.com
I've used Mathematica 5 on Linux, it worked ok for me... Also,
Mathematica notebooks can be written and stored in a notebook markup
language (NotebookML - it's XML) instead of the standard .nb files.
About decoupling input and output: You can write Mathematica code such
that it will not output cells to the current notebook, but will
instead write to a different one that you specify. In this way, you
could separate input from output.
Personally, I want better output options for XHTML+MathML+SVG...
On 10/17/05, Steven T. Hatton <hattons at globalsymmetry.com> wrote:
> [I'm not sure what the fate of this mail will be. I just subscribed to the
> mailing list. I had been using the usenet interface exclusively.]
> On Sunday 16 October 2005 13:46, David Park wrote:
> > Steven,
> > I am going to take a different position on this. I think that Mathematica
> > has a perfectly good user interface, which is the Mathematica notebook.
> I suggest you read this through before commenting. There are two levels of
> ideas presented here. One has to do with how the Mathematica document
> concept could be improved. That is really secondary to my current objective.
> My current objective is to have a GUI that works. The current GUI
> distributed with Mathematica 5.2 for Linux is obsolete and broken.
> The Notebook itself is something of a nebulous concept. We have the document
> class called Mathematica Notebook which typically has a filename extension
> of .nb. We also have the runtime instance which is represented by an
> instance of the Mathematica FrontEnd window. The FrontEnd window could be
> considered as a superset of the actual runtime instantiation of a Mathematica
> Notebook. For purposes of this discussion I will try to distinguish between
> the textual entity stored persistently on a harddrive, the runtime
> representation of that entity, and the GUI used to control that runtime
> instance. I believe all three of these classes are flawed in their own way.
> Mathematica Notebooks are stored as monolithic entities with both program
> generated data and user produced source code intermingled. For example,
> graphics data is stored in the same file as user source code. There are
> significant disadvantages to that. It's more difficult to decouple input
> from output when transferring informmation. Sourcecode becomes vulnerable to
> corruption of output data, etc. The syntax in which the sourcecode is stored
> is very hard to read because of the nesting of quotation and other escape
> characters. Ideally content should be decoupled from presentation as much as
> possible. That is currently not how notebooks are structured.
> > The Mathematica notebook follows a tradition of technical publication that
> > goes back at least to Euclid. The interface is the blending together of
> > expository text, equations and diagrams. This is what one sees in
> > mathematical, scientific and technical journals today. It is what one sees
> > in textbooks. One might call it the classic text-equation-diagram
> > interface.
> I've stated in the past that the facility for typesetting mathematical
> notation, and also processing that notation is very impressive. That is one
> of the features I am eager to maintain in any UI I happen to create (though
> from the looks of things, I don't believe I can achieve my objectives with
> the tools available.)
> > But the Mathematica notebook is a revolutionary advance over the classic
> > interface. It is so new that only a few have absorbed its capabilities and
> > made effective use of them. With the Mathematica engine behind it, a
> > Mathematica notebook follows but becomes much more powerful than the
> > classic interface. A short notebook can generate calculations, graphics and
> > animation. A reader can modify any of these elements. A notebook can
> > include routines and tools that a reader can use to check or extend the
> > material in the notebook. A reader can add calculations and also add
> > comments and text. In other words a Mathematica notebook is an active
> > text-equation-diagram document.
> It would benefit greatly from a formal document definition facility, as well
> as document definitions based on that facility. The current stylesheets mix
> structure and presentation in ways that make it difficult to decouple. Also,
> the existing stylesheets are poorly documented. That is, unless there is
> documentation I am not aware of.
> > A Mathematica notebook, if handled properly, is already far superior to
> > classic techincal papers and instructional material.
> I do not believe Mathematic is the superlative mathematical editing tool.
> Support or XML DTDs, or other formal document definition formats would
> greatly improve its usability. A stylesheet definition along the lines of
> CSS would also be of value.
> > In my limited experience I have observed that most users do not bother to
> > learn how to use the notebook interface. They don't know how to use Text
> > cells, or enter mathematical expressions in the text cells. They don't know
> > how to use the Section/Subsection organization of a notebook. They often
> > opt for Manual Grouping, which practically destroys the notebook concept.
> > Manual Grouping destroys the reader's ability to easily add material to a
> > notebook and that's one of the revolutionary advantages! They put in a
> > rainbow of colors that has no meaning to the typical reader and that only
> > distracts from the presentation of the material. Instead of using Titles
> > and Subtitles at the top of the notebook they put them anywhere and
> > sometimes use them for comments! They don't know how to use graphics and
> > animation. They generally slight textual exposition, which is just as
> > important as the calculations.
> It may also be the case that the current implementation is unnecessarily
> difficult to work with. It doesn't help that the stylesheet implementation
> on Linux is simply broken, and does not function as documented, nor does it
> function in a coherent fashion. This has been broken for a long time.
> > I believe that we are still learning how to use the notebook style. Perhaps
> > the great Masterpieces of 'Classical Mathematica' have yet to be produced.
> > It's a metter of good material, good writing, good style and elegance.
> Mathematica does not have a monopoly on structured document formmat. I find
> XEmacs, PSGML, and the DocBook DTD to be superior to Mathematica for
> producing structured documents. The biggest limitation is the ability to
> fromat mathematical expressions as they are input.
> > As for widgets and palette interfaces - I'm generally opposed to them for
> > several reasons.
> > 1) It is extremely difficult to make an interface that is as versatile as
> > the text-equation-diagram interface. Non-notebook interfaces usually end up
> > being limited choice devices and are therefore quite restrictive.
> The current FrontEnd GUI on Linux doesn't even allow the user to paste a
> string into the search dialog when doing search and replace. The help
> browser truncates the display of long section titles, and offers no way to
> scroll the display, nor to change the size of the displayed window. The file
> access widget is extremely painful to use. The property browser is
> non-functional 50% of the time. For some reason it rebuilds the display
> while the user is making modifications. The users modifications are
> therefore reset to the values they had when the dialog was opened. The
> commands described in the Mathematica book for opening and otherwise
> controlling notebooks do not behave as documented. Not even the scrollwheel
> for the mouse works. And imwheel is not an option.
> My current objective is simply to create a GUI that works correctly. The one
> provided for Linux is broken.
> > 2) People already understand the text-equation-diagram interface. (Actually
> > many don't but they are in a preliterate state.) Each new pallete or widget
> > interface presents a new learning challenge. It's true that the
> > introduction of Windows type GUI computer interface from PARC was a vast
> > improvement on the old command line computer interface. But it only brought
> > us back to the possibility of an active text-equation-diagram interface.
> Pallets are useful in presenting the user with a range of options which would
> be difficult to present using only the document interface. The most valuable
> pallets tend to be the ones which show the alternative methods of inputing
> the same information. Pallets are, for the most part, pedagogical devices.
> I don't use them very often. Nonetheless, I just looked at the available
> pallets and discovered new features of Mathematica's diffeq support.
> > The Mathematica notebook already incorporates this. It may be possible to
> > come up with something different and better - but it's going to be very
> > difficult.
> > 3) Is the widget going to completely replace notebooks or is it going to be
> > some kind of extra palette tool? Competition to get your widget on the
> > desktop is fierce. Desktop space is precious. One will have to come up with
> > something really good to get one's widget on very many people's desktops.
> How 'bout a Mathematica Notebook interface that works as documented? The
> widget I want is almost identical to the one you get when you type in
> `mathematica' in a xterm. The only difference between that and what I want
> is the one I want will not have any Motif functionality. I will provide my
> own file browser, etc.
Prev by Date:
Re: Language vs. Library why it matters / Turing
Next by Date:
Re: Getting a pure text widget?
Previous by thread:
Re: Getting a pure text widget?
Next by thread:
Re: Getting a pure text widget?