On Tue, Jul 31, 2007 at 03:34:53PM +1000, Darren Freeman wrote:
On Mon, 2007-07-30 at 22:41 -0600, Bob Lounsbury wrote:
That's strange. I have an Athlon XP 2000+ with 1GB of RAM, and I have
not noticed any slowness at all. I wonder if it has anything to do
with the graphics card. This
On Tue, 2007-07-31 at 10:08 +0300, Martin Vermeer wrote:
On Tue, Jul 31, 2007 at 03:34:53PM +1000, Darren Freeman wrote:
I have a Radeon 9200SE.
It is certainly using DRI at 24bpp.
I can't test the X settings hypothesis right now as I have a lot of
unsaved work open. Sounds likely
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
José got the mail, but it didn't include the crucial information, apparently
(and José was in a hurry himself).
Anyway, now you're back. You see, we missed you ;-)
That was the plan.
JMarc
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
Jean-Marc Lasgouttes wrote:
Didn't you forget the Makefile.am entry?
Indeed. Thanks.
FWIW, this is one of the thing you should be careful about when
looking at commits by others to the 1.5 branch. Missing makefil
entries can make you look very
Enrico Forestieri wrote:
I will not do neither of what you suggest. I will simply replace
that portion of code with other code adapted from the Forestieri
library as shown in the attached patch.
Even better.
I am picky about licenses because I expect people to respect the licenses of
my own
Martin Vermeer wrote:
We already have that: charstyles, which are however pretty
limited. But they could be extended (under a different name
probably, style insets?)
Could something like that do the trick for beamer? (I haven't
used beamer myself . . .)
Would be a partial solution
Enrico Forestieri [EMAIL PROTECTED] writes:
I think this is just for the records. While playing with a xforms
build I discovered that both the math matrix and the math delimiters
dialogs are broken. The bug was introduced way back in november by
r15901 and nobody has reported it since then,
Bo Peng [EMAIL PROTECTED] writes:
On 7/26/07, Bo Peng [EMAIL PROTECTED] wrote:
Going the other way is even worse - mark something in
LyX 1.5.0 (released) and you (usually) can't paste it into thunderbird.
Could you please test the attached patch?
JMarc and I tried to move numerous
On Tue, Jul 31, 2007 at 09:52:58AM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
I will not do neither of what you suggest. I will simply replace
that portion of code with other code adapted from the Forestieri
library as shown in the attached patch.
Even better.
I am picky
Martin Vermeer wrote:
...and more importantly, you just confirmed my diagnosis of
the problem. There is something in qt, or LyX's use of qt,
that responds very badly to DRI both being turned on and
practically unusable.
Clearly, qt4 think it is clever to use DRI for some things when it
is
Bo Peng [EMAIL PROTECTED] writes:
Jose, can you wait a bit for the fix of this one? Should be a one
liner somewhere.
I submitted a quick fix (r19199). It can be reverted if JMarc has some
better idea.
Here is the fix I would propose. It ensures that the cursor is set
through
Michael Gerz [EMAIL PROTECTED] writes:
Why are these file back? AFAIK they are unused and thus their messages
should not appear in the po files.
Well, po/Makefile.in.in does sees them, and thus they appear. There is
not much I can do about it. If the files areally unused, shouldn't
they be
Martin Vermeer [EMAIL PROTECTED] writes:
OK, that's agreed. Around 15 o'clock at the Arrivals meeting point
(I think there is such a beast).
Great! I suppose I will be there around 15h20, since I'll have to pick
up my luggage (I assume the new regulation will force me to do so...).
Looking
Bo Peng [EMAIL PROTECTED] writes:
qt will find qt_zh.pm for language_name = qt_zh_CN, but the other way
around. Can I remove the language_name.truncate(5) line?
Yes, you should definitely.
JMarc
Richard Heck [EMAIL PROTECTED] writes:
I've uploaded a patch to bugzilla
http://bugzilla.lyx.org/show_bug.cgi?id=3309#c3
that adds collapsible character styles, so you can do this:
[...]
and suddenly have your very own endnote inset. Comments welcome.
I do not like the idea of abusing the
Bennett Helm [EMAIL PROTECTED] writes:
On Jul 16, 2007, at 1:46 PM, Abdelrazak Younes wrote:
One additional (minor) problem I've noticed: if you start with a
saved file, and then use pdfsync to jump to a location in that
file, it marks the file as changed. Shall I file this as a
separate bug
Bo Peng wrote:
Will it be possible to add child documents as well? Assuming
you get the permissions, of course.
It is not considered now, but I will see what I can do later. With
separate .lyx files, you can open a child document without loading the
master one. Embedding child documents
On Tue, 2007-07-31 at 12:28 +0200, Helge Hafting wrote:
A user with trouble can run glxinfo. If one of the first lines
says direct rendering: no, then software DRI is in use, and
commenting out DRI from the Module section in xorg.conf
will fix the performance problem.
I don't think it's as
Darren Freeman wrote:
On Tue, 2007-07-31 at 12:28 +0200, Helge Hafting wrote:
A user with trouble can run glxinfo. If one of the first lines
says direct rendering: no, then software DRI is in use, and
commenting out DRI from the Module section in xorg.conf
will fix the performance problem.
Clearly, qt4 think it is clever to use DRI for some things when it
is available. It is probably faster than standard X when hardware
is used for DRI, but much slower when the software fallback is used.
wait a little - if i didnt overlook something Bob has not confirmed
this is hard x soft
On Tue, Jul 31, 2007 at 01:03:24PM +0200, Jean-Marc Lasgouttes wrote:
Richard Heck [EMAIL PROTECTED] writes:
I've uploaded a patch to bugzilla
http://bugzilla.lyx.org/show_bug.cgi?id=3309#c3
that adds collapsible character styles, so you can do this:
[...]
and suddenly have your
On Tue, Jul 31, 2007 at 12:28:31PM +0200, Helge Hafting wrote:
Martin Vermeer wrote:
...and more importantly, you just confirmed my diagnosis of
the problem. There is something in qt, or LyX's use of qt,
that responds very badly to DRI both being turned on and
practically unusable.
Helge Hafting [EMAIL PROTECTED] writes:
I see. But wouldn't it be simpler to just store the subdirectory
then? Zip supports subdirectories, and then you don't
need to program name mangling. With bad luck, there
might be a _l_nameclash.eps file too, occuring before
or after the
Jean-Marc Lasgouttes wrote:
Bo, Juergen, José?
Fine with me. If Bo agrees, you can commit to branch (Ha!).
Jürgen
I submitted a quick fix (r19199). It can be reverted if JMarc has some
better idea.
Here is the fix I would propose. It ensures that the cursor is set
through BufferView::mouseSetCursor, so that the selection is always
tracked correctly. The patch is a little longer because I used the
No, because the file could be ../a/nameclash.eps (or maybe I
misunderstand something).
I did not use subdirectories mainly because I am afraid of absolute
pathnames. For example, /path/a/A.lyx having figure
/path1/b/figure.eps. I do not know how to save figure.eps in the zip
file.
Bo
Bo, I am surprised that these haveSelection calls are useful, since it
is done in the master LyXFunc::dispatch. What is the problem?
I did not have enough time to investigate, but without my patch (which
does not work properly either), mouse selection, table selection does
not reach the
Bo Peng [EMAIL PROTECTED] writes:
Please commit to trunk so that it can be thoroughly tested.
I did so. All comments are welcome (especially since the code path is
not exactly as it was). In particular, I got rid of paset_internally
because it does not seem useful anymore, but this might have
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
Jean-Marc Lasgouttes wrote:
Bo, Juergen, José?
Fine with me. If Bo agrees, you can commit to branch (Ha!).
I committed to trunk for now, master.
JMarc
Jean-Marc Lasgouttes wrote:
I committed to trunk for now, master.
Well done, son.
Jürgen
Enrico Forestieri wrote:
I do not think that a new 1.4 version will ever be done, but I think
you should apply the patch to the branch nevertheless.
I did it.
perhaps we can make the patch publically available, for the people who rely on
xforms.
Jürgen
On Tue, Jul 31, 2007 at 12:02:21PM +0200, Jean-Marc Lasgouttes wrote:
Enrico Forestieri [EMAIL PROTECTED] writes:
I think this is just for the records. While playing with a xforms
build I discovered that both the math matrix and the math delimiters
dialogs are broken. The bug was introduced
Public release of LyX version 1.4.5.1
=
We are pleased to announce the release of LyX 1.4.5.1. This is expected
to be the last release in the 1.4.x stable branch. Besides the
obligatory bug fixes, its main feature is the ability to read files
created by LyX
Yes, you should definitely.
Jurgen,
Trunk and branch?
Index: src/frontends/qt4/GuiApplication.cpp
===
--- src/frontends/qt4/GuiApplication.cpp(revision 19253)
+++ src/frontends/qt4/GuiApplication.cpp(working copy)
Public release of LyX version 1.5.0
===
We are pleased to announce the release of LyX 1.5.0.
Since the announcement of release candidate 2, we have fixed bugs and
we have updated the documentation.
Following the ad hoc tradition of 1.5.0 pre-releases, called
Bo Peng wrote:
Jurgen,
Trunk and branch?
OK.
Jürgen
Hartmut Haase [EMAIL PROTECTED] writes:
Jean-Marc,
would you please change in Help-About LyX-Credits my email-address to the
one below.
Hi Hartmut,
I just did that.
JMarc
Bo Peng wrote:
No, because the file could be ../a/nameclash.eps (or maybe I
misunderstand something).
I did not use subdirectories mainly because I am afraid of absolute
pathnames. For example, /path/a/A.lyx having figure
/path1/b/figure.eps. I do not know how to save figure.eps in the
Martin Vermeer wrote:
On Tue, Jul 31, 2007 at 12:28:31PM +0200, Helge Hafting wrote:
Martin Vermeer wrote:
...and more importantly, you just confirmed my diagnosis of
the problem. There is something in qt, or LyX's use of qt,
that responds very badly to DRI both being turned on and
On 7/31/07, Pavel Sanda [EMAIL PROTECTED] wrote:
Clearly, qt4 think it is clever to use DRI for some things when it
is available. It is probably faster than standard X when hardware
is used for DRI, but much slower when the software fallback is used.
wait a little - if i didnt overlook
On Tue, Jul 31, 2007 at 03:34:53PM +1000, Darren Freeman wrote:
On Mon, 2007-07-30 at 22:41 -0600, Bob Lounsbury wrote:
That's strange. I have an Athlon XP 2000+ with 1GB of RAM, and I have
not noticed any slowness at all. I wonder if it has anything to do
with the graphics card. This
On Tue, Jul 31, 2007 at 12:28:31PM +0200, Helge Hafting wrote:
Martin Vermeer wrote:
...and more importantly, you just confirmed my diagnosis of
the problem. There is something in qt, or LyX's use of qt,
that responds very badly to DRI both being turned on and
practically unusable.
Jürgen Spitzmüller wrote:
Richard Heck wrote:
Attached is a patch that addresses the outstanding issues. Tested and
working on Linux (FC6). Tim says there are issues on Ubuntu, but that
seems an Ubuntu issue. Can anyone test on Wintel and Mac?
Works for me.
Committed to trunk and
Enrico Forestieri wrote:
On Tue, Jul 31, 2007 at 09:52:58AM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
I will not do neither of what you suggest. I will simply replace
that portion of code with other code adapted from the Forestieri
library as shown in the attached patch.
Jean-Marc Lasgouttes wrote:
Bo Peng [EMAIL PROTECTED] writes:
Jose, can you wait a bit for the fix of this one? Should be a one
liner somewhere.
I submitted a quick fix (r19199). It can be reverted if JMarc has some
better idea.
Here is the fix I would propose. It ensures that
Richard Heck wrote:
Committed to trunk and branch.
Update status.15x, please.
Jürgen
Hi Troy,
Ars Technica Open Ended wrote:
Hola Juergen,
I'm going to write up this release for Ars Technica over the next few
days (short blurb, like 300 words) since I think it's a big enough
milestone to warrant a little press.
Great!
I was wondering if I have permission to use the logo
On Tue, Jul 31, 2007 at 05:24:13PM +0200, Helge Hafting wrote:
Martin Vermeer wrote:
...
Is a workaround possible for LyX?
I assume you don't want make install to modify xorg.conf. :-)
A grep through qt4 documentation came up with:
void QGLFormat::setDirectRendering (
So this is the second report on corrupted compressed .lyx files within
a week. Maybe it's time to revert the boost zipping stuff.
I can confirm this problem under windows, but not under linux. It
might be a zlib windows packaging problem or a boost::iostreams bug,
who knows.
But this is a
On Tue, Jul 31, 2007 at 05:24:13PM +0200, Helge Hafting wrote:
I assume you don't want make install to modify xorg.conf. :-)
A grep through qt4 documentation came up with:
void QGLFormat::setDirectRendering ( bool /enable/ )
We do not use _any_ QGL* stuff in LyX. We also do not like
In the meantime I came to believe so as well. So why did we rip off
zlib initially?
Isn't this boost::iostreams thing beautiful? At least to me, the
elegency of the following code was the biggest reason to replace
gzstream with boost::iostreams.
if (compressed)
Please provide me with a patch to make LyX 1.5.0 use zlib again. The
Windows installer still includes zlib, so no other changes are needed. I
will then release 1.5.0-2.
But I am not sure if the zlib way is compatible with the iostreams
compressed files, which can be properly used under linux.
Attached is the latest patch addressing this bug. I'm seeking agreement
to commit it to trunk, for testing, prior to committing to branch,
hopefully for 1.5.2. This has been discussed with Jurgen already. JMarc,
or someone else: Does this seem OK?
If this does go in, I'll shortly start
With the patch this time.
Attached is the latest patch addressing this bug. I'm seeking agreement
to commit it to trunk, for testing, prior to committing to branch,
hopefully for 1.5.2. This has been discussed with Jurgen already. JMarc,
or someone else: Does this seem OK?
If this does go in,
My suggestion is to remove this menu item for now (and only under
windows), using the following patch. How to properly fix this issue is
something for Jose/Jurgen to decide.
By the way, if you would also like to prevent the case of open
compressed file generated under linux, save a corrupted
Bo Peng wrote:
But I am not sure if the zlib way is compatible with the iostreams
compressed files, which can be properly used under linux.
LyX 1.4.5 still uses zlib, right? Does this mean that 1.5.0 is not able
to open compressed files created by 1.4.5?
Joost
On 7/31/07, Joost Verburg [EMAIL PROTECTED] wrote:
Bo Peng wrote:
But I am not sure if the zlib way is compatible with the iostreams
compressed files, which can be properly used under linux.
LyX 1.4.5 still uses zlib, right? Does this mean that 1.5.0 is not able
to open compressed files
Maybe it could be better to write own iostream with zlib compression? Or you
could find one in the net?
The Boost problem might be some deep into cacheing/buffering the output.
Even more - implementation of STL might cause problems under Windows :-(
1.4.x uses that approach, and we switched
Bo Peng wrote:
Unfortunately yes. I just checked that 1.5.0/win can not even open a
properly compressed .lyx file created under linux.
So the format of compressed files has also been changed on Linux? Then I
think 1.5.1 should be released quickly and use zlib for compression
again. Otherwise
Bo Peng wrote:
Unfortunately yes. I just checked that 1.5.0/win can not even open a
properly compressed .lyx file created under linux.
So the format of compressed files has also been changed on Linux?
I do not think so. The problem is with windows. I do not really want
to revert to
This patch is now updated to current trunk. Jurgen?
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my
Is software rendering the same as DRI? If so, then yes with DRI on
no it is not. afaik this is possible under X:
1) DRI on
a) hardware render
b) software render
2) DRI off
the question was, whether 1a is fast while 1b is slow.
for my current system configuration it seems not much
Jean-Marc Lasgouttes wrote:
Richard Heck [EMAIL PROTECTED] writes:
I've uploaded a patch to bugzilla
http://bugzilla.lyx.org/show_bug.cgi?id=3309#c3
that adds collapsible character styles, so you can do this:
[...]
and suddenly have your very own endnote inset. Comments
On 7/31/07, Pavel Sanda [EMAIL PROTECTED] wrote:
Is software rendering the same as DRI? If so, then yes with DRI on
no it is not. afaik this is possible under X:
1) DRI on
a) hardware render
Can't say that I notice any difference in hardware render, but also
not sure how to judge this.
b) software render
LyX is slower in this mode, but a program like Stellarium is fast.
hmmm... stellarium fast in this mode ? how do you diagnose being in 1b ?
pavel
Bo Peng wrote:
Bo Peng wrote:
Unfortunately yes. I just checked that 1.5.0/win can not even open a
properly compressed .lyx file created under linux.
So the format of compressed files has also been changed on Linux?
I do not think so. The problem is with windows. I do not really want
to
Joost,
Attached please find a patch, against 1.5.0tag, that use gzstream (the
one 1.4.x uses) instead of boost::iostreams. The only thing I can say
is that it compiles, and can open a compressed file (by 1.5.0) under
linux. I do not have a good windows environment to test so I will
leave this
On 7/31/07, Pavel Sanda [EMAIL PROTECTED] wrote:
b) software render
LyX is slower in this mode, but a program like Stellarium is fast.
hmmm... stellarium fast in this mode ? how do you diagnose being in 1b ?
I diagnose LyX using a 100 page thesis with ~60 figures and some math.
I check
Richard Heck wrote:
Jean-Marc Lasgouttes wrote:
I do not like the idea of abusing the CharStyle inset to become a
do-it-all inset. If we go this way, we should make a more general
customizable inset and let CharStyle derive from it.
Do you mean in the code or in the layout file or both?
OK,
Here's this patch updated to the current trunk. Jurgen?
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get
b) software render
LyX is slower in this mode, but a program like Stellarium is fast.
hmmm... stellarium fast in this mode ? how do you diagnose being in 1b ?
I diagnose LyX using a 100 page thesis with ~60 figures and some math.
I check the speed by opening a figure float and
Richard Heck [EMAIL PROTECTED] writes:
But should they also be
differently defined in the layout file? I.e., should it be more like:
CollapsibleInset Endnote
LatexName endnote
rather than using CharStyle here, too?
Actually, I would also define things like footnotes like that, to
On Tue, Jul 31, 2007 at 01:09:55PM -0500, Bo Peng wrote:
So this is the second report on corrupted compressed .lyx files within
a week. Maybe it's time to revert the boost zipping stuff.
I can confirm this problem under windows, but not under linux. It
might be a zlib windows packaging
On Tue, Jul 31, 2007 at 03:00:34PM -0400, Richard Heck wrote:
Index: src/Buffer.h
===
--- src/Buffer.h (revision 19264)
+++ src/Buffer.h (working copy)
@@ -13,7 +13,11 @@
#define BUFFER_H
#include DocIterator.h
On Tue, Jul 31, 2007 at 02:24:17PM -0500, Bo Peng wrote:
On 7/31/07, Joost Verburg [EMAIL PROTECTED] wrote:
Bo Peng wrote:
But I am not sure if the zlib way is compatible with the iostreams
compressed files, which can be properly used under linux.
LyX 1.4.5 still uses zlib, right?
On Tue, Jul 31, 2007 at 02:25:59PM -0500, Bo Peng wrote:
Maybe it could be better to write own iostream with zlib compression? Or you
could find one in the net?
The Boost problem might be some deep into cacheing/buffering the output.
Even more - implementation of STL might cause problems
Andre Poenitz [EMAIL PROTECTED] writes:
On Tue, Jul 31, 2007 at 02:25:59PM -0500, Bo Peng wrote:
Maybe it could be better to write own iostream with zlib compression? Or
you
could find one in the net?
The Boost problem might be some deep into cacheing/buffering the output.
Even more
On Tue, Jul 31, 2007 at 10:15:58PM +0200, Joost Verburg wrote:
Bo Peng wrote:
Bo Peng wrote:
Unfortunately yes. I just checked that 1.5.0/win can not even open a
properly compressed .lyx file created under linux.
So the format of compressed files has also been changed on Linux?
I do not
You want me to remove all traces of 1.5.0? Or only the windows
version?
Just remove the windows installers. Joost is trying out a patch I sent
to him (revert to gzstream used in 1.4.x). If it works, he can release
an updated installer with the patch.
Then, we can see if updating boost can
Bo Peng [EMAIL PROTECTED] writes:
You want me to remove all traces of 1.5.0? Or only the windows
version?
Just remove the windows installers. Joost is trying out a patch I sent
to him (revert to gzstream used in 1.4.x). If it works, he can release
an updated installer with the patch.
Then,
On Jul 31, 2007, at 7:09 AM, Jean-Marc Lasgouttes wrote:
Bennett Helm [EMAIL PROTECTED] writes:
On Jul 16, 2007, at 1:46 PM, Abdelrazak Younes wrote:
One additional (minor) problem I've noticed: if you start with a
saved file, and then use pdfsync to jump to a location in that
file, it marks
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
I made all the files unreadable. And added a short announcement to the
web site.
And I think we can wait until tomorrow for further action.
On Tue, Jul 31, 2007 at 11:14:23PM +0200, Jean-Marc Lasgouttes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
On Tue, Jul 31, 2007 at 02:25:59PM -0500, Bo Peng wrote:
Maybe it could be better to write own iostream with zlib compression? Or
you
could find one in the net?
The
On Tue, Jul 31, 2007 at 11:39:08PM +0200, Jean-Marc Lasgouttes wrote:
Bo Peng [EMAIL PROTECTED] writes:
You want me to remove all traces of 1.5.0? Or only the windows
version?
Just remove the windows installers. Joost is trying out a patch I sent
to him (revert to gzstream used in
Bo Peng wrote:
If your windows build, with this patch, can open the attached
FAQ_comp.lyx (compressed with lyx 1.5.0 linux, official), and maybe a
1.4.x compressed file, you can release 1.5.0-1 with compression
enabled. Otherwise, please disable compression.
With this patch things seem to work
You want me to remove all traces of 1.5.0? Or only the windows
version?
at least for linux this is not possible, 1.5.0 tarballs already flying
mirrored over the net.
pavel
On 7/31/07, Pavel Sanda [EMAIL PROTECTED] wrote:
You want me to remove all traces of 1.5.0? Or only the windows
version?
at least for linux this is not possible, 1.5.0 tarballs already flying
mirrored over the net.
And this is not needed because only windows builds have this problem.
I
I just noticed that the following patch (which was accepted by José,
I think) just did
not get committed.
José, Juergen, can I commit it (trunk and branch)?
JMarc
pkgconfig.diff
Description: Binary data
Bennett Helm [EMAIL PROTECTED] writes:
Does the following one-liner help?
Yes -- that does it. Thanks.
José, Jürgen, can I apply to trunk and branch. It is truly trivial.
JMarc
Jean-Marc Lasgouttes wrote:
Richard Heck [EMAIL PROTECTED] writes:
But should they also be
differently defined in the layout file? I.e., should it be more like:
CollapsibleInset Endnote
LatexName endnote
rather than using CharStyle here, too?
Actually, I would also define
On Mon, 30 Jul 2007, Paul A. Rubin wrote:
[EMAIL PROTECTED] wrote:
As a side note, it's perfectly possible to add an enhancement request to
bugzilla, post a tweaked layout to bugzilla, and then refer to the tweaked
layout in bugzilla from within a wiki page. Not sure if it helps, but it
On Tue, 2007-07-31 at 18:12 +0200, Andre Poenitz wrote:
On Tue, Jul 31, 2007 at 03:34:53PM +1000, Darren Freeman wrote:
On Mon, 2007-07-30 at 22:41 -0600, Bob Lounsbury wrote:
That's strange. I have an Athlon XP 2000+ with 1GB of RAM, and I have
not noticed any slowness at all. I wonder
On Tue, 2007-07-31 at 00:00 +0300, Martin Vermeer wrote:
...and more importantly, you just confirmed my diagnosis of
the problem. There is something in qt, or LyX's use of qt,
that responds very badly to DRI both being turned on and
practically unusable.
Could all who are interested in this
I just compiled lyx against boost 1.34.1. Unfortunately, the problem
persists. So, unless someone can write to boost-devel, and be advised
with the correct way to write/build boost::iostreams under windows, we
have to revert to gzstreams for 1.5.1.
Bo
[EMAIL PROTECTED] wrote:
Your approach is valid, but somewhat unsafe as others may alter your
layout with no reasonable trace. Yes, this is a drawback with the
current system, but difficult to do something about.
Well, if you're worrying about there being untrustworthy LyXers out
there,
Andre Poenitz wrote:
On Tue, Jul 31, 2007 at 03:00:34PM -0400, Richard Heck wrote:
Index: src/Buffer.h
===
--- src/Buffer.h(revision 19264)
+++ src/Buffer.h(working copy)
@@ -13,7 +13,11 @@
#define BUFFER_H
Jean-Marc Lasgouttes wrote:
José, Jürgen, can I apply to trunk and branch. It is truly trivial.
OK.
Jürgen
Richard Heck wrote:
This patch is now updated to current trunk. Jurgen?
If it's well tested (which I believe it is), this can go in branch and trunk.
But please wait with branch until the compression issue is sorted out.
BTW as I wrote in bugzilla it would be nice if the tabs also reflected
Richard Heck wrote:
Here's this patch updated to the current trunk. Jurgen?
Same as for bug 2840: If it's well tested, this can go in branch and trunk.
But please wait with branch until the compression issue is sorted out.
Jürgen
Jean-Marc Lasgouttes wrote:
José, Juergen, can I commit it (trunk and branch)?
Yes.
Jürgen
1 - 100 of 200 matches
Mail list logo
