On 06/10/2008 00:40, Vincent van Ravesteijn wrote:
If you make a selection and paste something, the selection will be
replaced in case of normal paste, but the selection will be retained in
the case of paste special (clipboard-paste).
Does anyone know why there is the cur.clearSelection() in the
Thus, lyxskak.sty cannot find the *.fen files. If you copy them
into the
tmp directory, it compiles, but the output sucks.
Besides that, at my place LyX can't find chess.layout / lyxskak.sty /
lyxchess.sty, but that might be something with my installation.
It would be nice BTW to see what it
Yes, I wanted to have a look at the dissolve problems, but this
problem
is slightly more complicated, because the function that really
dissolves
the inset is the same as which is used to dissolve insets when you hit
backspace or so. Thus modifying this isn't that easy..
I think that we need
Le 4 oct. 08 à 18:55, Uwe Stöhr a écrit :
> So we ship two copies now?
Yes, because some example files and some template files use it. I
don't think this harms. Having the BibTeX file in the same folder
appeared to be best place to let users find their way to BibTeX.
I'd prefer to have the
The cause of the bug is that the counter-reading code overwrites an
existing counter when it is read again, rather than updating it, as for
other bits of layout information. This patch fixes the bug and, along
the way, makes the counter-reading code more like the style-reading
code. The bulk
Vincent van Ravesteijn wrote:
If you make a selection and paste something, the selection will be
replaced in case of normal paste, but the selection will be retained in
the case of paste special (clipboard-paste).
Does anyone know why there is the cur.clearSelection() in the code below
instead
I wrote:
We can ship the layout file and a template file directly with LyX.
I had a look:
- You use a lot of ERT for things that are already supported by LyX. These are for example \vspace,
\footnote, \centering, \clearpage. In LyX 1.6 also the command \nocite will be supported.
(LyX also s
If you make a selection and paste something, the selection will be
replaced in case of normal paste, but the selection will be retained in
the case of paste special (clipboard-paste).
Does anyone know why there is the cur.clearSelection() in the code below
instead of cap::replaceSelection(cur) as
On Sun, 2008-10-05 at 22:23 +0200, Uwe Stöhr wrote:
>
> > http://bugzilla.lyx.org/show_bug.cgi?id=3625
> >
> > Bug 3625 is about the fact that you can't copy text with leading
> spaces.
> > Ironically this is actively disabled by...
> > Why do we want to start copying text after a space?
>
>
Jürgen, OK to go in branch?
regards Uwe
Index: lib/languages
===
--- lib/languages (revision 26748)
+++ lib/languages (working copy)
@@ -44,9 +44,9 @@
kazakh kazakh "Kazakh" false pt154 kk_KZ ""
# there is no country cod
> http://bugzilla.lyx.org/show_bug.cgi?id=3625
>
> Bug 3625 is about the fact that you can't copy text with leading spaces.
> Ironically this is actively disabled by...
> Why do we want to start copying text after a space?
I think that was once introduced to avoid multiple spaces after pasting to
Jürgen Spitzmüller wrote:
rgheck wrote:
The attached patch gives you the more flexible interface. By default, it
sets CustomPars to false and ForcePlain to true. I've also made it so
that, if MultiPar is sets, then CustomPars gets set to the same thing
and ForcePlain to the opposite, so by de
Pavel Sanda wrote:
[EMAIL PROTECTED] wrote:
Author: rgheck
Date: Sun Oct 5 21:38:22 2008
New Revision: 26757
URL: http://www.lyx.org/trac/changeset/26757
Log:
Further to r26743, add CustomPars and ForcePlain layout tags to InsetLayout,
so that the allowParagraphCustomization() and forcePlai
On Sun, Oct 5, 2008 at 2:11 PM, Pavel Sanda <[EMAIL PROTECTED]> wrote:
> Bennett Helm wrote:
> > Here's a patch to fix an obvious recent typo in os_unix.cpp. Can someone
> > please apply?
>
> its in.
Thanks.
Bennett
[EMAIL PROTECTED] wrote:
> Author: rgheck
> Date: Sun Oct 5 21:38:22 2008
> New Revision: 26757
>
> URL: http://www.lyx.org/trac/changeset/26757
> Log:
> Further to r26743, add CustomPars and ForcePlain layout tags to InsetLayout,
> so that the allowParagraphCustomization() and forcePlainLayout()
On Sun, Oct 05, 2008 at 06:50:45PM +0200, Peter Kümmel wrote:
> Enrico Forestieri wrote:
> > On Sun, Oct 05, 2008 at 04:40:35PM +0200, Abdelrazak Younes wrote:
> >
> >> On 05/10/2008 16:30, Peter K�mmel wrote:
> >>> Andre Poenitz wrote:
> On Sun, Oct 05, 2008 at 02:09:03PM +0200, Peter K�mme
Uwe Stöhr wrote:
> > And what was the result for the background color of any widget?
> > The current color does not fit to the logo.
>
> Do you mean that our new "L" logo is not visible? If your OS window style
> is blue, then you are right, but we should then better draw a thin black
> line arou
> And what was the result for the background color of any widget?
> The current color does not fit to the logo.
Do you mean that our new "L" logo is not visible? If your OS window style is blue, then you are
right, but we should then better draw a thin black line around the "L" to improve the si
> wasn't it 2 other devs?
I don't know exactly. But OK, let the rule be an OK from 2 other developers.
regards Uwe
Bennett Helm wrote:
> Here's a patch to fix an obvious recent typo in os_unix.cpp. Can someone
> please apply?
its in.
pavel
Bennett Helm wrote:
Here's a patch to fix an obvious recent typo in os_unix.cpp. Can someone
please apply?
Thanks.
Bennett
Sorry, my fault, patch committed.
--
Peter Kümmel
Peter Kümmel wrote:
> The current color does not fit to the logo.
i agree with this from aesthetical point of view. instead of changing of
background
we could make darker those shaded borders of the logo.
pavel
Here's a patch to fix an obvious recent typo in os_unix.cpp. Can someone
please apply?
Thanks.
Bennett
Index: src/support/os_unix.cpp
===
--- src/support/os_unix.cpp (revision 26748)
+++ src/support/os_unix.cpp (working copy)
@@ -3
Uwe Stöhr wrote:
> So I propose that nothing is committed to trunk from now on that doesn't
> fix a Bugzilla bug or where you get OKs from at least 3 other developers.
wasn't it 2 other devs?
pavel
Peter Kümmel wrote:
> And what was the result for the background color of any widget?
> The current color does not fit to the logo.
> Is it possible to change this color by the dialog or should we
> say "you must use the color of your desktop settings"?
I think we should let the widgets chose the
> I think we already had this discussion.
i must be getting old. but then again, some discussions are worth forgetting...
Uwe Stöhr wrote:
i would like to suggest to change lyx's default background color to
white for 1.6
No. We have discussed this so often in the past. We use for good reason
not white. Black/white tires your eyes more than using black/light
yellow that we use.
In a lecture at the University I a
In the discussion about the extended search dialog, we came to the conclusion that we need to go
into bugfixing-only mode.
It is time to declare bugfixing-only mode officially.
So I propose that nothing is committed to trunk from now on that doesn't fix a Bugzilla bug or where
you get OKs from
> i would like to suggest to change lyx's default background color to white for
1.6
No. We have discussed this so often in the past. We use for good reason not white. Black/white tires
your eyes more than using black/light yellow that we use.
In a lecture at the University I also heard that thi
leuven edwin wrote:
> i would like to suggest to change lyx's default background color to white
> for 1.6
>
> white seems to be the default background color for text entry on most
> platforms...
I think we already had this discussion.
Jürgen
i would like to suggest to change lyx's default background color to white for
1.6
white seems to be the default background color for text entry on most
platforms...
laundry.patch
Description: laundry.patch
On 05/10/2008 18:53, rgheck wrote:
Pavel Sanda wrote:
diff --git a/src/BufferView.h b/src/BufferView.h
index d418260..585792d 100644
--- a/src/BufferView.h
+++ b/src/BufferView.h
@@ -92,9 +92,11 @@ public:
///
void setFullScreen(bool full_screen) { full_screen_ =
full_screen; }
+
rgheck wrote:
> The attached patch gives you the more flexible interface. By default, it
> sets CustomPars to false and ForcePlain to true. I've also made it so
> that, if MultiPar is sets, then CustomPars gets set to the same thing
> and ForcePlain to the opposite, so by default it does what you h
Pavel Sanda wrote:
diff --git a/src/BufferView.h b/src/BufferView.h
index d418260..585792d 100644
--- a/src/BufferView.h
+++ b/src/BufferView.h
@@ -92,9 +92,11 @@ public:
///
void setFullScreen(bool full_screen) { full_screen_ = full_screen; }
+ //FIXME: In RTL text this is the
[EMAIL PROTECTED] wrote:
Author: spitz
Date: Sun Oct 5 13:00:48 2008
New Revision: 26743
URL: http://www.lyx.org/trac/changeset/26743
Log:
* InsetFlex.h:
- correct the enabling of paragraph and layout changes as far as this
is possible with the current interface (see FIXMEs).
Enrico Forestieri wrote:
On Sun, Oct 05, 2008 at 04:40:35PM +0200, Abdelrazak Younes wrote:
On 05/10/2008 16:30, Peter K�mmel wrote:
Andre Poenitz wrote:
On Sun, Oct 05, 2008 at 02:09:03PM +0200, Peter K�mmel wrote:
Abdelrazak Younes wrote:
Yes, but please use (or extend) already existing
F
Vincent van Ravesteijn wrote:
> This patch solves some problems with painting selections in Insets.
> These are:
> - multiline selections paint in left margin of the main text (bug 5270),
> - the margins to the left and right side of the inset are not correct,
> - wrong painting of e.g. a multiline
On Sun, Oct 05, 2008 at 04:40:35PM +0200, Abdelrazak Younes wrote:
> On 05/10/2008 16:30, Peter K�mmel wrote:
> > Andre Poenitz wrote:
> >> On Sun, Oct 05, 2008 at 02:09:03PM +0200, Peter K�mmel wrote:
> >>> Abdelrazak Younes wrote:
> Yes, but please use (or extend) already existing
> F
This patch solves some problems with painting selections in Insets.
These are:
- multiline selections paint in left margin of the main text (bug 5270),
- the margins to the left and right side of the inset are not correct,
- wrong painting of e.g. a multiline selection of a caption in a float.
I r
On 05/10/2008 16:30, Peter Kümmel wrote:
Andre Poenitz wrote:
On Sun, Oct 05, 2008 at 02:09:03PM +0200, Peter Kümmel wrote:
Abdelrazak Younes wrote:
Yes, but please use (or extend) already existing
FileName::operator==()
FileName::operator==() expands now short names on Windows.
http://www.
Andre Poenitz wrote:
On Sun, Oct 05, 2008 at 02:09:03PM +0200, Peter Kümmel wrote:
Abdelrazak Younes wrote:
Yes, but please use (or extend) already existing FileName::operator==()
FileName::operator==() expands now short names on Windows.
http://www.lyx.org/trac/changeset/26745
In this case
Uwe Stöhr schrieb:
Just the same as for Vietnamese. I'll provide a patch.
I fixed the Lithuanian case and will have a look if this can easily be
backported to branch.
But can anybody tell me how to get a Latvian document to compile? I mean
do you know a LaTeX-package that add the encoding a
On Sun, Oct 05, 2008 at 02:09:03PM +0200, Peter Kümmel wrote:
> Abdelrazak Younes wrote:
>>
>> Yes, but please use (or extend) already existing FileName::operator==()
>>
>
> FileName::operator==() expands now short names on Windows.
> http://www.lyx.org/trac/changeset/26745
In this case I'd prefer
> JASA accepts manuscripts using either superscript or author-year citations.
> The LyXforJASA package includes separate template and .bst files for these
> citation styles. The .layout and .bib files can be used by both. The .layout
> file provides for both single- and two-column versions of a ma
We provide support for the languages Lithuanian and Latvian, but they won't
compile.
For Lithuanian, you need to install a special package that installs the encoding and babel support.
But then it can still not be compiled, as we create this code:
\documentclass[lithuanian]{book}
\usepackage[
On 05/10/2008 13:55, Peter Kümmel wrote:
I've checked in a more generic patch:
http://www.lyx.org/trac/changeset/26744
Good.
Abdel.
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Yes, but please use (or extend) already existing FileName::operator==()
FileName::operator==() expands now short names on Windows.
http://www.lyx.org/trac/changeset/26745
Uwe, could you verify it and close the bug report?
http://bugzilla.lyx.or
Andre Poenitz wrote:
We should have a Qt function, then we don't have to think about it. ;)
File a suggestion and send me a link.
4.5 is in feature freeze, though, so this won't hit the shelves before
next summer, then it takes a year to be picked up by the distributions
and two more years to
Abdelrazak Younes wrote:
Yes, but please use (or extend) already existing FileName::operator==()
FileName::operator==() expands now short names on Windows.
http://www.lyx.org/trac/changeset/26745
Peter
I've checked in a more generic patch:
http://www.lyx.org/trac/changeset/26744
Peter
50 matches
Mail list logo
