bar | doesn't work in Qt
In the Qt version, when I hit | (the pipe or the vertical bar obtained by hitting Shift and \) I see unknown function at the bottom.. and of course, the bar isn't displayed.. same thing happens in math mode also.. Thanks, nirmal
Re: Indenting left justified paragraphs
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Dekel Tsur [EMAIL PROTECTED] writes:
Lars | On Wed, Nov 27, 2002 at 04:16:16PM +0100, Jean-Marc Lasgouttes wrote:
Lars |
Lars | Probably not. I guess it is a consequence of our changing
Lars from | \centering to center environments and friends.
Lars |
Lars | \begin{center} is bad as it adds space. | We need to change it
Lars to something else.
Lars Then tell us a better _LaTeX_ way.
The reason why we changed from {\centering ... \par} to center
environment was to have better logical marking (for example, reLyX has
problems with that). It is possible too to use
\begin{centering}...\end{centering}, although this means that we need
an extra par.
See the attached file for examples of different constructs. Note that
\begin{centering}
blah
\end{centering}
does _not_ work.
JMarc
essai.tex
Description: TeX document
Re: Indenting left justified paragraphs
Duncan == Duncan Simpson [EMAIL PROTECTED] writes:
Duncan I think the solution to this LaTeX problem is to move into
Duncan plain TeX and use the machinery more directly. Having said
Duncan that I think this is a good solution for lots problems that
Duncan are difficult to solve in pure LaTeX.
No, we have a reasonable latex solution which is ``{centering blah\par}'',
what we want is a solution that is also good structured markup. Plain
TeX is not going to help us here...
JMarc
Re: compiling problems...
Christian == Christian Ridderström [EMAIL PROTECTED] writes:
Christian Hi I've finally decided to try and compile the cvs
Christian version... and after struggling with xforms I seem to have
Christian gotten past that but get this strange error message when
Christian running:
Christian Waiting for cpp_regex_traits.o.lock to be removed
I have the same problem on tru64 unix, unless I configure with
--disable-libtool-lock.
Actually, I looked at it a little and think this is a stupid bug in
libtool.m4. This happens because libtool.m4 thinks that the compiler
cannot handle -c and -o simultaneously. Why? Because it tries to
compile
int main(){
int some_variable = 0;
}
and thinks there is a problem when a warning is issued. Here the
warning is of course that the variable is not used.
Then it tries to do some tricky locking that does not work and
everything goes down the drain.
Note that NEWS for libtool 1.4.3 says:
* srcdir != builddir builds with Automake 1.5 work correctly.
So maybe an upgrade will help.
JMarc
Re: bar | doesn't work in Qt
Nirmal == Nirmal Govind [EMAIL PROTECTED] writes: Nirmal In the Qt version, when I hit | (the pipe or the vertical Nirmal bar obtained by hitting Shift and \) I see unknown Nirmal function at the bottom.. and of course, the bar isn't Nirmal displayed.. same thing happens in math mode also.. I have a patch for that (and other forgotten keys). I'll apply it asap. JMarc
Re: compiling problems...
On 4 Dec 2002, Jean-Marc Lasgouttes wrote: Christian == Christian Ridderström [EMAIL PROTECTED] writes: Christian Hi I've finally decided to try and compile the cvs Christian version... and after struggling with xforms I seem to have Christian gotten past that but get this strange error message when Christian running: Christian Waiting for cpp_regex_traits.o.lock to be removed I have the same problem on tru64 unix, unless I configure with --disable-libtool-lock. Thanks, the '--disable-libtool-lock' fixed it ... (at least it is compiling now :-) /C -- Christian Ridderström, +46-8-790 91 37 http://www.md.kth.se/~chr Mechatronics lab, Dept. of Machine Designhttp://www.md.kth.se
Re: bar | doesn't work in Qt
I have a patch for that (and other forgotten keys). I'll apply it asap. JMarc Great! Thanks a lot.. nirmal
Preference on GUI frontend
Hello again, last time I asked you whether you recommend any of the available frontends, you said no. However, when you compile LyX, xforms is chosen as default frontend. Will you keep this setting or switch to Qt before the final release? I guess that you don't want to recommend any of the frontends because that conflicts with the idea of the GUI independence layer. However, you must be prepared for users that ask for advice. I am sure they will do so! (Like myself) Michael -- === Michael Schmitt Telefon: +49 651 97551-40 Institut für TelematikTelefax: +49 651 97551-12 Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de D-54292 Trier E-Mail: mailto:[EMAIL PROTECTED] ===
Re: Indenting left justified paragraphs
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
|
| Lars Dekel Tsur [EMAIL PROTECTED] writes:
| Lars | On Wed, Nov 27, 2002 at 04:16:16PM +0100, Jean-Marc Lasgouttes wrote:
| Lars |
| Lars | Probably not. I guess it is a consequence of our changing
| Lars from | \centering to center environments and friends.
| Lars |
| Lars | \begin{center} is bad as it adds space. | We need to change it
| Lars to something else.
|
| Lars Then tell us a better _LaTeX_ way.
|
| The reason why we changed from {\centering ... \par} to center
| environment was to have better logical marking (for example, reLyX has
| problems with that). It is possible too to use
| \begin{centering}...\end{centering}, although this means that we need
| an extra par.
|
| See the attached file for examples of different constructs. Note that
| \begin{centering}
| blah
| \end{centering}
| does _not_ work.
Yes, I have been reading a lot in my books lately, and it seems that
it was a big misguided to switch away from the statement variants.
My fault probably.
The center environment is only suited when you want to center small
parts _within_ a paragraph. (the trivlist in the implementation is
really mucking things up.)
--
Lgb
Re: [PATCH] Change tracking for 1.3cvs
Allan Rae [EMAIL PROTECTED] writes: | On Wed, 4 Dec 2002, John Levon wrote: | | [...] | With all that administration, I'm even less inclined to do so then. | | CVS is worse at handling conflicts in such cases than patch is | | But at least CVS allows others to keep up to date with your work and | fiddle along with you. All you need to do is warn everyone when | you're rolling forward to a new branch -- if you find a suitable name | like BRANCH_CHANGE_TRACKER_x where x is a counter (1,2,3..) for the | current branch it shouldn't be hard for people to work out the latest | branch. I cannot believe that merging is that hard. The Gcc folks do this all the time, and that project is a tiny bit larger than LyX... -- Lgb
trouble with labels/cross-referencing
Hi.. I ran into trouble while cross-referencing sections which had the same names and hence same label names but belonged to different documents. Say I have two docs, and there's a section with exactly the same name in each of these docs. If I insert labels in each of these docs, they both have the same name by default. Now, if I include both these docs in another doc, things get confusing when I try to cross reference one of these sections in the main doc since there'll be two labels with the same name.. would it be possible to include some kind of an identifier in the label name (by default) which might make the label unique somehow? One of the reasons for the problem is that the cross reference dialog in the main doc will show ALL the labels together no matter which doc I select from the drop-down menu (this is something I'd reported in an earlier mail)... if this behavior is changed, it'll become easier to find the right label.. Thanks, nirmal
Re: gcc 3.2 internal compiler error
Michael Schmitt [EMAIL PROTECTED] writes: | Hi, | | are there any plans to provide a workaround for the following problem: no | g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost | -isystem /usr/X11R6/include -g -O -fno-exceptions -W -Wall -Winline -c | cregex.cpp -MT cregex.lo -MD -MP -MF .deps/cregex.TPlo | -- | PrepareDocumentForEditing | ../../../../boost/boost/regex/detail/regex_match.hpp: In member function |`unsigned int boost::RegEx::GrepFiles(bool (*)(const char*, const |boost::RegEx), const char*, bool, unsigned int)': | ../../../../boost/boost/regex/detail/regex_match.hpp:1902: Internal compiler |error in expand_call, at calls.c:3049 | Please submit a full bug report, | | Of course, it's not your fault. OTOH, gcc 3.2 is part of most current | Linux distributions, so you might be flooded by bug reports if | compilation of LyX 1.3.0 fails. Most distributions have added some vendor patches that fix this problem. So IMHO it is a vendor problem. RH f.ex. does not have this problem. (and suse do have it) -- Lgb
Size of inset labels
Hi, in the QT frontend, the note inset label is much larger than the footnote inset label. Moreover, menu item New is not translated into German (also revert, spellchecker, preferences, Index Entry, ...). Michael -- === Michael Schmitt Telefon: +49 651 97551-40 Institut für TelematikTelefax: +49 651 97551-12 Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de D-54292 Trier E-Mail: mailto:[EMAIL PROTECTED] ===
A note about compiling LyX
Considering the snags I've run into trying to compile LyX, I decided to add some notes to this wiki-page: http://ev-en.org/wiki/moin.cgi/LyXCompile /Christian -- Christian Ridderström, +46-8-790 91 37 http://www.md.kth.se/~chr Mechatronics lab, Dept. of Machine Designhttp://www.md.kth.se
Re: Preference on GUI frontend
Michael Schmitt [EMAIL PROTECTED] writes: | Hello again, | | last time I asked you whether you recommend any of the available | frontends, you said no. However, when you compile LyX, xforms is | chosen as default frontend. Will you keep this setting or switch to Qt | before the final release? | | I guess that you don't want to recommend any of the frontends because | that conflicts with the idea of the GUI independence layer. However, | you must be prepared for users that ask for advice. I am sure they | will do so! (Like myself) The default will stay on xforms for 1.3.0 as well, what happens after that I do not know yet. -- Lgb
Re: Size of inset labels
Michael Schmitt [EMAIL PROTECTED] writes: | Moreover, menu item New is not translated into German (also | revert, spellchecker, preferences, Index Entry, ...). Yes... we could certainly use some help with the translation effort. -- Lgb
Re: Size of inset labels
Lars Gullik Bjønnes wrote: Michael Schmitt [EMAIL PROTECTED] writes: | Moreover, menu item New is not translated into German (also | revert, spellchecker, preferences, Index Entry, ...). Yes... we could certainly use some help with the translation effort. I may be wrong but IIRC the xforms translates most texts correctly. Michael -- === Michael Schmitt Telefon: +49 651 97551-40 Institut für TelematikTelefax: +49 651 97551-12 Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de D-54292 Trier E-Mail: mailto:[EMAIL PROTECTED] ===
Re: Size of inset labels
Michael == Michael Schmitt [EMAIL PROTECTED] writes: Michael Lars Gullik Bjønnes wrote: Michael Schmitt [EMAIL PROTECTED] writes: | Moreover, menu item New is not translated into German (also | revert, spellchecker, preferences, Index Entry, ...). Yes... we could certainly use some help with the translation effort. Michael I may be wrong but IIRC the xforms translates most texts Michael correctly. Could you double check? This is very surprising... JMarc
Re: [PATCH] Change tracking for 1.3cvs
On 4 Dec 2002, Lars Gullik Bjønnes wrote: Allan Rae [EMAIL PROTECTED] writes: | On Wed, 4 Dec 2002, John Levon wrote: | | [...] | With all that administration, I'm even less inclined to do so then. | | CVS is worse at handling conflicts in such cases than patch is | | But at least CVS allows others to keep up to date with your work and | fiddle along with you. All you need to do is warn everyone when | you're rolling forward to a new branch -- if you find a suitable name | like BRANCH_CHANGE_TRACKER_x where x is a counter (1,2,3..) for the | current branch it shouldn't be hard for people to work out the latest | branch. I cannot believe that merging is that hard. The Gcc folks do this all the time, and that project is a tiny bit larger than LyX... GDB is a fairly large project also and they tend to start a new branch and roll their work forward that way rather than attempt to keep one branch going for long periods with multiple merges of the trunk into branch. Does GCC really have long living branches with multiple merges from the trunk into the branch? If so, they must know something a lot of others don't. It is supposed to be possible but if you read the blurb for that recently posted cvs replacement one of the things they claim is that they can do this but cvs can't. Allan. (ARRae)
Re: [PATCH] Change tracking for 1.3cvs
Allan Rae [EMAIL PROTECTED] writes: | Does GCC really have long living branches with multiple merges from | the trunk into the branch? yes. | If so, they must know something a lot of others don't. perhaps. The crucial things is to tag HAED and branch, so that you have something to merge against next time around. | It is supposed to be possible but if you read the blurb for that | recently posted cvs replacement one of the things they claim is that | they can do this but cvs can't. or they do it in an easier way... -- Lgb
Re: Indenting left justified paragraphs
On Wed, Dec 04, 2002 at 09:23:22AM +0100, Jean-Marc Lasgouttes wrote:
Duncan == Duncan Simpson [EMAIL PROTECTED] writes:
Duncan I think the solution to this LaTeX problem is to move into
Duncan plain TeX and use the machinery more directly. Having said
Duncan that I think this is a good solution for lots problems that
Duncan are difficult to solve in pure LaTeX.
No, we have a reasonable latex solution which is ``{centering blah\par}'',
what we want is a solution that is also good structured markup. Plain
TeX is not going to help us here...
As I written before, define \newenvironment{lyxcenter}{\centering}{\par},
and then \begin{lyxcenter}blah\end{lyxcenter} is equivalent to
{\centering blah\par}.
Re: insetinclude thoroughly borked
On Tue, Dec 03, 2002 at 05:38:32AM +, John Levon wrote: First off, xforms has the same bug qt had : if you change to include from input, then open the dialog, the radio is set to input. Second, the options doesn't actually do anything to the latex output: the command name is never reset ! Shows how often it's used... These are both my doing. Seems I was drinking too much of that dangerous toxin dihydrogen monoxide john -- Trolls like content too. - Bob Abooey, /.
Re: insetinclude thoroughly borked
On Wed, Dec 04, 2002 at 11:51:29AM +, John Levon wrote: These are both my doing. Seems I was drinking too much of that dangerous toxin dihydrogen monoxide Looks like you should consult www.dhmo.org immediately... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Redraw problems when resizing main window
Attached is a screenshot of the typical LyX screen after it's resized using
the mouse.
I suspect that we get these problems because we aren't using the xforms event
loop properly. (The gurus keep muttering about this occasionally I think, but
I've never got to the bottom of what was wrong until now).
As I understand it, the event loop works so:
do
do
* watch for XEvents for SHORT_PAUSE ms
(hardcoded as 10ms).
* handle these XEvents, putting the affected FL_OBJECT
on a stack for more expensive processing.
while (XEvents to process)
* process the FL_OBJECTs on this stack by calling
obj-object_callback and popping off the stack.
done
obj-handle is meant to provide cheap, initial processing.
obj-object_callback can be more expensive.
I think that we bugger things up in the XWorkArea by having a handle that
does everything. Ie, it handles the event and then calls the LyX core to
finish processing it with calls like
dispatch(FuncRequest(LFUN_MOUSE_PRESS,
ev-xbutton.x - ob-x,
ev-xbutton.y - ob-y,
x_button_state(key)));
It strikes me that all we need to do is put these FuncRequests onto a stack
in the handler and then pop-them off and dispatch them in the subsequent
callback routine.
I think that adding a FuncStack member variable, below, to XWorkArea would do
the trick. Have I got the right end of this stick? If not would someone
knowledgable provide me with illumination!
Regards,
Angus
class FuncStack {
public:
FuncStack(XworkArea parent) : parent_(parent) {}
push_back(FuncRequest const request) { store.push_back(request); }
process() {
Store::iterator it = store.begin();
Store::iterator end = store.end();
for (; it != end; ++it) {
parent_.dispatch(*it);
}
store.clear();
}
private:
XworkArea parent_;
typedef listFuncRequest Store;
Store store;
};
attachment: screenshot.png
Re: gcc 3.2 internal compiler error
On Wed, Dec 04, 2002 at 10:09:11AM +0100, Lars Gullik Bjønnes wrote: Most distributions have added some vendor patches that fix this problem. So IMHO it is a vendor problem. RH f.ex. does not have this problem. (and suse do have it) it's a buggy suse patch. clean 3.2 tarball is fine. I've asked people to report bug to suse to but nobody has said they've done so regards john -- Trolls like content too. - Bob Abooey, /.
Re: Size of inset labels
John == John Levon [EMAIL PROTECTED] writes: John On Wed, Dec 04, 2002 at 09:59:42AM +0100, Michael Schmitt wrote: in the QT frontend, the note inset label is much larger than the footnote inset label. John well, a little larger, for me. seems to be a different font John size. how odd Compare InsetNote::init() with InsetFootLike::InsetFootLike. I commited a fix. JMarc
Re: Current xforms bugs
Two more things: - If you switch from one submenu to another one (try InsertList = InsertMath), the window background is not repainted (xforms or lyx bug?) - You cannot switch between two menus without closing the first menu first (IMO one annoying mouse click too much) Regards, Michael -- === Michael Schmitt Telefon: +49 651 97551-40 Institut für TelematikTelefax: +49 651 97551-12 Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de D-54292 Trier E-Mail: mailto:[EMAIL PROTECTED] ===
Re: Current xforms bugs
On Wednesday 04 December 2002 1:22 pm, Michael Schmitt wrote: Two more things: - If you switch from one submenu to another one (try InsertList = InsertMath), the window background is not repainted (xforms or lyx bug?) All is fine for me. Anyone else? Michael, what version of the xforms library are you using? - You cannot switch between two menus without closing the first menu first (IMO one annoying mouse click too much) I'll add this to my list. Angus
Qt GUI: math symbols and math pannel problems
Hi all, I got the latest CVS LyX 1.3.0 sources (Dec. 4th) and compiled it with qt gui support (Qt 3.0.5, gcc 3.2, RedHat 8). When running LyX, I noted two main problems: 1- The math symbols, including greek letters, are not correct when shown in the qt frontend. It seems that the symbol font map is wrongly set or the wrong symbol font is beeing used. For example, \alpha is shown as the copyright symbol (a smal R inside a circle) on the screen. 2- The math pannel is not working. When a symbol is clicked, nothing happens. But the functions and the buttons over them (roots, fraction, etc) do work. The console shows the following error message: QObject::connect: No such signal IconPalette::button_clicked(string const) QObject::connect: (sender name: 'unnamed') QObject::connect: (receiver name: 'QMathDialogBase') I hope this report helps improoving LyX. Persio
Re: Current xforms bugs
On Wed, Dec 04, 2002 at 01:46:10PM +, Angus Leeming wrote: - If you switch from one submenu to another one (try InsertList = InsertMath), the window background is not repainted (xforms or lyx bug?) All is fine for me. Anyone else? Michael, what version of the xforms library are you using? No, I see the same. But it has been like that for several months now. xforms 0.89.6. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Current xforms bugs
On Wednesday 04 December 2002 1:40 pm, Andre Poenitz wrote: On Wed, Dec 04, 2002 at 01:46:10PM +, Angus Leeming wrote: - If you switch from one submenu to another one (try InsertList = InsertMath), the window background is not repainted (xforms or lyx bug?) All is fine for me. Anyone else? Michael, what version of the xforms library are you using? No, I see the same. But it has been like that for several months now. xforms 0.89.6. xforms 1.0 final is due out on Friday... Angus
Re: Current xforms bugs
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus o the xforms image loader should fail gracefully if it fails to Angus load a weird xpm file. BTW, angus, why don't we use the native pnm handler with xforms image loader? We could disable xpm support in flimage and give image-pnm converters. It seems that ppm files are larger than xpm ones (+60%), but is this such a big problem? The gains would be faster conversion, and maybe a more robust parser in xforms part. Another xforms bug to add to the list: the problem with clicking on Edit menu when File is open. I reported it in this thread http://bob.usuf2.usuhs.mil/mailserv/list-archives/xforms-archive.2000/0529.html and the reason for the problem is analyzed here: http://bob.usuf2.usuhs.mil/mailserv/list-archives/xforms-archive.2000/0643.html However, I guess the offending code is here for some reason, so I did not try to remove it (which would be the easiest solution). JMarc
Re: Current xforms bugs
On Wed, Dec 04, 2002 at 01:52:57PM +, Angus Leeming wrote: xforms 0.89.6. xforms 1.0 final is due out on Friday... Which year? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Current xforms bugs
On Wednesday 04 December 2002 1:47 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus o the xforms image loader should fail gracefully if it fails to Angus load a weird xpm file. BTW, angus, why don't we use the native pnm handler with xforms image loader? We could disable xpm support in flimage and give image-pnm converters. It seems that ppm files are larger than xpm ones (+60%), but is this such a big problem? The gains would be faster conversion, and maybe a more robust parser in xforms part. The only reason I haven't disabled the xpm loader already is, believe it or not, the splash screen and the fact that we currently support xforms versions with and without flimage. If we disable xpm loading and leave the splash screen as an xpm file then most people will start off LyX with a conversion process. Ditto, if we change to a ppm file, then those 0.88 users would start off with a conversion. Assuming that xforms 1.0 /does/ come out on Friday, will we continue to support xforms 1.0 or force people to upgrade? It'd be really nice to remove all that #ifdef mess... Another xforms bug to add to the list: the problem with clicking on Edit menu when File is open. I reported it in this thread http://bob.usuf2.usuhs.mil/mailserv/list-archives/xforms-archive.2000/0529. html and the reason for the problem is analyzed here: http://bob.usuf2.usuhs.mil/mailserv/list-archives/xforms-archive.2000/0643. html However, I guess the offending code is here for some reason, so I did not try to remove it (which would be the easiest solution). Thanks, JMarc, I'll add it to my list. Angus
Re: Qt GUI: math symbols and math pannel problems
On Wed, Dec 04, 2002 at 11:41:23AM -0200, Persio Barros wrote: I got the latest CVS LyX 1.3.0 sources (Dec. 4th) and compiled it with qt gui support (Qt 3.0.5, gcc 3.2, RedHat 8). Dec. 4th ? Are you *sure* ? 1- The math symbols, including greek letters, are not correct when shown in the qt frontend. It seems that the symbol font map is wrongly set or the wrong symbol font is beeing used. For example, \alpha is shown as the copyright symbol (a smal R inside a circle) on the screen. fine for me 2- The math pannel is not working. When a symbol is clicked, nothing happens. But the functions and the buttons over them (roots, fraction, etc) do work. The console shows the following error message: QObject::connect: No such signal IconPalette::button_clicked(string const) QObject::connect: (sender name: 'unnamed') QObject::connect: (receiver name: 'QMathDialogBase') I fixed this days ago, see frontends/qt2/ChangeLog. What is the very top entry ? regards john -- Trolls like content too. - Bob Abooey, /.
Re: Current xforms bugs
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus If we disable xpm loading and leave the splash screen as an xpm Angus file then most people will start off LyX with a conversion Angus process. Ditto, if we change to a ppm file, then those 0.88 Angus users would start off with a conversion. Why didn't you write a ppm loader? ;) Angus Assuming that xforms 1.0 /does/ come out on Friday, will we Angus continue to support xforms 1.0 or force people to upgrade? It would be nice to force the use of xforms 1.0 in 1.3.0. But we should make sure first that people use 1.0 with lyx 1.2.x. But at least, we can remove support for xforms versions older than 0.89.6, which would get rid of most of the ifdefs. Angus Thanks, JMarc, I'll add it to my list. Angus Feel free to fix it too... JMarc
AltGr chrashes qtlyx-1.0.0cvs -dbg key
Hallo, since yesterday (Dec., 3rd), my qtlyx-1.3.0cvs again crashes after entering AltGr, if I start it with the option -dbg 4: Press key 65535 text none, ascii 0 sym empty in getSymbolName() lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help-Introduction and send us a bug report, if necessary. Thanks ! Bye. Aborted Without the debug option it works! Some times ago, the lines // AltGr becomes Key_unknown on at least one keyboard case Qt::Key_unknown: return true; were added in qlkey.h, and all were good for me. I cannot find any significant change in qlkey.h. Moroever, an old version (from Oct., 10th), which I saved because it worked well, chrashes now also with this debug option if I enter AltGr. It is possible that some files in lib are changed which cause to crash the old lyx, too? Norbert
Re: A note about compiling LyX
Christian == Christian Ridderström [EMAIL PROTECTED] writes: Christian Considering the snags I've run into trying to compile LyX, Christian I decided to add some notes to this wiki-page: Christian http://ev-en.org/wiki/moin.cgi/LyXCompile A couple notes on what you wrote there: - to use less disk space, you can configure with --disable-debug - are you sure that --with-extra-prefix=/pkg/mdhacks/grp/util does not work? JMarc
Re: AltGr chrashes qtlyx-1.3.0cvs -dbg key
I corrected the subject. Norbert
Re: AltGr chrashes qtlyx-1.3.0cvs -dbg key
On Wed, Dec 04, 2002 at 03:53:32PM +0100, Norbert Koksch wrote: I corrected the subject. one of our lines starting lyxerr[Debug::KEY] in QLyXKeySym.C is accessing where it shouldn't. A backtrace would tell us where regards john -- Trolls like content too. - Bob Abooey, /.
Re: Qt GUI: math symbols and math pannel problems
Hi, John, From: John Levon [EMAIL PROTECTED] Date: Wed, 4 Dec 2002 14:14:03 + On Wed, Dec 04, 2002 at 11:41:23AM -0200, Persio Barros wrote: I got the latest CVS LyX 1.3.0 sources (Dec. 4th) and compiled it with qt gui support (Qt 3.0.5, gcc 3.2, RedHat 8). Dec. 4th ? Are you *sure* ? Well, I got the sources updated today. 1- The math symbols, including greek letters, are not correct when shown in the qt frontend. It seems that the symbol font map is wrongly set or the wrong symbol font is beeing used. For example, \alpha is shown as the copyright symbol (a smal R inside a circle) on the screen. fine for me May be some kind of system (or Qt?) configuration. But with XForms this doesn't happen. Any idea? 2- The math pannel is not working. When a symbol is clicked, nothing happens. But the functions and the buttons over them (roots, fraction, etc) do work. The console shows the following error message: QObject::connect: No such signal IconPalette::button_clicked(string const) QObject::connect: (sender name: 'unnamed') QObject::connect: (receiver name: 'QMathDialogBase') I fixed this days ago, see frontends/qt2/ChangeLog. What is the very top entry ? Here it is: 2002-11-25 Jean-Marc Lasgouttes [EMAIL PROTECTED] * qlkey.h (string_to_qkey): Add many missing entries 2002-12-04 John Levon [EMAIL PROTECTED] * qt_helpers.h: * qt_helpers.C: * QDocument.h: * QDocument.C: move methods below to helpers 2002-11-03 Juergen Spitzmueller [EMAIL PROTECTED] * QDocument.C: new methods widgetsToLength, lengthToWidgets. set defaultUnit 2002-12-03 John Levon [EMAIL PROTECTED] * QIncludeDialog.C: another fix Hope it helps. Persio _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
[EMAIL PROTECTED] wrote: Log message: fix some missing keys in qt frontend Jean-Marc, are you intending to fix the umlaut/ß-Problem as well? Jürgen.
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen [EMAIL PROTECTED] wrote: Log message: fix some missing keys in qt frontend Juergen Jean-Marc, are you intending to fix the umlaut/ß-Problem as Juergen well? I would not know how to do it... I just did the easy part. JMarc
Re: A note about compiling LyX
On 4 Dec 2002, Jean-Marc Lasgouttes wrote: Christian == Christian Ridderström [EMAIL PROTECTED] writes: Christian Considering the snags I've run into trying to compile LyX, Christian I decided to add some notes to this wiki-page: Christianhttp://ev-en.org/wiki/moin.cgi/LyXCompile A couple notes on what you wrote there: - to use less disk space, you can configure with --disable-debug Yes, guess I should mention that (but I want the debug information). - are you sure that --with-extra-prefix=/pkg/mdhacks/grp/util does not work? Pretty sure... but it was late :-) I can check again, now that I've got everything working. /C -- Christian Ridderström, +46-8-790 91 37 http://www.md.kth.se/~chr Mechatronics lab, Dept. of Machine Designhttp://www.md.kth.se
Towards LyX 1.2.2 [status update #4]
OK, LyX 1.2.2 is getting closer. However, I just commited a patch to remove special epsi support, and I would like to make sure that it still works. Could some people try it out please? Just try your most wicked eps files and tell me what does not work. Other new things include - some updated translations - fix problems with reading \limits in mathed - fix infinite redraw in large tables - updates to sciword bindings (and removal of accent-vector) Lars, the machine on which I can make a distribution is behind a firewall. Do you think you could do a distribution for me? JMarc -*- text -*- This file describes what has been done in the preparation of LyX 1.2.2. All comments are welcome. You can find a list of bugs pending for 1.2.2 at URL http://bugzilla.lyx.org/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=1.2.2 I'd be glad if some of you could take the time to check it out (or fix a bug or two if you are feeling adventurous). Let me recall that all these fixes have been checked in the branch BRANCH-1_2_X, which you can get with the command cvs checkout -d lyx-1_2_x -r BRANCH-1_2_X lyx-devel JMarc What's new == ** Updates - selecting a word by double clicking now sets the X clipboard (like when dragging the mouse) - it is now possible to specify the arguments for viewers; in particular, this means that it is possible to use browsers which require a file: URL as HTML viewers (mozilla is used as default if found) - when a new LyX version is launched, the EditReconfigure tool is automatically invoked; this should avoid many problems with users who are not aware that it is needed - when changing the current layout with the toolbar, the corresponding keyboard binding is shown in the minibuffer - in hebrew language, the key now inserts a typewriter quote (since other quotes do not make sense in hebrew) - InsertLists TOCBibtex Reference uses style 'plain' by default - new class ijmpd; update cl2emult, llncs and foils textclasses - update sciword bindings - small cleanup of UserGuide and FAQ; update to German, French and Russian documentation; new Hebrew tutorial - update french, german, russian, finnish and danish localization of the interface ** Bug fixes - fix bug where special characters in equations label confuse LyX (this was a new bug in 1.2.1) - fix bug with citation keys that contain spaces (this was a new bug in 1.2.1) - remove special handling of EPSI files, because it caused more problems than it fixed (EPSI handling was new in 1.2.1) - fix crash with undo - fix lockup when changing the layout of several paragraphs at the same time (and the layout of the first paragraph is already correct) - fix possible endless repainting when a tabular is larger than the workarea - fix bug with graphics files which name contain a '.' - fix bug in the xforms image loader, where images would be cropped by a few pixels - when a viewer has not been found (set to none), remove the corresponding View menu entry - fix bad latex output with language changes in nested environment - fix bad latex output with math array environment included in an eqnarray environment - fix bug where \limits statements (as obtained in math with M-m l) would not be read back from the lyx file - do not output labels in latex when numbering is off - harmonize the behavior of delete and backspace in main text, insettext, and tabulars, i.e. don't put stuff into the clipboard - add bindings for M- and M- in emacs mode - fix crash when using the koi8-u keyboard mapping - fix handling of word-related cursor movement functions in math editor - fix placement of cursor with mouse in presence of hfills - the reference dialog now lists the labels of the current buffer - fix the thesaurus dialog so that it can be closed with the Escape key - fix problem where citation labels do not appear in 'natbib' style when the user expects them to do so. - fix problems with wrong highlighted entry in citation dialog - fix drawing problem when a line of text contains both left-to-right and right-to-left text - ignore bogus matches of scalable fonts - when loading a font fails, show the name of the said font - make sure that pdf files use 1.3 format - add detection of kdeprintfax for sending faxes - add missing autoconf file xforms.m4 - fix compilation problem (missing wchar.h) on some BSD systems (including Mac OS X) - fix link problems with gcc on and non-GNU linkers
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
On Wed, Dec 04, 2002 at 04:06:25PM +0100, Jean-Marc Lasgouttes wrote:
Juergen Jean-Marc, are you intending to fix the umlaut/ß-Problem as
Juergen well?
I would not know how to do it... I just did the easy part.
I't's easy. in operator== you need something like :
if (r2.key() == Qt::Key_unknown) {
string symb = qtext_to_symb(r2.text());
return r1.text() == symb.c_str();
}
return r1.key() == r2.key();
where qtext_to_symb has :
if (text == Ä) return Adiaresis;
Juergen, if you have trouble trying this, tell me, and I'll commit a
framework patch doing it. I can't test it obviously
regards
john
--
Trolls like content too.
- Bob Abooey, /.
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
John == John Levon [EMAIL PROTECTED] writes:
John I't's easy. in operator== you need something like :
John if (r2.key() == Qt::Key_unknown) { string symb =
John qtext_to_symb(r2.text()); return r1.text() == symb.c_str(); }
John return r1.key() == r2.key();
John where qtext_to_symb has :
John if (text == Ä) return Adiaresis;
I took a quick look at the code and at qnamespace.h and have an
obvious question: does anyone know why Qt does not return
Qt::Adiaresis in this case? If it exists one would think that it is used somewhere, no?
John Juergen, if you have trouble trying this, tell me, and I'll
John commit a framework patch doing it. I can't test it obviously
Why? Don't you have a compose key? I do see the wrong behaviour on my
US keyboard.
JMarc
Re: AltGr chrashes qtlyx-1.3.0cvs -dbg key
Dear John, I tried to make a backtrace. But I don't know how to enter the option -dbg 4. If I start gdb lyx -dbg 4 gdb says unrecognized option `-dbg'. I didn't found a way to add the option. Norbert John Levon wrote: On Wed, Dec 04, 2002 at 03:53:32PM +0100, Norbert Koksch wrote: I corrected the subject. one of our lines starting lyxerr[Debug::KEY] in QLyXKeySym.C is accessing where it shouldn't. A backtrace would tell us where regards john
Re: AltGr chrashes qtlyx-1.3.0cvs -dbg key
On Wednesday 04 December 2002 3:34 pm, Norbert Koksch wrote: Dear John, I tried to make a backtrace. But I don't know how to enter the option -dbg 4. If I start gdb lyx -dbg 4 Try $ gdb lyx gdb run -dbg 4
Re: Towards LyX 1.2.2 [status update #4]
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars, the machine on which I can make a distribution is behind a | firewall. Do you think you could do a distribution for me? I am not sure I can... since I only have access to machines that have autoconf 2.53 now... -- Lgb
Re: Towards LyX 1.2.2 [status update #4]
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | Lars Lars, the machine on which I can make a distribution is behind a Lars | firewall. Do you think you could do a distribution for me? Lars I am not sure I can... since I only have access to machines that Lars have autoconf 2.53 now... OK, I'll see what I can do then. JMarc
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
On Wed, Dec 04, 2002 at 04:33:35PM +0100, Jean-Marc Lasgouttes wrote: I took a quick look at the code and at qnamespace.h and have an obvious question: does anyone know why Qt does not return Qt::Adiaresis in this case? If it exists one would think that it is used somewhere, no? Because Qt is broken. Why? Don't you have a compose key? I do see the wrong behaviour on my US keyboard. Everything works great for me with Qt2. Here's my xev output for 'Ä' : KeyPress event, serial 25, synthetic NO, window 0x401, root 0x25, subw 0x0, time 3930855237, (-477,505), root:(621,525), state 0x0, keycode 113 (keysym 0xff20, Multi_key), same_screen YES, XLookupString gives 0 characters: KeyRelease event, serial 25, synthetic NO, window 0x401, root 0x25, subw 0x0, time 3930855334, (-477,505), root:(621,525), state 0x20, keycode 113 (keysym 0xff20, Multi_key), same_screen YES, XLookupString gives 0 characters: KeyPress event, serial 25, synthetic NO, window 0x401, root 0x25, subw 0x0, time 3930855483, (-477,505), root:(621,525), state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 characters: KeyPress event, serial 25, synthetic NO, window 0x401, root 0x25, subw 0x0, time 3930855639, (-477,505), root:(621,525), state 0x1, keycode 11 (keysym 0x22, quotedbl), same_screen YES, XLookupString gives 1 characters: KeyRelease event, serial 25, synthetic NO, window 0x401, root 0x25, subw 0x0, time 3930855721, (-477,505), root:(621,525), state 0x1, keycode 11 (keysym 0x22, quotedbl), same_screen YES, XLookupString gives 1 characters: KeyPress event, serial 25, synthetic NO, window 0x401, root 0x25, subw 0x0, time 3930856149, (-477,505), root:(621,525), state 0x1, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 characters: A KeyRelease event, serial 25, synthetic NO, window 0x401, root 0x25, subw 0x0, time 3930856306, (-477,505), root:(621,525), state 0x1, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 characters: A This look a bit weird, but I do get Ä in every X application ... I so don't understand this stuff regards john -- Trolls like content too. - Bob Abooey, /.
Re: Qt GUI: math symbols and math pannel problems
On Wed, Dec 04, 2002 at 02:58:13PM +, Persio Barros wrote: 2002-11-25 Jean-Marc Lasgouttes [EMAIL PROTECTED] * qlkey.h (string_to_qkey): Add many missing entries Well, I still don't see these with a current build. try re-building all of lyx after a make distclean john -- Trolls like content too. - Bob Abooey, /.
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
John == John Levon [EMAIL PROTECTED] writes: John On Wed, Dec 04, 2002 at 04:33:35PM +0100, Jean-Marc Lasgouttes John wrote: I took a quick look at the code and at qnamespace.h and have an obvious question: does anyone know why Qt does not return Qt::Adiaresis in this case? If it exists one would think that it is used somewhere, no? John Because Qt is broken. I began to look at the code in qapplication_x11.cpp (at the end of QApplication::x11ClientMessage), which generates the QKeyEvent, but since I do not know the format of the XClientMessages that are sent around (and do not even understand how they are generated), it is difficult to understand what the code does. Actually, I fail to see a valid reason why key() == 0 in this case... Why? Don't you have a compose key? I do see the wrong behaviour on my US keyboard. John Everything works great for me with Qt2. Here's my xev output for John 'Ä' : I have the same. And it also works with lyx/qt? What is the -dbg key output? JMarc
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
John Levon wrote: Juergen, if you have trouble trying this, tell me, and I'll commit a framework patch doing it. I can't test it obviously Please do this (or send me a patch to test). This area looks very strange to me. Thanks, Jürgen.
Re: gcc 3.2 internal compiler error
John Levon wrote: On Wed, Dec 04, 2002 at 10:09:11AM +0100, Lars Gullik Bjønnes wrote: Most distributions have added some vendor patches that fix this problem. So IMHO it is a vendor problem. RH f.ex. does not have this problem. (and suse do have it) it's a buggy suse patch. clean 3.2 tarball is fine. I've asked people to report bug to suse to but nobody has said they've done so I just did. Nobody really said it is a SuSE bug so far, I thought it were a gcc bug.
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
On Wed, Dec 04, 2002 at 05:26:17PM +0100, Jean-Marc Lasgouttes wrote: I began to look at the code in qapplication_x11.cpp (at the end of QApplication::x11ClientMessage), which generates the QKeyEvent, but since I do not know the format of the XClientMessages that are sent around (and do not even understand how they are generated), it is difficult to understand what the code does. Actually, I fail to see a valid reason why key() == 0 in this case... it's == 0x I don't have Qt source right now I have the same. And it also works with lyx/qt? What is the -dbg key output? Press key 4128 text none, ascii 0 getSymbolName() - Shift_L KeySym is Shift_L Press key 4128 text none, ascii 0 getSymbolName() - Shift_L KeySym is Shift_L Press key 196 text Ä, ascii 196 getSymbolName() - Adiaeresis KeySym is Adiaeresis action first set to [-1] action now set to [-1] getSymbolName() - Adiaeresis Key [action=-1][S-Adiaeresis] Removing modifiers... Action now set to [88] getISO returning Ä Cannot decode: Ä SelfInsert arg[`Ä'] It's getSymbolName() that's the crucial bit. regards john -- Trolls like content too. - Bob Abooey, /.
Re: gcc 3.2 internal compiler error
On Wed, Dec 04, 2002 at 05:32:40PM +0100, Moritz Moeller-Herrmann wrote: to report bug to suse to but nobody has said they've done so I just did. Thanks. Nobody really said it is a SuSE bug so far, I thought it were a gcc bug. I did mention at some point that the gcc 3.2 tarball was OK for this... regards john -- Trolls like content too. - Bob Abooey, /.
Re: gcc 3.2 internal compiler error
John Levon wrote: On Wed, Dec 04, 2002 at 10:09:11AM +0100, Lars Gullik Bjønnes wrote: Most distributions have added some vendor patches that fix this problem. So IMHO it is a vendor problem. RH f.ex. does not have this problem. (and suse do have it) it's a buggy suse patch. clean 3.2 tarball is fine. I've asked people to report bug to suse to but nobody has said they've done so I just did. Nobody really said it is a SuSE bug so far, I thought it were a gcc bug. it is a gcc bug! rh and suse have the right patch on their ftp site. The only problem is that you have to recompile the whole gcc. Herbert -- Dr.-Ing Herbert Voss [EMAIL PROTECTED]
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
On Wed, Dec 04, 2002 at 05:28:57PM +0100, Juergen Spitzmueller wrote:
Please do this (or send me a patch to test). This area looks very strange to
me.
Try this
john
Index: QLyXKeySym.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLyXKeySym.h,v
retrieving revision 1.8
diff -u -r1.8 QLyXKeySym.h
--- QLyXKeySym.h20 Oct 2002 01:48:27 - 1.8
+++ QLyXKeySym.h4 Dec 2002 16:39:12 -
@@ -60,6 +60,11 @@
int key() const {
return key_;
}
+
+ QString text() const {
+ return text_;
+ }
+
private:
/// the Qt sym value
int key_;
Index: QLyXKeySym.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QLyXKeySym.C,v
retrieving revision 1.10
diff -u -r1.10 QLyXKeySym.C
--- QLyXKeySym.C20 Oct 2002 01:48:27 - 1.10
+++ QLyXKeySym.C4 Dec 2002 16:39:12 -
@@ -79,10 +79,14 @@
bool operator==(LyXKeySym const k1, LyXKeySym const k2)
{
- // note we ignore text_ here (non-strict ==), because
- // text_ is not filled out by keymap initialisation
+ QLyXKeySym const q1(static_castQLyXKeySym const (k1));
+ QLyXKeySym const q2(static_castQLyXKeySym const (k2));
+
+ if (q1.key() == Qt::Key_unknown)
+ lyxerr[Debug::KEY] q1 is unknown () ?? q1.text().latin1()
+endl;
- return static_castQLyXKeySym const (k1).key()
- == static_castQLyXKeySym const (k2).key();
+ if (q2.key() != Qt::Key_unknown)
+ return q1.key() == q2.key();
+ return q1.text() == qtext_to_symbol(q2.text());
}
Index: qlkey.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/qlkey.h,v
retrieving revision 1.16
diff -u -r1.16 qlkey.h
--- qlkey.h 4 Dec 2002 11:06:03 - 1.16
+++ qlkey.h 4 Dec 2002 16:39:18 -
@@ -555,4 +555,11 @@
}
}
+
+QString const qtext_to_symbol(QString const text)
+{
+ if (text == 'Ä') return Adiaeresis;
+ return ;
+}
+
#endif // QLKEY_H
Re: gcc 3.2 internal compiler error
On Wed, Dec 04, 2002 at 05:37:00PM +0100, Herbert Voss wrote: it is a gcc bug! rh and suse have the right patch on their Then why did lyx compile fine for me using gcc 3.2 whilst it was failing for others using vendor gcc's ? then you have the one with the patch, like the one from rh, but suse8.1 comes without it. what does your gcc --version says? Herbert john -- Trolls like content too. - Bob Abooey, /. -- Dr.-Ing Herbert Voss [EMAIL PROTECTED]
Re: gcc 3.2 internal compiler error
On Wed, Dec 04, 2002 at 05:46:24PM +0100, Herbert Voss wrote: then you have the one with the patch, like the one from rh, but suse8.1 comes without it. I compiled it from ftp.gnu.org tarball. what does your gcc --version says? 3.2 ;) (I'm using 3.2.1 now, but it was 3.2 at the time) regards john -- Trolls like content too. - Bob Abooey, /.
Re: gcc 3.2 internal compiler error
On Wed, Dec 04, 2002 at 05:37:00PM +0100, Herbert Voss wrote: it is a gcc bug! rh and suse have the right patch on their Then why did lyx compile fine for me using gcc 3.2 whilst it was failing for others using vendor gcc's ? john -- Trolls like content too. - Bob Abooey, /.
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
John Levon wrote: Try this No success. I get millions of these messages: QGArray: Cannot allocate array with negative length And -dbg key gives another million of this kind: q1 is unknown () ??Ydiaeresis Jürgen.
Re: gcc 3.2 internal compiler error
On Wed, Dec 04, 2002 at 05:46:24PM +0100, Herbert Voss wrote: then you have the one with the patch, like the one from rh, but suse8.1 comes without it. I compiled it from ftp.gnu.org tarball. what does your gcc --version says? 3.2 ;) what a joke ... the one from the rh ftp site was voss@maria:~ gcc --version gcc (GCC) 3.2.1 20020903 (prerelease) Herbert
Re: gcc 3.2 internal compiler error
On Wed, Dec 04, 2002 at 06:11:49PM +0100, Herbert Voss wrote: what a joke ... the one from the rh ftp site was That would be the pre-release snapshot. Download gcc-[core,g++]-3.2.tar.gz instead. voss@maria:~ gcc --version gcc (GCC) 3.2.1 20020903 (prerelease) I long deleted 3.2, but believe me, it WAS 3.2 regards john -- Trolls like content too. - Bob Abooey, /.
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
On Wed, Dec 04, 2002 at 06:09:59PM +0100, Jürgen Spitzmüller wrote: And -dbg key gives another million of this kind: q1 is unknown () ??Ydiaeresis with what else ? Indeed Qt knows nothing of Ydiaeresis. The patch still should have worked for Adiaeresis though. Try outputting q1/2 key/text and find where the comparison is failing. You're looking for q1.text == Adiaeresis To me, it looks like we have to abandon Qt altogether and use an API that actually works; namely, the X one. Fun. john -- Trolls like content too. - Bob Abooey, /.
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
q1 is unknown () ??Ydiaeresis is this the same as Key_ydiaeresis? http://doc.trolltech.com/3.0/qt.html#Key-enum (Key_ydiaeresis = 0x0ff) Ed.
Re: lyx-devel src/frontends/qt2/: ChangeLog qlkey.h
On Wed, Dec 04, 2002 at 06:25:47PM +, Edwin Leuven wrote: q1 is unknown () ??Ydiaeresis is this the same as Key_ydiaeresis? no, that's lowercase http://doc.trolltech.com/3.0/qt.html#Key-enum (Key_ydiaeresis = 0x0ff) moz X11 190 cgrepall Ydiaeresis ./HPkeysym.h:74:#define hpXK_Ydiaeresis 0x10EE ./HPkeysym.h:150:#ifndef XK_Ydiaeresis ./HPkeysym.h:151:#define XK_Ydiaeresis 0x10ee ./keysymdef.h:769:#define XK_Ydiaeresis 0x13be We really have no choice here, I think. Maybe one day Qt will be usable regards john -- Trolls like content too. - Bob Abooey, /.
Re: AltGr chrashes qtlyx-1.3.0cvs -dbg key
Hallo,
thanks to Angus, here is the backtrace:
Press key 65535 text none, ascii 0
sym empty in getSymbolName()
Program received signal SIGSEGV, Segmentation fault.
0x0824ddda in QLyXKeySym::getSymbolName (this=0x853a700)
at /usr/include/g++-3/std/bastring.h:225
225 { return assign (s, traits::length (s)); }
Norbert
Angus Leeming wrote:
On Wednesday 04 December 2002 3:34 pm, Norbert Koksch wrote:
Dear John,
I tried to make a backtrace. But I don't know how to enter the option
-dbg 4.
If I start
gdb lyx -dbg 4
Try
$ gdb lyx
gdb run -dbg 4
Re: AltGr chrashes qtlyx-1.3.0cvs -dbg key
On Wed, Dec 04, 2002 at 06:05:04PM +0100, Norbert Koksch wrote: Program received signal SIGSEGV, Segmentation fault. 0x0824ddda in QLyXKeySym::getSymbolName (this=0x853a700) OK update and try again john
Qt Key, testers wanted
I'm trying to compile a list of broken keys. Please compile the attached
test application (e.g. g++ -I$QTDIR/include -o keytest keytest.cpp -L$QTDIR/lib -lqt)
and tell me which keys produce BUG !!
On my keyboard, only KP_Begin gives this. Also please provide the
KeyPress event listed from running xev and pressing the eky
regards
john
--
Trolls like content too.
- Bob Abooey, /.
#include qapplication.h
#include qlabel.h
class QKeyTest : public QLabel {
public:
QKeyTest() : QLabel(0, , false) {}
protected:
void keyPressEvent(QKeyEvent * e) {
QString s(Pressed key which has text \);
s += e-text();
QString t;
t.setNum(e-key());
s += \, with key value of + t;
if (e-key() == Qt::Key_unknown) {
s += BUG !!;
}
setText(s);
}
};
int main(int argc, char **argv)
{
QApplication a(argc, argv);
QKeyTest * t = new QKeyTest();
a.setMainWidget(t);
t-show();
a.exec();
}
Re: Qt GUI: math symbols and math pannel problems
From: John Levon [EMAIL PROTECTED] try re-building all of lyx after a make distclean john OK. This is what I did: $ make distclean $ ./autogen.sh $ ./configure --with-frontend=qt --with-qt-dir=/usr/lib/qt3 $ make $ src/lyx The resulting program shows exactly the same behavior. Any other idea? Persio _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
Re: Qt GUI: math symbols and math pannel problems
On Wed, Dec 04, 2002 at 06:19:12PM +, Persio Barros wrote: The resulting program shows exactly the same behavior. Any other idea? No, none regards john -- Trolls like content too. - Bob Abooey, /.
[patch]: xworkarea
It looks big, but it's actually trivial with no change in functionality. See
ChangeLog.
Ok to apply?
Angus
? bmtable.c-safe
? patch.diff
? bmtable.h-safe
? README-xformsbugs
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.632
diff -u -p -r1.632 ChangeLog
--- ChangeLog 4 Dec 2002 02:57:14 - 1.632
+++ ChangeLog 4 Dec 2002 19:06:54 -
@@ -1,3 +1,16 @@
+2002-12-04 Angus Leeming [EMAIL PROTECTED]
+
+ * XWorkArea.h (backgroundbox): Removed. No need to name it explicitly.
+
+ * XWorkArea.C (work_area_handler): move static vars inside loop,
+ rename vars as discussed with Lars. Document changes in the text.
+ Don't declare functions as static; use namespace anon.
+ (setXtermCursor): removed; not used.
+ (destroy_object): removed; not used.
+ Remove unneeded header files ColorHandler.h, LyXView.h, filetools.h,
+ lstrings.h, LAssert.h, cmath, cctype.
+ Various other trivial clean-ups.
+
2002-12-03 Juergen Spitzmueller [EMAIL PROTECTED]
* xforms_helpers.C: (updateWidgetsFromLength)
Index: FormBase.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormBase.C,v
retrieving revision 1.67
diff -u -p -r1.67 FormBase.C
--- FormBase.C 1 Dec 2002 22:59:19 - 1.67
+++ FormBase.C 4 Dec 2002 19:06:54 -
@@ -259,10 +259,16 @@ void FormBase::PrehandlerCB(FL_OBJECT *
return;
}
-
if (event != FL_ENTER event != FL_LEAVE)
return;
+ if (message_widget_) {
+ // Post feedback as the mouse enters the object,
+ // remove it as the mouse leaves.
+ MessageCB(ob, event);
+ }
+
+#if FL_VERSION 1
if (ob-objclass == FL_TABFOLDER) {
// This prehandler is used to work-around an xforms bug and
// ensures that the form-x, form-y coords of the active
@@ -280,14 +286,12 @@ void FormBase::PrehandlerCB(FL_OBJECT *
}
}
+#endif
- if (message_widget_) {
- // Post feedback as the mouse enters the object,
- // remove it as the mouse leaves.
- MessageCB(ob, event);
- }
-
-#if FL_VERSION 0 || FL_REVISION = 89
+// Fixed in xforms 1.0.0.
+// Not applicable in xforms 0.88.
+#if (FL_VERSION == 0 FL_REVISION = 89) || \
+(FL_VERSION == 1 FL_REVISION == 0 FL_FIXLEVEL == 0)
// Tooltips are not displayed on browser widgets due to an xforms' bug.
// This is a work-around:
if (ob-objclass == FL_BROWSER) {
Index: XWorkArea.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/XWorkArea.C,v
retrieving revision 1.28
diff -u -p -r1.28 XWorkArea.C
--- XWorkArea.C 3 Dec 2002 18:28:17 - 1.28
+++ XWorkArea.C 4 Dec 2002 19:06:55 -
@@ -17,9 +17,7 @@
#include XWorkArea.h
#include debug.h
-#include LyXView.h
#include XLyXKeySym.h
-#include ColorHandler.h
#include funcrequest.h
#include Timeout.h
@@ -27,17 +25,6 @@
#include lyxlookup.h
#endif
-#include support/filetools.h // LibFileSearch
-#include support/lstrings.h
-#include support/LAssert.h
-
-#include cmath
-#include cctype
-
-// xforms doesn't define this (but it should be in forms.h).
-extern C
-FL_APPEVENT_CB fl_set_preemptive_callback(Window, FL_APPEVENT_CB, void *);
-
using std::endl;
using std::abs;
using std::hex;
@@ -46,23 +33,9 @@ using std::dec;
namespace {
inline
-void waitForX()
+void waitForX(bool discard)
{
- XSync(fl_get_display(), 0);
-}
-
-
-void setXtermCursor(Window win)
-{
- static Cursor cursor;
- static bool cursor_undefined = true;
- if (cursor_undefined) {
- cursor = XCreateFontCursor(fl_get_display(), XC_xterm);
- XFlush(fl_get_display());
- cursor_undefined = false;
- }
- XDefineCursor(fl_get_display(), win, cursor);
- XFlush(fl_get_display());
+ XSync(fl_get_display(), discard);
}
@@ -85,8 +58,6 @@ mouse_button::state x_button_state(unsig
case FL_MBUTTON5:
b = mouse_button::button5;
break;
- default: // FIXME
- break;
}
return b;
}
@@ -105,62 +76,56 @@ key_modifier::state x_key_state(unsigned
}
-} // anon namespace
+extern C {
+// Just a bunch of C wrappers around static members of XWorkArea
+void C_scroll_cb(FL_OBJECT * ob, long)
+{
+ XWorkArea * area = static_castXWorkArea*(ob-u_vdata);
+ area-scroll_cb();
+}
-extern C {
- // Just a bunch of C wrappers around static members of XWorkArea
- static
- void C_XWorkArea_scroll_cb(FL_OBJECT * ob, long)
- {
- XWorkArea * area = static_castXWorkArea*(ob-u_vdata);
- area-scroll_cb();
- }
+int C_work_area_handler(FL_OBJECT * ob, int event, FL_Coord, FL_Coord,
+ int key, void * xev)
+{
+ return XWorkArea::work_area_handler(ob, event, 0, 0, key, xev);
+}
- static
- int C_XWorkArea_work_area_handler(FL_OBJECT * ob, int event,
- FL_Coord, FL_Coord,
- int key, void * xev)
- {
- return XWorkArea::work_area_handler(ob, event,
- 0, 0, key, xev);
- }
- static
- int C_XWorkAreaEventCB(FL_FORM * form, void *
Cryptic message???
So what should it be doing, John? Angus /// X selection hook - xforms gets it wrong fl_current_form-u_vdata = this; fl_register_raw_callback(fl_current_form, FL_ALL_EVENT, C_event_cb);
Re: [patch]: xworkarea
Angus Leeming [EMAIL PROTECTED] writes:
| It looks big, but it's actually trivial with no change in functionality. See
| ChangeLog.
But you do change behaviour.
| -void waitForX()
| +void waitForX(bool discard)
| {
| - XSync(fl_get_display(), 0);
| -}
rationale?
| + if (!ev || !area-scrollbar)
| + break;
| +
| + int const drag_x = ev-xmotion.x;
| int const drag_y = ev-xmotion.y;
| + int const area_x = ob-x;
| int const area_y = ob-y;
| + int const area_w = ob-w;
| int const area_h = ob-h;
|
| - // Check if the mouse is above or below the workarea
| - if (drag_y = area_y + area_h || drag_y = area_y) {
| - // we are outside, then we must not give too many
| - // motion events.
| - if (timdel.running())
| + // Check if the mouse is outside the workarea
| + if (drag_x = area_w || drag_x = area_x + area_w ||
| + drag_y = area_y || drag_y = area_y + area_h) {
Why this change? Now line selection when having the mouse ourside the
workarea on the left or right side will be sluggish.
| - XSync(fl_get_display(), 1);
| - // This purge make f.ex. scrolling stop immidiatly when
| + waitForX(true);
| + // This purge make f.ex. scrolling stop
| immediately when
ok then...
--
Lgb
Re: A note about compiling LyX
On Wed, 4 Dec 2002, Christian Ridderström wrote: On 4 Dec 2002, Jean-Marc Lasgouttes wrote: Christian == Christian Ridderström [EMAIL PROTECTED] writes: - are you sure that --with-extra-prefix=/pkg/mdhacks/grp/util does not work? Pretty sure... but it was late :-) Well.. I can't repeat the error, so maybe it never happened :-) /Christian -- Christian Ridderström, +46-8-790 91 37 http://www.md.kth.se/~chr Mechatronics lab, Dept. of Machine Designhttp://www.md.kth.se
trouble with AM_FUNC_ERROR_AT_LINE
Hello, I have checkout files CVS from Thu Dec 5 02:25:24 MSK 2002 autogen.sh produced too many errors until I do not comment AM_FUNC_ERROR_AT_LINE $ diff -urN gnome.m4.old gnome.m4 --- gnome.m4.old2002-12-01 15:56:22 +0300 +++ gnome.m42002-12-05 02:30:09 +0300 @@ -1701,7 +1701,7 @@ # to include `error.c' error.c has some HAVE_* checks AC_CHECK_FUNCS(vprintf doprnt strerror_r) - AM_FUNC_ERROR_AT_LINE +dnl AM_FUNC_ERROR_AT_LINE # This is required if we declare setreuid () and setregid (). AC_TYPE_UID_T $ autoconf --version autoconf (GNU Autoconf) 2.56 $ automake --version automake (GNU automake) 1.7.1 $ aclocal --version aclocal (GNU automake) 1.7.1 -- Lav GNU! ALT Linux Team! LaTeX! LyX!
Re: trouble with AM_FUNC_ERROR_AT_LINE
Vitaly Lipatov [EMAIL PROTECTED] writes: | Hello, | I have checkout files CVS from Thu Dec 5 02:25:24 MSK 2002 | autogen.sh produced too many errors until I do not comment | AM_FUNC_ERROR_AT_LINE What errors? -- Lgb
Patch for cyrillic locale
Hello,
I attached patch to configure script running when LyX
reconfiguring.
It knowns Russia, Ukrainian have more than one locale with
various encoding in them. Attached patch do tuning LyX in
depends from user's locale setting. We is using it in ALT Linux
for two years and have not problem.
Please pay some attention :)
--
Lav
GNU! ALT Linux Team! LaTeX! LyX!
--- configure.m4.orig 2002-12-05 02:08:46 +0300
+++ configure.m4 2002-12-05 03:01:23 +0300
@@ -138,6 +138,8 @@
ac_n= ac_c='\c' ac_t=
fi
+# For language diagnostic purposes
+USERLANG=${LC_ALL:-${LC_CTYPE:-${LANG:-POSIX}}}
I do not really know why this is useful, but we might as well keep it.
# NLS nuisances.
@@ -593,6 +595,61 @@
\\font_encoding $chk_fontenc
EOF
+# Cyrillic defaults for user settings ##
+
+echo Add predefined settings for ${USERLANG} locale
+case ${USERLANG} in
+ru_RU.KOI8-R)
+cat $outfile EOF
+\\default_language russian
+\\default_papersize a4
+\\screen_font_scalable false
+\\screen_font_encoding koi8-r
+\\kbmap true
+\\kbmap_primary null.kmap
+\\kbmap_secondary koi8-r.kmap
+EOF
+ ;;
+ru_RU.CP1251)
+ cat $outfile EOF
+\\default_language russian
+\\default_papersize a4
+\\screen_font_scalable false
+\\screen_font_encoding cp1251
+EOF
+ ;;
+uk_UA.CP1251)
+ cat $outfile EOF
+\\default_language ukrainian
+\\default_papersize a4
+\\screen_font_scalable false
+\\screen_font_encoding cp1251
+EOF
+ ;;
+uk_UA.KOI8-U)
+ cat $outfile EOF
+\\default_language ukrainian
+\\default_papersize a4
+\\screen_font_scalable false
+\\screen_font_encoding koi8-u
+\\kbmap true
+\\kbmap_primary null.kmap
+\\kbmap_secondary koi8-u.kmap
+EOF
+
+ ;;
+ru_RU.PT154)
+ cat $outfile EOF
+\\default_language kazakh
+\\default_papersize a4
+\\screen_font_scalable false
+\\screen_font_encoding paratype-cp154
+EOF
+ ;;
+*) :;;
+esac
+
+
X FONTS
# create a fonts.dir file to make X fonts available to LyX
echo checking for TeX fonts
russian translation for LyX 1.2.2
Hello, Please commit ru.po for LyX 1.2.2 (BRANCH-1_2_X I hope :) File is attached. -- Lav GNU! ALT Linux Team! LaTeX! LyX! ru.po.bz2 Description: BZip2 compressed data
Re: trouble with AM_FUNC_ERROR_AT_LINE
On Четверг 05 Декабрь 2002 02:46, Lars Gullik Bjønnes wrote: Vitaly Lipatov [EMAIL PROTECTED] writes: | Hello, | I have checkout files CVS from Thu Dec 5 02:25:24 MSK 2002 | autogen.sh produced too many errors until I do not comment | AM_FUNC_ERROR_AT_LINE What errors? I removed config/gnome.m4 file and get working configure. ./autogen.sh output you requested: Locating GNU m4... found: m4 Generate acinclude.m4... done. Building macros... . aclocal: configure.in: : macro `AM_FUNC_ERROR_AT_LINE' not found in library lib/reLyX sigc++ done. Building config header template... . WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. configure.in:60: warning: AC_COMPILE_IFELSE was called before AC_AIX configure.in:60: warning: AC_RUN_IFELSE was called before AC_AIX autoheader-default: error: AC_CONFIG_HEADERS not found in configure.in sigc++ WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. done. Building Makefile templates... . configure.in: `AM_INIT_AUTOMAKE' must be used automake-default: no proper implementation of AM_INIT_AUTOMAKE was found, automake-default: probably because aclocal.m4 is missing... automake-default: You should run aclocal to create this file, then automake-default: run automake again. /usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL src/frontends/Makefile.am:7: Libtool library used but `LIBTOOL' is undefined src/frontends/Makefile.am:7: src/frontends/Makefile.am:7: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/frontends/Makefile.am:7: to `configure.in' and run `aclocal' and `autoconf' again. /usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL src/frontends/controllers/Makefile.am:3: Libtool library used but `LIBTOOL' is undefined src/frontends/controllers/Makefile.am:3: src/frontends/controllers/Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/frontends/controllers/Makefile.am:3: to `configure.in' and run `aclocal' and `autoconf' again. /usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL src/frontends/gnome/Makefile.am:11: USE_BASIC_IMAGE_LOADER does not appear in AM_CONDITIONAL src/frontends/gnome/Makefile.am:3: Libtool library used but `LIBTOOL' is undefined src/frontends/gnome/Makefile.am:3: src/frontends/gnome/Makefile.am:3: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/frontends/gnome/Makefile.am:3: to `configure.in' and run `aclocal' and `autoconf' again. /usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL /usr/share/automake-1.7/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL src/frontends/qt2/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined src/frontends/qt2/Makefile.am:9: src/frontends/qt2/Makefile.am:9: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/frontends/qt2/Makefile.am:9: to `configure.in' and run `aclocal' and `autoconf' again. /usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL src/frontends/qt2/moc/Makefile.am:6: Libtool library used but `LIBTOOL' is undefined src/frontends/qt2/moc/Makefile.am:6: src/frontends/qt2/moc/Makefile.am:6: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' src/frontends/qt2/moc/Makefile.am:6: to `configure.in' and run `aclocal' and `autoconf' again. /usr/share/automake-1.7/am/depend2.am: am__fastdepCXX does not appear in AM_CONDITIONAL /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
epsi (again...)
Y'all must be sick of this now... The latest changes to 122cvs break (for me) if the image is named something.epsi I get lots of file not found errors in lyx. Rod _ rod | Beneath the waves, the waves / That's where I will be / | I'm going to see the cow beneath the sea. | They Might Be Giants, Lincoln
further
Futher to that last bit... The image in lyx is called as something.epsi, but the error I get is could not locate the file with any of these extensions: .eps, .ps, .eps.gz, .ps.gz, eps.Z The file is in the tmp dir named as something.epsi So, I guess this is a problem at my end really. I presume latex normally would want the file to be called blah.eps. If that's the case, I'm happy to change, as in the end, I would like a file that can be exported and run through latex. Rod _ rod | Beneath the waves, the waves / That's where I will be / | I'm going to see the cow beneath the sea. | They Might Be Giants, Lincoln
Re: Qt Key, testers wanted
On Wed, Dec 04, 2002 at 06:06:51PM +, John Levon wrote: I'm trying to compile a list of broken keys. Please compile the attached test application (e.g. g++ -I$QTDIR/include -o keytest keytest.cpp -L$QTDIR/lib -lqt) and tell me which keys produce BUG !! On my keyboard, only KP_Begin gives this. Also please provide the KeyPress event listed from running xev and pressing the eky Everything fine here (Standard US layout, Umlauts work using Compose, too_ Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
bar "|" doesn't work in Qt
In the Qt version, when I hit "|" (the pipe or the vertical bar obtained by hitting Shift and "\") I see "unknown function" at the bottom.. and of course, the bar isn't displayed.. same thing happens in math mode also.. Thanks, nirmal
Re: Indenting left justified paragraphs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Dekel Tsur <[EMAIL PROTECTED]> writes:
Lars> | On Wed, Nov 27, 2002 at 04:16:16PM +0100, Jean-Marc Lasgouttes wrote:
Lars> | >
Lars> | > Probably not. I guess it is a consequence of our changing
Lars> from | > \centering to center environments and friends.
Lars> |
Lars> | \begin{center} is bad as it adds space. | We need to change it
Lars> to something else.
Lars> Then tell us a better _LaTeX_ way.
The reason why we changed from {\centering ... \par} to center
environment was to have better logical marking (for example, reLyX has
problems with that). It is possible too to use
\begin{centering}...\end{centering}, although this means that we need
an extra par.
See the attached file for examples of different constructs. Note that
\begin{centering}
blah
\end{centering}
does _not_ work.
JMarc
essai.tex
Description: TeX document
Re: Indenting left justified paragraphs
> "Duncan" == Duncan Simpson <[EMAIL PROTECTED]> writes:
Duncan> I think the solution to this LaTeX problem is to move into
Duncan> plain TeX and use the machinery more directly. Having said
Duncan> that I think this is a good solution for lots problems that
Duncan> are difficult to solve in "pure" LaTeX.
No, we have a reasonable latex solution which is ``{centering blah\par}'',
what we want is a solution that is also good structured markup. Plain
TeX is not going to help us here...
JMarc
Re: compiling problems...
> "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes:
Christian> Hi I've finally decided to try and compile the cvs
Christian> version... and after struggling with xforms I seem to have
Christian> gotten past that but get this strange error message when
Christian> running:
Christian> Waiting for cpp_regex_traits.o.lock to be removed
I have the same problem on tru64 unix, unless I configure with
--disable-libtool-lock.
Actually, I looked at it a little and think this is a stupid bug in
libtool.m4. This happens because libtool.m4 thinks that the compiler
cannot handle -c and -o simultaneously. Why? Because it tries to
compile
int main(){
int some_variable = 0;
}
and thinks there is a problem when a warning is issued. Here the
warning is of course that the variable is not used.
Then it tries to do some tricky locking that does not work and
everything goes down the drain.
Note that NEWS for libtool 1.4.3 says:
* srcdir != builddir builds with Automake 1.5 work correctly.
So maybe an upgrade will help.
JMarc
Re: bar "|" doesn't work in Qt
> "Nirmal" == Nirmal Govind <[EMAIL PROTECTED]> writes: Nirmal> In the Qt version, when I hit "|" (the pipe or the vertical Nirmal> bar obtained by hitting Shift and "\") I see "unknown Nirmal> function" at the bottom.. and of course, the bar isn't Nirmal> displayed.. same thing happens in math mode also.. I have a patch for that (and other forgotten keys). I'll apply it asap. JMarc
Re: compiling problems...
On 4 Dec 2002, Jean-Marc Lasgouttes wrote: > > "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes: > > Christian> Hi I've finally decided to try and compile the cvs > Christian> version... and after struggling with xforms I seem to have > Christian> gotten past that but get this strange error message when > Christian> running: > > Christian> Waiting for cpp_regex_traits.o.lock to be removed > > I have the same problem on tru64 unix, unless I configure with > --disable-libtool-lock. > Thanks, the '--disable-libtool-lock' fixed it ... (at least it is compiling now :-) /C -- Christian Ridderström, +46-8-790 91 37 http://www.md.kth.se/~chr Mechatronics lab, Dept. of Machine Designhttp://www.md.kth.se
Re: bar "|" doesn't work in Qt
> I have a patch for that (and other forgotten keys). I'll apply it > asap. > > JMarc > Great! Thanks a lot.. nirmal
Preference on GUI frontend
Hello again, last time I asked you whether you recommend any of the available frontends, you said "no". However, when you compile LyX, xforms is chosen as default frontend. Will you keep this setting or switch to Qt before the final release? I guess that you don't want to recommend any of the frontends because that conflicts with the idea of the GUI independence layer. However, you must be prepared for users that ask for advice. I am sure they will do so! (Like myself) Michael -- === Michael Schmitt Telefon: +49 651 97551-40 Institut für TelematikTelefax: +49 651 97551-12 Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de D-54292 Trier E-Mail: mailto:[EMAIL PROTECTED] ===
Re: Indenting left justified paragraphs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Dekel Tsur <[EMAIL PROTECTED]> writes:
| Lars> | On Wed, Nov 27, 2002 at 04:16:16PM +0100, Jean-Marc Lasgouttes wrote:
| Lars> | >
| Lars> | > Probably not. I guess it is a consequence of our changing
| Lars> from | > \centering to center environments and friends.
| Lars> |
| Lars> | \begin{center} is bad as it adds space. | We need to change it
| Lars> to something else.
|
| Lars> Then tell us a better _LaTeX_ way.
|
| The reason why we changed from {\centering ... \par} to center
| environment was to have better logical marking (for example, reLyX has
| problems with that). It is possible too to use
| \begin{centering}...\end{centering}, although this means that we need
| an extra par.
|
| See the attached file for examples of different constructs. Note that
| \begin{centering}
| blah
| \end{centering}
| does _not_ work.
Yes, I have been reading a lot in my books lately, and it seems that
it was a big misguided to switch away from the statement variants.
My fault probably.
The center environment is only suited when you want to center small
parts _within_ a paragraph. (the trivlist in the implementation is
really mucking things up.)
--
Lgb
Re: [PATCH] Change tracking for 1.3cvs
Allan Rae <[EMAIL PROTECTED]> writes: | On Wed, 4 Dec 2002, John Levon wrote: | | [...] | > With all that administration, I'm even less inclined to do so then. | > | > CVS is worse at handling conflicts in such cases than patch is | | But at least CVS allows others to keep up to date with your work and | fiddle along with you. All you need to do is warn everyone when | you're rolling forward to a new branch -- if you find a suitable name | like BRANCH_CHANGE_TRACKER_x where x is a counter (1,2,3..) for the | current branch it shouldn't be hard for people to work out the latest | branch. I cannot believe that merging is that hard. The Gcc folks do this all the time, and that project is a tiny bit larger than LyX... -- Lgb
trouble with labels/cross-referencing
Hi.. I ran into trouble while cross-referencing sections which had the same names and hence same label names but belonged to different documents. Say I have two docs, and there's a section with exactly the same name in each of these docs. If I insert labels in each of these docs, they both have the same name by default. Now, if I include both these docs in another doc, things get confusing when I try to cross reference one of these sections in the main doc since there'll be two labels with the same name.. would it be possible to include some kind of an identifier in the label name (by default) which might make the label unique somehow? One of the reasons for the problem is that the cross reference dialog in the main doc will show ALL the labels together no matter which doc I select from the drop-down menu (this is something I'd reported in an earlier mail)... if this behavior is changed, it'll become easier to find the right label.. Thanks, nirmal
Re: gcc 3.2 internal compiler error
Michael Schmitt <[EMAIL PROTECTED]> writes: | Hi, | | are there any plans to provide a workaround for the following problem: no | g++ -DHAVE_CONFIG_H -I. -I. -I../../../../src -I../../../../boost | -isystem /usr/X11R6/include -g -O -fno-exceptions -W -Wall -Winline -c | cregex.cpp -MT cregex.lo -MD -MP -MF .deps/cregex.TPlo | -- | PrepareDocumentForEditing | ../../../../boost/boost/regex/detail/regex_match.hpp: In member function |`unsigned int boost::RegEx::GrepFiles(bool (*)(const char*, const |boost::RegEx&), const char*, bool, unsigned int)': | ../../../../boost/boost/regex/detail/regex_match.hpp:1902: Internal compiler |error in expand_call, at calls.c:3049 | Please submit a full bug report, | | Of course, it's not your fault. OTOH, gcc 3.2 is part of most current | Linux distributions, so you might be flooded by bug reports if | compilation of LyX 1.3.0 fails. Most distributions have added some "vendor patches" that fix this problem. So IMHO it is a vendor problem. RH f.ex. does not have this problem. (and suse do have it) -- Lgb
Size of inset labels
Hi, in the QT frontend, the "note" inset label is much larger than the "footnote" inset label. Moreover, menu item "New" is not translated into German (also "revert", "spellchecker", "preferences", "Index Entry", ...). Michael -- === Michael Schmitt Telefon: +49 651 97551-40 Institut für TelematikTelefax: +49 651 97551-12 Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de D-54292 Trier E-Mail: mailto:[EMAIL PROTECTED] ===
A note about compiling LyX
Considering the snags I've run into trying to compile LyX, I decided to add some notes to this wiki-page: http://ev-en.org/wiki/moin.cgi/LyXCompile /Christian -- Christian Ridderström, +46-8-790 91 37 http://www.md.kth.se/~chr Mechatronics lab, Dept. of Machine Designhttp://www.md.kth.se
