Re: New layout for the menus
On Wed, 26 Jul 2000, R. Lahaye wrote: > "Lars Gullik Bjønnes" wrote: > > Yes, the two second learning curve can be pretty hard. > > (what is nicest "Ctrl-x Ctrl-f" or "C-x C-f"?) > > I'm rather addressing "Why is it "M", when all keyboards > I've seen in my entire life say "Alt"? 'M' stands for "Mod1" of "Modifier 1" (X11 keycode) There are two Alt keys on a keyboard. Not all keyboard maps have both Alt keys generating Mod1. If we put Alt in the menu which key do you mean? X11 considers the rightmost Alt key to be called "Alt_gr" (IIRC) Allan. (ARRae)
Re: New layout for the menus
"R. Lahaye" <[EMAIL PROTECTED]> writes: | "Lars Gullik Bjønnes" wrote: | > Yes, the two second learning curve can be pretty hard. | > (what is nicest "Ctrl-x Ctrl-f" or "C-x C-f"?) | | I'm rather addressing "Why is it "M", when all keyboards | I've seen in my entire life say "Alt"? And then why not | use "Shift" and "Ctrl" as well. In a variable width font | it's just a little more space. Why 'M'? That is an emacs (or UNIX) artifact. Unix keyboards usually have both Meta and Alt keys and on PC keyboards meta is often done through alt. I think it would be wrong for us to change this, if only for historical reasons. | I probably once again am swimming against the stream here. | Let me say why: | | Especially for a newbie, LyX is complicated and the | default install is not "newbie-optimized" I believe. And rightly so! Systems that are "newbie-optimized" tend to be "newbie-limited". | I think it would be nice if it was. Keep in mind: | 1) many 2 second learning curves add up to . | 2) people use not only LyX, but also other software If you expect to use a tool (more than 2 sec a day) you must be expected to invest some time in learning to use that tool. Lgb
Re: New layout for the menus
"Lars Gullik Bjønnes" wrote: > Yes, the two second learning curve can be pretty hard. > (what is nicest "Ctrl-x Ctrl-f" or "C-x C-f"?) I'm rather addressing "Why is it "M", when all keyboards I've seen in my entire life say "Alt"? And then why not use "Shift" and "Ctrl" as well. In a variable width font it's just a little more space. I probably once again am swimming against the stream here. Let me say why: Especially for a newbie, LyX is complicated and the default install is not "newbie-optimized" I believe. I think it would be nice if it was. Keep in mind: 1) many 2 second learning curves add up to . 2) people use not only LyX, but also other software Having said this (thank you for reading), I must admit that the design of LyX seems to be extremely configurable (bind and and menu files); though I still have to figure out how to configure my own design :). Regards, Rob.
Re: New layout for the menus
"R. Lahaye" <[EMAIL PROTECTED]> writes: |_New... C-n | | Where does the "C-n" come from? Is that silently added to | the entry? Is there a way to remove it and/or change it? The C-n is the command shortcut. for you probably defined in cua.bind. | Something different: LyX menus (and the documentation) uses "M", | "C" and "S" to address the special keyboard keys. But that is | never printed on the keyboard itself; you'll *always* find "Alt", | "Ctrl" and "Shift". Why not use these obvious names to address | the special keys? I like Netscape, for example, where the | short-cuts are extremely easy to understand! Yes, the two second learning curve can be pretty hard. (what is nicest "Ctrl-x Ctrl-f" or "C-x C-f"?) Lgb
Re: index support
Thomas Henlich <[EMAIL PROTECTED]> writes:
| On the 'LyX Wanted Features list' (http://www.devel.lyx.org/tasks.php3) I
| saw the proposal to implement support for multiple indexes (with the
| 'multind' package).
|
| I think a better suggestion is to use the 'index' package instead.
Yes, remeber that the features list is quite old...and I didn't know
about index.sty when I wrote it. My plan is to use index.sty when I
eventually come around to enhance the index support.
I also have plans to support the lindy(sp?) package (equiv. to
makeindex but much better at sorting other languages than english).
| Apart
| from supporting multiple indexes as well, this package also makes the \index
| command more robust. This has one important effect:
| An index entry like `Übermaß' is written as is to the .idx file
| instead of being expanded to `\"Uberma\IeC {\ss }'. The advantage is that an
| index processing program can sort the first one much easier than the latter
| (unfortunately, makeindex can sort neither properly).
|
| Another interesting feature for LyX would be the support of sub-items in
| index entries and explicit sort keys. Maybe LyX can even automatically
| compute the sort key from the entry, e.g. Übermaß -> Uebermass (or
| Ubermass), so the sorting problem would be solved.
|
| Just some ideas...
Thanks.
Lgb
Re: New layout for the menus
Jean-Marc Lasgouttes wrote:
> Menuset
>
> Menubar "main"
> Submenu "File|F" "file"
> Submenu "Edit|E" "edit"
[...]
> Menu "file"
> Item "New...|N" "buffer-new"
[snip]
This File->New menu item, for example, looks on my
screen as ("_N" is an "underlined N"):
_New... C-n
Where does the "C-n" come from? Is that silently added to
the entry? Is there a way to remove it and/or change it?
When I ran LyX from the default CVS compilation/installation,
I've got the following non-fatal messages at startup:
MenuItem(): LyX command `screen-options' does not exist.
MenuItem(): LyX command `spellchecker-options' does not exist.
MenuItem(): LyX command `keyboard-options' does not exist.
MenuItem(): LyX command `options-preferences' does not exist.
What I hope is that these entries are under construction; to
merge all options entries into one single "preferences" window?
Am I right, or is something else going wrong here?
Something different: LyX menus (and the documentation) uses "M",
"C" and "S" to address the special keyboard keys. But that is
never printed on the keyboard itself; you'll *always* find "Alt",
"Ctrl" and "Shift". Why not use these obvious names to address
the special keys? I like Netscape, for example, where the
short-cuts are extremely easy to understand!
Regards,
Rob.
Shift keys in the current menu style
Hi, I've just uploaded CVS with the new style menus (in default.ui). I go a little crazy by the Shift- menu list popups. When I type in the lyx text "I'm Frank Donut", I automatically get the insert, file and document lists when typing Shift-i, Shift-f and Shift-d for the capitals. Everytime this happens I lose focus in my text and have to first click away the menu list. All this did not happen with an earlier version of CVS. I hope there's something wrong with my settings? However, if this is the new default behaviour, it has to be changed. Regards, Rob.
Menubar bugs
Jean-Marc, the new system looks pretty impressive. I guess I've found a couple bugs, though. Apologies if they've already been mentioned and I didn't notice because I didn't get the latest update yet. (1) I added Icon "buffer-export latex" to my .lyx/ui/my.ui file. I got a core dump. So I changed it to "buffer-export_latex" (i.e, s/ /_/). Now I get Toolbar::add: no LyX command called`buffer-export_latex'exists! when I start LyX. But the run_LaTeX button shows up in the toolbar, and works. (It probably doesn't make any difference, but this happens whether I've got NEW_MENUS defined or not.) (2) I'll note that I haven't updated since Jun 6, so I can't guarantee that this problem is new. When I start LyX, I get: LyX: Couldn't allocate 'linen' for background with (r,g,b)=(64250,61680,59110). Using closest allocated color with (r,g,b)=(65535,65535,57568) instead. Pixel [12] is used. LyX: Couldn't allocate 'RoyalBlue' for special char with (r,g,b)=(16705,26985,57825). Using closest allocated color with (r,g,b)=(18247,18247,50115) instead. Pixel [18] is used. LyX: Couldn't allocate 'grey40' for bottom of button with (r,g,b)=(26214,26214,26214). Using closest allocated color with (r,g,b)=(26471,26471,26471) instead. Pixel [29] is used. LyX: Couldn't allocate 'grey40' for right of button with (r,g,b)=(26214,26214,26214). Using closest allocated color with (r,g,b)=(26471,26471,26471) instead. Pixel [29] is used. The weird thing is that I think one time that I ran LyX, it didn't give me this complaint. Is this a known problem? -Amir
Re: New layout for the menus
On Tue, Jul 25, 2000 at 01:48:00PM +0100, Jose Abilio Oliveira Matos wrote: > On Tue, Jul 25, 2000 at 02:25:52PM +0200, Jean-Marc Lasgouttes wrote: > [...] > > BTW, Jose', why is it necessary to have three different html export > > types? I' think the "export html" function could be clever enough to > > do the right thing... > > You are right, since I have the buffer I can simply do > > If I patch that what are the place that I should change? > That is, what are the places where you have used it. You don't need to make these changes as I am rewriting the export code, and the new code will do the correct thing when "buffer-export html" is dispatched.
when we get spammed
Just a reminder: please do not respond to the spam messages this list gets from time to time---unless you know what you are doing. I promptly deal with each of these messages (reporting them at appropriate places), and usually you put your own email address in danger if you try to handle spam yourself. Thx Mate
Re: Language: portugues, not portuges
On Tue, Jul 25, 2000 at 06:54:09PM +0100, Jose Abilio Oliveira Matos wrote: > > > > Or even a symlink (potugues->protuges) > > Kayvan you have done two error in the same line. :) That takes talent! > I think that your example was (portugues->portuges) fortunatelly > he are not very sensitive (you were lucky it is not friday yet) regarding > people who misspell our language name. :) > > BTW we write (say) "português"... Have I been clear? ;-) I spell guud! -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Language: portugues, not portuges
On Tue, Jul 25, 2000 at 09:08:57AM -0700, Kayvan A. Sylvan wrote: > > > > BTW, nothing prevents you from having a dictionary named "portugues". I > > have been doind that in Slackware Linux, Solaris and FreeBSD for the last > > two years. > > Or even a symlink (potugues->protuges) Kayvan you have done two error in the same line. :) I think that your example was (portugues->portuges) fortunatelly he are not very sensitive (you were lucky it is not friday yet) regarding people who misspell our language name. :) BTW we write (say) "português"... Have I been clear? ;-) -- José
LyX Development News for July
The latest LDN is now available: http://www.lyx.org/news/2726.php3 No point summarizing it for you, just go and read it ;-) Allan. (ARRae)
index support
On the 'LyX Wanted Features list' (http://www.devel.lyx.org/tasks.php3) I
saw the proposal to implement support for multiple indexes (with the
'multind' package).
I think a better suggestion is to use the 'index' package instead. Apart
from supporting multiple indexes as well, this package also makes the \index
command more robust. This has one important effect:
An index entry like `Übermaß' is written as is to the .idx file
instead of being expanded to `\"Uberma\IeC {\ss }'. The advantage is that an
index processing program can sort the first one much easier than the latter
(unfortunately, makeindex can sort neither properly).
Another interesting feature for LyX would be the support of sub-items in
index entries and explicit sort keys. Maybe LyX can even automatically
compute the sort key from the entry, e.g. Übermaß -> Uebermass (or
Ubermass), so the sorting problem would be solved.
Just some ideas...
--
Thomas Henlich
Re: Language: portugues, not portuges
Hello, # > > this patchlet sets the Portuguese language name to "portugues" rather # > > than "portuges", as it is now. With this fix, spelling works correctly # > > in Portuguese documents; otherwise, it doesn't (linux 2.2.15, Debian # > > "potato", ispell 3.1.20 with "portugues" dictionary). # > # > Will not this break things in non-Debian systems? For historical reasons, # > LaTeX ever used "portuges" instead of "portugues" (probablly to deal with Oops? I thought I had stumbled upon a typo. So it is better not to apply my patch, in case it breaks other things. Nothing at first sight, but who knows. # > the 8.3 filename limitation of some operating systems). For similar # > reasons it uses "brazil" instead of "brasil" as we spell here. # > # > BTW, nothing prevents you from having a dictionary named "portugues". I # > have been doind that in Slackware Linux, Solaris and FreeBSD for the last # > two years. # # Or even a symlink (potugues->protuges) That sounds a good solution. I used to specify the dictionnary before running the spellchecker. Another would be dissociating LaTeX language name and dictionnary name. That's harder, I guess. Thank you for the feedback, Etienne
Re: Problem compiling current cvs
Amir Karger <[EMAIL PROTECTED]> writes: | cvs updated 3 hours ago (9:30 am EDT). Gets through a bunch of stuff but | then: | | g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -isystem | /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall | -Wno-return-type -pedantic -Wp,-MD,.deps/insetinclude.pp -c insetinclude.C | -o insetinclude.o | insetinclude.C: In function `class string unique_id()': | insetinclude.C:205: request for member `c_str' in `ost.ostrstream::str()', | which is of non-aggregate type `char *' | insetinclude.C:206: warning: control reaches end of non-void function | `unique_id()' try again. Lgb
Problem compiling current cvs
cvs updated 3 hours ago (9:30 am EDT). Gets through a bunch of stuff but then: g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -isystem /usr/X11R6/include -g -O -fno-rtti -fno-exceptions -ansi -W -Wall -Wno-return-type -pedantic -Wp,-MD,.deps/insetinclude.pp -c insetinclude.C -o insetinclude.o insetinclude.C: In function `class string unique_id()': insetinclude.C:205: request for member `c_str' in `ost.ostrstream::str()', which is of non-aggregate type `char *' insetinclude.C:206: warning: control reaches end of non-void function `unique_id()' -Amir
CVS insetinclude.C problem
Current CVS won't compile on my machine due to a problem with insets/insetinclude.C : in line 205, ost.str() was changed to ost.str().c_str(). In my system, (HAVE_SSTREAM undefined), ost.str() already returns char*, and the code won't compile. I think the following is the correct fix. Lior. PS: Apologies for the set_color bug. I dumbly copied code without trying to understand how it should work. Index: insetinclude.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetinclude.C,v retrieving revision 1.34 diff -u -u -r1.34 insetinclude.C --- insetinclude.C 2000/07/25 10:46:17 1.34 +++ insetinclude.C 2000/07/25 16:09:33 @@ -195,14 +195,14 @@ #ifdef HAVE_SSTREAM std::ostringstream ost; ost << "file" << ++seed; + return ost.str().c_str(); #else char ctmp[16]; ostrstream ost(ctmp,16); ost << "file" << ++seed << '\0'; + return ost.str(); #endif - // Needed if we use lyxstring. - return ost.str().c_str(); }
Re: Language: portugues, not portuges
> > BTW, nothing prevents you from having a dictionary named "portugues". I > have been doind that in Slackware Linux, Solaris and FreeBSD for the last > two years. Or even a symlink (potugues->protuges) -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Language: portugues, not portuges
On Tue, 25 Jul 2000, Etienne Grossmann wrote: > this patchlet sets the Portuguese language name to "portugues" rather > than "portuges", as it is now. With this fix, spelling works correctly > in Portuguese documents; otherwise, it doesn't (linux 2.2.15, Debian > "potato", ispell 3.1.20 with "portugues" dictionary). Will not this break things in non-Debian systems? For historical reasons, LaTeX ever used "portuges" instead of "portugues" (probablly to deal with the 8.3 filename limitation of some operating systems). For similar reasons it uses "brazil" instead of "brasil" as we spell here. BTW, nothing prevents you from having a dictionary named "portugues". I have been doind that in Slackware Linux, Solaris and FreeBSD for the last two years. -- Carlos A. M. dos Santos Federal University of Pelotas Meteorological Research Center Av. Ildefonso Simoes Lopes 2791 Pelotas, RS, Brasil, CEP 96060-290 WWW: http://www.cpmet.ufpel.tche.br RENPAC (X.25): 153231641 Phone: +55 53 277-6767FAX: +55 53 277-6722
[Robin Fairbairns ] faq response to question "can i use tex wysiwyg?"
We need to reply to this one. Jean-Marc, Allan? Could you hava a look? Lgb i maintain the uk tex users' group faq, and i reckon it's about time it made mention of lyx and similar things. (the question typically asked is that in the subject line above, but we need not worry about fine details ... the faq is supposed to be pragmatic ;-) would anyone on this list (perhaps one of the lyx development team?) care to offer some text for me to start with? the reason i ask is i'm not a lyx user myself, but would nevertheless like to offer good advice to users of the faq. the thing is currently to be found in http://www.tex.ac.uk/cgi-bin/texfaq2html?introduction=yes i'ld be adding the proposed question in the section on support packages. note: i'm not currently subscribed to this list, so shan't see answers unless they're explicitly cc'ed to me. i shan't be offended if no-one does so, but then i shan't be able to add mention of lyx to the faq either. robin fairbairns
Re: New layout for the menus
Allan Rae <[EMAIL PROTECTED]> writes: | Then leave them out of the menu. It's likely to be a week before I get | around to removing the other ones anyway. And 1.1.6 is probably going to | be out before then. 1.1.6 in a week? Are you kidding? We need to have at least one prerelease first... Lgb
LyX crash
Using current CVS with all new whistles compiled, I can crash LyX by loading up the Help->TOC document. Anyone else see this? Specifically, if you have current CVS without NEW_INSETS, NEW_TABULAR defined and can/can't crash LyX please tell! This document loads fine with CVS of 19 July. Angus
Re: New layout for the menus
On 25 Jul 2000, Jean-Marc Lasgouttes wrote: > > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: > > Allan> Ahh. I misunderstood your cvslog posting. Those are currently > Allan> called directly from within the menu code (Menu?? callback) so > Allan> I guess you should add a lyxfunc for them that simply calls > Allan> whatever function in lyx_cb.C builds them. Then as I get > Allan> Preferences working I'll remove them again ;-) Oh and I don't > Allan> think options-preferences is the write name. It should be > Allan> lyx-preferences since it is a global scope dialog. I don't > Allan> think we should use the menu structure to name the lyxfuncs. > > I did not want to introduce function for something that was go away a > few days later. That's why I prefer to let you devise you own plans > (especially for 1.1.6, for which I want working menus). Then leave them out of the menu. It's likely to be a week before I get around to removing the other ones anyway. And 1.1.6 is probably going to be out before then. > Allan> BTW, I know you core-devvies are out there. When are you blokes > Allan> going to check my new LDN out for errors so I can unleash it on > Allan> the world? > > It is funnier to point out obvious errors afterwards:) Hmm, OK, let's > see... You could mention Herbert Voss' tips page > http://www.educat.hu-berlin.de/~voss/Informatik/LyXTips.html > > Also, on non-smiley day, one is allowed to say bad things even if they > are not justified (or true). That's much more funny this way:) Sssh not so loud. Someone might be listening and you'd give away all the LDN secrets! Allan. (ARRae)
Re: GTK/Gnome frontend elementary support
On Tue, 25 Jul 2000, Juergen Vigna wrote: > Well I guess that gtk is a ONLY C library and so does not compile with > a c++ compiler (only a guess but I already had such problems on linking!) > Why don't you test only for gtk-- as you need that one? That's a good point. We can use gtk--/gnome-- only as it is now, but I am not sure whether gnome-- covers libgnome functionality completely. Since all the scripts seems to be working now we may either leave as it is or remove unnecessary scripts. However, if we will need anything directly from gnome libraries we should add these scripts later. Both solutions should work. To check it, I've removed GNOME_INIT, GNOME_COMPILE_WARNINGS, GNOME_X_CHECKS from configure.in file, leaved only config/gnome/gtk--.m4 and config/gnome/gnome--.m4 in autogen.sh script and everything configured/compiled just fine. Marko
lyx ftp
Wasn't there supposed to be a lyx.stable.gz or lyx.latest.gz link on the ftp site that links to the latest stable tar? Speaking of which, the web site should be linking to 1.1.5fix1 right now. Actually, I think we should set up index.php3 to automatically link to the latest version (and mention what it is). It's pretty easy, right - we just split the number, then look for the highest major number, minor number, minorminor number, and fix number (if any). Once we switch to the new numbering system, it'll be even easier. We would still want to have a lyx.latest.gz at the ftp site, in case people don't go there from the web, but it would make it less of a problem if lars forgot to update the lyx.latest softlink for a while. Sound like a good idea? -Amir
Re: GTK/Gnome frontend elementary support
On 25 Jul 2000, Jean-Marc Lasgouttes wrote: > Yes, you should comment out the AC_LANG_C at line 89 of configure.in. AC_TRY_RUN compiles gtk program with C++ compiler instead of C compiler. That's why environment variable CFLAGS doesn't have any effect (see line 58, file config/gnome/gtk.m4). If we add line CXXFLAGS="$CXXFLAGS $GTK_CFLAGS" after line 58 then this test is passed. Marko
Language: portugues, not portuges
Hello,
this patchlet sets the Portuguese language name to "portugues"
rather than "portuges", as it is now. With this fix, spelling works
correctly in Portuguese documents; otherwise, it doesn't (linux
2.2.15, Debian "potato", ispell 3.1.20 with "portugues" dictionary).
Patch is against 1.1.5.
Cheers, and thanks for the continuing good work with LyX,
Etienne
==
--- src/language.C.2000.07.25 Tue Jul 25 09:56:06 2000
+++ src/language.C Tue Jul 25 09:56:22 2000
@@ -80,7 +80,7 @@
{ "magyar", N_("Magyar"), false },
{ "norsk", N_("Norsk"), false },
{ "polish", N_("Polish"), false },
- { "portuges", N_("Portuges"), false },
+ { "portugues", N_("Portugues"), false },
{ "romanian", N_("Romanian"), false },
{ "russian", N_("Russian"), false },
{ "scottish", N_("Scottish"), false },
==
Re: GTK/Gnome frontend elementary support
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: Marko> On 25 Jul 2000, Jean-Marc Lasgouttes wrote: >> Yes, I understand. But which one is it? And what is the error >> message in config.log? Marko> I've checked out the latest version from cvs and everything Marko> worked fine! GTK, gnome, gtkmm, gnomemm were configured without Marko> any errors. Thus, it is hard for me to reproduce the problem. Yes, you should comment out the AC_LANG_C at line 89 of configure.in. JMarc
Re: New layout for the menus
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes: Jose> On Tue, Jul 25, 2000 at 01:48:00PM +0100, Jose Abilio Oliveira Jose> Matos wrote: >> The other choice is you to do it.;) >> Jose> I have been unable to update the cvs code. The connection is Jose> extremely slow. And it breaks during the update stage. OK, I'll try to do it this evening. JMarc
Re: New layout for the menus
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> Ahh. I misunderstood your cvslog posting. Those are currently Allan> called directly from within the menu code (Menu?? callback) so Allan> I guess you should add a lyxfunc for them that simply calls Allan> whatever function in lyx_cb.C builds them. Then as I get Allan> Preferences working I'll remove them again ;-) Oh and I don't Allan> think options-preferences is the write name. It should be Allan> lyx-preferences since it is a global scope dialog. I don't Allan> think we should use the menu structure to name the lyxfuncs. I did not want to introduce function for something that was go away a few days later. That's why I prefer to let you devise you own plans (especially for 1.1.6, for which I want working menus). Allan> BTW, I know you core-devvies are out there. When are you blokes Allan> going to check my new LDN out for errors so I can unleash it on Allan> the world? It is funnier to point out obvious errors afterwards:) Hmm, OK, let's see... You could mention Herbert Voss' tips page http://www.educat.hu-berlin.de/~voss/Informatik/LyXTips.html Also, on non-smiley day, one is allowed to say bad things even if they are not justified (or true). That's much more funny this way:) JMarc
Re: GTK/Gnome frontend elementary support
On 25 Jul 2000, Jean-Marc Lasgouttes wrote: > Yes, I understand. But which one is it? And what is the error message > in config.log? I've checked out the latest version from cvs and everything worked fine! GTK, gnome, gtkmm, gnomemm were configured without any errors. Thus, it is hard for me to reproduce the problem. Marko
Re: New layout for the menus
> Hmmm, to me this looks like every entry is designed as a sort of > failsafe: > if you hit the wrong entry you still can do what you wanted to do. These properties of the commands are good. We should not remove these. Let me explain why. Yes, it's possible to create a new document with the "Open" command, but if you try, you'll be warned that you are creating a new document. This is not a problem - this is proper handling of a potential error situation. Similarly, if you try to create an existing document, you will be asked whether you want to open the existing one. This is proper handling of a potentially dangerous situation. I find it hard that this should be confusing. I think it would be much more confusing if LyX just silently overwrote existing documents or just failed with a stupid error message, such that you have to close the dialog, renavigate the menus, select "Open" instead of New, renavigate to the proper spot in the file system, and then cross your fingers that you can open the document. What if the document is already open? What should happen? IMHO LyX should offer to reload the already open document, offer to switch to it, and offer to cancel. And, hey, this is what it does. Should we also remove this error handling? These are all situations where LyX for once is more clever than most of the existing alternatives. We should not remove this cleverness, just because it *seems* inconsistent. It is *not* inconsistent. IMO it's an error to think that a command should do *only* what the name implies, and nothing more. It's much better that the command is robust in the grey areas, and offers to do what you would logically want in these border line cases. Compare with the behaviour when you save a document under a new name. When you do that, lots of strange things can happen in the cases where there is an existing file, where you already have another document open with the same name, different combinations there of, and so on. You should try to do it, and then you'll hopefully realize that the behaviour LyX has in this area is much better than just the raw implication of "If I say Save As, I mean save as no matter what." LyX handles these grey borderline cases in a robust and clever way. We should not remove this extra logic in the name of "cleaning up the menus", because cleaning is not the same as crippling. Yes, normally cleaning implies "remove redudant stuff", but in this case, these features are NOT redudant. They are proper handling of border line cases, and the fact that we have this robust handling is a certain PLUS for LyX, not a minus. Greets, Asger
Re: New layout for the menus
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes: Jose> If I patch that what are the place that I should change? That Jose> is, what are the places where you have used it. What you have to change is MenuExport() (of course), but also the conditional code in LyXFunc::getStatus (look for "case LFUN_EXPORT:"). I'll take care of the rest (which is lib/ui/defaults.ui). Jose> The other choice is you to do it.;) I do not have any sgml tools installed, so I cannot really test... JMarc
Re: New layout for the menus
On Tue, Jul 25, 2000 at 01:48:00PM +0100, Jose Abilio Oliveira Matos wrote: > > The other choice is you to do it.;) > I have been unable to update the cvs code. The connection is extremely slow. And it breaks during the update stage. -- José
Re: set_color documentation mistake
> "Lior" == Lior Silberman <[EMAIL PROTECTED]> writes: Lior> When documenting the \set_color lyxrc command I forgot that Lior> strings in lyxrc must be enclosed in quotes. I thus put in a Lior> misleading example. No that's the code which is wrong. I commited a correction. JMarc
Re: New layout for the menus
On 25 Jul 2000, Jean-Marc Lasgouttes wrote: > Juergen> MenuItem(): LyX command `screen-options' does not exist. > Juergen> MenuItem(): LyX command `spellchecker-options' does not > Juergen> exist. MenuItem(): LyX command `keyboard-options' does not > Juergen> exist. > Juergen> MenuItem(): LyX command `options-preferences' does not exist. > > I do not have lyxfuncs for those, and I am waiting to see what Allan > will come up with. Ahh. I misunderstood your cvslog posting. Those are currently called directly from within the menu code (Menu?? callback) so I guess you should add a lyxfunc for them that simply calls whatever function in lyx_cb.C builds them. Then as I get Preferences working I'll remove them again ;-) Oh and I don't think options-preferences is the write name. It should be lyx-preferences since it is a global scope dialog. I don't think we should use the menu structure to name the lyxfuncs. BTW, I know you core-devvies are out there. When are you blokes going to check my new LDN out for errors so I can unleash it on the world? Allan. (ARRae)
Re: New layout for the menus
On Tue, Jul 25, 2000 at 02:25:52PM +0200, Jean-Marc Lasgouttes wrote: [...] > BTW, Jose', why is it necessary to have three different html export > types? I' think the "export html" function could be clever enough to > do the right thing... You are right, since I have the buffer I can simply do if(buffer.isLatex()) . else if (buffer.isLinuxDoc()) . else if (buffer.isDocBook()) . else ERROR The first time I have seen this I didn't notice that. If I patch that what are the place that I should change? That is, what are the places where you have used it. The other choice is you to do it.;) > JMarc -- José
Re: Proposal for new features
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> Hi, one of my students made a proposal for improving the Michael> usefulness of Lyx. What he would like to see is the ability Michael> to hide/unhide single sections of a document, i.e. if you do Michael> not want to edit a particular section you can simply make it Michael> invisible such that you Michael> - neither make changes accidentally - nor have to scroll Michael> through large texts. Once our new textinsets are used all over, it will not be difficult to make a 'container' inset, which just serves this purpose. Also, it could be possible to make a container which hides its content. JMarc
Re: GTK/Gnome frontend elementary support
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: >> Could you show us this small program? It might be that it uses a >> valid C syntax that is not valid C++. These things are easy to fix >> in general. Marko> I mean the program used inside the script (gtk.m4) for checking Marko> GTK libraries installation. Yes, I understand. But which one is it? And what is the error message in config.log? JMarc
Re: New layout for the menus
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> MenuItem(): LyX command `external-inset-insert' does not Juergen> exist. Fixed. Juergen> MenuItem(): LyX command `screen-options' does not exist. Juergen> MenuItem(): LyX command `spellchecker-options' does not Juergen> exist. MenuItem(): LyX command `keyboard-options' does not Juergen> exist. Juergen> MenuItem(): LyX command `options-preferences' does not exist. I do not have lyxfuncs for those, and I am waiting to see what Allan will come up with. JMarc
Re: New layout for the menus
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: >> With the new OptItem scheme I will commit soon, it will be easy to >> add All the locking inset menu entries in the menu, and only the >> one which makes sense will be shown. Does it sound good to you? >> Juergen> How is this supposed to work? I would only need 1 entry for Juergen> accessing an eventually existing inset->layout->popup. You add to the menu: OptItem "Table" "table-layout" OptItem "MyOtherItem" "myotheritem-layout" Since the function table layout is disable outside of a table, it will only appear if you are inside a table! As a practical example, have a look at the File->Export menu, and see how it changed depending on whether the current document is Latex or LinuxDoc or DoocBook. The code is simply: Menu "export" OptItem "as LaTeX|L" "buffer-export latex" OptItem "as LinuxDoc|L" "buffer-export linuxdoc" OptItem "as DocBook|B" "buffer-export docbook" Item "as DVI|D" "buffer-export dvi" Item "as Postscript|P" "buffer-export postscript" Item "as Ascii|A" "buffer-export ascii" OptItem "as HTML|H" "buffer-export html" OptItem "as HTML|H" "buffer-export html-linuxdoc" OptItem "as HTML|H" "buffer-export html-docbook" OptItem "Custom...|C" "buffer-export custom" End And there is code in LyXFunc::getStatus() which tells when a function is disabled. BTW, I need a lyxfunc for Edit->Table :) BTW, Jose', why is it necessary to have three different html export types? I' think the "export html" function could be clever enough to do the right thing... Juergen> BTW.: The toolbar now works :), but the Insert Menu does not Juergen> display and gives: Juergen> ERROR:create_submenu: Unknown menu `floats' Error in Juergen> MenuCallback That was a typo. should be fixed now. JMarc
Proposal for new features
Hi, one of my students made a proposal for improving the usefulness of Lyx. What he would like to see is the ability to hide/unhide single sections of a document, i.e. if you do not want to edit a particular section you can simply make it invisible such that you - neither make changes accidentally - nor have to scroll through large texts. Hey, wouldn't that be nice? Michael PS: Please send any replies to [EMAIL PROTECTED] -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Re: The new Toolbar and Menubar.
JMarc> Angus, add to your .cvsrc the magic line: JMarc> update -dP JMarc> Then all these problems will be history! Many thanks for the tip, JMarc. A
Re: GTK/Gnome frontend elementary support
> Could you show us this small program? It might be that it uses a > valid C syntax that is not valid C++. These things are easy to fix in > general. I mean the program used inside the script (gtk.m4) for checking GTK libraries installation. Marko
Re: New layout for the menus
> > ERROR:create_submenu: Unknown menu `floats' > Error in MenuCallback > I get also: MenuItem(): LyX command `external-inset-insert' does not exist. MenuItem(): LyX command `screen-options' does not exist. MenuItem(): LyX command `spellchecker-options' does not exist. MenuItem(): LyX command `keyboard-options' does not exist. MenuItem(): LyX command `options-preferences' does not exist. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You're never too old to become younger. -- Mae West
Re: GTK/Gnome frontend elementary support
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: Marko> Well, it seems that script gtk.m4 fails to compile a small gtk Marko> program with AC_LANG_CPLUSPLUS. When I inserted AC_LANG_C Marko> before AC_TRY_RUN (gnome/gtk.m4, line 65) and AC_LANG_CPLUSPLUS Marko> at the end of this script, the program was compiled. However, Marko> the configure script produced slightly different Makefile (one Marko> CPPFLAGS option was missing). Thus, to resolve this problem one Marko> needs to run AC_TRY_RUN with AC_LANG_C and somehow keep the Marko> configuration of AC_LANG_CPLUSPLUS. I don't know how to do it. Could you show us this small program? It might be that it uses a valid C syntax that is not valid C++. These things are easy to fix in general. JMarc
Re: New layout for the menus
> > With the new OptItem scheme I will commit soon, it will be easy to add > All the locking inset menu entries in the menu, and only the one which > makes sense will be shown. Does it sound good to you? > How is this supposed to work? I would only need 1 entry for accessing an eventually existing inset->layout->popup. BTW.: The toolbar now works :), but the Insert Menu does not display and gives: ERROR:create_submenu: Unknown menu `floats' Error in MenuCallback Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "Pay no attention to the man behind the curtain." -- The Wizard Of Oz
Re: GTK/Gnome frontend elementary support
On 25-Jul-2000 Marko Vendelin wrote: > > Well, it seems that script gtk.m4 fails to compile a small gtk program > with AC_LANG_CPLUSPLUS. When I inserted AC_LANG_C before AC_TRY_RUN Well I guess that gtk is a ONLY C library and so does not compile with a c++ compiler (only a guess but I already had such problems on linking!) Why don't you test only for gtk-- as you need that one? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ An intellectual is someone whose mind watches itself. -- Albert Camus
Re: GTK/Gnome frontend elementary support
> We certinly need the AC_LANG_CPLUSPLUS, since otherwise checks for the > C++ compilers features are done with the C compiler :) I put it back > in, and added an AC_LANG_CPLUS_PLUS later. > > In general, configuring with AC_LANG_CPLUS_PLUS would be better, since > we will compile with the C++ compiler. If the gnome scripts are broken > with C++, they should be fixed. What are the errors? I cannot test, > since I do not have gnome installed here. Well, it seems that script gtk.m4 fails to compile a small gtk program with AC_LANG_CPLUSPLUS. When I inserted AC_LANG_C before AC_TRY_RUN (gnome/gtk.m4, line 65) and AC_LANG_CPLUSPLUS at the end of this script, the program was compiled. However, the configure script produced slightly different Makefile (one CPPFLAGS option was missing). Thus, to resolve this problem one needs to run AC_TRY_RUN with AC_LANG_C and somehow keep the configuration of AC_LANG_CPLUSPLUS. I don't know how to do it. > PS: Marko, are you on the lyx-devel list? yes, almost for an hour already :). Marko
Re: GTK/Gnome frontend elementary support
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: Marko> I see! The attached tar.gz and small patch to autogen.sh adds 1 Marko> .m4 script (config/gnome/gtk.m4). I've tried to generate Marko> configure script with minimal amount of files in Marko> /usr/share/aclocal and it worked now in my system. Sorry for Marko> the mess. I have found one in the meantime and can confirm that this work. I will comit soon. JMarc
Re: The new Toolbar and Menubar.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Looking in lib/ I see that there is no ui/ directory so typing Angus> cvs update -d causes a new file to be uploaded Angus> lib/scripts/fen2latex.py but then the update terminates with Angus> cvs [update aborted]: cannot open CVS/Entries.Log: No such file Angus> or directory Angus, add to your .cvsrc the magic line: update -dP Then all these problems will be history! JMarc
Re: Toolbar does not work anymore!
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 24-Jul-2000 Jean-Marc Lasgouttes wrote: >> It may be an update problem (the buttons are disabled when there >> is no buffer, except for new and open, but may not be re-enabled >> later). Do you have a custom toolbar? Juergen> Yes I have a custom toolbar! But the buttons are not enabled Juergen> from the beginning (after loading the first file). OK, I have a fix for this. JMarc
Re: New layout for the menus
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> I would insert here (inseted of TabularLayout) something like Juergen> TheLockingInset (find a better name but that is Juergen> what it shoud do) Juergen> we then need a function in the insets which tells us if Juergen> the_locking_inset has a layout-window or not and so we can Juergen> activate this on the actual locking inset's layout menu! With the new OptItem scheme I will commit soon, it will be easy to add All the locking inset menu entries in the menu, and only the one which makes sense will be shown. Does it sound good to you? JMarc
Re: tables typo?
> "Lior" == Lior Silberman <[EMAIL PROTECTED]> writes: Lior> My guess is that is was supposed to be an int (and not int*), so Lior> I suggest the enclosed fix. I commited it yesterday. JMarc
Re: GTK/Gnome frontend elementary support
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | Finally, to make configure script working I had to disable | Lars> AC_LANG_CPLUSPLUS in configure.in (line 66). Otherwise gnome Lars> configuration | scripts were not working properly. It will be Lars> very nice if someone with | good knowledge of configure.in magic Lars> would take a look on this | problem. Lars> Jean-Marc, can you have a cursory glance at this? I am not sure Lars> if we even need the AC_LANG_CPLUSPLUS there. We certinly need the AC_LANG_CPLUSPLUS, since otherwise checks for the C++ compilers features are done with the C compiler :) I put it back in, and added an AC_LANG_CPLUS_PLUS later. In general, configuring with AC_LANG_CPLUS_PLUS would be better, since we will compile with the C++ compiler. If the gnome scripts are broken with C++, they should be fixed. What are the errors? I cannot test, since I do not have gnome installed here. JMarc PS: Marko, are you on the lyx-devel list?
Re: GTK/Gnome frontend elementary support
> I do have all this files, but I think you have some gtkxxx.m4 files in > your /usr/share/aclocal (or whereever) directory, that got installed > when installing gtk. A simple check: grep AM_PATH_GTK > config/gnome/*.m4 reveals that this macro is used there, but never > defined. I see! The attached tar.gz and small patch to autogen.sh adds 1 .m4 script (config/gnome/gtk.m4). I've tried to generate configure script with minimal amount of files in /usr/share/aclocal and it worked now in my system. Sorry for the mess. Marko patch.gtk.m4.add.gz config.gnome.tar.gz
Re: GTK/Gnome frontend elementary support
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: Marko> Please check, whether you have these directories in your local Marko> copy and whether autogen.sh script contains a huge line with Marko> "for fil in config/lyxinclude.m4 config/libtool.m4 Marko> config/gettext.m4 config/lcmessage.m4 config/progtest.m4 Marko> config/sigc++.m4 config/kde.m4 confi g/gnome/aclocal-include.m4 Marko> config/gnome/gnome-print-check.m4 ..." I do have all this files, but I think you have some gtkxxx.m4 files in your /usr/share/aclocal (or whereever) directory, that got installed when installing gtk. A simple check: grep AM_PATH_GTK config/gnome/*.m4 reveals that this macro is used there, but never defined. JMarc
Re: GTK/Gnome frontend elementary support
Hi, > It seems that we miss an .m4 file which defines AM_PATH_GTK (and > probably others). It is now impossible for me to compile for xforms, > since the configure file produced by autoconf is plain wrong... I've obtained a fresh copy of lyx-devel this morning (cvs checkout) and at least xforms frontend works fine here. Current cvs should contain new directories config/gnome src/frontend/gtk Please check, whether you have these directories in your local copy and whether autogen.sh script contains a huge line with "for fil in config/lyxinclude.m4 config/libtool.m4 config/gettext.m4 config/lcmessage.m4 config/progtest.m4 config/sigc++.m4 config/kde.m4 confi g/gnome/aclocal-include.m4 config/gnome/gnome-print-check.m4 ..." Marko
Re: GTK/Gnome frontend elementary support
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes: Marko> the attached patch together with additional files included into Marko> the .tar.gz archive adds elementary support for GTK/Gnome Marko> frontend: configure scripts, Gtk/Gnome initialization, Gnome Marko> event loop processing, and Copyright dialog box implementation. Marko> It should be easy to use this code on the platform with good Marko> STL string implementation. In such case you need standard gtk, Marko> gnome, libsigc++ , gtk-- and gnome-- libraries. Hello, It seems that we miss an .m4 file which defines AM_PATH_GTK (and probably others). It is now impossible for me to compile for xforms, since the configure file produced by autoconf is plain wrong... Could you send us the files? JMarc
Re: can't compile!
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> With latest cvs I get the following error messages with Angus> autogen.sh Building macros... aclocal: configure.in: 0: macro Angus> `AM_PATH_GTK' not found in library aclocal: configure.in: 0: Angus> macro `AM_PATH_GTK' not found in library done. Building config Angus> header template... And indeed I cannot find it anywhere in the config directory. Where is it?? JMarc
can't compile!
With latest cvs I get the following error messages with autogen.sh Building macros... aclocal: configure.in: 0: macro `AM_PATH_GTK' not found in library aclocal: configure.in: 0: macro `AM_PATH_GTK' not found in library done. Building config header template... /usr/local/GNU/bin/autoheader: Symbol `GTKGUI' is not covered by /usr/local/GNU/share/autoconf/acconfig.h /usr/local/GNU/bin/autoheader: Symbol `KDEGUI' is not covered by /usr/local/GNU/share/autoconf/acconfig.h done. Building Makefile templates... src/Makefile.am:13: variable `SIGC_LIBS' not defined automake: src/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/mathed/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/insets/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' src/support/Makefile.am:11: USE_LYXSTRING does not appear in AM_CONDITIONAL src/support/Makefile.am:14: USE_REGEX does not appear in AM_CONDITIONAL automake: src/support/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/frontends/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/frontends/xforms/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/frontends/kde/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' automake: src/frontends/gtk/Makefile.am: C++ source seen but `CXX' not defined in `configure.in' done. Building configure... autoconf: Undefined macros: configure.in:12:AC_VALIDATE_CACHE_SYSTEM_TYPE configure.in:68:AC_DISABLE_SHARED configure.in:69:AC_LIBTOOL_WIN32_DLL done. Building lib/configure ... done. Creating POTFILES.in... done run "./configure ; make"
Re: New layout for the menus
On 24-Jul-2000 Lars Gullik Bjønnes wrote: > > I don't agree. And you _have_ managd with a popuå on both items in > several years now. > So why not extend this with 5 other popups so we just have a little more options to select from when creating just a dummy document to try new stuff! Jürgen P.S.: Well I guess everybody can make himself his most welcome menu so the discussion is just fruitless I just will make myself a "New..." AND a "New from Template..." menu button! -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Our problems are so serious that the best way to talk about them is lightheartedly.
