Re: mouse wheel
Angus Leeming wrote: >> Scroll with the mouse wheel without "cursor follows scrollbar" is >> severely broken in xforms. The qt version works because scroll >> doesn't get through LyX dispatch mechanism. > > Then is a possible solution to prevent the xforms frontend from > dispacthing an LFUN? (As in, if it works in the Qt frontend...) I may be a solution... but it seems a bit ad hoc to me. I think that we should solve this in the dispatch mechanism (maybe there are other LFUNS that need to not fire a fitCursor?) Alfredo
Re: Using reasonable Qt font defaults
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Maurizio" == Maurizio Monge <[EMAIL PROTECTED]> writes: > | Maurizio> Hello. I compiled lyx cvs (lyx-devel) on and amd64-pc-linux, | Maurizio> with gcc-3.4, latest binutils and qt font-end (qt-3.3.2). > | Maurizio> I get: > | Maurizio> terminate called after throwing an instance of | Maurizio> 'std::logic_error' what(): basic_string::_S_construct NULL | Maurizio> not valid Aborted > | The problem seems to be related to the use of the "sans" font family | which is unknown from qt. Could you try the attached patch which has | been send by Kornel Benko a while ago? > | Before applying this patch, though, I would like to understand why we | have those font values now, and why they do not work. Anyone has | ideas? I think you have nailed the reason for the crash. But I don't like your patch :-) (I am not sure that I like my own either... probably we could just do a: return QFontInfo(font).family(); and rely on the implicit conversion to std::string.) -- Lgb
Re: [patch] navigating
Lars Gullik BjÃnnes wrote: > I guess you have tested cases that need a screen update: > > - when seleciton This is handled explicitely, we only supress the update of we weren't selecting before the LFUN and we are not selecting after. > - cursor movement forcing a scroll This is handled separately in fitCursor. If fitCursor moves the screen an update is forced in any case. > - etc Hope so :-) Alfredo
Re: [patch] navigating
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | Alfredo Braunstein wrote: > >> second attempt to have an updateless cursor movement. > | Except that I forgot to restrict it to the few LFUNs that need it. | Third attempt. If this is all it takes, then go for it. I guess you have tested cases that need a screen update: - when seleciton - cursor movement forcing a scroll - etc -- Lgb
Re: lyx crash
Maurizio Monge <[EMAIL PROTECTED]> writes:
| #0 0x002a980626e9 in kill () from /lib64/libc.so.6
| #1 0x002a9736b111 in pthread_kill () from /lib64/libpthread.so.0
| #2 0x002a9736b432 in raise () from /lib64/libpthread.so.0
| #3 0x002a980623d2 in raise () from /lib64/libc.so.6
| #4 0x002a98063944 in abort () from /lib64/libc.so.6
| #5 0x002a975a6048 in __gnu_cxx::__verbose_terminate_handler ()
| at ../../../../libstdc++-v3/libsupc++/vterminate.cc:96
| #6 0x002a975a4236 in __cxxabiv1::__terminate (handler=0x7261)
| at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:43
| #7 0x002a975a4263 in std::terminate ()
| at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:53
| #8 0x002a975a4363 in __cxa_throw (obj=0x7261, tinfo=0x6, dest=0x1)
| at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:80
| #9 0x002a9754a158 in std::__throw_logic_error (
| __s=0x7261 ) at new_allocator.h:69
| #10 0x002a975885e6 in std::string::_S_construct (__beg=0x0,
| __end=0x ,
| [EMAIL PROTECTED])
| at basic_string.tcc:142
| #11 0x002a97588693 in basic_string (this=0x7fb2b0, __s=0x0,
| [EMAIL PROTECTED])
| at basic_string.h:1370
std::string constructor called with NULL, and the exception get
thrown.
| #12 0x00600687 in lyx_gui::sans_font_name () at
| lyx_gui.C:338
because QFontInfo where not able to find a sans-serif font. It seems
to me that the use of QString::latin1 in this funcion (sans_font_name)
is not very safe as it can obviously return NULL.
Can you test this patch and see if the crash goes away?
Index: lyx_gui.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/lyx_gui.C,v
retrieving revision 1.62
diff -u -p -r1.62 lyx_gui.C
--- lyx_gui.C 3 Apr 2004 08:37:10 - 1.62
+++ lyx_gui.C 18 May 2004 06:22:15 -
@@ -323,7 +323,9 @@ string const roman_font_name()
QFont font;
font.setStyleHint(QFont::Serif);
font.setFamily("serif");
- return QFontInfo(font).family().latin1();
+
+ QString name = QFontInfo(font).family().latin1();
+ return name;
}
@@ -335,7 +337,9 @@ string const sans_font_name()
QFont font;
font.setStyleHint(QFont::SansSerif);
font.setFamily("sans");
- return QFontInfo(font).family().latin1();
+
+ QString name = QFontInfo(font).family().latin1();
+ return name;
}
@@ -347,7 +351,9 @@ string const typewriter_font_name()
QFont font;
font.setStyleHint(QFont::TypeWriter);
font.setFamily("monospace");
- return QFontInfo(font).family().latin1();
+
+ QString name = QFontInfo(font).family().latin1();
+ return name;
}
--
Lgb
Re: Using reasonable Qt font defaults (was: lyx crash)
On Tue, May 18, 2004 at 01:42:58AM +0200, Kornel Benko wrote: > The patch I am using now without any crash is attached. The selected fonts may > have some unwanted default value, but at least you are then able to select your > own font with the lyx-UI. Hmm, that's interesting. Why would fromqstr() help us here? This patch can safely go in I think, so if it works, it works, but it's still curious. john
Re: Using reasonable Qt font defaults (was: lyx crash)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Montag, 17. Mai 2004 15:14, Jean-Marc Lasgouttes wrote:
> > "Maurizio" == Maurizio Monge <[EMAIL PROTECTED]> writes:
>
> Maurizio> Hello. I compiled lyx cvs (lyx-devel) on and amd64-pc-linux,
> Maurizio> with gcc-3.4, latest binutils and qt font-end (qt-3.3.2).
>
> Maurizio> I get:
>
> Maurizio> terminate called after throwing an instance of
> Maurizio> 'std::logic_error' what(): basic_string::_S_construct NULL
> Maurizio> not valid Aborted
>
> The problem seems to be related to the use of the "sans" font family
> which is unknown from qt. Could you try the attached patch which has
> been send by Kornel Benko a while ago?
>
> Before applying this patch, though, I would like to understand why we
> have those font values now, and why they do not work. Anyone has
> ideas?
>
> JMarc
The patch I am using now without any crash is attached. The selected fonts may
have some unwanted default value, but at least you are then able to select your
own font with the lyx-UI.
Kornel
- --
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQFAqU4IjEH+780+qtIRAgE6AKCLvL9LQMmT47qFK9YLgyihRGq9fgCdGdWd
OhOaXcQ07gncW95MqJ3L/qE=
=q8HG
-END PGP SIGNATURE-
Index: lyx_gui.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/lyx_gui.C,v
retrieving revision 1.62
diff -u -p -r1.62 lyx_gui.C
--- lyx_gui.C 2004/04/03 08:37:10 1.62
+++ lyx_gui.C 2004/05/17 23:34:59
@@ -323,7 +323,7 @@ string const roman_font_name()
QFont font;
font.setStyleHint(QFont::Serif);
font.setFamily("serif");
- return QFontInfo(font).family().latin1();
+ return fromqstr(QFontInfo(font).family());
}
@@ -335,7 +335,7 @@ string const sans_font_name()
QFont font;
font.setStyleHint(QFont::SansSerif);
font.setFamily("sans");
- return QFontInfo(font).family().latin1();
+ return fromqstr(QFontInfo(font).family());
}
@@ -347,7 +347,7 @@ string const typewriter_font_name()
QFont font;
font.setStyleHint(QFont::TypeWriter);
font.setFamily("monospace");
- return QFontInfo(font).family().latin1();
+ return fromqstr(QFontInfo(font).family());
}
}; // namespace lyx_gui
Index: QPrefs.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/QPrefs.C,v
retrieving revision 1.56
diff -u -p -r1.56 QPrefs.C
--- QPrefs.C 2004/04/20 08:51:11 1.56
+++ QPrefs.C 2004/05/17 23:35:00
@@ -409,7 +409,7 @@ void setComboxFont(QComboBox * cb, strin
for (int i = 0; i < cb->count(); ++i) {
lyxerr << "Looking at " << fromqstr(cb->text(i)) << endl;
- if (compare_no_case(cb->text(i).latin1(), info.family().latin1()) == 0) {
+ if (compare_no_case(fromqstr(cb->text(i)), fromqstr(info.family())) == 0) {
cb->setCurrentItem(i);
return;
}
Re: DocBook Export - IDs should not be in anchors, but in the elements
"Jose' Matos" <[EMAIL PROTECTED]> schrieb am 17.05.04 19:34:59: > > This can be easily solved using an external script though. :-) > :-))) I know what you mean. But believe me, depending on an external script, like the sed script http://www.karakas-online.de/mySGML/sedscr makes everything version-dependent. Once you change a small bit of how the exported SGML looks like in a next LyX version, you have to rewrite the script. That's why I set it my first priority to discuss and eliminate all substitutions in that file, at least those that depend on the structure of the SGML file. Chris -- Regards Chris Karakas http://www.karakas-online.de
Re: Description of connection between layouts, classes and styles
On Mon, 17 May 2004, Martin Vermeer wrote: > Yes, life sucks doesn't it. But the party was nice :-) > I tried to add my part -- will the better informed please chime in. Thank you very much! /Christian -- Christian Ridderström http://www.md.kth.se/~chr
Re: [patch] corrected file de_menus.bind
Uwe StÃhr wrote: because I'm dealing with the bindings at the moment, I looked at the file de_menus.bind which comes with the LyX distribution and changed it a little bit to to keep it up-todate. I removed a duplicate and rearranged some entries. Please forget this posting. My changes were wrong and unnecessary. Sorry for the inconvenience. regards Uwe
Re: [patch] corrected file de_math.bind
Jean-Marc Lasgouttes wrote:
Hmm, the bind file uses 'M-m ~S-bracketleft', which basically means
"[, with or without shift". From what you say about german keyboards
(which is true for french ones too), I would think that
\bind "M-m ~C-~M-~S-bracketleft""math-delim [ ]"
will work with both US and German keyboards. Could you try this?
Yes this works, thanks.
If is does work, then there is no need for a de_math.bind.
But we need a corrected version of math.bind. I attached all changes,
that were necessary to make it work with german keyboards.
I also reactivated the binding
"math-insert \oint"
with a new shortcut. Because the old one 'M-m o' collided with the bindings
"self-insert \#1"
regards Uwe
--- mathCVS.bind Sun May 18 22:02:08 2003
+++ math.bind Mon May 17 20:54:52 2004
@@ -33,10 +33,10 @@
\bind "M-m u" "math-insert \sum"
\bind "M-m i" "math-insert \int"
-\bind "M-m m" "math-mode"
+\bind "M-m m" "math-mode" # produces mathematical text
\bind "M-m d" "math-display"
-#\bind "M-m o" "math-insert \oint"
+\bind "M-m y" "math-insert \oint"
\bind "M-m p" "math-insert \partial"
\bind "M-m r" "math-insert \root"
\bind "M-m l" "math-limits"
@@ -91,9 +91,9 @@
\bind "M-m ~S-quotedbl" "math-insert \ddot"
\bind "M-m h""math-insert \hat"
-\bind "M-m ~S-backslash" "math-insert \grave"
+\bind "M-m ~C-~M-~S-backslash" "math-insert \grave"
\bind "M-m ~S-slash" "math-insert \acute"
-\bind "M-m ~S-ampersand" "math-insert \tilde"
+\bind "M-m ~C-~M-~S-ampersand" "math-insert \tilde"
\bind "M-m ~S-minus" "math-insert \bar"
\bind "M-m ~S-period" "math-insert \dot"
\bind "M-m S-V""math-insert \check"
@@ -107,11 +107,11 @@
# These do pairs of: () {} [] <> ||
\bind "M-m ~S-parenleft" "math-delim ( )"
-\bind "M-m ~S-bracketleft" "math-delim [ ]"
-\bind "M-m ~S-braceleft" "math-delim { }"
-\bind "M-m ~S-less" "math-delim langle rangle"
-\bind "M-m ~S-greater" "math-delim rangle langle"
-\bind "M-m ~S-bar" "math-delim | |"
+\bind "M-m ~C-~M-~S-bracketleft" "math-delim [ ]"
+\bind "M-m ~C-~M-~S-braceleft" "math-delim { }"
+\bind "M-m ~S-less" "math-delim langle rangle" # produces < >
+\bind "M-m ~S-greater" "math-delim rangle langle" # produces > <
+\bind "M-m ~C-~M-~S-bar" "math-delim | |"
# Note: it's easy to insert binary relations like \pm, \mp, \neq, \geq,
# This file is part of
# ==
#
# LyX, the Document Processor
#
# Copyright (C) 1997 LyX Team
#
# Version 0.1, May 28 1997
#
# ==
# This file provides math mode keys. Most were suggested by John Weiss
# and modified by Alejandro Aguilar Sierra to be used with different
# keyboard layouts.
#
# This file is automatically included from the main bind file.
#
# DO NOT CHANGE THIS BINDING FILE! It will be replaced
# with every new install of LyX and your changes will be lost.
# Instead, copy it to ~/.lyx/bind/math.bind and modify that copy.
# Note that the order of these is important. If you put the bindings
# that need "period" and "parenleft" first, they flood the minibuffer
# and make the keybinding hints impossible to read. That's why they're
# at the end.
# These are defined for the math menu:
\bind "M-m f" "math-insert \frac"
\bind "M-m s" "math-insert \sqrt"
\bind "M-m e" "math-superscript"
\bind "M-m x" "math-subscript"
\bind "M-m u" "math-insert \sum"
\bind "M-m i" "math-insert \int"
\bind "M-m m" "math-mode" # produces mathematical text
\bind "M-m d" "math-display"
\bind "M-m y" "math-insert \oint"
\bind "M-m p" "math-insert \partial"
\bind "M-m r" "math-insert \root"
\bind "M-m l" "math-limits"
\bind "M-m S-L l" "math-limits limits"
\bind "M-m S-L n" "math-limits nolimits"
\bind "M-m S-L space" "math-limits empty"
\bind "M-m n" "math-number"
\bind "M-m S-N" "math-nonumber"
\bind "M-m 8" "math-insert \infty"
\bind "M-m o 1" "self-insert \#1"
\bind "M-m o 2" "self-insert \#2"
\bind "M-m o 3" "self-insert \#3"
\bind "M-m o 4" "self-insert \#4"
\bind "M-m o 5" "self-insert \#5"
\bind "M-m o 6" "self-insert \#6"
\bind "M-m o 7" "self-insert \#7"
\bind "M-m o 8" "self-insert \#8"
\bind "M-m o 9" "self-insert \#9"
\bind "M-m t n" "math-mutate none"
\bind "M-m t t" "math-mutate dump"
\bind "M-m t a" "math-mutate align"
\bind "M-m t i" "math-mutate simple"
\bind "M-m t d" "math-mutate equation"
\bind "M-m t e" "math-mutate eqnarray"
\bind "M-m t m" "math-mutate multline"
\bind "M-m c i" "tabular-feature append-column"
\bind "M-m c d" "tabular-feature delete-column"
\bind "M-m c
Re: DocBook Export - IDs should not be in anchors, but in the elements
On Monday 17 May 2004 17:53, Chris Karakas wrote: > > > For sections and any other paragraph that you can set from menu that is > > correct, but for table and figures what we have now is: > > > > > > ... > > > > > > Is that OK with you? > > No. This can be solved but it will take a little bit more time, I will see how it can be done as I need to do some kind of multi-level analysis. This can be easily solved using an external script though. :-) > I am not even sure if an id in the title is semantically correct for > the DocBook SGML DTD - from the "feeling" of it, I would say no. Sure it is. :-) According to the TDG (Docbook: The Definitive Guide) the list of common attributes is: Arch Conformance ID Lang OS Remap Role Revision RevisionFlag UserLevel Vendor XrefLabel So we are on the safe side here. > Anyway, > I need the id in the table element (or equation, inlineequation etc. > element), because I want to use xrefs to a table (equation, > inlineequation and so on), not to a title. Sematically, you never point > to a title, rather to an element which might also have a title. Makes sense. If I don't get this for 1.4 I will get a script to do it. ;-) > > Now the anchor id is always transfered to its parent element. This > > only happens for the first, all other are ignored. > > Good. Can't you determine which anchor comes from a "title" setting in > the .lyx file and which not? Actually, only anchors that are due to > titles need to be transfered into the element as id's. Other anchors are > not relevant to our discussion here. I try to make the code as general as possible, that is why it is (almost) possible to pass another layout file, as use the docbook frontend to get xhtml without changing any LyX code. We are almost there. I know what needs to be done, though. :-) > > I forgot about equation and inline equation, but here it is easy as > > there is only one id. :-) > > > > I will do it soon. If not I will beg for help to André. ;-) > > Fine. Tell me when you are ready, I have more stuff. :-D Go on. :-) > O.K., I just could not resist: while you are looking at equation and > inlineequation, have a look at: > > http://www.karakas-online.de/forum/viewtopic.php?t=860 > > and make some thoughts for a future discussion. This cost me the whole > weekend and made me backstep to 1.2.0. I will open a new thread about it > when we are ready, but you can of course answer in that thread too. ;-) I will answer there an make copy to post here. :-) > Chris -- José Abílio LyX and docbook, a perfect match. :-)
Re: DocBook Export - IDs should not be in anchors, but in the elements
"Jose' Matos" <[EMAIL PROTECTED]> schrieb am 17.05.04 16:29:31: > > In 1.3.4: > > > blah blah... > > > In 1.4cvs: > > blah blah... > > I haven't ever used id's in para's, but might work, why not? This will have to be checked. If it works, it will enable setting xrefs not to anchors, but at least to a position "not far away" from a hypothetical, perfectly positioned anchor. > For sections and any other paragraph that you can set from menu that is > correct, but for table and figures what we have now is: > > > ... > > > > Instead of > > ... > > > > Is that OK with you? > No. I am not even sure if an id in the title is semantically correct for the DocBook SGML DTD - from the "feeling" of it, I would say no. Anyway, I need the id in the table element (or equation, inlineequation etc. element), because I want to use xrefs to a table (equation, inlineequation and so on), not to a title. Sematically, you never point to a title, rather to an element which might also have a title. > Now the anchor id is always transfered to its parent element. This only > happens for the first, all other are ignored. > Good. Can't you determine which anchor comes from a "title" setting in the .lyx file and which not? Actually, only anchors that are due to titles need to be transfered into the element as id's. Other anchors are not relevant to our discussion here. > I forgot about equation and inline equation, but here it is easy as there > is only one id. :-) > > I will do it soon. If not I will beg for help to André. ;-) > Fine. Tell me when you are ready, I have more stuff. :-D O.K., I just could not resist: while you are looking at equation and inlineequation, have a look at: http://www.karakas-online.de/forum/viewtopic.php?t=860 and make some thoughts for a future discussion. This cost me the whole weekend and made me backstep to 1.2.0. I will open a new thread about it when we are ready, but you can of course answer in that thread too. ;-) Chris -- Regards Chris Karakas http://www.karakas-online.de
Re: DocBook Export - IDs should not be in anchors, but in the elements
On Monday 17 May 2004 12:54, Chris Karakas wrote: > Did you do the same also for: , , , , > , , , and, more generally, > for *every* other element? equation is done now. Do we have inlineequation? -- José Abílio LyX and docbook, a perfect match. :-)
Re: Using reasonable Qt font defaults
On Mon, May 17, 2004 at 04:56:32PM +0200, Jean-Marc Lasgouttes wrote: > John> It looks wrong. For starters, these default aliases should exist > John> on any sane Qt system using Xft. Secondly, even if they don't > John> exist, the created font should change to a default, NOT return a > John> NULL. Something is badly wrong... > > Do you think you have time to have a look at this (understanding why > some people need this)? Not really, no. An interested party could double-check the Qt documentation to see if a NULL return value is acceptable or not. AFAIK it's not. "sans" etc. are just sensible defaults (and certainly way way better than "Arial" et al). The real bug here is the crash. The lack of a "sans" alias is probably a bug in whatever distro it is. If we don't have time to investigate, then a workaround would be to check for NULL, and then use a default-constructed QFont to get some kind of font name out of it. regards john
Re: Using reasonable Qt font defaults
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Mon, May 17, 2004 at 03:14:42PM +0200, Jean-Marc Lasgouttes John> wrote: >> The problem seems to be related to the use of the "sans" font >> family which is unknown from qt. Could you try the attached patch >> which has been send by Kornel Benko a while ago? John> It looks wrong. For starters, these default aliases should exist John> on any sane Qt system using Xft. Secondly, even if they don't John> exist, the created font should change to a default, NOT return a John> NULL. Something is badly wrong... Do you think you have time to have a look at this (understanding why some people need this)? JMarc
Re: Using reasonable Qt font defaults (was: lyx crash)
On Mon, May 17, 2004 at 03:14:42PM +0200, Jean-Marc Lasgouttes wrote: > The problem seems to be related to the use of the "sans" font family > which is unknown from qt. Could you try the attached patch which has > been send by Kornel Benko a while ago? It looks wrong. For starters, these default aliases should exist on any sane Qt system using Xft. Secondly, even if they don't exist, the created font should change to a default, NOT return a NULL. Something is badly wrong... john
Re: DocBook Export - IDs should not be in anchors, but in the elements
On Monday 17 May 2004 12:54, Chris Karakas wrote: > "Jose' Matos" <[EMAIL PROTECTED]> schrieb am 14.05.04 19:13:29: > > I have disabled anchors inside the paragraphs although they there is > > no problem with the xml convertion path. Later if needed this could be > > turned on only for xml with just one line. > > Fine! I will have to test all this but it may take some time - I have to > set up a separate chroot environment for this. I will come back on this > topic. > > I hope by "disabled" you don't mean really "erased". The id attribute of > the anchor immediately after an element should be brought "inside the > element" as an id attribute of the element itself - then you can erase > that anchor as it is not needed anymore. In 1.3.4: blah blah... In 1.4cvs: blah blah... Notice that the previous anchor is commented, that is why I called it disabled. :-) > I think you must decide how to do this in a "level" that is previous to > the one you are doing it now: at the level of parsing the .lyx file and > deciding how to export a LyX "token". > > I think the general rule should be: titles of whatever LyX environments, > be it sections, subsections, chapters, tables, figures, equations - > whatever, those titles should NOT be exported as > > sometitle > > but as > > ... Instead of ... Is that OK with you? > There may be some other anchors out there, not in such context. I don't > care - at the moment - about them. I am interested only at the anchors > that hold id attributes that should actually be id attributes of the > preceding elements. > > I hope it's clear. Now the anchor id is always transfered to its parent element. This only happens for the first, all other are ignored. [...] > > PS: Next issue, please. ;-) > > Don't worry, José - we have a long way in front of us. :-D :-) > Did you do the same also for: , , , , > , , , and, more generally, > for *every* other element? As you see in the title of this thread, I am > talking about "elements" not only 's. Thus, it must be: I forgot about equation and inline equation, but here it is easy as there is only one id. :-) I will do it soon. If not I will beg for help to André. ;-) > The same goes for the other elements accordingly. I think that's enough > work for the moment. ;-) > > Thank you very much for your efforts José - we are building a fantastic > application here! That would not be possible without the others guys in this list. 8-) > Chris -- José Abílio LyX and docbook, a perfect match. :-)
Re: 1.4.0cvs crash
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes: Alfredo> Maybe just to see what's inside? Like: "I'm editing here... Alfredo> hmmm let's see what's on the footnote down there... *click* Alfredo> -- now I've lost the position where I was editing... inset-toggle has the behaviour of opening the inset without entering there (and that's why I opposed to putting cursor inside). But now that I think of it, if you click on an element in the text, it means that you want to set the cursor there. So if one clicks on a footnote button, it may be reasonable to put the cursor inside. I do not know, really. JMarc
Using reasonable Qt font defaults (was: lyx crash)
> "Maurizio" == Maurizio Monge <[EMAIL PROTECTED]> writes:
Maurizio> Hello. I compiled lyx cvs (lyx-devel) on and amd64-pc-linux,
Maurizio> with gcc-3.4, latest binutils and qt font-end (qt-3.3.2).
Maurizio> I get:
Maurizio> terminate called after throwing an instance of
Maurizio> 'std::logic_error' what(): basic_string::_S_construct NULL
Maurizio> not valid Aborted
The problem seems to be related to the use of the "sans" font family
which is unknown from qt. Could you try the attached patch which has
been send by Kornel Benko a while ago?
Before applying this patch, though, I would like to understand why we
have those font values now, and why they do not work. Anyone has
ideas?
JMarc
Index: src/frontends/qt2/lyx_gui.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/lyx_gui.C,v
retrieving revision 1.59
diff -u -p -r1.59 lyx_gui.C
--- src/frontends/qt2/lyx_gui.C 2003/11/05 10:49:07 1.59
+++ src/frontends/qt2/lyx_gui.C 2004/01/03 16:31:07
@@ -287,8 +287,9 @@ string const roman_font_name()
QFont font;
font.setStyleHint(QFont::Serif);
- font.setFamily("serif");
- return QFontInfo(font).family().latin1();
+ font.setFamily("Times New Roman");
+ const char *x = QFontInfo(font).family().latin1();
+ return x?x:"";
}
@@ -299,8 +300,9 @@ string const sans_font_name()
QFont font;
font.setStyleHint(QFont::SansSerif);
- font.setFamily("sans");
- return QFontInfo(font).family().latin1();
+ font.setFamily("Arial");
+ const char *x = QFontInfo(font).family().latin1();
+ return x?x:"";
}
@@ -311,8 +313,9 @@ string const typewriter_font_name()
QFont font;
font.setStyleHint(QFont::TypeWriter);
- font.setFamily("monospace");
- return QFontInfo(font).family().latin1();
+ font.setFamily("Courier");
+ const char *x = QFontInfo(font).family().latin1();
+ return x?x:"";
}
}; // namespace lyx_gui
Re: 1.4.0cvs crash
Robin S. Socha wrote: > Alfredo Braunstein <[EMAIL PROTECTED]> writes: >> Robin S. Socha wrote: > >>> Not having used LyX for roughly 18 months, I found the new behaviour >>> quite counter-intuitive. >> >> Could you elaborate? Do you find couter-intuitive the fact that the >> cursor is not placed inside? > > Yes, obviously. I mean, why else would one open an inset except to edit > its contents? Maybe just to see what's inside? Like: "I'm editing here... hmmm let's see what's on the footnote down there... *click* -- now I've lost the position where I was editing... It's more or less like in cursor follows scrollbar vs. doesn't IMO. Sometimes you just want to see something in the document without losing the editing position. Alfredo
Re: Lyx About: license 1995 - 2001 / shouldn't that be 2004?
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Rob Lahaye wrote: >> Sorry, just a rediculous detail. >> >> "Help->About LyX...", License tab. >> >> Doesn't the LyX Team still have the license/copyrights? Angus> Apparently there's no such legal entity as the 'LyX Team'. Angus> I'd suggest changing this: Angus> LyX is Copyright (C) 1995 by Matthias Ettrich, 1995-2001 LyX Angus> Team Angus> to Angus> LyX is Copyright (C) 1995-2004 by the scores of volunteers Angus> listed in the CREDITS file that is distributed with the source Angus> and whose contents are shown in the Credits tab of this dialog. It makes sense, perhaps without the 'scores of volunteers'. JMarc
Re: [patch] corrected file de_math.bind
> "Uwe" == Uwe Stöhr <[EMAIL PROTECTED]> writes: Uwe> Dear developers, some of the key bindings defined in the file Uwe> math.bind could not be used with german keyboards. Uwe> The problem is the meta key "AltGr" on german keyboards. E.g. the Uwe> character "[" is produced with the sequence 'AltGr-[' (or Uwe> 'AltGr-8'). AltGr is the same as 'M-C'. But the bind file defines Uwe> 'M-m S-bracketleft' instead of 'M-m M-C-bracketleft'. Hmm, the bind file uses 'M-m ~S-bracketleft', which basically means "[, with or without shift". From what you say about german keyboards (which is true for french ones too), I would think that \bind "M-m ~C-~M-~S-bracketleft" "math-delim [ ]" will work with both US and German keyboards. Could you try this? If is does work, then there is no need for a de_math.bind. JMarc
Re: [possible patch]: numerical citation fix
Angus Leeming wrote: > Are there any other citation bugs none that I am aware of ATM. Jürgen.
Re: 1.4.0cvs crash
Alfredo Braunstein <[EMAIL PROTECTED]> writes: > Robin S. Socha wrote: >> Not having used LyX for roughly 18 months, I found the new behaviour >> quite counter-intuitive. > > Could you elaborate? Do you find couter-intuitive the fact that the cursor > is not placed inside? Yes, obviously. I mean, why else would one open an inset except to edit its contents? Mind you, I'm taking a user's perspective here (a former Mac user's to make matters worse).
Re: DocBook Export - IDs should not be in anchors, but in the elements
"Jose' Matos" <[EMAIL PROTECTED]> schrieb am 14.05.04 19:13:29: > > I have disabled anchors inside the paragraphs although they there is no > problem with the xml convertion path. Later if needed this could be turned > on only for xml with just one line. > Fine! I will have to test all this but it may take some time - I have to set up a separate chroot environment for this. I will come back on this topic. I hope by "disabled" you don't mean really "erased". The id attribute of the anchor immediately after an element should be brought "inside the element" as an id attribute of the element itself - then you can erase that anchor as it is not needed anymore. I think you must decide how to do this in a "level" that is previous to the one you are doing it now: at the level of parsing the .lyx file and deciding how to export a LyX "token". I think the general rule should be: titles of whatever LyX environments, be it sections, subsections, chapters, tables, figures, equations - whatever, those titles should NOT be exported as sometitle but as PS: Next issue, please. ;-) Don't worry, José - we have a long way in front of us. :-D Did you do the same also for: , , , , , , , and, more generally, for *every* other element? As you see in the title of this thread, I am talking about "elements" not only 's. Thus, it must be: Some table title ... and NOT: Some table title ... The same goes for the other elements accordingly. I think that's enough work for the moment. ;-) Thank you very much for your efforts José - we are building a fantastic application here! Chris -- Regards Chris Karakas http://www.karakas-online.de
Re: Make DVI export with graphics work
Angus Leeming wrote: > Georg Baum wrote: > >> it does not need to be copied either. The only clean solution that I >> can imagine is to introduce a switch in the external template that >> tells wether a file is "input like" or "includegraphics like", >> because the template is the only place where this is known. Any >> other ideas? > > This is a good idea I think. We'd need to find a more obvious naming > scheme for the idea though. You are the native english speaker ;-) I did not find a suitable name, otherwise I would have suggested one! >> Apart from the external inset problem above, is the patch ok? > > Looks good to me. Question: what happens if you run > lyx -e latex foo.lyx > > from the command line and foo.tex exists already. Does checkOverwrite > work as expected? Maybe we should add a '-f' option like 'cp' and > 'mv'? checkOverwrite does nothing in this case, because it only checks the external and graphics inset files (We need a checkOverwrite at several other places too). Furthermore, graphics are not yet converted for latex export, so in this case there is nothing to check. If you do lyx -e dvi foo.lyx and foo.lyx has a graphic, you get: Over-write file? The file /tmp/tex2lyx/41_tmp_c.eps already exists. Do you want to over-write that file? Assuming answer is &Überschreiben Over-write &all &Abbrechen and the file is overwritten, because this is the default button. BTW, I guess there should be a newline after the dashes? Georg
Re: [patch] remove const casts
Georg Baum <[EMAIL PROTECTED]> writes: | diff -p -r -U 4 -X excl.tmp lyx-1.4-clean/src/ChangeLog lyx-1.4-cvs/src/ChangeLog | --- lyx-1.4-clean/src/ChangeLog 2004-05-14 19:53:10.0 +0200 | +++ lyx-1.4-cvs/src/ChangeLog 2004-05-15 12:03:44.0 +0200 | @@ -1,4 +1,18 @@ | +2004-05-15 Georg Baum <[EMAIL PROTECTED]> | + | + * paragraph.C (startTeXParParams): correct column count | + * CutAndPaste.C (pasteSelection): remove const_cast | + * output_docbook.C (docbookParagraphs): remove const_cast | + * output_latex.C (TeXEnvironment, TeXOnePar, TeXDeeper): remove | + const_cast and return ParagraphList::const_iterator | + * output_linuxdoc.C (linuxdocParagraphs): remove const_cast | + * output_plaintext.C (writeFileAscii): remove const_cast | + * paragraph.[Ch] (simpleTeXOnePar): make const | + * paragraph_funcs.C (outerPar): use const iterators | + * paragraph_pimpl.C (validate): use const iterators | + * text.C (setHeightOfRow): use const iterators | + All of these changes look very good to me. -- Lgb
Re: [possible patch]: numerical citation fix
Jürgen Spitzmüller wrote: >> Juergen, can you explain to me what the problem is and how to >> reproduce it? > > You have to switch a document with existing citation insets from > natbib-authoryear to jurabib. Then click on an inset: The style in > the combo is wrong (off by one). Ok. And presumably this should also 'do the right thing' if the citation dialog is open when the engine is changed. Ie, the core should send a message to the citation dialog to refresh the combox contents. If we get this right, then adding support for \footcite et el. will be trivial. And getting the first item in the combox to be [#ID] when using natbib in numerical mode... Are there any other citation bugs or are we moving in the right direction? -- Angus
Re: [possible patch]: numerical citation fix
Angus Leeming wrote: > > which seems to be a qt issue btw. > > Juergen, can you explain to me what the problem is and how to > reproduce it? You have to switch a document with existing citation insets from natbib-authoryear to jurabib. Then click on an inset: The style in the combo is wrong (off by one). Jürgen.
Re: 1.4.0cvs crash
Alfredo Braunstein wrote: > Angus Leeming wrote: > >> Alfredo Braunstein wrote: >>> So the question is: do we want opening an inset to automatically >>> put the cursor inside? Or should we *not* call fitCursor when >>> opening/closing footnotes? (are there other LFUNs that need it)? >> >> I think that we do want to put the cursor inside. > > Could you argument an why do you want it so? It always used to do this and I'm a crusty old bugger who doesn't like change? So, no, not really ;-) We're not M$ after all, so backwards-compatibility for the sake of backwards-compatibility shouldn't be the 'be all and end all'. Do it your way. Much cleaner logically, after all. -- Angus
Re: 1.4.0cvs crash
Robin S. Socha wrote: > Not having used LyX for roughly 18 months, I found the new behaviour > quite counter-intuitive. Could you elaborate? Do you find couter-intuitive the fact that the cursor is not placed inside? If what you find couterintuitive is just the jumping, then of course we agree, but it's a bug (pretty ortogonal issues, they just happend to be related code-wise). Alfredo
Re: 1.4.0cvs crash
Angus Leeming wrote: > Alfredo Braunstein wrote: >> So the question is: do we want opening an inset to automatically put >> the cursor inside? Or should we *not* call fitCursor when >> opening/closing footnotes? (are there other LFUNs that need it)? > > I think that we do want to put the cursor inside. Could you argument an why do you want it so? Alfredo
Re: 1.4.0cvs crash
Robin S. Socha wrote: >>> I think that we do want to put the cursor inside. >> >> I don't think so. Opening is opening and moving the cursor is >> moving the cursor. > > May I humbly comment that currently opening an inset positions the > cursor in the first line of the buffer - and that is > counter-intuitive? CVS checkout as of last afternoon. I don't think that is true, but what happens now is most definitely buggy. For example, place the cursor manually at the very end of a long document, then return to the top of the document using the scrollbar and try and click on (say) a citation inset. (Note that the cursor is still at the end of the document.) There's a strange flash as the screen is redrawn at the current cursor position (I assume) followed by another redraw at the inset location. The dialog is *not* opened. Click on it again and everything behaves as you'd expect. Conclusion: something is not being initialised correctly, causing things to foo-bar the first time the action is invoked. Robin's use-case is just another example of the bug in action. In his case, the second redraw is not triggered. No time to investigate at the moment. -- Angus
Re: 1.4.0cvs crash
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > Angus Leeming <[EMAIL PROTECTED]> writes: >> Alfredo Braunstein wrote: >>> So the question is: do we want opening an inset to automatically >>> put the cursor inside? Or should we *not* call fitCursor when >>> opening/closing footnotes? (are there other LFUNs that need it)? > >> I think that we do want to put the cursor inside. > > I don't think so. Opening is opening and moving the cursor is moving > the cursor. May I humbly comment that currently opening an inset positions the cursor in the first line of the buffer - and that is counter-intuitive? CVS checkout as of last afternoon. Robin
Re: 1.4.0cvs crash
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Alfredo Braunstein wrote: >> So the question is: do we want opening an inset to automatically >> put the cursor inside? Or should we *not* call fitCursor when >> opening/closing footnotes? (are there other LFUNs that need it)? Angus> I think that we do want to put the cursor inside. I don't think so. Opening is opening and moving the cursor is moving the cursor. JMarc
Re: [possible patch]: numerical citation fix
Juergen Spitzmueller wrote: >> > Angus, it works very well. Now only the off-by-one error is still >> > there. >> >> Before we address that one, > > which seems to be a qt issue btw. Juergen, can you explain to me what the problem is and how to reproduce it? > (incidentally, there seem to be > some dispatch problems in xforms; opening the citation dialog from > an inset is a real pain). This is a core problem. It'll get addressed as things come together there. -- Angus
Re: Description of connection between layouts, classes and styles
On Sun, May 16, 2004 at 02:54:03PM +0200, Christian Ridderström spake thusly: > > Hi > > In response to a question on one of the lists, I thought I'd add a quick > description to the wiki of how the file types: .layout, .cls and .sty > relate. It's at this page: > > http://wiki.lyx.org/pmwiki.php/LyX/Concepts > > but my explanation of how they relate isn't coming together very well (ok, > having a hangover doesn't help of course...). Yes, life sucks doesn't it. > Anyway, this is the current > text (in wiki markup): ... > Any help or links would be appreciated. I tried to add my part -- will the better informed please chime in. > /Christian > > -- > Christian Ridderström http://www.md.kth.se/~chr > Martin V pgplbLFRkA5sw.pgp Description: PGP signature
Re: new LFUN?
Angus Leeming wrote: > The patch, attached, defines a new LFUN_INSET_BUTTONLABEL that is > used to force the label to be refreshed. It works perfectly, so is > this Ok to go in or can anyone think of a better way to reach the > same goal? Ok, I renamed it as LFUN_INSET_REFRESH and have committed it. -- Angus
Re: [patch] remove const casts
Georg Baum wrote: > Some time ago when lyx was crashing every second I played a bit with > const_casts. The attached patch exchanges some of them with the use > of const_iterators. It makes also Paragraph::simpleTeXOnePar const. That's great. One of the advantages of moving to the use of an stl container to store the paragraphs is that these const_iterators actually exist. They didn't in the old code because nobody bothered to write them. > > Furthermore I think that this line in Paragraph::startTeXParParams > should be a "+=" instead of a "=": > os << "\\protect"; > column = 8; > > Is this ok, or does somebody have contradicting plans? Go for it. It makes lots of sense. -- Angus
Re: [patch] navigating
Alfredo Braunstein wrote: >> second attempt to have an updateless cursor movement. > > Except that I forgot to restrict it to the few LFUNs that need it. > Third attempt. > > Alfredo Neat! If it works then that is GREAT! -- Angus
Re: Source Code inset?
Andreas Klostermann wrote: > Finally it would be fine to create a box around it stating the file > name and a Description, that is not an Algorithm, Picture or > whatever. Ideally it's the same as plotting a Position out of a FEN > or PNG file in Chess, or like getting a csv/gnumeric table into a > lyx-able form, something I will probably have a lot of uses for in > the future. Is there any documentation about doing this kind of > thing? Or good examples? I hope somebody can tell me the correct mud > puddle to plunge my nose into... (oink). ;-) Have a look at the the External inset and lib/external_templates which this inset uses. It should be easy to add the stuff you are talking about. If you play with the current cvs version (warning *not* for real work yet) then you'll find that the External inset is enormously more powerful than it was in 1.3.x. Feel free to ask any/all questions. -- Angus
Re: Make DVI export with graphics work
Georg Baum wrote: > Am Montag, 10. Mai 2004 15:49 schrieb Angus Leeming: >> > What do you think? Should I use the hack described above and >> > collect the data in latex(), or should I do it in validate(), and >> > how should I pass the files to Exporter::Export()? >> >> However you think it should be done best. > > Here comes the patch, I did it the easy way. It fixes bug 1244, but > has one problem concerning external insets: It copies every file, > even if it is a .tex file and therefore the content is already in > the .dvi file. I am not sure how to solve this. First I thought this > should depend on the format of the converted file (only copy it if > it is some kind of ps), but then it is perfectly legal to input a > .eps file verbatim (maybe in a tutorial about eps), and in this case > it does not need to be copied either. The only clean solution that I > can imagine is to introduce a switch in the external template that > tells wether a file is "input like" or "includegraphics like", > because the template is the only place where this is known. Any > other ideas? This is a good idea I think. We'd need to find a more obvious naming scheme for the idea though. > Apart from the external inset problem above, is the patch ok? Looks good to me. Question: what happens if you run lyx -e latex foo.lyx from the command line and foo.tex exists already. Does checkOverwrite work as expected? Maybe we should add a '-f' option like 'cp' and 'mv'? -- Angus
Re: 1.4.0cvs crash
Angus Leeming <[EMAIL PROTECTED]> writes: > Alfredo Braunstein wrote: >> So the question is: do we want opening an inset to automatically put >> the cursor inside? Or should we *not* call fitCursor when >> opening/closing footnotes? (are there other LFUNs that need it)? > > I think that we do want to put the cursor inside. Not having used LyX for roughly 18 months, I found the new behaviour quite counter-intuitive. On an unrelated subject, I'd like to thank everyone who put so much work into LyX. My SO is using it on her iMac (Debian/GNU ppc, mind you...) and is totally overwhelmed by its power. She's a lawyer (that's why I'm running the CVS version) and very happy with the jurabib support. If I may utter a wish: Better support for jurabib (including \footcite and its friends, see http://www.jurabib.homelinux.org/jurabib/jb-com-ref.html) and possibly jura.cls would be smashing. Kind regards, Robin
Re: Another comment about http://www.devel.lyx.org/cvs.php3
Reuben Thomas wrote: > This entry is rather confusing: > > lyx > This is the unstable development branch, and is not in use anymore. > Use this only if you know want to see in what direction LyX is going > (e.g. the new LyX kernel). Expect this to crash frequently. > > The second and third sentences should be deleted (if I understand > correctly, all current development happens in lyx-devel). Thanks Reuben. Both this and the cvs home page are now changed. May take half an hour or so to become visible. -- Angus
Re: mouse wheel
Alfredo Braunstein wrote: > Scroll with the mouse wheel without "cursor follows scrollbar" is > severely broken in xforms. The qt version works because scroll > doesn't get through LyX dispatch mechanism. Then is a possible solution to prevent the xforms frontend from dispacthing an LFUN? (As in, if it works in the Qt frontend...) > In xforms 1) mouse button 4 & 5 (mouse wheel) open collapsibles > (because they get dispatched to the tip inset before getting > dispatched to LyXText) 2) don't scroll at all (probably because > there's a forced fitCursor at the end of every dispatch). > > Do we need a fitcursor flag in DispatchResult? > > Alfredo -- Angus
Re: Src-specials with lyx?
Timo Carl wrote: > Hello, > > I'm working with lyx for a while now. But I'm missing a feature that > was a great enhancement when I was working with emacs/latex/xdvi: > Using Src-Specials for search/inverse search. > > Is it possible to use this already or do I have to wait for the next > minor release? Currently I'm using 1.3.4 You'll have to wait for lyx 1.4 which is moving towards a feature freeze. Several months to go before it is released though... > Thanks for this great piece of software! Thanks for using it ;-) > Regards, Timo Angus
Re: LyX 1.4.0cvs packages
Ling Li wrote: > Forgot to mention: Currently I "--disable-debug > --disable-assertions" in making the 1.4.0cvs packages. If I remember > correctly (since I disabled them long time ago), the reason to > --disable-debug is that the package size is way too big with debug > info, and the reason to --disable-assertions is that some assertions > are too strict (without them LyX still works). But disabling them > might be inappropriate if the purpose is to get users' feedback. > Please let me know what compiling options should be used. It seems to me that getting the adventurous to use the cvs version without debug info won't be very useful. "I get a core dump" doesn't help much. So, I'd suggest that you should turn off optimization and turn on debugging. Ditto with the assertions. Assertions are triggered by a logic fault. We want them to abort because we want to write the code correctly. -- Angus
Re: 1.4.0cvs crash
Alfredo Braunstein wrote: > So the question is: do we want opening an inset to automatically put > the cursor inside? Or should we *not* call fitCursor when > opening/closing footnotes? (are there other LFUNs that need it)? I think that we do want to put the cursor inside. -- Angus
