Re: Tooltips.

2002-05-12 Thread Herbert Voss

Joao Luis Meloni Assirati wrote:

> 
> lyx-devel/src/frontends/xforms/ChangeLog said:
> 
> 
>>2002-05-09  Angus Leeming  <[EMAIL PROTECTED]>
>>* Tooltips.C: enable tooltips by default.
>>
> 
> I'm using the latest cvs version with xforms-0., and although my lyx
> comes up with the help->Tooltips button checked, tooltips don't show. In
> order to enable tooltips, I have to uncheck, then recheck the tooltips
> button.


at this time the tooltips are only available for some

gui's: Bibtex, Citation, Sendto and Texinfo

And for this it works like expected for me

Herbert


-- 
http://www.lyx.org/help/




preview-LyX ?

2002-05-12 Thread David Kastrup


Sorry for barging in on this list like that, but I would like to
share a few thoughts I had recently.  Please stay on for a few
paragraphs before blowing your top, I hope the relevance of this will
then be clear.

Several of you probably are already aware of the preview-latex project
where I am head developer.  I delivered a talk about it at the recent
EuroBachoTeX conference in Poland and witnessed an impressive amount
of interest as compared to other Emacs-based tools for editing.  I
also had received several reports about vi users switching to Emacs
because of it, and on the conference people asked me whether there
would be any chance of seeing this in vi or its clones.  The answer
to that was no, simply because it is not conceivable that vi
development will want to cater for an extension mechanism like that,
or for graphical elements in buffers.

In contrast, I believe LyX to have the necessary infrastructure for
that kind of functionality.

Instead of people abandoning their favorite editor because of some
particular "killer feature", it would make more sense if their editor
gained that functionality.

preview-latex is little more than a bunch of streamlined glue
interconnecting existing pieces of software (LaTeX, DviPS,
GhostScript) and tying them with a convenient interface into an
existing editing environment (Emacs/AUC TeX).  Emacs has offered
itself because it has the necessary power, because I know it well,
because it provides a conveniently interactive test bed for
applications like that.  This does not mean that this approach would
be infeasible for other editors.

In fact, integrating this approach into LyX (which is a lot more
aware of the underlying LaTeX structures) would seem to make a lot of
sense.  One of the current qualms of LyX developers is "ERT" (evil
red text), LaTeX for which Lyx does not (yet) provide a graphical
representation.  If LyX offered the option to let LaTeX itself try to
come up with a good rendition, this could make LyX buffers a lot more
readable.  While the amount of ground that LyX developers have already
covered, is certainly impressive, things like PStricks graphics or
MusiXTeX codes, or chess diagrams or similar don't seem to warrant
the kind of work that would be necessary to make them natively known
to LyX.  Providing an option for having a graphical rendition for
them in the source buffers might extend LyX' potential user base
quite a bit.  Even in those areas where LyX _does_ know its things
(like in math formulas), some people might not be adverse to having
an option to let LyX replace its own rendition of them by a true
LaTeX one as long as one is not actively editing the formula.

preview-latex uses LaTeX for determining and extracting the pieces of
interest for previewing.  This is done with the help of the
preview.sty package that is part of preview-latex, but also
separately available on CTAN.  While most of the _determination_ of
the previewable parts would probably already be done by LyX itself,
the actual extraction (with the help of the preview environment
provided by the style) could still be accomplished using that
package.

I would be glad to be of assistance if particular options or general
advice would be necessary in order to generate a version suitable for
working with LyX.  The preview style already provides all of the
necessary ingredients in order to turn out a single DVI file which,
when processed by GhostScript, produces a set of graphic files with
tight TeX bounding boxes (which has turned out to be one of the more
challenging little details taking up quite more time than anticipated,
since both vertical and horizontal material needs to be catered for,
and any surrounding spacing should be removed).  That alone will
already provide a good and reasonably efficient path for an efficient
_initial_ rendition of the previews for an entire document.  But
already there it would prove beneficial to incorporate a few of the
details that have emerged desirable in the course of preview-latex
development: parsing the PostScript file for its DSC comments, and
using that information for generating those previews first that are
currently displayed makes up for a lot of preview-latex's interactive
response: the GhostScript pass is actually the slowest component of
its operation, but the one which has about the least impact on
interactive work since it first does the visible portions of its work.

Of course, since preview-latex is GPLed software, you would be free to
incorporate and read all of it that you want into LyX, anyhow.  But
also, of course, the source code sometimes is the result of some
lessons learned, and the lessons itself are no longer visible.  And
also the set of those both willing to dig through bunches of Emacs
Lisp, yet preferring to work on LyX rather than with Emacs, could
probably be small.

Implementing a way of making it easy for LyX users to let LaTeX itself
cater for source buffer renditions of more obscure constructs woul

Patch: fix bug #394

2002-05-12 Thread Dekel Tsur

The first patch does not change the float dialog, so in order to get
a default placement, the user has to deselect all buttons.
The second patch adds a "default placement" button to the dialog.



patch.gz
Description: GNU Zip compressed data


patch2.gz
Description: GNU Zip compressed data