Pavel Sanda wrote:
FYI you just encountered one of the few remaining tasks WRT unicode; and
yes, we've passed through this kind of spaghetti experience during the
unicode transition and it wasn't fun, at all! Andre' believe we should have
grep and replace all occurence of string with docstring
> FYI you just encountered one of the few remaining tasks WRT unicode; and
> yes, we've passed through this kind of spaghetti experience during the
> unicode transition and it wasn't fun, at all! Andre' believe we should have
> grep and replace all occurence of string with docstring and ostream
Pavel Sanda wrote:
exactly :-)
In practice, this does not have a big impact because these fields are
read as utf8 and stays encoded like that in the std::string. But it is
safer to use a docstring because they might get manipulated elsewhere.
the problem is that when i try to use
Jonathan Hall wrote:
To Whom It May Concern:
I am sorry that my request has upset some people. I too am annoyed by those
who take offense at every trivial thing and are hypersensitive, however it
seems that some of you would place me in that category. I only wanted to
point out that since the or
>>> exactly :-)
>>> In practice, this does not have a big impact because these fields are
>>> read as utf8 and stays encoded like that in the std::string. But it is
>>> safer to use a docstring because they might get manipulated elsewhere.
>>>
>>
>> the problem is that when i try to use docs
To Whom It May Concern:
I am sorry that my request has upset some people. I too am annoyed by those
who take offense at every trivial thing and are hypersensitive, however it
seems that some of you would place me in that category. I only wanted to
point out that since the ordering of options when
Chris Karakas wrote:
Where should I look if I wanted to correct the DocBook export, for example?
the
int docbook(odocstream &, OutputParams const &) const;
methods in the insets for a starter i guess:
ExternalTransforms.h (305): std::string const
sanitizeDocBookOption(std::string const & in
hi,
i send quite preliminary patch (only informative one, bit hand polished etc)
which will
allow graphics insets to be joined into groups, which share the same settings,
ie some kind of templates.
in the current situation group id can be assigned to images and changing
settings
of any picture
On Mon, May 05, 2008 at 06:51:14PM +0200, Helge Hafting wrote:
> Jonathan Hall wrote:
>> To Whom It May Concern:
>> When you press Alt-M to use a math shortcut, take a look at the options
>> listed at the bottom of the screen. I do not know what inspired the order
>> the options were listed in, but
On Mon, May 05, 2008 at 05:41:33PM +0200, Pavel Sanda wrote:
> > exactly :-) In practice, this does not have a big impact because
> > these fields are read as utf8 and stays encoded like that in the
> > std::string. But it is safer to use a docstring because they might
> > get manipulated elsewhere
On Mon, May 05, 2008 at 04:51:21PM +0200, Pavel Sanda wrote:
> hi,
>
> please do we have somewhere documented where should be used
> lyx::docstring (vs std::string) ?
I never saw a good reason to have this distiction at all.
I.e. using docstring everywhere would be just fine with me...
Andre'
On Mon, May 05, 2008 at 09:48:50AM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
>> What is the preferred way of resetting a std::string? The code source
>> has 166 clear for 75 erase(), although many clear() are in qt4
>> (QString?).
>>
> I prefer clear() personally; more meanin
Helge Hafting wrote:
> This patch improves the looks of various fill
Looks godd, so I committed it.
Jürgen
José Matos wrote:
> I agree with Rich, if it works it should go.
I committed it to trunk now. Please test.
I still haven't decided if it will go into 1.5.5.
Jürgen
> José Matos wrote:
> > On Monday 21 April 2008 10:30:23 Abdelrazak Younes wrote:
> >
> >> By the way, where are we WRT docbook support? Is there anything we can
> >> do to support the request of Chris Karakas who is still using LyX-1.2
> >> apparently?
> >>
> >> http://www.karakas-online.de/myS
Pavel Sanda wrote:
please do we have somewhere documented where should be used
lyx::docstring (vs std::string) ?
Simple: Use string whenever you want 7-bit ASCII only and docstring
anywhere else.
which means that e.g. members in PDFOptions class - like std::stri
Jonathan Hall wrote:
To Whom It May Concern:
When you press Alt-M to use a math shortcut, take a look at the options
listed at the bottom of the screen. I do not know what inspired the order
the options were listed in, but the letters S, E, and X are right in a row.
Perhaps some programmer thoug
Andre Poenitz wrote:
On Sun, May 04, 2008 at 09:39:43AM +0200, Abdelrazak Younes wrote:
Jonathan Hall wrote:
To Whom It May Concern:
When you press Alt-M to use a math shortcut, take a look at the options
listed at the bottom of the screen. I do not know what inspired the order
the options wer
This patch improves the looks of various fills:
* Arrowheads now have diagonal lines that meet in the correct pixel.
* Braces now have the central part, so they don't look like parentheses.
This is cosmetic only, so no format changes.
If this goes in, my next patch will deal with what happens wh
please do we have somewhere documented where should be used
lyx::docstring (vs std::string) ?
>>> Simple: Use string whenever you want 7-bit ASCII only and docstring
>>> anywhere else.
>>>
>>
>> which means that e.g. members in PDFOptions class - like std::string
>>
I'll put CC: to lyx-devel, so others might comment as well.
Jean-Pierre Chretien wrote:
> Jürgen Spitzmüller wrote:
> > Jean-Pierre Chretien wrote:
> > > 1.5.5svn compiles fine on Solaris with qt-4.3.4, but I get
> > > a lot of warnings. I guess they won't appear on the release,
> > > but I can po
Pavel Sanda wrote:
exactly :-)
In practice, this does not have a big impact because these fields are read
as utf8 and stays encoded like that in the std::string. But it is safer to
use a docstring because they might get manipulated elsewhere.
the problem is that when i try to use docstri
> exactly :-)
> In practice, this does not have a big impact because these fields are read
> as utf8 and stays encoded like that in the std::string. But it is safer to
> use a docstring because they might get manipulated elsewhere.
the problem is that when i try to use docstring internally the a
Pavel Sanda wrote:
please do we have somewhere documented where should be used
lyx::docstring (vs std::string) ?
Simple: Use string whenever you want 7-bit ASCII only and docstring
anywhere else.
which means that e.g. members in PDFOptions class - like std::stri
please do we have somewhere documented where should be used
lyx::docstring (vs std::string) ?
>>> Simple: Use string whenever you want 7-bit ASCII only and docstring
>>> anywhere else.
>>>
>>
>> which means that e.g. members in PDFOptions class - like std::string
>>
Pavel Sanda wrote:
please do we have somewhere documented where should be used lyx::docstring
(vs std::string) ?
Simple: Use string whenever you want 7-bit ASCII only and docstring
anywhere else.
which means that e.g. members in PDFOptions class - like std::string author;
are wr
>> please do we have somewhere documented where should be used lyx::docstring
>> (vs std::string) ?
>>
> Simple: Use string whenever you want 7-bit ASCII only and docstring
> anywhere else.
which means that e.g. members in PDFOptions class - like std::string author;
are wrong ?
pavel
Pavel Sanda wrote:
hi,
please do we have somewhere documented where should be used lyx::docstring (vs
std::string) ?
Simple: Use string whenever you want 7-bit ASCII only and docstring
anywhere else.
Abdel.
hi,
please do we have somewhere documented where should be used lyx::docstring (vs
std::string) ?
pavel
On Monday 05 May 2008 15:41:21 Jean-Marc Lasgouttes wrote:
> > OK, then I'll revert this. I wasn't aware that we ship these files in
> > the tarballs until Pavel prompted this to this yesterday. As I never
> > added my files there, I thought these entries were superfluous.
>
> Thanks.
+1
> JMarc
Uwe Stöhr <[EMAIL PROTECTED]> writes:
>> They should indeed stay in the release tarball.
>
> OK, then I'll revert this. I wasn't aware that we ship these files in
> the tarballs until Pavel prompted this to this yesterday. As I never
> added my files there, I thought these entries were superfluous
> They should indeed stay in the release tarball.
OK, then I'll revert this. I wasn't aware that we ship these files in the tarballs until Pavel
prompted this to this yesterday. As I never added my files there, I thought these entries were
superfluous.
Sorry and regards
Uwe
> Pavel Sanda wrote:
> > as an argument can be put any InsetGraphicsParams, from which only filename
> > would be used in editGraphics. the same is situation with insetexternal.
>
> yes.
>
> > so either the syntax would be "inset-edit []" or we should
> > remove string2params(to_utf8(cmd.argument
Pavel Sanda wrote:
> as an argument can be put any InsetGraphicsParams, from which only filename
> would be used in editGraphics. the same is situation with insetexternal.
yes.
> so either the syntax would be "inset-edit []" or we should
> remove string2params(to_utf8(cmd.argument()), buffer(), p
> Pavel Sanda wrote:
> > Juergen, are you sure this is correct syntax,
>
> yes.
>
> > i see in the code below it
> > touches cmd.argument()
>
> this is a leftover from the old graphics-edit and external-edit. I'm not sure
> about its use.
which means you can't be sure about correct syntax :)
Jean-Marc Lasgouttes wrote:
Why did you do that? The files were here in order to be distributable
(EXTRA_DIST variable). I do not see why the stuff needed to build
installers would not be in our official release.
They should indeed stay in the release tarball. I always download the
official ta
In lyx 1.5.4 I can change the document class to something that support
a different set of font sizes. For example, switching between "article" and
"article (more font sizes)".
The list of selectable font sizes then changes in LyX 1.5.4, but not in
LyX 1.6svn.
Closing and reopening the dialog do
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
JMarc,
Right-clicking does not set the cursor prior to showing the context
menu anymore.
That's weird... some time it does, some time not, randomly.
OK, I know understand: you have to dismiss the current context menu
before asking for a new o
Abdelrazak Younes wrote:
JMarc,
Right-clicking does not set the cursor prior to showing the context
menu anymore.
That's weird... some time it does, some time not, randomly.
Abdel.
José Matos wrote:
On Sunday 04 May 2008 23:50:32 Pavel Sanda wrote:
i hope i fixed this too.
Thanks Pavel,
I am tempted to take some time to complete cmake and get rid of this dreadful
nightmare. :-(
That would be a wondeful achievement!!
(In case you need some encouragment :-)
JMarc,
Right-clicking does not set the cursor prior to showing the context menu
anymore. Did you modify something in there recently?
Abdel.
On Sunday 04 May 2008 23:50:32 Pavel Sanda wrote:
> i hope i fixed this too.
Thanks Pavel,
I am tempted to take some time to complete cmake and get rid of this
dreadful
nightmare. :-(
> Jose, please can you try to release alpha3 soon before continuing work
> again break something else
Jean-Marc Lasgouttes wrote:
What is the preferred way of resetting a std::string? The code source
has 166 clear for 75 erase(), although many clear() are in qt4
(QString?).
I prefer clear() personally; more meaningful.
Abdel.
What is the preferred way of resetting a std::string? The code source
has 166 clear for 75 erase(), although many clear() are in qt4
(QString?).
JMarc
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
>> Just distribute 1.5.5 without the
>> patch, since it _might_ break something.
>
> OK. If you find time, could you try to help Uwe with bug 4806?
I'll try to have a look. The reason I did not react to your earlier
cry for help on this is that I do
[EMAIL PROTECTED] writes:
> Author: uwestoehr
> Date: Mon May 5 00:15:53 2008
> New Revision: 24604
>
> URL: http://www.lyx.org/trac/changeset/24604
> Log:
> development/Makefile.am: installers are not compiled by make, so take them
> out of the makefile. (they are for the same reason also not i
46 matches
Mail list logo
