Re: [Lars Jensen] [Web-team] LyX win32 link dead
Back up again on the old site for a while... Ruurd "Ruurd Reitsma" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > My crappy dsl provider thinks it´s neccesary to disable my account while > moving the physical connection to a new location > > Will put up a new page elsewhere some time soon. > > Ruurd > "Lars Gullik Bjønnes" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > > What do do about it? > > Just remove the link or is there a better one? > > > > > > > > > -- -- > > > > > > > > > -- > > Lgb > > > > > >
Re: [patch] undo final
Andre Poenitz wrote: > > This is a slight rework of undo to use 'StableDocumentIterator' as a > base. > > Seems to work even within mathed, so this is already an improvemnt > over 1.3 where the cursor had to leave mathed on undo. > > Andre' Any chance of a 'diff -u' diff? -- Angus
[patch] undo final
This is a slight rework of undo to use 'StableDocumentIterator' as a base. Seems to work even within mathed, so this is already an improvemnt over 1.3 where the cursor had to leave mathed on undo. Andre' 1.diff.gz Description: application/gunzip
seeking maintainer/developer for Lyx/Mac
For the last two years I've enthusiastically taken on the port of LyX to MacOS X, including the Qt/X11 version and LyX/Mac, which uses the GPL Qt/Mac library to build a version of LyX for the native Mac Aqua graphics display. Jean-Marc Lasgouttes and the other members of the LyX developers team have created such splendidly portable code, and they are so helpful and knowledgeable that the ports were relatively easy. As a result, LyX/Mac-1.3.4 is a stable, highly functional, and very easy-to-install MacOS X application. I've very much enjoyed being part of the porting and packaging effort. But, I am now heavily engaged in a new book (#9) and have virtually no time available to me for further development or maintenance work on LyX/Mac. The new versions of LyX that are emerging from the development team need a new maintainer/developer for the MacOS X platform. A knowledge of LyX internals, C++, and MacOS X development is useful, but if I can learn-on-the-job, I suspect anyone with an interest can. The pay stinks, but you'll have the privilege of working with a remarkably bright and simpatico group of developers, the eternal gratitude of Mac users of LyX, and the pleasures of working with a terrific product. Write me offline or in one on one of these mailing lists for details of the status of LyX/Mac-1.4.0. Regards, and thanks to whoever is willing to become the new adoptive parent/guardian of this thriving baby. -- Ronald Florencewww.18james.com
Re: [patch] support jurabib
[EMAIL PROTECTED] (Juergen Spitzmueller) writes: | Perhaps we can help propagating jurabib a bit with our support. Then it might | well be that we can indeed ditch natbib some day. Ok, thanks. -- Lgb
Re: InsetExternal & InsetGraphics merged?
Angus Leeming wrote: > Georg Baum wrote: >> What is the difference? > > Using the latex compiler: > [e]ps images should not be converted. > all other image formats should be converted to eps. > > Using the pdflatex compiler: > pdf and png images should not be converted. > [e]ps images should be converted to pdf. > all other image formats should be converted to png. Thanks, I did not see this as "bitmap" <-> "vector" but "formats pdflatex can handle" <-> "formats latex can handle". > I don't see any difficulty in writing a VectorImage external template > to sit alongside the existing RasterImage template. Why not steal findTargetFormat() from insetgraphics and call it for the updateresult? Then you gain this advantage not only for a specific template, but for all templates. >> 4. The external inset does not use the fallback converter >> convertDefault.sh. This renders the bitmap external template >> unusable in default installations. > > Sure, because we removed all the interesting converters from > lib/configure. > > Anyway, I have a violent dislike for convertDefault.sh. Me neither (it was a reliable way to crash my machine before the asynchronous conversion was implemented), because convert uses approx. 10 times more memory than the netpbm tools. Nevertheless the default installation should provide converters ;-) >> 5. The filename is not exported correctly in some complicated cases, >> as Jean-Marc pointed out recently. > > Really? I don't recall seeing this post. Will your improved mangling > improve things? It was this one: http://www.mail-archive.com/[EMAIL PROTECTED]/msg67615.html It is working in the "not nice" case, but the latex export is wrong. This is independent from the mangling stuff, but I'll try to fix it when I touch this area. Georg
Re: InsetExternal & InsetGraphics merged?
Georg Baum wrote: >> 2. The Graphics inset exports bitmapped graphics and vector >> graphics differently, albeit in a hard-coded manner. It should be >> straight-forward to define different External templates for these >> so that they do the right thing when converted to postscript or pdf >> documents using either latex or pdflatex. However, it still needs >> to be done. > > What is the difference? Using the latex compiler: [e]ps images should not be converted. all other image formats should be converted to eps. Using the pdflatex compiler: pdf and png images should not be converted. [e]ps images should be converted to pdf. all other image formats should be converted to png. I don't see any difficulty in writing a VectorImage external template to sit alongside the existing RasterImage template. > 4. The external inset does not use the fallback converter > convertDefault.sh. This renders the bitmap external template > unusable in default installations. Sure, because we removed all the interesting converters from lib/configure. Anyway, I have a violent dislike for convertDefault.sh. > 5. The filename is not exported correctly in some complicated cases, > as Jean-Marc pointed out recently. Really? I don't recall seeing this post. Will your improved mangling improve things? > 6. Displaying the image is not on by default ;-) I like grey buttons myself ;-) -- Angus
Re: InsetExternal & InsetGraphics merged?
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> 5. The filename is not exported correctly in some complicated Georg> cases, as Jean-Marc pointed out recently. Note that this is the case for insetgraphics too, without my patch in bug 605. JMarc
Re: [patch] Fix bugs 605, 1231, and 1244
Georg Baum wrote: >> main.lyx >> #1_.._dir1_sub.lyx >> #2_.._dir2_sub.lyx > > Why the dots? Currently every mangled filename is an absolute one. > Is there a reason to change that? None. My bad. -- Angus
Re: InsetExternal & InsetGraphics merged?
Angus Leeming wrote: > The External inset can now do *almost* everything that the Graphics > inset does. Some functionality is missing still however: > 1. The Graphics inset has this SubFigure stuff. This shouldn't be a > part of the inset, so I haven't added it to the External inset. > Instead, we should move the functionality out of the Graphics inset > and into a new SubFigure inset, also as you describe. > 2. The Graphics inset exports bitmapped graphics and vector graphics > differently, albeit in a hard-coded manner. It should be > straight-forward to define different External templates for these so > that they do the right thing when converted to postscript or pdf > documents using either latex or pdflatex. However, it still needs to > be done. What is the difference? > 3. The Graphics inset can handle .ps.gz files. Some thought is needed > about how best this can be done by the External inset. 4. The external inset does not use the fallback converter convertDefault.sh. This renders the bitmap external template unusable in default installations. 5. The filename is not exported correctly in some complicated cases, as Jean-Marc pointed out recently. 6. Displaying the image is not on by default ;-) Georg
Re: [patch] support jurabib
Lars Gullik Bjønnes wrote: > I just think that we should actively > support as few bib packages as possible (preferrably only one). Depends on the aims of the packages, but in general: yes. > If > jurabib can do the same as natbib and more: Great. Let's use that and > ditch natbib. OTOH if natbib does all the same as jurabib does... why > support jurabib? Jurabib basically includes natbib's features (almost all, except the "force upper case" and "full author list" features we have in the citation dialog). It has lots of fundamental features for human scientists that natbib doesn't have (short title citation, ibidem, fullcite, footcite) and it is the only package that supports citation for legal texts. As I wrote in my first post of this thread, the problem is that jurabib needs the styles choice in the citation dialog, but that was bound to natbib, and jurabib is not compatible to natbib. So just including jurabib via preamble is not a solution (and vice versa). OTOH natbib is the older package and it is certainly more widespread. I think we have some layouts that require natbib (i.e. some latex classes require natbib). And then, natbib has a slightly different approach. The layout of the bibliography is hardcoded in the bst files in natbib, while it is configurable via options in jurabib. This has both its pros and cons. In jurabib, you can only choose between 4 bst files that are shipped with the package. All the rest has to be done by package options (it's a little bit like the KOMA classes; this is also the reason why jurabib needs very much memory and therefor need "bibtex 8 --huge" on windows). Natbib also has some shipped bst files, but if you want your own special layout, you usually build it with custom-bib (which was written by natbib's author). This is not (yet) possible with jurabib. An example: I needed a very special style for my thesis' bibliography: the only solution was to build my own bst style and hack its source. Jurabibs options just didn't provide what I required (though they provide a lot). AND natbib also works without bibtex (with the bibliography environment), I'm not sure jurabib does this too. Conclusio: while those packages are heading in the same direction, they have both their special areas where the other packages' limits are reached (since jurabib is very actively developped, it might completely superceed natbib eventually, but ATM this is not the case). I think we should provide this bit of selection to the users. Remember that citing is the most important feature for human scientists. You wouldn't take the argument "you can both write formulas with and without AMS, so let's decide", would you? Some users depend on jurabibs extra features, while others need natbib for their style files (personally, I toggle between those two packages for different documents). UI wise, I think both packages can easily exist in parallel, the only extra gui element is a radio button "use jurabib", the handling is exactly the same (you can also switch between those two packages any time). It also does not blow the code very much, because it basically uses the natbib framework. Perhaps we can help propagating jurabib a bit with our support. Then it might well be that we can indeed ditch natbib some day. Regards, Jürgen.
Re: [patch] Fix bugs 605, 1231, and 1244
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> I am going to implement this unless somebody has a better idea. Just one point: I think that using `#' in a file name that LaTeX may see is a bad idea (since it has special meaning)... JMarc
Re: [patch] Fix bugs 605, 1231, and 1244
Angus Leeming wrote: > However, we mangle the names because we want to provide the user with > something understandable. Your proposed solution retains our simple > mangling as the basic operation but makes it less understandable in > its attempt to make it robust. Why not just prepend the counter? I > think we get a robust solution and understandable names: > > main.lyx > #1_foo1_doc_sub.lyx > #2_foo1_fig_image.eps > #3_foo2_doc_sub.lyx > #4_foo2_fig_image.eps > > main.lyx > #1_.._dir1_sub.lyx > #2_.._dir2_sub.lyx Why the dots? Currently every mangled filename is an absolute one. Is there a reason to change that? > It also has the advantage that encoding this is trivial ;-) > > The only problem is that multiply-included files might be copies > several times. Solution: std::map. We would need this anyway, because the mangled filename is queried more than once for the same file. I am going to implement this unless somebody has a better idea. Georg
Re: [patch] quick hack
Alfredo Braunstein wrote:
> This is a quick-hacked inlined-in-open mode as Andre's proposal. Seems to
> work, but I didn't test it much.
>
> Comments?
It seems that no one really tried this.
Let me point out that it works well in the sense that it finds the way that
uses less space (label on the side or on top); but it may seem a bit
squizofrenic when typing an inset consisting of a line that is approx the
allowed width; depending on the rebreaking the label can jump up or down to
use the more compact layout. I don't know if this is a problem, but if it
is, I don't know very well how to solve it.
Comments still welcomed...
Alfredo
? insetcollapsable-save.C
? insettext-save.C
Index: insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.241
diff -u -p -u -r1.241 insetcollapsable.C
--- insetcollapsable.C 4 Mar 2004 07:38:11 - 1.241
+++ insetcollapsable.C 8 Mar 2004 10:16:06 -
@@ -41,7 +41,7 @@ using std::ostream;
InsetCollapsable::InsetCollapsable(BufferParams const & bp,
CollapseStatus status)
- : inset(bp), label("Label"), status_(status)
+ : inset(bp), label("Label"), status_(status), openinlined_(false)
{
inset.setOwner(this);
inset.setAutoBreakRows(true);
@@ -144,8 +144,16 @@ void InsetCollapsable::metrics(MetricsIn
if (status_ == Open) {
Dimension insetdim;
inset.metrics(mi, insetdim);
- dim.des += insetdim.height() + TEXT_TO_BOTTOM_OFFSET;
- dim.wid = max(dim.wid, insetdim.wid);
+ openinlined_ = (insetdim.wid + dim.wid <= mi.base.textwidth);
+ if (openinlined_) {
+dim.wid += insetdim.wid;
+dim.des = max(dim.des, insetdim.height());
+ } else {
+dim.des += insetdim.height()
+ + TEXT_TO_BOTTOM_OFFSET;
+dim.wid = max(dim.wid, insetdim.wid);
+ }
+
}
}
dim_ = dim;
@@ -177,7 +185,11 @@ void InsetCollapsable::draw(PainterInfo
if (status_ == Open) {
if (!owner())
x += scroll();
- inset.draw(pi, x, y - aa + dimc.height() + inset.ascent());
+
+ if (!openinlined_)
+inset.draw(pi, x, y - aa + dimc.height() + inset.ascent());
+ else
+inset.draw(pi, x + dimc.width(), y - aa + inset.ascent());
}
}
}
@@ -324,14 +336,14 @@ void InsetCollapsable::priv_dispatch(LCu
case LFUN_MOUSE_PRESS:
if (status_ == Inlined)
inset.dispatch(cur, cmd);
- else if (status_ == Open && cmd.y > button_dim.y2)
+ else if (status_ == Open && !hitButton(cmd))
inset.dispatch(cur, cmd);
break;
case LFUN_MOUSE_MOTION:
if (status_ == Inlined)
inset.dispatch(cur, cmd);
- else if (status_ == Open && cmd.y > button_dim.y2)
+ else if (status_ == Open && !hitButton(cmd))
inset.dispatch(cur, cmd);
break;
Index: insetcollapsable.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.h,v
retrieving revision 1.168
diff -u -p -u -r1.168 insetcollapsable.h
--- insetcollapsable.h 16 Feb 2004 11:58:47 - 1.168
+++ insetcollapsable.h 8 Mar 2004 10:16:06 -
@@ -160,6 +160,8 @@ protected:
private:
///
mutable CollapseStatus status_;
+ /// a substatus of the Open status, determined automatically in metrics
+ mutable bool openinlined_;
};
#endif
Re: InsetExternal & InsetGraphics merged?
Ling Li wrote: > Hi, > > I thought I had a new idea about subfigure (making a separate > subfigure inset so it can be applied to external materials). After > searching in the mail archive, I found this have already been > discussed, at least by Angus > (http://www.mail-archive.com/[EMAIL PROTECTED]/msg62163.html). > > So I took a look at the current CVS. It appears that "Insert > External Material" has disappeared, and "Insert Graphics" now > accepts file types like XFig files. So subfigure can be applied too. > Excellent! Not true I'm afraid. The External inset is to be found under Insert->File->External Material. Not sure why. The External inset can now do *almost* everything that the Graphics inset does. Some functionality is missing still however: 1. The Graphics inset has this SubFigure stuff. This shouldn't be a part of the inset, so I haven't added it to the External inset. Instead, we should move the functionality out of the Graphics inset and into a new SubFigure inset, also as you describe. 2. The Graphics inset exports bitmapped graphics and vector graphics differently, albeit in a hard-coded manner. It should be straight-forward to define different External templates for these so that they do the right thing when converted to postscript or pdf documents using either latex or pdflatex. However, it still needs to be done. 3. The Graphics inset can handle .ps.gz files. Some thought is needed about how best this can be done by the External inset. Once these three are implemented, then the Graphics inset can just die. > After playing the new InsetGraphics inset for a while, I comes to a > few questions: > > 1. How can I tell LyX to convert .fig files in the "1.3.x" way? That > is, generating .eps and .pstex_t files so that math equations in > .fig files is nicely displayed. You can't. That's what the External inset is for. > 2. Will inset subfigure be implemented? Having a subfigure inset > still has its own merits, even after the merge of InsetGraphics and > InsetExternal. For example, adding labels to subfigures might be > easier. (See my old thoughts below). The quickest way to add a missing feature is to provide a patch... > 3. Is it a better strategy to have both InsetExternal and the > improved InsetGraphics? InsetGraphics can still handle "easier" > external materials and InsetExternal is left for complicated ones, > such as .fig files containing math equations. Users can pick > whatever they need. I don't think so. The problems I describe are hardly insumountable. > === My old thoughts: subfigure as a separate inset/module? === > > I have an idea for subfigure. > > Currently when a figure (graphics) is inserted, we have an option to > make it a "subfigure" in the LyX:Graphics:Extra panel. If the option > is selected, subfigure package will be included and \includegraphics > will be wrapped by \subfigure. However, if the figure is included by > other means, such as XFig external files, subfigure option cannot be > applied (unless we use the evil red text). > > If we can make subfigure a standalone inset, the above situation is > easily solved. We first insert a subfigure inset, then insert the > XFig file inside it. > > We may also add a label feature to the subfigure inset (like that > for math equations). For now, when we want to add a label to a > subfigure, we have to 1. add it as raw latex code in subfigure's > caption; and 2. refer it via red text. This is inconvenient. I think that the whole world agrees with you here. -- Angus
Re: [patch] Fix bugs 605, 1231, and 1244
On Mon, 8 Mar 2004, Lars Gullik Bjønnes wrote: > Christian Ridderström <[EMAIL PROTECTED]> writes: > > | I've often had to look in the temporary directory > > Why? It's been a while since I used LyX for serious writing, I was thinking about the time when I wrote my thesis last spring. That was a big multi-part document, and I think that had something to do with the need for peeking in the temporary directory. At the time, there was also a bug in the "cache"-functionality, i.e. files that you changed weren't updated in the /tmp-directory, but that's fixed now IIRC. Other than that, I'm afraid I don't remember why I was fiddling with the files in the temporary directory :-( /Christian -- Christian Ridderström http://www.md.kth.se/~chr
