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. > > -- > Regards, > Steven > > -- Chris Chiasson http://chrischiasson.com/contact/chris_chiasson
- Re: Getting a pure text widget?
- From: "Steven T. Hatton" <email@example.com>
- Re: Getting a pure text widget?