Andre Poenitz wrote:
On Thu, Nov 01, 2007 at 07:37:26PM +0100, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Wed, Oct 31, 2007 at 06:25:31PM +0100, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
If somebody use the docstream with latin8
Martin Vermeer wrote:
On Thu, Nov 08, 2007 at 09:11:26PM +0100, Andre Poenitz wrote:
On Thu, Nov 08, 2007 at 08:47:29PM +0200, Martin Vermeer wrote:
On Thu, Nov 08, 2007 at 06:02:02PM +0100, Jean-Marc Lasgouttes wrote:
Martin Vermeer <[EMAIL PROTECTED]> writes:
n times for every string you w
On Thu, Nov 08, 2007 at 09:11:26PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 08:47:29PM +0200, Martin Vermeer wrote:
> > On Thu, Nov 08, 2007 at 06:02:02PM +0100, Jean-Marc Lasgouttes wrote:
> > > Martin Vermeer <[EMAIL PROTECTED]> writes:
> > >
> > > > n times for every string you wan
On Thu, Nov 08, 2007 at 11:43:36PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 10:58:00PM +0100, Enrico Forestieri wrote:
> > On Thu, Nov 08, 2007 at 10:31:02PM +0100, Andre Poenitz wrote:
> >
> > > I am currently compiling with the attached changes. Would be nice if you
> > > could veri
On Thu, Nov 08, 2007 at 11:43:36PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 10:58:00PM +0100, Enrico Forestieri wrote:
> > On Thu, Nov 08, 2007 at 10:31:02PM +0100, Andre Poenitz wrote:
> >
> > > I am currently compiling with the attached changes. Would be nice if you
> > > could veri
On Thu, Nov 08, 2007 at 10:58:00PM +0100, Enrico Forestieri wrote:
> On Thu, Nov 08, 2007 at 10:31:02PM +0100, Andre Poenitz wrote:
>
> > I am currently compiling with the attached changes. Would be nice if you
> > could verify that it would work for you as well.
>
> I get the following error:
>
On Thu, Nov 08, 2007 at 11:28:32PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 11:07:29PM +0100, Enrico Forestieri wrote:
> > it would be cumbersome changing each instance of something like
> >
> >ws.os() << ' ';
> >
> > or
> >
> >ws.os() << '\n';
> >
> > in tha
On Thu, Nov 08, 2007 at 11:07:29PM +0100, Enrico Forestieri wrote:
> it would be cumbersome changing each instance of something like
>
>ws.os() << ' ';
>
> or
>
>ws.os() << '\n';
>
> in that way. And someone will forgot that and will use one of the
> above.
But we'd get
>> The phantom feature is a math feature
>
> No, \phantom, \vphantom and \hphantom are general (plain TeX) commands, which
> also work outside mathed (I use them from time to time).
I know and use them often e.g. also in the EmbeddedObjects manual. But the suport for these comands
is at the mome
On Thu, Nov 08, 2007 at 10:59:40PM +0100, Andre Poenitz wrote:
> On Thu, Nov 01, 2007 at 07:37:26PM +0100, Abdelrazak Younes wrote:
> > Abdelrazak Younes wrote:
> >> Andre Poenitz wrote:
> >>> On Wed, Oct 31, 2007 at 06:25:31PM +0100, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PRO
On Thu, Nov 01, 2007 at 07:37:26PM +0100, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
>> Andre Poenitz wrote:
>>> On Wed, Oct 31, 2007 at 06:25:31PM +0100, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> If somebody use the docstream with latin8 cha
On Thu, Nov 08, 2007 at 10:31:02PM +0100, Andre Poenitz wrote:
> I am currently compiling with the attached changes. Would be nice if you
> could verify that it would work for you as well.
I get the following error:
g++ -DHAVE_CONFIG_H -I. -I../../../src/support -I../../src
-I../../../src/suppo
On Thu, Nov 08, 2007 at 10:10:48PM +0100, Enrico Forestieri wrote:
> [...]
> > The Standard says how basic_istream<> etc should be defined. It does not
> > mandate that #include is the only way to get it. Doing it 'by
> > hand' is as legal even if less convienient than the #include.
>
> Then do i
On Thu, Nov 08, 2007 at 10:06:36PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 09:41:33PM +0100, Enrico Forestieri wrote:
> > > Because it voids 30% of the effect of having strfwd.h at all and it is
> > > not needed here and therefore probably on ~100% of the Linux systems out
> > > there
On Thu, Nov 08, 2007 at 09:41:33PM +0100, Enrico Forestieri wrote:
> > Because it voids 30% of the effect of having strfwd.h at all and it is
> > not needed here and therefore probably on ~100% of the Linux systems out
> > there.
>
> Even if that doesn't matter for you, there are other systems tha
On Thu, Nov 08, 2007 at 08:58:06PM +, José Matos wrote:
> On Thursday 08 November 2007 20:41:33 Enrico Forestieri wrote:
> > Even if that doesn't matter for you, there are other systems than
> > Linux out there and doing things the standard way usually helps.
>
> Not wanting to enter in a di
On Thursday 08 November 2007 20:41:33 Enrico Forestieri wrote:
> Even if that doesn't matter for you, there are other systems than
> Linux out there and doing things the standard way usually helps.
Not wanting to enter in a discussion with you, but the standard way is the
linux way. ;-)
Fort
On Thu, Nov 08, 2007 at 09:44:46PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 09:30:55PM +0100, Enrico Forestieri wrote:
> > > On second thoughts: I would agree to a solution using some kind of
> > > #ifdef as long as it does not lead to a #include on vanilla
> > > Linux.
> >
> > There
On Thu, Nov 08, 2007 at 09:30:55PM +0100, Enrico Forestieri wrote:
> > On second thoughts: I would agree to a solution using some kind of
> > #ifdef as long as it does not lead to a #include on vanilla
> > Linux.
>
> There's no need for any #ifdef. If you want forward declarations,
> then the ios
On Thu, Nov 08, 2007 at 09:38:08PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 09:19:25PM +0100, Enrico Forestieri wrote:
> > On Thu, Nov 08, 2007 at 09:04:37PM +0100, Andre Poenitz wrote:
> > > On Thu, Nov 08, 2007 at 07:53:13PM +0100, Enrico Forestieri wrote:
> > > > On Thu, Nov 08, 200
On Thu, Nov 08, 2007 at 09:26:52PM +0100, Enrico Forestieri wrote:
> > If we re-use other people's code, leaving their copyright messages
> > intact is the least we can do.
>
> Hmm, there was no other people's code left, me thinks.
Then please say so in the commit message.
Andre'
On Thu, Nov 08, 2007 at 09:19:25PM +0100, Enrico Forestieri wrote:
> On Thu, Nov 08, 2007 at 09:04:37PM +0100, Andre Poenitz wrote:
> > On Thu, Nov 08, 2007 at 07:53:13PM +0100, Enrico Forestieri wrote:
> > > On Thu, Nov 08, 2007 at 06:13:15PM +0100, Andre Poenitz wrote:
> > > > On Thu, Nov 08, 200
On Thu, Nov 08, 2007 at 09:27:53PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 07:53:13PM +0100, Enrico Forestieri wrote:
> > On Thu, Nov 08, 2007 at 06:13:15PM +0100, Andre Poenitz wrote:
> > > On Thu, Nov 08, 2007 at 01:55:44PM +0100, Enrico Forestieri wrote:
> > > > At least, I would s
On Thu, Nov 08, 2007 at 09:13:37PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 09:01:55PM +0100, Andre Poenitz wrote:
> > On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
> > > Author: forenr
> > > Date: Thu Nov 8 07:05:19 2007
> > > New Revision: 21513
> > >
> > > URL
On Thu, Nov 08, 2007 at 07:53:13PM +0100, Enrico Forestieri wrote:
> On Thu, Nov 08, 2007 at 06:13:15PM +0100, Andre Poenitz wrote:
> > On Thu, Nov 08, 2007 at 01:55:44PM +0100, Enrico Forestieri wrote:
> > > At least, I would suggest changing
> > >
> > > #ifdef _MSC_VER
> > >
> > > into
> > >
On Thu, Nov 08, 2007 at 09:01:55PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
> > Author: forenr
> > Date: Thu Nov 8 07:05:19 2007
> > New Revision: 21513
> >
> > URL: http://www.lyx.org/trac/changeset/21513
> > Log:
> > Fix problems with odoc
On Thu, Nov 08, 2007 at 09:04:37PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 07:53:13PM +0100, Enrico Forestieri wrote:
> > On Thu, Nov 08, 2007 at 06:13:15PM +0100, Andre Poenitz wrote:
> > > On Thu, Nov 08, 2007 at 01:55:44PM +0100, Enrico Forestieri wrote:
> > > > At least, I would s
On Thu, Nov 08, 2007 at 09:01:55PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
> > Author: forenr
> > Date: Thu Nov 8 07:05:19 2007
> > New Revision: 21513
> >
> > URL: http://www.lyx.org/trac/changeset/21513
> > Log:
> > Fix problems with odoc
On Thu, Nov 08, 2007 at 08:47:29PM +0200, Martin Vermeer wrote:
> On Thu, Nov 08, 2007 at 06:02:02PM +0100, Jean-Marc Lasgouttes wrote:
> > Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > > n times for every string you want to 'branchify', i.e., n times for every
> > > case in a 'cases' stateme
On Thu, Nov 08, 2007 at 07:53:13PM +0100, Enrico Forestieri wrote:
> On Thu, Nov 08, 2007 at 06:13:15PM +0100, Andre Poenitz wrote:
> > On Thu, Nov 08, 2007 at 01:55:44PM +0100, Enrico Forestieri wrote:
> > > At least, I would suggest changing
> > >
> > > #ifdef _MSC_VER
> > >
> > > into
> > >
On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
> Author: forenr
> Date: Thu Nov 8 07:05:19 2007
> New Revision: 21513
>
> URL: http://www.lyx.org/trac/changeset/21513
> Log:
> Fix problems with odocstream on "exotic" systems caused by the strfwd gimmick.
>
> * src/suppo
On Thursday 08 November 2007 16:51:33 José Matos wrote:
> Hi,
> today while reviewing old packages I found a bug in lyx2lyx where it
> does
> not work convert documents with a "default" language.
>
> The change happened in 1.1.6 and we have the corresponding
> transformation,
> the pr
On Thu, Nov 08, 2007 at 07:49:36AM +0200, Martin Vermeer wrote:
...
> BTW I just realized that the same method can already be applied
> manually, without modifying LyX. Just include the above command
> definitions inside ERT inside branch insets at the start of the
> document, activating/deactiv
On Thu, Nov 08, 2007 at 06:02:02PM +0100, Jean-Marc Lasgouttes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> > n times for every string you want to 'branchify', i.e., n times for every
> > case in a 'cases' statement, n times the number of branchifyable strings
> > in an XFig graphic, et
On Thu, Nov 08, 2007 at 06:13:15PM +0100, Andre Poenitz wrote:
> On Thu, Nov 08, 2007 at 01:55:44PM +0100, Enrico Forestieri wrote:
> > At least, I would suggest changing
> >
> > #ifdef _MSC_VER
> >
> > into
> >
> > #if ! defined(__GNUC__)
> >
> > as I think that forward declaring string is a
On Thu, Nov 08, 2007 at 01:55:44PM +0100, Enrico Forestieri wrote:
> At least, I would suggest changing
>
> #ifdef _MSC_VER
>
> into
>
> #if ! defined(__GNUC__)
>
> as I think that forward declaring string is a gcc-ism.
On what foundations did you base your thinking?
Andre'
On Thu, Nov 08, 2007 at 02:01:05PM +0100, Abdelrazak Younes wrote:
> Hum, there is even more than I though; in strfwd.h:
>
> #ifdef USE_WCHAR_T
>
> // Prefer this if possible because GNU libstdc++ has usable
> // std::ctype locale facets but not
> // std::ctype. gcc older than 3.4 is also missing
>
Martin Vermeer <[EMAIL PROTECTED]> writes:
> BTW I just realized that the same method can already be applied
> manually, without modifying LyX. Just include the above command
> definitions inside ERT inside branch insets at the start of the
> document, activating/deactivating as appropriate.
Yes.
Martin Vermeer <[EMAIL PROTECTED]> writes:
> n times for every string you want to 'branchify', i.e., n times for every
> case in a 'cases' statement, n times the number of branchifyable strings
> in an XFig graphic, etc., where n is the number of branches. Remember
> this is ERT-like. It's not LyX
On Thu, Nov 08, 2007 at 09:44:26AM +0100, Abdelrazak Younes wrote:
> Tommaso Cucinotta wrote:
>> Andre Poenitz ha scritto:
>>> of use): #include pulls in 62000 lines of code.
>>>
>> Ok, I didn't know about such issue. this was definitively
>> persuading as a reason for not using that, thanx.
>>
Hi,
today while reviewing old packages I found a bug in lyx2lyx where it
does not
work convert documents with a "default" language.
The change happened in 1.1.6 and we have the corresponding
transformation,
the problem is that now we try to find the document encoding before
co
On Thu, Nov 08, 2007 at 08:50:49AM +0100, Stefan Schimanski wrote:
>
> Am 08.11.2007 um 01:07 schrieb Andre Poenitz:
>
>> On Thu, Nov 08, 2007 at 12:01:16AM +0100, Stefan Schimanski wrote:
Nope, that's Stefan's work...
Stefan?
> - return QColor(v*minr+(1-v)*maxr, v*ming+(1-v)*max
On Thu, Nov 08, 2007 at 08:24:49AM +0100, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
>> On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
>>> Author: forenr
>>> Date: Thu Nov 8 07:05:19 2007
>>> New Revision: 21513
>>>
>>> URL: http://www.lyx.org/trac/changeset/21513
>>>
On Thu, Nov 08, 2007 at 07:45:40AM +0200, Martin Vermeer wrote:
> On Wed, Nov 07, 2007 at 10:27:07PM +0100, Andre Poenitz wrote:
> > On Wed, Nov 07, 2007 at 10:27:21PM +0200, Martin Vermeer wrote:
> > > > > @@ -269,6 +272,12 @@
> > > > >
> > > > > void InsetBranch::validate(LaTeXFeatures & featu
On Thu, Nov 08, 2007 at 08:18:25PM +1800, Bo Peng wrote:
> Andre,
>
> Please format the attached file and send it back to me.
>
> Questions:
>
> 1. Do we use space for alignment? When do we use tab?
We use tabs for logical indentation as for bodys of function
definitions, stuff 'within' for, if
On Thu, Nov 08, 2007 at 03:40:11PM +0100, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > On Thu, Nov 08, 2007 at 02:45:36PM +0100, Enrico Forestieri wrote:
> >> On Thu, Nov 08, 2007 at 02:25:29PM +0100, Abdelrazak Younes wrote:
> >>> Enrico Forestieri wrote:
> >> [...]
> I don't have
On Thu, 08 Nov 2007 15:33:55 +0100
Tommaso Cucinotta <[EMAIL PROTECTED]> wrote:
...
> It seems in this practical world, nobody cares anymore about optimizations.
> After all, we have to give something to do to our quad-core machines,
> right ? :-)
>
> I know perfectly what you're talking about,
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 02:45:36PM +0100, Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 02:25:29PM +0100, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
[...]
I don't have gcc 3.3 and could not test it. I'd rather not change it
unless someone reports problems.
S
Helge Hafting ha scritto:
Ideally, you don't update the entire screen on scrolling.
If the scroll is less than a screenfull, just let the windowing
system move the part that stays visible. And then you draw
only the exposed part. A nice speedup, especially when working
across the network.
Ideall
On Thu, Nov 08, 2007 at 02:45:36PM +0100, Enrico Forestieri wrote:
> On Thu, Nov 08, 2007 at 02:25:29PM +0100, Abdelrazak Younes wrote:
> > Enrico Forestieri wrote:
> [...]
> > > I don't have gcc 3.3 and could not test it. I'd rather not change it
> > > unless someone reports problems.
> >
> > So
On Thu, Nov 08, 2007 at 02:01:44PM +0100, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
[...]
> > Maybe we could
> > simply forward declare string for every platform. Will make some tests.
>
> Right. Be my guest ;-)
I did it:
http://www.lyx.org/trac/changeset/21518
--
Enrico
On Thu, Nov 08, 2007 at 02:25:29PM +0100, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
[...]
> > I don't have gcc 3.3 and could not test it. I'd rather not change it
> > unless someone reports problems.
>
> So I am wrong and USE_WCHAR_T is correctly detected and used. Then why
> did you pu
On Thu, Nov 08, 2007 at 02:28:26PM +0100, Abdelrazak Younes wrote:
> You are of course. Still, why don't we just generalised the code to use
> boost::uint32_t on all platforms? This would allow us to get rid of the
> configure testing for wchar_t etc.
Look at the comment in strfwd.h ;-)
Moreov
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 01:54:33PM +0100, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
Author: forenr
Date: Thu Nov 8 07:05:19 2007
New Revision: 21513
URL: http://www.lyx.org/trac/changeset/2151
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 02:01:05PM +0100, Abdelrazak Younes wrote:
Hum, there is even more than I though; in strfwd.h:
#ifdef USE_WCHAR_T
// Prefer this if possible because GNU libstdc++ has usable
// std::ctype locale facets but not
// std::ctype. gcc older than 3.4
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
By the way, IIUC you did this move because USE_WCHAR_T is defined in
which is included only in the cpp, right?
In this case you might also want to do the same for the char_traits
implementation
On Thu, Nov 08, 2007 at 02:01:05PM +0100, Abdelrazak Younes wrote:
> Hum, there is even more than I though; in strfwd.h:
>
> #ifdef USE_WCHAR_T
>
> // Prefer this if possible because GNU libstdc++ has usable
> // std::ctype locale facets but not
> // std::ctype. gcc older than 3.4 is also missin
On Thu, Nov 08, 2007 at 01:54:33PM +0100, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
> >> Author: forenr
> >> Date: Thu Nov 8 07:05:19 2007
> >> New Revision: 21513
> >>
> >> URL: http://www.lyx.org/trac/changeset/2151
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
By the way, IIUC you did this move because USE_WCHAR_T is defined in
which is included only in the cpp, right?
In this case you might also want to do the same for the char_traits
implementation beginning at docstring.h:
Koji Yokota <[EMAIL PROTECTED]> writes:
>> I do not know how to handle that actually. Even worse, what if some
>> people try to make a document in french+japanese?
>>
>
> As far as babel is used, platex can cover most of major western
> languages (maybe all languages) that babel supports, if a
Pavel Sanda wrote:
> playing with it i finally found a recipe to crash mentioned in bug 4316.
> are you able to reproduice i?
No. Do you have a backtrace?
> 1. launch lyx
> 2. new file, insert box
> 3. type "d" inside box
> 4. type "d" before box
> 5. open new window 2
> 6. in window 2 click on
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> By the way, IIUC you did this move because USE_WCHAR_T is defined in
> which is included only in the cpp, right?
>
> In this case you might also want to do the same for the char_traits
> implementation beginning at docstring.h:92:
>
In any case, whe
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 01:45:42PM +0100, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 08:51:06AM +0100, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
Abdel, I am not sure it is ok with MSVC. Can you confirm it?
This did the trick:
H
> > i vaguely remember some incidental problems with the width of some insets
> > when working.
>
> Could you get a bit more precise?
i'm not able to reproduce it now.
playing with it i finally found a recipe to crash mentioned in bug 4316.
are you able to reproduice i?
1. launch lyx
2. new fil
Abdelrazak Younes wrote:
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 06:05:20AM -,
[EMAIL PROTECTED] wrote:
Author: forenr
Date: Thu Nov 8 07:05:19 2007
New Revision: 21513
URL: http://www.lyx.org/trac/changeset/21513
Log:
Fix problems with odocstream on "exotic" systems caused by th
On Thu, Nov 08, 2007 at 01:45:42PM +0100, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > On Thu, Nov 08, 2007 at 08:51:06AM +0100, Abdelrazak Younes wrote:
> >> Enrico Forestieri wrote:
> >
> >>> Abdel, I am not sure it is ok with MSVC. Can you confirm it?
> >> This did the trick:
> >
>
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 06:05:20AM -, [EMAIL PROTECTED] wrote:
Author: forenr
Date: Thu Nov 8 07:05:19 2007
New Revision: 21513
URL: http://www.lyx.org/trac/changeset/21513
Log:
Fix problems with odocstream on "exotic" systems caused by the strfwd gimmick.
Enrico Forestieri wrote:
On Thu, Nov 08, 2007 at 08:51:06AM +0100, Abdelrazak Younes wrote:
Enrico Forestieri wrote:
Abdel, I am not sure it is ok with MSVC. Can you confirm it?
This did the trick:
Hmm, yep. Looking at
http://msdn2.microsoft.com/en-us/library/1af12yty(VS.80).aspx
I see tha
On Thu, Nov 08, 2007 at 08:51:06AM +0100, Abdelrazak Younes wrote:
> Enrico Forestieri wrote:
> > Abdel, I am not sure it is ok with MSVC. Can you confirm it?
>
> This did the trick:
Hmm, yep. Looking at
http://msdn2.microsoft.com/en-us/library/1af12yty(VS.80).aspx
I see that the forward declara
Martin Vermeer wrote:
Looks like an svn error... change markers. Are they in your local copy?
The file was broken indeed. svn refused to update or revert it,
which is strange. I had to delete it in order to make svn
work.
I got the same errors though, and they don't make sense:
../../lyx-de
Am 08.11.2007 um 10:49 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 08.11.2007 um 10:20 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 08.11.2007 um 09:33 schrieb Abdelrazak Younes:
By the way, about the monochrome mode, it seems that the mode
could not be leaved after
On Thu, 08 Nov 2007 10:38:44 +0100
Helge Hafting <[EMAIL PROTECTED]> wrote:
> Martin Vermeer wrote:
...
> >>> void InsetBranch::validate(LaTeXFeatures & features) const
> >>> {
> >>> + string const name = to_utf8(params_.branch);
> >>> + features.require(name);
> >>> + if (selected_)
> >>> +
Juergen Spitzmueller wrote:
Edwin Leuven wrote:
i had the impression a password was needed
It is. But it's not really secret (I found it within 5 minutes on the
Internet).
how lame...
Edwin Leuven wrote:
> i had the impression a password was needed
It is. But it's not really secret (I found it within 5 minutes on the
Internet).
Jürgen
Stefan Schimanski wrote:
Am 08.11.2007 um 10:20 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 08.11.2007 um 09:33 schrieb Abdelrazak Younes:
By the way, about the monochrome mode, it seems that the mode could
not be leaved after ArgumentProxy::draw():
void draw(PainterInfo & pi,
Juergen Spitzmueller wrote:
Edwin Leuven wrote:
perhaps someone can update the links to 1.5.2 here:
http://wiki.lyx.org/Windows/Windows
Why not you?
i had the impression a password was needed
Martin Vermeer wrote:
On Wed, Nov 07, 2007 at 09:06:52PM +0100, Andre Poenitz wrote:
On Wed, Nov 07, 2007 at 09:29:38PM +0200, Martin Vermeer wrote:
Has anybody else noticed that the branches feature doesn't work inside
math and inside graphics?
Not me ;-)
It would be esp
Am 08.11.2007 um 10:20 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 08.11.2007 um 09:33 schrieb Abdelrazak Younes:
By the way, about the monochrome mode, it seems that the mode
could not be leaved after ArgumentProxy::draw():
void draw(PainterInfo & pi, int x, int y) const {
Tommaso Cucinotta wrote:
Helge Hafting ha scritto:
6) I said that already but there's a number of optimisation that are
gone now because you basically do a full screen update at each
operation.
Please, note that the updateFlags are still correctly produced by the
various
(quite obscure) code
Stefan Schimanski wrote:
Am 08.11.2007 um 09:33 schrieb Abdelrazak Younes:
By the way, about the monochrome mode, it seems that the mode could
not be leaved after ArgumentProxy::draw():
void draw(PainterInfo & pi, int x, int y) const {
if (mathMacro_.editing()) {
pi.pain.leaveMo
Am 08.11.2007 um 07:08 schrieb Enrico Forestieri:
On Wed, Nov 07, 2007 at 10:55:23AM +0100, Stefan Schimanski wrote:
This commit breaks the MathStream class. You get plenty of ascii
codes
if you copy a part of a formula and insert it, e.g. \frac becomes
92frac. Reverting the MathStream part
Am 08.11.2007 um 09:33 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 08.11.2007 um 01:07 schrieb Andre Poenitz:
On Thu, Nov 08, 2007 at 12:01:16AM +0100, Stefan Schimanski wrote:
Nope, that's Stefan's work...
Stefan?
-return QColor(v*minr+(1-v)*maxr, v*ming+(1-v)*maxg, v*minb+
Tommaso Cucinotta wrote:
Andre Poenitz ha scritto:
of use): #include pulls in 62000 lines of code.
Ok, I didn't know about such issue. this was definitively
persuading as a reason for not using that, thanx.
Any attempt to contact the library authors about why so
many lines of code are pulle
Pavel Sanda wrote:
> i vaguely remember some incidental problems with the width of some insets
> when working.
Could you get a bit more precise?
Jürgen
Stefan Schimanski wrote:
Am 08.11.2007 um 01:07 schrieb Andre Poenitz:
On Thu, Nov 08, 2007 at 12:01:16AM +0100, Stefan Schimanski wrote:
Nope, that's Stefan's work...
Stefan?
-return QColor(v*minr+(1-v)*maxr, v*ming+(1-v)*maxg,
v*minb+(1-v)*maxb);
+QColor c;
+c.setRgbF(v*minr+
85 matches
Mail list logo
