Re: More eye candy
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes: Juergen I remember the KLyX icons to be rather ugly. What about Juergen those: Juergen http://mailbox.univie.ac.at/Reinhard.Stepanek/lyx/lyx_artwork_icons.html Yes, why not use these for 1.2.0? Except that I cannot guess what the icon to the right of TeX means :) JMarc
Re: Package Manager
John Levon wrote: sure, but before the second step is the first one ... ;-) sure. here it is: http://www.perce.de/lyx/package.gif puts the selected package at the end of the list, so you can get any order of the list. This is a trivial method, a better one is to put it with a mouseclick anywhere in the list. ah, right. You might consider having up / down arrows like citation does ... good idea Herbert -- http://www.lyx.org/help/
Re: More eye candy
On Mon, Mar 25, 2002 at 09:53:12AM +0100, Jean-Marc Lasgouttes wrote:
Yes, why not use these for 1.2.0? Except that I cannot guess what the
icon to the right of TeX means :)
It does not matter... isn't 1.2.0 some mysterious release?
So having mysterious icons, too, does not sound inappropriate...
Andre'
PS: baywatch still down ;-{
--
André Pönitz .. [EMAIL PROTECTED]
Re: More eye candy
John == John Levon [EMAIL PROTECTED] writes: John also, I need a name for each icon that can be shown in qt when John the toolbar is too wide... oh, and some moving around of John setPixmap to be GUII (I'll do that soon in my guii tree) Yes, the plan was to have names for the toolbars. This allows for having a math or tabular toolbar which appears when the core requests it. John As for menubar, it needs a /total/ overhaul I think. It /might/ John be possible to get the current version working with Qt, but it's John a real struggle. Here's a few of the things I want : John 1. shortcuts available (how does xforms do this ? haven't looked John ...) xforms queries the binding from toplevel_keymap. The way it is displayed in the menu is by using Tabs. For Qt, you may have to use a different trick. John 2. open_by_name makes little sense for Qt, it can handle it John already (probably qt can just continue to ignore this) The only place where this is used is the binding lib/bind/emacs.bind:\bind C-x C-bmenu-open documents I think we can get rid of it, especially since it will not work with non-english interface. John 3. the on-demand menu creation. This is a real pain for Qt. John Rather I would like expand() to work at Menubar_pimpl John constructor (I already have this, sort of), and provide some John signals to connect to so we can know whether to update the John special menus You do not have to do menu creation on demand. You are free to implement menus as you see fit. The only constraint is that you have to make sure before a menu is open that all items are disabled/toggled, etc. as needed. So anyway, you have to do _some_ work before showing a menu. Also, you can probably ignore the table of contents stuff for now, since we will have to fold it into menubackend in some way. My idea currently would be to provide an iterator on menu structure which would do the unfolding as needed. John 4. probably a lot of other things. I found the way you have to John parse the menu structure was a bit confusing ... What do you mean? John I don't know if the main main_nobuffer technique is really best. Feel free to propose something else. We could also decide that we do not need a different menu set when there is no document. John The menu stuff and the scrollbar are the only things really John remaining to do for the Qt thing to happen nicely I think. It has always been clear to me that this stuff will need cleanups to be usable to the other toolkits. However, it was difficult to guess those cleanups without knowing how those toolkits operate. What is the typical Qt way of handling menus like those of LyX? JMarc
Re: publicity
John == John Levon [EMAIL PROTECTED] writes: John http://www.advogato.org/article/447.html John Linux Format is reasonably widely read in the UK, it would be John good if we could ask for John a) beta-testers for pre1 (if we can time it right) John b) qt/gnome developers interested in GUII (and of course, trick John them into doing other lyx development too ;) I think b) is the most important. For beta testers, I prefer people who already use LyX. JMarc
Re: make install failing
Garst == Garst R Reese [EMAIL PROTECTED] writes: Garst sed: can't read xfonts/fonts.dir: No such file or directory What does ls -l lib/xfonts say? Did lib/configure get run? JMarc
Re: section etc. short titles
John == John Levon [EMAIL PROTECTED] writes: John wha t are the plans to allow users to specify a short title for John the benefit of header/footer for Section etc. ?? This is definitely something we need (also for captions). Unfortunately the plans for that are not yet clear. My preferred choice would be a collapsable inset that one can insert in some layouts. But this is not a perfect solution, of course. JMarc
Re: More eye candy
On Mon, Mar 25, 2002 at 10:08:01AM +0100, Jean-Marc Lasgouttes wrote: John also, I need a name for each icon that can be shown in qt when John the toolbar is too wide... oh, and some moving around of John setPixmap to be GUII (I'll do that soon in my guii tree) Yes, the plan was to have names for the toolbars. This allows for having a math or tabular toolbar which appears when the core requests it. no, I mean each /button/ needs a name. Also we want to be able to specify whether a toolbar should be horizontal, vertical, t,b,l,r too... We already have NewLine, so we just need to be a bit more flexible. Qt frontend can already make the standard toolbar vertical (but it looks a bit silly) xforms queries the binding from toplevel_keymap. The way it is displayed in the menu is by using Tabs. For Qt, you may have to use a different trick. Ah, I see it. I can do that too. The only place where this is used is the binding lib/bind/emacs.bind:\bind C-x C-bmenu-open documents I think we can get rid of it, especially since it will not work with non-english interface. great. You do not have to do menu creation on demand. You are free to implement menus as you see fit. This does not appear to be true, in particular for the view/update dynamic menu, currently I must wait for a buffer before I can get my data. The only constraint is that you have to make sure before a menu is open that all items are disabled/toggled, etc. as needed. So anyway, you have to do _some_ work before showing a menu. I don't think this is a good thing. I'm not even sure it can be done reliably in Qt, and I'd rather not try ;) John 4. probably a lot of other things. I found the way you have to John parse the menu structure was a bit confusing ... What do you mean? it just confused me :) I'm dumb ... Feel free to propose something else. We could also decide that we do not need a different menu set when there is no document. ISTR the problem is that you can't disable an entire menu in xforms, right ? It has always been clear to me that this stuff will need cleanups to be usable to the other toolkits. However, it was difficult to guess those cleanups without knowing how those toolkits operate. Of course, please don't take my comments as criticism. I'm amazed by how well most of lyx has held up under a Qt world. What is the typical Qt way of handling menus like those of LyX? I don't really know, I've never written a Qt application before ... What I think I would like to see is something like a MenuBackend Menu_pimpl::somethingChanged(SpecialType t) then the pimpl can do .expand(t) to get the current list of special entries. This can be ignored by xforms (since it will do expand at each menu open anyway) but can be used by qt (and gnome, if it makes sense) regards john p.s. I have fixed scrollbar for Qt ... now I need to refix all the xforms stuff I've broken ;) -- Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy. - John Hasler [EMAIL PROTECTED]
Re: binding for protected blank
John == John Levon [EMAIL PROTECTED] writes: John The menus say C-S-Space generates a protected blank but it is John actually just C-Space ... It is supposed to be C-space in emacs mode and C-S-space in cua mode. What bindings do you use? JMarc
Re: binding for protected blank
On Mon, Mar 25, 2002 at 10:22:43AM +0100, Jean-Marc Lasgouttes wrote: It is supposed to be C-space in emacs mode and C-S-space in cua mode. What bindings do you use? cua. Both variants work (thankfully). It's a very minor problem as a result, if it is even a problem. regards john -- Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy. - John Hasler [EMAIL PROTECTED]
Re: More eye candy
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Mon, Mar 25, 2002 at 09:53:12AM +0100, Jean-Marc Lasgouttes Andre wrote: Yes, why not use these for 1.2.0? Except that I cannot guess what the icon to the right of TeX means :) Andre It does not matter... isn't 1.2.0 some mysterious release? So Andre having mysterious icons, too, does not sound inappropriate... In normal 1.1.6, this icon stands for maths... But now, I cannot see what it means. JMArc
Re: binding for protected blank
John == John Levon [EMAIL PROTECTED] writes: John On Mon, Mar 25, 2002 at 10:22:43AM +0100, Jean-Marc Lasgouttes John wrote: It is supposed to be C-space in emacs mode and C-S-space in cua mode. What bindings do you use? John cua. Both variants work (thankfully). I think C-S-Space is what word uses, that's why cua.bind does that. The fact that C-space works too is due to some brilliant (not) trick from Lars. JMarc
Re: section etc. short titles
On Mon, Mar 25, 2002 at 10:19:11AM +0100, Jean-Marc Lasgouttes wrote: This is definitely something we need (also for captions). Unfortunately the plans for that are not yet clear. My preferred choice would be a collapsable inset that one can insert in some layouts. But this is not a perfect solution, of course. Hmm, maybe we could make Chapter etc. a borderless hidden inset, and have a context menu / whatever where you can set the short title ? I suppose eventually we want that to happen anyway, to avoid all this label gook in text.C, right ? regards john -- Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy. - John Hasler [EMAIL PROTECTED]
Re: Do you want a Porto (or the next LyX meeting)
On 23-Mar-2002 Lars Gullik Bjønnes wrote: The next LyX meeting will be here in Porto (Portugal), from 13 to 18 of June. (2002 of course :-) All LyX users and developers are invited. | Thank you, and I'll be there! | I hope lots and lots of others will join us! Me too, that would be really fun. Well another me too (if nothing bad happens ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You can't cheat the phone company.
Re: More eye candy
Jean-Marc Lasgouttes wrote: In normal 1.1.6, this icon stands for maths... But now, I cannot see what it means. AFAIK it's an abacus (or slide rule or how do you math guys call that?) Juergen. JMArc
Re: More eye candy
On Mon, Mar 25, 2002 at 11:08:58AM +0100, Juergen Spitzmueller wrote: Jean-Marc Lasgouttes wrote: In normal 1.1.6, this icon stands for maths... But now, I cannot see what it means. AFAIK it's an abacus (or slide rule or how do you math guys call that?) I think you missed the compliment to Andre in JMarc's joke :) john -- Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy. - John Hasler [EMAIL PROTECTED]
Re: More eye candy
John Levon wrote: I think you missed the compliment to Andre in JMarc's joke :) Oh bugger. I hate monday mornings ;-) Juergen. john
Re: section etc. short titles
John == John Levon [EMAIL PROTECTED] writes: John On Mon, Mar 25, 2002 at 10:19:11AM +0100, Jean-Marc Lasgouttes John wrote: This is definitely something we need (also for captions). Unfortunately the plans for that are not yet clear. My preferred choice would be a collapsable inset that one can insert in some layouts. But this is not a perfect solution, of course. John Hmm, maybe we could make Chapter etc. a borderless hidden John inset, and have a context menu / whatever where you can set the John short title ? The problem is to know where in the UI you set this title. Until we are able to insert an insettext in a dialog (do we really want to do that), the text has to be in the main UI. That's why I proposed a collapsable inset. John I suppose eventually we want that to happen anyway, to avoid all John this label gook in text.C, right ? What label gook? JMarc
Re: Do you want a Porto (or the next LyX meeting)
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 23-Mar-2002 Lars Gullik Bjønnes wrote: The next LyX meeting will be here in Porto (Portugal), from 13 to 18 of June. (2002 of course :-) All LyX users and developers are invited. | Thank you, and I'll be there! | I hope lots and lots of others will join us! Me too, that would be really fun. Juergen Well another me too (if nothing bad happens ;) As I already told Jose', I will unfortunately not be able to come. JMarc
Re: binding for protected blank
On 25-Mar-2002 Jean-Marc Lasgouttes wrote: John == John Levon [EMAIL PROTECTED] writes: John The menus say C-S-Space generates a protected blank but it is John actually just C-Space ... It is supposed to be C-space in emacs mode and C-S-space in cua mode. What bindings do you use? Well I always used cua mode and there I inserted protected spaces always with C-Space so maybe it is in emacs mode? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The difference between America and England is that the English think 100 miles is a long distance and the Americans think 100 years is a long time.
Re: section etc. short titles
On 25-Mar-2002 Jean-Marc Lasgouttes wrote: John Hmm, maybe we could make Chapter etc. a borderless hidden John inset, and have a context menu / whatever where you can set the John short title ? The problem is to know where in the UI you set this title. Until we are able to insert an insettext in a dialog (do we really want to do that), the text has to be in the main UI. That's why I proposed a collapsable inset. But it could be a collapsable insets with 2 InsetText's. One for entering the short title and one for entering the long one. We actually display only one of the two and give a dialog to switch between the 2 (like in ERT we swith between the different view-modes. That would permit to insert the short AND long one in the LyXView, but you get only one displayed at a time. I think this is a good compromise, don't you? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ BYTE editors are people who separate the wheat from the chaff, and then carefully print the chaff.
Re: Do you want a Porto (or the next LyX meeting)
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Juergen == Juergen Vigna [EMAIL PROTECTED] writes: | Juergen On 23-Mar-2002 Lars Gullik Bjønnes wrote: The next LyX meeting will be here in Porto (Portugal), from 13 to 18 of June. (2002 of course :-) All LyX users and developers are invited. | Thank you, and I'll be there! | I hope lots and lots of others will join us! Me too, that would be really fun. | Juergen Well another me too (if nothing bad happens ;) | As I already told Jose', I will unfortunately not be able to come. Pity, pity. But, it would've been really fun if some of the new developers could afford the trip. On another note, I am not going to look for sponsors this year. But if someone else have got some contacts that would be willing to help us a bit, we will certainly gracefully accept. -- Lgb
Re: section etc. short titles
On Mon, Mar 25, 2002 at 11:11:27AM +0100, Jean-Marc Lasgouttes wrote: The problem is to know where in the UI you set this title. Until we are able to insert an insettext in a dialog (do we really want to do that), This would be nice for other things. Like defining math macros. The current behaviour (having them as part of the main text) is neither nice nor safe.. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Do you want a Porto (or the next LyX meeting)
On Mon, Mar 25, 2002 at 11:11:58AM +0100, Jean-Marc Lasgouttes wrote: Juergen Well another me too (if nothing bad happens ;) As I already told Jose', I will unfortunately not be able to come. Shame on you. Why not? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: section etc. short titles
On Mon, Mar 25, 2002 at 11:17:28AM +0100, Juergen Vigna wrote: That would permit to insert the short AND long one in the LyXView, but you get only one displayed at a time. I think this is a good compromise, don't you? Sounds very sensible. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Do you want a Porto (or the next LyX meeting)
On Mon, Mar 25, 2002 at 11:18:02AM +0100, Lars Gullik Bjønnes wrote: But, it would've been really fun if some of the new developers could afford the trip. How far is Porto from 'mid-Germany' (no map around, sorry...)? Is this do-able by car or is going by plane a must? Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Do you want a Porto (or the next LyX meeting)
Andre Poenitz wrote: On Mon, Mar 25, 2002 at 11:18:02AM +0100, Lars Gullik Bjønnes wrote: But, it would've been really fun if some of the new developers could afford the trip. How far is Porto from 'mid-Germany' (no map around, sorry...)? Is this do-able by car or is going by plane a must? by ship is also possible, via Duisburg, Rotterdam ;-) Herbert -- http://www.lyx.org/help/
Re: binding for protected blank
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 25-Mar-2002 Jean-Marc Lasgouttes wrote: John == John Levon [EMAIL PROTECTED] writes: John The menus say C-S-Space generates a protected blank but it is John actually just C-Space ... It is supposed to be C-space in emacs mode and C-S-space in cua mode. What bindings do you use? Juergen Well I always used cua mode and there I inserted protected Juergen spaces always with C-Space so maybe it is in emacs mode? No, but Lars has added code that tries to remove S from a kbd sequence if it cannot be found. Therefore C-S-space is magically found as C-space also. I thik this trick is stupid, but... Anyway, if everybody thinks C-space would be a better binding, we can certainly add it. JMarc
Re: Do you want a Porto (or the next LyX meeting)
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Mon, Mar 25, 2002 at 11:11:58AM +0100, Jean-Marc Lasgouttes Andre wrote: Juergen Well another me too (if nothing bad happens ;) As I already told Jose', I will unfortunately not be able to come. Andre Shame on you. Why not? Because I'm going to have a brand new baby in may and I will be playing with my new toy for a number of weeks. Next year, if I got bored with her, I promise I'll come. JMarc
Re: Do you want a Porto (or the next LyX meeting)
On Mon, Mar 25, 2002 at 11:54:04AM +0100, Jean-Marc Lasgouttes wrote: Andre Shame on you. Why not? Because I'm going to have a brand new baby in may and I will be playing with my new toy for a number of weeks. Next year, if I got bored with her, I promise I'll come. Ah gee... just tell UPS they should deliver in July, not in May. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: Do you want a Porto (or the next LyX meeting)
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre Ah gee... just tell UPS they should deliver in July, not in Andre May. You see, as with all fresh products, there is a best before date. And no, frozen is not an option [*] JMarc [*] shaken is not either, but that's a different story
Re: section etc. short titles
On 25-Mar-2002 Andre Poenitz wrote: On Mon, Mar 25, 2002 at 11:17:28AM +0100, Juergen Vigna wrote: That would permit to insert the short AND long one in the LyXView, but you get only one displayed at a time. I think this is a good compromise, don't you? Sounds very sensible. Well Lars your comment about me being culpable of getting double mail because I set the Reply-To header seems bogus, as it seems it's the same now that I removed that one!!! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The pyramid is opening! Which one? The one with the ever-widening hole in it! -- The Firesign Theatre
Re: section etc. short titles
Juergen Vigna [EMAIL PROTECTED] writes: | On 25-Mar-2002 Andre Poenitz wrote: On Mon, Mar 25, 2002 at 11:17:28AM +0100, Juergen Vigna wrote: That would permit to insert the short AND long one in the LyXView, but you get only one displayed at a time. I think this is a good compromise, don't you? Sounds very sensible. | Well Lars your comment about me being culpable of getting double mail | because I set the Reply-To header seems bogus, as it seems it's the same | now that I removed that one!!! Perhaps, but no the reason is the answerers lazyness. btw. I have setup my reader to ignore Reply-To: in this group and also to always only answer to the mailinglist address. Gnus is bliss. -- Lgb
Re: section etc. short titles
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Juergen Vigna [EMAIL PROTECTED] writes: | | On 25-Mar-2002 Andre Poenitz wrote: On Mon, Mar 25, 2002 at 11:17:28AM +0100, Juergen Vigna wrote: That would permit to insert the short AND long one in the LyXView, but you get only one displayed at a time. I think this is a good compromise, don't you? Sounds very sensible. | | Well Lars your comment about me being culpable of getting double mail | | because I set the Reply-To header seems bogus, as it seems it's the same | | now that I removed that one!!! | Perhaps, but no the reason is the answerers lazyness. now | btw. I have setup my reader to ignore Reply-To: in this group and also | to always only answer to the mailinglist address. Gnus is bliss. -- Lgb
Re: section etc. short titles
On Mon, Mar 25, 2002 at 12:28:33PM +0100, Juergen Vigna wrote: Sounds very sensible. Well Lars your comment about me being culpable of getting double mail because I set the Reply-To header seems bogus, as it seems it's the same now that I removed that one!!! It is more sensible to be quiet up if people accuse you of making sensible proposals Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: section etc. short titles
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars btw. I have setup my reader to ignore Reply-To: in this group Lars and also to always only answer to the mailinglist address. Gnus Lars is bliss. What about bug reporters which are not on the list? What I did is remove a list of known people from To/Cc, and set up gnus on my side to delete duplicates. Therefore I do not suffer from others' laziness. JMarc
Additional argument to math macros
The macro _definitions_ on screen have now an additional cell. If this is kept empty, nothing else changes. Completely compatible to what we had before etc. If it is not empty, however, the contents of this second cell will be used as template for the drawing on screen whereas the contents of the first cell still serves as a template for the export to .tex and everything else. [And no, this was no 'enh' marked item on the bugtracker but rather a means to get food on Saturdays ;-)] Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: section etc. short titles
Juergen == Juergen Vigna [EMAIL PROTECTED] writes: Juergen On 25-Mar-2002 Jean-Marc Lasgouttes wrote: What I did is remove a list of known people from To/Cc, and set up gnus on my side to delete duplicates. Therefore I do not suffer from others' laziness. Juergen The net does however, doesn't it? Yes, but the net is sober enough to suffer in silence. JMarc
Re: section etc. short titles
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars btw. I have setup my reader to ignore Reply-To: in this group | Lars and also to always only answer to the mailinglist address. Gnus | Lars is bliss. | What about bug reporters which are not on the list? I add them manually. Or use 'R', that works most of the time. | What I did is remove a list of known people from To/Cc, and set up | gnus on my side to delete duplicates. Therefore I do not suffer from | others' laziness. Oh, I do that as well... I have both procmail and gnus deleting duplicates. -- Lgb
Re: section etc. short titles
Juergen Vigna [EMAIL PROTECTED] writes: | On 25-Mar-2002 Jean-Marc Lasgouttes wrote: What I did is remove a list of known people from To/Cc, and set up gnus on my side to delete duplicates. Therefore I do not suffer from others' laziness. | The net does however, doesn't it? Depends on how clever the mail server is. -- Lgb
fonts_as_insets.diff
André, did you mean this to become part of the repository? I see that mathed actually contains it's contents already. Angus
Re: listerrors followup
Kayvan == Kayvan A Sylvan [EMAIL PROTECTED] writes: Kayvan Hi Jean-Marc, Here is my latest followup to the listerrors Kayvan fixes. Hello Kayvan, I was away last week. Kayvan If you have not already done so, please apply this. Kayvan The backward-porting is important since many people don't have Kayvan python-2.2 installed as /usr/bin/python. I'll apply that. Kayvan The converter.C patch is important to allow people who have Kayvan the setting parselog=listerrors in their build-program Kayvan convertor to find listerrors without having to set an Kayvan additional path element outside of LyX. This would mean that Kayvan the listerrors change has no user-visible impact. I have some code in the tree that should work fine. I'll have a look tonight. I do not want to modifiy the path because I am not very sure of our implmentation of PutEnv on all architectures. Moreover, the solution I used in converter.C is simpler and looks also in .lyx and in the build directory. JMarc
Re: Additional argument to math macros
On Mon, Mar 25, 2002 at 12:27:17PM +, Angus Leeming wrote:
[And no, this was no 'enh' marked item on the bugtracker but rather a
means to get food on Saturdays ;-)]
Give us an example of this in use.
Say you want a macro \def\myrel{\mathrel\something} that behaves
properly, i.e. exports to LaTeX as \mathrel\something, but displays
nicely on screen.
Currently you could
(a) really put it the \mathrel into the macro. This exports nicely, but
shows a red 'mathrel' everywhere the macro is used, or
(b) use dirty tricks like putting just \something in the macro
definition and fix the export by putting a
\def\myrel{\mathrel\something} immediately afterwards in ERT.
Not really nice.
Now you can just put '\mathrel\somiething' in the first cell (the 'export
cell') and '\something' into the second cell (the 'display cell') and
both export and display just work.
If you don't need the feature, just leave the second box empty and nothing
will change.
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
Re: fonts_as_insets.diff
On Mon, Mar 25, 2002 at 12:58:35PM +, Angus Leeming wrote: André, did you mean this to become part of the repository? I see that mathed actually contains it's contents already. Argh... no... this should go to my 'private repository of half-baked patches'... Sorry. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: fonts_as_insets.diff
On Monday 25 March 2002 12:59 pm, Andre Poenitz wrote: On Mon, Mar 25, 2002 at 12:58:35PM +, Angus Leeming wrote: André, did you mean this to become part of the repository? I see that mathed actually contains it's contents already. Argh... no... this should go to my 'private repository of half-baked patches'... Sorry. ;-) Note that mathed now tries to compile math_fontinset.C which actually isn't in the repository but is in your diff ... Perhaps you'd care to add math_fontinset.[Ch]. Angus
Re: fonts_as_insets.diff
On Monday 25 March 2002 1:12 pm, Angus Leeming wrote: On Monday 25 March 2002 12:59 pm, Andre Poenitz wrote: On Mon, Mar 25, 2002 at 12:58:35PM +, Angus Leeming wrote: André, did you mean this to become part of the repository? I see that mathed actually contains it's contents already. Argh... no... this should go to my 'private repository of half-baked patches'... Sorry. ;-) Note that mathed now tries to compile math_fontinset.C which actually isn't in the repository but is in your diff ... Perhaps you'd care to add math_fontinset.[Ch]. Sorry that's remove math_fontinset.[Ch from Makefile.am !!! Angus
Re: fonts_as_insets.diff
On Mon, Mar 25, 2002 at 01:12:57PM +, Angus Leeming wrote: Perhaps you'd care to add math_fontinset.[Ch]. I removed them from Makefile.am... Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: compile success and a config patch
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Ok, Lars, I've finally got there. I had to tweak my configure Angus script so that CPP=deccxx -E, or I couldn't find ostream etc. Angus I also upgraded to automake 1.5, autoconf 2.52, although I'm Angus not sure that that was strictly necessary. (I did this before Angus finding the CPP fix.) Finally, I had to patch lyxinclude.m4; Angus attached. Concerning you patch to depcomp: it seems that automake 1.6 has fixes in depcomp for tru64 unix. You may want to upgrade to that and update depcomp in lyx sources. Your tweak for CPP is not needed if you configure with CC=deccxx. The bug in AC_CHECK_FUNCS is indeed an autoconf bug that I reported a few monthes ago, but I got no answer. The message is archived at http://mail.gnu.org/pipermail/autoconf/2001-November/011992.html Looking at cvs, I would say that this may be fixed in autoconf 2.53. Could you try that? JMarc
Re: compile success and a config patch
On Monday 25 March 2002 1:29 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Ok, Lars, I've finally got there. I had to tweak my configure Angus script so that CPP=deccxx -E, or I couldn't find ostream etc. Angus I also upgraded to automake 1.5, autoconf 2.52, although I'm Angus not sure that that was strictly necessary. (I did this before Angus finding the CPP fix.) Finally, I had to patch lyxinclude.m4; Angus attached. Concerning you patch to depcomp: it seems that automake 1.6 has fixes in depcomp for tru64 unix. You may want to upgrade to that and update depcomp in lyx sources. I'll have a look. Your tweak for CPP is not needed if you configure with CC=deccxx. I do that too and can state that I found that it _was_ needed to find those 4 cxx header files, ostream etc. The bug in AC_CHECK_FUNCS is indeed an autoconf bug that I reported a few monthes ago, but I got no answer. The message is archived at http://mail.gnu.org/pipermail/autoconf/2001-November/011992.html Looking at cvs, I would say that this may be fixed in autoconf 2.53. Could you try that? Hmmm. Ok. JMarc Angus
Re: compile success and a config patch
Angus == Angus Leeming [EMAIL PROTECTED] writes: Your tweak for CPP is not needed if you configure with CC=deccxx. Angus I do that too and can state that I found that it _was_ needed Angus to find those 4 cxx header files, ostream etc. Could you recall me what are the environment variables you have to set? Can I see configure output when you onl set CC and CXX? JMarc
Re: [Devel] Graphics bug
On Saturday 23 March 2002 10:13 am, Michael Schmitt wrote: Hi Angus, the latest graphics patch seems to be broken. I have several documents which include tgif files (*.obj). When I want to view the DVI output, I get a large number of error messages like the following one: LaTeX Error: File '/tmp/lyx_tmpdir1642YziKta/lyx_tmpbuf0/MyGraphics5' not found. In fact, the corresponding directory does not include any graphics file, just *.dvi, *.log, and *.tex. I guess there is a problem with relative paths? Upgrade to today's cvs! Angus
Re: compile success and a config patch
On Monday 25 March 2002 1:29 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Ok, Lars, I've finally got there. I had to tweak my configure Angus script so that CPP=deccxx -E, or I couldn't find ostream etc. Angus I also upgraded to automake 1.5, autoconf 2.52, although I'm Angus not sure that that was strictly necessary. (I did this before Angus finding the CPP fix.) Finally, I had to patch lyxinclude.m4; Angus attached. Concerning you patch to depcomp: it seems that automake 1.6 has fixes in depcomp for tru64 unix. You may want to upgrade to that and update depcomp in lyx sources. The guy doing the maintenance is clearly braindead. This is automake 1.6 where object=file.o or file.lo: base=`echo $object | sed -e 's/\.o$/.d/' -e 's/\.lo$/.d/'` tmpdepfile1=$base.o.d tmpdepfile2=$base.d resulting in base=file.d etc It should be: base=`echo $object | sed -e 's/\.o$//' -e 's/\.lo$//'` What should I do now? Angus
Re: compile success and a config patch
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus The guy doing the maintenance is clearly braindead. This is Angus automake 1.6 where object=file.o or file.lo: Angus What should I do now? Report the bug (you may want to avoid the comment on his braindeadness). And depending on what is in the new depcomp, either keep what we already have or provide a fixed version of depcomp 1.6. JMarc
Re: compile success and a config patch
On Monday 25 March 2002 2:27 pm, Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus The guy doing the maintenance is clearly braindead. This is
Angus automake 1.6 where object=file.o or file.lo:
Angus What should I do now?
Report the bug (you may want to avoid the comment on his
braindeadness).
Ok. Done.
And depending on what is in the new depcomp, either
keep what we already have or provide a fixed version of depcomp 1.6.
I'll let you decide that. Here's the diff between the version in config (with
my patch removed) and automake 1.6's. Do you want these other fixes in too?
Angus
--- config/depcomp Mon Mar 25 14:43:22 2002
+++ /usr/local/GNU/share/automake-1.6/depcomp Mon Mar 25 13:45:09 2002
@@ -31,7 +31,16 @@
fi
# `libtool' can also be set to `yes' or `no'.
-depfile=${depfile-`echo $object | sed 's,\([^/]*\)$,.deps/\1,;s/\.\([^.]*\)$/.P\1/'`}
+if test -z $depfile; then
+ base=`echo $object | sed -e 's,^.*/,,' -e 's,\.\([^.]*\)$,.P\1,'`
+ dir=`echo $object | sed 's,/.*$,/,'`
+ if test $dir = $object; then
+ dir=
+ fi
+ # FIXME: should be _deps on DOS.
+ depfile=$dir.deps/$base
+fi
+
tmpdepfile=${tmpdepfile-`echo $depfile | sed 's/\.\([^.]*\)$/.T\1/'`}
rm -f $tmpdepfile
@@ -204,8 +213,9 @@
# dependencies in `foo.d' instead, so we check for that too.
# Subdirectories are respected.
- tmpdepfile1=$object.d
- tmpdepfile2=`echo $object | sed -e 's/.o$/.d/'`
+ base=`echo $object | sed -e 's/\.o$/.d/' -e 's/\.lo$/.d/'`
+ tmpdepfile1=$base.o.d
+ tmpdepfile2=$base.d
if test $libtool = yes; then
$@ -Wc,-MD
else
@@ -314,7 +324,7 @@
if test $stat != 0; then exit $stat; fi
rm -f $depfile
cat $tmpdepfile $depfile
- tail +3 $tmpdepfile | tr ' ' '
+ sed '1,2d' $tmpdepfile | tr ' ' '
' | \
## Some versions of the HPUX 10.20 sed can't process this invocation
## correctly. Breaking it into two sed invocations is a workaround.
@@ -382,6 +392,21 @@
done
;;
esac
+for arg
+do
+ case $arg in
+ -Gm|/Gm|-Gi|/Gi|-ZI|/ZI)
+ set fnord $@
+ shift
+ shift
+ ;;
+ *)
+ set fnord $@ $arg
+ shift
+ shift
+ ;;
+ esac
+done
$@ -E |
sed -n '/^#line [0-9][0-9]* \([^]*\)/ s::echo `cygpath -u \\\1\\`:p' | sort | uniq $tmpdepfile
)
[PATCH] fix bug #241
please apply
regards
john
--
Way back at the beginning of time around 1970 the first man page was
handed down from on high. Every one since is an edited copy.
- John Hasler [EMAIL PROTECTED]
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.644
diff -u -r1.644 ChangeLog
--- src/ChangeLog 22 Mar 2002 15:13:35 - 1.644
+++ src/ChangeLog 25 Mar 2002 14:57:15 -
@@ -1,3 +1,8 @@
+2002-03-25 John Levon [EMAIL PROTECTED]
+
+ * BufferView_pimpl.C (updateScrollbar): update on buffer switch
+ properly
+
2002-03-22 Angus Leeming [EMAIL PROTECTED]
* PrinterParams.h: #include lyxrc.h and remove that bloody irritating
Index: src/BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.218
diff -u -r1.218 BufferView_pimpl.C
--- src/BufferView_pimpl.C 21 Mar 2002 17:25:06 - 1.218
+++ src/BufferView_pimpl.C 25 Mar 2002 14:57:20 -
@@ -397,10 +402,8 @@
void BufferView::Pimpl::updateScrollbar()
{
- /* If the text is smaller than the working area, the scrollbar
-* maximum must be the working area height. No scrolling will
-* be possible */
if (!bv_-text) {
+ lyxerr[Debug::GUI] no text in updateScrollbar endl;
workarea_.setScrollbar(0, 1.0);
return;
}
@@ -408,42 +411,36 @@
long const text_height = bv_-text-height;
long const work_height = workarea_.height();
+ double const lineh = bv_-text-defaultHeight();
+ double const slider_size =
+ (text_height == 0) ? 1.0 : 1.0 / double(text_height);
+
+ lyxerr[Debug::GUI] text_height now text_height endl;
+ lyxerr[Debug::GUI] work_height work_height endl;
+
+ /* If the text is smaller than the working area, the scrollbar
+* maximum must be the working area height. No scrolling will
+* be possible */
if (text_height = work_height) {
+ lyxerr[Debug::GUI] doc smaller than workarea ! endl;
workarea_.setScrollbarBounds(0.0, 0.0);
current_scrollbar_value = bv_-text-first_y;
workarea_.setScrollbar(current_scrollbar_value, 1.0);
return;
}
- double const lineh = bv_-text-defaultHeight();
- double const slider_size =
- (text_height == 0) ? 1.0 : 1.0 / double(text_height);
-
- static long old_text_height;
- static double old_lineh;
- static double old_slider_size;
-
- if (text_height != old_text_height) {
- workarea_.setScrollbarBounds(0.0,
-text_height - work_height);
- old_text_height = text_height;
- }
- if (lineh != old_lineh) {
- workarea_.setScrollbarIncrements(lineh);
- old_lineh = lineh;
- }
- if (current_scrollbar_value != bv_-text-first_y
- || slider_size != old_slider_size) {
- current_scrollbar_value = bv_-text-first_y;
- workarea_.setScrollbar(current_scrollbar_value, slider_size);
- old_slider_size = slider_size;
- }
+ workarea_.setScrollbarBounds(0.0, text_height - work_height);
+ workarea_.setScrollbarIncrements(lineh);
+ current_scrollbar_value = bv_-text-first_y;
+ workarea_.setScrollbar(current_scrollbar_value, slider_size);
}
// Callback for scrollbar slider
void BufferView::Pimpl::scrollCB(double value)
{
+ lyxerr[Debug::GUI] scrollCB of value endl;
+
if (!buffer_) return;
current_scrollbar_value = long(value);
Re: compile success and a config patch
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus I'll let you decide that. Here's the diff between the version Angus in config (with my patch removed) and automake 1.6's. Do you Angus want these other fixes in too? It is difficult to say like that... Just keep what we have for now. In 1.3.0cvs we'll require autoconf 2.53/automake 1.6, I think. JMarc
Re: Package Manager
John == John Levon [EMAIL PROTECTED] writes: John there's also the listings dialog and probably more I've John forgotten ... This is in the more involved category, and this one will have to wait for after 1.2.0. JMarc
Re: [PATCH] fix bug #300
John == John Levon [EMAIL PROTECTED] writes: John last try for this one ... Applied in my tree. JMarc
autogen.sh warnings...
Using automake 1.6 and autoconf 2.53... What do I need to do to recreate aclocal.m4? (see warnings below). I ran aclocal, but to no effect. Guess it's linked to the AM_FUNC_ERROR_AT_LINE message? Should I back out to automake 1.5 and autoconf 2.52? Angus aleem@pneumon:devel- ./autogen.sh Locating GNU m4... found: gm4 Generate acinclude.m4... done. Building macros... . aclocal: configure.in: : macro `AM_FUNC_ERROR_AT_LINE' not found in library lib/reLyX sigc++ done. Building config header template... . WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. configure.in:5: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst configure.in:372: warning: do not use m4_regexp: use regexp or m4_bregexp autoheader: `src/config.h.in' is updated sigc++ WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `sigc++config.h.in' is updated done. Building Makefile templates... . configure.in:19: your implementation of AM_INIT_AUTOMAKE comes from an configure.in:19: old Automake version. You should recreate aclocal.m4 configure.in:19: with aclocal and run automake again. aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' /usr/local/GNU/share/automake-1.6/am/compile.am: LIBS was set with `+=' and is now set with `=' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' /usr/local/GNU/share/automake-1.6/am/compile.am: LIBS was set with `+=' and is now set with `=' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' aclocal.m4:5382: invalid unused variable name: `QT2_LDFLAGS' aclocal.m4:914: invalid unused variable name: `FRONTEND_LDFLAGS' lib/reLyX sigc++ done. Building configure... . lib/reLyX sigc++ done. Building lib/configure ... done. run ./configure ; make
Re: Package Manager
John == John Levon [EMAIL PROTECTED] writes: John On Mon, Mar 25, 2002 at 04:09:34PM +0100, Jean-Marc Lasgouttes John wrote: This is in the more involved category, and this one will have to wait for after 1.2.0. John oh, sorry, I thought we were talking only about post 1.2 anyway John I'll shut up then These are two smallish patches that are useful enough to go in 1.2.0 if Herbert finds time to clean them up. JMarc
Help: make install error
I get an error during make install (make works fine). Here is the story: cvs -z9 checkout lyx-devel cd lyx-devel ./autogen.sh ./configure --prefix=/home2/marco/local/lyx-1.2 ... Configuration Host type: i686-pc-linux-gnu Special build flags:warnings assertions included-libsigc xforms-image-loader C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (3.0.4) C++ Compiler flags: -g -O -fno-rtti -fno-exceptions -W -Wall Linker flags: Frontend: xforms libXpm version: 4.11 libforms version: 0.89.6 LyX binary dir: /home2/marco/local/lyx-1.2/bin LyX files dir: /home2/marco/local/lyx-1.2/share/lyx Configuration of LyX was successful. Type 'make' to compile the program, and then 'make install' to install it. make make install ... files=`sed -e 's/^\([^ ]*\) .*$/\1/' xfonts/fonts.dir` ; \ for i in $(files) ; do \ ln -sf `kpsewhich $i` /home2/marco/local/lyx-1.2/share/lyx/xfonts/$i ; \ done sed: can't read xfonts/fonts.dir: No such file or directory /bin/sh: files: command not found /usr/bin/install -c -m 644 xfonts/fonts.dir /home2/marco/local/lyx-1.2/share/lyx/xfonts/fonts.dir /usr/bin/install: cannot stat `xfonts/fonts.dir': No such file or directory make[3]: *** [install-xfonts] Error 1 make[3]: Leaving directory `/home3/marco/lyx-devel/lib' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/home3/marco/lyx-devel/lib' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home3/marco/lyx-devel/lib' make: *** [install-recursive] Error 1 What's wrong? Thanks in advance for your help, Marco Morandini
Re: lyx hangs
Edwin Leuven wrote:
when opening attached doc with latest cvs...
try this, worked here
Herbert
Index: src/insets/insetgraphicsParams.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetgraphicsParams.C,v
retrieving revision 1.29
diff -u -r1.29 insetgraphicsParams.C
--- src/insets/insetgraphicsParams.C25 Mar 2002 11:04:34 - 1.29
+++ src/insets/insetgraphicsParams.C25 Mar 2002 15:40:38 -
-251,8 +251,11
draft = true;
} else if (token == display) {
lex.next();
- string const type = lex.getString();
- display = displayTranslator.find(type);
+ if (IsFileReadable(filename)) {
+ string const type = lex.getString();
+ display = displayTranslator.find(type);
+ } else
+ display = NONE;
} else if (token == subcaption) {
subcaption = true;
} else if (token == subcaptionText) {
Re: lyx hangs
On Monday 25 March 2002 3:42 pm, Herbert Voss wrote: Edwin Leuven wrote: when opening attached doc with latest cvs... try this, worked here Herbert I guess that this should go in anyway. I'll do that. Ed do you have any problems if the files exist? Angus
Re: lyx hangs
Ed do you have any problems if the files exist? Actually, yes. I'd thought however to report this one first... Files attached this time Ed. doc.tar.gz Description: application/tgz
Re: autogen.sh warnings...
Angus Leeming [EMAIL PROTECTED] writes: | Using automake 1.6 and autoconf 2.53... | What do I need to do to recreate aclocal.m4? (see warnings below). I ran | aclocal, but to no effect. Guess it's linked to the AM_FUNC_ERROR_AT_LINE | message? | Should I back out to automake 1.5 and autoconf 2.52? Try it. -- Lgb
Re: compile success and a config patch
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Angus == Angus Leeming [EMAIL PROTECTED] writes: | Angus I'll let you decide that. Here's the diff between the version | Angus in config (with my patch removed) and automake 1.6's. Do you | Angus want these other fixes in too? | It is difficult to say like that... Just keep what we have for now. | In 1.3.0cvs we'll require autoconf 2.53/automake 1.6, I think. Would be nice if the main distributions switched to that first... Has any distributions switched? -- Lgb
Re: autogen.sh warnings...
On Monday 25 March 2002 4:06 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Using automake 1.6 and autoconf 2.53... | | What do I need to do to recreate aclocal.m4? (see warnings below). I ran | aclocal, but to no effect. Guess it's linked to the AM_FUNC_ERROR_AT_LINE | message? | | Should I back out to automake 1.5 and autoconf 2.52? Try it. As cryptic messages, this takes the biscuit! Try what? Backing out? Well of course that would work. Do you want me to? Angus
Re: lyx hangs
Edwin Leuven wrote: Ed do you have any problems if the files exist? Actually, yes. I'd thought however to report this one first... Files attached this time ok, your graphic program saves the eps files in a wrong way because the bounding box is a HiResBoundingBox but saved as a standard one. patch comes Herbert -- http://www.lyx.org/help/
Re: compile success and a config patch
Lars Gullik Bjønnes wrote: | In 1.3.0cvs we'll require autoconf 2.53/automake 1.6, I think. Would be nice if the main distributions switched to that first... Has any distributions switched? SuSE 7.3 has automake 1.4-p5 and autoconf 2.52 SuSE 8.0 will be shipped end april, but there's no information available about packages versions by now. Juergen.
Re: compile success and a config patch
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars | In 1.3.0cvs we'll require autoconf 2.53/automake 1.6, I think. Lars Would be nice if the main distributions switched to that Lars first... Lars Has any distributions switched? Do we care? It is only a burden for the developpers. We can choose automake1.5/autoconf2.52, if you prefer. Anyway mandrake 8.2 and rh7.3beta provide the new ones, but the default is to use the old ones. JMarc
Re: autogen.sh warnings...
Angus Leeming [EMAIL PROTECTED] writes: | On Monday 25 March 2002 4:06 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | Using automake 1.6 and autoconf 2.53... | | What do I need to do to recreate aclocal.m4? (see warnings below). I ran | aclocal, but to no effect. Guess it's linked to the AM_FUNC_ERROR_AT_LINE | message? | | Should I back out to automake 1.5 and autoconf 2.52? Try it. | As cryptic messages, this takes the biscuit! Try what? Backing out? Well of | course that would work. Do you want me to? back out of course. -- Lgb
Re: make install error
Marco == Marco Morandini [EMAIL PROTECTED] writes: Marco A few more details after noticing Marco http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg35269.html Marco Yes, configure in lib get run, but lib/xfonts is an empty Marco directory. Marco but my system does not have such X11 fonts (cmex10.pfb, for Marco example), only Tex ones: cmex10.tfm and cmex10.mf (in Marco /usr/share/texmf/fonts) Marco Hope this helps. Yes, this probably helps. I will take a look at that tonight. JMarc
LyX's cvs support
How close is LyX's cvs support to working?
Does it just need a lyxrc variable and LyXVC::registrer changing like this
(below)? If so, what should MASTER and FILENAME be set to?
Angus
void LyXVC::registrer()
{
// it is very likely here that the vcs is not created yet...
// so... we use RCS as default, later this should perhaps be
// a lyxrc option.
if (!vcs) {
switch (lyxrc.vcs) {
case LyXRC::RCS:
vcs = new RCS(owner_-fileName());
break;
case LyXRC::CVS:
vcs = new CVS(MASTER, FILENAME);
break;
}
vcs-owner(owner_);
}
Re: compile success and a config patch
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I have some other projects that also use auto tools, so Lars currently switching will be a real burden. Currently, my 'other project' was 1.1.6, but soon it will change :) It is not difficult to make a configure.in file that works for both versions (see what we have in 1.2.0cvs). And you are the guy who wants everybody to upgrade something every other week, aren't you? Lars | Anyway mandrake 8.2 and rh7.3beta provide the new ones, but Lars the | default is to use the old ones. Lars Ok... btw. where do you find information about rh7.3? I started from the announcement on slashdot, and from there found my way to the ftp repository, to see what rpms are in there. JMarc
autogen.sh warnings
With automake 1.5 and autoconf 2.52, I get (below). Hope this is useful. Angus aleem@pneumon:devel- ./autogen.sh Locating GNU m4... found: gm4 Generate acinclude.m4... done. Building macros... . lib/reLyX sigc++ done. Building config header template... . autoheader: src/config.h.in is unchanged sigc++ autoheader: sigc++config.h.in is unchanged done. Building Makefile templates... . src/Makefile.am:12: LIBS was set with `+=' and is now set with `=' src/frontends/Makefile.am:12: LIBS was set with `+=' and is now set with `=' lib/reLyX sigc++ done. Building configure... . lib/reLyX sigc++ done. Building lib/configure ... done. run ./configure ; make
Re: More eye candy
John == John Levon [EMAIL PROTECTED] writes: John no, I mean each /button/ needs a name. Can you use the tooltip text for that? Otherwise, we could add names in the toolbar specification. John Also we want to be able to specify whether a toolbar should be John horizontal, vertical, t,b,l,r too... This is probably a general qt2-only pref. Not something we want in the general toolbar code... John We already have NewLine, so we just need to be a bit more John flexible. Qt frontend can already make the standard toolbar John vertical (but it looks a bit silly) I'm not sure what Newline is good for here (actually, I think we should nuke it). You do not have to do menu creation on demand. You are free to implement menus as you see fit. John This does not appear to be true, in particular for the John view/update dynamic menu, currently I must wait for a buffer John before I can get my data. If you do not have a buffer, there is nothing to display, no? You mean that Menubar::update is not called when there is no buffer? Feel free to change that. Note however that recomputing the toc at each key press may prove expensive. John ISTR the problem is that you can't disable an entire menu in John xforms, right ? I could, it is just a bit more code. But this is the solution we chose for now. It is an UI policy, however. You can decide to disable menus whose entris are all disabled. What is the typical Qt way of handling menus like those of LyX? John I don't really know, I've never written a Qt application before John ... It would be interesting to know what applications without hardcoded menus (koffice??) do. John What I think I would like to see is something like a John MenuBackend Menu_pimpl::somethingChanged(SpecialType t) John then the pimpl can do .expand(t) to get the current list of John special entries. This can be ignored by xforms (since it will do John expand at each menu open anyway) but can be used by qt (and John gnome, if it makes sense) THis is something I'd like to avoid, sice it means we would have to add a lot of calls to this signal all over the code. And I'd rather have the core ignorant of the UI. JMarc
Re: autogen.sh warnings
Angus Leeming [EMAIL PROTECTED] writes: | With automake 1.5 and autoconf 2.52, I get (below). Hope this is useful. | Angus | aleem@pneumon:devel- ./autogen.sh | Locating GNU m4... found: gm4 | Generate acinclude.m4... done. | Building macros... | . | lib/reLyX | sigc++ | done. | Building config header template... | . | autoheader: src/config.h.in is unchanged | sigc++ | autoheader: sigc++config.h.in is unchanged | done. | Building Makefile templates... | . | src/Makefile.am:12: LIBS was set with `+=' and is now set with `=' | src/frontends/Makefile.am:12: LIBS was set with `+=' and is now set | with `=' I don't like this warning... but I think we can live with it. To remove it I would have to set LIBS explictly in all Makefile.am's and I don't want to do that. -- Lgb
Re: compile success and a config patch
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: | Lars | In 1.3.0cvs we'll require autoconf 2.53/automake 1.6, I think. | Lars Would be nice if the main distributions switched to that | Lars first... | Lars Has any distributions switched? | Do we care? It is only a burden for the developpers. We can choose | automake1.5/autoconf2.52, if you prefer. I have some other projects that also use auto tools, so currently switching will be a real burden. | Anyway mandrake 8.2 and rh7.3beta provide the new ones, but the | default is to use the old ones. Ok... btw. where do you find information about rh7.3? -- Lgb
Re: autogen.sh warnings
On Monday 25 March 2002 4:54 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | With automake 1.5 and autoconf 2.52, I get (below). Hope this is useful. | | Angus | | | aleem@pneumon:devel- ./autogen.sh | Locating GNU m4... found: gm4 | Generate acinclude.m4... done. | Building macros... | . | lib/reLyX | sigc++ | done. | Building config header template... | . | autoheader: src/config.h.in is unchanged | sigc++ | autoheader: sigc++config.h.in is unchanged | done. | Building Makefile templates... | . | src/Makefile.am:12: LIBS was set with `+=' and is now set with `=' | src/frontends/Makefile.am:12: LIBS was set with `+=' and is now set | with `=' I don't like this warning... but I think we can live with it. To remove it I would have to set LIBS explictly in all Makefile.am's and I don't want to do that. Well print out a comment before this warning to the effect that these warnings are expected. Or you'll get loads of messages from people like me! A
Re: LyX's cvs support
On Monday 25 March 2002 4:50 pm, Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| How close is LyX's cvs support to working?
|
| Does it just need a lyxrc variable and LyXVC::registrer changing like
| this (below)? If so, what should MASTER and FILENAME be set to?
|
| Angus
|
| void LyXVC::registrer()
| {
| // it is very likely here that the vcs is not created yet...
| // so... we use RCS as default, later this should perhaps be
| // a lyxrc option.
| if (!vcs) {
| switch (lyxrc.vcs) {
| case LyXRC::RCS:
| vcs = new RCS(owner_-fileName());
| break;
|
| case LyXRC::CVS:
| vcs = new CVS(MASTER, FILENAME);
| break;
| }
|
| vcs-owner(owner_);
| }
Hmm?? Isn't it working?
Or is it only register that you wonder about?
Yes.
remember that a cvs register is a cvs add, the master is CVS/Entries
in the current dir. And if there are no CVS/Entries the user should
not be allowed to register a new file...
Ah, Ok. So I'd have to first set up a repository? Well I'll try. Why doesn't
LyX do that for me?
Angus
Re: LyX's cvs support
On Mon, Mar 25, 2002 at 05:02:49PM +, Angus Leeming wrote: Ah, Ok. So I'd have to first set up a repository? Well I'll try. Why doesn't LyX do that for me? hey, hey, it's not emacs... john -- Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy. - John Hasler [EMAIL PROTECTED]
Re: autogen.sh warnings
Angus Leeming [EMAIL PROTECTED] writes: | On Monday 25 March 2002 4:54 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | With automake 1.5 and autoconf 2.52, I get (below). Hope this is useful. | | Angus | | | aleem@pneumon:devel- ./autogen.sh | Locating GNU m4... found: gm4 | Generate acinclude.m4... done. | Building macros... | . | lib/reLyX | sigc++ | done. | Building config header template... | . | autoheader: src/config.h.in is unchanged | sigc++ | autoheader: sigc++config.h.in is unchanged | done. | Building Makefile templates... | . | src/Makefile.am:12: LIBS was set with `+=' and is now set with `=' | src/frontends/Makefile.am:12: LIBS was set with `+=' and is now set | with `=' I don't like this warning... but I think we can live with it. To remove it I would have to set LIBS explictly in all Makefile.am's and I don't want to do that. | Well print out a comment before this warning to the effect that these | warnings are expected. Or you'll get loads of messages from people like me! How did you know that these were warnings? IMHO they are just info notices. (ok ok ok) -- Lgb
Re: LyX's cvs support
John Levon [EMAIL PROTECTED] writes: | On Mon, Mar 25, 2002 at 05:02:49PM +, Angus Leeming wrote: Ah, Ok. So I'd have to first set up a repository? Well I'll try. Why doesn't LyX do that for me? What should be done in register is to check if the currenct dir is a CVS dir (i.e. that CVS/Entries exist), and if so a CVS should be instatiated instead of a RCS. Then vcs-registrer will do the right thing. | hey, hey, it's not emacs... True ... and to make the current dir a CVS dir you will have to do import and stuff... not something that I think we should do from inside LyX. -- Lgb
Re: compile success and a config patch
On Monday 25 March 2002 1:43 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Your tweak for CPP is not needed if you configure with CC=deccxx. Angus I do that too and can state that I found that it _was_ needed Angus to find those 4 cxx header files, ostream etc. Could you recall me what are the environment variables you have to set? Can I see configure output when you onl set CC and CXX? JMarc Jean-Marc, this is the what I need to get configure running correctly with automake 1.5 and autoconf 2.52. Note that I don't need the deccc and deccxx wrappers anymore, but I do need to define the compilers as cc -std1 and cxx -strict_ansi, rather than leaving these flags in CFLAGS and CXXFLAGS. I justified that to myself easily enough (they really _are_ different compilers). I find that without, the c++ preprocessor is unable to find ostream etc. Do you want the config.log output with/without these flags in the CC and CXX definitions or are you happy just to see that all is working fine? Regards, Angus configure-setup Description: application/shellscript
Re: LyX's cvs support
Lars Gullik Bjønnes wrote: True ... and to make the current dir a CVS dir you will have to do import and stuff... not something that I think we should do from inside LyX. But maybe this procedure should be documented in Extended or such then. For dumb people like me. Juergen.
Re: compile success and a config patch
On Mon, Mar 25, 2002 at 05:35:11PM +0100, Jean-Marc Lasgouttes wrote: And you are the guy who wants everybody to upgrade something every other week, aren't you? Only when he happens to have installed the stuff already on his own machine ;-} Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Fwd: Re: lyx hangs
Actually, this looks like something for the inset wizards. Angus -- Forwarded Message from Herbert Voss -- Subject: Re: lyx hangs Date: Mon, 25 Mar 2002 18:06:51 +0100 From: Herbert Voss [EMAIL PROTECTED] To: Edwin Leuven [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Edwin Leuven wrote: Ed do you have any problems if the files exist? Actually, yes. I'd thought however to report this one first... Files attached this time there were different problems, but the major one still exist. Angus, it's your turn: I suppose a timing problem, in fact of these three images which lyx tries to convert at the same time. 1. you can insert as much images as you like into the lyx workarea. All works well. Closing and reopening the doc gives some problems, when there are more than 2 images to convert. 2. delete one of these images and all works! 3. when I insert some text between the 3 images, so that only one is in the workarea, all works fine. Herbert -- http://www.lyx.org/help/
lyxinclude question
Incidentally, Jean-Marc, Lars' says that this fix will not work with autoconf 2.13. Have you any idea what the right thing to do is? (It's needed because autoconf 2.52 assigns flimage_dup to a pointer to a function without checking whether that function has extern C linkage.) Angus Index: config/lyxinclude.m4 === RCS file: /usr/local/lyx/cvsroot/lyx-devel/config/lyxinclude.m4,v retrieving revision 1.57 diff -u -p -r1.57 lyxinclude.m4 --- config/lyxinclude.m421 Mar 2002 16:49:06 - 1.57 +++ config/lyxinclude.m425 Mar 2002 17:10:08 - -617,10 +617,12 AC_DEFUN(LYX_USE_XFORMS_IMAGE_LOADER, save_LIBS=$LIBS LIBS=$XFORMS_LIB $LIBS lyx_use_xforms_image_loader=no +AC_LANG(C) AC_CHECK_FUNCS(flimage_dup,[ AC_CHECK_FUNCS(flimage_to_pixmap,[ lyx_use_xforms_image_loader=yes AC_CHECK_FUNCS(flimage_enable_ps)])]) +AC_LANG(C++) LIBS=$save_LIBS test $lyx_use_xforms_image_loader = yes lyx_flags=$lyx_flags xforms-image-loader ### If the gui cannot load images itself, then we default to the
Re: LyX's cvs support
[EMAIL PROTECTED] (Juergen Spitzmueller) writes: | Lars Gullik Bjønnes wrote: True ... and to make the current dir a CVS dir you will have to do import and stuff... not something that I think we should do from inside LyX. | But maybe this procedure should be documented in Extended or such then. | For dumb people like me. Why really? LyX is not CVS, and should not educate people about it. A reference to some CVS documentation should be enough. -- Lgb
Re: compile success and a config patch
Andre Poenitz [EMAIL PROTECTED] writes: | On Mon, Mar 25, 2002 at 05:35:11PM +0100, Jean-Marc Lasgouttes wrote: And you are the guy who wants everybody to upgrade something every other week, aren't you? | Only when he happens to have installed the stuff already on his own machine | ;-} Yup, I am just as selfish as the next guy. But in this case... changing autoconf version trigger problems with other packages as well. otoh... I am getting closer and closer to a switch. -- Lgb
Re: lyxinclude question
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Incidentally, Jean-Marc, Lars' says that this fix will not Angus work with autoconf 2.13. Have you any idea what the right thing Angus to do is? Probably AC_LANG_C/AC_LANG_CPLUSPLUS, which are used all over configure.in :) Angus (It's needed because autoconf 2.52 assigns flimage_dup to a Angus pointer to a function without checking whether that function Angus has extern C linkage.) Did you try 2.53? I believe it fixes the problem. We do not want to switch to C unless we are forced to. It is the c++ compiler which will use those functions, after all. JMarc
Re: LyX's cvs support
Lars Gullik Bjønnes wrote: | But maybe this procedure should be documented in Extended or such | then. For dumb people like me. Why really? LyX is not CVS, and should not educate people about it. A reference to some CVS documentation should be enough. Mention it at least. I have thought that LyX does not yet support cvs but only rcs until now. If you want to use CVS for version control, you need to create proper CVS directory manually. Consult the CVS manpage for further instructions or something would be better than nothing. Juergen.
Re: More eye candy
On Mon, Mar 25, 2002 at 05:46:26PM +0100, Jean-Marc Lasgouttes wrote: John no, I mean each /button/ needs a name. Can you use the tooltip text for that? Otherwise, we could add names in the toolbar specification. I could use tooltips I suppose ... a minor point anyway. John horizontal, vertical, t,b,l,r too... This is probably a general qt2-only pref. Not something we want in the general toolbar code... hmm ? It's a hint - frontends are free to ignore it. This makes sense to me. John We already have NewLine, so we just need to be a bit more John flexible. Qt frontend can already make the standard toolbar John vertical (but it looks a bit silly) I'm not sure what Newline is good for here (actually, I think we should nuke it). So how do I have multiple user defined toolbars ? If you do not have a buffer, there is nothing to display, no? Then the backend should return nothing (I've already done this). Making me check the magic type and see if it's one that might require a buffer is ugly. Feel free to change that. Note however that recomputing the toc at each key press may prove expensive. I believe we've covered this territory (unsuccessfully) before. I could, it is just a bit more code. But this is the solution we chose for now. It is an UI policy, however. You can decide to disable menus whose entris are all disabled. ok, sure. It would be interesting to know what applications without hardcoded menus (koffice??) do. yes, it would. I suspect they just hard code everything in; they don't need to work with more than one frontend. THis is something I'd like to avoid, sice it means we would have to add a lot of calls to this signal all over the code. And I'd rather have the core ignorant of the UI. A signal is pretty ignorant IMHO. We reached this empasse before. You claim I don't have to fill menus on demand on the one hand, but say I can't keep up to date on the other. I can't spot the middle ground you're talking about ? regards john -- Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy. - John Hasler [EMAIL PROTECTED]
Re: LyX's cvs support
On Monday 25 March 2002 5:57 pm, Juergen Spitzmueller wrote: Lars Gullik Bjønnes wrote: | But maybe this procedure should be documented in Extended or such | then. For dumb people like me. Why really? LyX is not CVS, and should not educate people about it. A reference to some CVS documentation should be enough. Mention it at least. I have thought that LyX does not yet support cvs but only rcs until now. If you want to use CVS for version control, you need to create proper CVS directory manually. Consult the CVS manpage for further instructions or something would be better than nothing. Juergen. Jürgen, if, like me, you are a cvs novice, then try cervisia. It's taking the pain away for me. Angus
Re: lyxinclude question
On Monday 25 March 2002 5:38 pm, Jean-Marc Lasgouttes wrote: Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Incidentally, Jean-Marc, Lars' says that this fix will not Angus work with autoconf 2.13. Have you any idea what the right thing Angus to do is? Probably AC_LANG_C/AC_LANG_CPLUSPLUS, which are used all over configure.in :) Angus (It's needed because autoconf 2.52 assigns flimage_dup to a Angus pointer to a function without checking whether that function Angus has extern C linkage.) Did you try 2.53? I believe it fixes the problem. We do not want to switch to C unless we are forced to. It is the c++ compiler which will use those functions, after all. No, Lars told me to back out. Should I use a combination of automake 1.5 autoconf 2.53 ? Angus
Re: LyX's cvs support
Angus Leeming wrote: Jürgen, if, like me, you are a cvs novice, then try cervisia. It's taking the pain away for me. Thanks, Angus. I have played with cervisia (though my version fails to create patches for some reason, but doing this from the console is not too hard). But I don't speak for me. I think a little documentation on this would be good for the most users. You don't have to know anything about rcs to use it for version control within LyX. That's not the case with cvs. Juergen. Angus
Re: LyX's cvs support
On Monday 25 March 2002 5:08 pm, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| On Mon, Mar 25, 2002 at 05:02:49PM +, Angus Leeming wrote:
Ah, Ok. So I'd have to first set up a repository? Well I'll try. Why
doesn't LyX do that for me?
What should be done in register is to check if the currenct dir is a
CVS dir (i.e. that CVS/Entries exist), and if so a CVS should be
instatiated instead of a RCS.
Then vcs-registrer will do the right thing.
Like this?
void LyXVC::registrer()
{
// it is very likely here that the vcs is not created yet...
- // so... we use RCS as default, later this should perhaps be
- // a lyxrc option.
if (!vcs) {
- vcs = new RCS(owner_-fileName());
+ static string const cvs_entries = CVS/Entries;
+
+ if (IsFileReadable(cvs_entries)) {
+ vcs = new CVS(cvs_entries, owner_-fileName());
+ } else {
+ vcs = new RCS(owner_-fileName());
+ }
+
vcs-owner(owner_);
}
Re: lyxinclude question
Did you try 2.53? I believe it fixes the problem. We do not want to switch to C unless we are forced to. It is the c++ compiler which will use those functions, after all. No, Lars told me to back out. Should I use a combination of automake 1.5 autoconf 2.53 Yes, this is what I had in mind. JMarc
Re: More eye candy
Can you use the tooltip text for that? Otherwise, we could add names in the toolbar specification. I could use tooltips I suppose ... a minor point anyway. Yes, but it is all these minor points that make a polished UI. John horizontal, vertical, t,b,l,r too... This is probably a general qt2-only pref. Not something we want in the general toolbar code... hmm ? It's a hint - frontends are free to ignore it. This makes sense to me. I thought that all toolbar in KDE apps were supposed to be setable by the user as floating top, bottom, whatever... However, we could have a flag in the format telling whether a toolbar should default to on/off. I'm not sure what Newline is good for here (actually, I think we should nuke it). So how do I have multiple user defined toolbars ? Toolbar one Enabled 1 #this one is shown by default ... End Toolbar two Enabled 0 #this one is hidden by default ... End I do not say this is the right solution, just a thought. If you do not have a buffer, there is nothing to display, no? Then the backend should return nothing (I've already done this). Making me check the magic type and see if it's one that might require a buffer is ugly. You do not have to check for that. getStatus tells you whether a lyxfunc is enabled or not, whatever the reason (no buffer, readonly, ...) Feel free to change that. Note however that recomputing the toc at each key press may prove expensive. I believe we've covered this territory (unsuccessfully) before. Yes, but we will have to eventually find a solution. It would be interesting to know what applications without hardcoded menus (koffice??) do yes, it would. I suspect they just hard code everything in; they don't need to work with more than one frontend. Even these apps do not allow to redefine menus (a la word)? They suck. We reached this empasse before. You claim I don't have to fill menus on demand on the one hand, but say I can't keep up to date on the other. I can't spot the middle ground you're talking about ? I do not say I won't change my opinion, I am arguing. Convince me. JMarc
Re: LyX's cvs support
Angus Leeming [EMAIL PROTECTED] writes:
| On Monday 25 March 2002 5:08 pm, Lars Gullik Bjønnes wrote:
John Levon [EMAIL PROTECTED] writes:
| On Mon, Mar 25, 2002 at 05:02:49PM +, Angus Leeming wrote:
Ah, Ok. So I'd have to first set up a repository? Well I'll try. Why
doesn't LyX do that for me?
What should be done in register is to check if the currenct dir is a
CVS dir (i.e. that CVS/Entries exist), and if so a CVS should be
instatiated instead of a RCS.
Then vcs-registrer will do the right thing.
| Like this?
| void LyXVC::registrer()
| {
| // it is very likely here that the vcs is not created yet...
| - // so... we use RCS as default, later this should perhaps be
| - // a lyxrc option.
| if (!vcs) {
| - vcs = new RCS(owner_-fileName());
| + static string const cvs_entries = CVS/Entries;
| +
| + if (IsFileReadable(cvs_entries)) {
| + vcs = new CVS(cvs_entries, owner_-fileName());
| + } else {
| + vcs = new RCS(owner_-fileName());
| + }
| +
| vcs-owner(owner_);
| }
Yes, something like that. I am not sure if the static string gains
anything.
a plain 'string const cvs_entries(CVS/Entries)', should be enough.
--
Lgb
