From: David Park on
The DocumentationTools palette does have a button on the top right to
activate scrolling if it is too long for the screen. (But I don't know if
this works because it is never too long for the screen on my PC.)


David Park
djmpark(a)comcast.net
http://home.comcast.net/~djmpark/


From: Hannes Kessler [mailto:HannesKessler(a)hushmail.com]

Hello Albert,

I tried to create some test documentation using the workbench but
failed to use the documentation tools palette when Mathematica was
called because some of its elements were hidden and I could not
increase the size of the palette window. In the workbench I had
problems using the help system as the font size is really tiny, but no
possibility to change it. I am afraid such elementary difficulties
will discourage newcomers like me to use the workbench.

Best regards,
Hannes

On 25 Feb., 07:54, Albert Retey <a...(a)gmx-topmail.de> wrote:
> Hi,
>
> > could you give some recommendations for a smooth transition to the
> > workbench for packages developed in a standard mathematica notebook
> > environment? Starting a completely new project in the workbench is
> > one thing, but at least as important is the question how to continue
> > to work on existing packages created previously by other means. Up to
> > now I wrote code in input cells of a mathematica notebook, added
> > explanations in text cells, marked the input cells with package code
> > as initialization cells to create the .m file automatically upon
> > saving the notebook. I never looked into the .m files themselves.
> > Should one / could one import the notebook (or the .m file) to a
> > workbench project, or copy it to a work space directory, or work
> > directly on the files in the user base directory, or what else ... ?
>
> all this is possible, there is an import wizard that will import
> notebooks and create package files from them but you can just as well
> copy the notebook files to the project directory of a new project and
> keep editing the notebook and create the package file automatically.
> This approach might need some more work to get the configuration right
> but you will need to learn only those features of the workbench that you
> want to use. I would recommend to create a dummy application project to
> see how the directory structure and configuration files need to be set
> up for the workbench utilities to work alright. You could also crate a
> new application project an then just replace the templates that are
> generated with your already existing files, if these meet the suggested
> conventions...
>
> If you are only writing pure mathematica package files, the added value
> of the workbench is IMHO limited, it really can help you to save a lot
> of work only if you either plan to provide documentation that you want
> to integrate into the Documentation Center or if you want to combine
> mathematica code with java, webMathematica and/or probably
> GridMathematica (which I have no experience with). It also is nice when
> you are using or plan to use additional tools like a version control
> system or a ticket/task repository which all can be integrated with
> appropriate eclipse plugins.
>
> Files will always be stored in the "workspace", a special directory that
> contains your project directories but the workbench takes care that
> $Path is set so that you can load the package you are developing. You
> can configure the workspace to be at any location you want to. The
> workbench has an application tool view which lets you export your
> application/package with a mouseclick to e.g. the user base directory so
> you can test it without the workbench environment.
>
> > Are there tutorials deeling with this problem?
>
> there is documentation for the workbench and it also deals with the
> import of existing projects. Some of the material is not really
> exhaustive though. If you consider to work with the workbench, I would
> recommend to also take a few hours to get familiar with eclipse.
>
> hth,
>
> albert




From: John Fultz on
Was the file still open in Mathematica? Mathematica can lock open files (so
they won't get changed by another program and leave things in an uncertain
state). It's entirely possible that Workbench wants a sole lock on files and
won't play nicely with a file that's locked by another app. Regardless of
whether that's the case or not, though, I wouldn't advise having the file open
in both Workbench and Mathematica simultaneously.

If that's not the issue, it's difficult for me to say. Workbench isn't my area,
and the package is a standard package in every regard (on top of being a simple,
plain text file). I'd suggest submitting it to tech support as a possible bug
in Workbench if you continue to have problems.

Sincerely,

John Fultz
jfultz(a)wolfram.com
User Interface Group
Wolfram Research, Inc.

On Thu, 25 Feb 2010 17:37:09 -0500 (EST), Hannes Kessler wrote:
> What you said works for saving a Mathematica notebook as a package
> under a different name and re-opening it in Mathematica. I'll probably
> look now more on .m files in Mathematica during package development
> and debugging. But when I re-opened the created .m file in the
> Workbench I got an error "Could not open the editor. An unexpected
> exception was thrown." followed by
>
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:
> 3880)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3473)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:
> 2405)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221)
> at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:
> 332)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:
> 493)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:
> 149)
> at
>=
org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication..
> java:
> 113)
> at
>=
org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:
> 194)
> at
>=
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(
> EclipseAppLauncher.java:
> 110)
> at
>=
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAp
> pLauncher.java:
> 79)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:
> 368)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:
> 179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>=
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39)
> at
>=
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp=
l
> .java:
> 25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
>
> I don't know what to do with it.
>
> Best regards,
> Hannes Kessler
>
>
> On 25 Feb., 07:53, John Fultz <jfu...(a)wolfram.com> wrote:
>> If take your notebook and you do...
>>
>> * File->Save As...
>> * Choose "Mathematica Package" under the file type
>> * Save as any .m file...but not using the same name as your .nb file
>> (because
>> your .nb file is already writing a companion package, and so will keep
>> destroying and recreating the like-named package every time you save
>> your
>> notebook).
>>
>> You'll now end up with a package file which has some interesting
>> properties.
>>
>> * If you open it in Mathematica, it looks much like a notebook, even
>> preserving
>> the cell structure and most of the properties of the notebook.
>>
>> * If you open it in Workbench (or any text editor), it will be
>> completely
>> readable, and all of that work you put into commenting your code in
>> Text cells
>> will *still* be there in clearly readable comments.
>>
>> * If you decide to make changes in Workbench (or any text editor), it
>> will be
>> pretty clear how to do so without destroying any structure that would
>> allow you
>> to reopen the package in the Mathematica front end and continue to see
>> the same
>> structure.
>>
>> When we designed the package editor in Mathematica (i.e., the mode
>> you're put in
>> when you open a .m file), one of the chief goals was to have it stream
>> out to a
>> file which is completely readable in any text editor, and which can be
>> co-developed using any combination of Mathematica, Workbench, and text
>> editor.
>> By following this procedure, you'll be making absolutely no irreversible
>> commitment to Workbench, and this will allow you to transition as
>> quickly or
>> slowly (or not at all) as you wish.
>>
>> Incidentally, something else which you might wish to know...Mathematica
>> has an
>> alternate evaluatable cell style known as "Code" (Alt+8 or Cmd+8).
>> Code is like
>> Input, but with the following differences...
>>
>> * Much less automatic formatting (e.g., auto-indent, auto-line-wrap)
>> * InitializationCell->True is set by default
>> * Differing background color so you can easily distinguish from Input
>> cells
>>
>> This can be a much easier and more visible way of tagging package code
>> than
>> using the Initialization Cell menu item, and it's the style which is
>> used by the
>> package editor for package code by default.
>>
>> Sincerely,
>>
>> John Fultz
>> jfu...(a)wolfram.com
>> User Interface Group
>> Wolfram Research, Inc.
>>
>> On Wed, 24 Feb 2010 06:18:42 -0500 (EST), Hannes Kessler wrote:
>>> Hello,
>>>
>>> could you give some recommendations for a smooth transition to the
>>> workbench for packages developed in a standard mathematica notebook
>>> environment? Starting a completely new project in the workbench is
>>> one thing, but at least as important is the question how to continue
>>> to work on existing packages created previously by other means. Up to
>>> now I wrote code in input cells of a mathematica notebook, added
>>> explanations in text cells, marked the input cells with package code
>>> as initialization cells to create the .m file automatically upon
>>> saving the notebook. I never looked into the .m files themselves.
>>> Should one / could one import the notebook (or the .m file) to a
>>> workbench project, or copy it to a work space directory, or work
>>> directly on the files in the user base directory, or what else ... ?
>>>
>>> Are there tutorials deeling with this problem?
>>>
>>> Best regards,
>>> Hannes Kessler



From: Albert Retey on
Hi,

> I tried to create some test documentation using the workbench but
> failed to use the documentation tools palette when Mathematica was
> called because some of its elements were hidden and I could not
> increase the size of the palette window. In the workbench I had
> problems using the help system as the font size is really tiny, but no
> possibility to change it.

it sounds like you are using either a non standard setup, since all
looks very reasonable on the systems I have been using. One thing you
can try is to configure the eclipse help system to use an external web
browser, you have then all the possibilities to change the appearance of
the help content within the web browser of your choice. As for the
documentation tools palette you could try to manipulate the
corresponding notebooks magnification to make everything fit within the
window with something like:

SetOptions[Notebooks[][[1]], Magnification -> 1]

where of course you would have to check at which position the
DocumentationTools-Palette appears in your case...

> I am afraid such elementary difficulties
> will discourage newcomers like me to use the workbench.

I am not trying to convince anyone to use the workbench, as I said, IMHO
it only adds value for certain special tasks and it needs some effort to
get used to it _and_ it might well have its deficiencies. Unfortunatly
at this time there isn't really an alternative to it when you want to
create documentation for the Documentation Center, although there are
some recipes about how you can create documentation for the
documentation center without using the workbench and wolframs
documentation tools. But these also have their deficiencies and also
need some effort to get decent results.

hth,

albert

From: Hannes Kessler on
Hi Albert,

I tried to change the help system to internet explorer (Window-
>Preferences->General->Webbrowser->Use external Web browsers->Internet
explorer) but nothing changed: All help pages still open in the
internal browser window with a tiny font. I am working under Windows
7.

Best regards,
Hannes Kessler

On 27 Feb., 09:15, Albert Retey <a...(a)gmx-topmail.de> wrote:
> Hi,
>
> > I tried to create some test documentation using the workbench but
> > failed to use the documentation tools palette when Mathematica was
> > called because some of its elements were hidden and I could not
> > increase the size of the palette window. In the workbench I had
> > problems using the help system as the font size is really tiny, but no
> > possibility to change it.
>
> it sounds like you are using either a non standard setup, since all
> looks very reasonable on the systems I have been using. One thing you
> can try is to configure the eclipse help system to use an external web
> browser, you have then all the possibilities to change the appearance of
> the help content within the web browser of your choice. As for the
> documentation tools palette you could try to manipulate the
> corresponding notebooks magnification to make everything fit within the
> window with something like:
>
> SetOptions[Notebooks[][[1]], Magnification -> 1]
>
> where of course you would have to check at which position the
> DocumentationTools-Palette appears in your case...
>
> > I am afraid such elementary difficulties
> > will discourage newcomers like me to use the workbench.
>
> I am not trying to convince anyone to use the workbench, as I said, IMHO
> it only adds value for certain special tasks and it needs some effort to
> get used to it _and_ it might well have its deficiencies. Unfortunatly
> at this time there isn't really an alternative to it when you want to
> create documentation for the Documentation Center, although there are
> some recipes about how you can create documentation for the
> documentation center without using the workbench and wolframs
> documentation tools. But these also have their deficiencies and also
> need some effort to get decent results.
>
> hth,
>
> albert


From: Albert Retey on
Hi,

> I tried to change the help system to internet explorer (Window-
>> Preferences->General->Webbrowser->Use external Web browsers->Internet
> explorer) but nothing changed: All help pages still open in the
> internal browser window with a tiny font. I am working under Windows
> 7.

Sorry, I have no experience with neither Windows 7 nor Internet
Explorer. On my Windows XP box when I choose "Use External Browser" and
then check "Default System Browser" the help will be opened with
Firefox, which is my "Default System Browser". There I can increase the
zoom factor with the usual menu entry or Ctrl-+. Have you tried to just
check the "Default System Browser" entry?

hth,

albert