Re: [Patch] CT related fixes (Re: [Patch] allow delete para break after insert in CT)
On Wed, 2006-03-15 at 23:16 +0200, Martin Vermeer wrote: ... > OK, here is a patch fixing several small interrelated CT issues (one an > assert, i.e., not so small) and documentation improvements. This goes in > soon unless someone spots a problem. Committed to trunk. - Martin signature.asc Description: This is a digitally signed message part
Re: isTrueTextInset issue
On Thu, 2006-03-16 at 01:04 +0200, Martin Vermeer wrote: > On Thu, Mar 16, 2006 at 12:51:43AM +0200, Martin Vermeer wrote: > > ... > > > The reason for this is, that paragraph_pimpl.C expects something > > different from isTextInset than rowpainter.C. It expects to find out if > > the inset _actually contains_ a lyxtext with paragraphs. > > More precisely: it expects to find out if the inset contains "stuff" > that can be change track marked in LaTeX. Perhaps we should choose a > name that reflects this. Even more precisely: the idea is, that if you have an inset that can contain internal text that can _itself_ be change-track marked in LaTeX/DVI, then in the text surrounding it, the change track markings have to end before it. So on the outside, the inset meta-character is handled as being of type Change::UNCHANGED. After the inset, external change track marking can then resume. This avoids the ugly (illegal?) situation that a character within a textinset would, for the purpose of LaTeX/DVI output, have two change tracking statuses: an external one for the whole inset, and an internal one for the character itself. Things like quote insets etc. which do not contain inner text, have isTextInset == false and will be change marked just like ordinary characters. I propose to change the name to containsInnerText() and the one to replace isTrueTextInset() could then be named isTextInsetBased() Does that sound like a plan? - Martin signature.asc Description: This is a digitally signed message part
Re: isTrueTextInset issue
On Thu, Mar 16, 2006 at 01:04:05AM +0200, Martin Vermeer wrote: > On Thu, Mar 16, 2006 at 12:51:43AM +0200, Martin Vermeer wrote: > > ... > > > The reason for this is, that paragraph_pimpl.C expects something > > different from isTextInset than rowpainter.C. It expects to find out if > > the inset _actually contains_ a lyxtext with paragraphs. > > More precisely: it expects to find out if the inset contains "stuff" > that can be change track marked in LaTeX. Perhaps we should choose a > name that reflects this. The use of isTextInset in paragraph_pimpl is part of John Levon's change tracking patch (revision 6074). The method itself is much older; I haven't been able to find out who introduced it and for what reason. - Martin pgpBwMNDgSSXA.pgp Description: PGP signature
Re: Please! publish the .spec files!
On Wed, 15 Mar 2006, Andre Poenitz wrote: On Mon, Mar 13, 2006 at 10:33:28AM -0600, Rex Dieter wrote: Georg Baum wrote: Rex Dieter wrote: Georg Baum wrote: The latter is not possible, because x64 requires --with-qt-includes=/usr/lib64/qt3/include --with-qt-libraries=/usr/lib64/qt3/lib64. These shouldn't be necessary, provided that your linux/os vendor/distro properly defines QTDIR, QTLIB, QTINC env vars. It is necessary on SuSE 10. Then tell SuSE to fix their qt packaging... so no end-user hacks are required to make x86_64 builds "just work". Adding vast amounts of environment variables would be even worse. I humbly disagree, but that's not my problem (it's SuSE's). -- Rex
Re: [patch] fix bug 2361
On Tue, Mar 14, 2006 at 02:38:42PM +0100, Georg Baum wrote: > Jean-Marc Lasgouttes wrote: > > > I am a bit nervous about removing things like \begin, \left or > > \protect. Can you tell what having these break? > > Nothing, but they are not used either. At least \protect will be used as soon such a formula is read in. As Ly writes out \protect in some cases this makes sure that save/load cycles do not create sequences of \protect. > Lets go through the list (reordered to group similar cases): > > #name inset flags > > begin begin none > right right none > protect protect none > newcommandnewcommand none > left leftnone > end end none > > We don't have these as insets, so these get parsed as a MathSymbolInset > (with name 'begin' etc.) in createMathInset(). This does not make sense > IMO. Oh. Swallowing things can make sense. > Apart from that, all these cases are handled explicitly in the math parser. > Therefore these entries in lib/symbols have no effect, because everything > goes through the math parser (including text->math conversion and > math-insert \bla\blub via the minibuffer) That might be a different (and possibly valid reason). Andre'
Re: [patch] bug 1999: Wrong default label in figure captions
On Mon, Mar 13, 2006 at 06:32:52PM +0100, Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
> > This does not work for example when the caption is inside a minipage
> > inside the float (people do that!).
>
> Of course. I forgot that.
>
> > You should look at this code snippet from setCounter (buffer_funcs.C):
>
> Thanks. Updated patch attached.
Index: src/text.C
===
--- src/text.C (Revision 13338)
+++ src/text.C (Arbeitskopie)
@@ -2264,8 +2264,25 @@ string LyXText::getPossibleLabel(LCursor
}
}
- string text = layout->latexname().substr(0, 3);
- if (layout->latexname() == "theorem")
+ string name = layout->latexname();
+
+ // for captions, we want the abbreviation of the float type
+ if (layout->labeltype == LABEL_SENSITIVE) {
+ // Search for the first float or wrap inset in the iterator
+ size_t i = cur.depth();
+ while (i > 0) {
+ --i;
I'd prefer something like
for (size_t i = cur.depth(); i--; )
Andre'
Re: [patch] fix lib/configure.py
On Mon, Mar 13, 2006 at 02:54:13PM +0100, Abdelrazak Younes wrote: > Coming back to QProcess, I am sure we could use that in a clean manner > by using a virtual base class that would be inherited by a new > ForkedCall that would encapsulate QProcess. If rtti is enabled, the Lyx > kernel could choose at runtime which ForkedCall class to use depending > on the frontend. What do you think? I'd even go as far as building a Qt based helper lib wrapping QProcess, QSettings and thte XML parsing stuff to prevent us from re-inventing the wheel again. But I doubt we'd get consensus on that. Andre'
Re: Please! publish the .spec files!
On Mon, Mar 13, 2006 at 10:33:28AM -0600, Rex Dieter wrote: > Georg Baum wrote: > >Rex Dieter wrote: > > > > > >>Georg Baum wrote: > >> > >>>The latter is not possible, because x64 requires > >>>--with-qt-includes=/usr/lib64/qt3/include > >>>--with-qt-libraries=/usr/lib64/qt3/lib64. > >> > >>These shouldn't be necessary, provided that your linux/os vendor/distro > >>properly defines QTDIR, QTLIB, QTINC env vars. > > > > > >It is necessary on SuSE 10. > > Then tell SuSE to fix their qt packaging... so no end-user hacks are > required to make x86_64 builds "just work". Adding vast amounts of environment variables would be even worse. Andre'
Re: Qt4 frontend
On Mon, Mar 13, 2006 at 12:20:28PM +0100, Abdelrazak Younes wrote: > Juergen Spitzmueller a écrit : > >Abdelrazak Younes wrote: > >>>The problems seems to be that we try to initialize the QPainter object > >>>multiple times (at least in QLPainter). This is not allowed: > >>>http://doc.trolltech.com/4.1/qpainter.html#QPainter-2 > >>Yep and that's why I erased all use of qp_ private member in > >>"QLPainter.C" (start() and end() do nothing). > > > >Hmm, I would have suspected that exactly this change is what causes the > >error. > > I am not sure because QLPainter is only painting onto a pixmap. The only > painting onto an X11 device is in QWorkArea::paintEvent. I thought even painting into a pixmap should only be done in a paintEvent(). The pixmap is located on the server side after all... > >Did you encounter some problems with the use of qp_? > > Yes, I had big troubles making it works. I managed to get it working but > at the end, I just noticed that using a QPainter for each operation was > not that complicated and actually resulted in less code (please compare > it with qt2 version). Plus it's the recommended way to use QPainter in > Qt4 documentation because of that very problem. Indeed. QPainters should not be cached unnecessarily. Andre'
Re: isTrueTextInset issue
On Thu, Mar 16, 2006 at 12:51:43AM +0200, Martin Vermeer wrote: ... > The reason for this is, that paragraph_pimpl.C expects something > different from isTextInset than rowpainter.C. It expects to find out if > the inset _actually contains_ a lyxtext with paragraphs. More precisely: it expects to find out if the inset contains "stuff" that can be change track marked in LaTeX. Perhaps we should choose a name that reflects this. - Martin pgpbvjx1r5Rwp.pgp Description: PGP signature
Re: isTrueTextInset issue
On Wed, Mar 15, 2006 at 10:27:04PM +0100, Georg Baum wrote:
> Am Mittwoch, 15. März 2006 21:34 schrieb Martin Vermeer:
> > On Fri, Mar 10, 2006 at 04:13:47PM +0100, Georg Baum wrote:
...
> > > >> Isn't there another way?
> > > >
> > > > A method in the inset (base inset) itself?
> > >
> > > Please not if possible. Do you know why math insets return
> isTextInset() ==
> > > true? Maybe this can be changed?
> >
> > Actually I would like to bring up this alternative once again. A method
> > (derivesFromTextInset?) implemented in insetbase.h returning false, and
> > re-implemented in insettext returning true.
>
> But this is exactly what isTextInset is supposed to tell! I had a look,
> and it is not used much. The attached patch (ignoring your
> isTrueTextInset changes) should restore the true meaning of isTextInset,
> but change no functionality. I think that you should build on this. I am
> not sure about the tabular inset, we probably need to treat it separately
> sometimes, because it
> a) is a text inset (it contains text)
> b) is no text inset (it does not have a amin LyXText)
With all due respect, I think you miss the point. What the
isTrueTextInset method tries to establish, is whether a certain type of
inset (math; collapsable; tabular) is _derived_ from textinset, by
inheritance. The reason this is necessary is, that only then will it
have the data member wide_inset_, and is it safe to assign a value to
it, to a memory location that the inset actually owns.
(It would be possible to put wide_inset_ in insetbase; bad idea because
of memory allocation. Lots of little insets in math.)
Yes, we could adapt isTextInset() to provide this info, as you propose
for math. The price you pay is the extra testing condition in
paragraph_pimpl.C. You _shift_ the problem, but don't _solve_ it.
You could do the same with tabular: make its isTextInset return false.
Then you could add a third condition for tabular to paragraph_pimpl.C
too ;-/ (There's a Danish saying: nissen flytter med. Hard to translate.)
The reason for this is, that paragraph_pimpl.C expects something
different from isTextInset than rowpainter.C. It expects to find out if
the inset _actually contains_ a lyxtext with paragraphs. One method
cannot serve these two masters.
BTW checking insets/ I see the following:
grep isTextInset *.h
insetbase.h:virtual bool isTextInset() const { return false; }
insetcollapsable.h: bool isTextInset() const { return true; }
insetenv.h: bool isTextInset() const { return true; }
insettabular.h: bool isTextInset() const { return true; }
insettext.h:bool isTextInset() const { return true; }
Of these, I think insetenv.h and insetcollapsable.h are simply
unnecessary as they derive from insettext.h which already returns true.
Agreed? Should we remove them?
- Martin
pgpO7HB0IK9lD.pgp
Description: PGP signature
Re: LyX 1.4.0 and DocBook SGML
> Am Mittwoch, 15. März 2006 22:01 schrieb Chris Karakas: > > > Whatever I had written in pure SGML is now exported as if it were normal > text, with "" becoming "", for example. > > Do you mean that in 1.2 you can write in normal text and that it > will be output as ? If yes, then the lyx2lyx conversion is > incomplete, but I don't know if that can be changed easily. > No. I mean in LyX 1.2 I can choose the SGML environment, then write "" and it will be exported to SGML as "", i.e. unchanged. Now, with LyX 1.4, all SGML environments have become "Standard" environments - this breaks whole parts of the document, like smilies, author info, callouts, admonitions etc., as they are all written in an SGML environment. > > How am I supposed to do SGML processing in LyX 1.4? Any pointers, tips, > docs? > > You should type pure SGML in a ERT box. > Why isn't this done automatically for existing "SGML environments"? I will certainly NOT spend a week to convert all my 300 or so SGML snippets to ERT (whatever ERT is...to me it's the state television channel in Greece :)). > > I am the author of the 230 page document "Document processing with LyX > and SGML" (http://www.karakas-online.de/mySGML/), which was written LyX > 1.2, so I have an interest in extending my procedures to support LyX 1.4 > (currently it seems that only LyX 1.2 will work with them). > > I am sure that it is possible. > Well, for the moment I am stuck. Have you tried to import this: http://www.karakas-online.de/mySGML/mySGML.lyx to see what I mean? Chris -- Regards Chris Karakas http://www.karakas-online.de
qt4 frontend
Title: qt4 frontend
hi guys,
just compiled the qt4 frontend and am surprised how well it works. great work abdul!
i made some little changes over here for the followings things:
- entries in the combobox in the toolbar are not legible
- same for entries in the listview in the preferences dialog
- the color is not updated after changing it (i always change the murky pink color of lyx's background to white)
don't know whether these are the correct changes (it seems that the sizehint is a bit to generous for the items in the preferences dialog) but little patch attached in case...
good night, edwin
Index: QLToolbar.C
===
--- QLToolbar.C (revision 13383)
+++ QLToolbar.C (working copy)
@@ -80,9 +80,9 @@
QLayoutBox::QLayoutBox(QToolBar * toolbar, QtView & owner)
: owner_(owner)
{
- QSizePolicy p(QSizePolicy::Minimum, QSizePolicy::Fixed);
+// QSizePolicy p(QSizePolicy::Minimum, QSizePolicy::Fixed);
combo_ = new QComboBox;
- combo_->setSizePolicy(p);
+ combo_->setSizeAdjustPolicy(QComboBox::AdjustToContents);
combo_->setFocusPolicy(Qt::ClickFocus);
combo_->setMinimumWidth(combo_->sizeHint().width());
Index: QPrefsDialog.C
===
--- QPrefsDialog.C (revision 13383)
+++ QPrefsDialog.C (working copy)
@@ -895,7 +895,7 @@
QColor c(QColorDialog::getColor(ci->color(), qApp->focusWidget() ? qApp->focusWidget() : qApp->mainWidget()));
if (c.isValid()) {
ci->color(c);
- lb->update();
+ lb->triggerUpdate(false);
change_adaptor();
}
}
Index: panelstack.C
===
--- panelstack.C (revision 13383)
+++ panelstack.C (working copy)
@@ -81,6 +81,8 @@
}
panel_map_[n] = item;
+
+ list_->setFixedWidth(list_->sizeHint().width());
/*
item->setFlags(false);
item->setOpen(true);
Re: [Patch] CT related fixes (Re: [Patch] allow delete para break after insert in CT)
Martin Vermeer <[EMAIL PROTECTED]> writes: | (BTW tip: alias svndiff='svn diff --diff-cmd /usr/bin/diff -x -up' | in .bashrc) Or set it in .subversion/config -- Lgb
Re: [Patch] Qt4 wheel mouse + Q_WS_* macro
On Mar 15, 2006, at 12:31 PM, Abdelrazak Younes wrote: Bennett Helm a écrit : On Mar 15, 2006, at 5:22 AM, Abdelrazak Younes wrote: Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Hum, I don't know, did someone tested your changes on Abdelrazak> qt2/X11/Mac? I would tend to think that the X11 clipboard Abdelrazak> wouldn't need this change but I don't know really. I would assume that the X11 clipboard always uses LF, but I have no way to check. I guess our only hope is Bennett... How you guys did managed to complete the MAC port without any developer on board? So what am I, chopped liver? ... Sorry Bennet, I didn't meant to hurt you, I meant "C++ developer". I got the (maybe wrong) impression that you were not. No offense taken (and no apology necessary): as you correctly surmised, I'm not a developer -- just able (and willing) to test ... and kibitz. (Though I did manage to write a GUI installer for Mac: that ought to count for something!) I suppose, since it's not Friday, I should have included a smiley. In any case, I'm impressed by and appreciative of the efforts you real developers have made, in spite of my bumbling, to get things to work on Mac. I just hope I'm not your only hope! :P Bennett
Re: [Patch] allow delete para break after insert in CT
Am Mittwoch, 15. März 2006 22:18 schrieb Martin Vermeer: > Looking forward to your experiences playing with this code ;-) I prefer to do only the easy changes myself and otherwise do armchair criticism ;-) Georg
Re: LyX 1.4.0 and DocBook SGML
Am Mittwoch, 15. März 2006 22:01 schrieb Chris Karakas: > Whatever I had written in pure SGML is now exported as if it were normal text, with "" becoming "", for example. Do you mean that in 1.2 you can write in normal text and that it will be output as ? If yes, then the lyx2lyx conversion is incomplete, but I don't know if that can be changed easily. > How am I supposed to do SGML processing in LyX 1.4? Any pointers, tips, docs? You should type pure SGML in a ERT box. > I am the author of the 230 page document "Document processing with LyX and SGML" (http://www.karakas-online.de/mySGML/), which was written LyX 1.2, so I have an interest in extending my procedures to support LyX 1.4 (currently it seems that only LyX 1.2 will work with them). I am sure that it is possible. Georg
Re: isTrueTextInset issue
Am Mittwoch, 15. März 2006 21:34 schrieb Martin Vermeer:
> On Fri, Mar 10, 2006 at 04:13:47PM +0100, Georg Baum wrote:
> > Martin Vermeer wrote:
> >
> > > On Fri, 2006-03-10 at 15:54 +0100, Jean-Marc Lasgouttes wrote:
> > >
> > >> Small note: I do not like the following much
> > >>
> > >> +bool isTrueTextInset(InsetBase * in)
> > >> +{
> > >> +// Math and tabular insets have isTextInset = true, though
they are
> > >> +// not derived from InsetText. Paint them fully
> > >> +return (in && in->isTextInset() && in->asMathInset() == 0
> > >> +&& in->lyxCode() != InsetBase::TABULAR_CODE);
> > >> +}
> > >> +
> > >> +
> > >
> > > Join the club.
> > >
> > >> Isn't there another way?
> > >
> > > A method in the inset (base inset) itself?
> >
> > Please not if possible. Do you know why math insets return
isTextInset() ==
> > true? Maybe this can be changed?
>
> Actually I would like to bring up this alternative once again. A method
> (derivesFromTextInset?) implemented in insetbase.h returning false, and
> re-implemented in insettext returning true.
But this is exactly what isTextInset is supposed to tell! I had a look,
and it is not used much. The attached patch (ignoring your
isTrueTextInset changes) should restore the true meaning of isTextInset,
but change no functionality. I think that you should build on this. I am
not sure about the tabular inset, we probably need to treat it separately
sometimes, because it
a) is a text inset (it contains text)
b) is no text inset (it does not have a amin LyXText)
> This is much more robust than the current solution against possible
> future changes in the inset landscape. Imagine someone adds a new inset
> type that (like tabular) can contain texts yet does not derive from
> insettext. Then we would have to add a condition to the above method,
> which is essentially un-guessable. A built-in timebomb. The alternative
> solution proposed -- if you want to know if an inset derives from
> textinset, just ask it -- would simply keep working right.
>
> What do you say?
I fully agree.
Georg
Index: src/paragraph_pimpl.C
===
--- src/paragraph_pimpl.C (Revision 13383)
+++ src/paragraph_pimpl.C (Arbeitskopie)
@@ -536,7 +536,8 @@ void Paragraph::Pimpl::simpleTeXSpecialC
&& runparams.flavor == OutputParams::LATEX
&& features.isAvailable("dvipost");
- if (inset->isTextInset()) {
+ if (inset->isTextInset() ||
+ inset->lyxCode() == InsetBase::MATH_CODE) {
column += Changes::latexMarkChange(os, running_change,
Change::UNCHANGED, output);
running_change = Change::UNCHANGED;
Index: src/mathed/math_hullinset.h
===
--- src/mathed/math_hullinset.h (Revision 13383)
+++ src/mathed/math_hullinset.h (Arbeitskopie)
@@ -189,8 +189,6 @@ public:
/// what appears in the minibuffer when opening
virtual std::string const editMessage() const;
///
- virtual bool isTextInset() const { return true; }
- ///
virtual void mutateToText();
///
virtual void revealCodes(LCursor & cur) const;
Index: src/rowpainter.C
===
--- src/rowpainter.C (Revision 13383)
+++ src/rowpainter.C (Arbeitskopie)
@@ -153,9 +153,7 @@ int RowPainter::leftMargin() const
bool isTrueTextInset(InsetBase * in)
{
- // Math and tabular insets have isTextInset = true, though they are
- // not derived from InsetText. Paint them fully
- return (in && in->isTextInset() && in->asMathInset() == 0
+ return (in && in->isTextInset()
&& in->lyxCode() != InsetBase::TABULAR_CODE);
}
Re: [Patch] allow delete para break after insert in CT
On Wed, Mar 15, 2006 at 09:34:24PM +0100, Georg Baum wrote: > Am Mittwoch, 15. März 2006 19:24 schrieb Martin Vermeer: > > On Wed, Mar 15, 2006 at 04:52:59PM +0100, Jean-Marc Lasgouttes wrote: > > > > PS: is it normal that in head, a footnote along in its paragraph takes > > > the whole width of the window when edited? Is that what you discussed > > > with bennett? > > > > Yes, that was a design choice. Without it, selective redraw will > > generate a hopeless mess of inset left and right edges, all in slightly > > different places, due to variations in inset width as you type into it. > > Having edited a lot of footnotes recently I agree with Bennet that it is > ugly. I understand the reason for doing it, mut it might be worth it to > rethink about that when the most urgent bugs are fixed. Looking forward to your experiences playing with this code ;-) - Martin pgpQeYCd5VrjC.pgp Description: PGP signature
[Patch] CT related fixes (Re: [Patch] allow delete para break after insert in CT)
On Wed, Mar 15, 2006 at 04:52:59PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> This is the patch posted on bugzilla (880) to allow
> Martin> backspacing over a paragraph break inserted under change
> Martin> tracking.
>
> Martin> It works, but Jürgen reported a cursor positioning issue, for
> Martin> which I didn't see any obvious reason or fix.
>
> Martin> Can this go into 1.5?
>
> I think you have some freedom about what goes in 1.5.
OK, here is a patch fixing several small interrelated CT issues (one an
assert, i.e., not so small) and documentation improvements. This goes in
soon unless someone spots a problem.
- Martin
(BTW tip: alias svndiff='svn diff --diff-cmd /usr/bin/diff -x -up'
in .bashrc)
Index: ChangeLog
===
--- ChangeLog (revision 13383)
+++ ChangeLog (working copy)
@@ -1,3 +1,13 @@
+2006-03-15 Martin Vermeer <[EMAIL PROTECTED]>
+
+ * CutAndPaste.C (pasteSelectionHelper): comments
+ * paragraph_funcs.C (mergeParagraph): fix Juergen's cut&paste bug
+ * changes.h: comments
+ * paragraph.C (stripLeadingSpaces): remove unnecessary setChange
+ * text.C (backspace): allow deletion of inserted para break
+ Change tracking -related bug fixes (reported by Juergen) and
+ some documentation work
+
2006-03-15 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* MenuBackend.C (expand): make sure the menu is empty before
Index: CutAndPaste.C
===
--- CutAndPaste.C (revision 13383)
+++ CutAndPaste.C (working copy)
@@ -234,7 +234,8 @@ pasteSelectionHelper(Buffer const & buff
pit = last_paste;
pos = pars[last_paste].size();
- // Maybe some pasting.
+ // Join (conditionally) last pasted paragraph with next one, i.e.,
+ // the tail of the spliced document paragraph
if (!empty && last_paste + 1 != pit_type(pars.size())) {
if (pars[last_paste + 1].hasSameLayout(pars[last_paste])) {
mergeParagraph(buffer.params(), pars, last_paste);
Index: paragraph_funcs.C
===
--- paragraph_funcs.C (revision 13383)
+++ paragraph_funcs.C (working copy)
@@ -236,6 +236,19 @@ void mergeParagraph(BufferParams const &
pos_type pos_end = next.size() - 1;
pos_type pos_insert = par.size();
+ // What happens is the following. Later on, moveItem() will copy
+ // over characters from the next paragraph to be inserted into this
+ // position. Now, if the first char to be so copied is "red" (i.e.,
+ // marked deleted) and the paragraph break is marked "blue",
+ // insertChar will trigger (eventually, through record(), and see
+ // del() and erase() in changes.C) a "hard" character deletion.
+ // Which doesn't make sense of course at this pos, but the effect is
+ // to shorten the change range to which this para break belongs, by
+ // one. It will (should) remain "orphaned", having no CT info to it,
+ // and check() in changes.C will assert. Setting the para break
+ // forcibly to "black" prevents this scenario. -- MV 13.3.2006
+ par.setChange(par.size(), Change::UNCHANGED);
+
Change::Type cr = next.lookupChange(next.size());
// ok, now copy the paragraph
for (pos_type i = 0, j = 0; i <= pos_end; ++i) {
Index: changes.h
===
--- changes.h (revision 13383)
+++ changes.h (working copy)
@@ -84,7 +84,8 @@ public:
/// return true if there is a deleted or unchanged range contained
bool isChangeEdited(lyx::pos_type start, lyx::pos_type end) const;
- /// remove the given entry
+ /// remove the given entry. This implies that a character was
+ /// deleted at pos, and will adjust all range bounds past it
void erase(lyx::pos_type pos);
/// output latex to mark a transition between two changetypes
@@ -134,22 +135,23 @@ private:
typedef std::vector ChangeTable;
- /// our table of changes
+ /// our table of changes, every row a range and change descriptor
ChangeTable table_;
/// change type for an empty paragraph
Change::Type empty_type_;
- /// handle a delete
+ /// handle a delete, either logical or physical (see erase)
void del(Change change, ChangeTable::size_type pos);
- /// handle an add
+ /// handle an add, adjusting range bounds past it
void add(Change change, ChangeTable::size_type pos);
- /// merge neighbouring ranges
+ /// merge neighbouring ranges, assuming that they are abutting
+ /// (as done by set())
void merge();
- /// consistency check
+ /// consistency check, needed
LyX 1.4.0 and DocBook SGML
Hello all, very nice work on LyX 1.4! The xft fonts are a pleasure to see (although I haven't found a way yet to make them smaller...). I have still to explore all the other goodies. I am trying to import a LyX 1.2 document: http://www.karakas-online.de/mySGML/mySGML.lyx into LyX 1.4. That document is of class "DocBook book SGML". The class seems to be there (the very first time seemed to be "unavailable", but a "reconfigure" seemed to fix that), however the SGML environment is not! :shock: Whatever I had written in pure SGML is now exported as if it were normal text, with "" becoming "", for example. How am I supposed to do SGML processing in LyX 1.4? Any pointers, tips, docs? I am the author of the 230 page document "Document processing with LyX and SGML" (http://www.karakas-online.de/mySGML/), which was written LyX 1.2, so I have an interest in extending my procedures to support LyX 1.4 (currently it seems that only LyX 1.2 will work with them). Any suggestions? Chris -- Regards Chris Karakas http://www.karakas-online.de
Re: LyX 1.4.0 does not truncate long file names
Am Mittwoch, 15. März 2006 19:00 schrieb Michael Gerz:
> Hi Georg,
>
> pdflatex works now. I had to truncate the filenames to 140 characters.
> Please see attachment.
>
> Could you please commit? I have no svn access.
I changed the comment slightly to make the reason for the value 140 clear.
The attached goes into trunk now.
Is it also OK for 1.4?
Georg
Index: src/support/ChangeLog
===
--- src/support/ChangeLog (Revision 13382)
+++ src/support/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2006-03-15 Georg Baum <[EMAIL PROTECTED]>
+
+ * filename.C (mangledFilename): truncate filename to 140 characters
+ for MiKTeX's pdflatex
+
2006-03-07 Georg Baum <[EMAIL PROTECTED]>
* debugstream.h: fix nullstream.hpp location for boost 1.33.0
Index: src/support/filename.C
===
--- src/support/filename.C (Revision 13382)
+++ src/support/filename.C (Arbeitskopie)
@@ -104,21 +104,25 @@ string const FileName::mangledFilename(s
// This string contains about 50 chars-worth of other data,
// leaving us, say, 160 characters for the file name itself.
// (Erring on the side of caution.)
- string::size_type max_length = 160;
+ // Other experiments show that MiKTeX's pdflatex compiler is even
+ // more picky. A maximum length of 140 has been proven to work.
+ string::size_type max_length = 140;
if (dir.size() - 1 < max_length) {
- // If dir.size() > max_length, all bets are off anyway.
// "+ 1" for the directory separator.
max_length -= dir.size() + 1;
-
- // If the mangled file name is too long, hack it to fit.
- // We know we're guaranteed to have a unique file name because
- // of the counter.
- if (mname.size() > max_length) {
- int const half = (int(max_length) / 2) - 2;
- if (half > 0) {
-mname = mname.substr(0, half) + "___" +
- mname.substr(mname.size() - half);
- }
+ }
+ // If dir.size() > max_length, all bets are off for YAP anyway.
+ // We truncate the filename nevertheless because of MiKTeX's
+ // pdflatex compiler.
+
+ // If the mangled file name is too long, hack it to fit.
+ // We know we're guaranteed to have a unique file name because
+ // of the counter.
+ if (mname.size() > max_length) {
+ int const half = (int(max_length) / 2) - 2;
+ if (half > 0) {
+ mname = mname.substr(0, half) + "___" +
+mname.substr(mname.size() - half);
}
}
Re: Question about Patch submission and commit
Am Mittwoch, 15. März 2006 15:56 schrieb Lars Gullik Bjønnes: > I'll setup both a viewvc and a trac so that we can try them both out. Great! Georg
Re: Sysprof -- did anybody try it?
Am Mittwoch, 15. März 2006 18:49 schrieb Jean-Marc Lasgouttes: > To my defense, I shall add that I never managed to use oprofile (I > plead guilty of incompetence). What I saw on the sysprof page seemed > just simple... You are not alone -- I tried to use it two or three times, but was not patient enough to set up the kernel support correctly. Now that I run a recent kernel it is already included, so I might try it again. Georg
isTrueTextInset issue
On Fri, Mar 10, 2006 at 04:13:47PM +0100, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > On Fri, 2006-03-10 at 15:54 +0100, Jean-Marc Lasgouttes wrote:
> >
> >> Small note: I do not like the following much
> >>
> >> +bool isTrueTextInset(InsetBase * in)
> >> +{
> >> +// Math and tabular insets have isTextInset = true, though they are
> >> +// not derived from InsetText. Paint them fully
> >> +return (in && in->isTextInset() && in->asMathInset() == 0
> >> +&& in->lyxCode() != InsetBase::TABULAR_CODE);
> >> +}
> >> +
> >> +
> >
> > Join the club.
> >
> >> Isn't there another way?
> >
> > A method in the inset (base inset) itself?
>
> Please not if possible. Do you know why math insets return isTextInset() ==
> true? Maybe this can be changed?
Actually I would like to bring up this alternative once again. A method
(derivesFromTextInset?) implemented in insetbase.h returning false, and
re-implemented in insettext returning true.
This is much more robust than the current solution against possible
future changes in the inset landscape. Imagine someone adds a new inset
type that (like tabular) can contain texts yet does not derive from
insettext. Then we would have to add a condition to the above method,
which is essentially un-guessable. A built-in timebomb. The alternative
solution proposed -- if you want to know if an inset derives from
textinset, just ask it -- would simply keep working right.
What do you say?
- Martin
pgpJzNQCn4Qmh.pgp
Description: PGP signature
Re: [Patch] allow delete para break after insert in CT
Am Mittwoch, 15. März 2006 19:24 schrieb Martin Vermeer: > On Wed, Mar 15, 2006 at 04:52:59PM +0100, Jean-Marc Lasgouttes wrote: > > PS: is it normal that in head, a footnote along in its paragraph takes > > the whole width of the window when edited? Is that what you discussed > > with bennett? > > Yes, that was a design choice. Without it, selective redraw will > generate a hopeless mess of inset left and right edges, all in slightly > different places, due to variations in inset width as you type into it. Having edited a lot of footnotes recently I agree with Bennet that it is ugly. I understand the reason for doing it, mut it might be worth it to rethink about that when the most urgent bugs are fixed. Georg
Re: Update to the devel/ web sub-site
On Tue, 14 Mar 2006, Angus Leeming wrote: > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > > "christian" == christian ridderstrom > > <[EMAIL PROTECTED]> writes: > > > > christian> I was also thinking about having to modify .php-files, but > > christian> I haven't really looked at them so I don't know how > > christian> difficult it'd be to change any content. > > > > It is reasonably trivial. And there are some parts (devel/i18n.php) > > where we _do_ use the programming possibilities of php. > > U, but we could equally well use the scripts in the po directory to > create a > wiki-wiki table. The syntax is only: > >|| foo || bar || baz || > > There's no real advantage for the .php here AFAICS because our pages are > essentially static. Or I can just make our own custom markup (:generate-po-info:) which invokes some php-function that I copy from devel/i18n.php... Getting off-topic, is there an online 'subversion' module for Apache now? In other words, where's the equivalent to view-cvs? /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: Update to the devel/ web sub-site
On Tue, 14 Mar 2006, Jean-Marc Lasgouttes wrote: > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > > Lars> But sites that use wiki has a tendency to look like a wiki, just > Lars> as sites that use some publishing tool has a tendency to look > Lars> like a newspaper etc. Ok. I'll see if I copy the web pages into a wiki "backend". As for the apperance and structure, I'll simply copy the existing. I'll just to do this as an experiment, and you can have a look at it to see if looks close enough to the original web site. Maybe I'll do this in the weekend. It's not like it's a priority :-) > That is my concern too. Personally, I have difficulties finding my way > in the wiki. Yeah, to be honest I also find it difficult to navigate my way around the wiki. Unfortunately no one has come up with something that's truly self-organizing when it comes to a wiki. In practice it takes quite a bit of discipline to get a structure and order to the information. So in essence, the wiki needs one or more editors... /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [Patch] allow delete para break after insert in CT
On Wed, Mar 15, 2006 at 04:52:59PM +0100, Jean-Marc Lasgouttes wrote: > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: > > Martin> This is the patch posted on bugzilla (880) to allow > Martin> backspacing over a paragraph break inserted under change > Martin> tracking. > > Martin> It works, but Jürgen reported a cursor positioning issue, for > Martin> which I didn't see any obvious reason or fix. > > Martin> Can this go into 1.5? > > I think you have some freedom about what goes in 1.5. > > You are accumulating changes for 1.4.x too, right? What do you mean? 1. Yes, I try to remember updating status.14x whenever committimg 2. Yes, I'll make a list of all change tracking -related patches in trunk when the time comes to backport. > JMarc > > PS: is it normal that in head, a footnote along in its paragraph takes > the whole width of the window when edited? Is that what you discussed > with bennett? Yes, that was a design choice. Without it, selective redraw will generate a hopeless mess of inset left and right edges, all in slightly different places, due to variations in inset width as you type into it. - Martin pgp5Mj8yZyXSu.pgp Description: PGP signature
Re: LyX 1.4.0 does not truncate long file names
Hi Georg, pdflatex works now. I had to truncate the filenames to 140 characters. Please see attachment. Could you please commit? I have no svn access. Michael - Original Message - From: "Georg Baum" <[EMAIL PROTECTED]> To: Sent: Wednesday, March 15, 2006 1:51 PM Subject: Re: LyX 1.4.0 does not truncate long file names Michael Gerz wrote: I found the piece of code below in support/filename.C. I think there is something wrong with the logic. If dir.size() already exceeds 160 character then LyX will not truncate the filename at all! I guess this is the case in my case. You are right. Angus introduced the truncation because of YAP, therefore the dir name had to be included in the maximum length. We did not know at that time that pdflatex has a limitation, too. Does the attached patch fix the problem? Georg miktexpdflatex.patch Description: Binary data
Re: Sysprof -- did anybody try it?
On Wed, Mar 15, 2006 at 06:49:07PM +0100, Jean-Marc Lasgouttes wrote: > To my defense, I shall add that I never managed to use oprofile (I > plead guilty of incompetence). Hmmm... I dunno how. You only have to do one piece of setup... > What I saw on the sysprof page seemed just simple... Alas they couldn't be bothered to work with an existing project so they reinvented the wheel. The GUI seems nice. john
Re: Sysprof -- did anybody try it?
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Wed, Mar 15, 2006 at 04:23:00PM +0100, Jean-Marc Lasgouttes John> wrote: >> This seems to be very close to Shark.app: >> http://www.daimi.au.dk/~sandmann/sysprof/ John> *grumble* :) To my defense, I shall add that I never managed to use oprofile (I plead guilty of incompetence). What I saw on the sysprof page seemed just simple... But I am sure there are many reason why this program is useless :) JMarc
Re: [patch] fix bug 2361
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: >> I propose to change just label fbox and boxed for now in 1.4. Georg> OK, I did that. Perfect. JMarc
Re: Pending patches for 1.5 -> 1.4.x
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sat, Mar 11, 2006 at 04:28:08PM +0100, Lars Gullik Bjønnes wrote:
| > | > template
| > | > RandomAccessList(It it_start, It it_end) {
| > |
| > | Maybe adding 'reserve' is in order.
| >
| > imho leave all optimizations of that kind out for now.
|
| Given that this is work to improve performance I wonder what
| the reasoning behind leaving out some 'obvious' optimization
| might be...
that it is not as an obvious optimization at all...
Figuring out what to revserve is an O(n) operations in itself. And
most of hte time the vector will alreay be larger or have the correct
size anyway.
--
Lgb
Re: [Cvslog] r13362 -/lyx-devel/trunk/development/Win32/packaging/bui...
Michael Gerz <[EMAIL PROTECTED]> writes: > Hi Angus, > is there any reason why you did not add build_aspell.sh to the 1.4.0 branch? > How about the update to polish.nsh? > My understanding is that 1.5.0 and 1.4.X should be in sync. > I would like to update INSTALL.Win32 afterwards. Michael, please get some commit privileges yourself. I'm nowhere near a box that I can commit from ATM and am unlikely to be near one for some time. Angus
Re: pre6
On Wednesday 15 March 2006 16:08, Jean-Marc Lasgouttes wrote: > > "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: > > Jose'> Jean-Marc, do you want to commite something like this for > Jose'> 1.4.x? > > Jose'> As Rex said the order does not need to be the same used, > Jose'> nevertheless I propose to always place the x-viewers at the > Jose'> end. In modern linux (*) most of those relics look really bad, > Jose'> and it impacts in our first contact with new users. > > Make a proposal :) I was thinking along the lines of: \System neutral \Format agr"xmgrace" "xmgrace" \System kde \Format asciichess "kate" "kate" \Format bmp"kview""krita" \Format dvi"kdvi" "" \Format html "konqueror file://$$p$$i" "" \System gnome \Format asciichess "gedit" "gedit" \Format bmp"eog""gimp" \Format dvi"evince" "" \Format html "htmlview file://$$p$$i" "" \System X11 \Format asciichess "nedit" "nedit" \Format bmp"xv""xv" \Format dvi"xdvi" "" \Format html "netscape" "" \System win \Format asciichess "winedit" "winedit" \Format bmp"ie""ie" \Format dvi"xdvi" "" \Format html "ie" "" \System OSX \Format asciichess "display" "..." \Format bmp"...""..." \Format dvi"..." "..." \Format html "..." "..." \SystemOrder neutral kde gnome X11 > JMarc -- José Abílio
Re: [Patch] Qt4 wheel mouse + Q_WS_* macro
Bennett Helm a écrit : On Mar 15, 2006, at 5:22 AM, Abdelrazak Younes wrote: Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Hum, I don't know, did someone tested your changes on Abdelrazak> qt2/X11/Mac? I would tend to think that the X11 clipboard Abdelrazak> wouldn't need this change but I don't know really. I would assume that the X11 clipboard always uses LF, but I have no way to check. I guess our only hope is Bennett... How you guys did managed to complete the MAC port without any developer on board? So what am I, chopped liver? ... Sorry Bennet, I didn't meant to hurt you, I meant "C++ developer". I got the (maybe wrong) impression that you were not. I appreciate very much your help in testing in any case. Abdel. Actually, I might as well be for the next week: I'm getting too busy with other things right now. Hopefully by Tuesday I'll be able to try this again. Bennett
Re: [Cvslog] r13362 -/lyx-devel/trunk/development/Win32/packaging/bui...
Hi Angus, is there any reason why you did not add build_aspell.sh to the 1.4.0 branch? How about the update to polish.nsh? My understanding is that 1.5.0 and 1.4.X should be in sync. I would like to update INSTALL.Win32 afterwards. Michael - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 13, 2006 3:38 PM Subject: [Cvslog] r13362 -/lyx-devel/trunk/development/Win32/packaging/bui... Author: leeming Date: Mon Mar 13 15:38:22 2006 New Revision: 13362 Log: Helper script to compile the Aspell library. Added: lyx-devel/trunk/development/Win32/packaging/build_aspell.sh ___ Cvslog mailing list [EMAIL PROTECTED] http://www.lyx.org/mailman/listinfo/cvslog
Re: Lyx-trunk configure fails
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Sat, Mar 11, 2006 at 04:32:09PM +0100, Lars Gullik Bjønnes wrote: | > Andre Poenitz <[EMAIL PROTECTED]> writes: | > | > | On Wed, Mar 08, 2006 at 10:30:02PM +0100, Jean-Marc Lasgouttes wrote: | > | > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: | > | > | > | > Andre> However, if the idea is to enforce LF in this file the | > | > Andre> canonical solution is a pre-commit hook script that rejects | > | > Andre> commits containing the 'wrong' line endings. | > | > | > | > No, the problem is that line ending must remain LF when checking out | > | > in windows. | > | | > | That happens also if the file is checked in with LF and no svn:eol-style | > | is set. | > | > But will svn then complain if you try to commit a file with mixed | > line-endings? | | Not without installing a pre-commit hook that will reject commits with | 'wrong' line endings. But we could/should have such anyway. sure it will. Just set eol-style to native and svn will complain if you try to commit a file with mixed line endings. -- Lgb
Re: [Patch] Qt4 wheel mouse + Q_WS_* macro
On Mar 15, 2006, at 5:22 AM, Abdelrazak Younes wrote: Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Hum, I don't know, did someone tested your changes on Abdelrazak> qt2/X11/Mac? I would tend to think that the X11 clipboard Abdelrazak> wouldn't need this change but I don't know really. I would assume that the X11 clipboard always uses LF, but I have no way to check. I guess our only hope is Bennett... How you guys did managed to complete the MAC port without any developer on board? So what am I, chopped liver? ... Actually, I might as well be for the next week: I'm getting too busy with other things right now. Hopefully by Tuesday I'll be able to try this again. Bennett
Re: Pending patches for 1.5 -> 1.4.x
On Sat, Mar 11, 2006 at 04:28:08PM +0100, Lars Gullik Bjønnes wrote:
> | > template
> | > RandomAccessList(It it_start, It it_end) {
> |
> | Maybe adding 'reserve' is in order.
>
> imho leave all optimizations of that kind out for now.
Given that this is work to improve performance I wonder what
the reasoning behind leaving out some 'obvious' optimization
might be...
Andre'
Re: Lyx-trunk configure fails
On Sat, Mar 11, 2006 at 04:32:09PM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | On Wed, Mar 08, 2006 at 10:30:02PM +0100, Jean-Marc Lasgouttes wrote: > | > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: > | > > | > Andre> However, if the idea is to enforce LF in this file the > | > Andre> canonical solution is a pre-commit hook script that rejects > | > Andre> commits containing the 'wrong' line endings. > | > > | > No, the problem is that line ending must remain LF when checking out > | > in windows. > | > | That happens also if the file is checked in with LF and no svn:eol-style > | is set. > > But will svn then complain if you try to commit a file with mixed > line-endings? Not without installing a pre-commit hook that will reject commits with 'wrong' line endings. But we could/should have such anyway. Andre'
Re: Pending patches for 1.5 -> 1.4.x
On Sat, Mar 11, 2006 at 05:21:43PM +0100, Abdelrazak Younes wrote: > enpos is a size_t, do you really think there is a benefit to make it > const? The compiler will produce identical code (at least 3.3.6(?) did a while ago), but we try to enforce 'as much const as possible' and there is no exception for five-liners. Andre'
Re: Pending patches for 1.5 -> 1.4.x
On Sat, Mar 11, 2006 at 09:03:22AM +0100, Abdelrazak Younes wrote:
> Hello Andre,
Hello Abdel.
> I noticed that your mails seem to arrive with a delay of one or two
> days. Maybe your clock settings are wrong or something?
No, it just means I am rarely online and am usually not connected to the
net when I write mail.
> Andre Poenitz a écrit :
> >On Wed, Mar 08, 2006 at 04:28:30PM +0100, Abdelrazak Younes wrote:
> >
> >It shouldn't be much of a difference, but the canonical way for
> >such a 'symmetric' operation is to have it as free function outside the
> >class.
>
> I know but in this case (template class), it is much less code inside
> the class.
I am fine with that as long as you find a reason...
> >I am not sure there are many precedence for capitalized member variables
> >in LyX code.
>
> There are some from which I took example... I think you guys should
> agree on coding style guidelines and write a _small_ document with it.
> Second step would be to actually use it all through the code ;-)
Ugh...
>
> >>RandomAccessList(It it_start, It it_end) {
> >
> >Maybe adding 'reserve' is in order.
>
> OK.
>
> >
> >'swap' would be nice to have in the long run...
>
> Yes.
>
> >>bool erase(iterator start, iterator end) {
> >>size_t startpos = std::distance(Container_.begin(),
> >>static_cast(start));
> >>size_t endpos = std::distance(Container_.begin(),
> >>static_cast(end));
> >>return erase(startpos, endpos-startpos);
> >>}
> >
> >const + spacing.
>
> const?
bool erase(iterator start, iterator end) {
size_t const startpos = std::distance(Container_.begin(),
static_cast(start));
size_t const endpos = std::distance(Container_.begin(),
static_cast(end));
> >Could you move this up a bit closer to the constructors?
>
> Sure.
>
> >
> >Look pretty good in general.
>
> Thanks for the comments Andre. One question about the spacing: is it
> because of your editor or just that you find it easier to read?
Spacing? Well, it's nowadays fairly consistent within LyX.
I usually don't care too much about a certain style as long as it is
used consistently within a project. But when given a choice, I tend to
prfer the 'spacey style' for private stuff (except for shell and
Makefiles...)
Andre'
Re: Pending patches for 1.5 -> 1.4.x
On Sat, Mar 11, 2006 at 04:29:56PM +0100, Lars Gullik Bjønnes wrote: > Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > | > I am not sure there are many precedence for capitalized member variables > | > in LyX code. > | > | There are some from which I took example... I think you guys should > | agree on coding style guidelines and write a _small_ document with it. > | Second step would be to actually use it all through the code ;-) > > We have rules and guidelines... you just have to read them. > > development/Code_rules/ This is the first file that should be renamed. Andre'
Re: Problem with mathed
Abdelrazak Younes a écrit : Abdelrazak Younes a écrit : Georg Baum a écrit : Abdelrazak Younes wrote: Hello, Mathed doesn't seem to work with the qt4 frontend. Symbols are not displayed at all, equations just show empty blue square. Back to my equation problem, the qt2 frontend does not have it, so it is qt4 only. I'll reboot windows to see if it helps... I don't know the reason but after a reboot, a svn update and a recompile, my equations came back! Weird... Abdel.
Re: Problem with mathed
Abdelrazak Younes wrote: > My god! I forgot how slw and memory intensive was the compilation of > the qt2 frontend. I don't know about linux but on windows it is slow as > hell. Now I remember why I started the Qt4 port :-) > Out of curiosity, Georg, Juergen, do you see any improvement under linux > with qt4 frontend wrt compilation time? On windows, if I'm changing a > file, re-generating the executable is a matter of three minutes (with > -O3). Qt2, well, a bit less than an hour and 450 Megs of RAM. This is a well known windows-only problem. I did not really measure compilation time, but I can't see any difference on Linux from watching. Georg
Re: Problem with mathed
Abdelrazak Younes a écrit : Georg Baum a écrit : Abdelrazak Younes wrote: Hello, Mathed doesn't seem to work with the qt4 frontend. Symbols are not displayed at all, equations just show empty blue square. Here I get every symbol displayed in red. Is it due to some recent changes? I know I haven't touch anything at all on the pixmap painting (QLPainter). But math is rendered with fonts. The output of -dbg font tells me that the qt4 font handdling in LyX is broken: It was working a few days ago. I am compiling qt2 frontend right now to see the difference. My god! I forgot how slw and memory intensive was the compilation of the qt2 frontend. I don't know about linux but on windows it is slow as hell. Now I remember why I started the Qt4 port :-) Out of curiosity, Georg, Juergen, do you see any improvement under linux with qt4 frontend wrt compilation time? On windows, if I'm changing a file, re-generating the executable is a matter of three minutes (with -O3). Qt2, well, a bit less than an hour and 450 Megs of RAM. Back to my equation problem, the qt2 frontend does not have it, so it is qt4 only. I'll reboot windows to see if it helps... Abdel
Re: make po fails on windows
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> [EMAIL PROTECTED] ~/lyx/trunk/po $ grep FIND Makefile* This does not mean anything, since find is invoked lowercase. The error you get is from windows' find.exe as this page (in french!) says: http://developer.mozilla.org/fr/docs/FAQ_sur_la_compilation_de_Mozilla Interesting, thanks. But there's something rotten here because '/bin' is before '/c/WINDOWS/system32' on my Msys system. Even removing '/c/WINDOWS/system32' completely for the variable won't work! And bloody windows XP automatically recreate find.exe whenever you delete it... That's OK, I don't use the other languages in any case. Abdel.
Re: pre6
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes: Jose'> Jean-Marc, do you want to commite something like this for Jose'> 1.4.x? Jose'> As Rex said the order does not need to be the same used, Jose'> nevertheless I propose to always place the x-viewers at the Jose'> end. In modern linux (*) most of those relics look really bad, Jose'> and it impacts in our first contact with new users. Make a proposal :) JMarc
Re: pre6
> "Rex" == Rex Dieter <[EMAIL PROTECTED]> writes: Rex> And here it is (sorry for not mentioning it here/upstream Rex> earlier). Should be pretty self-explanatory. Rex> In particular, adds usage for htmlview, evince, gsview... Rex> re-arranges priorities a bit (you can freetly omit/ignore those Rex> bits if you disagree with my preference of priorities). I agree with this patch in general. Why is firefox ignored for html? JMarc
Re: [patch] fix bug 2361
Jean-Marc Lasgouttes wrote: > Anyway, with your patch I see a difference when I type \protect in > mathed (was: nothing (or maybe empty symbol inset?), becomes: red > protect). I do not think the red protect is good. It does not matter IMO since you should not enter \protect anyway: It will be ignored when the document is read the next time. If you really need a \protect where LyX does not put one you have to define a \myprotect (in ERT or preamble, a macro would not work) and use that. > Georg> Summary: lbale, fbox and boxed need to be removed, parbox is > Georg> broken in either case, and the others are ignored anyway. > > Georg> What shall I now do for 1.4? > > I propose to change just label fbox and boxed for now in 1.4. OK, I did that. GeorgIndex: status.14x === --- status.14x (Revision 13382) +++ status.14x (Arbeitskopie) @@ -50,5 +50,7 @@ What's new - Fix drawing of inset buttons (bug 2328) +- Fix drawing of \boxed and \fbox in formulas (bug 2361). + * Configuration/Installation: Index: lib/ChangeLog === --- lib/ChangeLog (Revision 13382) +++ lib/ChangeLog (Arbeitskopie) @@ -1,3 +1,7 @@ +2006-03-15 Georg Baum <[EMAIL PROTECTED]> + + * symbols: Comment out unused insets + 2006-03-11 Georg Baum <[EMAIL PROTECTED]> * configure.py: fix off-by-one error in version_suffix handling Index: lib/symbols === --- lib/symbols (Revision 13382) +++ lib/symbols (Arbeitskopie) @@ -121,11 +121,9 @@ parboxparbox none protect protect none mbox mboxforcetext newcommandnewcommand none -label label none +#label label none left leftnone end end none -fbox fboxnone -boxed fboxnone #
Re: make po fails on windows
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> [EMAIL PROTECTED] ~/lyx/trunk/po $ grep FIND Makefile* This does not mean anything, since find is invoked lowercase. The error you get is from windows' find.exe as this page (in french!) says: http://developer.mozilla.org/fr/docs/FAQ_sur_la_compilation_de_Mozilla JMarc
Re: [Patch] allow delete para break after insert in CT
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> This is the patch posted on bugzilla (880) to allow Martin> backspacing over a paragraph break inserted under change Martin> tracking. Martin> It works, but Jürgen reported a cursor positioning issue, for Martin> which I didn't see any obvious reason or fix. Martin> Can this go into 1.5? I think you have some freedom about what goes in 1.5. You are accumulating changes for 1.4.x too, right? JMarc PS: is it normal that in head, a footnote along in its paragraph takes the whole width of the window when edited? Is that what you discussed with bennett?
Re: [patch] fix bug 2361
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> begin begin none right right none protect protect none Georg> newcommand newcommand none left left none end end none Georg> We don't have these as insets, so these get parsed as a Georg> MathSymbolInset (with name 'begin' etc.) in createMathInset(). Georg> This does not make sense IMO. Apart from that, all these cases Georg> are handled explicitly in the math parser. Therefore these Georg> entries in lib/symbols have no effect, because everything goes Georg> through the math parser (including text->math conversion and Georg> math-insert \bla\blub via the minibuffer) Anyway, with your patch I see a difference when I type \protect in mathed (was: nothing (or maybe empty symbol inset?), becomes: red protect). I do not think the red protect is good. Georg> Summary: lbale, fbox and boxed need to be removed, parbox is Georg> broken in either case, and the others are ignored anyway. Georg> What shall I now do for 1.4? I propose to change just label fbox and boxed for now in 1.4. JMarc
Re: [patch] bug 1999: Wrong default label in figure captions
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes: Juergen> Thanks. Updated patch attached. Tested and approved. Please apply to branch and trunk. JMarc
Re: Sysprof -- did anybody try it?
On Wed, Mar 15, 2006 at 04:23:00PM +0100, Jean-Marc Lasgouttes wrote: > This seems to be very close to Shark.app: > http://www.daimi.au.dk/~sandmann/sysprof/ *grumble* john
Re: [PATCH] bug 2328: inset buttons are not painted correctly.
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: Georg> Jean-Marc Lasgouttes wrote: >> It turns out that fillPolygon does not work the same in all >> frontends (qt is a problem). The following patch uses normal lines >> instead. >> >> It means that fillPolygon is not used anymore. Georg> Then I would think that it should either be removed completely, Georg> or a comment added that it is broken. I added a comment that it is unused and committed to branch and trunk. JMarc
Re: [Patch] add Menu::clear()
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Lars, qt4 frontend needs a Menu::clear() method to Abdelrazak> compile. Could you apply this please? I added Menu::clear() and called it at the start of MenuBackend::expand. So you should remove explicit calls in qt4 frontend. Done. Thanks, Abdel.
Sysprof -- did anybody try it?
This seems to be very close to Shark.app: http://www.daimi.au.dk/~sandmann/sysprof/ Did anybody try it on LyX? JMarc
Re: [Patch] add Menu::clear()
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Lars, qt4 frontend needs a Menu::clear() method to Abdelrazak> compile. Could you apply this please? I added Menu::clear() and called it at the start of MenuBackend::expand. So you should remove explicit calls in qt4 frontend. John, the same holds for gtk (I think clearBackMenu is not useful anymore). JMarc
Re: Question about Patch submission and commit
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> In this case that would be enough. | | Lars> One thing the ChangeLog format has that is usefule is mentioning | Lars> the function where the change took place. | | Definitely that part I like most. | | Lars> But, yes, a tiny bit of effort and svn log messages could just | Lars> as useful as ChangeLog, but more powerful and less work. | | What would be nice is a web-based interface that lets us look at | annotations... I'll setup both a viewvc and a trac so that we can try them both out. -- Lgb
Re: Question about Patch submission and commit
On Wed, Mar 15, 2006 at 03:09:56PM +0100, Lars Gullik Bjønnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: ... > | Even that is overkill: svn log -v gives output like > | > | > | r13311 | baum | 2006-03-07 12:02:07 +0200 (Tue, 07 Mar 2006) | 2 lines > | Changed paths: > |M /lyx-devel/trunk/src/ChangeLog > |M /lyx-devel/trunk/src/frontends/controllers/ChangeLog > |M /lyx-devel/trunk/src/frontends/controllers/tests/pch.h > |M /lyx-devel/trunk/src/pch.h > |M /lyx-devel/trunk/src/support/ChangeLog > |M /lyx-devel/trunk/src/support/pch.h > | > | fix nullstream also in pch files > | > | What more do we need? Only the last line was manually entered. > > In this case that would be enough. > > One thing the ChangeLog format has that is usefule is mentioning the > function where the change took place. > > But, yes, a tiny bit of effort and svn log messages could just as > useful as ChangeLog, but more powerful and less work. Subversion itself uses only svn log. See Karl Fogel's .bashrc esp. "quicklog": http://svn.red-bean.com/repos/kfogel/trunk/.bashrc - Martin pgpcdBphSDYdD.pgp Description: PGP signature
Re: Question about Patch submission and commit
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> In this case that would be enough. Lars> One thing the ChangeLog format has that is usefule is mentioning Lars> the function where the change took place. Definitely that part I like most. Lars> But, yes, a tiny bit of effort and svn log messages could just Lars> as useful as ChangeLog, but more powerful and less work. What would be nice is a web-based interface that lets us look at annotations... JMarc
Re: Question about Patch submission and commit
Martin Vermeer <[EMAIL PROTECTED]> writes: | On Wed, Mar 15, 2006 at 02:41:33PM +0200, Martin Vermeer wrote: | > On Wed, Mar 15, 2006 at 12:57:24PM +0100, Lars Gullik Bjønnes wrote: | > > Abdelrazak Younes <[EMAIL PROTECTED]> writes: | > > | > > | Hello, | > > | | > > | I have a tendency to commit very often... but this double-changelogs | > > | and mail to lyx-devel is fastidious. | > > | > > Agree. | > > | > > btw. did we come to any consensus about my "Drop ChangeLogs" RFC? | > | > I would agree... but shouldn't then the commit message be of the | > ChangeLog format? I.e., without the name line. The output of svn log | > should look more or less like the ChangeLog file. It shouldn't be hard | > to set up emacs for this. | | Even that is overkill: svn log -v gives output like | | | r13311 | baum | 2006-03-07 12:02:07 +0200 (Tue, 07 Mar 2006) | 2 lines | Changed paths: |M /lyx-devel/trunk/src/ChangeLog |M /lyx-devel/trunk/src/frontends/controllers/ChangeLog |M /lyx-devel/trunk/src/frontends/controllers/tests/pch.h |M /lyx-devel/trunk/src/pch.h |M /lyx-devel/trunk/src/support/ChangeLog |M /lyx-devel/trunk/src/support/pch.h | | fix nullstream also in pch files | | What more do we need? Only the last line was manually entered. In this case that would be enough. One thing the ChangeLog format has that is usefule is mentioning the function where the change took place. But, yes, a tiny bit of effort and svn log messages could just as useful as ChangeLog, but more powerful and less work. -- Lgb
Re: Problem with mathed
Abdelrazak Younes wrote: > So what is my problem then? Any idea? No :-( Georg
Re: Problem with mathed
Georg Baum a écrit : Abdelrazak Younes wrote: Does it seem correct to you? Yes. So what is my problem then? Any idea? The attached patch makes symbols work for me. It is going in right now. Very good. PS: The line endings in the ChangeLog are mixed up. I guess I have to change my editor then, I'll try to switch to XEmacs. Thanks, Abdel.
Re: Problem with mathed
Abdelrazak Younes wrote:
> Does it seem correct to you?
Yes. The problem in my case is that the font name on X11 with Xft is always
"xft" in qt2. In qt4 it seems that this clever name changed to "Multi".
The attached patch makes symbols work for me. It is going in right now.
Georg
PS: The line endings in the ChangeLog are mixed up.Index: src/frontends/qt4/ChangeLog
===
--- src/frontends/qt4/ChangeLog (Revision 13377)
+++ src/frontends/qt4/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2006-03-15 Georg Baum <[EMAIL PROTECTED]>
+
+ * qfont_loader.C (isChosenFont): Xft-enabled Qt 4.1 seems to call
+ all fonts "Multi". Therefore test for this case.
+
2006-03-15 Abdelrazak Younes <[EMAIL PROTECTED]>
* QLPopupMenu.[Ch]: renamed topLevelMenu to topLevelMenu_
Index: src/frontends/qt4/qfont_loader.C
===
--- src/frontends/qt4/qfont_loader.C (Revision 13377)
+++ src/frontends/qt4/qfont_loader.C (Arbeitskopie)
size_t const nr_symbol_fonts = sizeof(symbol_fonts) / sizeof(symbol_font);
@@ -177,7 +177,8 @@ bool isChosenFont(QFont & font, string c
}
// Qt 3.2 beta1 returns "xft" for all xft fonts
- if (font.rawName() == "xft") {
+ // Qt 4.1 returns "Multi" for all ? xft fonts
+ if (font.rawName() == "xft" || font.rawName() == "Multi") {
if (contains(fromqstr(fi.family()), family)) {
lyxerr[Debug::FONT] << " got it (Xft) ";
return true;
Re: Problem with mathed
Georg Baum a écrit : Abdelrazak Younes wrote: Hello, Mathed doesn't seem to work with the qt4 frontend. Symbols are not displayed at all, equations just show empty blue square. Here I get every symbol displayed in red. Is it due to some recent changes? I know I haven't touch anything at all on the pixmap painting (QLPainter). But math is rendered with fonts. The output of -dbg font tells me that the qt4 font handdling in LyX is broken: It was working a few days ago. I am compiling qt2 frontend right now to see the difference. -dbg font tells me: Setting debug level to font Debugging `font' (Font handling) Language code:C Setting new locale for Qt:C lyx: Disabling LyX socket. Font 'Sans Serif, Bold, Upright, Normal, yellow, Emphasis Off, Underline Off, Noun Off, Language: English' matched by The font has size: 15 This font is NOT an exact match XFLD: Font 'Roman, Medium, Upright, Normal, none, Emphasis Off, Underline Off, Noun Off, Language: English' matched by The font has size: 15 This font is NOT an exact match XFLD: Looking for font family eufm10 ... raw: eufm10 alleged fi family: got it normal! Looking for font family cmsy10 ... raw: cmsy10 alleged fi family: got it normal! Looking for font family cmmi10 ... raw: cmmi10 alleged fi family: got it normal! Looking for font family cmr10 ... raw: cmr10 alleged fi family: got it normal! Looking for font family cmex10 ... raw: cmex10 alleged fi family: got it normal! Looking for font family msam10 ... raw: msam10 alleged fi family: got it normal! Looking for font family msbm10 ... raw: msbm10 alleged fi family: got it normal! Looking for font family wasy10 ... raw: wasy10 alleged fi family: got it normal! Font 'Roman, Medium, Italic, Normal, math, Emphasis Off, Underline Off, Noun Off, Language: English' matched by The font has size: 15 This font is NOT an exact match XFLD: Does it seem correct to you? Welcome to Qt font hell :-) Indeed Abdel
Re: Problem with mathed
Abdelrazak Younes wrote: > Hello, > > Mathed doesn't seem to work with the qt4 frontend. Symbols are not > displayed at all, equations just show empty blue square. Here I get every symbol displayed in red. > Is it due to some recent changes? I know I haven't touch anything at all > on the pixmap painting (QLPainter). But math is rendered with fonts. The output of -dbg font tells me that the qt4 font handdling in LyX is broken: Font 'Sans Serif, Bold, Upright, Normal, yellow, Emphasis Off, Underline Off, Noun Off, Language: German' matched by Multi The font has size: 15 This font is NOT an exact match XFLD: Multi Font 'Roman, Medium, Upright, Normal, none, Emphasis Off, Underline Off, Noun Off, Language: German' matched by Multi The font has size: 15 This font is NOT an exact match XFLD: Multi Looking for font family eufm10 ... raw: Multi alleged fi family: Albany AMT raw: Multi alleged fi family: Albany AMT raw: Multi alleged fi family: FreeSans FAILED :-( Looking for font family cmsy10 ... raw: Multi alleged fi family: cmsy10 raw: Multi alleged fi family: cmsy10 raw: Multi alleged fi family: Albany AMT FAILED :-( Looking for font family cmmi10 ... raw: Multi alleged fi family: cmmi10 raw: Multi alleged fi family: cmmi10 raw: Multi alleged fi family: cmmi10 FAILED :-( Looking for font family symbol ... raw: Multi alleged fi family: Standard Symbols L raw: Multi alleged fi family: Standard Symbols L raw: Multi alleged fi family: Dustismo FAILED :-( Looking for font family cmr10 ... raw: Multi alleged fi family: cmr10 raw: Multi alleged fi family: cmr10 raw: Multi alleged fi family: Albany AMT FAILED :-( Looking for font family cmex10 ... raw: Multi alleged fi family: cmex10 raw: Multi alleged fi family: cmex10 raw: Multi alleged fi family: Albany AMT FAILED :-( Looking for font family msam10 ... raw: Multi alleged fi family: msam10 raw: Multi alleged fi family: msam10 raw: Multi alleged fi family: Albany AMT FAILED :-( Looking for font family msbm10 ... raw: Multi alleged fi family: msbm10 raw: Multi alleged fi family: msbm10 raw: Multi alleged fi family: Albany AMT FAILED :-( Looking for font family wasy10 ... raw: Multi alleged fi family: wasy10 raw: Multi alleged fi family: wasy10 raw: Multi alleged fi family: Albany AMT FAILED :-( Font 'Roman, Medium, Italic, Normal, math, Emphasis Off, Underline Off, Noun Off, Language: German' matched by Multi The font has size: 15 This font is NOT an exact match XFLD: Multi Welcome to Qt font hell :-) Georg
Re: Question about Patch submission and commit
Lars Gullik Bjønnes wrote: > btw. did we come to any consensus about my "Drop ChangeLogs" RFC? I don't care too much about ChangeLog <-> log message, but I think we should do it uniformly (I don't want to look both in ChangeLogs and svn log). Georg
Re: Question about Patch submission and commit
On Wed, Mar 15, 2006 at 02:41:33PM +0200, Martin Vermeer wrote: > On Wed, Mar 15, 2006 at 12:57:24PM +0100, Lars Gullik Bjønnes wrote: > > Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > > > | Hello, > > | > > | I have a tendency to commit very often... but this double-changelogs > > | and mail to lyx-devel is fastidious. > > > > Agree. > > > > btw. did we come to any consensus about my "Drop ChangeLogs" RFC? > > I would agree... but shouldn't then the commit message be of the > ChangeLog format? I.e., without the name line. The output of svn log > should look more or less like the ChangeLog file. It shouldn't be hard > to set up emacs for this. Even that is overkill: svn log -v gives output like r13311 | baum | 2006-03-07 12:02:07 +0200 (Tue, 07 Mar 2006) | 2 lines Changed paths: M /lyx-devel/trunk/src/ChangeLog M /lyx-devel/trunk/src/frontends/controllers/ChangeLog M /lyx-devel/trunk/src/frontends/controllers/tests/pch.h M /lyx-devel/trunk/src/pch.h M /lyx-devel/trunk/src/support/ChangeLog M /lyx-devel/trunk/src/support/pch.h fix nullstream also in pch files What more do we need? Only the last line was manually entered. - Martin pgpNggTVxicDe.pgp Description: PGP signature
Re: LyX 1.4.0 does not truncate long file names
Michael Gerz wrote:
> I found the piece of code below in support/filename.C. I think there is
> something wrong with the logic. If dir.size() already exceeds 160
> character then LyX will not truncate the filename at all! I guess this is
> the case in my case.
You are right. Angus introduced the truncation because of YAP, therefore the
dir name had to be included in the maximum length. We did not know at that
time that pdflatex has a limitation, too. Does the attached patch fix the
problem?
GeorgIndex: src/support/filename.C
===
--- src/support/filename.C (Revision 13371)
+++ src/support/filename.C (Arbeitskopie)
@@ -106,19 +106,21 @@ string const FileName::mangledFilename(s
// (Erring on the side of caution.)
string::size_type max_length = 160;
if (dir.size() - 1 < max_length) {
- // If dir.size() > max_length, all bets are off anyway.
// "+ 1" for the directory separator.
max_length -= dir.size() + 1;
-
- // If the mangled file name is too long, hack it to fit.
- // We know we're guaranteed to have a unique file name because
- // of the counter.
- if (mname.size() > max_length) {
- int const half = (int(max_length) / 2) - 2;
- if (half > 0) {
-mname = mname.substr(0, half) + "___" +
- mname.substr(mname.size() - half);
- }
+ }
+ // If dir.size() > max_length, all bets are off for YAP anyway.
+ // We truncate the filename nevertheless because MiKTeX's
+ // pdflatex can only handle names up to about 200 characters.
+
+ // If the mangled file name is too long, hack it to fit.
+ // We know we're guaranteed to have a unique file name because
+ // of the counter.
+ if (mname.size() > max_length) {
+ int const half = (int(max_length) / 2) - 2;
+ if (half > 0) {
+ mname = mname.substr(0, half) + "___" +
+mname.substr(mname.size() - half);
}
}
Re: Question about Patch submission and commit
On Wed, Mar 15, 2006 at 12:57:24PM +0100, Lars Gullik Bjønnes wrote: > Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > | Hello, > | > | I have a tendency to commit very often... but this double-changelogs > | and mail to lyx-devel is fastidious. > > Agree. > > btw. did we come to any consensus about my "Drop ChangeLogs" RFC? I would agree... but shouldn't then the commit message be of the ChangeLog format? I.e., without the name line. The output of svn log should look more or less like the ChangeLog file. It shouldn't be hard to set up emacs for this. - Martin pgpc1jqO74dj2.pgp Description: PGP signature
Re: [Patch] MACX QMenubar crash fix.
On Wed, Mar 15, 2006 at 12:20:48PM +0100, Abdelrazak Younes wrote: > Oups, I comitted before creating the patch... > > Is there a way to generate the generate a patch automatically when you > commit? No, but you can extract it after the fact: svn diff -r old:new URL >patch.diff or something. - Martin pgpENSw8T4xea.pgp Description: PGP signature
Problem with mathed
Hello, Mathed doesn't seem to work with the qt4 frontend. Symbols are not displayed at all, equations just show empty blue square. Is it due to some recent changes? I know I haven't touch anything at all on the pixmap painting (QLPainter). Abdel.
Re: LyX 1.4.0 does not truncate long file names
Hi Georg,
I found the piece of code below in support/filename.C. I think there is
something wrong with the logic. If dir.size() already exceeds 160 character
then LyX will not truncate the filename at all! I guess this is the case in
my case.
Michael
// Experiments show that MiKTeX's YAP (version 2.4.1803)
// will crash if the string referencing the file name in
// the .dvi file is longer than 220 characters.
// This string contains about 50 chars-worth of other data,
// leaving us, say, 160 characters for the file name itself.
// (Erring on the side of caution.)
string::size_type max_length = 160;
if (dir.size() - 1 < max_length) {
// If dir.size() > max_length, all bets are off anyway.
// "+ 1" for the directory separator.
max_length -= dir.size() + 1;
// If the mangled file name is too long, hack it to fit.
// We know we're guaranteed to have a unique file name
because
// of the counter.
if (mname.size() > max_length) {
int const half = (int(max_length) / 2) - 2;
if (half > 0) {
mname = mname.substr(0, half) + "___" +
mname.substr(mname.size() - half);
}
}
}
- Original Message -
From: "Georg Baum" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, March 14, 2006 8:06 PM
Subject: Re: LyX 1.4.0 does not truncate long file names
Am Dienstag, 14. März 2006 18:42 schrieb Michael Gerz:
the critical length is about 200 characters. However, to me it makes no
sense to have file name of this length. Maybe 100 (or 160) chars is a
more
reasonable limitation.
But LyX is supposed to truncate to 160 chars already. Can you please find
out whether this is working (and pdflatex requires even shorter
filenames), or whether the truncation is not working?
Georg
Re: Question about Patch submission and commit
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Hello, | | I have a tendency to commit very often... but this double-changelogs | and mail to lyx-devel is fastidious. Agree. btw. did we come to any consensus about my "Drop ChangeLogs" RFC? | Is it OK if I don't respect the | rule for simple patches? yes. | Or should I change my habits and commit only big changes? One change one commit is ok. But several commits as part of one logical change is not. -- Lgb
Question about Patch submission and commit
Hello, I have a tendency to commit very often... but this double-changelogs and mail to lyx-devel is fastidious. Is it OK if I don't respect the rule for simple patches? Or should I change my habits and commit only big changes? Abdel.
Line deletion OK with bug 1827 (Re: [Patch] change tracking bar in rowpainter)
On Mon, Mar 13, 2006 at 08:45:26AM +0100, Juergen Spitzmueller wrote: > Martin Vermeer wrote: > > So I propose to remove the line > > > > setChange(0, Change::INSERTED); > > But then you have to check if bug 1827 doesn't come back. > > Jürgen I have the line deleted, and bug 1827 (according to the description in the original bug posting) is still gone. I think the deletion is safe. OK to commit to trunk? - Martin pgpa8h26hbvTg.pgp Description: PGP signature
[Patch] Small QLPopupMenu cleanup
Index: D:/msys/home/yns/lyx/trunk/src/frontends/qt4/ChangeLog
===
--- D:/msys/home/yns/lyx/trunk/src/frontends/qt4/ChangeLog (revision 13371)
+++ D:/msys/home/yns/lyx/trunk/src/frontends/qt4/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2006-03-15 Abdelrazak Younes <[EMAIL PROTECTED]>
+
+ * QLPopupMenu.[Ch]: renamed topLevelMenu to topLevelMenu_
+
+2006-03-15 Abdelrazak Younes <[EMAIL PROTECTED]>
+
+ * QLMenubar.C: MACX menubar initialisation crash fix
+
2006-03-14 Abdelrazak Younes <[EMAIL PROTECTED]>
* QWorkArea.[Ch]: Wheel one-liner mouse fix
Index: D:/msys/home/yns/lyx/trunk/src/frontends/qt4/QLPopupMenu.C
===
--- D:/msys/home/yns/lyx/trunk/src/frontends/qt4/QLPopupMenu.C (revision 13371)
+++ D:/msys/home/yns/lyx/trunk/src/frontends/qt4/QLPopupMenu.C (working copy)
@@ -52,7 +52,7 @@
QLPopupMenu::QLPopupMenu(QLMenubar * owner,
MenuItem const & mi, bool
topLevelMenu)
- : owner_(owner), topLevelMenu_(topLevelMenu)
+ : owner_(owner)
{
name_ = mi.submenuname();
@@ -70,18 +70,18 @@
lyxerr[Debug::GUI] << "\tTriggered menu: " << name_ << endl;
clear();
- topLevelMenu.clear();
+ topLevelMenu_.clear();
if (name_.empty())
return;
Menu const & fromLyxMenu = owner_->backend().getMenu(name_);
- owner_->backend().expand(fromLyxMenu, topLevelMenu, owner_->view());
+ owner_->backend().expand(fromLyxMenu, topLevelMenu_, owner_->view());
- if (!owner_->backend().hasMenu(topLevelMenu.name())) {
- lyxerr[Debug::GUI] << "\tWARNING: menu seems empty" <<
topLevelMenu.name() << endl;
+ if (!owner_->backend().hasMenu(topLevelMenu_.name())) {
+ lyxerr[Debug::GUI] << "\tWARNING: menu seems empty" <<
topLevelMenu_.name() << endl;
}
- populate(this, &topLevelMenu);
+ populate(this, &topLevelMenu_);
specialMacXmenuHack();
}
Index: D:/msys/home/yns/lyx/trunk/src/frontends/qt4/QLPopupMenu.h
===
--- D:/msys/home/yns/lyx/trunk/src/frontends/qt4/QLPopupMenu.h (revision 13369)
+++ D:/msys/home/yns/lyx/trunk/src/frontends/qt4/QLPopupMenu.h (working copy)
@@ -56,14 +56,12 @@
/// \todo Mac specific binding handling.
void addBinding(std::string & label, MenuItem const & mi);
- bool topLevelMenu_;
-
- /// Mac specific menu hack
- /// \todo Fix it
- void specialMacXmenuHack();
-
/// Top Level Menu
- Menu topLevelMenu;
+ Menu topLevelMenu_;
+
+ /// Mac specific menu hack
+ /// \todo Fix it
+ void specialMacXmenuHack();
};
} // namespace frontend
[Patch] MACX QMenubar crash fix.
Oups, I comitted before creating the patch...
Is there a way to generate the generate a patch automatically when you
commit?
This patch is simple:
menubackend_.specialMenu("LyX");
// make sure that the special entries are added to the first
// menu even before this menu has been opened.
-name_map_[menubackend_.getMenubar().begin()->submenuname()]->update();
+//name_map_[menubackend_.getMenubar().begin()->submenuname()]->update();
#endif
Author: younes
Date: Wed Mar 15 12:12:52 2006
New Revision: 13376
Log:
QLMenubar.C: Fix potential MACX crash on menubar initialisation.
The MACX specific menubar hack present in qt2 frontend is still not
ported to the qt4 frontend.
Modified:
lyx-devel/trunk/src/frontends/qt4/QLMenubar.C
Re: [Patch] Qt4 wheel mouse + Q_WS_* macro
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> I guess our only hope is Bennett... How you guys did Abdelrazak> managed to complete the MAC port without any developer on Abdelrazak> board? Because of GUI-I, and because Qt/Mac does not work too badly. And also because Ronald Florence (the initiator of the port) was enough of a programmer to do it. But getting right the code in the qt2 frontend has been an amusing task (Bennett has been very patient to try out the various bogus ideas I came up with). JMarc
Re: [Patch] Qt4 wheel mouse + Q_WS_* macro
Jean-Marc Lasgouttes wrote: >> "Abdelrazak" == Abdelrazak Younes >> <[EMAIL PROTECTED]> writes: > > Abdelrazak> Hum, I don't know, did someone tested your changes on > Abdelrazak> qt2/X11/Mac? I would tend to think that the X11 clipboard > Abdelrazak> wouldn't need this change but I don't know really. > > I would assume that the X11 clipboard always uses LF, but I have no > way to check. Me neither. Therefore I went to the safe side and did the translation also for X11. This would only fail if X11 used CRLF, but that would be very awkward. Georg
Re: [Patch] Qt4 wheel mouse + Q_WS_* macro
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Hum, I don't know, did someone tested your changes on Abdelrazak> qt2/X11/Mac? I would tend to think that the X11 clipboard Abdelrazak> wouldn't need this change but I don't know really. I would assume that the X11 clipboard always uses LF, but I have no way to check. I guess our only hope is Bennett... How you guys did managed to complete the MAC port without any developer on board? Abdelrazak> The Qt4 documentation is misleading, only Q_OS_* are Abdelrazak> documented, not Q_WS_*. I have verified that Q_OS_X11 does Abdelrazak> not exist in qglobal.h, only Q_WS_X11; X11 is a window system, not an operating system. Tell that to Trolltech ;-) Abdelrazak> I thought it to be the same for MAC, hence the change. But Abdelrazak> Q_OS_MAC and Q_OS_MACX are defined: Abdelrazak> #if defined(Q_OS_DARWIN) # define Q_OS_MAC /* Q_OS_MAC is Abdelrazak> mostly for compatiblity, but also more clear */ # define Abdelrazak> Q_OS_MACX /* Q_OS_MACX is only for compatiblity.*/ #endif I guess Q_OS_MAC should be replaced with Q_OS_DARWIN, if we want to keep it. Yes. Abdel.
Re: Mysterious crash with a cygwin build
Enrico Forestieri <[EMAIL PROTECTED]> writes: > )) (C:\texmf\tex\latex\pgf\basiclayer\pgfcore.sty > (C:\texmf\tex\latex\graphics\ > graphicx.sty > Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR) > ... > Notice that the line ending in "(C:\texmf\tex\latex\graphics\" really > ends with a linebreak, such that graphicx.sty is not wrapped but it is > on the next line (I checked it editing with vim the file). > So, instead of "C:\texmf\tex\latex\graphics\graphicx.sty" the regexps > extract simply "C:\texmf\tex\latex\graphics\", upon which the crc > computation is tried, leading to a crash in cygwin. Great detective work, Enrico. Are all these ".sty" lines in the log file followed by "Package:"? Perhaps you could use that as the delimiter? > I'll try to come up with a patch to the LaTeX::deplog() function in > src/LaTeX.C. Way to go! Angus
Re: [Patch] Qt4 wheel mouse + Q_WS_* macro
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Hum, I don't know, did someone tested your changes on Abdelrazak> qt2/X11/Mac? I would tend to think that the X11 clipboard Abdelrazak> wouldn't need this change but I don't know really. I would assume that the X11 clipboard always uses LF, but I have no way to check. Abdelrazak> The Qt4 documentation is misleading, only Q_OS_* are Abdelrazak> documented, not Q_WS_*. I have verified that Q_OS_X11 does Abdelrazak> not exist in qglobal.h, only Q_WS_X11; X11 is a window system, not an operating system. Abdelrazak> I thought it to be the same for MAC, hence the change. But Abdelrazak> Q_OS_MAC and Q_OS_MACX are defined: Abdelrazak> #if defined(Q_OS_DARWIN) # define Q_OS_MAC /* Q_OS_MAC is Abdelrazak> mostly for compatiblity, but also more clear */ # define Abdelrazak> Q_OS_MACX /* Q_OS_MACX is only for compatiblity.*/ #endif I guess Q_OS_MAC should be replaced with Q_OS_DARWIN, if we want to keep it. JMarc
Re: LyX on Mac with Qt-4
Abdelrazak Younes a écrit : Bennett Helm a écrit : On Mar 11, 2006, at 4:26 AM, Abdelrazak Younes wrote: With current svn (revision 13371), after I comment out line 275, I can compile to the final linking stage, which then bombs for what I assume are the same reasons others have had problems compiling with gcc-4.0.1(2?). Hum, I am not at all confident in the Mac specific stuff in 'QLPopupMenu.C'. I had a crash myself when I '#define Q_WS_MACX'... ^^^ That's 'QLMenubar.C' not 'QLPopupMenu.C'! You could try to #undef Q_WS_MACX at the top of 'QLPopupMenu.C' or erase QLMenubar.C all the code inside the #ifdef and see if you still have the crash. In any case, a back trace and/or the output you get from '-dbg any' would be welcome. Thanks for testing, Abdel.
Re: LyX on Mac with Qt-4
Bennett Helm a écrit : On Mar 11, 2006, at 4:26 AM, Abdelrazak Younes wrote: With current svn (revision 13371), after I comment out line 275, I can compile to the final linking stage, which then bombs for what I assume are the same reasons others have had problems compiling with gcc-4.0.1(2?). Hum, I am not at all confident in the Mac specific stuff in 'QLPopupMenu.C'. I had a crash myself when I '#define Q_WS_MACX'... You could try to #undef Q_WS_MACX at the top of 'QLPopupMenu.C' or erase all the code inside the #ifdef and see if you still have the crash. In any case, a back trace and/or the output you get from '-dbg any' would be welcome. Thanks for testing, Abdel.
Re: make po fails on windows
Angus Leeming a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: Hello, Special question for Angus (or Michael), I never managed to compile the 'po' directory. Could this be something similar to 'configure.ac' which had dos-style line-ending? Thanks in advance, Abdel. D:\mingw\bin\make.exe[1]: Leaving directory `D:/msys/home/yns/lyx/trunk/intl' Making all in po FIND: Parameter format not correct I've never seen this before, but it looks to me as if you're invoking 'FIND' as if from a cmd prompt, rather than the *nix 'find' tool: FIND /? Searches for a text string in a file or files. I think it might be something else: [EMAIL PROTECTED] ~/lyx/trunk/po $ grep FIND Makefile* [EMAIL PROTECTED] ~/lyx/trunk/po $ grep find Makefile* Makefile:POTFILE_IN_DEPS = $(shell find $(top_srcdir)/src -name Makefile.am) Makefile: ../src/lyxfind.C \ Makefile:grep -l "_(\".*\")" `find src \( -name '*.[Cch]' -o -name '*.C.in' \) -print` |\ Makefile.in:POTFILE_IN_DEPS = $(shell find $(top_srcdir)/src -name Makefile.am) Makefile.in: grep -l "_(\".*\")" `find src \( -name '*.[Cch]' -o -name '*.C.in' \) -print` |\ Makefile.in.in:POTFILE_IN_DEPS = $(shell find $(top_srcdir)/src -name Makefile.am) Makefile.in.in: grep -l "_(\".*\")" `find src \( -name '*.[Cch]' -o -name '*.C.in' \) -print` |\ [EMAIL PROTECTED] ~/lyx/trunk/po $ find --version GNU find version 4.1 [EMAIL PROTECTED] ~/lyx/trunk/po $ FIND /? FIND: /?: No such file or directory Weird, isn't it? /V Displays all lines NOT containing the specified string. /C Displays only the count of lines containing the string. /N Displays line numbers with the displayed lines. /I Ignores the case of characters when searching for the string. /OFF[LINE] Do not skip files with offline attribute set. "string" Specifies the text string to find. [drive:][path]filename Specifies a file or files to search. If a path is not specified, FIND searches the text typed at the prompt or piped from another command.
Re: [Patch] Qt4 wheel mouse + Q_WS_* macro
Georg Baum a écrit : Abdel, the line end conversion in the clipboard used Q_OS_MACX on purpose. You changed that to Q_WS_MACX, meaning that it will not happen on X11/Mac. Are you sure that it is not needed there? If yes, we should also change the qt2 frontend, otherwise please change it back. Hum, I don't know, did someone tested your changes on qt2/X11/Mac? I would tend to think that the X11 clipboard wouldn't need this change but I don't know really. The Qt4 documentation is misleading, only Q_OS_* are documented, not Q_WS_*. I have verified that Q_OS_X11 does not exist in qglobal.h, only Q_WS_X11; I thought it to be the same for MAC, hence the change. But Q_OS_MAC and Q_OS_MACX are defined: #if defined(Q_OS_DARWIN) # define Q_OS_MAC /* Q_OS_MAC is mostly for compatiblity, but also more clear */ # define Q_OS_MACX /* Q_OS_MACX is only for compatiblity.*/ #endif So, in short, if you're sure about that, I'll happily revert the changes. Abdel. Georg
