On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
Hi,
I couldn't really understand what information is
stored inside the BufferView.offset_ref_ variable.
At a first glance, it would seem that anchor_ref_
stores the paragraph offset that is displayed from
the WorkArea top
On Sat, Sep 15, 2007 at 11:36:37PM -0500, Bo Peng wrote:
Can I make the label of InsetIndex more meaningful by displaying
'Idx:name' instead of 'Idx'?
A simple patch is attached. I will commit it if there is no objection
in one day.
Bo
Hmmm, what does name stand for? The content of the
On Sat, Sep 15, 2007 at 11:36:37PM -0500, Bo Peng wrote:
Can I make the label of InsetIndex more meaningful by displaying
'Idx:name' instead of 'Idx'?
A simple patch is attached. I will commit it if there is no objection
in one day.
... and for the closed inset, you can leave out the Idx:
On Sat, Sep 15, 2007 at 11:36:37PM -0500, Bo Peng wrote:
Can I make the label of InsetIndex more meaningful by displaying
'Idx:name' instead of 'Idx'?
I don't mind.
A simple patch is attached. I will commit it if there is no objection
in one day.
Only stylistic.
Index:
On Sun, Sep 16, 2007 at 09:00:50AM +0300, Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
Hi,
I couldn't really understand what information is
stored inside the BufferView.offset_ref_ variable.
At a first glance, it would seem that anchor_ref_
Abdelrazak Younes wrote:
This should go in branch Jurgen. It is I think the right fix for bug 4178.
Looks good. Please commit.
Jürgen
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
Hi,
I couldn't really understand what information is
stored inside the BufferView.offset_ref_ variable.
At a first glance, it would seem that anchor_ref_
stores the paragraph offset that is displayed from
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
This should go in branch Jurgen. It is I think the right fix for bug 4178.
Looks good. Please commit.
Done.
Abdel.
On Sun, Sep 16, 2007 at 10:41:21AM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
Hi,
I couldn't really understand what information is
stored inside the BufferView.offset_ref_ variable.
At a first glance, it would
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 10:41:21AM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
Hi,
I couldn't really understand what information is
stored inside the BufferView.offset_ref_ variable.
At a first
Abdelrazak Younes wrote:
Done.
Thanks. This also fixes the crash I encountered in bug 4082 (I cannot
reproduce the crash originally reported).
Jürgen
I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
trunk), and got both some new warnings and a few errors. This patch
fixes those.
The main variants of warnings/errors:
* Ambigous else
* Ambigous logical operators
* Headers in libstdc++ cleanup,
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
| trunk), and got both some new warnings and a few errors. This patch
| fixes those.
|
| The main variants of warnings/errors:
| * Ambigous else
| * Ambigous
On Sun, Sep 16, 2007 at 11:35:09AM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 10:41:21AM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
Hi,
I couldn't really understand what
I have some preliminary results from compiling with gcc 4.3.
size
text data bss dec hex filename
13152818 28032162896 13343746 cb9c02build/src/lyx
13634327 28096162928 13825351 d2f547gcc-4.2/src/lyx
10486888 28104163280 10678272 a2f000
[EMAIL PROTECTED] wrote:
Author: larsbj
Date: Sun Sep 16 12:41:33 2007
New Revision: 20309
URL: http://www.lyx.org/trac/changeset/20309
Log:
* Ambigous else
* Missing header file
I assume this should also go in branch. Right?
Jürgen
On Sun, Sep 16, 2007 at 12:18:56PM +0200, Lars Gullik Bjønnes wrote:
I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
trunk), and got both some new warnings and a few errors. This patch
fixes those.
The main variants of warnings/errors:
* Ambigous else
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
| [EMAIL PROTECTED] wrote:
| Author: larsbj
| Date: Sun Sep 16 12:41:33 2007
| New Revision: 20309
|
| URL: http://www.lyx.org/trac/changeset/20309
| Log:
| * Ambigous else
| * Missing header file
|
| I assume this should also go in branch.
Lars Gullik Bjønnes wrote:
Perhaps. Shouldn't harm anything.
Done.
Jürgen
http://bugzilla.lyx.org/show_bug.cgi?id=4014
What shall we do with this bug?
Here's a summary:
1.5svn crashes (with stdlib-debug enabled), while 1.6svn doesn't. The only
difference (after the boost upgrade) is the build procedure, which was changed
in trunk here:
Andre Poenitz [EMAIL PROTECTED] writes:
| PS:
|
| - bool const empty() const
| + bool empty() const
| {
| return data_.empty();
| }
|
| So gcc starts complaining about the first 'const'? Nice.
Not all first 'const' though. Only for basic types it seems.
--
On Sun, Sep 16, 2007 at 02:11:44PM +0200, Lars Gullik Bjønnes wrote:
Andre Poenitz [EMAIL PROTECTED] writes:
| PS:
|
| - bool const empty() const
| + bool empty() const
|{
|return data_.empty();
|}
|
| So gcc starts complaining about the first 'const'? Nice.
And, what about ParagraphMetrics.position_, ascent
and discent ?
Ok, they're y coords, they represent the paragraph vertical
dimension and position, but I couldn't really figure out what
are they relative to, and why I always see in the code
*) position()-ascent()
*) position()+descent()
Thanx
On Sun, Sep 16, 2007 at 02:42:11PM +0200, Tommaso Cucinotta wrote:
And, what about ParagraphMetrics.position_, ascent
and discent ?
Ok, they're y coords, they represent the paragraph vertical
dimension and position, but I couldn't really figure out what
are they relative to, and why I
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I'll post some timing stats when I have them.
gcc-trunk:
real103m54.529s
user29m4.877s
sys 4m1.443s
gcc-fedora-7:
real113m2.677s
user33m43.024s
sys 4m6.792s
gcc-4.2:
real116m38.515s
user37m21.355s
sys
Martin Vermeer wrote:
The attached seems to fix it and has the merit of me sort of
understanding why it works.
Do you also have a fix for branch?
Jürgen
Hmmm, what does name stand for? The content of the inset, i.e., the
term being indexed?
Yes.
So it will be up to 45 chars long, and if longer, cut it off with an
ellipsis. How much screen real estate will this eat, and is there a way
to prevent this?
45 is quite a lot. ERT uses 15, like
URL: http://www.lyx.org/trac/changeset/20313
Log:
Display index name in InsetIndex label
Jurgen:
Is this something you want for branch?
Bo
Bo Peng wrote:
Is this something you want for branch?
yes, why not.
Jürgen
[EMAIL PROTECTED] wrote:
- return _(Idx);
+ size_t const maxLabelChars = 25;
+
+ docstring label = Idx: + getParam(name);
However, Idx still should be translatable. And I would add a blank after the
colon.
Jürgen
[EMAIL PROTECTED] wrote:
Modified: lyx-devel/branches/BRANCH_1_5_X/src/Text3.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/branches/BRANCH_1_5_X/src/Text3.cpp?
rev=20311
===
=== ---
On 9/16/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
Bo Peng wrote:
Is this something you want for branch?
yes, why not.
Done. Thanks.
I needed to change some index labels from 'a b' to 'b!a' for my
document and I quickly lost track of which indexes have been updated
and which have not.
On 9/16/07, Jürgen Spitzmüller [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
-return _(Idx);
+size_t const maxLabelChars = 25;
+
+docstring label = Idx: + getParam(name);
However, Idx still should be translatable. And I would add a blank after the
colon.
My mistake.
Fixed.
Bo
Andre Poenitz wrote:
So as long as I don't see
src/frontends/controllers/tests/regfiles/biblio show up in the
source-tarball, I will also disable
src/frontends/controllers/tests/test_biblio. (Unless anybody tells me,
that this test is very mandatory)
I have added tests/regfiles/biblio
On Sun, Sep 16, 2007 at 04:00:34PM +0200, Jürgen Spitzmüller wrote:
Martin Vermeer wrote:
The attached seems to fix it and has the merit of me sort of
understanding why it works.
Do you also have a fix for branch?
Not needed... the fix replaces something that Abdel removed ;-)
- Martin
On Sun, Sep 16, 2007 at 02:53:56PM +0200, Andre Poenitz wrote:
On Sun, Sep 16, 2007 at 02:42:11PM +0200, Tommaso Cucinotta wrote:
And, what about ParagraphMetrics.position_, ascent
and discent ?
Ok, they're y coords, they represent the paragraph vertical
dimension and position, but I
I noticed that MSVC comes now up with this warning:
cl /nologo /EHsc /wd4819 /wd4996 /nologo /MD /O2 /TP
/ID:\LyXSVN\LyX1.5.x\lyx-windows-deps-msvc-qt4\include /Irelease\common /ID:\LyXSVN\LyX1.5.x\src
/ID:\LyXSVN\LyX1.5.x\src /ID:\LyXSVN\LyX1.5.x\boost /c D:\LyXSVN\LyX1.5.x\src\Server.cpp /
Andre Poenitz wrote:
On Sun, Sep 16, 2007 at 12:18:56PM +0200, Lars Gullik Bjønnes wrote:
I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
trunk), and got both some new warnings and a few errors. This patch
fixes those.
The main variants of warnings/errors:
*
Does anyone know why the size of a Mac binary compiled from trunk has
increased to about 280 MB? The same compilation procedure (basically
as outlined in INSTALL.MacOSX including install-strip) for the 1.5-
branch results in a size of about 43 MB.
Anders
Tommaso Cucinotta wrote:
And, what about ParagraphMetrics.position_, ascent
and discent ?
Ok, they're y coords, they represent the paragraph vertical
dimension and position, but I couldn't really figure out what
are they relative to,
All inset and paragraph coords are absolute WRT the screen.
On 16 sep 2007, at 20.59, Anders Ekberg wrote:
Does anyone know why the size of a Mac binary compiled from trunk
has increased to about 280 MB? The same compilation procedure
(basically as outlined in INSTALL.MacOSX including install-strip)
for the 1.5-branch results in a size of about 43
[EMAIL PROTECTED] wrote:
Author: spitz
Date: Sun Sep 16 14:14:03 2007
New Revision: 20310
URL: http://www.lyx.org/trac/changeset/20310
Log:
Backport revision 20309:
URL: http://www.lyx.org/trac/changeset/20309
* Ambigous else
* Missing header file
Modified:
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 11:35:09AM +0200, Abdelrazak Younes wrote:
Moreover, what var decides how the gray text background
is cut at the end of the doc ?
Yes, that is tricky. It's years ago that I looked at this :-(
I suspect it is in GuiWorkArea::setScrollbarParams():
Hope this helps. Feel free to synthesize all these information and write
some documentation ;-)
btw i'm trying to catch such threads and put them into
http://wiki.lyx.org/Devel/Diagrams .
pavel
Pavel Sanda wrote:
Hope this helps. Feel free to synthesize all these information and write
some documentation ;-)
btw i'm trying to catch such threads and put them into
http://wiki.lyx.org/Devel/Diagrams .
Very good initiative. Proper doxygen documentation should also go in the
header...
On Sun, Sep 16, 2007 at 06:50:04PM +0200, Jürgen Spitzmüller wrote:
Andre Poenitz wrote:
So as long as I don't see
src/frontends/controllers/tests/regfiles/biblio show up in the
source-tarball, I will also disable
src/frontends/controllers/tests/test_biblio. (Unless anybody tells me,
On Sun, Sep 16, 2007 at 08:28:54PM +0200, Uwe Stöhr wrote:
I noticed that MSVC comes now up with this warning:
cl /nologo /EHsc /wd4819 /wd4996 /nologo /MD /O2 /TP
/ID:\LyXSVN\LyX1.5.x\lyx-windows-deps-msvc-qt4\include /Irelease\common
/ID:\LyXSVN\LyX1.5.x\src /ID:\LyXSVN\LyX1.5.x\src
On Sun, Sep 16, 2007 at 08:57:32PM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sun, Sep 16, 2007 at 12:18:56PM +0200, Lars Gullik Bjønnes wrote:
I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
trunk), and got both some new warnings and a few errors. This
Pavel Sanda ha scritto:
btw i'm trying to catch such threads and put them into
http://wiki.lyx.org/Devel/Diagrams .
Great. Also, the (reference point of the) return
value of buffer_view::coordOffset() and buffer_view::getPos(),
and the role of BufferView.wh_ would complete the
picture.
+ docstring label = Idx: + getParam(name);
However, Idx still should be translatable. And I would add a blank after the
colon.
Why is this an advantage? Now the index entry boxes are unnecessary large - take for example the
EmbeddedObjects manual.
Showing the name of the index is no
Why is this an advantage?
Because you do not have to click on the index to know the index key.
We also don't show footnote text in the footnote label.
Because footnotes, ERT etc are long.
Book indexes like the ones in the LyX docs don't have a name
??? The name is the index key.
Instead
_(Idx) was translatable. I made a mistake and changed it to Idx:
and now it is translatable again: _(Idx: ).
This is not what I meant. Idx: is not translateable because it is not a word. The label should
have the name Index not Idx. This could then be translated to different languages, e.g
This is not what I meant. Idx: is not translateable because it is not a
word. The label should
have the name Index not Idx. This could then be translated to different
languages, e.g to
Índice when you use Spanish menus.
You have complained that the label of index inset is too long now,
Bo Peng schrieb:
This is not what I meant. Idx: is not translateable because it is not a
word. The label should
have the name Index not Idx. This could then be translated to different
languages, e.g to
Índice when you use Spanish menus.
You have complained that the label of index inset is
I think keysym handlign could be a bit simpler on the technical
side. As I usually do not do fancy stuff with my keys it would be
nice if someone tried the attached patch.
Andre'
Index: LyXFunc.h
===
--- LyXFunc.h (revision 20318)
On Fri, 2007-09-14 at 09:29 +0200, Jean-Marc Lasgouttes wrote:
Darren Freeman [EMAIL PROTECTED] writes:
Add three radio buttons to the configuration dialogue, under Action to
perform when a preview is still open, which would be Ask what to do,
Always update the existing preview, and
On Fri, 2007-09-14 at 12:36 +0200, Tommaso Cucinotta wrote:
Waiting for the process to die would only work for simple apps
like gv. For example, the default behaviour of acroread is,
on Linux, to open a new window and wait if it is not running,
or to display the requested document into the
On Sun, 2007-09-16 at 09:20 +0300, Martin Vermeer wrote:
On Sat, Sep 15, 2007 at 11:36:37PM -0500, Bo Peng wrote:
Can I make the label of InsetIndex more meaningful by displaying
'Idx:name' instead of 'Idx'?
A simple patch is attached. I will commit it if there is no objection
in one
On Mon, Sep 17, 2007 at 01:17:18AM +0200, Uwe Stöhr wrote:
Bo Peng schrieb:
This is not what I meant. Idx: is not translateable because it is not
a word. The label should
have the name Index not Idx. This could then be translated to
different languages, e.g to
Índice when you use
Dear all,
I am experiencing something like this:
1. open a master document,
2. click on a child document and edit
3. save the child document and close lyx.
Lyx thinks that the master document has unsaved changes and ask me if
I want to save it. This is sort of scary because I have to ask myself
On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
> Hi,
>
> I couldn't really understand what information is
> stored inside the BufferView.offset_ref_ variable.
> At a first glance, it would seem that anchor_ref_
> stores the "paragraph offset" that is displayed from
> the
On Sat, Sep 15, 2007 at 11:36:37PM -0500, Bo Peng wrote:
> Can I make the label of InsetIndex more meaningful by displaying
> 'Idx:name' instead of 'Idx'?
>
> A simple patch is attached. I will commit it if there is no objection
> in one day.
>
> Bo
Hmmm, what does "name" stand for? The content
On Sat, Sep 15, 2007 at 11:36:37PM -0500, Bo Peng wrote:
> Can I make the label of InsetIndex more meaningful by displaying
> 'Idx:name' instead of 'Idx'?
>
> A simple patch is attached. I will commit it if there is no objection
> in one day.
... and for the closed inset, you can leave out the
On Sat, Sep 15, 2007 at 11:36:37PM -0500, Bo Peng wrote:
> Can I make the label of InsetIndex more meaningful by displaying
> 'Idx:name' instead of 'Idx'?
I don't mind.
> A simple patch is attached. I will commit it if there is no objection
> in one day.
Only stylistic.
> Index:
On Sun, Sep 16, 2007 at 09:00:50AM +0300, Martin Vermeer wrote:
> On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
> > Hi,
> >
> > I couldn't really understand what information is
> > stored inside the BufferView.offset_ref_ variable.
> > At a first glance, it would seem that
Abdelrazak Younes wrote:
> This should go in branch Jurgen. It is I think the right fix for bug 4178.
Looks good. Please commit.
Jürgen
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
Hi,
I couldn't really understand what information is
stored inside the BufferView.offset_ref_ variable.
At a first glance, it would seem that anchor_ref_
stores the "paragraph offset" that is displayed
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
This should go in branch Jurgen. It is I think the right fix for bug 4178.
Looks good. Please commit.
Done.
Abdel.
On Sun, Sep 16, 2007 at 10:41:21AM +0200, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> >On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
> >>Hi,
> >>
> >>I couldn't really understand what information is
> >>stored inside the BufferView.offset_ref_ variable.
> >>At a first
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 10:41:21AM +0200, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
Hi,
I couldn't really understand what information is
stored inside the BufferView.offset_ref_ variable.
At a first
Abdelrazak Younes wrote:
> Done.
Thanks. This also fixes the crash I encountered in bug 4082 (I cannot
reproduce the crash originally reported).
Jürgen
I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
trunk), and got both some new warnings and a few errors. This patch
fixes those.
The main variants of warnings/errors:
* Ambigous else
* Ambigous logical operators
* Headers in libstdc++ cleanup,
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
| trunk), and got both some new warnings and a few errors. This patch
| fixes those.
|
| The main variants of warnings/errors:
| * Ambigous else
| * Ambigous
On Sun, Sep 16, 2007 at 11:35:09AM +0200, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> >On Sun, Sep 16, 2007 at 10:41:21AM +0200, Abdelrazak Younes wrote:
> >>Martin Vermeer wrote:
> >>>On Sun, Sep 16, 2007 at 04:27:04AM +0200, Tommaso Cucinotta wrote:
> Hi,
>
> I couldn't
I have some preliminary results from compiling with gcc 4.3.
size
text data bss dec hex filename
13152818 28032162896 13343746 cb9c02build/src/lyx
13634327 28096162928 13825351 d2f547gcc-4.2/src/lyx
10486888 28104163280 10678272 a2f000
[EMAIL PROTECTED] wrote:
> Author: larsbj
> Date: Sun Sep 16 12:41:33 2007
> New Revision: 20309
>
> URL: http://www.lyx.org/trac/changeset/20309
> Log:
> * Ambigous else
> * Missing header file
I assume this should also go in branch. Right?
Jürgen
On Sun, Sep 16, 2007 at 12:18:56PM +0200, Lars Gullik Bjønnes wrote:
>
> I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
> trunk), and got both some new warnings and a few errors. This patch
> fixes those.
>
> The main variants of warnings/errors:
> * Ambigous else
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
| [EMAIL PROTECTED] wrote:
| > Author: larsbj
| > Date: Sun Sep 16 12:41:33 2007
| > New Revision: 20309
| >
| > URL: http://www.lyx.org/trac/changeset/20309
| > Log:
| > * Ambigous else
| > * Missing header file
|
| I assume this should also go in
Lars Gullik Bjønnes wrote:
> Perhaps. Shouldn't harm anything.
Done.
Jürgen
http://bugzilla.lyx.org/show_bug.cgi?id=4014
What shall we do with this bug?
Here's a summary:
1.5svn crashes (with stdlib-debug enabled), while 1.6svn doesn't. The only
difference (after the boost upgrade) is the build procedure, which was changed
in trunk here:
Andre Poenitz <[EMAIL PROTECTED]> writes:
| PS:
|
| > - bool const empty() const
| > + bool empty() const
| > {
| > return data_.empty();
| > }
|
| So gcc starts complaining about the first 'const'? Nice.
Not all "first 'const'" though. Only for basic types it seems.
On Sun, Sep 16, 2007 at 02:11:44PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | PS:
> |
> | > - bool const empty() const
> | > + bool empty() const
> | > {
> | > return data_.empty();
> | > }
> |
> | So gcc starts complaining about the
And, what about ParagraphMetrics.position_, ascent
and discent ?
Ok, they're y coords, they represent the paragraph vertical
dimension and position, but I couldn't really figure out what
are they relative to, and why I always see in the code
*) position()-ascent()
*) position()+descent()
Thanx
On Sun, Sep 16, 2007 at 02:42:11PM +0200, Tommaso Cucinotta wrote:
> And, what about ParagraphMetrics.position_, ascent
> and discent ?
>
> Ok, they're y coords, they represent the paragraph vertical
> dimension and position, but I couldn't really figure out what
> are they relative to, and why I
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| I'll post some timing stats when I have them.
gcc-trunk:
real103m54.529s
user29m4.877s
sys 4m1.443s
gcc-fedora-7:
real113m2.677s
user33m43.024s
sys 4m6.792s
gcc-4.2:
real116m38.515s
user37m21.355s
sys
Martin Vermeer wrote:
> The attached seems to fix it and has the merit of me sort of
> understanding why it works.
Do you also have a fix for branch?
Jürgen
> Hmmm, what does "name" stand for? The content of the inset, i.e., the
> term being indexed?
Yes.
> So it will be up to 45 chars long, and if longer, cut it off with an
> ellipsis. How much screen real estate will this eat, and is there a way
> to prevent this?
>
> 45 is quite a lot. ERT uses
> URL: http://www.lyx.org/trac/changeset/20313
> Log:
> Display index name in InsetIndex label
Jurgen:
Is this something you want for branch?
Bo
Bo Peng wrote:
> Is this something you want for branch?
yes, why not.
Jürgen
[EMAIL PROTECTED] wrote:
> - return _("Idx");
> + size_t const maxLabelChars = 25;
> +
> + docstring label = "Idx:" + getParam("name");
However, "Idx" still should be translatable. And I would add a blank after the
colon.
Jürgen
[EMAIL PROTECTED] wrote:
> Modified: lyx-devel/branches/BRANCH_1_5_X/src/Text3.cpp
> URL:
> http://www.lyx.org/trac/file/lyx-devel/branches/BRANCH_1_5_X/src/Text3.cpp?
>rev=20311
> ===
>=== ---
On 9/16/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
> Bo Peng wrote:
> > Is this something you want for branch?
>
> yes, why not.
Done. Thanks.
I needed to change some index labels from 'a b' to 'b!a' for my
document and I quickly lost track of which indexes have been updated
and which
On 9/16/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > -return _("Idx");
> > +size_t const maxLabelChars = 25;
> > +
> > +docstring label = "Idx:" + getParam("name");
>
> However, "Idx" still should be translatable. And I would add a blank after the
> colon.
My
Andre Poenitz wrote:
> > So as long as I don't see
> > src/frontends/controllers/tests/regfiles/biblio show up in the
> > source-tarball, I will also disable
> > src/frontends/controllers/tests/test_biblio. (Unless anybody tells me,
> > that this test is very mandatory)
>
> I have added
On Sun, Sep 16, 2007 at 04:00:34PM +0200, Jürgen Spitzmüller wrote:
> Martin Vermeer wrote:
> > The attached seems to fix it and has the merit of me sort of
> > understanding why it works.
>
> Do you also have a fix for branch?
Not needed... the fix replaces something that Abdel removed ;-)
-
On Sun, Sep 16, 2007 at 02:53:56PM +0200, Andre Poenitz wrote:
> On Sun, Sep 16, 2007 at 02:42:11PM +0200, Tommaso Cucinotta wrote:
> > And, what about ParagraphMetrics.position_, ascent
> > and discent ?
> >
> > Ok, they're y coords, they represent the paragraph vertical
> > dimension and
I noticed that MSVC comes now up with this warning:
cl /nologo /EHsc /wd4819 /wd4996 /nologo /MD /O2 /TP
/ID:\LyXSVN\LyX1.5.x\lyx-windows-deps-msvc-qt4\include /Irelease\common /ID:\LyXSVN\LyX1.5.x\src
/ID:\LyXSVN\LyX1.5.x\src /ID:\LyXSVN\LyX1.5.x\boost /c D:\LyXSVN\LyX1.5.x\src\Server.cpp /
Andre Poenitz wrote:
On Sun, Sep 16, 2007 at 12:18:56PM +0200, Lars Gullik Bjønnes wrote:
I just did a some test compilations with gcc 4.2 and gcc 4.3 (from gcc
trunk), and got both some new warnings and a few errors. This patch
fixes those.
The main variants of warnings/errors:
*
Does anyone know why the size of a Mac binary compiled from trunk has
increased to about 280 MB? The same compilation procedure (basically
as outlined in INSTALL.MacOSX including install-strip) for the 1.5-
branch results in a size of about 43 MB.
Anders
Tommaso Cucinotta wrote:
And, what about ParagraphMetrics.position_, ascent
and discent ?
Ok, they're y coords, they represent the paragraph vertical
dimension and position, but I couldn't really figure out what
are they relative to,
All inset and paragraph coords are absolute WRT the screen.
1 - 100 of 120 matches
Mail list logo
