Re: InsetGraphics
On 07-Jul-2000 Baruch Even wrote: On Fri, 7 Jul 2000, Juergen Vigna wrote: Is there any reason why to do that instead of just a simple: \begin_inset Graphics filename /tmp/platypus.png rotate 0 display monochrome ... \end_inset Seems good for me! This way seems to me to be easier to parse, though I admit that I still haven't looked on your inset's Read/Write methods. It is not that hard and I have methods in tabular.C which I would like to put in the support directory which make reading it easier! Is there an intention to move LyX to XML format? Well we had some discussions about that, but IMO it's not really important (maybe others have other opinions ;), I just had to change the tabular-format as a lot of people complaint about that, especitally people writing converters so I thougth I make it easier for them #:O) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Eternal nothingness is fine if you happen to be dressed for it. -- Woody Allen
RE: More Inset question (InsetGraphics)
On 07-Jul-2000 Baruch Even wrote: After some more work on the inset I've got even more questions. 1. Marking the buffer dirty. After my inset gets changed by the dialog, how should I go about notifying lyx that the data has changed? I know of the markxxxDirty, but how do I get access to them? basically it amounts to "how do I get a pointer to buffer from a function that isnt called by buffer?" Why buffer you need a "BufferView *" and you have to call in any case bview-updateInset(inset, mark_dirty) (at least if you want to implement the visual feedback sometime in the future :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Sattinger's Law: It works better if you plug it in.
Re: New CVS Solaris configure patch breaks compilation
"Kayvan" == Kayvan Sylvan [EMAIL PROTECTED] writes: Kayvan Content-Type: text/plain; charset=us-ascii Hi everyone, Kayvan Te latest configure.in patch breaks configure/compilation on Kayvan my Solaris box: Kayvan The problem is probably related to the fact that I use the Kayvan extra include and extra lib directory flags in addition to Kayvan putting the fragment ``-isystem /usr/openwin/include'' in my Kayvan CXXFLAGS and CFLAGS. Could you show me what the config.log file says about xpm.h?
bug report
Reading an old lyx file with current CVS, I notice that protected blanks are converted to SpecialChar \- rather than SpecialChar ~ Angus
Re: Problems compiling lyx 1.1.5pre3
Pablo De Napoli [EMAIL PROTECTED] writes: | Hi! | | I could not lyx-1.1.5pre3 from the sources. Something is wrong with the | regex stuff. I'm using linux (debian distribution) | | g++ 2.95.2-13 | libc 2.1.2-11 | libstdc++2.10 2.95.2-13 | | I think the problem could be caused by the changes in the C library (that | now supports the posix regular expresions) | Plese, help me. Thank you This looks more like a configure problem. Do you have the functions that the linker complains about in the libc library? What does the configure log say about regex support? Lgb
RE: small patch 2
On 10-Jul-2000 Angus Leeming wrote: I reported this DEC cxx warning a few days ago. It seems that the consensus was that Inset::deleteLyXText should be a const function, but the code hasn't been updated. If it makes life easier, here is the patch. Could someone apply it, please. Thanks I did it by hand! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ An expert is one who knows more and more about less and less until he knows absolutely everything about nothing.
Hi again, and still CVS problems
At long last I think I'm back. I unsubscribed last christmas, and never got around to subscribing again (but I've still been advocating and defending wherever it came up :) I'm now on the Penn State Dubois faculty, and getting my machine running. Hopefully I can draft a student or two to turn my old mailmerge patch into a library and finally integrate it. Anyway, in the meantime, cvs doesn't like me (an ongoing occurrence). I'm running FreeBSD 4.0, and I *think* I'm following the instructions. hawkinsttyp1:hawksetenv CVSROOT "pserver:[EMAIL PROTECTED]:/usr/local/lyx/cvsroot" hawkinsttyp1:hawkecho $CVSROOT pserver:[EMAIL PROTECTED]:/usr/local/lyx/cvsroot hawkinsttyp1:hawkcd /usr/src/ hawkinsttyp1:srccvs login cvs login: can only use pserver method with `login' command cvs [login aborted]: CVSROOT: pserver:[EMAIL PROTECTED]:/usr/local/lyx/cvsroot h I get this whether I run as a user (with appropriate permissions from the wheel group) or root. rick
Re: bug report
JMarc Angus Reading an old lyx file with current CVS, I notice that JMarc Angus protected blanks are converted to SpecialChar \- rather than JMarc Angus SpecialChar ~ JMarc I do not see that with a file created with LyX 1.0.3 (read correctly JMarc with both cvs and 1.1.5fix). Do you have an example file? No, of course not! (:-) I had an old file (not too old; I've only been using lyx for 6 months!) that had a few things such as Appendix-1 when I opened the file today. They should have been Appendix_1. (Was a blue bash, should have been the protected space.) Of course, I only noticed this after I'd been editing the file for a while and saved things a few times, so my original is no more and I've no idea what the original lyx file contained (ie what lyx code. It was written originally to be a protected space.) Presumably, therefore, this is now a useless bug report. It may crop up again in more useful guise. Angus
Re: bug report
Angus Leeming wrote: JMarc Angus Reading an old lyx file with current CVS, I notice that JMarc Angus protected blanks are converted to SpecialChar \- rather than JMarc Angus SpecialChar ~ JMarc I do not see that with a file created with LyX 1.0.3 (read correctly JMarc with both cvs and 1.1.5fix). Do you have an example file? No, of course not! (:-) I had an old file (not too old; I've only been using lyx for 6 months!) that had a few things such as Appendix-1 when I opened the file today. They should have been Appendix_1. (Was a blue bash, should have been the protected space.) Of course, I only noticed this after I'd been editing the file for a while and saved things a few times, so my original is no more and I've no idea what the original lyx file contained (ie what lyx code. It was written originally to be a protected space.) Presumably, therefore, this is now a useless bug report. It may crop up again in more useful guise. Hi, maybe it was a file, with the "temporary" protected blank? Don't remember the exact intermediate value (\SpecialChar \protected_separator?). Regards, Stephan --- [EMAIL PROTECTED] | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
GTK/Gnome frontend and string class
I've tried to add some elementary support of GTK/Gnome frontend to LyX. The composed code and collection of configure .m4 scripts brings the GTK frontend to the same level as KDE one --- showing the copyright dialog box. In the code I used GTK-- and GNOME-- libraries (C++ wrappers of GTK and Gnome libraries). GTK-- and GNOME-- rely on STL string class which is not good enough for LyX on my platform (i386, redhat linux 6.0, egcs-1.1.2 or gcc-2.95.2). This is a problem since in LyX string class is typedefed to lyxstring and the resulting code does not link properly with GTK-- and GNOME-- libraries. The following solutions to this conflict between GNOME/Gtk and LyX popped into my mind: 1. Use GTK/Gnome libraries directly (in C) without C++ wrappers 2. Make LyX compatible with the string class included in libstdc++ by fixing files src/support/lstrings.C (lines 184 and 201, string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string interaction). 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this libraries with lyxstring. 4. Find better implementation of STL for Linux and use its string class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ is not good enough to compile LyX). Which of these (or any alternative) solutions should be used for LyX GTK/Gnome frontend? Regards, Marko
Re: GTK/Gnome frontend and string class
Marko Vendelin [EMAIL PROTECTED] writes: | 2. Make LyX compatible with the string class included in libstdc++ by |fixing files src/support/lstrings.C (lines 184 and 201, |string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string |interaction). You mean unfixing I hope. The lyxstring tries to be close to API compatible with std::string. | 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this |libraries with lyxstring. Isn't Gtk-- and Gnome--- a bit large for that? | 4. Find better implementation of STL for Linux and use its string |class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ |is not good enough to compile LyX). the libstdc++ is far from standard C++. The libstdc++-v3 is getting there, but there are a bit too many bugs in cvs gcc currently. | Which of these (or any alternative) solutions should be used for LyX | GTK/Gnome frontend? None of the suggestions seems really good. Can we have an interim solution where we use char* to communicate between lyx-core and the gtk frontend? When Gcc 2.96 is released it will hopefully be with the new libstdc++-v3 library, and then there will be no problems. Lgb
Re: Patch: better multi-lingual support
(I still have some difficulty sending mails.) "Asger K. Alstrup Nielsen" [EMAIL PROTECTED] wrote: Could you factor out this part of the patch? Then we can look at it, and if it looks good, apply it to cvs. I will try. But please wait! So the font selection is based on the global LC_CTYPE? Hmm, that seems a bit restrictive. Is it not possible to specifically ask for the font norms for a given locale without setting LC_CTYPE? Only if you are ready to use a semi-internal Xlib function _XOpenLC(). There are no public interfaces in Xlib to access its powerful Input/Output methods machinery without setting locale. If it is allowed to use _XOpenLC(), then an X client can manage multiple locales IM/OM at the same time. That would probably be the best solution, since we would like to support writing Japanese on a system where the LC_CTYPE might be set up for Danish. If we assume that it is possible to specify our own LC_CTYPE without really doing it (you know what I mean), how would this fit in with Dekel's approach? Dekel, can the two approaches be integrated in some way? Well, I'm not against to have a unicode based multilingual document support. I would just like to have a mode for single language documents in local encodings, just as single byte language users have at present. [EMAIL PROTECTED] (Lars Gullik Bj nes) wrote: Regardless of how it ends up: we don't want multi-byte charates as the internal representation. We also want to support multiple languages on the same time, afaik unicode is the road to accomplish this. I perfectly understand we do not want to use variable length multibyte characters as the internal representation. But any multibyte encodings have their fixed width wide charcater representation counterpart. So for a single language document, unicode *encoding* might not be obligatory. Regards, SMiyata
fdfix.sh patch
I've patched fdfix.sh and associated makefile to allow me to make forward
declarations such as
struct FD_form_citation;
class FormCitation : public DialogBase {
FD_form_citation * dialog_;
}
rather than have to include the header file. (If I so wish. Both options are now
available.)
Can somebody (Jürgen?) please check that they're happy with the changes.
Many thanks,
Angus
patch11July2000.gz
Literate Patch against latest CVS
Hi folks, Here is Bernard Michael Hurley's literate patch against the latest CVS. This includes my lib/build-listerror script, re-written to work on a generic /bin/sh, instead of requiring bash. Please apply to CVS. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory lit-prog.patch.gz build-listerrors.tgz
RE: More Inset question (InsetGraphics)
On Tue, 11 Jul 2000, Juergen Vigna wrote: 1. Marking the buffer dirty. After my inset gets changed by the dialog, how should I go about notifying lyx that the data has changed? I know of the markxxxDirty, but how do I get access to them? basically it amounts to "how do I get a pointer to buffer from a function that isnt called by buffer?" Why buffer you need a "BufferView *" and you have to call in any case Ok. Then I'll take a BufferView * instead :-) I now looked at the code and saw that indeed I need a BufferView. bview-updateInset(inset, mark_dirty) (at least if you want to implement the visual feedback sometime in the future :) Ok. one more tidbit that I'll add to my todo stuff. But the question remains unanswered, How do I get this bview pointer out of the blue? Should I save the BufferView* I get from last time and use that? It seems ugly to me, is there no other way to get this pointer? -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: GTK/Gnome frontend and string class
On 11 Jul 2000, Lars Gullik Bjønnes wrote: Marko Vendelin [EMAIL PROTECTED] writes: | 4. Find better implementation of STL for Linux and use its string |class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ |is not good enough to compile LyX). the libstdc++ is far from standard C++. The libstdc++-v3 is getting there, but there are a bit too many bugs in cvs gcc currently. How does the SGI-STL/STLport fare in relation with the standard? It might be possible to use them, and compile externally the GTK--/Gnome-- with them and then compile LyX with them too, this should solve it, although it will require quite a bit of work from anyone who wishes to use the GTK version of LyX. (I've tried to use the STLport but couldn't get LyX to find it, though I must admit I tried for a very short time and settled for lyxstring). -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers ADD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Patch: better multi-lingual support
Dekel Tsur [EMAIL PROTECTED] wrote:
We need to change the internal text storage from 8-bit to 16/32-bit,
before we can use such a patch.
Yes, I realize this (and called it 2. in the previous message.)
We also want to be able to render simultaneously Japanese, Hebrew, Russia
etc. Is it supported by Xlib? (i.e. does the XCreateOC call also load
iso8859-n font if they are available?)
OK here is the official way to use multiple fontsets:
/// after calling XSetLocaleModifiers() etc.
string real_locale = "LC_CTYPE=" + getenv(LC_CTYPE);
putenv("LC_CTYPE=ja_JP");
XOM om_ja = XOpenOM(dpy, 0, 0, 0);
putenv("LC_CTYPE=he_IL");
XOM om_he = XOpenOM(dpy, 0, 0, 0);
putenv(real_locale.c_str());
/// Now this creates a XFontSet consists of
/// ISO8859-1, JISX0208.1983-0, JISX0201.1976-0 and possibly
/// JISX0212.1990-0
XOC oc_ja = XCreateOC(om_ja,
XNBaseFontName, "-*-*-*-*-*-*-12-*", NULL);
/// And this one creates a XFontSet consists of
/// ISO8859-8 (for ch = 0x7f), and ISO8859-8 (for ch = 0x80)
XOC oc_he = XCreateOC(om_he,
XNBaseFontName, "-*-*-*-*-*-*-12-*", NULL);
/// You can draw some texts
XmbDrawString(dpy, win, oc_, gc, x1, y1,
ja_text.c_str(), ja_text.length());
XmbDrawString(dpy, win, oc_, gc, x2, y2,
he_text.c_str(), he_text.length());
If _XOpenLC() is used, you don't have to change the environment variable:
XLCd lcd_ja = _XOpenLC("ja_JP");
XOM om_ja = lcd_ja-methods-open_om(dpy, 0, 0, 0);
XLCd lcd_he = _XOpenLC("he_IL");
XOM om_he = lcd_he-methods-open_om(dpy, 0, 0, 0);
/// etc. etc.
In case you want to create a custom XFontSet, please refer to
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg07891.html
Regards,
SMiyata
Re: GTK/Gnome frontend and string class
Hello, Marko! Another solution: 1. Take the GTK--/GNOME-- headers, and use macro to change "string" to basic_stringchar for them: #define string basic_stringchar #include GTK.h #undef string You can also create wrappers for all headers that you use to add this macro automatically. 2. Add operator std::basic_stringchar() const and lyxstring(const std::basic_stringchar) const to lyxstring to make it possible to convert between GTK and lyx strings on the fly. This has an advantage that you can use GTK installed on the system, without recompilation or changing the headers. Quoting r. Marko Vendelin ([EMAIL PROTECTED]) "GTK/Gnome frontend and string class": I've tried to add some elementary support of GTK/Gnome frontend to LyX. The composed code and collection of configure .m4 scripts brings the GTK frontend to the same level as KDE one --- showing the copyright dialog box. In the code I used GTK-- and GNOME-- libraries (C++ wrappers of GTK and Gnome libraries). GTK-- and GNOME-- rely on STL string class which is not good enough for LyX on my platform (i386, redhat linux 6.0, egcs-1.1.2 or gcc-2.95.2). This is a problem since in LyX string class is typedefed to lyxstring and the resulting code does not link properly with GTK-- and GNOME-- libraries. The following solutions to this conflict between GNOME/Gtk and LyX popped into my mind: 1. Use GTK/Gnome libraries directly (in C) without C++ wrappers 2. Make LyX compatible with the string class included in libstdc++ by fixing files src/support/lstrings.C (lines 184 and 201, string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string interaction). 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this libraries with lyxstring. 4. Find better implementation of STL for Linux and use its string class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ is not good enough to compile LyX). Which of these (or any alternative) solutions should be used for LyX GTK/Gnome frontend? Regards, Marko -- This message content is not part of Intel's views or affairs Michael S. Tsirkin Four things are to be strengthened: Torah,and good deeds, prayer and one's good manners (Berachoth)
Re: GTK/Gnome frontend and string class
Marko Vendelin [EMAIL PROTECTED] writes: | 4. Find better implementation of STL for Linux and use its string |class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ |is not good enough to compile LyX). Could anybody please explain once more in simple words what kind of strings LyX needs, in how many places such "good" strings are used and in how many places they are absolutely necessary (i.e. can't be replaced by some workaround that works even with "bad" strings). Thank you. Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: InsetGraphics
On 07-Jul-2000 Baruch Even wrote: > On Fri, 7 Jul 2000, Juergen Vigna wrote: > > Is there any reason why to do that instead of just a simple: > \begin_inset Graphics > filename /tmp/platypus.png > rotate 0 > display monochrome > ... > \end_inset > Seems good for me! > This way seems to me to be easier to parse, though I admit that I still > haven't looked on your inset's Read/Write methods. > It is not that hard and I have methods in tabular.C which I would like to put in the support directory which make reading it easier! > Is there an intention to move LyX to XML format? Well we had some discussions about that, but IMO it's not really important (maybe others have other opinions ;), I just had to change the tabular-format as a lot of people complaint about that, especitally people writing converters so I thougth I make it easier for them #:O) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Eternal nothingness is fine if you happen to be dressed for it. -- Woody Allen
RE: More Inset question (InsetGraphics)
On 07-Jul-2000 Baruch Even wrote: > After some more work on the inset I've got even more questions. > > 1. Marking the buffer dirty. After my inset gets changed by the dialog, > how should I go about notifying lyx that the data has changed? I know of > the markxxxDirty, but how do I get access to them? basically it amounts to > "how do I get a pointer to buffer from a function that isnt called by > buffer?" Why buffer you need a "BufferView *" and you have to call in any case bview->updateInset(inset, mark_dirty) (at least if you want to implement the visual feedback sometime in the future :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Sattinger's Law: It works better if you plug it in.
Re: New CVS Solaris configure patch breaks compilation
> "Kayvan" == Kayvan Sylvan <[EMAIL PROTECTED]> writes: Kayvan> Content-Type: text/plain; charset=us-ascii Hi everyone, Kayvan> Te latest configure.in patch breaks configure/compilation on Kayvan> my Solaris box: Kayvan> The problem is probably related to the fact that I use the Kayvan> extra include and extra lib directory flags in addition to Kayvan> putting the fragment ``-isystem /usr/openwin/include'' in my Kayvan> CXXFLAGS and CFLAGS. Could you show me what the config.log file says about xpm.h?
bug report
Reading an old lyx file with current CVS, I notice that protected blanks are converted to SpecialChar \- rather than SpecialChar ~ Angus
Re: Problems compiling lyx 1.1.5pre3
Pablo De Napoli <[EMAIL PROTECTED]> writes: | Hi! | | I could not lyx-1.1.5pre3 from the sources. Something is wrong with the | regex stuff. I'm using linux (debian distribution) | | g++ 2.95.2-13 | libc 2.1.2-11 | libstdc++2.10 2.95.2-13 | | I think the problem could be caused by the changes in the C library (that | now supports the posix regular expresions) | Plese, help me. Thank you This looks more like a configure problem. Do you have the functions that the linker complains about in the libc library? What does the configure log say about regex support? Lgb
RE: small patch 2
On 10-Jul-2000 Angus Leeming wrote: > I reported this DEC cxx warning a few days ago. It seems that the consensus was > that Inset::deleteLyXText should be a const function, but the code hasn't been > updated. If it makes life easier, here is the patch. Could someone > apply it, please. > Thanks I did it by hand! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ An expert is one who knows more and more about less and less until he knows absolutely everything about nothing.
Hi again, and still CVS problems
At long last I think I'm back. I unsubscribed last christmas, and never got around to subscribing again (but I've still been advocating and defending wherever it came up :) I'm now on the Penn State Dubois faculty, and getting my machine running. Hopefully I can draft a student or two to turn my old mailmerge patch into a library and finally integrate it. Anyway, in the meantime, cvs doesn't like me (an ongoing occurrence). I'm running FreeBSD 4.0, and I *think* I'm following the instructions. hawkinsttyp1:hawk>setenv CVSROOT "pserver:[EMAIL PROTECTED]:/usr/local/lyx/cvsroot" hawkinsttyp1:hawk>echo $CVSROOT pserver:[EMAIL PROTECTED]:/usr/local/lyx/cvsroot hawkinsttyp1:hawk>cd /usr/src/ hawkinsttyp1:src>cvs login cvs login: can only use pserver method with `login' command cvs [login aborted]: CVSROOT: pserver:[EMAIL PROTECTED]:/usr/local/lyx/cvsroot h I get this whether I run as a user (with appropriate permissions from the wheel group) or root. rick
Re: bug report
JMarc> Angus> Reading an old lyx file with current CVS, I notice that JMarc> Angus> protected blanks are converted to SpecialChar \- rather than JMarc> Angus> SpecialChar ~ JMarc> I do not see that with a file created with LyX 1.0.3 (read correctly JMarc> with both cvs and 1.1.5fix). Do you have an example file? No, of course not! (:-) I had an old file (not too old; I've only been using lyx for 6 months!) that had a few things such as Appendix-1 when I opened the file today. They should have been Appendix_1. (Was a blue bash, should have been the protected space.) Of course, I only noticed this after I'd been editing the file for a while and saved things a few times, so my original is no more and I've no idea what the original lyx file contained (ie what lyx code. It was written originally to be a protected space.) Presumably, therefore, this is now a useless bug report. It may crop up again in more useful guise. Angus
Re: bug report
Angus Leeming wrote: > > JMarc> Angus> Reading an old lyx file with current CVS, I notice that > JMarc> Angus> protected blanks are converted to SpecialChar \- rather than > JMarc> Angus> SpecialChar ~ > > JMarc> I do not see that with a file created with LyX 1.0.3 (read correctly > JMarc> with both cvs and 1.1.5fix). Do you have an example file? > > No, of course not! (:-) I had an old file (not too old; I've only been using > lyx for 6 months!) that had a few things such as Appendix-1 when I opened the > file today. They should have been Appendix_1. (Was a blue bash, should have > been the protected space.) Of course, I only noticed this after I'd been > editing the file for a while and saved things a few times, so my original is no > more and I've no idea what the original lyx file contained (ie what lyx code. > It was written originally to be a protected space.) > > Presumably, therefore, this is now a useless bug report. It may crop up again > in more useful guise. Hi, maybe it was a file, with the "temporary" protected blank? Don't remember the exact intermediate value (\SpecialChar \protected_separator?). Regards, Stephan --- <[EMAIL PROTECTED]> | beusen unternehmensgruppe senkel fon: +49 30 549932-62 | Landsberger Allee 392 fax: +49 30 549932-29 | 12681 Berlin, Germany ---
GTK/Gnome frontend and string class
I've tried to add some elementary support of GTK/Gnome frontend to LyX. The composed code and collection of configure .m4 scripts brings the GTK frontend to the same level as KDE one --- showing the copyright dialog box. In the code I used GTK-- and GNOME-- libraries (C++ wrappers of GTK and Gnome libraries). GTK-- and GNOME-- rely on STL string class which is not good enough for LyX on my platform (i386, redhat linux 6.0, egcs-1.1.2 or gcc-2.95.2). This is a problem since in LyX string class is typedefed to lyxstring and the resulting code does not link properly with GTK-- and GNOME-- libraries. The following solutions to this conflict between GNOME/Gtk and LyX popped into my mind: 1. Use GTK/Gnome libraries directly (in C) without C++ wrappers 2. Make LyX compatible with the string class included in libstdc++ by fixing files src/support/lstrings.C (lines 184 and 201, string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string interaction). 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this libraries with lyxstring. 4. Find better implementation of STL for Linux and use its string class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ is not good enough to compile LyX). Which of these (or any alternative) solutions should be used for LyX GTK/Gnome frontend? Regards, Marko
Re: GTK/Gnome frontend and string class
Marko Vendelin <[EMAIL PROTECTED]> writes: | 2. Make LyX compatible with the string class included in libstdc++ by |fixing files src/support/lstrings.C (lines 184 and 201, |string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string |interaction). You mean unfixing I hope. The lyxstring tries to be close to API compatible with std::string. | 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this |libraries with lyxstring. Isn't Gtk-- and Gnome--- a bit large for that? | 4. Find better implementation of STL for Linux and use its string |class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ |is not good enough to compile LyX). the libstdc++ is far from standard C++. The libstdc++-v3 is getting there, but there are a bit too many bugs in cvs gcc currently. | Which of these (or any alternative) solutions should be used for LyX | GTK/Gnome frontend? None of the suggestions seems really good. Can we have an interim solution where we use char* to communicate between lyx-core and the gtk frontend? When Gcc 2.96 is released it will hopefully be with the new libstdc++-v3 library, and then there will be no problems. Lgb
Re: Patch: better multi-lingual support
(I still have some difficulty sending mails.) "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> wrote: > Could you factor out this part of the patch? > Then we can look at it, and if it looks good, apply it to cvs. I will try. But please wait! > So the font selection is based on the global LC_CTYPE? > > Hmm, that seems a bit restrictive. Is it not possible to specifically > ask for the font norms for a given locale without setting LC_CTYPE? Only if you are ready to use a semi-internal Xlib function _XOpenLC(). There are no public interfaces in Xlib to access its powerful Input/Output methods machinery without setting locale. If it is allowed to use _XOpenLC(), then an X client can manage multiple locales IM/OM at the same time. > That would probably be the best solution, since we would like to > support writing Japanese on a system where the LC_CTYPE might be > set up for Danish. > > If we assume that it is possible to specify our own LC_CTYPE without > really doing it (you know what I mean), how would this fit in with > Dekel's approach? Dekel, can the two approaches be integrated in > some way? Well, I'm not against to have a unicode based multilingual document support. I would just like to have a mode for single language documents in local encodings, just as single byte language users have at present. [EMAIL PROTECTED] (Lars Gullik Bj nes) wrote: > Regardless of how it ends up: we don't want multi-byte charates as the > internal representation. We also want to support multiple languages on > the same time, afaik unicode is the road to accomplish this. I perfectly understand we do not want to use variable length multibyte characters as the internal representation. But any multibyte encodings have their fixed width wide charcater representation counterpart. So for a single language document, unicode *encoding* might not be obligatory. Regards, SMiyata
fdfix.sh patch
I've patched fdfix.sh and associated makefile to allow me to make forward
declarations such as
struct FD_form_citation;
class FormCitation : public DialogBase {
FD_form_citation * dialog_;
}
rather than have to include the header file. (If I so wish. Both options are now
available.)
Can somebody (Jürgen?) please check that they're happy with the changes.
Many thanks,
Angus
patch11July2000.gz
Literate Patch against latest CVS
Hi folks, Here is Bernard Michael Hurley's literate patch against the latest CVS. This includes my lib/build-listerror script, re-written to work on a generic /bin/sh, instead of requiring bash. Please apply to CVS. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory lit-prog.patch.gz build-listerrors.tgz
RE: More Inset question (InsetGraphics)
On Tue, 11 Jul 2000, Juergen Vigna wrote: > > 1. Marking the buffer dirty. After my inset gets changed by the dialog, > > how should I go about notifying lyx that the data has changed? I know of > > the markxxxDirty, but how do I get access to them? basically it amounts to > > "how do I get a pointer to buffer from a function that isnt called by > > buffer?" > > Why buffer you need a "BufferView *" and you have to call in any case Ok. Then I'll take a BufferView * instead :-) I now looked at the code and saw that indeed I need a BufferView. > bview->updateInset(inset, mark_dirty) > (at least if you want to implement the visual feedback sometime in the > future :) Ok. one more tidbit that I'll add to my todo stuff. But the question remains unanswered, How do I get this bview pointer out of the blue? Should I save the BufferView* I get from last time and use that? It seems ugly to me, is there no other way to get this pointer? -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: GTK/Gnome frontend and string class
On 11 Jul 2000, Lars Gullik Bjønnes wrote: > Marko Vendelin <[EMAIL PROTECTED]> writes: > > | 4. Find better implementation of STL for Linux and use its string > |class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ > |is not good enough to compile LyX). > > the libstdc++ is far from standard C++. The libstdc++-v3 is getting > there, but there are a bit too many bugs in cvs gcc currently. How does the SGI-STL/STLport fare in relation with the standard? It might be possible to use them, and compile externally the GTK--/Gnome-- with them and then compile LyX with them too, this should solve it, although it will require quite a bit of work from anyone who wishes to use the GTK version of LyX. (I've tried to use the STLport but couldn't get LyX to find it, though I must admit I tried for a very short time and settled for lyxstring). -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
Re: Patch: better multi-lingual support
Dekel Tsur <[EMAIL PROTECTED]> wrote:
> We need to change the internal text storage from 8-bit to 16/32-bit,
> before we can use such a patch.
Yes, I realize this (and called it 2. in the previous message.)
> We also want to be able to render simultaneously Japanese, Hebrew, Russia
> etc. Is it supported by Xlib? (i.e. does the XCreateOC call also load
> iso8859-n font if they are available?)
OK here is the official way to use multiple fontsets:
/// after calling XSetLocaleModifiers() etc.
string real_locale = "LC_CTYPE=" + getenv(LC_CTYPE);
putenv("LC_CTYPE=ja_JP");
XOM om_ja = XOpenOM(dpy, 0, 0, 0);
putenv("LC_CTYPE=he_IL");
XOM om_he = XOpenOM(dpy, 0, 0, 0);
putenv(real_locale.c_str());
/// Now this creates a XFontSet consists of
/// ISO8859-1, JISX0208.1983-0, JISX0201.1976-0 and possibly
/// JISX0212.1990-0
XOC oc_ja = XCreateOC(om_ja,
XNBaseFontName, "-*-*-*-*-*-*-12-*", NULL);
/// And this one creates a XFontSet consists of
/// ISO8859-8 (for ch <= 0x7f), and ISO8859-8 (for ch >= 0x80)
XOC oc_he = XCreateOC(om_he,
XNBaseFontName, "-*-*-*-*-*-*-12-*", NULL);
/// You can draw some texts
XmbDrawString(dpy, win, oc_, gc, x1, y1,
ja_text.c_str(), ja_text.length());
XmbDrawString(dpy, win, oc_, gc, x2, y2,
he_text.c_str(), he_text.length());
If _XOpenLC() is used, you don't have to change the environment variable:
XLCd lcd_ja = _XOpenLC("ja_JP");
XOM om_ja = lcd_ja->methods->open_om(dpy, 0, 0, 0);
XLCd lcd_he = _XOpenLC("he_IL");
XOM om_he = lcd_he->methods->open_om(dpy, 0, 0, 0);
/// etc. etc.
In case you want to create a custom XFontSet, please refer to
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg07891.html
Regards,
SMiyata
Re: GTK/Gnome frontend and string class
Hello, Marko! Another solution: 1. Take the GTK--/GNOME-- headers, and use macro to change "string" to basic_string for them: #define string basic_string #include #undef string You can also create wrappers for all headers that you use to add this macro automatically. 2. Add operator std::basic_string() const and lyxstring(const std::basic_string&) const to lyxstring to make it possible to convert between GTK and lyx strings on the fly. This has an advantage that you can use GTK installed on the system, without recompilation or changing the headers. Quoting r. Marko Vendelin ([EMAIL PROTECTED]) "GTK/Gnome frontend and string class": > > I've tried to add some elementary support of GTK/Gnome frontend to LyX. > The composed code and collection of configure .m4 scripts brings the GTK > frontend to the same level as KDE one --- showing the copyright dialog > box. In the code I used GTK-- and GNOME-- libraries (C++ wrappers of GTK > and Gnome libraries). > > GTK-- and GNOME-- rely on STL string class which is not good enough for > LyX on my platform (i386, redhat linux 6.0, egcs-1.1.2 or gcc-2.95.2). > This is a problem since in LyX string class is typedefed to lyxstring and > the resulting code does not link properly with GTK-- and GNOME-- > libraries. The following solutions to this conflict between GNOME/Gtk and > LyX popped into my mind: > > 1. Use GTK/Gnome libraries directly (in C) without C++ wrappers > > 2. Make LyX compatible with the string class included in libstdc++ by >fixing files src/support/lstrings.C (lines 184 and 201, >string::compare) and src/lyx_cb.C (line 1109, algorithm copy and string >interaction). > > 3. Include GTK-- and Gnome-- into LyX (as sig++) and compile this >libraries with lyxstring. > > 4. Find better implementation of STL for Linux and use its string >class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ >is not good enough to compile LyX). > > Which of these (or any alternative) solutions should be used for LyX > GTK/Gnome frontend? > > Regards, > > Marko -- This message content is not part of Intel's views or affairs Michael S. Tsirkin > Four things are to be strengthened: Torah,and good deeds, > prayer and one's good manners (Berachoth)
Re: GTK/Gnome frontend and string class
> > Marko Vendelin <[EMAIL PROTECTED]> writes: > > > > | 4. Find better implementation of STL for Linux and use its string > > |class with LyX and GTK--/Gnome-- (current CVS version of gcc/libstdc++ > > |is not good enough to compile LyX). Could anybody please explain once more in simple words what kind of strings LyX needs, in how many places such "good" strings are used and in how many places they are absolutely necessary (i.e. can't be replaced by some workaround that works even with "bad" strings). Thank you. Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
