Hello,
I noticed two issues with the SCons build system:
* If LyX is compiled with a version suffix, the gettext mo files should
also get this suffix. So lyx.mo should become lyx.mo.
* For a Windows build, ole32.lib should be added to the linker
libraries. Aspell/Windows makes some ole32 cal
Bo Peng wrote:
Why lyx/aspell/mingw works but lyx/aspell/msvc does not? Is it because
we use standard aspell under mingw, but cvs aspell under msvc?
No, it's not related to the Aspell version. I don't know the details,
Peter says a pointer managed by lyx is null when it is dereferenced.
Mayb
So it's indeed a LyX bug. Can someone have a look at the problem? It's
the only thing left before a 1.4.3svn / MSVC build can be released.
Why lyx/aspell/mingw works but lyx/aspell/msvc does not? Is it because
we use standard aspell under mingw, but cvs aspell under msvc?
Bo
Peter Kümmel wrote:
> LyX crashes because a pointer managed by lyx is null when it
> is dereferenced, so I don't think it is an aspell error.
> We only had luck with the mingw version.
So it's indeed a LyX bug. Can someone have a look at the problem? It's
the only thing left before a 1.4.3svn /
On Wed, 30 Aug 2006 14:31:05 +0200 Helge Hafting <[EMAIL PROTECTED]>
wrote:
> From reading the related bug reports 2093 and 2671, I know there is
> some problems with branches & lists. This is about branch stuff that
> can
> be done, but in an unnecessarily cumbersome and surprising way.
>
>
Georg Baum wrote:
Lars Gullik Bjønnes wrote:
Why cannot the converson functions be allowd to stay in one place?
(unicode.Ch)
After all we are not supposed to use them all the time.
They can also go to unicode.[Ch]. I did not do that because that would mean
to add lots of #include during the
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Yes, I mean argument and data_. Maybe nothing is stored for that
particular lfun in argument anymore, but others do still use argument.
You did not change getArg(), and you also forgot to adjust operator==.
I did not forgot anything
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Yes, I mean argument and data_. Maybe nothing is stored for that
>> particular lfun in argument anymore, but others do still use argument.
>> You did not change getArg(), and you also forgot to adjust operator==.
>
> I did not forgot anything. I cre
Lars Gullik Bjønnes wrote:
> Why cannot the converson functions be allowd to stay in one place?
> (unicode.Ch)
> After all we are not supposed to use them all the time.
They can also go to unicode.[Ch]. I did not do that because that would mean
to add lots of #include during the transition proce
Georg Baum <[EMAIL PROTECTED]> writes:
| Abdelrazak Younes wrote:
|
| > Georg Baum wrote:
| >> Yes. You store now the data twice, and it is not synchronised.
| >
| > If you mean data_ and QLyXKeySym, it was like this before, I am just
| > mapping functionalities with the old code. Port first, cl
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Yes. You store now the data twice, and it is not synchronised.
If you mean data_ and QLyXKeySym, it was like this before, I am just
mapping functionalities with the old code. Port first, cleanup second.
If you mean argument and data
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Yes. You store now the data twice, and it is not synchronised.
>
> If you mean data_ and QLyXKeySym, it was like this before, I am just
> mapping functionalities with the old code. Port first, cleanup second.
> If you mean argument and data_, then n
Michael Gerz wrote:
I guess there are many other dialogs in which the logical order of the
field is strange.
you're right
i went through all of them and hope things look better now.
Georg Baum wrote:
Abdelrazak Younes wrote:
Here is a new patch, working this time and tested.
Objection?
Yes. You store now the data twice, and it is not synchronised.
If you mean data_ and QLyXKeySym, it was like this before, I am just
mapping functionalities with the old code. Port firs
Abdelrazak Younes wrote:
> Here is a new patch, working this time and tested.
>
> Objection?
Yes. You store now the data twice, and it is not synchronised.
Wait a bit, I am currently compiling an alternative.
Georg
Michael Gerz wrote:
the fields in the Qt4 box dialog are ordered strangely. makes you
jump back and forth between the different fields.
is ok now. also cleaned up the layout a bit...
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This back and forth conversion to utf8 is obviously extraneous and
| should be deleted. We have two solutions:
| | 1) use something else that FuncRequest::argument to store the
| characters to be
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This back and forth conversion to utf8 is obviously extraneous and
| should be deleted. We have two solutions:
|
| 1) use something else that FuncRequest::argument to store the
| characters to be inserted. I am thinking
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Hello,
|
| For each character key typed, two conversions occurs:
|
| lyxfunc.C: 324
| if (func.action == LFUN_SELF_INSERT) {
| if (encoded_last_key != 0) {
| std::vector tmp =
|
Hello,
For each character key typed, two conversions occurs:
lyxfunc.C: 324
if (func.action == LFUN_SELF_INSERT) {
if (encoded_last_key != 0) {
std::vector tmp =
ucs4_to_utf8(encoded_last_key);
On Tue, Aug 29, 2006 at 07:58:24PM +0200, Enrico Forestieri wrote:
> > I've tested it under Windows and Linux and the patch fixes all the
> > display issues, great.
>
> I cannot get some math symbols right, most notably greek characters.
I guess with Unicode support the math symbol stuff should b
On Wed, Aug 30, 2006 at 09:53:05AM +0200, Juergen Spitzmueller wrote:
> Michael Gerz wrote:
> > No objections?
>
> Well, I think inset-dissolve does not need a menu entry. It's bound to two
> keys (delete in the first inset position, backspace in the last), I think
> that's enough. The menus ten
Lars Gullik Bjønnes wrote:
Angus Leeming writes:
| Lars Gullik Bjønnes wrote:
| > | What's that? "No, I have an objection" or "No objection." ?
| > d/,/
|
| You're inventing syntax ;-)
|
| Either you mean 's/,//' or you mean '/,/d', this latter removing the
| entire line.
sod sed.
tr -d ','
Abdelrazak Younes wrote:
Anyway. I think you semi-convinced me that passing "odocstringstream" to
plaintext should be supported :-)
Think of it this way: the LyX core will deal with char32_t
(boost::uint32). A buffer-ed stream (and all LyX's streams are buffered)
stores its data in a streambu
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > | What's that? "No, I have an objection" or "No objection." ?
| > d/,/
|
| You're inventing syntax ;-)
|
| Either you mean 's/,//' or you mean '/,/d', this latter removing the
| entire line.
sod sed.
tr -d ','
--
Lars Gullik Bjønnes wrote:
| What's that? "No, I have an objection" or "No objection." ?
d/,/
You're inventing syntax ;-)
Either you mean 's/,//' or you mean '/,/d', this latter removing the
entire line.
Pedantically yrs,
Angus
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Abdel.
| > | Index: unicode.C
| > | ===
| > | --- unicode.C (revision 14849)
| > | +++ unicode.C (working copy)
| > | @@ -49,7 +49,7 @@
| > | |
Georg Baum wrote:
Abdelrazak Younes wrote:
[...]
and we do not want to convert to utf8 in plaintext(),
Why not?
Two important reasons maybe more:
- Because we do not want to do the ucs4 -> utf8 conversion in every inset
but in one place (at least IMO)
Note that my proposal was also to do i
qfont_metrics.C: In function 'int::smallcapswidth(const QString&,
const LyXFont&)':
qfont_metrics.C:50: error: ambiguous overload for 'operator[]' in 's[i]'
/usr/include/QtCore/qstring.h:544: note: candidates are: const QChar
QString::operator[](int) const
/usr/include/QtCore/qstring.h:693: note:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | This simple patch provides a nice speedup without any visual side
| > effect.
| > | | Comments? Objection?
| > No, objections.
|
| What's that? "No, I have an objecti
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This simple patch provides a nice speedup without any visual side effect.
|
| Comments? Objection?
No, objections.
What's that? "No, I have an objection" or "No objection." ?
| Abdel.
| Index: unicode.C
| ===
31 matches
Mail list logo
