Hi,
Could someone please upload the new LyXWinInstaller for LyX 1.4.2 at
ftp.lyx.org in the directory
ftp://ftp.lyx.org/pub/lyx/contrib/LyXWinInstaller/LyX142/
Thanks,
Andreas
Hello,
I finished my trip through the list of LFUNs. There are 5 nice LFUNs
left for which I would like to add a menu entry. With these additions,
the menu is feature-complete now!
OK?
Michael
PS: Paragraph-Move-Up/Down is REALLY nice!
Index: stdmenus.ui
==
Hi,
while looking for interesting LFUNs that deserve a menu entry (such that
users can adore them), I came across a few functions which look
unused/outdated/unimplemented.
? caption-insert - no effect
? drop-layouts-choice- unused in the code
? environment-insert - LyX crashes
Juergen Spitzmueller schrieb:
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 tend to be overloaded anyway.
No, it definitely needs a menu entry - for the reason why w
Aspell 0.60.4 and the cvs version are now
usable on windows when compiled with msvc.
But there is a lyx related bug: this patch
Index: ControlSpellchecker.C
===
--- ControlSpellchecker.C (revision 14851)
+++ ControlSpellchecker
Hi Edwin,
the fields in the Qt4 box dialog are ordered strangely. makes you
jump back and forth between the different fields.
I guess there are many other dialogs in which the logical order of the
field is strange.
Regards, Michael
Peter Kümmel wrote:
> There was a bug in their vector.hpp implementation. With the patch it don't
> crashes any more but now I have a other error message from aspell :
>
> .../standart.kbd:3: The string "qw" is invalid.
>
> The good news is that I've the same message with the cvs version
> (the l
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This simple patch provides a nice speedup without any visual side effect.
|
| Comments? Objection?
No, objections.
| Abdel.
| Index: unicode.C
| ===
| --- unicode.C (revision 14849)
Joost Verburg wrote:
> Peter Kümmel wrote:
>> When I start the spell checker lyx crashes because of
>> the debug code in stl:
>> I think this is a aspell problem. The only chance we have is that it
>> works in
>> the release mode, start compiling know.
>
> The release version crashes for me as wel
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Abdelrazak Younes wrote:
>>
>>> Georg Baum wrote:
A char is not a "character in the stream sense" if you want to output
it to a 4 byte wide stream.
Look e.g. at this code from insetnote.C:
ostringstream ss;
David Hall wrote:
Hi,
I need some help getting LyX working. I'm using 1.4.2 on Windows XP.
Loaded full install and keep getting
"The document uses a missing TeX class "".
Lyx will not be able to produce output. "
where classname varies depending on the file loaded.
At first, I couldn't get t
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
A char is not a "character in the stream sense" if you want to output it
to a 4 byte wide stream.
Look e.g. at this code from insetnote.C:
ostringstream ss;
ss << "[";
InsetText::plaintext(buf, ss, runparams)
Peter Kümmel wrote:
> And am I right that the current plan to complete the Unicode support is:
>
> 1. find a 32bit per character string class: docstring
We have that already.
> 2. find docstring streams
Yes (almost done, we only need to decide how to resolve the character
widening problem).
This simple patch provides a nice speedup without any visual side effect.
Comments? Objection?
Abdel.
Index: unicode.C
===
--- unicode.C (revision 14849)
+++ unicode.C (working copy)
@@ -49,7 +49,7 @@
char ICONV_CONST
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> A char is not a "character in the stream sense" if you want to output it
>> to a 4 byte wide stream.
>> Look e.g. at this code from insetnote.C:
>>
>> ostringstream ss;
>> ss << "[";
>> InsetText::plaintext(buf, ss, runparams
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Ah but you are talking about ostringstream here not ostream. This
| > is a
| > | different problem: if ss was an ostream, ss << "]" would
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Ah but you are talking about ostringstream here not ostream. This
| > is a
| > | different problem: if ss was an ostream, ss << "]" would really output
| > | a single
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Ah but you are talking about ostringstream here not ostream. This is a
| different problem: if ss was an ostream, ss << "]" would really output
| a single one-bite char and that's what we want.
stringstream is an ostream
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Ah but you are talking about ostringstream here not ostream. This is a
| different problem: if ss was an ostream, ss << "]" would really output
| a single one-bite char and that's what we want.
stringstream is an ostream
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Ah but you are talking about ostringstream here not ostream. This is a
| different problem: if ss was an ostream, ss << "]" would really output
| a single one-bite char and that's what we want.
stringstream is an ostream... you mean fstream.
--
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
No, that would not work for stringstreams for example. We use them a lot
to construct strings, and therefore we need a full ucs4 stringstream.
But ucs4 stringstream is an unrelated problem IMHO, the characters
passing through the st
On Aug 30, 2006, at 9:25 AM, Sebastian Spaeth wrote:
Bennett Helm wrote:
On Aug 22, 2006, at 8:18 PM, Bo Peng wrote:
Nope. It's Preview that is opened then. In fact, if I export the
file
with LyX and go to Finder to open the file, Preview gets opened.
Only
when I choose 'View' do I get Qui
Any more hints on what could be wrong here?
No idea yet. But you can always set a viewer explicitly to get around
this problem for now.
Cheers,
Bo
In src/support/os_cygwin.C path styles are converted (when needed) from
one style to another. I discovered a couple of cases in which an
unnecessary conversion takes place.
The default output path style in external_path is windows because this
function is also used when adding fonts though a nativ
Bennett Helm wrote:
> On Aug 22, 2006, at 8:18 PM, Bo Peng wrote:
>>> Nope. It's Preview that is opened then. In fact, if I export the file
>>> with LyX and go to Finder to open the file, Preview gets opened. Only
>>> when I choose 'View' do I get Quicktime Player.
> It's actually something strang
Hi,
I need some help getting LyX working. I'm using 1.4.2 on Windows XP.
Loaded full install and keep getting
"The document uses a missing TeX class "".
Lyx will not be able to produce output. "
where classname varies depending on the file loaded.
At first, I couldn't get the user guide loaded
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> No, that would not work for stringstreams for example. We use them a lot
>> to construct strings, and therefore we need a full ucs4 stringstream.
>
> But ucs4 stringstream is an unrelated problem IMHO, the characters
> passing through the streams wi
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> Abdelrazak Younes wrote:
>>
>>> Exactly and that was my argument but Lars insisted that the vector
>>> solution is better. He even said that docstring would probably better
>>> use vector instead.
>>
>> I must have overread that.
>
> Just for referen
Abdelrazak Younes wrote:
I don't understand... Why do you want to widen a char before outputting
it? A char is a char and the default std::ostream is normally used as it
should be.
Yes... But for normal char
That sentence slipped in there god knows how... please ignore.
operator<<(std::ost
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Georg Baum wrote:
> | > Does this mean that we need to implement our own
> | > char_traits? I would rather avoid that. On linux one
> could
> | > simply use wchar_t instead of boost::uint32_t, but wchar_t is only 16 bit
Georg Baum wrote:
Abdelrazak Younes wrote:
I don't understand much your problem other than the conversion from char
to uint32 is not immediate as this type is not of characters type. But
you know that already.
Yes. The std library has support for so called "widening" of characters in
theory,
Angus Leeming <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Does this mean that we need to implement our own
| > char_traits? I would rather avoid that. On linux one could
| > simply use wchar_t instead of boost::uint32_t, but wchar_t is only 16 bit
| > on windows. Do other alternatives exis
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.
I write multilingual documents, where each list item is in two
languages. The document sh
Abdelrazak Younes wrote:
> I don't understand much your problem other than the conversion from char
> to uint32 is not immediate as this type is not of characters type. But
> you know that already.
Yes. The std library has support for so called "widening" of characters in
theory, but in practice
Georg Baum wrote:
As I already wrote I had a closer look on plain text output. Among other
things I changed the stream type for plain text output to use ucs4
characters (see attached diff). This is IMO a must, because it makes
outputting docstrings much easier. The conversion to utf8 is done else
Thought you might be interested in this proposal to add unicode support
to the standard library. Not of much use to you right now, but one day...
Minimal Unicode support for the standard library
Matthew Austern
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2035.pdf
Angus
Peter Kümmel wrote:
Your test program does not crash when compiled with msvc, so why not use wchar_t
under linux/gcc/mingw and unsigne int with msvc.
IIRC, wchar_t on MinGW is 16 bits. But sure, a configure-time test of
the suitablility of the system std::char_traits is a good
idea. We used t
Georg Baum wrote:
Does this mean that we need to implement our own
char_traits? I would rather avoid that. On linux one could
simply use wchar_t instead of boost::uint32_t, but wchar_t is only 16 bit
on windows. Do other alternatives exist on windows? Can we simply plug in
some existing char_trai
Georg Baum wrote:
> As I already wrote I had a closer look on plain text output. Among other
> things I changed the stream type for plain text output to use ucs4
> characters (see attached diff). This is IMO a must, because it makes
> outputting docstrings much easier. The conversion to utf8 is don
As I already wrote I had a closer look on plain text output. Among other
things I changed the stream type for plain text output to use ucs4
characters (see attached diff). This is IMO a must, because it makes
outputting docstrings much easier. The conversion to utf8 is done elsewhere
(and is not in
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
In this patch I use simple casts instead of the costly ucs2_to_ucs4
and ucs4_to_ucs2 functions. It turned out that all display issues are
resolved... including math! It even brings a very nice speed-up...
Here is a cleaned up version of the pa
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Maybe it is worth to define a inline function in qt_helpers:
QChar const & ucs4_to_QChar(char_type c)
Yes but without the ref, see my newer patch.
Index: frontends/qt4/QLyXKeySym.C
=
On Tue, Aug 29, 2006 at 02:24:06PM +0200, Peter Kümmel wrote:
> Maybe it is worth to define a inline function in qt_helpers:
>
>
> QChar const & ucs4_to_QChar(char_type c)
> {
> return QChar(static_cast(c));
> }
>
>
> then QChar(static_cast(c)) could be replaced with a more verbose code
> u
Georg Baum wrote:
Abdelrazak Younes wrote:
Exactly and that was my argument but Lars insisted that the vector
solution is better. He even said that docstring would probably better
use vector instead.
I must have overread that.
Just for reference, here are his exact words:
Abdelrazak Younes
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 tend to be overloaded anyway.
But I have another candidate:
Item "Phonetic Symbols|y
Abdelrazak Younes wrote:
> Exactly and that was my argument but Lars insisted that the vector
> solution is better. He even said that docstring would probably better
> use vector instead.
I must have overread that.
Georg
Georg Baum wrote:
Abdelrazak Younes wrote:
But wait... that's docstring we are talking about here ;-)
IMHO we must merge this docstring and the vector.
I don't agree.
Well I think you agree with me below ;-)
I just meant that we don't need two types.
We need
only one type! Lars seems to
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
And he is right. Therefore the comment that it should go eventually. The
problem is that we currently have _a lot_ of utf8 encoded data in
std::string. All these strings need to be converted to docstring. It is
not practical to do th
48 matches
Mail list logo
