Re: line endings again

[Georg Baum]

Abdelrazak Younes wrote:

 What does this mean in practice? Now that I use Xemacs will I see ^M at
 each end-of-line because I checkout from windows?

No, xemacs should handle that transparently. Use vim if it cannot do
that ;-)

 And why only the qt4 
 frontend?

Because the other files have it already.

 I have cleanup everything already and promised to use Xemacs, 
 wasn't that enough?

No, because it was not enforced. This does not mean that I don't trust you
to be careful, but it is very easy to mix up line endings accidentally
again, and you would not notice. Now you don't need to care at all anymore.

 I would to continue working with Unix-style line 
 ending.

You don't need to do that anymore. xemacs should handle both styles, and any
dumb editor will simply use windows style.


Georg

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Martin Vermeer]

On Tue, 2006-03-21 at 22:23 +0100, Georg Baum wrote:

...

 What do you think?
 
 
 Georg

Looks good... but I don't understand this

Index: src/Color.C
===
--- src/Color.C (Revision 13447)
+++ src/Color.C (Arbeitskopie)

Is this a peculiarity of svn diff? I understand you moved and modified
this file from the one in src/frontends/xforms/, right?

- Martin



signature.asc
Description: This is a digitally signed message part

[Patch in parent] Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Martin Vermeer]

On Tue, 2006-03-21 at 18:29 +0200, Martin Vermeer wrote:
 On Tue, 2006-03-21 at 18:14 +0200, Martin Vermeer wrote:

...

 Here's the patch. Trivial (Georg, how did we overlook this?)
 
 OK to put into both trunk and 1.4?
 
 - Martin

Committed to trunk:

* math_gridinset.C (MathGridInset::doDispatch): reset cur.pos() when
deleting current col or row

- Martin



signature.asc
Description: This is a digitally signed message part

LyX 1.5 crash while scrolling

[Juergen Spitzmueller]

1. Load the UserGuide
2. Scroll

= LyX crashes. Not reproducible with 1.4

(preview-latex is disabled)

Jürgen

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1086936672 (LWP 26996)]
lyx::graphics::CacheItem::status (this=0x7) at scoped_ptr.hpp:94
94  BOOST_ASSERT(ptr != 0);

(gdb) bt
#0  lyx::graphics::CacheItem::status (this=0x7) at scoped_ptr.hpp:94
#1  0x08499008 in lyx::graphics::Loader::Impl::statusChanged (this=0x8964860)
at GraphicsLoader.C:260
#2  0x0849a609 in 
boost::detail::function::void_function_obj_invoker0boost::_bi::bind_tvoid, 
boost::_mfi::mf0void, lyx::graphics::Loader::Impl, 
boost::_bi::list1boost::_bi::valuelyx::graphics::Loader::Impl*  , 
void::invoke (function_obj_ptr=
  {obj_ptr = 0x88a99b8, const_obj_ptr = 0x88a99b8, func_ptr = 0x88a99b8, 
data = })
at mem_fn_template.hpp:45
#3  0x0807988a in boost::function0void, std::allocatorvoid ::operator() 
(this=0x8965c34)
at function_template.hpp:576
#4  0x080798c8 in 
boost::operator++boost::signals::detail::slot_call_iteratorboost::signals::detail::call_bound0void::callerboost::functionvoid
 
()(), std::allocatorvoid  , 
boost::signals::detail::named_slot_map_iterator, 
boost::signals::detail::unusable, boost::single_pass_traversal_tag, 
boost::signals::detail::unusable const, int ([EMAIL PROTECTED]) at 
signal_template.hpp:119
#5  0x08079cf7 in boost::signal0void, boost::last_valuevoid, int, 
std::lessint, boost::functionvoid ()(), std::allocatorvoid  
::operator() (this=0x89658a8) at last_value.hpp:43
#6  0x0848ff12 in lyx::graphics::CacheItem::Impl::setStatus (this=0x8965878,
new_status=lyx::graphics::Converting) at GraphicsCacheItem.C:256
#7  0x08490534 in lyx::graphics::CacheItem::Impl::convertToDisplayFormat 
(this=0x8965878)
at GraphicsCacheItem.C:378
#8  0x084913cf in lyx::graphics::CacheItem::Impl::startLoading 
(this=0x8965878)
at GraphicsCacheItem.C:218
#9  0x0849140a in lyx::graphics::CacheItem::startLoading (this=0x88a8d48)
at GraphicsCacheItem.C:156
#10 0x0849becb in lyx::graphics::LoaderQueue::loadNext (this=0x86858e0) at 
LoaderQueue.C:48
---Type return to continue, or q return to quit---
#11 0x0849d061 in 
boost::detail::function::void_function_obj_invoker0boost::_bi::bind_tvoid, 
boost::_mfi::mf0void, lyx::graphics::LoaderQueue, 
boost::_bi::list1boost::_bi::valuelyx::graphics::LoaderQueue*  , 
void::invoke (function_obj_ptr=
  {obj_ptr = 0x87d0280, const_obj_ptr = 0x87d0280, func_ptr = 0x87d0280, 
data = \200})
at mem_fn_template.hpp:45
#12 0x0807988a in boost::function0void, std::allocatorvoid ::operator() 
(this=0x87d026c)
at function_template.hpp:576
#13 0x080798c8 in 
boost::operator++boost::signals::detail::slot_call_iteratorboost::signals::detail::call_bound0void::callerboost::functionvoid
 
()(), std::allocatorvoid  , 
boost::signals::detail::named_slot_map_iterator, 
boost::signals::detail::unusable, boost::single_pass_traversal_tag, 
boost::signals::detail::unusable const, int ([EMAIL PROTECTED]) at 
signal_template.hpp:119
#14 0x08079cf7 in boost::signal0void, boost::last_valuevoid, int, 
std::lessint, boost::functionvoid ()(), std::allocatorvoid  
::operator() (this=0x8685928) at last_value.hpp:43
#15 0x083093bd in Timeout::emit (this=0x8685928) at Timeout.C:51
#16 0x08313b1b in qtTimeout::timerEvent (this=0x87d0188) at Timeout.h:72
#17 0x4028c852 in QObject::event () from /usr/lib/qt3/lib/libqt-mt.so.3
#18 0x4022cd41 in QApplication::internalNotify () 
from /usr/lib/qt3/lib/libqt-mt.so.3
#19 0x4022d6b9 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3
#20 0x40221ab8 in QEventLoop::activateTimers () 
from /usr/lib/qt3/lib/libqt-mt.so.3
#21 0x401daf4f in QEventLoop::processEvents () 
from /usr/lib/qt3/lib/libqt-mt.so.3
#22 0x40243c39 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3
#23 0x40243b36 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#24 0x4022c68f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#25 0x08373eeb in lyx_gui::start ([EMAIL PROTECTED], [EMAIL PROTECTED]) at 
lyx_gui.C:248
#26 0x08149563 in LyX::priv_exec (this=0x86bd6c8, [EMAIL PROTECTED], 
argv=0xbfe3a134)

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Jean-Marc Lasgouttes]

 Martin == Martin Vermeer [EMAIL PROTECTED] writes:

Martin Here's the patch. Trivial (Georg, how did we overlook this?)

Martin OK to put into both trunk and 1.4?

OK for 1.4.

JMarc

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Georg Baum]

Martin Vermeer wrote:

 Looks good... but I don't understand this
 
 Index: src/Color.C
 ===
 --- src/Color.C (Revision 13447)
 +++ src/Color.C (Arbeitskopie)
 
 Is this a peculiarity of svn diff?

Yes.

 I understand you moved and modified 
 this file from the one in src/frontends/xforms/, right?

Exactly. Therefore the patch won't apply as-is, but you can see the
differences from the original file


Georg

Re: line endings again

[Abdelrazak Younes]

OK, thanks for the clarification.

Abdel.

Georg Baum a écrit :

Abdelrazak Younes wrote:


What does this mean in practice? Now that I use Xemacs will I see ^M at
each end-of-line because I checkout from windows?


No, xemacs should handle that transparently. Use vim if it cannot do
that ;-)

And why only the qt4 
frontend?


Because the other files have it already.

I have cleanup everything already and promised to use Xemacs, 
wasn't that enough?


No, because it was not enforced. This does not mean that I don't trust you
to be careful, but it is very easy to mix up line endings accidentally
again, and you would not notice. Now you don't need to care at all anymore.

I would to continue working with Unix-style line 
ending.


You don't need to do that anymore. xemacs should handle both styles, and any
dumb editor will simply use windows style.


Georg

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Abdelrazak Younes]

Angus Leeming a écrit :

Abdelrazak Younes [EMAIL PROTECTED] writes:
The patch looks good but I am wondering if this solution is not a bit 
too complicated. Why not just define some const string in hexa and let 
the frontend take care of the rest?


Just for clarification, this would mean replacing x11name by this RGB 
value in ColorEntry:



class ColorEntry {
ColorEntry(
string rgb_hexa = #00,
string const guiname_ = ,
string const latexname_ = ,
string const lyxname_ = );


Georg's solution may look complicated, but it's just a refactoring of existing,
working code. A real RGBColor class has real advantages, not least being type
safe. We (you :)) should strive to remove kludges, not add to them!

Further, a real Color lends itself to easy manipulation; the fact that we have
to separately define the colours of inset button and borders is a real ugliness!


Note that we could add optional hsv offset members to ColorEntry and let 
QColor in the case of Qt do the manipulation. The idea is that Qt will 
do color manipulation anyway so why doing it twice at difference 
location? At the end, what's on sreen is what Qt shows, isn't it?
This pseudo code will summarize my idea. The advantage of it is that you 
can for example authorize the manipulation of the button background but 
all other button related colors would be set automatically.


class ColorEntry {
ColorEntry(
string rgb_hexa = #00,
string const guiname_ = ,
string const latexname_ = ,
string const lyxname_ = ,
int h_offset = 0,
int s_offset = 0,
int v_offset = 0);

string const  get_rbg() const;
void set_rbg(string const  rgb_hexa);
void const  get_hsv_offset(int  ho, int  so, int  vo) const;

private:
string rgb_;
int const h_offset_;
int const s_offset_;
int const v_offset_;
string const guiname_;
string const latexname_;
string const lyxname_;
};

class LQColor: public QColor
{
LQColor(ColorEntry const ce): QColor(ce.get_rbg()) {
if (ce.h_offset != 0
|| ce.s_offset != 0
|| ce.v_offset != 0) {

convertTo(QColor::Hsv);
int h, s, v, ho, so, vo;
getHsv(h,s,v);
ce.get_hsv_offset(ho,so,vo);
setHsv((h += ho), (s += so), (v += so));
}
}

What do you think?


À demain!


A+
Abdel.

PS: A+ means A plus tard or See you later


Angus

[PATCH] better support for classes that do not define a ToC

[Jean-Marc Lasgouttes]

This patch (against 1.4.1svn) tries to handle better classes where no
ToC structure is defined. This is useful when old textclasses give
errors (this was the original motivation, see bug 2410), but also for
classes without a ToC, like cv.

What it does is trivial: (1) do not update or use secnumdepth and tocdepth
when there is no ToC and (2) disable the corresponding UI elements.

The gtk part is not done, but it is trivial.

Comments? I'd like to apply it for 1.4.1. Then of course we'll have to
fix the actual problem.

JMarc

Index: src/ChangeLog
===
--- src/ChangeLog	(revision 13450)
+++ src/ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2006-03-22  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
+
+	* lyxtextclass.C (hasTocLevels): new method.
+
+	* bufferparams.C (useClassDefaults, writeLaTeX): skip secnumdepth
+	and tocdepth if the class does not define a ToC structure.
+
 2006-03-16  Jürgen Spitzmüller  [EMAIL PROTECTED]
 
 	* text.C (delete): adjust cursor after backspace in change tracking
Index: src/bufferparams.C
===
--- src/bufferparams.C	(revision 13450)
+++ src/bufferparams.C	(working copy)
@@ -915,17 +915,20 @@ bool BufferParams::writeLaTeX(ostream  
 		texrow.newline();
 	}
 
-	if (secnumdepth != tclass.secnumdepth()) {
-		os  \\setcounter{secnumdepth}{
-		secnumdepth
-		}\n;
-		texrow.newline();
-	}
-	if (tocdepth != tclass.tocdepth()) {
-		os  \\setcounter{tocdepth}{
-		tocdepth
-		}\n;
-		texrow.newline();
+	// Only if class has a ToC hierarchy
+	if (tclass.hasTocLevels()) {
+		if (secnumdepth != tclass.secnumdepth()) {
+			os  \\setcounter{secnumdepth}{
+			secnumdepth
+			}\n;
+			texrow.newline();
+		}
+		if (tocdepth != tclass.tocdepth()) {
+			os  \\setcounter{tocdepth}{
+			tocdepth
+			}\n;
+			texrow.newline();
+		}
 	}
 
 	if (paragraph_separation) {
@@ -1068,8 +1071,11 @@ void BufferParams::useClassDefaults()
 	columns = tclass.columns();
 	pagestyle = tclass.pagestyle();
 	options = tclass.options();
-	secnumdepth = tclass.secnumdepth();
-	tocdepth = tclass.tocdepth();
+	// Only if class has a ToC hierarchy
+	if (tclass.hasTocLevels()) {
+		secnumdepth = tclass.secnumdepth();
+		tocdepth = tclass.tocdepth();
+	}
 }
 
 
Index: src/frontends/qt2/ChangeLog
===
--- src/frontends/qt2/ChangeLog	(revision 13450)
+++ src/frontends/qt2/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2006-03-22  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
+
+	* QDocument.C (apply): skip secnumdepth and tocdepth if the class
+	does not define a ToC structure.
+	(update_contents): cleanup and use LyXTextClass::hasTocLevels.
+
 2006-03-20  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
 
 	* QWorkArea.C (QWorkArea): do not paint background (bug 2197).
Index: src/frontends/qt2/QDocument.C
===
--- src/frontends/qt2/QDocument.C	(revision 13450)
+++ src/frontends/qt2/QDocument.C	(working copy)
@@ -267,8 +267,10 @@ void QDocument::apply()
 	params.language = languages.getLanguage(lang_[pos]);
 
 	// numbering
-	params.tocdepth = dialog_-numberingModule-tocSL-value();
-	params.secnumdepth = dialog_-numberingModule-depthSL-value();
+	if (params.getLyXTextClass().hasTocLevels()) {
+		params.tocdepth = dialog_-numberingModule-tocSL-value();
+		params.secnumdepth = dialog_-numberingModule-depthSL-value();
+	}
 
 	// bullets
 	params.user_defined_bullet(0) = dialog_-bulletsModule-getBullet(0);
@@ -506,19 +508,19 @@ void QDocument::update_contents()
 	// numbering
 	int const min_toclevel = controller().textClass().min_toclevel();
 	int const max_toclevel = controller().textClass().max_toclevel();
-	if (min_toclevel != LyXLayout::NOT_IN_TOC)
+	if (controller().textClass().hasTocLevels()) {
 		dialog_-numberingModule-setEnabled(true);
-	else {
+		dialog_-numberingModule-depthSL-setMinValue(min_toclevel - 1);
+		dialog_-numberingModule-depthSL-setMaxValue(max_toclevel);
+		dialog_-numberingModule-depthSL-setValue(params.secnumdepth);
+		dialog_-numberingModule-tocSL-setMinValue(min_toclevel - 1);
+		dialog_-numberingModule-tocSL-setMaxValue(max_toclevel);
+		dialog_-numberingModule-tocSL-setValue(params.tocdepth);
+		dialog_-updateNumbering();
+	} else {
 		dialog_-numberingModule-setEnabled(false);
 		dialog_-numberingModule-tocLV-clear();
 	}
-	dialog_-numberingModule-depthSL-setMinValue(min_toclevel - 1);
-	dialog_-numberingModule-depthSL-setMaxValue(max_toclevel);
-	dialog_-numberingModule-depthSL-setValue(params.secnumdepth);
-	dialog_-numberingModule-tocSL-setMinValue(min_toclevel - 1);
-	dialog_-numberingModule-tocSL-setMaxValue(max_toclevel);
-	dialog_-numberingModule-tocSL-setValue(params.tocdepth);
-	dialog_-updateNumbering();
 
 	// bullets
 	dialog_-bulletsModule-setBullet(0,params.user_defined_bullet(0));
Index: src/frontends/xforms/FormDocument.C

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Abdelrazak Younes]

Small rectification, the offsets are private so the previous code won't 
work. But pseudo-code are not meant to work, are they? :-)


class LQColor: public QColor
{
 LQColor(ColorEntry const ce): QColor(ce.get_rbg()) {
 int ho, so, vo;
 ce.get_hsv_offset(ho,so,vo);
 if (ho != 0 || so != 0 || vo != 0) {
 convertTo(QColor::Hsv);
 int h, s, v;
 getHsv(h,s,v);
 setHsv((h += ho), (s += so), (v += so));
}
}

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Angus Leeming]

Abdelrazak Younes [EMAIL PROTECTED] writes:
 Note that we could add optional hsv offset members to ColorEntry and let 
 QColor in the case of Qt do the manipulation. The idea is that Qt will 
 do color manipulation anyway so why doing it twice at difference 
 location? At the end, what's on sreen is what Qt shows, isn't it?

I'm not going to fight about this as I'm not going to write the code, but it
seems to me that the code to do all this elegantly exists already, is tested and
is known to work. All Georg is doing is moving it out of the XForms directory.

I'll let you two continue the debate.

 What do you think?

I prefer OO code for stuff that fits elegantly into the concept of object.

Angus

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Abdelrazak Younes]

Angus Leeming a écrit :

Abdelrazak Younes [EMAIL PROTECTED] writes:
Note that we could add optional hsv offset members to ColorEntry and let 
QColor in the case of Qt do the manipulation. The idea is that Qt will 
do color manipulation anyway so why doing it twice at difference 
location? At the end, what's on sreen is what Qt shows, isn't it?


I'm not going to fight about this as I'm not going to write the code, but it
seems to me that the code to do all this elegantly exists already, is tested and
is known to work. All Georg is doing is moving it out of the XForms directory.


I am  not trying to fight. I was just trying to have an interesting 
discussion ;-)



I'll let you two continue the debate.


Georg will make up his mind and do what he thinks right. I am a firm 
believer that he who do the job should decide at the end.



What do you think?


I prefer OO code for stuff that fits elegantly into the concept of object.


Hum... so colors are not object for you?

Just kidding, we can stop the debate here.
Abdel.

[PATCH] update vs repaint

[Jean-Marc Lasgouttes]

There was a consensus that this patch is the right thing to do, even
though it might not speed things up per se. I tested it and propose to
apply to trunk and branch.

OK?

JMarc

Index: src/frontends/qt2/qscreen.C
===
--- src/frontends/qt2/qscreen.C	(revision 13433)
+++ src/frontends/qt2/qscreen.C	(working copy)
@@ -144,7 +144,7 @@ void QScreen::showCursor(int x, int y, i
 		break;
 	}
 
-	owner_.getContent()-repaint(
+	owner_.getContent()-update(
 		cursor_x_, cursor_y_,
 		cursor_w_, cursor_h_);
 }
@@ -160,5 +160,5 @@ void QScreen::removeCursor()
 	   nocursor_pixmap_, 0, 0, cursor_w_, cursor_h_);
 
 	owner_.getContent()
-		-repaint(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
+		-update(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
 }

Re: [PATCH] update vs repaint

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

There was a consensus that this patch is the right thing to do, even
though it might not speed things up per se. I tested it and propose to
apply to trunk and branch.

OK?


Alleluia!
:-)

Re: [Ãpatch] RandomAccessList take 4

[Juergen Spitzmueller]

Georg Baum wrote:
 This patch compiles for 1.4

Yes. Compiles, runs and feels good.
What specifically should we test for (I notice that scrolling the UserGuide is 
quite fluently, as long as no graphics or previews are involved [1]).

Jürgen

[1] It appears to me that in 1.3, the graphics and previews weren't loaded 
immediately, so that they didn't block scrolling. 

Re: [Ãpatch] RandomAccessList take 4

[Abdelrazak Younes]

Juergen Spitzmueller a écrit :

Georg Baum wrote:

This patch compiles for 1.4


Yes. Compiles, runs and feels good.
What specifically should we test for


Paragraph insertion/deletion (especially around graphics), Undo/Redo, 
CutPaste inside/outside insets, export*, navigate.
Navigating when the lyx file and graphics are not local (i.e in the 
network) is the ultimate test.


(I notice that scrolling the UserGuide is 
quite fluently, as long as no graphics or previews are involved [1]).


You mean it is better or slower than without the patch?

Abdel.

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Georg Baum]

Angus Leeming wrote:

 Abdelrazak Younes [EMAIL PROTECTED] writes:
  The patch looks good but I am wondering if this solution is not a bit
  too complicated. Why not just define some const string in hexa and let
  the frontend take care of the rest?

What would we gain? Not much IMHO. Whether a color name is given in
#rrggbb notation, or as a real name linen, does not matter IMHO,
because in both cases the frontend will resolve it to an rgb value, and to
users of ColorEntry it is just a string.

 Just for clarification, this would mean replacing x11name by this RGB
 value in ColorEntry:
 
 class ColorEntry {
 ColorEntry(
 string rgb_hexa = #00,
 string const guiname_ = ,
 string const latexname_ = ,
 string const lyxname_ = );

I agree that we should get rid of x11name, because it is not so useful
anymore, but I would rather replace it by something like RGBColor (or maybe
merge RGBColor with ColorEntry). Anyway, this is for later and unrelated to
the branch change.

 Georg's solution may look complicated, but it's just a refactoring of
 existing, working code.

Yes. It would be a pity to ditch this code together with the xforms frontend
if it is useful somewhere else.
I think I am going to apply the patch this evening (will send Changelog
then, too).

 A real RGBColor class has real advantages, not 
 least being type safe. We (you :)) should strive to remove kludges, not
 add to them!
 
 Further, a real Color lends itself to easy manipulation; the fact that we
 have to separately define the colours of inset button and borders is a
 real ugliness!

This is something that can come later. For now, I am only interested in
making the color handling of branches easier/more robust.
At a later point we could think of making branches using a LColor instead of
RGBColor. That would mean that we either add a new LColor for every user
defined color, or a special general purpose color that has no name but
rgb values. I am not sure yet what would be best, but we are not in a
hurry: 1.4.x bugs are waiting!


Georg

Re: [Ãpatch] RandomAccessList take 4

[Juergen Spitzmueller]

Abdelrazak Younes wrote:
  (I notice that scrolling the UserGuide is
  quite fluently, as long as no graphics or previews are involved [1]).

 You mean it is better or slower than without the patch?

No, it's completely unrelated. I just noticed it while testing the patch.

Jürgen

Compile/link problem (lyx-1.5.0svn)

[Kayvan A. Sylvan]

My automated builds are still not happening. The link is failing
with multiple definition of (anonymous namespace)... messages.

Here are some representative messages.

 === Building QT LyX ===
 [...]
 
 Configuration
   Host type:  x86_64-unknown-linux-gnu
   Special build flags:compression aiksaurus assertions pch 
 concept-checks stdlib-debug warnings  use-aspell use-ispell
   C   Compiler:   gcc 
   C   Compiler LyX flags:  
   C   Compiler flags: -Wextra -Wall-I/usr/X11R6/include -O2
   C++ Compiler:   g++ (4.0.2)
   C++ Compiler LyX flags:  
   C++ Compiler flags: -Wextra -Wall-I/usr/X11R6/include -O2
   Linker flags:   
   Linker user flags:  
   Qt Frontend:
   Qt version: 3.3.4
   Packaging:  posix
   LyX binary dir: /usr/local/bin
   LyX files dir:  /usr/local/share/lyx
 
 Configuration of LyX was successful.
 [...]
 if g++ -DHAVE_CONFIG_H -I. -I. -I.  -Winvalid-pch --include=./pch.h 
 -I../boost -Wextra -Wall-I/usr/X11R6/include  -O2 -MT version.o -MD -MP 
 -MF .deps/version.Tpo -c -o version.o version.C; \
 then mv -f .deps/version.Tpo .deps/version.Po; else rm -f 
 .deps/version.Tpo; exit 1; fi
 if g++ -DHAVE_CONFIG_H -I. -I. -I.  -Winvalid-pch --include=./pch.h 
 -I../boost -Wextra -Wall-I/usr/X11R6/include  -O2 -MT vspace.o -MD -MP 
 -MF .deps/vspace.Tpo -c -o vspace.o vspace.C; \
 then mv -f .deps/vspace.Tpo .deps/vspace.Po; else rm -f 
 .deps/vspace.Tpo; exit 1; fi
 /bin/sh ../libtool --tag=CXX --mode=link g++  -O2   -o lyx-qt  main.o Bidi.o 
 BufferView.o BufferView_pimpl.o Bullet.o BranchList.o Chktex.o CutAndPaste.o 
 DepTable.o FloatList.o Floating.o FontIterator.o FuncStatus.o InsetList.o 
 LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o 
 ParagraphParameters.o PrinterParams.o Spacing.o Thesaurus.o ToolbarBackend.o 
 author.o boost.o box.o buffer.o buffer_funcs.o bufferlist.o bufferparams.o 
 bufferview_funcs.o changes.o chset.o converter.o counters.o coordcache.o 
 cursor.o cursor_slice.o debug.o dimension.o dociterator.o encoding.o 
 errorlist.o exporter.o gettext.o factory.o format.o funcrequest.o graph.o 
 importer.o intl.o insetiterator.o kbmap.o kbsequence.o language.o lastfiles.o 
 lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxfont.o lyxfind.o lyxfunc.o 
 lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxlex_pimpl.o lyxrc.o 
 lyxrow.o lyxrow_funcs.o lyxserver.o lyxsocket.o lyxtextclass.o 
 lyxtextclasslist.o lyxvc.o messages.o metricsinfo.o mover.o output.o 
 outputparams.o output_docbook.o output_latex.o output_linuxdoc.o 
 output_plaintext.o paragraph.o paragraph_funcs.o paragraph_pimpl.o 
 pariterator.o aspell.o  ispell.o SpellBase.o rowpainter.o sgml.o tabular.o 
 tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o 
 trans_mgr.o undo.o vc-backend.o version.o vspace.o mathed/libmathed.la 
 insets/libinsets.la frontends/libfrontends.la frontends/qt2/libqt2.la 
 frontends/controllers/libcontrollers.la graphics/libgraphics.la 
 support/libsupport.la ../boost/libs/regex/src/libboost_regex.la 
 ../boost/libs/signals/src/libboost_signals.la 
 ../boost/libs/filesystem/src/libboost_filesystem.la  -lAiksaurus -laspell  
 -lSM -lICE -lc -lm   -L/usr/X11R6/lib64 -lX11  -lz  
 mkdir .libs
 g++ -O2 -o lyx-qt main.o Bidi.o BufferView.o BufferView_pimpl.o Bullet.o 
 BranchList.o Chktex.o CutAndPaste.o DepTable.o FloatList.o Floating.o 
 FontIterator.o FuncStatus.o InsetList.o LColor.o LaTeX.o LaTeXFeatures.o 
 LyXAction.o MenuBackend.o ParagraphParameters.o PrinterParams.o Spacing.o 
 Thesaurus.o ToolbarBackend.o author.o boost.o box.o buffer.o buffer_funcs.o 
 bufferlist.o bufferparams.o bufferview_funcs.o changes.o chset.o converter.o 
 counters.o coordcache.o cursor.o cursor_slice.o debug.o dimension.o 
 dociterator.o encoding.o errorlist.o exporter.o gettext.o factory.o format.o 
 funcrequest.o graph.o importer.o intl.o insetiterator.o kbmap.o kbsequence.o 
 language.o lastfiles.o lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxfont.o 
 lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o 
 lyxlex_pimpl.o lyxrc.o lyxrow.o lyxrow_funcs.o lyxserver.o lyxsocket.o 
 lyxtextclass.o lyxtextclasslist.o lyxvc.o messages.o metricsinfo.o mover.o 
 output.o outputparams.o output_docbook.o output_latex.o output_linuxdoc.o 
 output_plaintext.o paragraph.o paragraph_funcs.o paragraph_pimpl.o 
 pariterator.o aspell.o ispell.o SpellBase.o rowpainter.o sgml.o tabular.o 
 tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o 
 trans_mgr.o undo.o vc-backend.o version.o vspace.o  mathed/.libs/libmathed.a 
 insets/.libs/libinsets.a frontends/.libs/libfrontends.a 
 frontends/qt2/.libs/libqt2.a -L/usr/lib64/qt-3.3/lib -lqt-mt 
 frontends/controllers/.libs/libcontrollers.a graphics/.libs/libgraphics.a 
 

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Abdelrazak Younes]

Georg Baum a écrit :

Angus Leeming wrote:


Abdelrazak Younes [EMAIL PROTECTED] writes:

The patch looks good but I am wondering if this solution is not a bit
too complicated. Why not just define some const string in hexa and let
the frontend take care of the rest?


What would we gain? Not much IMHO. Whether a color name is given in
#rrggbb notation, or as a real name linen, does not matter IMHO,
because in both cases the frontend will resolve it to an rgb value, and to
users of ColorEntry it is just a string.


Actually I prefer the 3 ints solution but I thought this would 
complicate the lyx and latex file writings.



I agree that we should get rid of x11name, because it is not so useful
anymore, but I would rather replace it by something like RGBColor (or maybe
merge RGBColor with ColorEntry). Anyway, this is for later and unrelated to
the branch change.


OK


Yes. It would be a pity to ditch this code together with the xforms frontend
if it is useful somewhere else.


That was my point, I doing thing it provide much compared to QColor and 
I am sure there is a Gtk equivalent.



I think I am going to apply the patch this evening (will send Changelog
then, too).


Good. We'll probably have to come back to this later.

Thanks,
Abdel.

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Abdelrazak Younes]

Abdelrazak Younes a écrit :
Yes. It would be a pity to ditch this code together with the xforms 
frontend

if it is useful somewhere else.


That was my point, I doing thing it provide much compared to QColor and 


Err, I don't think.

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Georg Baum]

Abdelrazak Younes wrote:

 Actually I prefer the 3 ints solution but I thought this would
 complicate the lyx and latex file writings.

I don't understand. lyxname and latexname are used for lyx and latex file
writing, x11name has nothing to do with that.

 That was my point, I doing thing it provide much compared to QColor and
 I am sure there is a Gtk equivalent.

Yes, Gdk::Color IIRC, but how could these be used outside of the specific
frontend? I know only one way (ditch all frontends but one and give up the
frontend-core separation), but proposing that would generate heated
discussions that I'd like to avoid by all means.


Georg

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Martin Vermeer]

On Wed, Mar 22, 2006 at 11:44:09AM +0100, Jean-Marc Lasgouttes wrote:
  Martin == Martin Vermeer [EMAIL PROTECTED] writes:
 
 Martin Here's the patch. Trivial (Georg, how did we overlook this?)
 
 Martin OK to put into both trunk and 1.4?
 
 OK for 1.4.
 
 JMarc

It is in... unfortunately the change to status.14x went in first :-(

Playing around with esvn... looks quite nice.

- Martin



pgpp8nOrSEMw8.pgp
Description: PGP signature

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Jean-Marc Lasgouttes]

 Martin == Martin Vermeer [EMAIL PROTECTED] writes:

Martin It is in... unfortunately the change to status.14x went in
Martin first :-(

Thanks.

JMarc

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Abdelrazak Younes]

Georg Baum a écrit :

Abdelrazak Younes wrote:


Actually I prefer the 3 ints solution but I thought this would
complicate the lyx and latex file writings.


I don't understand. lyxname and latexname are used for lyx and latex file
writing, x11name has nothing to do with that.


My (stupid) mistake. My mind is mixed up by lyx file format and latex 
file format using #f like string AFAIK. Nothing to do with branch 
and GUI colorization.



That was my point, I doing thing it provide much compared to QColor and
I am sure there is a Gtk equivalent.


Yes, Gdk::Color IIRC, but how could these be used outside of the specific
frontend? I know only one way (ditch all frontends but one and give up the
frontend-core separation), but proposing that would generate heated
discussions that I'd like to avoid by all means.


My point is that you shouldn't need to manipulate Colors outside the 
frontend. But I am maybe missing something.


Forget about it.

Abdel.

Crash during acrolling with arrow-down

[Bo Peng]

Dear list,

I can not reproduce this crash. It happens when I use down arrow key
to navigate an article.

The assertion is:

% break on pointer: 0x8dcbe38 hint: xy size: 259
Assertion triggered in void lyxbreaker(const void*, const char*, int)
by failing check false in file coordcache.C:30

This happens with the r13450 on RHEL4. Hope this helps.
Bo

Re: LyX/Mac bundle changes

[Bennett Helm]

On Mar 20, 2006, at 6:29 AM, Jean-Marc Lasgouttes wrote:


Bennett == Bennett Helm [EMAIL PROTECTED] writes:


Bennett (Note my question in the other thread
Bennett http://www.mail-archive.com/
Bennett lyx-devel@lists.lyx.org/msg86805.html: should the source for
Bennett this (as an XCode project) go into the LyX source? I'd be
Bennett happier if others more knowledgeable than I reviewed it. ...
Bennett Sorry if I shouldn't have created a new thread for this)

Did I ever answer?


(No.)


I think the source would be better in the source, and that automatic
building would be even better. You can maybe find someone
knowledgeable enough to do it...


The source can be found here: http://wiki.lyx.org/uploads/LyX/MacOSX/ 
lyx-metadata-source.zip.


Bennett

gtk frontend and gcc 4.1

[Ling Li]

Hi, it seems that this small patch is needed to compile gtk
frontend with gcc 4.1 (on fedora core 5).

--Ling
diff -ur lyx-1.4.0/src/frontends/gtk/GCharacter.h 
lyx-1.4.0/src/frontends/gtk/GCharacter.h
--- lyx-1.4.0/src/frontends/gtk/GCharacter.h2004-10-10 08:10:37.0 
-0700
+++ lyx-1.4.0/src/frontends/gtk/GCharacter.h2006-03-22 09:08:27.0 
-0800
@@ -65,7 +65,7 @@
 
Gtk::CheckButton * toggleallcheck_;
 
-   void GCharacter::onChange();
+   void onChange();
 };
 
 } // namespace frontend
diff -ur lyx-1.4.0/src/frontends/gtk/GtkLengthEntry.h 
lyx-1.4.0/src/frontends/gtk/GtkLengthEntry.h
--- lyx-1.4.0/src/frontends/gtk/GtkLengthEntry.h2006-02-06 
14:51:24.0 -0800
+++ lyx-1.4.0/src/frontends/gtk/GtkLengthEntry.h2006-03-22 
09:03:38.0 -0800
@@ -27,7 +27,7 @@
 
 class GtkLengthEntry : public Gtk::HBox {
 public:
-   GtkLengthEntry::GtkLengthEntry(BaseObjectType* cobject, const 
Glib::RefPtrGnome::Glade::Xml refGlade);
+   GtkLengthEntry(BaseObjectType* cobject, const 
Glib::RefPtrGnome::Glade::Xml refGlade);
 
void set_length(LyXLength const  length);
void set_length(std::string const  length);

Re: LyX 1.5 crash while scrolling

[Georg Baum]

Am Mittwoch, 22. März 2006 11:24 schrieb Juergen Spitzmueller:
 1. Load the UserGuide
 2. Scroll
 
 = LyX crashes. Not reproducible with 1.4

This smells like a boost thing. Does it happen also if you compile against 
system boost? Do you have that at all? Or maybe with the boost directory 
of 1.4?


Georg

Re: [PATCH] better support for classes that do not define a ToC

[Georg Baum]

Am Mittwoch, 22. März 2006 15:39 schrieb Jean-Marc Lasgouttes:
 
 Comments? I'd like to apply it for 1.4.1. Then of course we'll have to
 fix the actual problem.

I think you should put that in. Even if we are going to fix the xurrent 
problems it will LyX make more robust wrt incomoplete layout files, which 
is a Good Thing (TM).


Georg

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Georg Baum]

Am Mittwoch, 22. März 2006 18:10 schrieb Martin Vermeer:

 Playing around with esvn... looks quite nice.

Does it work now? I researched several svn GUIS when we switched to svn at 
work, but back then (end of 2004 IIRC) none was usable (esvn kept 
crashing).


Georg

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Georg Baum]

Am Mittwoch, 22. März 2006 18:47 schrieb Abdelrazak Younes:

 My point is that you shouldn't need to manipulate Colors outside the 
 frontend. But I am maybe missing something.

That might well be the case (I am not sure actually). If that is really 
true we can still reduce RGBColor to just three ints when we ditch 
xforms.


Georg

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Martin Vermeer]

On Wed, Mar 22, 2006 at 09:09:31PM +0100, Georg Baum wrote:
 Am Mittwoch, 22. März 2006 18:10 schrieb Martin Vermeer:
 
  Playing around with esvn... looks quite nice.
 
 Does it work now? I researched several svn GUIS when we switched to svn at 
 work, but back then (end of 2004 IIRC) none was usable (esvn kept 
 crashing).

No, it doesn't crash. This is 0.6.11-1 rpm.

There is the problem that entering userid and password don't work.
That's not really esvn's problem: it is due to ssh handling svn's
authentication, for svn+ssh that is. The only way around that that I saw
was putting my public key in aussie's authorized_keys.

I haven't yet worked a lot with it, but it looks pretty good, esp. for
browsing around. For committing stuff I still trust the command line
more.

- Martin
 


pgpzH4b8O5Zft.pgp
Description: PGP signature

Re: configure failure... (latest CVS) missing file?

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| One of these two fixes should work. The reason nobody noticed is that
| we already have tests/Makefile.in from earlier runs, I guess.
| 
| Index: src/frontends/controllers/Makefile.am
| ===
| --- src/frontends/controllers/Makefile.am (revision 13444)
| +++ src/frontends/controllers/Makefile.am (working copy)
| @@ -1,5 +1,7 @@
|  include $(top_srcdir)/config/common.am
|  
| +SUBDIRS = tests
| +
|  EXTRA_DIST = pch.h BCView.tmpl
|  
|  BUILT_SOURCES = $(PCH_FILE)

This is the correct fix.


-- 
Lgb

Re: [Ãpatch] RandomAccessList take 4

[Lars Gullik Bjønnes]

Andre Poenitz [EMAIL PROTECTED] writes:

| I guess we'll end up with a beautiful version using latest technology
| which won't fix the original problem (speed) but would look much nicer
| than any pragmatic and working solution.

I am not quite sure what high horse you have saddled yourself upon, but
please come down.

-- 
Lgb

Re: qt4: some colors messed up in preferences dialog

[Lars Gullik Bjønnes]

Leuven, E. [EMAIL PROTECTED] writes:

|  Edwin, I noticed that you didn't commit your patch. I want to
|  do some cleanup that include your patch so I am going to commit
|  the attached patch.
| 
| sorry for that, but i haven't had the opportunity to commit since my old 
password doesn't seem to work. (lars is going to reset it, i hope...)

I will, I will. I only need 5 minutes of spare time...

-- 
Lgb

A Cygwin related patch

[Enrico Forestieri]

The attached patch fixes the bug reported here:
http://thread.gmane.org/gmane.editors.lyx.general/29227

In my intention this is the first of a series of patches aimed at polishing
the Cygwin target, which I think is lagging behind. Please, tell me if this
ok with you. I have no problem in maintaining the Cygwin target but my time
is limited so I cannot guarantee a continuous commitment. I will do it time
permitting. There should be no big problems, as I think the Cygwin users
will not be more than those I can count with only one of my hands ;-)

Do you prefer that I file this one on bugzilla?

-- 
Enrico


Index: src/support/os_unix.C
===
--- src/support/os_unix.C   (revision 13450)
+++ src/support/os_unix.C   (working copy)
@@ -97,6 +97,12 @@ char path_separator()
 void cygwin_path_fix(bool)
 {}
 
+
+bool cygwin_path_fix()
+{
+   return false;
+}
+
 } // namespace os
 } // namespace support
 } // namespace lyx
Index: src/support/os.h
===
--- src/support/os.h(revision 13450)
+++ src/support/os.h(working copy)
@@ -65,6 +65,7 @@ char path_separator();
  *  under Cygwin.
  */
 void cygwin_path_fix(bool use_cygwin_paths);
+bool cygwin_path_fix();
 
 } // namespace os
 } // namespace support
Index: src/support/filetools.C
===
--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,13 @@ string const latex_path(string const  o
latex_path_extension extension,
latex_path_dots dots)
 {
-   string path = subst(original_path, \\, /);
+   string path;
+
+   if (suffixIs(original_path, '/')  os::cygwin_path_fix())
+   path = os::external_path(original_path) + /;
+   else
+   path = subst(original_path, \\, /);
+
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because  is sometimes active (e.g. if
Index: src/support/os_win32.C
===
--- src/support/os_win32.C  (revision 13450)
+++ src/support/os_win32.C  (working copy)
@@ -265,6 +265,12 @@ void cygwin_path_fix(bool)
 {}
 
 
+bool cygwin_path_fix()
+{
+   return false;
+}
+
+
 namespace {
 
 void bail_out()
Index: src/support/os_cygwin.C
===
--- src/support/os_cygwin.C (revision 13450)
+++ src/support/os_cygwin.C (working copy)
@@ -146,6 +146,12 @@ void cygwin_path_fix(bool use_cygwin_pat
cygwin_path_fix_ = use_cygwin_paths;
 }
 
+
+bool cygwin_path_fix()
+{
+   return cygwin_path_fix_;
+}
+
 } // namespace os
 } // namespace support
 } // namespace lyx
Index: src/support/os_os2.C
===
--- src/support/os_os2.C(revision 13450)
+++ src/support/os_os2.C(working copy)
@@ -212,6 +212,12 @@ char path_separator()
 void cygwin_path_fix(bool)
 {}
 
+
+bool cygwin_path_fix()
+{
+   return false;
+}
+
 } // namespace os
 } // namespace support
 } // namespace lyx

Re: gtk frontend and gcc 4.1

[Georg Baum]

Am Mittwoch, 22. März 2006 20:41 schrieb Ling Li:
 Hi, it seems that this small patch is needed to compile gtk
 frontend with gcc 4.1 (on fedora core 5).

Thanks, I put it in both 1.4 and 1.5,since it is obviously right.


Georg

Log:
compile fix from Ling Li: remove superflous class name of members

Feature request: Remember the editing location when a file is closed.

[Bo Peng]

Dear list,

I am not sure if others will like this idea. When I edit a long file,
it may be troublesome to locate and continue from where I was working
on, after the file is re-opened. I would be happy if lyx can
automatically goes to the page at which lyx was closed.

I can think of two ways to do this:

1. (More intrusive). Remember the location under .lyx and jump to it
when a lyx file is opened. I think this is what vim is doing.

2. (Less intrusive). Save bookmark with the lyx file. A user can save
bookmark, close the file, and go to the bookmark after the file is
re-opened.

Cheers,
Bo

Re: Feature request: Remember the editing location when a file is closed.

[christian . ridderstrom]

On Wed, 22 Mar 2006, Bo Peng wrote:

 Dear list,
 
 I am not sure if others will like this idea. When I edit a long file,
 it may be troublesome to locate and continue from where I was working
 on, after the file is re-opened. I would be happy if lyx can
 automatically goes to the page at which lyx was closed.
 
 I can think of two ways to do this:
 
 1. (More intrusive). Remember the location under .lyx and jump to it
 when a lyx file is opened. I think this is what vim is doing.

For good or worse, this also means that when working with someone else on 
the same file (that's sent back and forth, or under version control), 
you'll open it up where the other person left off...

 2. (Less intrusive). Save bookmark with the lyx file. A user can save
 bookmark, close the file, and go to the bookmark after the file is
 re-opened.

Maybe file a bugzilla report? Or if you're brave, discss which of the 
options would be best on the user's list :-)

/C

-- 
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: configure failure... (latest CVS) missing file?

[Kayvan A. Sylvan]

On Wed, Mar 22, 2006 at 09:35:16PM +0100, Lars Gullik Bjønnes wrote:
 Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 
 | One of these two fixes should work. The reason nobody noticed is that
 | we already have tests/Makefile.in from earlier runs, I guess.
 | 
 | Index: src/frontends/controllers/Makefile.am
 | ===
 | --- src/frontends/controllers/Makefile.am   (revision 13444)
 | +++ src/frontends/controllers/Makefile.am   (working copy)
 | @@ -1,5 +1,7 @@
 |  include $(top_srcdir)/config/common.am
 |  
 | +SUBDIRS = tests
 | +
 |  EXTRA_DIST = pch.h BCView.tmpl
 |  
 |  BUILT_SOURCES = $(PCH_FILE)
 
 This is the correct fix.

Yes. This gets me past the initial problem. Now there is a link issue (see
my other email).

Thanks.
-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan, | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | my beautiful Queen.| Robin Gregory (2/28/92)

Re: A Cygwin related patch

[Enrico Forestieri]

Enrico Forestieri [EMAIL PROTECTED] writes:

 
 The attached patch fixes the bug reported here:
 http://thread.gmane.org/gmane.editors.lyx.general/29227
 
 In my intention this is the first of a series of patches aimed at polishing
 the Cygwin target, which I think is lagging behind. Please, tell me if this
 ok with you. I have no problem in maintaining the Cygwin target but my time
 is limited so I cannot guarantee a continuous commitment. I will do it time
 permitting. There should be no big problems, as I think the Cygwin users
 will not be more than those I can count with only one of my hands 
 
 Do you prefer that I file this one on bugzilla?

Here is a perhaps less obtrusive patch.

-- 
Enrico


Index: src/support/filetools.C
===
--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,16 @@ string const latex_path(string const  o
latex_path_extension extension,
latex_path_dots dots)
 {
-   string path = subst(original_path, \\, /);
+   string path;
+
+   if (suffixIs(original_path, '/')) {
+   // The call to os::external_path is needed for Cygwin.
+   path = subst(os::external_path(original_path), \\, /);
+   if (!suffixIs(path, '/'))
+   path += /;
+   } else
+   path = subst(original_path, \\, /);
+
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because  is sometimes active (e.g. if

Re: A Cygwin related patch

[Martin Vermeer]

On Wed, Mar 22, 2006 at 09:29:35PM +, Enrico Forestieri wrote:
 The attached patch fixes the bug reported here:
 http://thread.gmane.org/gmane.editors.lyx.general/29227
 
 In my intention this is the first of a series of patches aimed at polishing
 the Cygwin target, which I think is lagging behind. Please, tell me if this
 ok with you. I have no problem in maintaining the Cygwin target but my time
 is limited so I cannot guarantee a continuous commitment. I will do it time
 permitting. There should be no big problems, as I think the Cygwin users
 will not be more than those I can count with only one of my hands ;-)

You would be amazed by the true number of LyX/Windows users...

Unfortunately I am unable / cannot be bothered to work on that, but I am
really happy somebody does. LyX adoption benefits greatly by having the
option of cross-platform collaborative authoring. And some people are
stuck on Windows.

BTW some of us are hit by symptoms like compulsive hand washing after
touching Windows. Another reason for admiring you ;-)

- Martin



pgphtPh5qNEUY.pgp
Description: PGP signature

[Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Bo Peng]

Dear list,

It does not look so difficult to implement this feature so I tried to
implement it by myself. Attached is my patch. Since I rarely submit a
patch here so I am afraid that there might be many problems (format,
logic, bugs). Please have a look and give me some feedbacks.

Many files have been modified:

src/BufferView_pimpl.C
When a new buffer is loaded, it tries to get last cursor position from
ref().lastfiles(). When a file is going to be closed, current location
is saved as bookmark 0, and to ref().lastfiles(). A side effect of
this is that a file can be re-opened (and to the same location) from
bookmark 0.

src/lastfiles.C:
I do not want to change the Files structure so I use a map to store
position information. lastfile format is changed to id, pos
filename if position information is available, and filename if not.
The biggest changes are to read/write lastfile. I hope that I have not
broken anything here.

src/lyxfunc.C:
   save cursor position when the buffer is closed.

lib/ui/stdmenus.ui:
   add a menu item with an awkard name.

I am worrying about two problem though:

1. Will invalid paragraph id, pos crash lyx? I mean, if a file is
saved (with id, pos saved locally), and is modified externally (get a
revised copy from others), id, pos will no longer be valid and goto
bookmark 0 will fail.

2. Save position does not seem to work when I quit lyx by closing the
lyx window. Only close-buffer will do. Where should I handle the close
event?

3. Is saved_positions[0] really unused?

Cheers,
Bo
Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 13455)
+++ src/BufferView_pimpl.C	(working copy)
@@ -293,6 +293,14 @@
 
 	setBuffer(b);
 	bv_-showErrorList(_(Parse));
+
+	// load position when the file was last closed
+	int id;
+	lyx::pos_type pos; 
+	LyX::ref().lastfiles().loadFilePosition(s, id, pos);
+	// if id is valid ...
+	if( id = 0 )
+		saved_positions[0] = Position(s, id, pos);
 
 	if (tolastfiles)
 		LyX::ref().lastfiles().newFile(b-fileName());
@@ -767,7 +775,14 @@
 	saved_positions[i] = Position(buffer_-fileName(),
   cursor_.paragraph().id(),
   cursor_.pos());
-	if (i  0)
+	// if i == 0, (called when this buffer is closed), 
+	// save current position to lastfile
+	if (i == 0) {
+		LyX::ref().lastfiles().saveFilePosition(buffer_-fileName(),
+cursor_.paragraph().id(), 
+cursor_.pos());
+}
+	else
 		owner_-message(bformat(_(Saved bookmark %1$d), i));
 }
 
Index: src/lastfiles.C
===
--- src/lastfiles.C	(revision 13455)
+++ src/lastfiles.C	(working copy)
@@ -19,6 +19,11 @@
 #include fstream
 #include iterator
 
+// file_pos is a map to save position of cursor when a file is closed.
+#include map
+#include sstream
+#include utility
+
 namespace fs = boost::filesystem;
 
 using std::copy;
@@ -26,10 +31,16 @@
 using std::find;
 using std::getline;
 using std::string;
+using std::map;
+using std::pair;
 using std::ifstream;
 using std::ofstream;
 using std::ostream_iterator;
 
+// store file position information to a map to avoid changing the 
+// dequeue structure Files
+typedef mapstring, pairint, lyx::pos_type  file_pos;
+file_pos filePositions;
 
 LastFiles::LastFiles(string const  filename, bool st, unsigned int num)
 	: dostat(st)
@@ -60,6 +71,22 @@
 	string tmp;
 
 	while (getline(ifs, tmp)  files.size()  num_files) {
+		// id, position filename\n
+		if (tmp[0] == ''  tmp.find('', 1) != string::npos ) {
+			std::istringstream itmp(tmp);
+			string fname;
+			int id;
+			lyx::pos_type pos;
+			itmp.ignore(1);  // ignore ''
+			itmp  id;
+			itmp.ignore(2);  // ignore , 
+			itmp  pos;
+			itmp.ignore(2);  // ingore  ' '
+			itmp  fname;
+			filePositions[fname] = pairint, lyx::pos_type(id, pos);
+			tmp = fname;
+		}
+		// the last part of  file or or lines without .
 		if (dostat  !fs::exists(tmp))
 continue;
 		files.push_back(tmp);
@@ -71,8 +98,18 @@
 {
 	ofstream ofs(filename.c_str());
 	if (ofs) {
-		copy(files.begin(), files.end(),
-		 ostream_iteratorstring(ofs, \n));
+		for (const_iterator file=files.begin(); file != files.end(); ++file) {
+			// has position information, save in the format of 
+// id, pos filename
+			file_pos::iterator entry = filePositions.find(*file);
+			if (entry != filePositions.end() )
+ofs(*entry).second.first  ,   
+	(*entry).second.second *file  endl;
+			// if not, simply save filename
+			else
+ofs  *file  endl;
+		}
+		ofs.close();
 	} else
 		lyxerr  LyX: Warning: unable to save LastFiles: 
 		filename  endl;
@@ -90,7 +127,26 @@
 		files.pop_back();
 }
 
+void LastFiles::saveFilePosition(string const fname, int id, lyx::pos_type pos ) const
+{
+	filePositions[fname] = pairint, lyx::pos_type(id, pos);
+}
 
+void LastFiles::loadFilePosition(string const fname, int id, lyx::pos_type pos ) const
+{
+	

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Martin Vermeer]

On Wed, 2006-03-22 at 23:19 -0600, Bo Peng wrote:
 Dear list,
 
 It does not look so difficult to implement this feature so I tried to
 implement it by myself. Attached is my patch. Since I rarely submit a
 patch here so I am afraid that there might be many problems (format,
 logic, bugs). Please have a look and give me some feedbacks.

Format looks OK. The logic is a bit ad-hoc, but that comes with the
territory.

Others may give detailed feedback on the code.

 Many files have been modified:
 
 src/BufferView_pimpl.C
 When a new buffer is loaded, it tries to get last cursor position from
 ref().lastfiles(). When a file is going to be closed, current location
 is saved as bookmark 0, and to ref().lastfiles(). A side effect of
 this is that a file can be re-opened (and to the same location) from
 bookmark 0.
 
 src/lastfiles.C:
 I do not want to change the Files structure so I use a map to store
 position information. lastfile format is changed to id, pos
 filename if position information is available, and filename if not.

Would it be easier to always have the id, pos filename format? And id
= pos = 0 if no valid info exists, so current behaviour is reproduced?

 The biggest changes are to read/write lastfile. I hope that I have not
 broken anything here.
 
 src/lyxfunc.C:
save cursor position when the buffer is closed.
 
 lib/ui/stdmenus.ui:
add a menu item with an awkard name.
 
 I am worrying about two problem though:
 
 1. Will invalid paragraph id, pos crash lyx? I mean, if a file is
 saved (with id, pos saved locally), and is modified externally (get a
 revised copy from others), id, pos will no longer be valid and goto
 bookmark 0 will fail.

This is a file format change and lyx2lyx must be made to handle it.

+// not found, return invalid id number
+   else {
+   id = -1;
+   pos = 0;
+   }

Please don't do this ;-)

It won't be needed if we change and handle the new file format.

 2. Save position does not seem to work when I quit lyx by closing the
 lyx window. Only close-buffer will do. Where should I handle the close
 event?

Don't bother. That's not the way to leave LyX.

 3. Is saved_positions[0] really unused?

No, it's used in at least two other places.

1) To save the main document position to return to when opening a child
2) To save the return (ref) position when jumping to a label.

Neither interferes with your use, I think.

So you're not the first to have this brilliant idea :-)

 Cheers,
 Bo

Welcome to the club!

Regards Martin



signature.asc
Description: This is a digitally signed message part

[patch] remove wheel mouse ui from qt2

[Juergen Spitzmueller]

The attached patch finally eliminates the gui element.
I did not touch qt4, since Abdel is reorganizing the Prefs dialog currently. 
Abdel, while you are at it, could you please remove the wheel mouse spinbox?

OK to apply to branch and trunk?


* src/frontends/qt2/QPrefs.C
(void QPrefs::apply):
(void QPrefs::update_contents):
* src/frontends/qt2/QPrefsDialog.C
(QPrefsDialog::QPrefsDialog):
* src/frontends/qt2/ui/QPrefUIModule.ui:  remove wheel mouse spin box   
(bug 783).


Jürgen 
Index: src/frontends/qt2/QPrefs.C
===
--- src/frontends/qt2/QPrefs.C	(Revision 13455)
+++ src/frontends/qt2/QPrefs.C	(Arbeitskopie)
@@ -174,7 +174,6 @@ void QPrefs::apply()
 	rc.ui_file = internal_path(uimod-uiFileED-text());
 	rc.bind_file = internal_path(uimod-bindFileED-text());
 	rc.cursor_follows_scrollbar = uimod-cursorFollowsCB-isChecked();
-	rc.wheel_jump = uimod-wheelMouseSB-value();
 	rc.autosave = uimod-autoSaveSB-value() * 60;
 	rc.make_backup = uimod-autoSaveCB-isChecked();
 	rc.num_lastfiles = uimod-lastfilesSB-value();
@@ -496,7 +495,6 @@ void QPrefs::update_contents()
 	uimod-uiFileED-setText(external_path(rc.ui_file));
 	uimod-bindFileED-setText(external_path(rc.bind_file));
 	uimod-cursorFollowsCB-setChecked(rc.cursor_follows_scrollbar);
-	uimod-wheelMouseSB-setValue(rc.wheel_jump);
 	// convert to minutes
 	int mins(rc.autosave / 60);
 	if (rc.autosave  !mins)
Index: src/frontends/qt2/QPrefsDialog.C
===
--- src/frontends/qt2/QPrefsDialog.C	(Revision 13455)
+++ src/frontends/qt2/QPrefsDialog.C	(Arbeitskopie)
@@ -229,7 +229,6 @@ QPrefsDialog::QPrefsDialog(QPrefs * form
 	connect(uiModule-uiFileED, SIGNAL(textChanged(const QString)), this, SLOT(change_adaptor()));
 	connect(uiModule-bindFileED, SIGNAL(textChanged(const QString)), this, SLOT(change_adaptor()));
 	connect(uiModule-cursorFollowsCB, SIGNAL(toggled(bool)), this, SLOT(change_adaptor()));
-	connect(uiModule-wheelMouseSB, SIGNAL(valueChanged(int)), this, SLOT(change_adaptor()));
 	connect(uiModule-autoSaveSB, SIGNAL(valueChanged(int)), this, SLOT(change_adaptor()));
 	connect(uiModule-autoSaveCB, SIGNAL(toggled(bool)), this, SLOT(change_adaptor()));
 	connect(uiModule-lastfilesSB, SIGNAL(valueChanged(int)), this, SLOT(change_adaptor()));
Index: src/frontends/qt2/ui/QPrefUIModule.ui
===
--- src/frontends/qt2/ui/QPrefUIModule.ui	(Revision 13455)
+++ src/frontends/qt2/ui/QPrefUIModule.ui	(Arbeitskopie)
@@ -13,7 +13,7 @@
 rect
 x0/x
 y0/y
-width416/width
+width412/width
 height441/height
 /rect
 /property
@@ -26,9 +26,9 @@
 /property
 property stdset=1
 namecaption/name
-string/string
+stringQPrefUIModule/string
 /property
-vbox
+grid
 property stdset=1
 namemargin/name
 number11/number
@@ -37,90 +37,7 @@
 namespacing/name
 number6/number
 /property
-widget
-classQLayoutWidget/class
-property stdset=1
-namename/name
-cstringLayout2/cstring
-/property
-grid
-property stdset=1
-namemargin/name
-number0/number
-/property
-property stdset=1
-namespacing/name
-number6/number
-/property
-widget row=1  column=2 
-classQPushButton/class
-property stdset=1
-namename/name
-cstringbindFilePB/cstring
-/property
-property stdset=1
-nametext/name
-stringBamp;rowse.../string
-/property
-/widget
-widget row=0  column=0 
-classQLabel/class
-property stdset=1
-namename/name
-cstringuiFileLA/cstring
-/property
-property stdset=1
-nametext/name
-stringamp;User interface file:/string
-/property
-property
-namebuddy/name
-cstringuiFileED/cstring
-/property
-/widget
-widget row=1  column=0 
-classQLabel/class
-property stdset=1
-namename/name
-cstringbindFileLA/cstring
-/property
-property stdset=1
-   

Re: line endings again

[Georg Baum]

Abdelrazak Younes wrote:

> What does this mean in practice? Now that I use Xemacs will I see ^M at
> each end-of-line because I checkout from windows?

No, xemacs should handle that transparently. Use vim if it cannot do
that ;-)

> And why only the qt4 
> frontend?

Because the other files have it already.

> I have cleanup everything already and promised to use Xemacs, 
> wasn't that enough?

No, because it was not enforced. This does not mean that I don't trust you
to be careful, but it is very easy to mix up line endings accidentally
again, and you would not notice. Now you don't need to care at all anymore.

> I would to continue working with Unix-style line 
> ending.

You don't need to do that anymore. xemacs should handle both styles, and any
"dumb" editor will simply use windows style.


Georg

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Martin Vermeer]

On Tue, 2006-03-21 at 22:23 +0100, Georg Baum wrote:

...

> What do you think?
> 
> 
> Georg

Looks good... but I don't understand this

Index: src/Color.C
===
--- src/Color.C (Revision 13447)
+++ src/Color.C (Arbeitskopie)

Is this a peculiarity of svn diff? I understand you moved and modified
this file from the one in src/frontends/xforms/, right?

- Martin



signature.asc
Description: This is a digitally signed message part

[Patch in parent] Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Martin Vermeer]

On Tue, 2006-03-21 at 18:29 +0200, Martin Vermeer wrote:
> On Tue, 2006-03-21 at 18:14 +0200, Martin Vermeer wrote:

...

> Here's the patch. Trivial (Georg, how did we overlook this?)
> 
> OK to put into both trunk and 1.4?
> 
> - Martin

Committed to trunk:

* math_gridinset.C (MathGridInset::doDispatch): reset cur.pos() when
deleting current col or row

- Martin



signature.asc
Description: This is a digitally signed message part

LyX 1.5 crash while scrolling

[Juergen Spitzmueller]

1. Load the UserGuide
2. Scroll

=> LyX crashes. Not reproducible with 1.4

(preview-latex is disabled)

Jürgen

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1086936672 (LWP 26996)]
lyx::graphics::CacheItem::status (this=0x7) at scoped_ptr.hpp:94
94  BOOST_ASSERT(ptr != 0);

(gdb) bt
#0  lyx::graphics::CacheItem::status (this=0x7) at scoped_ptr.hpp:94
#1  0x08499008 in lyx::graphics::Loader::Impl::statusChanged (this=0x8964860)
at GraphicsLoader.C:260
#2  0x0849a609 in 
boost::detail::function::void_function_obj_invoker0, 
boost::_bi::list1 > >, 
void>::invoke (function_obj_ptr=
  {obj_ptr = 0x88a99b8, const_obj_ptr = 0x88a99b8, func_ptr = 0x88a99b8, 
data = ""})
at mem_fn_template.hpp:45
#3  0x0807988a in boost::function0::operator() 
(this=0x8965c34)
at function_template.hpp:576
#4  0x080798c8 in 
boost::operator++ >, 
boost::signals::detail::named_slot_map_iterator>, 
boost::signals::detail::unusable, boost::single_pass_traversal_tag, 
boost::signals::detail::unusable const&, int> ([EMAIL PROTECTED]) at 
signal_template.hpp:119
#5  0x08079cf7 in boost::signal0 
>::operator() (this=0x89658a8) at last_value.hpp:43
#6  0x0848ff12 in lyx::graphics::CacheItem::Impl::setStatus (this=0x8965878,
new_status=lyx::graphics::Converting) at GraphicsCacheItem.C:256
#7  0x08490534 in lyx::graphics::CacheItem::Impl::convertToDisplayFormat 
(this=0x8965878)
at GraphicsCacheItem.C:378
#8  0x084913cf in lyx::graphics::CacheItem::Impl::startLoading 
(this=0x8965878)
at GraphicsCacheItem.C:218
#9  0x0849140a in lyx::graphics::CacheItem::startLoading (this=0x88a8d48)
at GraphicsCacheItem.C:156
#10 0x0849becb in lyx::graphics::LoaderQueue::loadNext (this=0x86858e0) at 
LoaderQueue.C:48
---Type  to continue, or q  to quit---
#11 0x0849d061 in 
boost::detail::function::void_function_obj_invoker0, 
boost::_bi::list1 > >, 
void>::invoke (function_obj_ptr=
  {obj_ptr = 0x87d0280, const_obj_ptr = 0x87d0280, func_ptr = 0x87d0280, 
data = "\200"})
at mem_fn_template.hpp:45
#12 0x0807988a in boost::function0::operator() 
(this=0x87d026c)
at function_template.hpp:576
#13 0x080798c8 in 
boost::operator++ >, 
boost::signals::detail::named_slot_map_iterator>, 
boost::signals::detail::unusable, boost::single_pass_traversal_tag, 
boost::signals::detail::unusable const&, int> ([EMAIL PROTECTED]) at 
signal_template.hpp:119
#14 0x08079cf7 in boost::signal0 
>::operator() (this=0x8685928) at last_value.hpp:43
#15 0x083093bd in Timeout::emit (this=0x8685928) at Timeout.C:51
#16 0x08313b1b in qtTimeout::timerEvent (this=0x87d0188) at Timeout.h:72
#17 0x4028c852 in QObject::event () from /usr/lib/qt3/lib/libqt-mt.so.3
#18 0x4022cd41 in QApplication::internalNotify () 
from /usr/lib/qt3/lib/libqt-mt.so.3
#19 0x4022d6b9 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3
#20 0x40221ab8 in QEventLoop::activateTimers () 
from /usr/lib/qt3/lib/libqt-mt.so.3
#21 0x401daf4f in QEventLoop::processEvents () 
from /usr/lib/qt3/lib/libqt-mt.so.3
#22 0x40243c39 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3
#23 0x40243b36 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#24 0x4022c68f in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#25 0x08373eeb in lyx_gui::start ([EMAIL PROTECTED], [EMAIL PROTECTED]) at 
lyx_gui.C:248
#26 0x08149563 in LyX::priv_exec (this=0x86bd6c8, [EMAIL PROTECTED], 
argv=0xbfe3a134)

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Jean-Marc Lasgouttes]

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

Martin> Here's the patch. Trivial (Georg, how did we overlook this?)

Martin> OK to put into both trunk and 1.4?

OK for 1.4.

JMarc

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Georg Baum]

Martin Vermeer wrote:

> Looks good... but I don't understand this
> 
> Index: src/Color.C
> ===
> --- src/Color.C (Revision 13447)
> +++ src/Color.C (Arbeitskopie)
> 
> Is this a peculiarity of svn diff?

Yes.

> I understand you moved and modified 
> this file from the one in src/frontends/xforms/, right?

Exactly. Therefore the patch won't apply as-is, but you can see the
differences from the original file


Georg

Re: line endings again

[Abdelrazak Younes]

OK, thanks for the clarification.

Abdel.

Georg Baum a écrit :

Abdelrazak Younes wrote:


What does this mean in practice? Now that I use Xemacs will I see ^M at
each end-of-line because I checkout from windows?


No, xemacs should handle that transparently. Use vim if it cannot do
that ;-)

And why only the qt4 
frontend?


Because the other files have it already.

I have cleanup everything already and promised to use Xemacs, 
wasn't that enough?


No, because it was not enforced. This does not mean that I don't trust you
to be careful, but it is very easy to mix up line endings accidentally
again, and you would not notice. Now you don't need to care at all anymore.

I would to continue working with Unix-style line 
ending.


You don't need to do that anymore. xemacs should handle both styles, and any
"dumb" editor will simply use windows style.


Georg

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Abdelrazak Younes]

Angus Leeming a écrit :

Abdelrazak Younes <[EMAIL PROTECTED]> writes:
The patch looks good but I am wondering if this solution is not a bit 
too complicated. Why not just define some const string in hexa and let 
the frontend take care of the rest?


Just for clarification, this would mean replacing x11name by this RGB 
value in ColorEntry:



class ColorEntry {
ColorEntry(
string rgb_hexa = "#00",
string const guiname_ = "",
string const latexname_ = "",
string const lyxname_ = "");


Georg's solution may look complicated, but it's just a refactoring of existing,
working code. A real RGBColor class has real advantages, not least being type
safe. We (you :)) should strive to remove kludges, not add to them!

Further, a real Color lends itself to easy manipulation; the fact that we have
to separately define the colours of inset button and borders is a real ugliness!


Note that we could add optional hsv offset members to ColorEntry and let 
QColor in the case of Qt do the manipulation. The idea is that Qt will 
do color manipulation anyway so why doing it twice at difference 
location? At the end, what's on sreen is what Qt shows, isn't it?
This pseudo code will summarize my idea. The advantage of it is that you 
can for example authorize the manipulation of the button background but 
all other button related colors would be set automatically.


class ColorEntry {
ColorEntry(
string rgb_hexa = "#00",
string const guiname_ = "",
string const latexname_ = "",
string const lyxname_ = "",
int h_offset = 0,
int s_offset = 0,
int v_offset = 0);

string const & get_rbg() const;
void set_rbg(string const & rgb_hexa);
void const & get_hsv_offset(int & ho, int & so, int & vo) const;

private:
string rgb_;
int const h_offset_;
int const s_offset_;
int const v_offset_;
string const guiname_;
string const latexname_;
string const lyxname_;
};

class LQColor: public QColor
{
LQColor(ColorEntry const ce): QColor(ce.get_rbg()) {
if (ce.h_offset != 0
|| ce.s_offset != 0
|| ce.v_offset != 0) {

convertTo(QColor::Hsv);
int h, s, v, ho, so, vo;
getHsv(,,);
ce.get_hsv_offset(ho,so,vo);
setHsv(&(h += ho), &(s += so), &(v += so));
}
}

What do you think?


À demain!


A+
Abdel.

PS: A+ means "A plus tard" or "See you later"


Angus

[PATCH] better support for classes that do not define a ToC

[Jean-Marc Lasgouttes]

This patch (against 1.4.1svn) tries to handle better classes where no
ToC structure is defined. This is useful when old textclasses give
errors (this was the original motivation, see bug 2410), but also for
classes without a ToC, like "cv".

What it does is trivial: (1) do not update or use secnumdepth and tocdepth
when there is no ToC and (2) disable the corresponding UI elements.

The gtk part is not done, but it is trivial.

Comments? I'd like to apply it for 1.4.1. Then of course we'll have to
fix the actual problem.

JMarc

Index: src/ChangeLog
===
--- src/ChangeLog	(revision 13450)
+++ src/ChangeLog	(working copy)
@@ -1,3 +1,10 @@
+2006-03-22  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
+
+	* lyxtextclass.C (hasTocLevels): new method.
+
+	* bufferparams.C (useClassDefaults, writeLaTeX): skip secnumdepth
+	and tocdepth if the class does not define a ToC structure.
+
 2006-03-16  Jürgen Spitzmüller  <[EMAIL PROTECTED]>
 
 	* text.C (delete): adjust cursor after backspace in change tracking
Index: src/bufferparams.C
===
--- src/bufferparams.C	(revision 13450)
+++ src/bufferparams.C	(working copy)
@@ -915,17 +915,20 @@ bool BufferParams::writeLaTeX(ostream & 
 		texrow.newline();
 	}
 
-	if (secnumdepth != tclass.secnumdepth()) {
-		os << "\\setcounter{secnumdepth}{"
-		   << secnumdepth
-		   << "}\n";
-		texrow.newline();
-	}
-	if (tocdepth != tclass.tocdepth()) {
-		os << "\\setcounter{tocdepth}{"
-		   << tocdepth
-		   << "}\n";
-		texrow.newline();
+	// Only if class has a ToC hierarchy
+	if (tclass.hasTocLevels()) {
+		if (secnumdepth != tclass.secnumdepth()) {
+			os << "\\setcounter{secnumdepth}{"
+			   << secnumdepth
+			   << "}\n";
+			texrow.newline();
+		}
+		if (tocdepth != tclass.tocdepth()) {
+			os << "\\setcounter{tocdepth}{"
+			   << tocdepth
+			   << "}\n";
+			texrow.newline();
+		}
 	}
 
 	if (paragraph_separation) {
@@ -1068,8 +1071,11 @@ void BufferParams::useClassDefaults()
 	columns = tclass.columns();
 	pagestyle = tclass.pagestyle();
 	options = tclass.options();
-	secnumdepth = tclass.secnumdepth();
-	tocdepth = tclass.tocdepth();
+	// Only if class has a ToC hierarchy
+	if (tclass.hasTocLevels()) {
+		secnumdepth = tclass.secnumdepth();
+		tocdepth = tclass.tocdepth();
+	}
 }
 
 
Index: src/frontends/qt2/ChangeLog
===
--- src/frontends/qt2/ChangeLog	(revision 13450)
+++ src/frontends/qt2/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2006-03-22  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
+
+	* QDocument.C (apply): skip secnumdepth and tocdepth if the class
+	does not define a ToC structure.
+	(update_contents): cleanup and use LyXTextClass::hasTocLevels.
+
 2006-03-20  Jean-Marc Lasgouttes  <[EMAIL PROTECTED]>
 
 	* QWorkArea.C (QWorkArea): do not paint background (bug 2197).
Index: src/frontends/qt2/QDocument.C
===
--- src/frontends/qt2/QDocument.C	(revision 13450)
+++ src/frontends/qt2/QDocument.C	(working copy)
@@ -267,8 +267,10 @@ void QDocument::apply()
 	params.language = languages.getLanguage(lang_[pos]);
 
 	// numbering
-	params.tocdepth = dialog_->numberingModule->tocSL->value();
-	params.secnumdepth = dialog_->numberingModule->depthSL->value();
+	if (params.getLyXTextClass().hasTocLevels()) {
+		params.tocdepth = dialog_->numberingModule->tocSL->value();
+		params.secnumdepth = dialog_->numberingModule->depthSL->value();
+	}
 
 	// bullets
 	params.user_defined_bullet(0) = dialog_->bulletsModule->getBullet(0);
@@ -506,19 +508,19 @@ void QDocument::update_contents()
 	// numbering
 	int const min_toclevel = controller().textClass().min_toclevel();
 	int const max_toclevel = controller().textClass().max_toclevel();
-	if (min_toclevel != LyXLayout::NOT_IN_TOC)
+	if (controller().textClass().hasTocLevels()) {
 		dialog_->numberingModule->setEnabled(true);
-	else {
+		dialog_->numberingModule->depthSL->setMinValue(min_toclevel - 1);
+		dialog_->numberingModule->depthSL->setMaxValue(max_toclevel);
+		dialog_->numberingModule->depthSL->setValue(params.secnumdepth);
+		dialog_->numberingModule->tocSL->setMinValue(min_toclevel - 1);
+		dialog_->numberingModule->tocSL->setMaxValue(max_toclevel);
+		dialog_->numberingModule->tocSL->setValue(params.tocdepth);
+		dialog_->updateNumbering();
+	} else {
 		dialog_->numberingModule->setEnabled(false);
 		dialog_->numberingModule->tocLV->clear();
 	}
-	dialog_->numberingModule->depthSL->setMinValue(min_toclevel - 1);
-	dialog_->numberingModule->depthSL->setMaxValue(max_toclevel);
-	dialog_->numberingModule->depthSL->setValue(params.secnumdepth);
-	dialog_->numberingModule->tocSL->setMinValue(min_toclevel - 1);
-	dialog_->numberingModule->tocSL->setMaxValue(max_toclevel);
-	dialog_->numberingModule->tocSL->setValue(params.tocdepth);
-	dialog_->updateNumbering();
 
 	// bullets
 	

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Abdelrazak Younes]

Small rectification, the offsets are private so the previous code won't 
work. But pseudo-code are not meant to work, are they? :-)


class LQColor: public QColor
{
 LQColor(ColorEntry const ce): QColor(ce.get_rbg()) {
 int ho, so, vo;
 ce.get_hsv_offset(ho,so,vo);
 if (ho != 0 || so != 0 || vo != 0) {
 convertTo(QColor::Hsv);
 int h, s, v;
 getHsv(,,);
 setHsv(&(h += ho), &(s += so), &(v += so));
}
}

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Angus Leeming]

Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Note that we could add optional hsv offset members to ColorEntry and let 
> QColor in the case of Qt do the manipulation. The idea is that Qt will 
> do color manipulation anyway so why doing it twice at difference 
> location? At the end, what's on sreen is what Qt shows, isn't it?

I'm not going to fight about this as I'm not going to write the code, but it
seems to me that the code to do all this elegantly exists already, is tested and
is known to work. All Georg is doing is moving it out of the XForms directory.

I'll let you two continue the debate.

> What do you think?

I prefer OO code for stuff that fits elegantly into the concept of object.

Angus

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Abdelrazak Younes]

Angus Leeming a écrit :

Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Note that we could add optional hsv offset members to ColorEntry and let 
QColor in the case of Qt do the manipulation. The idea is that Qt will 
do color manipulation anyway so why doing it twice at difference 
location? At the end, what's on sreen is what Qt shows, isn't it?


I'm not going to fight about this as I'm not going to write the code, but it
seems to me that the code to do all this elegantly exists already, is tested and
is known to work. All Georg is doing is moving it out of the XForms directory.


I am  not trying to fight. I was just trying to have an interesting 
discussion ;-)



I'll let you two continue the debate.


Georg will make up his mind and do what he thinks right. I am a firm 
believer that he who do the job should decide at the end.



What do you think?


I prefer OO code for stuff that fits elegantly into the concept of object.


Hum... so colors are not object for you?

Just kidding, we can stop the debate here.
Abdel.

[PATCH] update vs repaint

[Jean-Marc Lasgouttes]

There was a consensus that this patch is the right thing to do, even
though it might not speed things up per se. I tested it and propose to
apply to trunk and branch.

OK?

JMarc

Index: src/frontends/qt2/qscreen.C
===
--- src/frontends/qt2/qscreen.C	(revision 13433)
+++ src/frontends/qt2/qscreen.C	(working copy)
@@ -144,7 +144,7 @@ void QScreen::showCursor(int x, int y, i
 		break;
 	}
 
-	owner_.getContent()->repaint(
+	owner_.getContent()->update(
 		cursor_x_, cursor_y_,
 		cursor_w_, cursor_h_);
 }
@@ -160,5 +160,5 @@ void QScreen::removeCursor()
 	   _pixmap_, 0, 0, cursor_w_, cursor_h_);
 
 	owner_.getContent()
-		->repaint(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
+		->update(cursor_x_, cursor_y_, cursor_w_, cursor_h_);
 }

Re: [PATCH] update vs repaint

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

There was a consensus that this patch is the right thing to do, even
though it might not speed things up per se. I tested it and propose to
apply to trunk and branch.

OK?


Alleluia!
:-)

Re: [Ãpatch] RandomAccessList take 4

[Juergen Spitzmueller]

Georg Baum wrote:
> This patch compiles for 1.4

Yes. Compiles, runs and feels good.
What specifically should we test for (I notice that scrolling the UserGuide is 
quite fluently, as long as no graphics or previews are involved [1]).

Jürgen

[1] It appears to me that in 1.3, the graphics and previews weren't loaded 
immediately, so that they didn't block scrolling. 

Re: [Ãpatch] RandomAccessList take 4

[Abdelrazak Younes]

Juergen Spitzmueller a écrit :

Georg Baum wrote:

This patch compiles for 1.4


Yes. Compiles, runs and feels good.
What specifically should we test for


Paragraph insertion/deletion (especially around graphics), Undo/Redo, 
Cut inside/outside insets, export*, navigate.
Navigating when the lyx file and graphics are not local (i.e in the 
network) is the ultimate test.


(I notice that scrolling the UserGuide is 
quite fluently, as long as no graphics or previews are involved [1]).


You mean it is better or slower than without the patch?

Abdel.

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Georg Baum]

Angus Leeming wrote:

> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> > The patch looks good but I am wondering if this solution is not a bit
>> > too complicated. Why not just define some const string in hexa and let
>> > the frontend take care of the rest?

What would we gain? Not much IMHO. Whether a color name is given in
"#rrggbb" notation, or as a real name "linen", does not matter IMHO,
because in both cases the frontend will resolve it to an rgb value, and to
users of ColorEntry it is just a string.

>> Just for clarification, this would mean replacing x11name by this RGB
>> value in ColorEntry:
> 
>> class ColorEntry {
>> ColorEntry(
>> string rgb_hexa = "#00",
>> string const guiname_ = "",
>> string const latexname_ = "",
>> string const lyxname_ = "");

I agree that we should get rid of x11name, because it is not so useful
anymore, but I would rather replace it by something like RGBColor (or maybe
merge RGBColor with ColorEntry). Anyway, this is for later and unrelated to
the branch change.

> Georg's solution may look complicated, but it's just a refactoring of
> existing, working code.

Yes. It would be a pity to ditch this code together with the xforms frontend
if it is useful somewhere else.
I think I am going to apply the patch this evening (will send Changelog
then, too).

> A real RGBColor class has real advantages, not 
> least being type safe. We (you :)) should strive to remove kludges, not
> add to them!
> 
> Further, a real Color lends itself to easy manipulation; the fact that we
> have to separately define the colours of inset button and borders is a
> real ugliness!

This is something that can come later. For now, I am only interested in
making the color handling of branches easier/more robust.
At a later point we could think of making branches using a LColor instead of
RGBColor. That would mean that we either add a new LColor for every user
defined color, or a special "general purpose color" that has no name but
rgb values. I am not sure yet what would be best, but we are not in a
hurry: 1.4.x bugs are waiting!


Georg

Re: [Ãpatch] RandomAccessList take 4

[Juergen Spitzmueller]

Abdelrazak Younes wrote:
> > (I notice that scrolling the UserGuide is
> > quite fluently, as long as no graphics or previews are involved [1]).
>
> You mean it is better or slower than without the patch?

No, it's completely unrelated. I just noticed it while testing the patch.

Jürgen

Compile/link problem (lyx-1.5.0svn)

[Kayvan A. Sylvan]

My automated builds are still not happening. The link is failing
with "multiple definition of (anonymous namespace)..." messages.

Here are some representative messages.

> === Building QT LyX ===
> [...]
> 
> Configuration
>   Host type:  x86_64-unknown-linux-gnu
>   Special build flags:compression aiksaurus assertions pch 
> concept-checks stdlib-debug warnings  use-aspell use-ispell
>   C   Compiler:   gcc 
>   C   Compiler LyX flags:  
>   C   Compiler flags: -Wextra -Wall-I/usr/X11R6/include -O2
>   C++ Compiler:   g++ (4.0.2)
>   C++ Compiler LyX flags:  
>   C++ Compiler flags: -Wextra -Wall-I/usr/X11R6/include -O2
>   Linker flags:   
>   Linker user flags:  
>   Qt Frontend:
>   Qt version: 3.3.4
>   Packaging:  posix
>   LyX binary dir: /usr/local/bin
>   LyX files dir:  /usr/local/share/lyx
> 
> Configuration of LyX was successful.
> [...]
> if g++ -DHAVE_CONFIG_H -I. -I. -I.  -Winvalid-pch --include=./pch.h 
> -I../boost -Wextra -Wall-I/usr/X11R6/include  -O2 -MT version.o -MD -MP 
> -MF ".deps/version.Tpo" -c -o version.o version.C; \
> then mv -f ".deps/version.Tpo" ".deps/version.Po"; else rm -f 
> ".deps/version.Tpo"; exit 1; fi
> if g++ -DHAVE_CONFIG_H -I. -I. -I.  -Winvalid-pch --include=./pch.h 
> -I../boost -Wextra -Wall-I/usr/X11R6/include  -O2 -MT vspace.o -MD -MP 
> -MF ".deps/vspace.Tpo" -c -o vspace.o vspace.C; \
> then mv -f ".deps/vspace.Tpo" ".deps/vspace.Po"; else rm -f 
> ".deps/vspace.Tpo"; exit 1; fi
> /bin/sh ../libtool --tag=CXX --mode=link g++  -O2   -o lyx-qt  main.o Bidi.o 
> BufferView.o BufferView_pimpl.o Bullet.o BranchList.o Chktex.o CutAndPaste.o 
> DepTable.o FloatList.o Floating.o FontIterator.o FuncStatus.o InsetList.o 
> LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o 
> ParagraphParameters.o PrinterParams.o Spacing.o Thesaurus.o ToolbarBackend.o 
> author.o boost.o box.o buffer.o buffer_funcs.o bufferlist.o bufferparams.o 
> bufferview_funcs.o changes.o chset.o converter.o counters.o coordcache.o 
> cursor.o cursor_slice.o debug.o dimension.o dociterator.o encoding.o 
> errorlist.o exporter.o gettext.o factory.o format.o funcrequest.o graph.o 
> importer.o intl.o insetiterator.o kbmap.o kbsequence.o language.o lastfiles.o 
> lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxfont.o lyxfind.o lyxfunc.o 
> lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxlex_pimpl.o lyxrc.o 
> lyxrow.o lyxrow_funcs.o lyxserver.o lyxsocket.o lyxtextclass.o 
> lyxtextclasslist.o lyxvc.o messages.o metricsinfo.o mover.o output.o 
> outputparams.o output_docbook.o output_latex.o output_linuxdoc.o 
> output_plaintext.o paragraph.o paragraph_funcs.o paragraph_pimpl.o 
> pariterator.o aspell.o  ispell.o SpellBase.o rowpainter.o sgml.o tabular.o 
> tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o 
> trans_mgr.o undo.o vc-backend.o version.o vspace.o mathed/libmathed.la 
> insets/libinsets.la frontends/libfrontends.la frontends/qt2/libqt2.la 
> frontends/controllers/libcontrollers.la graphics/libgraphics.la 
> support/libsupport.la ../boost/libs/regex/src/libboost_regex.la 
> ../boost/libs/signals/src/libboost_signals.la 
> ../boost/libs/filesystem/src/libboost_filesystem.la  -lAiksaurus -laspell  
> -lSM -lICE -lc -lm   -L/usr/X11R6/lib64 -lX11  -lz  
> mkdir .libs
> g++ -O2 -o lyx-qt main.o Bidi.o BufferView.o BufferView_pimpl.o Bullet.o 
> BranchList.o Chktex.o CutAndPaste.o DepTable.o FloatList.o Floating.o 
> FontIterator.o FuncStatus.o InsetList.o LColor.o LaTeX.o LaTeXFeatures.o 
> LyXAction.o MenuBackend.o ParagraphParameters.o PrinterParams.o Spacing.o 
> Thesaurus.o ToolbarBackend.o author.o boost.o box.o buffer.o buffer_funcs.o 
> bufferlist.o bufferparams.o bufferview_funcs.o changes.o chset.o converter.o 
> counters.o coordcache.o cursor.o cursor_slice.o debug.o dimension.o 
> dociterator.o encoding.o errorlist.o exporter.o gettext.o factory.o format.o 
> funcrequest.o graph.o importer.o intl.o insetiterator.o kbmap.o kbsequence.o 
> language.o lastfiles.o lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxfont.o 
> lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o 
> lyxlex_pimpl.o lyxrc.o lyxrow.o lyxrow_funcs.o lyxserver.o lyxsocket.o 
> lyxtextclass.o lyxtextclasslist.o lyxvc.o messages.o metricsinfo.o mover.o 
> output.o outputparams.o output_docbook.o output_latex.o output_linuxdoc.o 
> output_plaintext.o paragraph.o paragraph_funcs.o paragraph_pimpl.o 
> pariterator.o aspell.o ispell.o SpellBase.o rowpainter.o sgml.o tabular.o 
> tex-accent.o tex-strings.o texrow.o text.o text2.o text3.o toc.o trans.o 
> trans_mgr.o undo.o vc-backend.o version.o vspace.o  mathed/.libs/libmathed.a 
> insets/.libs/libinsets.a frontends/.libs/libfrontends.a 
> frontends/qt2/.libs/libqt2.a -L/usr/lib64/qt-3.3/lib -lqt-mt 
> 

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Abdelrazak Younes]

Georg Baum a écrit :

Angus Leeming wrote:


Abdelrazak Younes <[EMAIL PROTECTED]> writes:

The patch looks good but I am wondering if this solution is not a bit
too complicated. Why not just define some const string in hexa and let
the frontend take care of the rest?


What would we gain? Not much IMHO. Whether a color name is given in
"#rrggbb" notation, or as a real name "linen", does not matter IMHO,
because in both cases the frontend will resolve it to an rgb value, and to
users of ColorEntry it is just a string.


Actually I prefer the 3 ints solution but I thought this would 
complicate the lyx and latex file writings.



I agree that we should get rid of x11name, because it is not so useful
anymore, but I would rather replace it by something like RGBColor (or maybe
merge RGBColor with ColorEntry). Anyway, this is for later and unrelated to
the branch change.


OK


Yes. It would be a pity to ditch this code together with the xforms frontend
if it is useful somewhere else.


That was my point, I doing thing it provide much compared to QColor and 
I am sure there is a Gtk equivalent.



I think I am going to apply the patch this evening (will send Changelog
then, too).


Good. We'll probably have to come back to this later.

Thanks,
Abdel.

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Abdelrazak Younes]

Abdelrazak Younes a écrit :
Yes. It would be a pity to ditch this code together with the xforms 
frontend

if it is useful somewhere else.


That was my point, I doing thing it provide much compared to QColor and 


Err, "I don't think".

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Georg Baum]

Abdelrazak Younes wrote:

> Actually I prefer the 3 ints solution but I thought this would
> complicate the lyx and latex file writings.

I don't understand. lyxname and latexname are used for lyx and latex file
writing, x11name has nothing to do with that.

> That was my point, I doing thing it provide much compared to QColor and
> I am sure there is a Gtk equivalent.

Yes, Gdk::Color IIRC, but how could these be used outside of the specific
frontend? I know only one way (ditch all frontends but one and give up the
frontend-core separation), but proposing that would generate heated
discussions that I'd like to avoid by all means.


Georg

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Martin Vermeer]

On Wed, Mar 22, 2006 at 11:44:09AM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> 
> Martin> Here's the patch. Trivial (Georg, how did we overlook this?)
> 
> Martin> OK to put into both trunk and 1.4?
> 
> OK for 1.4.
> 
> JMarc

It is in... unfortunately the change to status.14x went in first :-(

Playing around with esvn... looks quite nice.

- Martin



pgpp8nOrSEMw8.pgp
Description: PGP signature

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Jean-Marc Lasgouttes]

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

Martin> It is in... unfortunately the change to status.14x went in
Martin> first :-(

Thanks.

JMarc

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Abdelrazak Younes]

Georg Baum a écrit :

Abdelrazak Younes wrote:


Actually I prefer the 3 ints solution but I thought this would
complicate the lyx and latex file writings.


I don't understand. lyxname and latexname are used for lyx and latex file
writing, x11name has nothing to do with that.


My (stupid) mistake. My mind is mixed up by lyx file format and latex 
file format using #f like string AFAIK. Nothing to do with branch 
and GUI colorization.



That was my point, I doing thing it provide much compared to QColor and
I am sure there is a Gtk equivalent.


Yes, Gdk::Color IIRC, but how could these be used outside of the specific
frontend? I know only one way (ditch all frontends but one and give up the
frontend-core separation), but proposing that would generate heated
discussions that I'd like to avoid by all means.


My point is that you shouldn't need to manipulate Colors outside the 
frontend. But I am maybe missing something.


Forget about it.

Abdel.

Crash during acrolling with arrow-down

[Bo Peng]

Dear list,

I can not reproduce this crash. It happens when I use down arrow key
to navigate an article.

The assertion is:

% break on pointer: 0x8dcbe38 hint: xy size: 259
Assertion triggered in void lyxbreaker(const void*, const char*, int)
by failing check "false" in file coordcache.C:30

This happens with the r13450 on RHEL4. Hope this helps.
Bo

Re: LyX/Mac bundle changes

[Bennett Helm]

On Mar 20, 2006, at 6:29 AM, Jean-Marc Lasgouttes wrote:


"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:


Bennett> (Note my question in the other thread
Bennett>  lyx-devel@lists.lyx.org/msg86805.html>: should the source for
Bennett> this (as an XCode project) go into the LyX source? I'd be
Bennett> happier if others more knowledgeable than I reviewed it. ...
Bennett> Sorry if I shouldn't have created a new thread for this)

Did I ever answer?


(No.)


I think the source would be better in the source, and that automatic
building would be even better. You can maybe find someone
knowledgeable enough to do it...


The source can be found here: .


Bennett

gtk frontend and gcc 4.1

[Ling Li]

Hi, it seems that this small patch is needed to compile gtk
frontend with gcc 4.1 (on fedora core 5).

--Ling
diff -ur lyx-1.4.0/src/frontends/gtk/GCharacter.h 
lyx-1.4.0/src/frontends/gtk/GCharacter.h
--- lyx-1.4.0/src/frontends/gtk/GCharacter.h2004-10-10 08:10:37.0 
-0700
+++ lyx-1.4.0/src/frontends/gtk/GCharacter.h2006-03-22 09:08:27.0 
-0800
@@ -65,7 +65,7 @@
 
Gtk::CheckButton * toggleallcheck_;
 
-   void GCharacter::onChange();
+   void onChange();
 };
 
 } // namespace frontend
diff -ur lyx-1.4.0/src/frontends/gtk/GtkLengthEntry.h 
lyx-1.4.0/src/frontends/gtk/GtkLengthEntry.h
--- lyx-1.4.0/src/frontends/gtk/GtkLengthEntry.h2006-02-06 
14:51:24.0 -0800
+++ lyx-1.4.0/src/frontends/gtk/GtkLengthEntry.h2006-03-22 
09:03:38.0 -0800
@@ -27,7 +27,7 @@
 
 class GtkLengthEntry : public Gtk::HBox {
 public:
-   GtkLengthEntry::GtkLengthEntry(BaseObjectType* cobject, const 
Glib::RefPtr& refGlade);
+   GtkLengthEntry(BaseObjectType* cobject, const 
Glib::RefPtr& refGlade);
 
void set_length(LyXLength const & length);
void set_length(std::string const & length);

Re: LyX 1.5 crash while scrolling

[Georg Baum]

Am Mittwoch, 22. März 2006 11:24 schrieb Juergen Spitzmueller:
> 1. Load the UserGuide
> 2. Scroll
> 
> => LyX crashes. Not reproducible with 1.4

This smells like a boost thing. Does it happen also if you compile against 
system boost? Do you have that at all? Or maybe with the boost directory 
of 1.4?


Georg

Re: [PATCH] better support for classes that do not define a ToC

[Georg Baum]

Am Mittwoch, 22. März 2006 15:39 schrieb Jean-Marc Lasgouttes:
 
> Comments? I'd like to apply it for 1.4.1. Then of course we'll have to
> fix the actual problem.

I think you should put that in. Even if we are going to fix the xurrent 
problems it will LyX make more robust wrt incomoplete layout files, which 
is a Good Thing (TM).


Georg

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Georg Baum]

Am Mittwoch, 22. März 2006 18:10 schrieb Martin Vermeer:

> Playing around with esvn... looks quite nice.

Does it work now? I researched several svn GUIS when we switched to svn at 
work, but back then (end of 2004 IIRC) none was usable (esvn kept 
crashing).


Georg

Re: [Qt4 bug] Branches dialog, small issue with "alter color"

[Georg Baum]

Am Mittwoch, 22. März 2006 18:47 schrieb Abdelrazak Younes:

> My point is that you shouldn't need to manipulate Colors outside the 
> frontend. But I am maybe missing something.

That might well be the case (I am not sure actually). If that is really 
true we can still reduce RGBColor to just three ints when we ditch 
xforms.


Georg

Re: Reproducible segmentation fault (LyX 1.4.0, Mac OS X)

[Martin Vermeer]

On Wed, Mar 22, 2006 at 09:09:31PM +0100, Georg Baum wrote:
> Am Mittwoch, 22. März 2006 18:10 schrieb Martin Vermeer:
> 
> > Playing around with esvn... looks quite nice.
> 
> Does it work now? I researched several svn GUIS when we switched to svn at 
> work, but back then (end of 2004 IIRC) none was usable (esvn kept 
> crashing).

No, it doesn't crash. This is 0.6.11-1 rpm.

There is the problem that entering userid and password don't work.
That's not really esvn's problem: it is due to ssh handling svn's
authentication, for svn+ssh that is. The only way around that that I saw
was putting my public key in aussie's authorized_keys.

I haven't yet worked a lot with it, but it looks pretty good, esp. for
browsing around. For committing stuff I still trust the command line
more.

- Martin
 


pgpzH4b8O5Zft.pgp
Description: PGP signature

Re: configure failure... (latest CVS) missing file?

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| One of these two fixes should work. The reason nobody noticed is that
| we already have tests/Makefile.in from earlier runs, I guess.
| 
| Index: src/frontends/controllers/Makefile.am
| ===
| --- src/frontends/controllers/Makefile.am (revision 13444)
| +++ src/frontends/controllers/Makefile.am (working copy)
| @@ -1,5 +1,7 @@
|  include $(top_srcdir)/config/common.am
|  
| +SUBDIRS = tests
| +
|  EXTRA_DIST = pch.h BCView.tmpl
|  
|  BUILT_SOURCES = $(PCH_FILE)

This is the correct fix.


-- 
Lgb

Re: [Ãpatch] RandomAccessList take 4

[Lars Gullik Bjønnes]

Andre Poenitz <[EMAIL PROTECTED]> writes:

| I guess we'll end up with a beautiful version using latest technology
| which won't fix the original problem (speed) but would look much nicer
| than any pragmatic and working solution.

I am not quite sure what high horse you have saddled yourself upon, but
please come down.

-- 
Lgb

Re: qt4: some colors messed up in preferences dialog

[Lars Gullik Bjønnes]

"Leuven, E." <[EMAIL PROTECTED]> writes:

| > Edwin, I noticed that you didn't commit your patch. I want to
| > do some cleanup that include your patch so I am going to commit
| > the attached patch.
| 
| sorry for that, but i haven't had the opportunity to commit since my old 
password doesn't seem to work. (lars is going to reset it, i hope...)

I will, I will. I only need 5 minutes of spare time...

-- 
Lgb

A Cygwin related patch

[Enrico Forestieri]

The attached patch fixes the bug reported here:
http://thread.gmane.org/gmane.editors.lyx.general/29227

In my intention this is the first of a series of patches aimed at polishing
the Cygwin target, which I think is lagging behind. Please, tell me if this
ok with you. I have no problem in maintaining the Cygwin target but my time
is limited so I cannot guarantee a continuous commitment. I will do it time
permitting. There should be no big problems, as I think the Cygwin users
will not be more than those I can count with only one of my hands ;-)

Do you prefer that I file this one on bugzilla?

-- 
Enrico


Index: src/support/os_unix.C
===
--- src/support/os_unix.C   (revision 13450)
+++ src/support/os_unix.C   (working copy)
@@ -97,6 +97,12 @@ char path_separator()
 void cygwin_path_fix(bool)
 {}
 
+
+bool cygwin_path_fix()
+{
+   return false;
+}
+
 } // namespace os
 } // namespace support
 } // namespace lyx
Index: src/support/os.h
===
--- src/support/os.h(revision 13450)
+++ src/support/os.h(working copy)
@@ -65,6 +65,7 @@ char path_separator();
  *  under Cygwin.
  */
 void cygwin_path_fix(bool use_cygwin_paths);
+bool cygwin_path_fix();
 
 } // namespace os
 } // namespace support
Index: src/support/filetools.C
===
--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,13 @@ string const latex_path(string const & o
latex_path_extension extension,
latex_path_dots dots)
 {
-   string path = subst(original_path, "\\", "/");
+   string path;
+
+   if (suffixIs(original_path, '/') && os::cygwin_path_fix())
+   path = os::external_path(original_path) + "/";
+   else
+   path = subst(original_path, "\\", "/");
+
path = subst(path, "~", "\\string~");
if (path.find(' ') != string::npos) {
// We can't use '"' because " is sometimes active (e.g. if
Index: src/support/os_win32.C
===
--- src/support/os_win32.C  (revision 13450)
+++ src/support/os_win32.C  (working copy)
@@ -265,6 +265,12 @@ void cygwin_path_fix(bool)
 {}
 
 
+bool cygwin_path_fix()
+{
+   return false;
+}
+
+
 namespace {
 
 void bail_out()
Index: src/support/os_cygwin.C
===
--- src/support/os_cygwin.C (revision 13450)
+++ src/support/os_cygwin.C (working copy)
@@ -146,6 +146,12 @@ void cygwin_path_fix(bool use_cygwin_pat
cygwin_path_fix_ = use_cygwin_paths;
 }
 
+
+bool cygwin_path_fix()
+{
+   return cygwin_path_fix_;
+}
+
 } // namespace os
 } // namespace support
 } // namespace lyx
Index: src/support/os_os2.C
===
--- src/support/os_os2.C(revision 13450)
+++ src/support/os_os2.C(working copy)
@@ -212,6 +212,12 @@ char path_separator()
 void cygwin_path_fix(bool)
 {}
 
+
+bool cygwin_path_fix()
+{
+   return false;
+}
+
 } // namespace os
 } // namespace support
 } // namespace lyx

Re: gtk frontend and gcc 4.1

[Georg Baum]

Am Mittwoch, 22. März 2006 20:41 schrieb Ling Li:
> Hi, it seems that this small patch is needed to compile gtk
> frontend with gcc 4.1 (on fedora core 5).

Thanks, I put it in both 1.4 and 1.5,since it is obviously right.


Georg

Log:
compile fix from Ling Li: remove superflous class name of members

Feature request: Remember the editing location when a file is closed.

[Bo Peng]

Dear list,

I am not sure if others will like this idea. When I edit a long file,
it may be troublesome to locate and continue from where I was working
on, after the file is re-opened. I would be happy if lyx can
automatically goes to the page at which lyx was closed.

I can think of two ways to do this:

1. (More intrusive). Remember the location under .lyx and jump to it
when a lyx file is opened. I think this is what vim is doing.

2. (Less intrusive). Save bookmark with the lyx file. A user can save
bookmark, close the file, and go to the bookmark after the file is
re-opened.

Cheers,
Bo

Re: Feature request: Remember the editing location when a file is closed.

[christian . ridderstrom]

On Wed, 22 Mar 2006, Bo Peng wrote:

> Dear list,
> 
> I am not sure if others will like this idea. When I edit a long file,
> it may be troublesome to locate and continue from where I was working
> on, after the file is re-opened. I would be happy if lyx can
> automatically goes to the page at which lyx was closed.
> 
> I can think of two ways to do this:
> 
> 1. (More intrusive). Remember the location under .lyx and jump to it
> when a lyx file is opened. I think this is what vim is doing.

For good or worse, this also means that when working with someone else on 
the same file (that's sent back and forth, or under version control), 
you'll open it up where the other person left off...

> 2. (Less intrusive). Save bookmark with the lyx file. A user can save
> bookmark, close the file, and go to the bookmark after the file is
> re-opened.

Maybe file a bugzilla report? Or if you're brave, discss which of the 
options would be best on the user's list :-)

/C

-- 
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: configure failure... (latest CVS) missing file?

[Kayvan A. Sylvan]

On Wed, Mar 22, 2006 at 09:35:16PM +0100, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> 
> | One of these two fixes should work. The reason nobody noticed is that
> | we already have tests/Makefile.in from earlier runs, I guess.
> | 
> | Index: src/frontends/controllers/Makefile.am
> | ===
> | --- src/frontends/controllers/Makefile.am   (revision 13444)
> | +++ src/frontends/controllers/Makefile.am   (working copy)
> | @@ -1,5 +1,7 @@
> |  include $(top_srcdir)/config/common.am
> |  
> | +SUBDIRS = tests
> | +
> |  EXTRA_DIST = pch.h BCView.tmpl
> |  
> |  BUILT_SOURCES = $(PCH_FILE)
> 
> This is the correct fix.

Yes. This gets me past the initial problem. Now there is a link issue (see
my other email).

Thanks.
-- 
Kayvan A. Sylvan  | Proud husband of   | Father to my kids:
Sylvan Associates, Inc.   | Laura Isabella Sylvan, | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | my beautiful Queen.| Robin Gregory (2/28/92)

Re: A Cygwin related patch

[Enrico Forestieri]

Enrico Forestieri <[EMAIL PROTECTED]> writes:

> 
> The attached patch fixes the bug reported here:
> http://thread.gmane.org/gmane.editors.lyx.general/29227
> 
> In my intention this is the first of a series of patches aimed at polishing
> the Cygwin target, which I think is lagging behind. Please, tell me if this
> ok with you. I have no problem in maintaining the Cygwin target but my time
> is limited so I cannot guarantee a continuous commitment. I will do it time
> permitting. There should be no big problems, as I think the Cygwin users
> will not be more than those I can count with only one of my hands 
> 
> Do you prefer that I file this one on bugzilla?

Here is a perhaps less obtrusive patch.

-- 
Enrico


Index: src/support/filetools.C
===
--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,16 @@ string const latex_path(string const & o
latex_path_extension extension,
latex_path_dots dots)
 {
-   string path = subst(original_path, "\\", "/");
+   string path;
+
+   if (suffixIs(original_path, '/')) {
+   // The call to os::external_path is needed for Cygwin.
+   path = subst(os::external_path(original_path), "\\", "/");
+   if (!suffixIs(path, '/'))
+   path += "/";
+   } else
+   path = subst(original_path, "\\", "/");
+
path = subst(path, "~", "\\string~");
if (path.find(' ') != string::npos) {
// We can't use '"' because " is sometimes active (e.g. if

Re: A Cygwin related patch

[Martin Vermeer]

On Wed, Mar 22, 2006 at 09:29:35PM +, Enrico Forestieri wrote:
> The attached patch fixes the bug reported here:
> http://thread.gmane.org/gmane.editors.lyx.general/29227
> 
> In my intention this is the first of a series of patches aimed at polishing
> the Cygwin target, which I think is lagging behind. Please, tell me if this
> ok with you. I have no problem in maintaining the Cygwin target but my time
> is limited so I cannot guarantee a continuous commitment. I will do it time
> permitting. There should be no big problems, as I think the Cygwin users
> will not be more than those I can count with only one of my hands ;-)

You would be amazed by the true number of LyX/Windows users...

Unfortunately I am unable / cannot be bothered to work on that, but I am
really happy somebody does. LyX adoption benefits greatly by having the
option of cross-platform collaborative authoring. And some people are
stuck on Windows.

BTW some of us are hit by symptoms like compulsive hand washing after
touching Windows. Another reason for admiring you ;-)

- Martin



pgphtPh5qNEUY.pgp
Description: PGP signature

[Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Bo Peng]

Dear list,

It does not look so difficult to implement this feature so I tried to
implement it by myself. Attached is my patch. Since I rarely submit a
patch here so I am afraid that there might be many problems (format,
logic, bugs). Please have a look and give me some feedbacks.

Many files have been modified:

src/BufferView_pimpl.C
When a new buffer is loaded, it tries to get last cursor position from
ref().lastfiles(). When a file is going to be closed, current location
is saved as bookmark 0, and to ref().lastfiles(). A side effect of
this is that a file can be re-opened (and to the same location) from
bookmark 0.

src/lastfiles.C:
I do not want to change the Files structure so I use a map to store
position information. lastfile format is changed to "
filename" if position information is available, and "filename" if not.
The biggest changes are to read/write lastfile. I hope that I have not
broken anything here.

src/lyxfunc.C:
   save cursor position when the buffer is closed.

lib/ui/stdmenus.ui:
   add a menu item with an awkard name.

I am worrying about two problem though:

1. Will invalid paragraph id, pos crash lyx? I mean, if a file is
saved (with id, pos saved locally), and is modified externally (get a
revised copy from others), id, pos will no longer be valid and "goto
bookmark 0" will fail.

2. Save position does not seem to work when I quit lyx by closing the
lyx window. Only close-buffer will do. Where should I handle the close
event?

3. Is saved_positions[0] really unused?

Cheers,
Bo
Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 13455)
+++ src/BufferView_pimpl.C	(working copy)
@@ -293,6 +293,14 @@
 
 	setBuffer(b);
 	bv_->showErrorList(_("Parse"));
+
+	// load position when the file was last closed
+	int id;
+	lyx::pos_type pos; 
+	LyX::ref().lastfiles().loadFilePosition(s, id, pos);
+	// if id is valid ...
+	if( id >= 0 )
+		saved_positions[0] = Position(s, id, pos);
 
 	if (tolastfiles)
 		LyX::ref().lastfiles().newFile(b->fileName());
@@ -767,7 +775,14 @@
 	saved_positions[i] = Position(buffer_->fileName(),
   cursor_.paragraph().id(),
   cursor_.pos());
-	if (i > 0)
+	// if i == 0, (called when this buffer is closed), 
+	// save current position to lastfile
+	if (i == 0) {
+		LyX::ref().lastfiles().saveFilePosition(buffer_->fileName(),
+cursor_.paragraph().id(), 
+cursor_.pos());
+}
+	else
 		owner_->message(bformat(_("Saved bookmark %1$d"), i));
 }
 
Index: src/lastfiles.C
===
--- src/lastfiles.C	(revision 13455)
+++ src/lastfiles.C	(working copy)
@@ -19,6 +19,11 @@
 #include 
 #include 
 
+// file_pos is a map to save position of cursor when a file is closed.
+#include 
+#include 
+#include 
+
 namespace fs = boost::filesystem;
 
 using std::copy;
@@ -26,10 +31,16 @@
 using std::find;
 using std::getline;
 using std::string;
+using std::map;
+using std::pair;
 using std::ifstream;
 using std::ofstream;
 using std::ostream_iterator;
 
+// store file position information to a map to avoid changing the 
+// dequeue structure Files
+typedef map > file_pos;
+file_pos filePositions;
 
 LastFiles::LastFiles(string const & filename, bool st, unsigned int num)
 	: dostat(st)
@@ -60,6 +71,22 @@
 	string tmp;
 
 	while (getline(ifs, tmp) && files.size() < num_files) {
+		//  filename\n
+		if (tmp[0] == '<' && tmp.find('>', 1) != string::npos ) {
+			std::istringstream itmp(tmp);
+			string fname;
+			int id;
+			lyx::pos_type pos;
+			itmp.ignore(1);  // ignore '<'
+			itmp >> id;
+			itmp.ignore(2);  // ignore ", "
+			itmp >> pos;
+			itmp.ignore(2);  // ingore  '> '
+			itmp >> fname;
+			filePositions[fname] = pair(id, pos);
+			tmp = fname;
+		}
+		// the last part of "<> file" or or lines without <>.
 		if (dostat && !fs::exists(tmp))
 continue;
 		files.push_back(tmp);
@@ -71,8 +98,18 @@
 {
 	ofstream ofs(filename.c_str());
 	if (ofs) {
-		copy(files.begin(), files.end(),
-		 ostream_iterator(ofs, "\n"));
+		for (const_iterator file=files.begin(); file != files.end(); ++file) {
+			// has position information, save in the format of 
+//  filename
+			file_pos::iterator entry = filePositions.find(*file);
+			if (entry != filePositions.end() )
+ofs << "<" << (*entry).second.first << ", " << 
+	(*entry).second.second << "> " << *file << endl;
+			// if not, simply save filename
+			else
+ofs << *file << endl;
+		}
+		ofs.close();
 	} else
 		lyxerr << "LyX: Warning: unable to save LastFiles: "
 		   << filename << endl;
@@ -90,7 +127,26 @@
 		files.pop_back();
 }
 
+void LastFiles::saveFilePosition(string const& fname, int id, lyx::pos_type pos ) const
+{
+	filePositions[fname] = pair(id, pos);
+}
 
+void LastFiles::loadFilePosition(string 

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Martin Vermeer]

On Wed, 2006-03-22 at 23:19 -0600, Bo Peng wrote:
> Dear list,
> 
> It does not look so difficult to implement this feature so I tried to
> implement it by myself. Attached is my patch. Since I rarely submit a
> patch here so I am afraid that there might be many problems (format,
> logic, bugs). Please have a look and give me some feedbacks.

Format looks OK. The logic is a bit ad-hoc, but that comes with the
territory.

Others may give detailed feedback on the code.

> Many files have been modified:
> 
> src/BufferView_pimpl.C
> When a new buffer is loaded, it tries to get last cursor position from
> ref().lastfiles(). When a file is going to be closed, current location
> is saved as bookmark 0, and to ref().lastfiles(). A side effect of
> this is that a file can be re-opened (and to the same location) from
> bookmark 0.
> 
> src/lastfiles.C:
> I do not want to change the Files structure so I use a map to store
> position information. lastfile format is changed to "
> filename" if position information is available, and "filename" if not.

Would it be easier to always have the  filename format? And id
= pos = 0 if no valid info exists, so current behaviour is reproduced?

> The biggest changes are to read/write lastfile. I hope that I have not
> broken anything here.
> 
> src/lyxfunc.C:
>save cursor position when the buffer is closed.
> 
> lib/ui/stdmenus.ui:
>add a menu item with an awkard name.
> 
> I am worrying about two problem though:
> 
> 1. Will invalid paragraph id, pos crash lyx? I mean, if a file is
> saved (with id, pos saved locally), and is modified externally (get a
> revised copy from others), id, pos will no longer be valid and "goto
> bookmark 0" will fail.

This is a file format change and lyx2lyx must be made to handle it.

+// not found, return invalid id number
+   else {
+   id = -1;
+   pos = 0;
+   }

Please don't do this ;-)

It won't be needed if we change and handle the new file format.

> 2. Save position does not seem to work when I quit lyx by closing the
> lyx window. Only close-buffer will do. Where should I handle the close
> event?

Don't bother. That's not the way to leave LyX.

> 3. Is saved_positions[0] really unused?

No, it's used in at least two other places.

1) To save the main document position to return to when opening a child
2) To save the return (ref) position when jumping to a label.

Neither interferes with your use, I think.

So you're not the first to have this brilliant idea :-)

> Cheers,
> Bo

Welcome to the club!

Regards Martin



signature.asc
Description: This is a digitally signed message part

[patch] remove wheel mouse ui from qt2

[Juergen Spitzmueller]

The attached patch finally eliminates the gui element.
I did not touch qt4, since Abdel is reorganizing the Prefs dialog currently. 
Abdel, while you are at it, could you please remove the wheel mouse spinbox?

OK to apply to branch and trunk?


* src/frontends/qt2/QPrefs.C
(void QPrefs::apply):
(void QPrefs::update_contents):
* src/frontends/qt2/QPrefsDialog.C
(QPrefsDialog::QPrefsDialog):
* src/frontends/qt2/ui/QPrefUIModule.ui:  remove wheel mouse spin box   
(bug 783).


Jürgen 
Index: src/frontends/qt2/QPrefs.C
===
--- src/frontends/qt2/QPrefs.C	(Revision 13455)
+++ src/frontends/qt2/QPrefs.C	(Arbeitskopie)
@@ -174,7 +174,6 @@ void QPrefs::apply()
 	rc.ui_file = internal_path(uimod->uiFileED->text());
 	rc.bind_file = internal_path(uimod->bindFileED->text());
 	rc.cursor_follows_scrollbar = uimod->cursorFollowsCB->isChecked();
-	rc.wheel_jump = uimod->wheelMouseSB->value();
 	rc.autosave = uimod->autoSaveSB->value() * 60;
 	rc.make_backup = uimod->autoSaveCB->isChecked();
 	rc.num_lastfiles = uimod->lastfilesSB->value();
@@ -496,7 +495,6 @@ void QPrefs::update_contents()
 	uimod->uiFileED->setText(external_path(rc.ui_file));
 	uimod->bindFileED->setText(external_path(rc.bind_file));
 	uimod->cursorFollowsCB->setChecked(rc.cursor_follows_scrollbar);
-	uimod->wheelMouseSB->setValue(rc.wheel_jump);
 	// convert to minutes
 	int mins(rc.autosave / 60);
 	if (rc.autosave && !mins)
Index: src/frontends/qt2/QPrefsDialog.C
===
--- src/frontends/qt2/QPrefsDialog.C	(Revision 13455)
+++ src/frontends/qt2/QPrefsDialog.C	(Arbeitskopie)
@@ -229,7 +229,6 @@ QPrefsDialog::QPrefsDialog(QPrefs * form
 	connect(uiModule->uiFileED, SIGNAL(textChanged(const QString&)), this, SLOT(change_adaptor()));
 	connect(uiModule->bindFileED, SIGNAL(textChanged(const QString&)), this, SLOT(change_adaptor()));
 	connect(uiModule->cursorFollowsCB, SIGNAL(toggled(bool)), this, SLOT(change_adaptor()));
-	connect(uiModule->wheelMouseSB, SIGNAL(valueChanged(int)), this, SLOT(change_adaptor()));
 	connect(uiModule->autoSaveSB, SIGNAL(valueChanged(int)), this, SLOT(change_adaptor()));
 	connect(uiModule->autoSaveCB, SIGNAL(toggled(bool)), this, SLOT(change_adaptor()));
 	connect(uiModule->lastfilesSB, SIGNAL(valueChanged(int)), this, SLOT(change_adaptor()));
Index: src/frontends/qt2/ui/QPrefUIModule.ui
===
--- src/frontends/qt2/ui/QPrefUIModule.ui	(Revision 13455)
+++ src/frontends/qt2/ui/QPrefUIModule.ui	(Arbeitskopie)
@@ -13,7 +13,7 @@
 
 0
 0
-416
+412
 441
 
 
@@ -26,9 +26,9 @@
 
 
 caption
-
+QPrefUIModule
 
-
+
 
 margin
 11
@@ -37,90 +37,7 @@
 spacing
 6
 
-
-QLayoutWidget
-
-name
-Layout2
-
-
-
-margin
-0
-
-
-spacing
-6
-
-
-QPushButton
-
-name
-bindFilePB
-
-
-text
-Browse...
-
-
-
-QLabel
-
-name
-uiFileLA
-
-
-text
-User interface file:
-
-
-buddy
-uiFileED
-
-
-
-QLabel
-
-name
-bindFileLA
-
-
-text
-Bind file:
-
-
-buddy
-bindFileED
-
-
-
-QLineEdit
-
-name
-uiFileED
-
-
-
-QPushButton
-
-name
-uiFilePB
-
-
-text
-Browse...
-
-
-
-QLineEdit
-
-name
-