Re: What's wrong here?
Allan Rae wrote: > Just because a user can't see the changes wouldn't make it > misleading. Changing to a different class in my experience has always > involved saying "yes" to the question -- when you take a paper for a > conference and want to turn it into a journal article you have to > comply with what the journal wants (so you have to use their > formatting). Not always. E.g. in Germany Separation is "Indent" by Default. If I write a doc and want to have it "Skip" instead for some reason, I differ from default settings. If I decide to use scrarticle instead of article and confirm the question (or use autoreset), Separation is "Indent" again. That's of course not what I want! Same goes for line spacing (this indeed caught me some times in the past before I noticed what this question leeds to). I think it's good to see *what* will be automatically changed before closing the dialog. And the new settings will only be taken if you push "OK" or "Apply", so nothing will go in without user confirmation. IMHO it's good to have this visual control before applying a change. Moreover, with the new "Reset" button you have the additional ability to reset to defaults without changing the class. That was not possible before. > I think the autoreset stuff is just making the interface more > complicated (not quite the word I want... maybe confusing, because > things are happening automatically -- so a warning message would be > useful but then we get back to the annoying little dialog again...) I disagree here too. IMHO "Class Options: Auto Reset" is as clear as it can be and certainly as clear as a message. People might correct me if they think it is confusing. And finally, we will switch autoreset off by default, so nothing happens until the user decides to. Of course, this is just my personal opinion. If people think that this is not clear or confusing, I will certainly try to improve the behaviour. Regards, Jürgen > Allan. (ARRae)
Re: What's wrong here? [w/ PATCH]
Am Freitag, 21. September 2001 09:14 schrieb Allan Rae: > Document it. In NEWS and in whichever user manual Mike thinks fits > best (User Guide? but certainly in the Reference manual). Good idea. I will do (after it is decided that this approach will go in and how). Maybe Mike can tell me where I have to document it... Thanks, Jürgen > Allan. (ARRae)
Re: What's wrong here?
On Fri, 21 Sep 2001, Juergen Spitzmueller wrote: > Allan Rae wrote: > > Just because a user can't see the changes wouldn't make it > > misleading. Changing to a different class in my experience has always > > involved saying "yes" to the question -- when you take a paper for a > > conference and want to turn it into a journal article you have to > > comply with what the journal wants (so you have to use their > > formatting). > > Not always. E.g. in Germany Separation is "Indent" by Default. If I > write a doc and want to have it "Skip" instead for some reason, I > differ from default settings. If I decide to use scrarticle instead of > article and confirm the question (or use autoreset), Separation is > "Indent" again. That's of course not what I want! Same goes for line > spacing (this indeed caught me some times in the past before I noticed > what this question leeds to). I think it's good to see *what* will be > automatically changed before closing the dialog. And the new settings > will only be taken if you push "OK" or "Apply", so nothing will go in > without user confirmation. IMHO it's good to have this visual control > before applying a change. Moreover, with the new "Reset" button you > have the additional ability to reset to defaults without changing the > class. That was not possible before. So the user might notice something changed by a flash of a text input changing or a radio button toggling and wonder: "Did I really see something change? If so, which one was it?" With a warning message or some other feedback they'd know they will get changed entries. As it is we have surprises. Sure, you can argue that the auto reset button is off by default and that it should be clear that something will be automatically reset but think about a newbie and how they will react and how they use software. They/we/I usually don't read manuals until all else fails. They/we/I push buttons blindly hoping that one of them will do what they/we/I want it to do. Even if we can't tell them which entries have changed (or which are about to change) we can at least warn them (or confirm for them) that something did/will change. > > I think the autoreset stuff is just making the interface more > > complicated (not quite the word I want... maybe confusing, because > > things are happening automatically -- so a warning message would be > > useful but then we get back to the annoying little dialog again...) > > I disagree here too. IMHO "Class Options: Auto Reset" is as clear as it > can be and certainly as clear as a message. People might correct me if > they think it is confusing. And finally, we will switch autoreset off > by default, so nothing happens until the user decides to. > > Of course, this is just my personal opinion. If people think that this > is not clear or confusing, I will certainly try to improve the > behaviour. I think I'd be inclinded to just get rid of the auto-reset and let the user push the "class options: reset" button if they really want them reset. Allan. (ARRae)
Re: What's wrong here?
Am Freitag, 21. September 2001 10:12 schrieb Allan Rae: > So the user might notice something changed by a flash of a text input > changing or a radio button toggling and wonder: "Did I really see > something change? If so, which one was it?" > > With a warning message or some other feedback they'd know they will > get changed entries. As it is we have surprises. Sure, you can > argue that the auto reset button is off by default and that it should > be clear that something will be automatically reset but think about a > newbie and how they will react and how they use software. They/we/I > usually don't read manuals until all else fails. They/we/I push > buttons blindly hoping that one of them will do what they/we/I want > it to do. > > Even if we can't tell them which entries have changed (or which are > about to change) we can at least warn them (or confirm for them) that > something did/will change. Well, yes... But a warning message does not solve this IMHO. I can only tell you how I used it as a newbie (not long ago). I always confirmed that question without thinking about the results. I'm too lazy to think about that, and confirming is always the best if you have no idea. I thought something like "yes, of course it has to be reset, otherwise it probably won't work!?" (quite stupid, isn't it?). With the button, *I* would be a little more careful and try to find out what that button's for before activating anything. > I think I'd be inclinded to just get rid of the auto-reset and let > the user push the "class options: reset" button if they really want > them reset. After I knew what Reset to Default means, I began to be very annoyed by the popup. I don't want to be asked over and over again, I hate to repeat myself, I want to decide once. And that's the idea behind the "Autoreset" button. I can decide that class change should always mean "Reset to Default". I tell that once and no question will keep annoying me anymore. I don't have to press "Reset" each and any time. Maybe I'm just lazy, but that's my opinion of efficient working. Personally I'd really miss the autoreset possibility. And do you think that the user will press the "Reset" button more reflected than the "autoreset" checkbox? Or the "Save as Defaults" button (which is *much* more dangerous)? I don't see why this checkbox should be more dangerous than a lot of other checkboxes in LyX. And you can't popup a message on each of this checkbox "Do you really know what you are doing? Read the manual on this button first!", can you? Jürgen (of course there should have been a lot of smileys in this message, but I begin to get used to the rules of this list) > Allan. (ARRae)
A possible patch. Opinions solicited.
From Michael's bug list:
- The spellchecker should ignore ERTs
The patch attached achieves this by modifying LyXText::selectNextWord. A word
is not selected if it is inside an ERT inset.
It's a one-line fix, but I don't know if it's the "right" fix. Perhaps
someone with some knowledge of this part of the code would cast their beady
eyes over it.
Many thanks,
Angus
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.335
diff -u -p -r1.335 ChangeLog
--- src/ChangeLog 2001/09/21 12:11:24 1.335
+++ src/ChangeLog 2001/09/21 13:54:26
@@ -1,3 +1,8 @@
+2001-09-21 Angus Leeming <[EMAIL PROTECTED]>
+
+ * text.C (selectNextWord): do not select words inside an ERT
+ inset.
+
2001-09-21 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* sp_base.h: include
Index: src/text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.187
diff -u -p -r1.187 text.C
--- src/text.C 2001/09/09 22:02:13 1.187
+++ src/text.C 2001/09/21 13:54:26
@@ -2306,10 +2306,12 @@ string const LyXText::selectNextWord(Buf
while ((cursor.par()->size() > cursor.pos()
&& (!cursor.par()->isLetter(cursor.pos()))
&& (!cursor.par()->isInset(cursor.pos()) ||
- !cursor.par()->getInset(cursor.pos())->isTextInset()))
+ !(cursor.par()->getInset(cursor.pos())->isTextInset() &&
+cursor.par()->getInset(cursor.pos())->lyxCode() !=
+Inset::ERT_CODE)))
|| (cursor.par()->size() == cursor.pos()
&& cursor.par()->next()))
- {
+ {
if (cursor.pos() == cursor.par()->size()) {
cursor.par(cursor.par()->next());
cursor.pos(0);
@@ -2319,7 +2321,7 @@ string const LyXText::selectNextWord(Buf
// now check if we hit an inset so it has to be a inset containing text!
if (cursor.pos() < cursor.par()->size() &&
- cursor.par()->isInset(cursor.pos()))
+ cursor.par()->isInset(cursor.pos()))
{
// lock the inset!
cursor.par()->getInset(cursor.pos())->edit(bview);
Re: Qt2 configure fix
On Fri, Sep 21, 2001 at 10:49:43AM +0900, R. Lahaye wrote:
> Yes, I started from scratch:
> --
> make distclean
> ./autogen.sh
> ./configure --with-frontend=qt2 \
> --with-qt2-includes=/usr/X11R6/include/qt2 \
> --with-qt2-libraries=/usr/X11R6/lib
> make
no wonder it didn't work, those files are from the old version of qt2.m4.
Perhaps I sent you the wrong version, please try again with attached.
You can tell it's the new version if "ac_qt2_name" is in config.status afterwards
regards
john
--
"If you're not part of the problem, you're part of the problem space."
# Configure paths and libs when using Qt2 GUI
##-*- shell-script -*-
##Based on KDE file written by :
##Copyright (C) 1997 Janos Farkas ([EMAIL PROTECTED])
## (C) 1997 Stephan Kulow ([EMAIL PROTECTED])
##This file is free software; you can redistribute it and/or
##modify it under the terms of the GNU Library General Public
##License as published by the Free Software Foundation; either
##version 2 of the License, or (at your option) any later version.
##This library is distributed in the hope that it will be useful,
##but WITHOUT ANY WARRANTY; without even the implied warranty of
##MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
##Library General Public License for more details.
##You should have received a copy of the GNU Library General Public License
##along with this library; see the file COPYING.LIB. If not, write to
##the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
##Boston, MA 02111-1307, USA.
AC_DEFUN(QT2_MOC_ERROR_MESSAGE,
[
AC_MSG_ERROR([No Qt meta object compiler (moc) found!
Please check whether you installed Qt correctly.
You need to have a running moc binary.
configure tried to run $ac_cv_path_qt2moc and the test didn't
succeed. If configure shouldn't have tried this one, set
the environment variable MOC to the right one before running
configure.
])
])
AC_DEFUN(QT2_FIND_PATH,
[
AC_MSG_CHECKING([for $1])
AC_CACHE_VAL(qt2_cv_path_$1,
[
qt2_cv_path_$1="NONE"
if test -n "$$2"; then
qt2_cv_path_$1="$$2";
else
dirs="$3"
qt2_save_IFS=$IFS
IFS=':'
for dir in $PATH; do
dirs="$dirs $dir"
done
IFS=$qt2_save_IFS
for dir in $dirs; do
if test -x "$dir/$1"; then
if test -n "$5"
then
evalstr="$dir/$1 $5 2>&1 "
if eval $evalstr; then
qt2_cv_path_$1="$dir/$1"
break
fi
else
qt2_cv_path_$1="$dir/$1"
break
fi
fi
done
fi
])
if test -z "$qt2_cv_path_$1" || test "$qt2_cv_path_$1" = "NONE"; then
AC_MSG_RESULT(not found)
$4
else
AC_MSG_RESULT($qt2_cv_path_$1)
$2=$qt2_cv_path_$1
fi
])
dnl
dnl Find the UIC compiler if available
dnl
AC_DEFUN(QT2_AC_PATH_UIC,
[
QT2_FIND_PATH(uic, UIC, [$ac_qt2_bindir $QTDIR/bin \
/usr/bin /usr/X11R6/bin /usr/lib/qt2/bin \
/usr/local/qt2/bin /usr/local/qt/bin /usr/lib/qt/bin], )
AC_SUBST(UIC)
])
dnl
dnl Find the meta object compiler in the PATH, in $QTDIR/bin, and some
dnl more usual places
dnl
dnl
AC_DEFUN(QT2_AC_PATH_MOC,
[
QT2_FIND_PATH(moc, MOC, [$ac_qt2_bindir $QTDIR/bin \
/usr/bin /usr/X11R6/bin /usr/lib/qt2/bin \
/usr/local/qt2/bin /usr/local/qt/bin /usr/lib/qt/bin],)
QT2_FIND_PATH(moc2, MOC2, [$ac_qt2_bindir $QTDIR/bin \
/usr/bin /usr/X11R6/bin /usr/lib/qt2/bin \
/usr/local/qt2/bin /usr/local/qt/bin /usr/lib/qt/bin],)
if ! test -z "$MOC2"; then
MOC="$MOC2";
fi
if test -z "$MOC"; then
if test -n "$ac_cv_path_qt2moc"; then
output=`eval "$ac_cv_path_qt2moc --help 2>&1 | sed -e '1q' | grep Qt"`
fi
echo "configure:__oline__: tried to call $ac_cv_path_qt2moc --help 2>&1 | sed -e
'1q' | grep Qt" >&AC_FD_CC
echo "configure:__oline__: moc output: $output" >&AC_FD_CC
if test -z "$output"; then
QT2_MOC_ERROR_MESSAGE
fi
fi
AC_SUBST(MOC)
])
AC_DEFUN(QT2_PRINT_PROGRAM,
[
AC_LANG_CPLUSPLUS
cat > conftest.$ac_ext <
#include
int main() {
QMovie m;
m.setSpeed(20);
return 0;
}
EOF
])
##
## Try to find the Qt2 headers and libraries.
## $(QT2_LDFLAGS) will be -Lqt2liblocation (if needed)
## and $(QT2_INCLUDES) will be -Iqt2hdrlocation (if needed)
##
qt2 configure
er, I was talking crap actually, it should be in config.cache you see $ac_qt2_name. Please send me that file too - I cannot understand how QT2_LIBS is empty. You did rm config.cache right ? thanks john -- "If you're not part of the problem, you're part of the problem space."
InsetGraphics update
The graphics inset willl now: * deal correctly with xpm files with a transparent colour. * not display the image if the DisplayType is set to NONE. It does not yet take account of MONOCHROME, GRAYSCALE or COLOR. I assume that this is an XpmAttribute that I can set when calling XpmReadFileToPixmap, but I'll need some help here form my XPM consultants out there! Angus
Re: InsetGraphics update
On Fri, Sep 21, 2001 at 03:31:30PM +0100, Angus Leeming wrote: > It does not yet take account of MONOCHROME, GRAYSCALE or COLOR. > > I assume that this is an XpmAttribute that I can set when calling color_key + XpmColorKey you do know that libXpm has an extensive manual right ? ftp.x.org regards john -- "If you're not part of the problem, you're part of the problem space."
Re: A possible patch. Opinions solicited.
On Friday 21 September 2001 15:41, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> From Michael's bug list: - The spellchecker should ignore ERTs > > Angus> The patch attached achieves this by modifying > Angus> LyXText::selectNextWord. A word is not selected if it is inside > Angus> an ERT inset. > > Angus> It's a one-line fix, but I don't know if it's the "right" fix. > Angus> Perhaps someone with some knowledge of this part of the code > Angus> would cast their beady eyes over it. > > I think it is good enough. Anyway selectNextWord is only used by > spellchecker. It should maybe be renamed to something else, like > selectNextWordToSpellCheck... Good. I'll change the function name and commit. A
Re: InsetGraphics update
On Friday 21 September 2001 15:47, John Levon wrote: > On Fri, Sep 21, 2001 at 03:31:30PM +0100, Angus Leeming wrote: > > > It does not yet take account of MONOCHROME, GRAYSCALE or COLOR. > > > > I assume that this is an XpmAttribute that I can set when calling > > color_key + XpmColorKey > > you do know that libXpm has an extensive manual right ? I didn't, but I do now. Thank you. A
Re: reference dialog locks to reference
On Friday 21 September 2001 16:23, Richard E. Hawkins wrote: > After inserting or modifying a reference with Apply rather than > Close, and then moving the cursor to insert another, the first reference > is modified. This is confusing behavior (and took me a couple of > minutes to figure out. > > > Having to open the dialog each time is "too mousey". Ideally, there > should be a way to insert references of the user's preferred type > purely by key commands. > > hawk So you prefer the way that the citation dialog deals with this problem? It disconnects from the inset having Applied to it. Press Apply again when not connected to any particular inset, and you'll get a new citation reference. You want this behaviour for the referencedialog also? Angus
Re: What's wrong here? [w/ PATCH] (+ Reference manual comment)
Mike weighs in :-) On Fri, 21 Sep 2001, Juergen Spitzmueller wrote: > Am Freitag, 21. September 2001 09:14 schrieb Allan Rae: > > Document it. In NEWS and in whichever user manual Mike thinks fits > > best (User Guide? but certainly in the Reference manual). > > Good idea. I will do (after it is decided that this approach will go in > and how). Maybe Mike can tell me where I have to document it... It should go in the User Guide where File->Open... stuff is discussed. If you like, write up a short description of exactly how it works and what the issues are, and send it to me. I can polish it and insert it appropriately. Note that the Reference manual is officially obsolete, at least in the sense that it is no longer maintained by the documentation team and it no longer appears in the Help menu in LyX. Information useful to a typical user was copied over to other docs; the rest of it was deemed too out of date for redemption. Since it is a document primarily for the developers, the doc team voted unanimously (1-0, with several other concurrences) :-) to leave it to the developers to update it and use it as they see fit. Ideally, it will morph into the document that enthusiastic newbies on the dev team would read to get up to speed. By its nature, though, it has to be maintained by the people who actually write the code, not merely hardcore users like me (who have no clue what "#pragma" means). I suggest, in fact, that it be moved from lyxdoc to perhaps lyx-devel/development or to the Code_rules subdirectory under that. Either way, it will be up to you guys to make something of it, or bury it once and for all. Mike P.S. Note that I committed "final" copies of the Intro and Tutorial a few days ago. Translators should start thinking about gearing up ... Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: reference dialog locks to reference
On Friday 21 September 2001 16:51, [EMAIL PROTECTED] wrote: > I think that's the best way, yes. Done. Check it out. A
Re: DB2LyX release (0.1.4)
On Thu, Sep 20, 2001 at 11:06:44PM +0200, ben wrote: > Here is a minor release, that fixes the following points: > > * Possibility to select the XSLT used by the Makefiles. XT, Xalan and xsltproc are > supported. By default xsltproc is used. Good. > * Some XSL changes so that xsltproc works fine. > * The LyX manual file is changed so that HTML chunking produces files named like the > section ids. Great. I still get a t1.html, to remove it add in Layout->Document->Extra Options id="db2lyx" Ok, ok I'm getting picky, but I like the final result. Really good. > * The doc/ directory doesn't contain the HTML files nor the the out.lyx one, *but* >the > directories remain there for those who want to build the docs, or if we want to > build the files during install. Is it acceptable? Ok. > What is not ready in this release: > * Full 1.2.0 compliance. Let us concentrate on the other points for now. > As usual the package and the diff are available at: > http://perso.libertysurf.fr/bgu/#DB2LyX Got it. > BG When doing make in doc/ I get the errors that are attached. I had changed manually the reference to the xml dtd for docbook. I need to take care that in the make file. I use: rpm -qi libxml2 Name: libxml2 Version : 2.4.3 rpm -qi libxslt Name: libxslt Version : 1.0.3 Any idea what's wrong. (PS: The smiles are on vacations." -- José err.txt.gz
Re: DB2LyX release (0.1.4)
One problem. The content of my catalog file is: -- AUTOMATICALLY GENERATED, DO NOT EDIT -- CATALOG "/usr/share/sgml/entities/iso-entities-8879.1986/iso-entities.cat" CATALOG "/usr/share/sgml/dtd/docbook/3.1/docbook.cat" CATALOG "/usr/share/sgml/stylesheets/docbook/catalog" CATALOG "/usr/share/sgml/dtd/jade/dsssl.cat" CATALOG "/usr/share/sgml/dtd/sgmltools/catalog" CATALOG "/usr/share/sgml/stylesheets/sgmltools/sgmltools.cat" CATALOG /etc/sgml/sgml-docbook-3.0.cat CATALOG /etc/sgml/sgml-docbook-3.1.cat CATALOG /etc/sgml/sgml-docbook-4.0.cat CATALOG /etc/sgml/sgml-docbook-4.1.cat CATALOG /etc/sgml/xml-docbook-4.1.cat in /etc/sgml/catalog, and as you see this is list of catalog files. config_xml doesn't understand this. Is it sgml specific? -- José
Re: What's wrong here?
Am Freitag, 21. September 2001 11:54 schrieb Jean-Marc Lasgouttes: > Juergen> Not always. E.g. in Germany Separation is "Indent" by > Juergen> Default. If I write a doc and want to have it "Skip" instead > Juergen> for some reason, I differ from default settings. If I decide > Juergen> to use scrarticle instead of article and confirm the > question Juergen> (or use autoreset), Separation is "Indent" again. > > Then it is a bug. The settings supposed to be updated are (taken from > BufferParams::useClassDefaults): > > sides = tclass.sides(); > columns = tclass.columns(); > pagestyle = tclass.pagestyle(); > options = tclass.options(); > secnumdepth = tclass.secnumdepth(); > tocdepth = tclass.tocdepth(); And I take it back because I was wrong! Sorry about that. But as you mentioned, the problem is there with columns. Jürgen > JMarc
