Re: Try File->New with 1.3.0cvs
On 27-May-2002 Lars Gullik Bjønnes wrote: > If your file was in 1.2.0 format it should be no probles, and if it is > you have found a bug. ??? What file? I just launched lyx and did "File->New...". "I" may know that we are reading a default.lyx file, but are you willing to tell it to every user?! > stops all fileformat cleanup and changes. And it was a real > bee-hive... not nice code at all. Well it's there and it's well commented I think it is no problem to leave it there a while longer. Otherwise we just move all the compatibility stuff in a "old_format_read.C" and if we see that "version < our_favoured_version" we just call the function in that file appart. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Living on Earth may be expensive, but it includes an annual free trip around the Sun.
Re: Can't compile with lyxstring
On 27-May-2002 Jean-Marc Lasgouttes wrote: > Juergen> Do we have basic_string somewhere in lyxstring? > > I took a look, and boost::regexp seems to make a large use of > basic_string, even if we disable use of wide strings. So Lars, does it > mean that you put us in a situation of forcing the death of lyxstring > just for the pleasure of using boost::regexp? I would have preferred a > discussion beforehand. Me too! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ One small step for man, one giant stumble for mankind.
Re: Try File->New with 1.3.0cvs
On 27-May-2002 Lars Gullik Bjønnes wrote: >| Otherwise we just move all the compatibility stuff >| in a "old_format_read.C" and if we see that "version < our_favoured_version" >| we just call the function in that file appart. > > we do not want this stuff in LyX. sed,awk,python,perl are the place to > do this. Could you elaborate this? I think we CAN have this in lyx (at least starting from the version we support with 1.2.0). Why should 1 additional file give any more problems? It's isolated and if you don't want you don't have too look inside it, we just say if we don't support this file-version anymore then call this function and it should handle it as it thinks it should do it! If you don't want to work on it noone is forcing you, but IMO it is the best thing to do and mybe we can extend the compatibility read also for older files. We don't need any external application it's one file module and I don't think it will neighter add a lot more bytes to the lyx executable nor give you any more thing to think of! And this is "really" user friendly! And thinking of it I really think I should start doing such a move. If you don't like it we will vote for it on the developers meeting when we already had some beer and discussing is easier ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ All intelligent species own cats.
Re: Try File->New with 1.3.0cvs
On 27-May-2002 John Levon wrote: > On Mon, May 27, 2002 at 06:26:06PM +0300, Dekel Tsur wrote: > >> A conversion script does not need to understand all the tokens in the .lyx >> file. > > Indeed. An external script is definitely the best way. Thins like > tabular-old.C are just a painful maintenance burden. Well the "external" script has to be maintained too to be usefull and we all know how external scripts are maintained (see reLyX!). I think we should do that internally! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Because the wine remembers.
Re: Try File->New with 1.3.0cvs
On 28-May-2002 Lars Gullik Bjønnes wrote: > I disagree... > > A script that translates between two _specific_ lyx-format versions > does not really have to know all the semantics of a lyx file. You mean it has to only know the parts which changed between formats? Well then give someone a good description about that, good luck! > We should have scripts lyxcon-218-220, and then perhaps > lyxcon-215-218 etc. To get a 220 format file, both scripts are chained > together. > > This will render small static scripts (scripts that does not have to > be changed), that will place no maintence burdon upon us. Well I disagree in return. It seems we have different opinions about will be supported and I'm pretty sure external scripts get not enough support! > And as such... the explict format versioning on tabulars should be > removed, and be part of the global lyx file format instead. > > This also means that we have to be careful, so that even the tiniest > format change results in a increased lyx-format. I agree completely with you here the format number on tabulars is historical and can/should be removed and we also have to pay more attention in changing the format number when changing something in the fileformat! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Billy: Mom, you know that vase you said was handed down from generation to generation? Mom:Yes? Billy: Well, this generation dropped it.
Re: graphics stuff
On 28-May-2002 Andre Poenitz wrote: > On Tue, May 28, 2002 at 09:41:30AM +0100, John Levon wrote: >> > How big is the chance that the src/graphics stuff gets seperated >> > "properly" >> > (i.e. in some purely loading related and some InsetGraphics related part) >> > "soon" (i.e within the next few weeks)? >> >> If you want it fixed ... > > Some support from the people who created that code would be nice, though. Well Andre I think Angus told you that he's not able at the moment to compile lyx so what more support should he give you? You'll see all will be done in due time and we all have real work too, so give us the time to react :) Anyway do you come to the meeting? I bought my tickets and will be there from 14th to 18th, I really hope to see as much as possible of the faces I already know and hopefully a few new ones, but as much as I understood there is no new developer able to come to the meeting :(, they have all more or less foul excuses #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Kids always brighten up a house; mostly by leaving the lights on.
Re: Try File->New with 1.3.0cvs
On 28-May-2002 John Levon wrote: > On Tue, May 28, 2002 at 10:43:42AM +0200, Juergen Vigna wrote: > >> Well I disagree in return. It seems we have different opinions about >> will be supported and I'm pretty sure external scripts get not enough >> support! > > Well, our minipage and floatflt support in 1.2.0 wasn't too great was it > ? Well I would say tell with Lars about that, if I could decide I would have my best to make compatibility perfekt and as you know I didn't agree at all with Lars decisions of just droping some features! About the minipages I don't have any open bug assigned telling me that there are problems with them, so?! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ disbar, n: As distinguished from some other bar.
Re: Try File->New with 1.3.0cvs
On 28-May-2002 John Levon wrote: > On Tue, May 28, 2002 at 11:04:41AM +0200, Juergen Vigna wrote: > >> with Lars decisions of just droping some features! About the minipages I >> don't have any open bug assigned telling me that there are problems with >> them, so?! > > bug 374, 375, 376 are a couple of examples. I don't know if all of them > are fixed by Dekel's script. > > And the problem was that we didn't get enough examples of documents > early enough in 1.2.0cvs to be able to get all the cases. Trying to edit > that horrific minipage compatibility code any further is not a good idea > ... > > Even Dekel gave up and wrote a script instead, which I'm sure was much > easier... Well I don't know, but I doubt it. Give me example documents assign the bugs to me (as I think at least all of you fellow developers know that at least bugs regarding InsetText&Co. should ;) or put me in the Cc: list so that I have them in my list filter and I'll have a go for 1.2.1. I always thought that Dekels skript regarded only floatflt, but it seems I was wrong. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ To the systems programmer, users and applications serve only to provide a test load.
RE: File format robustness
On 28-May-2002 Jules Bean wrote:
> Then an old version of LyX can attempt to load a new version's docs
> ('Newer version detected, attempting to load anyway\n Unknown block
> type 'foo' ignored'), and, *most* of the time, a new version of the
> file format will just be a 'superset' of the old version, so a new
> version will be able to load old files without any problem at all.
Well have a look at the new tabular file-format it's exactly this :)
So you see we will go in that direction.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Cache:
A very expensive part of the memory system of a computer that no one
is supposed to know is there.
RE: cvs
On 28-May-2002 Andre Poenitz wrote: > How do I get a list of all branches? Well I go to lyxcvs (webcvs interface) and have a look at the tags branch selection field ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "Bureaucracy is the enemy of innovation." -- Mark Shepherd, former President and CEO of Texas Instruments
Re: [RFC PATCH] Require arguments when needed
On 29-May-2002 Lars Gullik Bjønnes wrote: >| us much, unless you have something in mind) instead of trying to specify >| better these arguments? > > Oh, I plan to specify the types of arguments as well + enforce them. I find this nice. Especially now the minibuffer should know if a inputed command needs an argument and can add the needed " " after the command if it is so. This also is a visual feedback there that we really are needing an argument. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Well, the handwriting is on the floor. -- Joe E. Lewis
Re: cvs crashes on start up.
On 29-May-2002 Lars Gullik Bjønnes wrote: > I like newsgroups, but sometimes I get the mail first... > Does it matter? Well when I hit replay it put's just the newgroup into the Addressbox, so that I have to delete it and put the lyx-devel To: address by hand, other than that I see no problem ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "In my opinion, Richard Stallman wouldn't recognise terrorism if it came up and bit him on his Internet." -- Ross M. Greenberg
Re: cvs crashes on start up.
On 04-Jun-2002 Lars Gullik Bjønnes wrote: >| Well when I hit replay it put's just the newgroup into the Addressbox, >| so that I have to delete it and put the lyx-devel To: address by hand, >| other than that I see no problem ;) > > Then I blame your mailreader/newsreader and not my using the newsgroup > for the postings. Sure it is my mailreader I stated that above. The problem is it sees the newsgroup-address and asks me if I want to do a "Post followup" and only if I reply to that question "No" (I only saw now that new question I never looked at it because I've never seen that type;) then it goes in normal "Mail-Reply" mode. But does it be a pro to put that there for you, it surely irritates others (me) #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Tuesday is the Wednesday of the rest of your life.
Re: 2.96 and boost::signals [investigation]
On 05-Jun-2002 Andre Poenitz wrote: > These are arguments in the real world. Compile times of more than an hour > and 563MB for a single build means that I can't use three out of four boxes > that I use regularly, including /all/ I have at home. > > The latter alone reduces the time I can potentially spend on LyX to a > quarter or so. > > Your recent changes are actively and seriously hampering LyX development. Unfortunately I have to give reason to Andre too. I thought to work a bit at Home on LyX in June, but now I'm copletely cut of my 450 PIII is not anymore enough to compile LyX #:O( We end up working on 1.2.x and leave 1.3.0 there were it is until we are able to work on it again. You tried the new stuff and that is more than ok, you got our responses which say, well it works, but at what costs! You will answer that it will decrease your interest if we take back and we will say that's a pitty, but if you leave it as is (and don't tell us we should help you, you know we cannot, we can just comment on the stuff in there) you will loose us for the time being. Maybe we will have the money to buy us some larger PC's in future but I won't count on it. Why not just retreat a step where we can again compile without rtti and exceptions (that means remove boost::signal and boost::regexp) which then permits us again to compile with lyxstring (which gives a really big boost to compile&link time) and go on with the important stuff. We can move all this changes up into a branch and there we can play with it and it is not lost to us. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If this is a service economy, why is the service so bad?
Re: 2.96 and boost::signals [investigation]
On 05-Jun-2002 Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > >| On Tue, Jun 04, 2002 at 06:47:35PM +0200, Lars Gullik Bjønnes wrote: >>> Not even an feeble attempt at trying to help fix anything, or even look >>> at alternative solutions. >> >| Lars: You lost quite a few of us. There aren't too many people left who >| are able to help you. > > and none trying to it seems... What you won't understand that we just cannot help you. Well I'm speaking from my part. What should I do that could help your, if not backing out some of the "new" features you introduced. The problem is that we don't know that code and we don't have the time to get it known. We know the LyX source so we could work on that, but that wouldn't get us anywhere, we have to work on the boost stuff to get out of the pit. You know we all have counted time and you force us to work on stuff we aren't really interested in working at. And that is the main problem IMO. As you and for that also me and others said it is a freetime project and we do on it what we're interested at. I know you are interested "a lot" in all this boost and "modern" compiler stuff, I for myself are not, but you want to force us to "be" interested in just that as otherwise we just cannot do other things and this attitude is wrong IMO. Let's do the transition in small steps. Let's back out the boost::signal and boost::regexp stuff go back to the one we used earlier, put that stuff up a branch where we can look further at it, remove the rtti and exeption options from compile/link phase and we're again to the same routine as in 1.2.x, wouldn't we? Greets, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ There goes the good time that was had by all. -- Bette Davis, remarking on a passing starlet
RE: ButtonController questions
On 05-Jun-2002 Michael Koziarski wrote: > Hey all, > > Lately I've been thinking about the layout of the GNOME dialogs. My > goal is to stick as closely as possible to the Gnome-2 Human interface > Guidelines (http://developer.gnome.org/projects/gup/hig/). > > One of the requirements for this is that properties dialogs should > automatically apply, and have only a close button. Same as in the tabular-dialog? Well you don't need a button controler if you do that, but what you need is a lot of interaction with the main core as the dialogs should update automatically to the new cursor position. After that you cannot f.ex. apply a paragraph layout to more than one paragraph only if you select them before but maybe you want to exclude some in the middle then you have to go to every paragraph and do the same actions again. Are you really sure this is the best option? It seems good in general but then if you have a look at the details it seems to me not that good in "every" case. Greets, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I'd rather laugh with the sinners, Than cry with the saints, The sinners are much more fun! -- Billy Joel, "Only The Good Die Young"
RE: Sponsor for LyX Developer Meeting
On 05-Jun-2002 Herbert Voss wrote: > for your interest ... > > http://www.dante.de, the German TeX User Group, is the official > sponsor of the LyX Developers Meeting. Did you organize this? Was this the official announcement? What does that mean in Euro #:O) A really curious, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ It is necessary to have purpose. -- Alice #1, "I, Mudd", stardate 4513.3
Re: 2.96 and boost::signals [investigation]
On 05-Jun-2002 Andre Poenitz wrote: > Developpers? Me at home, Juergen at home... And head that "Juergen at home" will most probably be the only developement station for me for the time being. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The question of whether computers can think is just like the question of whether submarines can swim. -- Edsger W. Dijkstra
RE: Porto - here I come
On 07-Jun-2002 Asger K. Alstrup Nielsen wrote: > Dear All, > > I have received my flight ticket now. Good! > I'll arrive in Oporto 12.50 on the 13th of June. > My flight back to Denmark leaves at 13.15 on the 17th of June. Just for the records I also got my tickets and will arrive the 14th at 12:20 and leave at more or less the same time the 18th. > Jose, could you please send your mobile number, and instructions > for how to get to your place? Same for me! > BTW, what is the abbreviation for this year's LDM? SILDEM? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ We have lingered long enough on the shores of the Cosmic Ocean. -- Carl Sagan
Re: rework of xforms configuration stuff
On 07-Jun-2002 Jean-Marc Lasgouttes wrote: > What are the versions of xforms that are linked against -ljpeg? > Actually, I use the static version of 0. here. Is the latest rc4 > still linked against -jpeg? This is an xforms bug IMO and if it > appears that it is fixed in 1.0 I do not want to catter for the > behaviour of the 1.0rcX (or 0. either). Why an xforms bug? This is a problem of the binary distribution on a system. Why should xforms statically link in libjpeg? This may be good on some systems, but on others it is nicer if libjpeg is loaded dynamically. So this at the end is not a problem of the xforms library but how people prepare it for their user! We should however support both versions one that needs external graphics libraries (-ljpeg -lxpm, ...) and one that doesn't need them because xforms linked them in statically. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The best way to accelerate a Macintoy is at 9.8 meters per second per second.
Re: compiler error cvs
On 10-Jun-2002 Lars Gullik Bjønnes wrote: > Are you sure you do not need a clean build? > > When did this error emerge? > Have you compiled 1.3.0cvs successfully earlier? Well I get /data/soft/lyx/lyx-devel/src/frontends/controllers/ControlDialog_impl.C:21: undefined reference to `ControlButtons::bc(void)' /data/soft/lyx/lyx-devel/src/frontends/controllers/ControlDialog_impl.C:21: undefined reference to `ControlButtons::view(void)' And I did the build 3 times and one with maintainer-clean. Do I really to make a fresh co? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS. I'm very probably wrong.
Re: gui work - and bloat...
On 11-Jun-2002 John Levon wrote: > Who is it ? Do they have the time to liaise with me on getting work into > the tree in a form agreeable to all ? Off topic! A pitty you don't come to the meeting then. You'll see that there will be a big change during the meeting as we always did we will work a lot also this year and IMO we will concentrate on the GUII. And if we will make things different to the implementation you already did then it's only your fault as you're not there to speak up #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "Earth is a great, big funhouse without the fun." -- Jeff Berner
Re: gui work - and bloat...
On 11-Jun-2002 Lars Gullik Bjønnes wrote: >| I've said it before, I'll say it again: the fact that there are still >| LyX users despite the user interface it has speaks wonders for how >| useful LyX is > > I am a bit uncertain why all this flamage is beeing directed at me... > (was it a good party tonight?) Well one has to take it and it seems you're just the right one this time (not because of any particolar reason just because you're far away still and can't hit anyone) I will stop doing it as there will be a certain risk starting at Friday 15:15 when you'll arrive ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Ahh... the smell of cuprinol and mahogany. It excites me to... acts of passion... acts of... ineptitude.
Re: gui work - and bloat...
On 11-Jun-2002 John Levon wrote: > I agree totally. It was the deadlock that had "annoyed" me ... now > you've said it's simply livelock instead, then it can certainly wait. Don't do that pester us this days as much as you can. Put as much of your stuff into the HEAD branch as Lars permits (I'm sorry I delegate this only to Lars but I'm really bussy now doing other things and don't have the head to concentrate on this stuff). The more you are able to commit more similar will be the outcome after the meeting! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Let's _not_ bring that into this thread, OK? - Al Viro on linux-kernel
Re: Math panel keyboard focus.
On 11-Jun-2002 David Kastrup wrote: > Please don't overgeneralize. Even many users that have had suffered > extended exposure to Microsoft Windows prefer focus following mouse. Well I have to disagree here. I really don't like focus following mouse and as soon as it was possible to shut it of on our X-Terminals and then Linux workstations (changing from twm to fvwm) I did it. I like to not pay attention to where the mouse is and do a lot with the cursor. I don't know if it is possible to create windows which never get input focus, but I think it should be. And this is definitively the way to go for dialogs with only buttons and no "keyboard" input fields. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Bit rot
Re: Math panel keyboard focus.
On 11-Jun-2002 David Kastrup wrote: > That is exactly the sort of overgeneralization that I was talking > about. But I didn't I just told you that "I'm" not one of your "many" users and not because I suffered MS something as I'm working 100% on Unix! It seemed to me you generalized in your sentence, but if I was wrong I'm sorry. IMO that on Unix there are more and more people using "click to focus" policy then "focus follow mouse" but I may be completely wrong here too (here we work 100% on Linux workstation and all of our ~50 user use "click to focus"). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I'm encased in the lining of a pure pork sausage!!
Re: Math panel keyboard focus.
On 11-Jun-2002 David Kastrup wrote: [snip] > Here is the extract which you conveniently snipped: [snip again] > So you quite obviously expressed disagreement about whether many users > might prefer focus following mouse. If you intended to mean something > different from what you wrote, that is fine, but first cutting away > the evidence and then claiming it meant something entirely different > from what you wrote is quite misleading. Well I meant what I meant and I assume that people writing to the mailing list know what they wrote and people reading the mailing list should be able to follow a tread, so I don't think it's always necessary to quote back a lot, as one should have the "evidence" in his mailbox :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ An artist should be fit for the best society and keep out of it.
RE: A solution to the "center" problem?
On 12-Jun-2002 Jean-Marc Lasgouttes wrote:
> It occured to be today that \begin{centering}foo\end{centering} works
> perfectly well. Before I make the change I have to ask: would people
> be pleased with it?
Well Jean Marc it's not only centering it's any alignment excluded
"block". I agree if it does not add vertical space the above is perfect,
but we would have to find solution also for the other cases!
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
The more cordial the buyer's secretary, the greater the odds that the
competition already has the order.
Re: A solution to the "center" problem?
On 12-Jun-2002 Jean-Marc Lasgouttes wrote:
> Juergen> Well Jean Marc it's not only centering it's any alignment
> Juergen> excluded "block". I agree if it does not add vertical space
> Juergen> the above is perfect, but we would have to find solution also
> Juergen> for the other cases!
>
> Do you really think I am _this_ dumb?
Sorry I just wanted to remind you! And do you really think, I think, you
are _that_ dumb? #:O)
> I have to double check the latex docs, but basically, I think that
> most commands that can be used as {\foo ...} can also be used as
> \begin{foo}...\end{foo}. So of course it should work for other
> alignment macros, but also, if we ever need it, for
> \begin{sffamily}...\end{sffamily}.
Good. The question is why didn't we do this in first place. Well
I think it was latex ignorance, wasn't it? I'm really happy you
found a solution as it was really bad behaviour when working with
tabulars and trying to left or centeralign a paragraph inside a fixed
width column!
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
I did this 'cause Linux gives me a woody. It doesn't generate revenue.
(Dave '-ddt->` Taylor, announcing DOOM for Linux)
Re: [Bug 424] build fails on ppc
Quoting Lars Gullik Bjønnes <[EMAIL PROTECTED]>: > I find it _very_ hard to use bugzilla for discussion bugs. Me too!!! (but I read the whole bug report before replying to it on lyx-devel if I want to discuss it publicy and not only with the reporter) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Jürgen Vigna E-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel.:+39-328-6368761 I-39050 Steinegg Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ - This mail sent through IMP: http://web.horde.org/imp/
Re: Generating previewed snippets yourselves...
Andre Poenitz wrote: > On Sat, Jul 06, 2002 at 12:31:16PM +0100, Angus Leeming wrote: > >>I'm sure that the wizards will be able to help here. Wizards, are you reading >>this? I'd like to generate small batches of these previews, say for the first >>three or four screen heights. Thereafter, if I arrive at an inset for which a >>preview hasn't been generated, I'd like to generate previews for three or >>four screen heights around it. Any thoughts on an interface? > > > Remember that currently we have problem with the "on demand" loading as > done by the graphics insets. We'll certainly run into the same problem when > we do that with the previews. So I'd still try to load everything ASAP, at > least we might consider doing that "size caching in the .lyx" thingy. What problem do you see here? I cannot look at the code right now but IMO that when terminating to convert the images a signal is called which then enters all insets and loads the requested file is this true? Well IMO it's really easy to decide inside the inset that it is actually not in a position where it is displayed so loading of the image would not be needed and we just return from there without doing anything. We only redraw the inset where we need to and that would be really fews. I don't think that iterating over all insets in the buffer takes that long actaully I think it should be quite fast, what takes up the time is loading of the images into the buffer and then redrawing in when it is not needed. So I think that David is right and that this is easily doable, but maybe I just didn't understand exactly what you really do and so my above proposal is not really doable. Jug P.S.: I sent a few replies to the mailing list this morning but I only now see that I always replied to the sender only could the people please forward the messages to the list. Thanks! -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
This is one of the mails I wrongly didn't send to the list so I answer now to the list :) Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 08:45:55AM +0200, Juergen Vigna wrote: > >>Well I think that an opinion for this is a hard thing to do as most >>of us don't know how mathed works internally. I know you have one >>cursor and passes this cursor down so that every inset can put therein >>it's locking inset. It seems you can transverse the inset with this >>cursor the only problem I see is that you sometimes crash because >>you depend on this cursor for a lot of operations also if no cursor >>is required. > > > Hm... lets say I have "deep iterators" and the math cursor is just a pair > of them for selection anchor and the actual cursor position. Such an > iterator is basically a vector<> of triplets (inset pointer, cell in > inset, position in that cell). Well then it's basically the same as we have only we don't have all the information saved if we don't need it. You for any inset have all information allocated even the ones you don't need. On the other hand you have all in an external structure on the same place in InsetText you have this information inside the insets "private" data. > For traversing insets the math cursor is not needed, one should use such an > iterator instead. Ok! > Again: Inset locking is not needed in mathed, the math cursor is not > needed for inset scanning, so s&r is trivial to implement _within the math > hierarchy_. The interface to the "external" s&r code is the problem. > > Concerning the crashes. Short of calling that "FUD": first of all, so far > these have been programming errors and not technical problems even if > interfacing the two inset hierarchies is neither trivial nor nice. But > as I were suggesting to make the two hierarchies into a single one, one > should assume that things are simpler afterwards as exactly these problems > will magically disappear. Well it may be trival to implement _after_ you made all other insets "math-alike", but now I've seen you would have big problems at least to implement the "r" part (and I admit this is not only your fault). This could be fixed by adding another function to the actual insets which do the replace (seems cleaner somehow) instead as it is done now where you need the LyXText to replace and obviously mathed does not contain a LyXText ;) >>>If the latter, it would be nice if a few (if possible technical) reasons >>>were given. I gave a few for the 'pro' side in a previous mail, so I >>>think they do not need to be repeated. >> >>Same as above. The only thing you should keep in mind is that _text_ and >>_mathed_ is struktured differently. IMO text is a bit more complicated > > > If that were 'current text implementation is a bit complicated' I'd agree. > [Well, I'd discuss the 'a bit' bit...] Text per se is not complicated but I > probably need to do some more work on mathed's text support to have 'hard > facts'. > > What exactly makes you think that "text is complex"? That not everything is an inset ;) and I explained already why this is so. >>and we have to regard also performance so seeing all (also normal text) >>as an inset is IMO not the right way to go right now. > > > Math tables are on par with real tables performance-wise. I have no timings > on plain text as the current math text support is too weak to have "real > world" examples. Well come on make a 50x50 math tabular and then put stuff inside and see how it behaves. InsetTabular does not have any problem with small arrays, but the performance is checked with really big tabulars. >>But you may try it on a branch appart and we will have a look how it >>works and if it really brings something to the LyX kernel, be it in >>performance be it in clean code. > > > Ok... Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Replay to list instead as it should go there in first place! Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 08:55:15AM +0200, Juergen Vigna wrote: > >>I don't get you here IMO that Insets ARE unified already the only >>ones not being in that class are _mathed_ ones. > > > And I believe mathed's approach is better. Not because it is my idea (which > it isn't, it's Alejandro's idea) but I have seen it working nicely. > How long would you need to implement some \fbox inset in the old hierarchy? > [Note: You lose if that's more than 20 minutes.] \fbox what is that a text in a fixed width box? Anyway IMO any boxed text command would be really easy to implement in the actual state and would BTW be a really small file ;) I cannot tell about minutes as I first probably would have to understand how \fbox works and that would take some time :) >>And as I told you I really think this should go off in a branch as >>this _really_ can compromise the main core. Let's see how it works >>and we will all be better of deciding then IMO. I'm also sure that >>if you do a good work it will surely be merged with the trunk and >>you can merge it whenever you think it is really not harassing the >>working behaviour and we could have a look if this is true (with our >>own tests ;) > > Indeed. > > And you should start making tables a bit faster otherwise I can tell > already where you lose ;-) IMO tabulars a pretty fast right now, prove that for mathed arrays ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 09:17:28AM +0200, Juergen Vigna wrote: > >>What problem do you see here? > > > The cursor jumps wildly when scrolling down the documents. To a degree that > LyX is unusable if you have lots of images. I believe storing the image > size in the .lyx file might improve the situation a lot. Well normal graphics should do that anyway! I don't know if that would help for stuff like preview, but it wouldn't be worse too, would it? >>IMO that when terminating to convert the images a signal is called which >>then enters all insets and loads the requested file is this true? Well >>IMO it's really easy to decide inside the inset that it is actually >>not in a position where it is displayed so loading of the image would >>not be needed and we just return from there without doing anything. > > > But when we need it there is a delay of up to several(!) seconds. Not nice > when 'jsut scrolling down'. Are you sure? The image is already converted you just have to load it and display it I don't think that should take so much time for a screen full of images and if you want you always could "preload" a screenfull of images before and behind the actuall displayed size, just not all of them. >>P.S.: I sent a few replies to the mailing list this morning but >> I only now see that I always replied to the sender only could >> the people please forward the messages to the list. Thanks! > > > Some to me? I'll have a look what's left. I usually delete read mail... I already sent the replies to the list so they will actually only loose the original post ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 09:35:23AM +0200, Juergen Vigna wrote: > >>\fbox what is that a text in a fixed width box? Anyway IMO any boxed >>text command would be really easy to implement in the actual state and >>would BTW be a really small file ;) I cannot tell about minutes as >>I first probably would have to understand how \fbox works and that >>would take some time :) > > > \fbox just draws a box around its argument. Do you want it collapsable? >>IMO tabulars a pretty fast right now, prove that for mathed arrays ;) > > > Do I smell a challenge? #:O) > And if you lose, you implement \multicolum support for math arrays (this is > currently _really_ a disadvanteg of math tables)? ;-) You're dreaming of that aren't you ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: >>>iterator is basically a vector<> of triplets (inset pointer, cell in >>>inset, position in that cell). > > Which information do we have that we don't need. I don't know for mathed but it seems that for normal text I wouldn't need the cell, would I? > No. That's just because I don't have 'reverse_iterators' yet which are > straight forward to implement if you look at math_iterator.[Ch]. But as I > did not really need them for internal stuff I just did not implement them > so far. No I don't think you solve the problem with iterators the problem is as you said in the interface and that a LyXText is necessary, when it shouldn't, but you see before all text has been in a LyXText so we didn't have to care for other posibilities this now is obviouly not true anymore (but we did discuss this briefly in the meeting, didn't we?) so we would have to change the "replace" interface the "search" part is ok IMO. > mathed will never contain a LyXText. That does not mean that text handling > would be impossible (and in fact right now we already have font changes. > The big remaining issue is line breaking, that's why math text is not yet a > replacement for LyXText) Pay attention that you don't reinvent the wheel. LyXText is LyXText because of all the line/paragraph breaking algorithms IMO you're better of to use LyXText (or a InsetText) for your text and tell us what is so bad in it and what you think could be made better then reinvent all of this again. > Everything is an inset. Repeat that mantra. I don't think of this as mantra I don't believe in this. > The depends on what's in the table. Currently your tables are usually > faster, but not always. Apart from that I know why this is as it is, and > part of that problem is again the interface of the math inset and the > enclosing paragraph. Tell us what problems you have with the enclosing paragraph? > So is performance the killer criteria? Say so and we can have a shoot out > in four weeks time ;-} Ha your telling this because you know that I don't have any time to code on LyX right now, so you would have all the time to make my code slower ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Andre Poenitz wrote: > Yes. I am still unable to read some documentation containing lots of > screenshots created with 1.1.6fix4 with neither 1.2.0 nor 1.3.0cvs. IMO you're mixing stuff here. InsetGraphics right now still starts to convert the image when it should be displayed and that is what you see as delay. What we were talking about is if you already _have_ the converted image and only have to load and display it! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Angus Leeming wrote: > On Monday 08 July 2002 10:05 am, Juergen Vigna wrote: > >>Andre Poenitz wrote: >> >>>Yes. I am still unable to read some documentation containing lots of >>>screenshots created with 1.1.6fix4 with neither 1.2.0 nor 1.3.0cvs. >> >>IMO you're mixing stuff here. InsetGraphics right now still starts >>to convert the image when it should be displayed and that is what >>you see as delay. What we were talking about is if you already _have_ >>the converted image and only have to load and display it! > > > Yes. Unfortunately if I have 1000 equations in a thesis then loading them all > takes a significant chunk of time. Minutes. > > I really like Lars' idea of a separate thread, especially if we combine it > with an intelligent queue so we can send off 40 equations or so at a time. _PLEASE_ enlighten me here. Are you talking about _loading_ or about _converting_ or maybe about both? I think we should make a distinction about _convert_ an image and _load/draw_ and image. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Angus Leeming wrote: >>_PLEASE_ enlighten me here. Are you talking about _loading_ or about >>_converting_ or maybe about both? I think we should make a distinction >>about _convert_ an image and _load/draw_ and image. > > > Just loading. > > The preview code will gather all the latex snippets together and send them > off as a forked process to convert to X image files of PPM format. LyX > (xforms) can load these natively. It is this loading process that takes time > for 1000 equations. Hence Lars' idea of a thread. Ok that specified how much time takes it to just load 1-3 screenfull of images (obviously not only images but the screenfulls of your document)? It is not necessary to load all images at starting of lyx but only when they are needed. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Angus Leeming wrote: > > Yes. This it would make sense to do this too. That's the first thing on my > list of improvements. We'll see if that provides "acceptable" performance. > > Along these lines, I think if it's a good idea if we can prevent loading > while we're scrolling. Ie, if I'm moving the view using the scrollbar or the > arrow keys, loading should be disabled. Only when I've stopped this and the > screen position hasn't changed for a second or so should loading be started. > > What do you think. Is this possible? Not in the first go, but with a bit of work maybe yes. This implies that not InsetGraphics::draw() does the loading if needed but most probably the BufferView has to do this then explicitely. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Andre Poenitz wrote: > I'd do that, but on the loader side: > > If an item is added to the 'to-be-loaded list', start a time out of a > second or so, and only if there are no new items added to that list, start > the actual loading, otherwise restart the timer. The more advanced version > of that would then re-order requests such that "needed" things go first. > Well, maybe a simple stack is already sufficient for that... > > So this would be completely transparent to client code (the buffer etc) and > everything is well encapsulated within the loader. IMO you're thinking too complicated ;) I think that graphics I just scrolled up but are way away now don't have to be loaded. BufferView knows what it displays and just has to request loading/redrawing of the graphics insets it displays a certain time after scrolling stopped. The insets then know if they already loaded/displayed correctly or have to do it on the request! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 11:54:29AM +0200, David Kastrup wrote: > >>My pleasure. You don't want to load 1000 image files into LyX when a >>majority of them will never be displayed on screen since it is highly >>unlikely that a particular editing session will rediplay the entire >>document. Load them when you need them, not before. > > > I usually scroll to the bottom of the doc and continue working from there. > So "usually" I'll see most things jsut once, but I'll see them. Well I use Ctrl-End for this and it brings me at the spot without displaying the whole of the document. But I think this can be handled with the delayed loading model Angus told us, can't it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 12:18:51PM +0200, Juergen Vigna wrote: > >>>What do you think. Is this possible? >> >>Not in the first go, but with a bit of work maybe yes. This implies >>that not InsetGraphics::draw() does the loading if needed but most >>probably the BufferView has to do this then explicitely. > > > I do not want any preview code in the BufferView (nor in the Buffer, nor in > LyXText etc for that matter) And if that's not reason enough I'll call my > big brothers... Start to call then :) This is not "preview" stuff it is just "loading graphics on demand" stuff and I think this can be in BufferView! Not all of lyx graphics is connected to "preview", is it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Jean-Marc Lasgouttes wrote: >>>>>>"Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: >>>>> > > Juergen> IMO tabulars a pretty fast right now, prove that for mathed > Juergen> arrays ;) > > Did you ever see this message? > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg35736.html > > There is an example file attached at > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg35739.html I tried it with current cvs version (just now) and for me all seems perfectly sound. I tried to select all cells in every table in the file and I don't get any cpu usage (only while selecting), but the selection is so fast I cannot follow it. So what should I learn from this? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 01:38:37PM +0200, Jean-Marc Lasgouttes wrote: > >>Juergen> IMO tabulars a pretty fast right now, prove that for mathed >>Juergen> arrays ;) >> >>Did you ever see this message? >>http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg35736.html > > > Aehm.. I just wonder: How do I delete a rectangluar region from a table? > Selecting it end pressing 'del' does not seem to do the trick... I use Ctrl-x anyway you have to use a "cut" operation! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Angus Leeming wrote: > Could you two great minds think of ways of improving the interface to do what > we'd like to do. The rest should be hidden inside the implementation. Well I cannot comment on your implementation (I don't have the time to look over it in detail), but I will give you a realtime example of what I think and why it should be in BufferView. Think of being Andre opening your workfile and scrolling till the end of the document. What should happens now: 1. All previews/graphics should be converted to a loadable format 2. I would like to display the part of the graphics I'm actually in and am not interested to wait till all other graphics I passed truth are displayed to. 3. Only the really needed graphics should be loaded and displayed 4. Who knows about where I am in the document? Yes ONLY LyXText which is part of the BufferView and BufferView is generally the passed pointer. 5. BufferView should now after I stopped scrolling for "n" bits of defined time request the loading of the graphic segments I'm displaying right now. For this it should advise the insets actually displayed to load it's graphics and fix it's width (if it differs from the saved one which could be). 6. We have to do a rebreak of the text starting at the first displayed paragraph-row. 7. We have to redraw the screen. That is how I see it. But please fill in the gaps how you would see the whole process and where I'm wrong. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Jean-Marc Lasgouttes wrote: > At the time when I tried to profile it I saw a number of redraw > operations of the whole table that were very unreasonable. Maybe is it > not relevant anymore. > > I just thought it was a good time to remind you about this one. Maybe there are a lot of redraw events but the tabular won't draw anything if it is not necessary. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 02:03:22PM +0200, Juergen Vigna wrote: > >>I tried it with current cvs version (just now) and for me all >>seems perfectly sound. I tried to select all cells in every table >>in the file and I don't get any cpu usage (only while selecting), >>but the selection is so fast I cannot follow it. So what should I >>learn from this? > > > That you change it do 'WORKS FOR ME'. Works for me, too, btw. Hmm and how should I do that in the mail-archive? Or is there an open bug on this too? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Edwin Leuven wrote: >>Maybe there are a lot of redraw events but the tabular won't >>draw anything if it is not necessary. > > > but as you said, selecting *is* very slow (much too slow I think, often I have > to wait for LyX!) When did I say that? I don't see it slow here. But it may depend on the hardware we use. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
> I don't think you're wrong. I'd just like to implement it so that the Inset
> does as little as possible. I think I see how we'd do this, but I need your
> help to turn it into working code.
>
> The plan
> ===
> 1. Don't load all image files once they are converted.
> 2. insets ascertain whether they should use the previewed image with
[snip]
I have the impression that we talk of different things. While you're
fixed at the preview level I think at a more general "graphics" level.
I don't care about the implementation of "preview" I care if and when
a graphics file is loaded and/or displayed.
void SomeInset::draw(...)
{
[am I in the range I need to be drawed?][no] return!
[need to draw a graphics file]
[is graphics already converted]?
[no] goto really_draw
[yes] load graphics file; goto really_draw
really_draw:
[am I visible]? [no] return!
[draw myself]
}
This is more or less what I think the inset should do now. What
we can make better in the above design is the "delaid" loading
of graphics files. To do this IMO we would have to split the
loading from the drawing part. That means that loading the graphics
into memory has to be requested by someone. I see this something like:
[i am scrolling now]
[i stopped scrolling]
[call load graphics on all insets in 2 seconds]
after 2 seconds
[iterate over all insets and do]
[bool loaded = false;]
[loaded = loaded || inset->loadGraphicsIfAvailable()] for all insets
[if loaded rebreak_the_text() and redraw_the_screen()]
Am I clear what I think now?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122
I-39100 Bozen Web: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Angus Leeming wrote:
> We're talking about /exactly/ the same thing.
Well I said I have the impression when I read your last post ;)
> I /want/ to invoke startLoading() from within Inset::draw.
>
> I /do not want/ to do it without a little care.
>
> I envisage something like:
>
> Image::startLoading(Inset * inset) {
> // call REALLYstartLoading(inset) in 2 secs time
> startTimer(2, inset REALLYstartLoading)
> }
>
> Image::REALLYstartLoading(Inset * inset) {
> if (!inset->isVisible())
> return;
>
> // load it
> ..
> }
>
> Similarly in BufferView::updateInset(Inset * inset) {
> if (!inset->isVisible())
> return;
>
> inset->draw();
> }
What I miss in all this is the "rebreaking" where would you
put that here?
> So, my question again. What's the equivalent of "Inset::isVisible()". I /do/
> know the BufferView.
Ok. No we don't have a isVisible function right now and I don't think
this is easy to make as the "visibility" depends on the x,baseline
values passed as parameters to draw, which could change if I have to
rebreak the text after the loading. You could have a look at the
tabular.C or insettext.C draw functions. I just draw the visible
parts there, but for a graphics file with a fixed hight it could
be as easy as "if baseline+graphics_height > 0 then draw".
> You know, /if/ there were such a method or way of ascertaining this
> information, then BufferView::updateInset() should also use it to not redraw
> things that aren't visible. That would stop all those "the cursor jumps all
> over the place as the graphics insets are loaded" problems that people moan
> about now.
>
> void BufferView::updateInset(Inset * inset) {
> if (!inset->isVisible())
> return;
>
> inset->draw();
> }
I don't think we can do this.
> Capito?
Sure I hope you too.
Jug
P.S.: Is it only an impression or do I get mail doubled again :)
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122
I-39100 Bozen Web: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > On Mon, Jul 08, 2002 at 05:32:53PM +0200, Jean-Marc Lasgouttes wrote: > >>What I mean is that there are AFAIK different design choices in normal >>and math insets. And then there is the problem of the quality of the >>existing implementations. These are two different things, although >>both are very important in practice. > > > The main problem is that both approaches are not really compatible. > Of course, we have it working _somehow_, but the interface is far from > nice... Agreed! >>Basically I see that Andre' says math insets are better, Juergen says >>the opposite. They are the ones who know about it. > > ... and the second problem is that neither of us knows both sides well. Agreed! >>And then, why am I supposed to say sound things? > > Because usually nobody else does. The only right answer, Andre #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Angus Leeming wrote:
> On Monday 08 July 2002 4:36 pm, Juergen Vigna wrote:
>
>>Ok. No we don't have a isVisible function right now and I don't think
>>this is easy to make as the "visibility" depends on the x,baseline
>>values passed as parameters to draw, which could change if I have to
>>rebreak the text after the loading. You could have a look at the
>>tabular.C or insettext.C draw functions. I just draw the visible
>>parts there, but for a graphics file with a fixed hight it could
>>be as easy as "if baseline+graphics_height > 0 then draw".
I forgot here obviously that it should be < screen height!
> Excuse me if I'm being dumn, but do you do have this info to hand because you
> only call Inset::draw for a small set of Insets at a time. All you need to do
> is cache this info. Something like:
>
> vector visible_insets;
>
> void Your_Main_Draw_Routine () {
> visible_insets.clear();
> for (some group of insets) {
> inset->draw(...);
> visible_insets.push_back(inset);
> }
> }
>
> bool isVisible(Inset * inset) {
> vector::const_iterator it = visible_insets.begin();
> vector::const_iterator end = visible_insets.end();
> it = std::find(it, end, inset);
> return it != end;
> }
>
> Am I wrong?
Yes we could do that, but what happens if we have a rebreaking
of the rows (and we most surely will have if sizes change). Then
the above information is not valid anymore and you have to ask
the single insets again. But on the other hand we don't care if we
load one or 2 insets too much the important part is that the
row rebreaking is good afterwards.
bool SomeInset::loadGraphics()
{
if (graphicsAvailable())
return loadGraphics_setDimensions();
return false;
}
bool SomeInset::loadGraphics_setDimensions();
{
if (!graphicsAvailable())
return false;
loadGraphics();
setDimensions();
if (dimesions_changed)
return true;
return false;
}
I guess somewhere in BufferView:
...
bool do_rebreak = false;
for in in all_visible_insets(); do
do_rebreak = in->loadGraphics() || do_rebreak;
done
if (do_rebreak)
rebreakLyXText(par_of_first_vis_inset, par_of_last_vis_inset);
redrawScreenIfNeeded(); (== update() call ;)
...
Do you think something like this would work?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122
I-39100 Bozen Web: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
S+R already fixed
Well I had a look into the sourcecode (as I had a spare minute) and discovered that the changes to S+R have been already commited by Lars quite some time ago. Strange nobody noticed??? Did the patch not work or is nobody using S+R ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: S+R already fixed
Michael Schmitt wrote: > Hi Jürgen, Hi Michael! > I tend you use 1.2.x instead 1.3.0. How big is your S+R patch? Can it be > back-ported to 1.2.1cvs? If you can send me a patch against 1.2.1cvs, I > will give it a try. If it takes too long for you to prepare such a > patch, you could give me a hint on which files have been modified. If > their number is < 10, I will try to backport S+R on my own. Yes, > I REALLY need a good S+R :-) Please have a look at the attached patch. It is practically the same as in 1.3.0 (I had only a trivial problem in formulabase because of lyxfont changes in 1.3.x). Jean-Marc if you think you want this let me know and I apply it with some ChangeLog entries :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ s+r.patch.gz Description: GNU Zip compressed data
Re: S+R already fixed
Michael Schmitt wrote: > I will patch my 1.2.1cvs this evening. Since I use LyX excessively at the > moment, we could agree on waiting for a week or so and see whether I get > into trouble. When processing smaller docs, I could run valgrind to make > sure that S+R does not corrupt the memory. Good! > Jürgen, does the patch solely affect S+R or are there other functionalities > that deserve special testing? There is only one general change which should affect also spell checking (the reclosing of collapsable insets) but that is a one liner and pretty save. I think that actually the whole patch should be safe at it removes a lot of unclean code, but we will see what your tests say :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > Events are handled bottom-up. The most nested inset that claims the ability > to handle the event, wins. [Well, currently it's like that only for mouse > clicks and hard-wired for things like 'add row to array' but I intend to > extend that consistently to all "events"]. So when clicking on a URL in a > minipage the URL can handle the click first. Well this seems indeed VERY strange. How would you do that? As much as I know of the structure BufferView gets the click and delegates it to the topmost inset, which then delegates it to it's childs if necessary (click really hit a child). I guess that as you know from the top-level-inset with your cursor the innermost inset you could then jump from the outermost to the innermost and then return outside could you explain a bit better how this works in mathed, as the above explanation is not really exact, is it ;) > Redraw is "always redraw everything" but uses cached sizes of nested stuff. > I fiddled a bit with more selective redrawing and it was not too bad > except for the macro editing, so I decided to leave it as it is for the > time being. I have a gut feeling that this is possible anyway. I think here is the real difference between InsetText and Mathed. Mathed has more or less fixed sizes while the InsetText depending on the outside world may have to rebreak it's rows and adapt it's sizes and not only it but has to delegate this also to all child insets as they too may change sizes. And this was the big difficuly in getting the Inset in it's now more or less working state and this is also the main problem why we still see that nested insets are slower to update the normal text. You have a lot more stuff to do for which you don't care in normal text. > I don't really no what checkInsertChar() does ... ok, had a quick look. > There are no back references from the ownees to the owner. But as the > insertion of a char is handled by the innermost inset that claims to be > able to handle the insertion of _a_ char, this inset can check whether it > wants to handle _this_ char and e.g. do nothing but return a "I handled > this" or do nothing and return a "I do not want to handle this". Well this is the same for all inset! I see no difference in the handling here. >>I have found the existing inset locking method to be very difficult to >>understand, > > So have I. Well maybe I don't see it so because I wrote that code and it seems pretty easy to understand to me. For me it's much more difficult to understand how mathed does the same stuff and how delegation works there. In InsetText I have a top down delegation and then a down top back tracking. This means that I go to the innermost inset first and if that doesn't want to handle the event I return from there always one level up till the outermost inset. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > On Wed, Jul 10, 2002 at 04:20:05AM +0100, John Levon wrote: > >>It's a massive class ? I defy you to come up with a single-sentence >>description of LyXText ... > > > And make sure that this description does not contain the word 'and' ;^) Well that's not fair I was already half true in writing the description (it was about 3 A4 pages) and still was in the first sentence, then you come up and ditch all my hard work #:OP Seriously I know that the class is big and it does a lot of stuff. We could maybe put some functionallity in another module, but IMO that we _need_ all the functionallity inside LyXText to really draw our screen the way we want it drawn. Tell me the parts you think can be droped I don't think you'll find much of them. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Dekel Tsur wrote: > On Mon, Jul 08, 2002 at 09:32:27AM +0200, Juergen Vigna wrote: > >>Well come on make a 50x50 math tabular and then put stuff inside and >>see how it behaves. InsetTabular does not have any problem with small >>arrays, but the performance is checked with really big tabulars. > > > One area in which there is a great performance difference between > InsetTabular and mathed arrays is nesting: > try nesting 10 2x2 tabulars/arrays and see which is faster > (this is not a real life example, but it is interesting for comparing > code efficiency). I know that nested tabulars get slower on every nesting level and maybe we can make something there. I know also why it is slow because we have to recalculate all of the cells if one column get's larger I just didn't find the way to make it better. All of you are invited to help out and tell me where I'm wrong. I tried a lot of optimations and some did work (try to see the difference between tabulars in 1.1.6 and 1.2.0, but some of them I had to ditch because the the update/redraws where wrong in some cases. As I told you we all know the backsides of actual tabular implemenation but I don't think that a lot of people would like to go back to tabular implementation before 1.1.6 after they get used to all the new functionallity. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
John Levon wrote: > There's a bug on it. > > http://bugzilla.lyx.org/show_bug.cgi?id=164 > > You aren't seeing this bug unless selecting eats CPU big-time. I can't > reproduce such a problem. > > See my last comment (this is exactly why closing bugs that aren't really > closed is a bad idea ...) Well then we have to find a better way. I don't like open bug I cannot reproduce and I think are fixed. Let's set them to "Works for me" instead of "fixed". I understand that you reopened the bug as it is still present in 1.2.0 I didn't see that it was assigned to 1.2.0. Anybody know how I can filter out bugs in older versions, which are fixed in the new ones? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Generating previewed snippets yourselves...
Angus Leeming wrote: > > Jürgen, I'm sinking fast in a pile of poo. However I think that this gives me > the paragraph that is currently visible at the top of the LyX screen. #:O) > BufferView * bv = ...; // I have a cached copy of this. Where are you here. Where should the below piece of code pe placed. (this is important to know!) > LyXText * text - bv->getLyXText(); You only care for bv->text. For this stuff you have always start from the topmost place IMO. > int const top_y = text->first_y; This cannot be const as it is set in the below call to the right y value! > Row * row = text->getRowNearY(top_y); > Paragraph * par = row->par(); Otherwise your pretty there ;) > If that's right, then that's all I need. I'll just load all previews for > insets in the 5 pars on either side of this using Paragraph::next() and > Paragraph::previous(). No I think you always should load all of one paragraph and then check if the first row of the following paragraph is still visible on screen if yes iterate above. > Am I on the right track? Yes more or less, but I will bring you there #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > It is fairly exact as it describes how it works in mathed not outside. > > When mathed currently gets a click, the cursor is positioned as close as > possible and the event is passed up along the cursor path until some inset > is willing to handle it. I'm confused now in your former mail you said it works from the innermost one to the outermost and now you are telling me that it's exactly the opposite. > Yes, that's exactly the opposite as it works outside but that means that > insets only have to be aware of events they want do handle and simply > ignore the rest, whereas "oustside" every inset has to pass down all > "unknown events". I don't understand this claim and I don't believe it. Can you please explain this for dummies like me and maybe make a real-world example so that I'm able to follow what you mean. > I am aware of these problems but I think they are solvable. I have Well I think most stuff is solvable so we think the same here :) > pre-alpha code for a \parbox implementation that would exactly do that. > But this is far from finished, so mathed is currently no replacement for > InsetText. \parbox is very different as it too has a "fixed" size doesn't it? What you have similar in a parbox is that you need to do automatic row breaking, but still for the outside world the inset will always have a fixed with, if you don't change it in a layout and then you have to rebreak it only one time. > I believe that this was not easy to get right in InsetText and I believe it > won't be easy to get right in mathed. But there is no evidence that it is > technically not possible. Did I say so? > Bottom up along some iterator which in most cases is the one representing > the cursor position in *mathcursor. What happens if you don't have a cursor? I mean what handles if I have size changes and no cursor inside the mathed inset (think of undo!) > So the events are handle by the innermost inset as well. I am doing exactly > the same. The only difference is that enclosing inset does not do anything > at all if the event is handled by some deeper nested inset. No big deal. Well that's the same in all insets (see the handle of pre_events in insettabular), but most events have to pass the innermost InsetText as we don't know if it wants to handle it or not. We could also in lyxfunc put some functions before the call to LocalDispatch of the inset, but it really isn't important as if the inset does not handle the event in time cosumation it is negligible if we enter there and do nothing or if we don't, IMO on the other hand we are on the safe side if we enter as we then are sure the inset does not handle it. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > I am not. The event is passed _up_ along the cursor path. Well ok we talk of the same then and this is also the same for InsetText. Same behaviour just we don't have a global cursor we have to go up by theLockingInset(). What I _really_ would like to change is in InsetText the use of LyXText::the_locking_inset so that the private variable has to disapear! Then it is the same behaviour as in the main LyXText. > The big Dispatch in lyxfunc.C has to pass (-- or, I don't know whether it > _has to_, but it certainly does --) math related LFUNs (as 'math-extern' > for example) to a math inset. So it is aware of the fact that math insets > might handle 'math-extern'. Why should the dispatcher (a) know of the > existence of math insets (or any other inset for that matter) and (b) > explicitly know which events are handled by that inset. Well that's what I was saying, wasn't it? > It has. But how is that different from a fixed width of the main LyX > screen? I don't think so :) > Gosh. _Any_ iterator will do. That's currently the cursor in most cases > is just co-incidence and/or bad separation of functionality. I don't know how mathed put's the insets inside and how you access them on the same level in InsetText it's just the same as in LyXText I have to sequentially look in the paragraphs (or use the inset iterator in the paragraphs in other words) and then for every inset descent the tree and see if the inset I search is inside that inset. > The events just have to bubble up and the innermost text inset will shout > "Hey, I can handle that!" And then? Is it passed down to the inset below it? > Anyway. I have made my mind up. If we want 1.3 out in September or so, I > won't do something concerning the inset unification that touches the "outer > world" i.e. src/inset as well as the core. I'll just try t get the math > insets and cursor right and then we'll have something to mumble about in > the 1.4 cycle. Ok! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView height
Angus Leeming wrote: > Am I right in saying that there's no way of accessing this info from outside > at the moment? Have a look at insettabular::draw(...) it is: bv->painter().paperHeight() Hope this helps! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: S+R already fixed
Michael Schmitt wrote: Hi Michael! > just some short information (I have not managed to prepare nice-looking test > cases yet). > > First of all: The new S+R code is very fast. It seems to work in most cases > but nonetheless there are at least two problems: #:O) > 1. Given a math formular inside a table inside a float. Search for some text > in the math formula. When the text is highlighted, search again. The same > text is shown (the cursor hangs). I guess the table is left in the wrong > direction, i.e. the cursor is put in front of it when it should be put after > it (this bug sounds familiar to me). I think that this is matheds problem Andre could you have a look at this? > 2. Given a document where the search string only occurs in "note" insets. > When you put the cursor at the beginning of the doc, "search" finds the > string but "replace all" does not. AFAICS this behaviour is dependent on the > document, in particular what is in front of the note. I can imagine that > LyX sometimes does not find the "entry point" of the inset. Valgrind reports > no memory problem. I'll have a look at this (time permiting) when you send me some testcases. Better you could append them too, to the bugreport on lyx's bugzilla. > It is still interesting to see how LyX updates the screen (try valgrind; it > slows down LyX such that you can see what is going on); when you search > inside an inset, first the inset is displayed from its very beginning, than > the correct part is shown. I once heard that LyX needs to paint some output > in order to calculate its size. Is this the reason for the otherwise > redundant repaints? On ancient machines you would see a lot of flickering. Maybe I know that but this are optimizations I don't have time to have a look now. > OK, I will try to prepare some test cases today unless you already know what > the problem is and what needs to be fixed. We should try to make the patch > robust such that it can be included in 1.2.1. ok I'll wait for this. Thanks, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Kravoglstrasse 4Tel/Fax: +39 0471 564172 - +39 0471 564122 I-39100 Bozen Web: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset unification
Andre Poenitz wrote: > No. Why should it? If the child were interested in the event it would have > said so when it had is chance during the "bubbling up". Or you or I am now confused. I think we should not talk of up or down from now on but from inner and outer inset. You said it went from the outer to the inner inset to see if it could do something with the event it couldn't but the outer inset still could do something with it if the child didn't like it, couldn't it? So the chain is from outer to innermost and back till the lyxfunc, isn't it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView height
John Levon wrote: > can we standardise on one or the other please ? (personally asking the > painter for metrics info seems odd) > For both width and height, that is Yes but you should wait for Lars as I already did such a proposal and he didn't like it, so ... > Why can't this list of rows be constructed inside bufferview ?? Because it is a LyXText thing and belongs logically there? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: mouse wheel problem with lyx-1.3CVS
John Levon wrote: > > Hmm, yes. The problem is obvious. Can somebody explain what units > lyxrc.wheel_jump is supposed to be in, and I can fix it ? > > 420 double const diff = t->defaultHeight() > 421 + double(time) * double(time) * 0.125; > 422 > 423 scrollDocView(int(diff)); > > should be something like > > float add_value = float(workarea_.height()) * float(time) / 100; > > but that was disabled in the old code. Somebody help please ! That outcommented code was put in there from myself to fix the IMO wrong scrolling algorithm, but Lars didn't like it. So I left it there until we can convince him that his code is really odd and it should be changed to the new one ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Qt frontend TODO list
John Levon wrote: > > LyXServer > > - remove xforms dependency > We didn't port LyXServer to GUII in the meeting because we would like to know how you would do the event polling. Please have a look at the only xforms specific stuff in there and tell us how you would port this to GUII (how qt would handle this!) We need you here to do anything at all. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Bug in 1.2.1cvs: graphics get LaTeX size and undo
John Levon wrote:
> I can't see this changing any time soon to be honest - Jug ?
Well this would be really easy one would have to call
setUndo(bv, Undo::EDIT, bv->getLyXText()->cursor.par(),
bv->getLyXText()->cursor.par()->next());
somewhere where the parameters are changed and I have access to bv.
One question however:
> void ControlGraphics::applyParamsToInset()
> {
> // Set the parameters in the inset, it also returns true if
the new
> // parameters are different from what was in the inset already.
> bool changed = inset()->setParams(params(),
lv_.buffer()->filePath());
>// Tell LyX we've got a change, and mark the document dirty,
>// if it changed.
>lv_.view()->updateInset(inset(), changed);
> }
Why is the updateInset not called inside inset()->setParams(...) and
when I don't change anything in the insetparams why do I have to call
a updateInset?
BTW: This seems to be the place to call the setUndo :)
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Preview: request for testers
Angus Leeming wrote: > One other point (for Jürgen?): I think that a (working) isInsetVisible could > be used to advantage by BufferView::updateInset. Seems intelligent to only > redraw insets that are visible... I think you didn't understand the Row::pos() variable/function. The pos returning from a row is the _first_ position of the first character of this row inside the Row::par(). You understand that in the visible rows you may have more than one paragraph and so the use of the start/end pos cannot work as you use it because most probably the lastrow is inside a different paragraph then the firstrow. Capito ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: minibuffer design problems
John Levon wrote: > I guess we also need something to get the "information" string > (I assume this is the keyboard shortcut list string ?) > > It's quite wrong IMHO for the core code to push /anything/ to the > MiniBuffer: it should only push to the StatusBar > > Note such a scheme still alllows the xforms-style commingling > > Does anybody have any comments / objections ? Jug ? Asger ? I don't understand really what problems you have with this? Why do you need two different objects? Isn't it possible to do this internal to the Minibuffer-Object? Why should the core care to change between a StatusBar and a Minibuffer. What real problem do you have to make this internal to the object? You just have to define a Input object and a display object and change between them when needed. That shouldn't be that big of a problem (just show/hide calls to the objects which have the same size/position). IMO that for the core it should be just one object to not complicate the stuff to much and for the frontend it should be really easy to implement this as such. But obviously you are the qt expert (I only made such small projects as KSendFax, KGoodStuff which I recently ported to qt3 ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Preview: request for testers
Angus Leeming wrote: >>- equations in floats (caption) are not previewed >>maybe all insets??? > > > It's possible that my isInsetVisible function won't work on these. Same > problem as the tabulars and something that Jürgen might be able to help with. Well I think you have to inform the InsetText that some update happend and that it has to redraw itself on the row where the insets reside. I'll try to debug this as soon as your patch is in the main line and I can do an update. I think this shouldn't hamper the inclusion if it works in normal text as this surely can be fixed quite fast. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: A more elegant way of defining a loop?
Andre Poenitz wrote: > I tried that once and failed as there is not alwasy a clear meaning of a > Row * in the code. It could be a single row or a set of rows starting with > this row. This makes things really messy. Would you care to explain this better? A Row * is always 1 row, as much as I know of that code. The rows are used _only_ in LyXText and denotes the whole set of rows of the entire document (visible rows on screen). I don't see what's messy with it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: A more elegant way of defining a loop?
Angus Leeming wrote: > A Row is a row. It shouldn't care or know about its next() and previous(). > > A list is a collection of Rows. Ok explanation understood and accepted! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: minibuffer design problems
John Levon wrote: > I don't think you understand: they are two entirely separate UI objects, > both visible at once. I don't think they are visible at once. There is or the message bar or the input buffer visible (well they have the same design so you won't notice. But they use the same space. Do you say you want to make that part higher and so make visible both at the same time? I don't Lars will agree with that. We always implemented it like an Emacs minibuffer and it handles stuff more or less the same as we do. > Well I don't know zip about Qt, but that's not really relevant anyway. > This is a sane design regardless of toolkit IMHO. Why do you prefer to > conflate two entirely separate concepts into one set of code ? It seems > to me that it's only because xforms has happened to do the same > previously. I don't have any strong opinion about this, to tell you the truth. So if you implement it in a, for you, cleaner way for me you may go ahead, just leave the xforms behaviour as it is now and also the look and feel. After that if behind the scenes it is one or two classes I really don't care much about. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: FINISHED_UP/DOWN/...
Dekel Tsur wrote:
> Why do we need FINISHED_UP et al. ?
> These are used only when exiting an inset with a cursor key (namely LFUN_UP
> et al. is called), so the direction is known according to the action.
> So, why can't we have something like
>
>result = lockinginset->localDispatch(..,action,..);
>if (result==FINISHED) {
> if (action == LFUN_DOWN) {
>
> } else if (action == LFUN_UP) {
>
> } ...
>
I would say because there are actions not given by a cursor movement
which will have to move the cursor to the position. Maybe UP is not
one of them but _before_ and _behind_ are needed so I think we should
have all 4 directions and do not have to reinterpret lfuns outside
again. What problem do you have with this? Heed that just FINISHED
is not enough as result value.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: insetContainsInset function?
Angus Leeming wrote: > Is there a function > bool insetContainsInset(Inset const & container, Inset const & containee); > > If so, what's it called ! No there is no such function the one existant is: bool isInsetInInset(Inset *) but you could just change the parameters to your needs or add it if you really need it. But could you please explain me in short for what you need this? > I need it for my isInsetVisible function which now works perfectly for all > insets appearing in the main text. Thanks to Jürgen of course! #:O) well I'd like to help you more active but at the moment that is not possible. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: insetContainsInset function?
Angus Leeming wrote:
>
> VPList::const_iterator vpit = vps.begin();
> VPList::const_iterator vpend = vps.end();
>
> for (; vpit != vpend; ++vpit) {
> Paragraph * par = vpit->par;
> Paragraph::inset_iterator iit = par->inset_iterator_begin();
> Paragraph::inset_iterator iend = par->inset_iterator_end();
>
> for (; iit != iend; ++iit) {
> lyx::pos_type const pos = iit.getPos();
> if (pos >= vpit->start && pos <= vpit->end) {
> if (*iit == &inset)
> return true;
> if (insetContainsInset(**iit, inset))
> return true;
You can write this as
if (*iit->isInsetInInset(&inset))
return true;
But probably you already figured this our by yourself. Anyway the same
is more or less used in BufferView::lockInset(...); (BufferView2.C).
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: insetContainsInset function?
Angus Leeming wrote: > On Monday 15 July 2002 10:39 am, Juergen Vigna wrote: > >>Angus Leeming wrote: >> >>>Is there a function >>> bool insetContainsInset(Inset const & container, Inset const & >>>containee); >>> >>>If so, what's it called ! >> >>No there is no such function the one existant is: >> bool isInsetInInset(Inset *) > > > You've just made this up There is no such function! Sorry you're right you have to use the function getInsetFromID(id) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: insetContainsInset function?
Juergen Vigna wrote: > if (*iit->isInsetInInset(&inset)) > return true; So this obviously should be: const int id = inset.id(); ... if ((*iit)->getInsetFromID(id)) return true; ... Well I hope this will work, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: FINISHED_UP/DOWN/...
Dekel Tsur wrote: > For RTL I need to have a distinction between FINISHED_LEFT/RIGHT > and FINISHED_BEFORE/AFTER, so in other words, we will need to have > 6 FINISHED* values. Why would you need this? IMO we just need LEFT/RIGHT (not BEFORE/AFTER) IMO that left/right are in the same direction in RTL too, isn't it ;) So before/after are not needed. Anyway why do you have problems with UP/DOWN? Why should we have to check it 2 times? IMO the result values should stay as they are if you don't have a _real_ reason to change them. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: LyX Qt2 on native win32 screenshot
John Levon wrote: > Actually doing this and testing it out is something for a rainy day Well then we will see it quite fast, I have heard some rumors about the weather in England ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: One for André
Andre Poenitz wrote: > On Tue, Jul 16, 2002 at 06:18:00PM +0100, Angus Leeming wrote: > >>Ok, understood. Since this box is not present in Preview display, I'll remove >>the extras then. > > > Ok. You need also some space between enclosing text and inset. I normally add 2 pixels at each side to the width (see InsetText and/or InsetTabular). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: 1.3.0cvs can't use template lyx files due to version conflict!
R. Lahaye wrote: >iletter.lyx I added this in old 0.12 times and also the supporting iletter.cls, but I think now as I will not support this anymore and so it is unsupported we should just remove this and the tex and template files from the lyx distrib. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: One for André
Andre Poenitz wrote: >>You need also some space between enclosing text and inset. I normally >>add 2 pixels at each side to the width (see InsetText and/or >>InsetTabular). > > > As LaTeX does not add such space when changing into math mode I'd rather > don't do it on screen either. Well you'll need that space otherwise it may be that you don't see the cursor blinking .InsetText and InsetTabular may have some border lines and if you don't have that added pixels the cursor will be exactly on the line and so you're not able to see it. But if you don't care to see the cursor then you're free to not use the added space (anyway you also use this in mathed for more or less the same reasons, only that you may not remember it because it was already that way before you started the rewrite ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: One for André
David Kastrup wrote: [sniped Emacs explanation] > Can't you overlay it? Are we talking about the text-cursor and not the mouse cursor? Well we have the really easy solution to give a bigger width to the outside world, this is all we have to do. We could however just add a default to the width, but I think it's better the inset decides this as this is really only needed for insets which start drawing at the left- or rightmost position and the drawing color is the same as the cursor color. So I think this is already solved inside LyX and is not connected to preview but to insets behaviour. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Font loading messages
Andre Poenitz wrote: > No, it should say 'Layout: Title', and if there is some font change in the > titel it should say 'Layout: Titel, Font: Emph' or similar. Also note > that mathed does that already, at least for font changes and "major insets" Why should we display the Layout we have that information already. But the more I follow this discussion the more it seems Jean-Marc is right with his "configurable" message-bar. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: scary_eqns.lyx doesn't travel well
Andre Poenitz wrote: > On Thu, Jul 18, 2002 at 05:27:47PM +1000, Allan Rae wrote: > >>The scary_eqns.lyx file we've used in the past for some maths testing >>results in errors in 1.3.0 after conversion by 1.2.1cvs. > > > The problem are the braces in the label. > > Please try the attached patch against 1.2.1cvs. And what are we doing with files saved by the user? Shouldn't this be fixed also in the reading part of 1.3.0? If the file is saved with 1.2.0 then the file is "doomed"? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: insert tabular
Andre Poenitz wrote: > On Fri, Jul 19, 2002 at 02:37:39PM +0200, Edwin Leuven wrote: > >>>You mean the extra horizontal border after the first line? >> >>No I mean *all* lines. I don't want them. First of all I don't like vertical >>lines in tables unless they really serve a purpose and usually they don't. >>And why would I want a horizontal line after every row? >> >>So I want a clean table after inserting. > > > A button 'Delete _all_ lines' would be nice indeed (not jsut the lines > around a given cell) Select the whole tabular and do "Unset borders" that will remove all borders around all cells! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: 1.3.0cvs can't use template lyx files due to version conflict!
Jean-Marc Lasgouttes wrote: > Juergen> I added this in old 0.12 times and also the supporting > Juergen> iletter.cls, but I think now as I will not support this > Juergen> anymore and so it is unsupported we should just remove this > Juergen> and the tex and template files from the lyx distrib. > > I removed it and uploaded it to ftp.lyx.org/pub/lyx/contrib > > JMarc Good! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: CVS generates empty Makefiles. Due to latest update in configure.in/acconfig.h?
R. Lahaye wrote: > After an autogen.sh I still need to modify configure manually to add a > "-lXpm" to the LIBS when configure tests for -lforms. That's a nuissance. > > I thought there's some sort of consensus that Xforms library will not carry > the Xpm libs, so that always -lXpm will be needed. Shouldn't that be added > somewhere then in LyX? In configure.in or in some .m4 file? IMO this is a problem of the .la file for libforms (libforms.la), which does not require the Xpm library which it should. We use libtool and if a library puts an .la file there then it should be the right one, shouldn't it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Ju"rgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: insert tabular
Edwin Leuven wrote: > Take alignment. Suppose I have a selection and I want to align right > > if I am in a multicolumn cell or have multicolumn cells in the selection > -> align multicolumn cell(s) right > > in I have selected a column > -> align column right > As much as I know we don't have a really easy way to mark a column or row have we? if you have a longtabular with a lot of rows it's _very_ cumbersome to mark all of it to just have a column setting changed. > otherwise > -> do nothing/disable align right button on table toolbar > > idem for borders > > why do we need separate dialogs for cells and columns for alignment and > borders? Because we earlier had exactly that (only one setting) and people complained that it was hard to guess what it was doing. Therefore we added a second tab for cell defaults. We can change back to the old behaviour, but we always will have people complaining about it. So why should I spend time to change between the two options when I already don't have time enough to answer mail :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: insert tabular
Jean-Marc Lasgouttes wrote: > Concerning having a finite list of possible defaults, this should be > added to the 'tabular create' dialog. Yes! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: insert tabular
John Levon wrote: > On Fri, Jul 19, 2002 at 03:27:37PM +0200, Jean-Marc Lasgouttes wrote: > > >>"template/default.table". This file would be read at startup to create >>a table object that can be clone()'d when creating a new table. > > > And then we can remove that silly TabularCreate dialog too Well I don't think so seeing how this tread is going #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: lyx-devel src/insets/: ChangeLog insetgraphicsParams.C
Jean-Marc Lasgouttes wrote: > People, what do you think? Renaming all variables for fun in the code > is one thing, changing the format is different. Well you know what we decided some time ago. To not make changes to the fileformat if not absolutely necessary and _if_ we make them the lyx-format number _has_ to reflect it in any case! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: tabular woes
Edwin Leuven wrote: > Like John's patch this should go in I think (also 1.2.X) Thanks for sending the patch, but I included this already from your other mail by hand. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: tabular woes
Jean-Marc Lasgouttes wrote: > And do you agree it should go in 1.2.x? Does it make a big performance > difference (Edwin, are you satisfied with performance now?) Yes I think that should go into 1.2.x too, it helps performance and cannot harm. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Help - key sequence madness
Jean-Marc Lasgouttes wrote: > Why should S-C-z undo?? This is a crazy idea. S-C-z and C-z are > different key sequences. Don't we remove the S part if we don't find a key sequence with S-C-z and then the C-z is undo, isn't it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: S+R already fixed
Michael Schmitt wrote: > Hi, > > I prepared two small test cases for s+r problems. The first one is > related to mathed (math text is replaced endlessly), the second one > demonstrates that "replace all" sometimes misses some occurrences. It > happens very seldom but it is easily reproducible. I fixed both bugs and attache the new patch for 1.2.x to this mail (to be applied on a clean tree)! Hope this works now as expected and IMO this should go into 1.2.1 version. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ s+r.patch.gz Description: GNU Zip compressed data
