Abdelrazak Younes wrote:
> Yes, but the thread was hijacked by a different problem in trunk. The
> 1.5.x is different but still present AFAIU.
OK. Thanks for the clarification.
Jürgen
Pavel Sanda wrote:
> i would like to propose this small patch for box menu entry, as i want to
> distinguish between inset and menu occurence of this string for translation
> (for shortcut occurence to be more explicit).
I think the proposal makes sense. I'm gonna put it in branch and trunk if I
Jürgen Spitzmüller wrote:
Martin Vermeer wrote:
Not needed... the fix replaces something that Abdel removed ;-)
I'm confused. I thought this "ERT in titel bug" is something that appeared in
1.5.x?
Yes, but the thread was hijacked by a different problem in trunk. The
1.5.x is different but
Darren Freeman wrote:
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 obje
Martin Vermeer wrote:
> Not needed... the fix replaces something that Abdel removed ;-)
I'm confused. I thought this "ERT in titel bug" is something that appeared in
1.5.x?
Jürgen
Martin Vermeer wrote:
> > Jürgen?
I think "Index: " plus a 25-char-string is too long (I actually think the
string should be shortened to 20 chars anyway). And I don't understand
why "Idx" isn't a suitable abbreviation (and also why it shouldn't be
translatable; the abbreviation in other langua
Uwe Stöhr wrote:
> Besides this, I don't know why this could go to branch since there was no
> need for this change.
Because it was trivial and I agree with Bo that it is helpful.
Jürgen
Martin Vermeer wrote:
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
"Í
Darren Freeman wrote:
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 exi
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 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
> >>"Índ
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
>
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 th
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 prev
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)
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 in
> 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
> _("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 lan
> 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.
> Ins
>> + 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 i
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.
Gue
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. T
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 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 anybod
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...
> 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
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():
[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:
lyx-devel/branches/BRANCH_1_5_X/
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 M
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.
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
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:
* Ambig
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 /
F
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 positio
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 ;-)
- Ma
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/regfi
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 mi
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
[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
> ===
>=== --- lyx-devel/branches/BRANCH_1_5_X/s
[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
Bo Peng wrote:
> Is this something you want for branch?
yes, why not.
Jürgen
> URL: http://www.lyx.org/trac/changeset/20313
> Log:
> Display index name in InsetIndex label
Jurgen:
Is this something you want for branch?
Bo
> 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
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
[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 4m12.558
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
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 a
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
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.
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:
http://www.lyx.org/trac/change
Lars Gullik Bjønnes wrote:
> Perhaps. Shouldn't harm anything.
Done.
Jürgen
[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 b
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] 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
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
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
[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 lo
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, requir
Abdelrazak Younes wrote:
> Done.
Thanks. This also fixes the crash I encountered in bug 4082 (I cannot
reproduce the crash originally reported).
Jürgen
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
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 gl
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.
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
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
64 matches
Mail list logo
