Problems on LyX Host
Hello Lars, I've seen that we have again an 100% full /var filesystem on www.lyx.org :( It seems that blocks the mails from there. Could you have a look please. Best regards, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Segmentation fault on lyx-devel build
Hello there, i tried today to build lyx on my RedHat 4 system and the build was OK, but when trying to run it I get a Segmentation fault. Anyone has similar experiences? This is the gdb backtrace: $ gdb src/lyx-xforms GNU gdb Red Hat Linux (6.3.0.0-1.96rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /soft/lyx/builddev/src/lyx-xforms Program received signal SIGSEGV, Segmentation fault. 0x00947baa in __gnu_debug::_Safe_iterator_base::_M_detach () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x00947baa in __gnu_debug::_Safe_iterator_base::_M_detach () from /usr/lib/libstdc++.so.6 #1 0x00947bff in __gnu_debug::_Safe_iterator_base::_M_attach () from /usr/lib/libstdc++.so.6 #2 0x00947cde in __gnu_debug::_Safe_sequence_base::_M_detach_all () from /usr/lib/libstdc++.so.6 #3 0x080f9ef1 in ~match_results (this=0xbfe4ffb0) at /usr/lib/gcc/i386-redhat-linux/3.4.5/../../../../include/c++/3.4.5/debug/safe_base.h:170 #4 0x08238193 in CharacterSet::loadFile (this=0xa5be604, [EMAIL PROTECTED]) at ../../lyx-devel/src/chset.C:73 #5 0x0851bffb in TransManager::setCharset (this=0xa5be588, [EMAIL PROTECTED]) at ../../lyx-devel/src/trans_mgr.C:225 #6 0x082fd8c6 in Intl::initKeyMapper (this=0xa5be578, on=false) at ../../lyx-devel/src/intl.C:92 #7 0x087404cf in LyXView::init (this=0xa5a49a8) at ../../../lyx-devel/src/frontends/LyXView.C:89 #8 0x0874e87f in lyx_gui::start ([EMAIL PROTECTED], [EMAIL PROTECTED]) at ../../../../lyx-devel/src/frontends/xforms/lyx_gui.C:314 #9 0x08343a9e in LyX::priv_exec (this=0xa56a510, [EMAIL PROTECTED], argv=0xbfe50574) at ../../lyx-devel/src/lyx_main.C:287 #10 0x08341b8d in LyX::exec ([EMAIL PROTECTED], argv=0xbfe50574) at ../../lyx-devel/src/lyx_main.C:142 -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Segmentation fault on lyx-devel build
This works! Thanks a lot! How did you discover this? Greets, Jürgen Lars Gullik Bjønnes wrote: Juergen Vigna <[EMAIL PROTECTED]> writes: | Hello there, | | i tried today to build lyx on my RedHat 4 system and the build was OK, | but when trying to run it I get a Segmentation fault. Anyone has similar | experiences? Yes :-) configure with --disable-stdlib-debug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: 9th? International LyX developers meeting in Denmark 19th to 22nd of October
Hello, I may be also attending the meeting, but I have to do some checks still :) Greets, Jürgen -- ** Würth Phoenix S.r.l. Dr. Jürgen Vigna System Integration Via Kravogl 4, I-39100 Bolzano Phone: +39 0471 564111 Direct: +39 0471 564172 Fax:+39 0471 564122 mailto:[EMAIL PROTECTED] http://www.wuerth-phoenix.com
Re: 9th? International LyX developers meeting in Denmark 19th to 22nd of October
Hello Asger, I bought my tickets yesterday (Sterling: for 151€ ;) So if nothing happens I will be there with all off you. I will arrive Thurthday 19 October Afternoon and depart Monday 23 October Midday. Till then, Jürgen Asger Ottar Alstrup wrote: Dear Jürgen, It would be great if you came! You can try Sterling: http://www.sterling.dk I found some tickets from Malpensa at €74 out and €35 home. Regards, Asger -- ** Würth Phoenix S.r.l. Dr. Jürgen Vigna System Integration Via Kravogl 4, I-39100 Bolzano Phone: +39 0471 564111 Direct: +39 0471 564172 Fax:+39 0471 564122 mailto:[EMAIL PROTECTED] http://www.wuerth-phoenix.com
Re: About scrolling speed
Hi Abdel, as much as I know before we started on fixing bugs there I was not able to scroll trough the UserGuide without hitting an Assert ;) I think that this is due to the "more" metrics calculations we have to do in order to fix all that scrolling bugs and with it the removal of the nullpainter which was not calculating important stuff as *normal* text, and therefore with it in place the x positions of the insets where all wrong! Greets, Jürgen Abdelrazak Younes wrote: Hi Andre, Before Denmark, the UserGuide PageDown test was at 18 seconds. Now it is at 25 seconds. I hope you have some more code in store for speed ;-) Abdel. -- ** Würth Phoenix S.r.l. Dr. Jürgen Vigna System Integration Via Kravogl 4, I-39100 Bolzano Phone: +39 0471 564111 Direct: +39 0471 564172 Fax:+39 0471 564122 mailto:[EMAIL PROTECTED] http://www.wuerth-phoenix.com
Re: About scrolling speed
Asger Ottar Alstrup wrote: One conclusion is clear: The only sure way to get substantially faster rendering is to draw less on the screen, as discussed earlier today, either by introducing the old singlePar optimisation, or do some drawing-caching scheme. I'm of the opinion that in 1.6 we should work in be able to decide if we have to redraw just *one* row, one paragraph or the whole of the screen. Especially the *one* row stuff would increase "typing" performance a lot (and make it usefull again ;) Greets, Jürgen -- ** Würth Phoenix S.r.l. Dr. Jürgen Vigna System Integration Via Kravogl 4, I-39100 Bolzano Phone: +39 0471 564111 Direct: +39 0471 564172 Fax:+39 0471 564122 mailto:[EMAIL PROTECTED] http://www.wuerth-phoenix.com
Re: Alles im Griff auf dem sinkenden Schiff...
Hello boys, I still follow *very quiet* the lyx-devel list ;) I would *really* also like to come, but as you know I'm very committed especially in summer and as this year we have taken over the Pool with Bar/Restaurant it's worse then before. I see forward to another year when we can organize the meeting maybe early June or September. Have FUN, Jürgen Andre Poenitz wrote: Ok, boys - we have a contract for the club from Thursday 12 through Tuesday 17. August that is. And since we've been nice boys last time we've got 20% off the constumary rent without even asking for it. Translated into understandable terms this means a full day of truly free beer. With respect to accomodation Konni struck almost the same deal as last year as well: Five days of exile for two persons and a half just round the corner in exchange for watering some flowers. So our flat is free and you know where the supermarket is to fill the fridge... John, are you coming? Angus, are you coming? Anybody else (apart from Alfredo, Lgb, Jean-Marc and José) fancy coming? Andre' -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [patch[ undo
Andre Poenitz wrote: This 'when needed' is basically the time between first and second drawing phase. We need the rebreak to figure out the height of the InsetText, so it is needed in the metrics() phase. And once we've done it there there is no reason not to save the results up to the next draw() phase (which "immediately" follows) I don't buy the 'too slow' argument as the functionalit is essentially there in mathed which is way faster than e.g. InsetTabular. InsetTabular does NO row breaking! It is just one big object. The row breaking is ONLY done in InsetText and (as much as I know) InsetText "was" (at least I made it so) already ready for multiple LyXViews. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [patch] simplify TextInset
Andre Poenitz wrote:
This is arguably a step back on the path to 'multiple BufferView' as
now there's just a single 'active' BufferView again (complete rebreak when
changing BufferViews), but the current 'solution' contained (among others)
- bool clear = false;
- if (!lt) {
- lt = getLyXText(bv);
- clear = true;
- }
[interesting code]
- if (clear)
- lt = 0;
in almost all function which I consider Not Nice and which certainly should
not a long term solution to be extended to the rest of LyX.
Could somebody please have a look?
I don't have the time *sight* to test this stuff, but just for the
public info the above code is not there because of "multiple BV",
the code above is there because LyXScreen resize operations deleted
the LyXText instance!
The only stuff there to be there because of "multiple BV" is the
vector of LyXText's instead of a single LyXText.
Greets,
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Anybody know this code?
Andre Poenitz wrote: What could go wrong after applying the following? The cursor x position is probably wrong (inset inside inset). Greets, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Anybody know this code?
John Levon wrote: On Tue, Jul 22, 2003 at 05:38:40PM +0200, Andre Poenitz wrote: What could go wrong after applying the following? Mouse cursor positioning would be the obvious thing to try. But, it's already quite broken in current CVS ... And fixing mouse press positioning problems is even less fun than fiing update issues :( Don't you think you shoule slowly start fixing problems than open new bugs? I mean LyX seems pretty unusable right now and I don't see a fast way out to a working LyX again. Obviously there is the developers meeting and if you concentrate there all is possible (if enough beer is available), as you know :) Greets, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
compiling lyx?
Hello Folk, it seems that I didn't follow enough the lyx list as I'm not anymore able to configure LyX now. Could somebody explain me what options I HAVE to use in the configure command? How do I now compile the different frontends? When I do a --help it seems that --with-frontend does not anymore exist as option. Thanks for your help, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: compiling lyx?
Angus Leeming wrote: Good to hear from you Jürgen. :) Well I still read the mailing list (not all most mails I only read the subject ;) and I regularly build lyx on my pc to see what you're all doing :P Attached is a little wrapper script that I use. Use it so: $ ./configure-14x $LYX_DIR xforms qt Thanks, my problem was that some files had a "C" (clash) when cvs updating (don't know why I never changed them!) and this files where configure files, so the xforms frontend and the --with-frontend was not found :( I now did a clean checkout and all works again, anyway I use your script now to do the configure part of my autobuild-script. Greets, Jürgen P.S.: I'm really sorry I'm so busy with life AND work at the moment, I really would love to do some programing on LyX but I have just NO spare time at the moment for doing so :( -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: LyX meeting in Paris. When?
Hello, I would really like to be there this year I just have to organize myself. Probably any of the dates will be 3 for me. So put me there with 3 on all and I try to orgnize myself to be able to partecipate. I see forward to see you all again!!! Cheers, Jürgen Lars Gullik Bjønnes wrote: Asger Alstrup <[EMAIL PROTECTED]> writes: | Jean-Marc Lasgouttes wrote: Jul 16Jul 23Jul 30 Aug 06 JMarc 5 5 5 5 Jose' 5 5 0 0 Lars 5 5 5 5 Michael5 0 0 0 Andre' 5 5 5 5 Alfredo0 0 0 2 Asger 0 0 3 5 Georg 0 5 5 5 Stephan4 0 0 0 Martin 3 4 5 0 | Sum 322928 27 | Participants 7 6 6 6 | Sob, sob, I'll probably not be able to participate this year, unless | someone starts to like Jul 30 and Aug 06 more, hint, hint. Hmm we haven't heard from Jurgen this year have we? We should probably ask him directly if he want a reunion. -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: LyX meeting in Paris. What about July 14-18?
I already bought my tickets today, so most probably we will meet up in Paris #:O) ~Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: LyX meeting in Paris. What about July 14-18?
What do you mean my flight dates/times? Arrival in Paris evening the 14th, departure evening the 18th :) I will check back with you as soon as I have all plans ready, for the moment I just booked the flight (77 €). ~Jürgen Jean-Marc Lasgouttes wrote: "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> I already bought my tickets today, so most probably we will Juergen> meet up in Paris #:O) ~Jürgen Great! When? JMarc -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: William Leeming
Hello Angus, I wish you, Emma and little William all the best. Enjoy him till he's little that are the best years (also if sometimes tiresome ;) Kind regards, Jürgen Angus Leeming wrote: Dear all, I'd like to announce the arrival of William who arrived on Tuesday 15 November, weighing in at 3.55kg (7lb 12oz in old money.) It wasn't easy getting him out (40 hours labour followed by a Cæsarian) but now he is out both he and Emma are doing really well. They finally came home from hospital yesterday, so last night was my very first of real family life! I've put together a few pictures to satisfy your curiosity: http://www.lyx.org/~leeming/William/ It's not a very professional-looking page but, hey ho, it should give you a flavour. -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Licensing of tex2lyx (and perhaps LyX itself?)
The same for me! Regards, Jürgen Asger Alstrup wrote: I grant permission to license any and all contributions I've made to LyX under any open source license. Regards, Asger -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Licensing of tex2lyx (and perhaps LyX itself?)
Angus Leeming wrote: Juergen Vigna wrote: The same for me! Regards, Jürgen Wooo! Jürgen! It's good to see a message from you! How's life in Italy? Very busy! #:O) Anyway I follow the mailinglist by reading "Subjects", but I don't find more time than this for the moment. Have fun, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Backup of bugzilla
Hi! I would have a request, would it be possible to have a backup of the bugzilla installation with it's data? Or how can I have offline reading of the buglists in another way? Anyway IMO that it would be quite good to have a downloadable backup installed somewhere so that if the server is out for some reason we have a backup server. As I now I own a quite nice new PC I would be able to do some work at home on LyX ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: captions in longtables / input in lyx
Dear Joachim! Sorry for my late reply but I marked your message todo and the forgot. Right now I've seen it again and here is my answer. j.heidemeier wrote: Dear Juergen, Well, now I'm having some time to come back to the caption / longtables thread from November. I finally found a kludge to get the stuff working right. One can enter the caption as ERT in the header and firstheader row. All this is a hack and it should be implemented in the right way. Maybe I will find some time in future (after the 1.3.0) release to look into this and do it the right way. For now I'm sorry but in the short time this cannot be fixed. Greets, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Importing really long tables
Garst R. Reese wrote: I have some ascii tab separated tables of 150-200 rows. The table thing limits to 50. Is there a way to handle this (splitting imported tables over several pages) ? Alt-x tabular-insert 200 20 should work. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Using Qt in text.C
Andre Poenitz wrote: On Fri, Feb 07, 2003 at 09:52:12PM +0100, Daniel Naber wrote: I'd like to use some Qt classes in text.C - just for trying some things out. Which Qt classes? And what would the benefit of using Qt classes in the LyX core be? I don't think we would like such a change as then we would need qt libraties to comile one of the other frontends not really what we made GUII for. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: June 20-25th
Lars Gullik Bjønnes wrote: | Btw: What about your plans for June, Juergen? He is comming to the developers meeting of course! #:O) well I will tell you in time. You see I will have family bussiness at the end of May and I'm not sure I can make it this year. But we'll see later this year ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: June 20-25th
Andre Poenitz wrote: Folks, I have been asking well in advance, and there was _noone_ opposing that date. Well I always told you I most probably cannot attend in May/June! Sep20 [3] Sep27 [4] Ciao, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: some C++ queries
Andre Poenitz wrote: I am starting to believe that all insets should cache a bufferview or some "context" after e.g. draw() is called ... The problem with this is that the BufferView is sometimes redone and you point to a non valid pointer (the problems we had especially in the beginning with InsetText after cleaning it up a bit, but IMO we still can have this problem!). Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Inset::localDispatch problem
Andre Poenitz wrote: The hierarchy should be something like LyXFunc | BufferView | Buffer | OutermostText [And this should go if everything is an inset] | Insets and we should walk it bottom-up. Currently we have some strange combination of guessing jumps down (the_locking_inset and some hard coded 'let's the inset handle it) and a few steps up... I don't understand where you see jumps? the above is true and you have to extend it like: ... | Inset | Inset ... | Inset I don't see a jump it goes from the outermost to the innermost and stops there where the event is handled than it returns back. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: clean-up a 'gross hack'
Andre Poenitz wrote: On Mon, Mar 10, 2003 at 08:38:07AM +, Angus Leeming wrote: Have you checked math? No. I just assumed that you did the tight thing already ;-) Juergen explained to me how edit() works and how it should work already twice or so. Then I took another beer, and watched him fixing the current problem, hoping I'll learn something in the process. As far as I remember I learned that a single bottle is not enough. As far as I remember you didn't have only "that" bottle that day #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Meeting dates (was Re: Math/Tabular dialog)
Andre Poenitz wrote: This would make Sep 27 a good target, closely followed by Sep 20 and July 26. The next bunch is July 19, and Sep 6. IMO Sep 27 would be a perfect date ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] dump all the BufferView args from LyXText methods
Alfredo Braunstein wrote: Lars Gullik Bjønnes wrote: I have a patch ready (that seems to work) that does 99.9% of these changes. How the multiple bv will be adressed (or is it already in the patch?) - by having a cont bv member in lyxtext (i.e different bv for different buffers) - by resetting the bv * member in all children lyxtexts when switching BVs - by some other way? We will need 1 LyXText for every BufferView! Hope that answers all your questions above ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] dump all the BufferView args from LyXText methods
Alfredo Braunstein wrote: It doesn't. You need 1 _top_ lyxtext for every bv (and there is already). Then you have also a lyxtext in every children insettext... I'm talking about these, mostly. Or else I am confusing something ;) InsetText already has support for multiple BufferViews (while other parts don't have) so this means we have 1 (toplevel) LyXText for every BufferView and 1 LyXText for every BufferView in every InsetText. Is this clearer now? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] dump all the BufferView args from LyXText methods
Lars Gullik Bjønnes wrote: Juergen Vigna <[EMAIL PROTECTED]> writes: | Alfredo Braunstein wrote: | > It doesn't. You need 1 _top_ lyxtext for every bv (and there is already). | > Then you have also a lyxtext in every children insettext... I'm talking | > about these, mostly. Or else I am confusing something ;) | | InsetText already has support for multiple BufferViews (while other | parts don't have) so this means we have 1 (toplevel) LyXText for every | BufferView and 1 LyXText for every BufferView in every InsetText. But InsetText is not very nice about this... And what should it do in your opinion? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: This looks to be very silly indeed, so I guess I'm missing something. Why are we calling update(text) directly several times for one "lfun" ? Can we not just post the update, and then call it *once* at the end of handling the lfun (and at the end of handleKeypress and a couple of other spots I guess). It looks to me currently like we do an awful lot of unnecessary redrawing for no good reason ? I don't understand code like this : 400 bv->update(text, BufferView::SELECT | BufferView::FITCUR); 401 text->toggleFree(font, toggleall); 402 bv->update(text, BufferView::SELECT | BufferView::FITCUR | BufferView::CHANGE); Is this related to CHANGED_IN_DRAW ? (and if so, how ...) This code is related to "selections" and their redraw/drawing, it doesn't do that much actually have a better look at the update function and you'll see that actually most of this calls don't do that much. I explain you also why one update won't work because then we would have to do "full redraw" as Andre tell's us always. I think that full redraw was normal at the beginning, but it was (and IMO it still would be) way too slow when someone is typing fast! I didn't finish my explanation above ;), if we don't do a "full redraw" we have to "clear the selection first" then do the change, and after that "redraw the selection" as otherwise we would have drawing glitches and blue selection rectangles in spots where they should not be. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] dump all the BufferView args from LyXText methods
Lars Gullik Bjønnes wrote: Keep the enclosed LyXText somehwere else, so that parts of the paragraph structure could be modified at will, without having to thing about anything else. I don't really understand how you would do that and how that would facilitate the process, I understand however that something should be changed in there especially I don't like to have to take attention that the LyXText could be removed when we are still using it. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] dump all the BufferView args from LyXText methods
Lars Gullik Bjønnes wrote: Who are "we"? the inset? The inset should know nothing about any lyxtext at all, the same way a Paragraph today knows nothing about any lyxtext. Well "we" is the inset. And yes this is a good idea and quite easy IMO we just have to remove the "DRAW" functionality from the insets and see it only as container ;), but on the other hand then you would have to put that functionality somewhere else. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote:
On Tue, Mar 18, 2003 at 11:52:32AM +0100, Juergen Vigna wrote:
PS: Cut&Paste&press C-M on this to create the math tabular.
$\begin{tabular}{}
\\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\
\end{tabular}$
??? I would like to try that but I don't know how to create the
tabular inside mathed.
As I said: Cut&paste that $...$ to the main lyx text, mark it, press C-m.
Is it a "real" InsetTabular?
No. It doesn't have multicols and fixed width columns and a few other bells
an whistles.
Well then I just don't have to test this, as if I would have an
InsetTabular with that restrictions I also could just do a "full redraw"
the problems are the "other" features (and I tried to do them doing a
"full redraw", but it was *way* too slow, at least on the PC I had at
that time!)
Jug
--
**
Würth Phoenix S.r.l.
Dr. Jürgen Vigna
System Administration
Via Kravogl 4, I-39100 Bolzano
Phone: +39 0471 / 564111 (direct 564172)
Fax: +39 0471 / 564122
mailto:[EMAIL PROTECTED]
http://www.wuerth-phoenix.com
**
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote: Face it: Full redraw _is_ faster. This might have changed over time, though, but it is the current state. Well this is easy enough to try just forget about the "inteligent" redraw and set the update always to "NEED_FULL_REDRAW" and you'll see the difference. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: This just sounds like bugs to me, and several redraws (did you know each character press sends redraws twice even in a normal par ?) is not the correct solution. Do you mean cursor droppings ? There are a lot of different situations when we have "wrong redraws" if we don't do the double draws. I know this because I tried to remove them some time ago and saw the results. There are various places where that happens, but I would now have to have a deeper look into the files to remember and as you say the whole update stuff is not what I call easy understandable. So if you think you have the ultimate solution just try it out ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
Andre Poenitz wrote: Would that mean (almost) no effort is spent to "be clever" in this case? I don't understand your question here? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BufferView_pimpl::update(blah) vs. update()
John Levon wrote: [snip] Perhaps you're referring to insettext/tabular specific code that decides which cells needs updating ? But that's not related to redrawings really, it's more a matter of rebreaking etc. (and it's broken in several circumstances) Yes John you are right and I see you're on the right trace just go on with your investigation. Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
I don't really read all of the mails arriving right now (there is just too much traffic), but I overscan all of them fast. Now I'm a bit worried about the actual state of the lyx developement are you all sure we will not end up as in the "old" development tree? I hope you try to hold on yourself and don't start changing stuff in too many places otherwise we will never be able to see what changes broke behaviour and we will therefore not be able to fix all of the newly introduced bugs. A bit worried, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
Andre Poenitz wrote: So what about the two-stage drawing? Give the insets a small cache of width/ascent/descent (you could steal from math_diminset I suppose), fill the cache of an inset in the first stage according to the size of the contents of the inset, and do all the drawing in the second stage... But we do this already we calculate all the matrices for drawing and in the draw function we (most of the time) do just drawing and that is pretty fast!) or what do you think do we use the "LyXText" inside the InsetText for? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Fun with updating
John Levon wrote: Juergen, can you help ? What would you say if I suggest ripping the font paramter from inset->update ? I would say this could be a good idea. Just define a "default" font for an empty CellInset and pass that one instead. IMO this is the best solution and you're able to rip out the LyXFont parameter. Would that be an option? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Fun with updating
John Levon wrote: HA ! That's a bloody joke. This doesn't work. I have absolutely no idea why, of course. This update stuff is entirely beyond understanding. Just dealing with the bv->updateInset() vs. bv->update() vs. bv->update(blah) vs. inset->update() vs. inset->updateInsetInInset() vs lyxtext->update() vs. lyxtext->updateInset() [1] isn't too bad, but the semi-recursive nature and delayed insettext state update thing makes it impossible. I've spent 2 solid hours trying to work out the correct way of forcing an update of a minipage, no go. Pretty pissed off ... I would have been *really* surprised if you would have figured out a better way in one day, do you know how long I worked on this stuff to make it work as it is now. The only way I see to fix the whole lot is that we would have to update the deepest insets first. I'm pretty sure there is a good algoritmus for this and if one goes and concentrates on the problem I'm pretty sure we come up with something working. As I told you we have to update the deepest insets first and then from there come up. Obviously at each level we can have more then just 1 inset and that is what complicates all of it, but as I said I'm pretty confident that there is a better way to solve this as the actual one which (I admit it) is pretty hard to understand and far away from the best way to do it. I've done this anyway, since it doesn't make things worse. I'm committing the lot below tomorrow. Ok you did it as I expected. Defined a fixed font for the empty tabular cell font. What I don't like in all this is the removal of the "mark_dirty" flag how do you do now to set the dirty flag on the buffer? (I admit I had only a fast look at your patch). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] move need_update handling into insetert
John Levon wrote: This fixes a long-standing bug, for some reason (namely, switch from closed to inlined did not correctly recalculate the width), but does not fix an *existing* bug that is new to 1.4.0cvs (bug 965). Jug, if you're listening: why doesn't the insettext->update() correctly deal with the cursor positioning changing ? But really this is a matter of a start of cleanup, only insetert uses the insetcollapsable need_update handling, so it should go there. It also doesn't yet fix bug 966, which is old. OK ? IMO this is ok if this need_update is only used in InsetERT then this surely is wrong. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] more ert stuff
John Levon wrote: This is a more recent version, that also fixes bug 966. We were not checking for size(text) < size(button) in the ERT draw. This was fixed by merging the duplicated code. IMO this should be pretty safe to apply. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
Andre Poenitz wrote: Look at what mathed does: At a very high level (i.e InsetFormula::draw) the work is split. The first call to width() calls metrics() [ok, this is messy, but currently the easiest way to make sure that metrics() is called after loading of a buffer, too]. Afterwards, the real draw part is done, by calling the nested inset's draw() [which do not contain metrics computations anymore] I told you this already a lot of times, the redraw of mathed is "really" easy to do. You have all fixed width insets and the don't do a rebreak or resize themselfs to their environment. You cannot compare this to the complexity of InsetText you may compare this to a inset like lets say a InsetTabular if we wouldn't have the posibility of autobreaking rows (as it was in the first draft of the inset). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
Andre Poenitz wrote: And I still do not believe that this makes a big difference. Well this is up to you Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
John Levon wrote: On Thu, Mar 20, 2003 at 09:02:56AM +0100, Juergen Vigna wrote: But we do this already we calculate all the matrices for drawing and in the draw function we (most of the time) do just drawing and that is pretty fast!) or what do you think do we use the "LyXText" inside the InsetText for? If this was true, CHANGED_IN_DRAW would not exist. I said "most of the times", didn't I? This means we need to redo the calculations if at the time we get to the draw routine the drawing tells us we don't have all the space we thought we had. The problem is that we have this information for now only when the draw function is really called :( Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
John Levon wrote: Well, I think I follow you a bit better now. In fact, that is what I am trying to do ! Basically make sure all inset updates have been done by the time we actually call draw. But it is beyond my ken (I cannot even get one small part of this to work, in fact). As I told you in my earlier mail some informations you have only when you are in the real draw function, well actually we are interested for a "test-rebreak" only in the "x" position as if this changes it means we have to rebreak the whole text inside the inset. This is also the difference between an InsetText and a InsetMath as mathed does not care how large it will become and this assumption takes out the whole complexitiy! We could queue inset updates and do them all after an lfun etc, but I don't see how to get the sensible ordering of innermost->outermost. That's the problem! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Fun with updating
John Levon wrote: Well, can you explain why calling insettext->update(reinit == true) inside the insetminipage thing doesn't work ? That's alll I want to know and after about 50 printf's, I'm still stuck. Because you do it at the wrong spot! Try to "printf x()" and then after it drawed it wrong (or inside the draw function) also the x(), you will see they changed. I explained this in the earlier mails. This is the final part of an earlier patch - we look at the lfun definition and decide from that whether we modified the buffer Good! Seems a nice way to do it! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Fun with updating
John Levon wrote: Why is it the wrong spot ? Can you explain in simple terms ? I explained below, the x position is changing during draw and if that happens we have to "recalculate all"! Dude, I spent *hours* doing this, and could not see where or why it didn't work. This is lots of printfs in various update() functions etc. Only hours come on that's nothing in confront to how many time I spent to make it work ;) Where ? Draw + x()! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: top_y() is killing us
Andre Poenitz wrote: So why do we see several updates per redraw? Why does an inset communicate explicitly with its parent? I think discussing helps thinking ;) The problem we have is that we do "updating" of the text in "rows". so if the "inset" is embedded in a row and it changes it may be that we have to recalculate the whole row (therefore up and down). I don't see any easy solution for this as we cannot "update" first all insets and then the text, as we then don't know the exact "x" position of the inset and this gives us the "width" of the inset. I admit that I tried to come up with an example (and I know I knew of various), but now I come up with nothing. Why not let us create a branch and try out the solution to update all insets first (starting from the innermost childs!) and then update the text structure. After that doing the draw. And see what's happens. I won't do something like this in the main branch. And maybe it comes back to my mind what examples I had which did break this behaviour. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: lyxtexts & insettext
John Levon wrote: Can somebody give me a brief summary of how/why this works ? Especially, why can't we "reinitLyXText" when lt is non-null ? Because it might be we are working on "Row" pointers which would disapear or be invalidated by the reinit, don't you think so? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: lyxtexts & insettext
José Matos wrote: Probably you meant "raw" pointers, no? No I meant (raw) "row" pointer In this subject "row" pointers will probably mean something else. Also I would not have pointed if it wasn't friday... Did you joke? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [patch[ undo
Andre Poenitz wrote: But the contained InsetTexts do, so I am not spanking 'slow InsetTabular as created by Juergen' but 'InsetTabular as container of lots InsetTexts' [Although I'd think that there is some unnecessary fat in InsetTabular, too...] You may have a point here, althought I don't know where I would optimize something I didn't already consider :( In practice, I'd consider this a premature optimization. This readiness has resulted in a lot of code which is not exactly easy to read or to modify, especially when it comes to conceptual changes like the conversion from an 'update based drawing' to the 'two phase drawing'. The only change to make to "rip" that functionallity would be to have instead of a map Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: getCursorPos() & formulabase.C
On 15-Apr-2002 Andre Poenitz wrote: > > Could you check whether the attached patch makes a difference? Well yes it works on Buffer change now, but the values are still wrong, you just compensate them in the edit() call now! Practically you would have to use the x/y code you use in ::insetButtonPress()! So if I get edit(bv, 0, 0, 0) then it's the start of the inset! You didn't understand the "relative" x/y problem I explained in my first mail, isn't it? I try it with other words a math inset in the middle of a row (which say starts at x position 200) will have as x position in the call to edit AND insetButtonPress 0 if I press BEFORE the first character INSIDE the inset. Hope this is clearer, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Before borrowing money from a friend, decide which you need more. -- Addison H. Hallock
Re: getCursorPos() & formulabase.C
On 15-Apr-2002 Andre Poenitz wrote: >> I try it with other words a math inset in the middle of a row (which say >> starts at x position 200) will have as x position in the call to edit AND >> insetButtonPress 0 if I press BEFORE the first character INSIDE the inset. > > Does this mean, mathed can be ignorant to any outside positioning? I.e. I > can assume all parameters send to mathed methods are 'normalized', i.e. > assume an origin of the inset in (0,0)? This would be nice... Yes and as much as I know this has been so since a long time! > Ok, then all the xo_/yo_ handling in mathed is Wrong, since it stores > absolute values everywhere, not relative to the inset's origin. > > This is not exactly my doing and maybe was not even possible to do > otherwise until this recent change of yours that allowed me to remove this > awful hack for cursor positioning... I don't know about that you have to see it. Where do you get the absolute postions from? Anyway you need absolute position only for drawing but then you get the x and baseline there so that should be no problem! > But the question is: How important is it to get this right? I probably > would have to touch a dozen math insets to switch from absolute positions > to relative... Well if you want to have the cursor on the right x spot when doing a cursor up/down (I'm fixing this at this moment and therefore I've seen that mathed does it wrong and InsetText did is also wrong!) then you should fix it. If you don't care that the cursor goes to the end of the next/previous row on a cursor up/down and can handle all the requests coming from the user because of this strange behaviour then let it be ;) Anyway it's just 1 function to fix in which you return the normalized values to the outside world. Why would you have to fix this in a lot of functions? A well there is the edit call too but that should be really easy to fix. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Aliquid melius quam pessimum optimum non est.
Re: getCursorPos() & formulabase.C
On 15-Apr-2002 Andre Poenitz wrote: > On Mon, Apr 15, 2002 at 03:14:19PM +0200, Juergen Vigna wrote: >> Well yes it works on Buffer change now, but the values are still wrong, >> you just compensate them in the edit() call now! > > Aehm, since this 'fixes' this case now, should I commit it? It depends on the answer to my other mail! You decide I don't care ;) We can just open a Bug on this and you tell us you fix it in 1.3. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ A good plan today is better than a perfect plan tomorrow. -- Patton
RE: showLockedInsetCursor etc
On 15-Apr-2002 Andre Poenitz wrote:
>
> When I call this function with (0,0) I get the cursor displayed on a
> y-coordinate corresponding to the baseline of my formula, but at the very
> left edge of the screen (something that looks like "absolute x-coord 0").
>
> So what am I supposed to do here? Does 'everything is relative' not hold?
> Or is it more likely that I missed something during my "corrections"?
No you're right! This bugged me also for long, but IMO it's easier for the
inset to give this as for the BufferView to find out. It's just your relative
position + top_x. We would obviously also do it in the outer function by
calling theLockingInset->getLockingInset()->x(), but IMO it's just the same.
Let us keep it for the moment as it is and later we can change this if we
think we should do it.
As I told you we have to cache the top_x anyway in the inset as it is A LOT
harder to calculate this information on the fly from the outside world.
We should however put a comment on that function that the y position is
relative and the x position is absolut!
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
printf("Don't Panic!\n");
exit(42);
}
(Arnold Robbins in the LJ of February '95, describing RCS)
Re: lyx 1.1.6 fix 4
On 15-Apr-2002 Kuba Ober wrote: >> The attempt by xforms to report the error fails because the function >> it called doesn't exist in your glibc. > > Hmm, I'm using the latest glibc from redhat (2.2.4). What version of xforms are you using (I mean the RPM package version!) the one 0.88 supplied from RH is buggy! You have to install another version and I think you get the RPM from the lyx contrib directory (Jean-Marc?) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Nothing ever becomes real until it is experienced. - John Keats
A site note
Meta-CVS 0.11 (Development) http://users.footprints.net/~kaz/mcvs.html This looks very promising :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If at first you do succeed, try to hide your astonishment.
Re: A site note
On 16-Apr-2002 Jean-Marc Lasgouttes wrote: > A program that 'requires' linux for no good reason cannot be > production-ready. Well it does not say it's stable and production ready, does it? But we HAVE a linux box for our cvs tree, don't we? The problem is if the tree can be used with normal cvs too (for our mirrors). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ A man usually falls in love with a woman who asks the kinds of questions he is able to answer. -- Ronald Colman
Re: A site note
On 16-Apr-2002 Lars Gullik Bjønnes wrote: >| Well it does not say it's stable and production ready, does it? >| But we HAVE a linux box for our cvs tree, don't we? The problem >| is if the tree can be used with normal cvs too (for our mirrors). > > it also says that it is only for clients. Hmm, yes, I really ask myself how they do it then? Are the history informations then local??? Well whatever we'll see in the future ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 6 oz. orange juice 1 oz. vodka 1/2 oz. Galliano Harvey Wallbangers
RE: lyx 1.2.0pre3 language oddity
On 16-Apr-2002 Helge Hafting wrote:
> I use lyx for writing webpages with math.
> I have \usepackage{html} in the preamble,
> and some documents starts with the following code
>
> \begin{rawhtml}
>
> \end{rawhtml}
>
> 1.2.0pre3 makes 3 ERT insets, which is fine - but
> also insists that the first of these inset is in the
> english language. I don't think that makes a difference,
> but it is certainly odd. The whole document used
> to be in norwegian. (\language norsk)
>
> The lyx file now have
> \lang english
> before the first inset, and it appears with a blue underline
> on screen. There is no trace of english in the pre-1.2.0pre3 file.
Could you send a minimal document otherwise it's hard to see where the
wrong read is.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Do not permit a woman to ask forgiveness, for that is only the first
step. The second is justification of herself by accusation of you.
-- DeGourmont
Re: A site note
On 16-Apr-2002 Lars Gullik Bjønnes wrote: > I do not thing meta-CVS is ready for primetime and certainly not for > us (now). I never implied that but the idea behind is not that stupid! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You will be misunderstood by everyone.
Re: showLockedInsetCursor etc
On 16-Apr-2002 Andre Poenitz wrote: > Ok. So I cahce it from the last redraw? Yes. I think every inset has a top_x variable (see inset.h) I don't know if you already set it but that is certainly the right way to go as then surrounding inset can also retrieve it with the x() call. (Same for top_baseline and y() call) >> We should however put a comment on that function that the y position is >> relative and the x position is absolut! > > That would be nice. It's somehow confusing as it is now. Where should we put the comment? In the BufferView.h file? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Pick another fortune cookie.
Re: Graphics: "Waiting for draw request to start loading" ?
On 16-Apr-2002 John Levon wrote: > I don't see the difference between this and "Don't display", except that > the former is more accurate (the latter is imperative and hence makes no > sense). And in first place why load it (and have all the conversion stuff started) if we don't want to display it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You can't push on a string.
RE: cursor movement problems
On 17-Apr-2002 Andre Poenitz wrote:
>
> When I mark some paasge of text by pressing shift-down and the cursor
> crosses a math inset it gets stuck there. Formerly the whole inset was
> selected or not as some monolithic object, which is much better in my
> opinion. We can't do much with half formulas anyway.
Ok I fixed this (this was due to my comit yesterday)!
> Looks like the outside world sees the same problems as mathed as
> it starts to get 'smart' ;-}
I don't understand!
> Next problem: Enter math in tables with the cursor from behind. THe cursor
> goes to the first position.But this could be my fault somehow...
Well let's say yes it's your fault, but I don't understand are you never
debugging code? I't just a simple break in the FormulaBase::edit() and see
what they do!
What happens! When inside a insettext a cursor-Left move enters the inset
from behind. Instead of using the "new" edit(bv, front) call it still used
the edit(bv, x, y, button) call with x=inset::width() and y=inset::asc + desc.
Normally with such x/y values we should enter the inset at the bottom left!
I now simplified that function and use the edit(bv, front) call so it should
be fixed for you, but IMO you should check your function first (before
updating after my next commit) as it seems your algorithm in
MathCursor::bruteFind() is wrong (heed that x/y values are relative to the
inset as you see by the values they are set too!). Also why do you use
while(1) and a break; instead of do { ... } while, or for() there?
(the for only if you don't care that your iterator is already the_end
iterator and as much as I know end iterators do not have any good values
in them, do they?)
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Sometimes you get an almost irresistible urge to go on living.
Re: PATCH: Fix page up/down behaviour
On 17-Apr-2002 Lars Gullik Bjønnes wrote: >| I have to admit I'm a bit worried about all this patching going on ... >> >| We've already had two or three new bugs come from your recent changes. I >| thought we wanted 1.2 to be released ?? > > I can only say that the number of prereleases has been increased with > at least 3... that means about three more weeks... and for every > non-trivial patch the number will increase... > > Do you really want 1.2.0 before summer? If you ask me we could just release it today! 1.2.0 is much more stable then 1.1.6 and has more features. So we could start 1.3.0 and Jean-Marc can trow away 1.1.6 and hack 1.2.0 for bugfixes ;) If you think my recent changes only added more bugs to lyx then I miss the bug reports on LyXBugs. I've only seen decrease the bugs. Now as Allan told you I really don't care if we add this now or only in 1.2.0 (allthought the user will be a bit dissappointed!). I just cannot sit on Bug Reports (as maybe someone of you can while doing completely different stuff which will only be included in 1.3.0 for sure) when I see them and also feel the misbehaviour they produce. Did you actually look at the patch? Did you actually try it? Did you try the PageDown up/down with heigh insets such as a minipage or a big tabular, before and after this really small bug, if you did all this then you can comment and please don't comment with feeling comment with "real" arguments if possible. If you think I'm annoyed I'm not. I have this patch in my tree and also already fixed the bug which doesn't permit the mouse selection of the whole UserGuide. I will commit them now or save them for later. Ahh and before I forget if you think we shouldn't fix the bugs in LyXBugs before 1.2.0 is released then please tag them as 1.3.0 or as later so that when I look at the list I know what you want to be fixed and what not. Back to real work, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Life is not for everyone.
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Lars Gullik Bjønnes wrote: >| If you ask me we could just release it today! 1.2.0 is much more stable then >| 1.1.6 and has more features. So we could start 1.3.0 and Jean-Marc can trow >| away 1.1.6 and hack 1.2.0 for bugfixes ;) > > I almost agree with this... but I want at least a prerelease where we > have a larger group of people testing, and also a period of time where > no patches are going in. I do not want to release 1.2.0 one day and > 1.2.1 the other just because of some small stupid trivial bug. Sure but you know that you won't get a really great audience with prereleases (and the more prereleases we'll make fewer people will try them ;) and there is always the posibility of not discovering a stupid trivial bug which a user just discovers on his first load of a file. BTW.: As much as I've heard Jean-Marc couldn't convert 2 of our documents, so this should be a priority to fix first. What documents where that? > I do think that the recent changes are needed, and I am grateful that > you do it. But it is changes and changes need some testing. Sure they need! > do it now, would be nice to have in. Will do it now. > I have on the bugs that I do not think needs fixing reduced the > priority to P3,P4,P5 (but several of the P2 bugs should also wait for > 1.3) To tell you the truth I only look at bugs which seem to me fixable with a minor source change. I don't like to introduce new functions or change the functions params right now and so I try to estimate the impact of the change, but obviously one not always knows. But with this last changes I really took the time to look how all this scrolling and cursorsetting really works. I also figured out how the redraw and drawing should work to do it right. I was here with paper and pen to figure out how the algorithm has to be so that it works ;) and it was fun to do. Now I have also a deeper understanding of this things so that later changes are much easier to do :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Lars Gullik Bjønnes wrote: > I'll try to get a new prelease out today. (it is a but time consuming > since I want to check that a lot of make targets work as expected. > Especially clean and distclean. Also building where srcdir != builddir > and srcdir == builddir must be checked, and the actual build of the > tar.gz with the different variants. Well I always build with srcdir == builddir and that works I didn't try the other options, so tell me what I should try and for what I should look out. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Look ere ye leap. -- John Heywood
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Lars Gullik Bjønnes wrote: > Some compability reading failing. Is the file correct in the first > place? Does the file reading stop at this point or does it continue? Well the first question coming to my mind is could the files be read with 1.1.6? If yes and we save them again in 1.1.6 format do we have the same problems. If yes than I would say the bug is on our side, if no then the bug is in the file the test is easy to do, isn't it ;) But Jean-Marc probably did already try that, didn't you? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Any program which runs right is obsolete.
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Jean-Marc Lasgouttes wrote: > So this is a very old file, but 1.1.6 can read it. Should I just > convert it, or does somebody want to investigate why it does not work? > Why doesn't lyx warn that this file format revision is not well > supported anymore? I was quite sure you did this test already ;) Well I got further as a lot of people did not upgrade to 1.1.6, but stayed with 1.1.5 (for obvious reasons ;) I tried 1.1.5pre3 (the one I had here) and that one also reads the file perfectly and saved again 1.2.0 CAN read it! As in 1.2.0 we only support fileformat >= 1.1.5 version (maybe somewhat also from version before, but I'm not sure about that) I would say we are on the safe side and don't have to do anything more in the compatibility read (this for it_??? file) I investigate the one in sk_ as it most probably is a compatibility read problem! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ He who spends a storm beneath a tree, takes life with a grain of TNT.
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Lars Gullik Bjønnes wrote: > It probably should... but we have not made any guarantees with 1.2.0 > towards 1.1.5. Well but we should! A lot of people did not change because of the problems with tabulars in 1.1.6. I think we have to support at least 1.1.5 file format! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ That's odd. That's very odd. Wouldn't you say that's very odd?
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Juergen Vigna wrote: While investigating for the sk_??? read I saw that most probably the problem lies in the mathed parser I will tell Andre when I see where, but for now I saw just this (no bug just a bit strange handling) In Parser::parse_into1() you check a lot of paterns on the cs_ string and as last entry you ask if the size of the cs_ string > 0. Seems strange to me shouldn't this be in the first place? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Charity, n.: A thing that begins at home and usually stays there.
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Juergen Vigna wrote: > While investigating for the sk_??? read I saw that most probably the problem > lies in the mathed parser I will tell Andre when I see where, but for now I > saw just this (no bug just a bit strange handling) Well it wasn't Andres, but Lars's fault #:O) He changed all \\end_float to \\end_inset without changing the check for this in other compatibility reads (say tabulars!). >From Andre: > I am not too convinced that the current state is ok, in fact undo crashed > on me yesterday when preparing a few really trivial slides (but I had no > time to investigate) and both math and tables "just feel not right". Don't > ask me why. I cannot do anything with "feelings" (didn't I tell this already today) and I learned to not care for them if people cannot give me facts for them! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Home life as we understand it is no more natural to us than a cage is to a cockatoo. -- George Bernard Shaw
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Jean-Marc Lasgouttes wrote: > So this is a very old file, but 1.1.6 can read it. Should I just > convert it, or does somebody want to investigate why it does not work? I would say now just convert them, going over a 1.1.5 format to be sure! If you don't have 1.1.5 anymore I can do it if you want. > Why doesn't lyx warn that this file format revision is not well > supported anymore? Hmm I think we fixed it. And I'm pretty sure that the it_?? file was hacked as it is a fileformat for > 1.1.4 (I cannot read that file with 1.1.4, but I can without errors with 1.1.5) and then when saved with it I can read it with 1.2.0. (I'll try the last 1.1.5fix2 too to be sure maybe we changed something in the fileformat between 1.1.5pre3 and 1.1.5fix2! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I thought there was something fishy about the butler. Probably a Pisces, working for scale. -- Firesign Theatre, "The Further Adventures of Nick Danger"
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Lars Gullik Bjønnes wrote: >| He changed all \\end_float to \\end_inset without changing the check for >| this in other compatibility reads (say tabulars!). > > So was it a cosmetic bug, or a real one? Hmm, well, I let you decide if you change the fileformat and then give it to a routine as input and don't tell the routine that you changed the fileformat and so the routine failed to read the file properly is it a bug then? (Anyway I would say a cosmetic one as we didn't have no misread we only got the error message, but that could also have been luck!) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ What use is magic if it can't save a unicorn? -- Peter S. Beagle, "The Last Unicorn"
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Jean-Marc Lasgouttes wrote: > Juergen> I would say now just convert them, going over a 1.1.5 format > Juergen> to be sure! If you don't have 1.1.5 anymore I can do it if > Juergen> you want. > > Yes, please do! Hmm well strange enough someone change it_Tutorial already. I did a update recently and now the top of it_Tutorial tells us: #LyX 1.2 created this file. For more info see http://www.lyx.org/ \lyxformat 220 And cvs tells me: (file) it_Tutorial.lyx 1.3 9 days lasgouttes update all files to 218 format So it seems I'm not anymore able to test this ;) (and you gave us wrong data to work with and/or updated a file you didn't want to update :) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ At no time is freedom of speech more precious than when a man hits his thumb with a hammer. -- Marshall Lumsden
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Jean-Marc Lasgouttes wrote: > Juergen> Hmm well strange enough someone change it_Tutorial already. I > Juergen> did a update recently and now the top of it_Tutorial tells > Juergen> us: > > I said it_Customization.lyx. Oops ;), well then it is surely no 1.1.5 file as 1.1.5 had version number 2.16 and that file has 218 as version and that is the 1.1.6 file version! And I cannot read it without errors with 1.1.6 so it seems to me that this is a manually edited file! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If you are not for yourself, who will be for you? If you are for yourself, then what are you? If not now, when?
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Jean-Marc Lasgouttes wrote: > I do think too that it is one. But you know italian, don't you? This > was for this that I suggested you could take a look, for for your > hacking skills. And for what should I look exactly? Anyway it seems really bad for me to edit lyxfiles by hand and THEN save them to the repository while not checking that they load without problems! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Democracy is a form of government in which it is permitted to wonder aloud what the country could do under first-class management. -- Senator Soaper
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Andre Poenitz wrote: > On Thu, Apr 18, 2002 at 02:13:10PM +0200, Juergen Vigna wrote: >> I cannot do anything with "feelings" (didn't I tell this already today) and >> I learned to not care for them if people cannot give me facts for them! > > You should practise "not caring" a bit. Hmm probably I should and I shouldn't answer to this mail too, but you know human kind is not without errors ;) > After all I was answering to one of Lars' mails... You are complaining about missbehaviour but cannot give real points as long as you do this for mathed I don't care, but when you bring tabulars in the discussion I at least have to say you that you have to give me more pointers to be able to make you "feel good". Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Someone will try to honk your nose today.
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 Andre Poenitz wrote: > One item is: > > - new doc > - click on table toolbar entry to create 'standard table' > - move cursor around in the cell > > Cells touch by the cursor get a red box (which is ok) but retain it even > after the cursor left. Nothing serious, but 'unexpected'. Hmm this is obviously a bug (cell is not redrawed) I changed something in that logic recently to fix a bug so a redraw has to asked explicitely and is not done automatically on an unlock request (which I find better) I obviously missed one place to put a UpdateLocal(bv, CELL, false) in some spot inside insettabular.C I'll find it. This are really small things but if not reported it's not obvious that I will see them ;) So now the next one? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Each new user of a new system uncovers a new class of bugs. -- Kernighan
Re: PATCH: Fix page up/down behaviour
On 18-Apr-2002 John Levon wrote: >> Cells touch by the cursor get a red box (which is ok) but retain it even >> after the cursor left. Nothing serious, but 'unexpected'. > > Argh argh regression regression :) #:O) > Why does this bug haunt us so ... Maybe because we the implementation is not perfect? Anyway this are really easy parts to fix now it's just an update call in the right place. And this can only happen for tabulars as all other insets have a "fixed" frame! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Peace is much more precious than a piece of land... let there be no more wars. -- Mohammed Anwar Sadat, 1918-1981
Re: Graphics & Export LaTeX: non-eps-graphics cause trouble
On 19-Apr-2002 Herbert Voss wrote:
> Angus, I think Rob means that file->export->latex should not
> write the original filename. for example:
> \includegraphics[...]{my.agr}
> is the original latex code. Rob wants it as my.eps in the
> exported texfile.
But can't we anymore have \includegraphics[...]{my}?
Didn't we say this is good if we want pdf and ps output?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Machines that have broken down will work perfectly when the repairman arrives.
Re: [Bug 257] insert file in tabular doesn't work
On 19-Apr-2002 Edwin Leuven wrote: >> Well have a look at your file and HOW we insert files in tabulars. >> TAB's are column separators, NEWLINES are row separators (normally). > > Indeed this is how it should be Well I guessed so. >> We could however don't check for the existence of >> TAB's and honor the NEWLINES as rowseparator anyway, hmm seems like a >> good idea as you could always insert the whole file inside the cell by >> just being inside the cell when calling the function. Opinions? > > I don't think that it is a good idea to make inserting dependent on where you > stand in the table. I think it's better to have a separate menu item I think it is otherwise you cannot fill only a part of a tabular with data, or if you refer to the "dummy" position and being "inside" an inset this is also needed otherwise you are not able to force some actions to happen inside the inset and not on the tabular. > I already don't understand why you can have your cursor in a cell and don't be > in the cell, if you know what i mean The reason is easy. When an action is abivalent, that means it could be applied to the tabular or to the inset then you decide where to apply it, otherwise we would need some dialogs opening or double all lyx_func functions to tell them do_it_in_tabular or do_it_inside_inset not really appealing. Anyway you didn't answer to my question! What did you paste and what did you expect! As you wrote the bug-comment I just cannot figure out what is wrong. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Harrison's Postulate: For every action, there is an equal and opposite criticism.
Re: [Bug 257] insert file in tabular doesn't work
On 19-Apr-2002 Edwin Leuven wrote: >> Anyway you didn't answer to my question! What did you paste and what did >> you expect! As you wrote the bug-comment I just cannot figure out what is >> wrong. > > Paste? Well I meant "insert files as lines", but it's mainly the same as doing a Paste of an external selection! > When I filed the bug, "insert files as lines" did not correctly insert the > file in the tabular (respecting the tabs etc). > > afaik you fixed this bug some time ago. In current cvs things are fine. Sorry, but someone (John?) reopened the bug telling us that it does NOT work properly, I was only replying to your mail. If you think all works as you would expect we can reclose the bug. Greets, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Expansion means complexity; and complexity decay.
[Bug 339] Cursor up/down in nested insets
It's easier to discuss this on lyx-devel so I go for that way. > As before, in a new document create a footnote and within it an ERT inset. > Don't enter any text. > > Cursor right before footnote: >does nothing, should enter footnote Why you are at the left of the footnote and press DOWN why should the cursor go right??? > Cursor at beginning of footnote (right before ERT): >goes outside footnote, should enter ERT Again you are left of the ERT inset in the last row of the footnote if pressing DOWN you shouldn't go right you should navigate down! > Cursor at beginning of ERT: >goes outside footnote, should do nothing Why again! You are in the last row of the ERT and in the last of the footnote Down should leave the ERT and the Footnote! >goes outside footnote, should go to beginning of foonote Same as above you are in the first row of ERT and first of footnote! > Cursor at end of footnote (right after ERT): >goes outside footnote, should go into ERT Ditto! > By the way, " and behave logically, not visually" wouldn't be a good > answer, because > a. It's inconsistent with the behavior when there *is* some text around the > insets -- try it. Please explain I think it IS consitent! > b. It's inconsistent with mathed cursor navigation (go Andre!). I don't care how navigation is inside mathed I think that navigation on the main LyXText has always been visually and not logically. I understand that this may be different in formulas and that Andre did the right thing there! > c. It's incompatible with the principle of least astonishment. I think moving the cursor visually is the on with least astonishment! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The main problem I have with cats is, they're not dogs. -- Kevin Cowherd
Re: [Bug 339] Cursor up/down in nested insets
On 19-Apr-2002 Eran Tromer wrote: > (Note: the old screenshot was inaccurate, since I faked the cursor (it > wasn't captured) just to show where I'm putting it logically. I've now > updated the screenshow to be perfectly accurate.) > > The inset is one line below and 1 pixel to the right of the cursor. Are Yes that 1 pixel makes the difference and for that single pixel (actually I think there are 2 of them ;) you move to the right and not down. > so makes more sense than . Sorry but I don't agree with you here. > Unless... Maybe by "inset" you refer to the label, while I refer to the > editable region? Indeed the former is to the right and the latter is > below, so that would explain things (both here and in the added-text case). [snip] It refers to the inset as whole, but the interesting part is the editable area. > Minor indeed, but these sort of minor annoyances are a major part > of the mythical "user experience". This is the sort of stuff that makes > things "feel wrong". Not 1.2.0 stuff, but there should be a bug filed on > this (unless it's fixed as a by-product of this one). I don't agree here to this is not a bug in my opinion and the behaviour should not be changed, so as simple as that I will close the bug with a WONTFIX. Obviously I respect your opinion, but I just feel that it would be wrong changing the cursor-movements as you ask to do. Greets, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ [Wisdom] is a tree of life to those laying hold of her, making happy each one holding her fast. -- Proverbs 3:18, NSV
Re: [Bug 339] Cursor up/down in nested insets
On 22-Apr-2002 Eran Tromer wrote: > Anyway, at least now we're in sync: the criterion is strictly visual, to > the level of single pixels. Got it. Please allow me to try your patience > and go back to the original example (ERT in footnote). #:O) > >>Cursor at beginning of footnote (right before ERT): > >> goes outside footnote, should enter ERT > > > > Again you are left of the ERT inset in the last row of the footnote if > > pressing DOWN you shouldn't go right you should navigate down! > > There's nothing strictly below the cursor, so by your criterion > should do nothing. Instead, it goes up and right. [snip the rest] I may agree on this with you. The problem is that we cannot fix this and it is REALLY a very special case, isn't it? The problem is that the inset wants to go down sees there is no row below and decides to unlock itself to permit the outerworld to handle this cursor request. A unlocked cursor as default goes to the back of an inset. Now in this special case you don't have a row below the inset so it just stays there. But IMO this is the right thing to do, so you just can go on editing from that spot on. In your case we would have to check from the inset if the outside paragraph (LyXText) has another row and only unlock the inset if this happens. I'm sure then people will complain that they are on the last row editing and have to press ESC or go to the right of the inset to be able to go on editing, while before they had to press just "Down" and could go on editing. >> I don't agree here to this is not a bug in my opinion and the behaviour >> should not be changed, so as simple as that I will close the bug with a >> WONTFIX. > > Uhm? I thought you admitted this one is a bug. No not really. I didn't admit it is a bug. I only admited that depending on who uses it, the one could have different tastes. We obiously could just create a dummy row below so when moving down we will go there, but I guess this is really not worthwise the time. Hope you understand now that this is REALLY a minor annoyance in a VERY certain situation, which, in your case, is VERY theoretical, isn't it? Greets, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You own a dog, but you can only feed a cat.
Re: [Bug 339] Cursor up/down in nested insets
On 22-Apr-2002 Andre Poenitz wrote: > On Mon, Apr 22, 2002 at 12:31:16PM +0200, Juergen Vigna wrote: >> I may agree on this with you. The problem is that we cannot fix this and >> it is REALLY a very special case, isn't it? The problem is that the inset >> wants to go down sees there is no row below and decides to unlock itself to >> permit the outerworld to handle this cursor request. A unlocked cursor as >> default goes to the back of an inset. > > May I suggest to the both of you to get this _somehow_ working and postpone > the "proper solution" to 1.3? I don't think we have to do anything on this. For me the behaviour is correct as it is (somehow ;) >> Hope you understand now that this is REALLY a minor annoyance in a VERY >> certain situation, which, in your case, is VERY theoretical, isn't it? > > Is it _somehow usable_? Then mark it "wontfix"... That's what we will do. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Good night, Mrs. Calabash, wherever you are.
RE: bug in latest cvs
On 21-Apr-2002 Herbert Voss wrote: > - open new doc with any class > - choose enumeration layout style > - write a word > - insert a displayed formula with alt-m-d > - write something into the mathbox > - leave mathbox and hit control-enter to get a new line > - insert a word > --> the first character appears twice in different lines Ok I've seen that and accept it as a bug, but why do you hit Ctrl-Enter in first place. Just go on typing your text! Are people the same opinion as myself that the cursor should never apear "behind" a displayed inset or an inset which is NeedFullRow? Obviously if we say yes to the above question we would have to always add a row below the inset in LyXText (not really difficutlt ;), so that we HAVE a row to go to with the cursor. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Satire is what closes in New Haven.
Re: [Bug 339] Cursor up/down in nested insets
On 22-Apr-2002 Eran Tromer wrote: > A naive question of Bugzilla policy -- if this is an acknowledged by all > as a problematic issue, why mark it WONTFIX as opposed to setting a > far-away milestone or something? Definitely not 1.2.x stuff, but you do > want it addressed *sometime* by *someone*, don't you? No I don't think I will fix this, therefore I marked it WONTFIX. It may get fixed with other changes we do, but only as consequence (about the mail I wrote earlier where to display the cursor when behind a NFR-Inset). > BTW, did you notice how LyX gets horribly slow when you create comments > that are nested 15 levels deep? We have to do too much update calls the more nesting we get because we can never be sure what our child did. We have to find a better solution for this, but for now I would say don't nest so deep are you sure you need this? Or do you just test stuff :) > > About this SPECIFIC subissue you said "It should go into the footnote > not ERT though, I agree there." Did I really say that? I think it was John. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ There are few people more often in the wrong than those who cannot endure to be thought so.
Re: bug in latest cvs
On 22-Apr-2002 Jean-Marc Lasgouttes wrote: > So it the item of a paragraph (think display math) is needfullrow, we > would always have this nasty empty line? I think this will confuse > people a lot. No we will ONLY have it if we are on the LAST row of LyXText! Hmmm, no let me see, hmmm, well let me specify better, we should have this only if the inset is the last character of a paragraph. The row anyway will go away as soon as we leave it and should come back when we hold again that cursor position. Do you think it is confusing to create an empty row to put the cursor in when needed? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The first marriage is the triumph of imagination over intelligence, and the second the triumph of hope over experience.
Re: [Bug 339] Cursor up/down in nested insets
On 22-Apr-2002 Andre Poenitz wrote: > Did I mention "drawing in two phases: one for metrics computation and one > for the actual drawing" lately? Well in a certain mode we do this already, we draw it so many times until we got all metrics ready and this can be a multiple step and it can take more than 1 go to get it right depending on the nesting level. Look that in difference to mathed insets the InsetText can have a changing width height so you're not able to calculate all in one go. It's easy in mathed because all has it's fixed size. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ A clash of doctrine is not a disaster -- it is an opportunity.
Re: bug in latest cvs
On 22-Apr-2002 Jean-Marc Lasgouttes wrote: > Juergen> Do you think it is confusing to create an empty row to put > Juergen> the cursor in when needed? > > Can we experiment with it later? In 1.3.0? Sure! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The worst sin towards our fellow creatures is not to hate them, but to be indifferent to them; that's the essence of inhumanity. -- G.B. Shaw
RE: [Devel] Crash
On 22-Apr-2002 Michael Schmitt wrote: > at the weekend, I have noticed that LyX crashes eventually (about every > three to fives hours). Unfortunately, I cannot give you a detailed test > case. The only thing I can provide is the following backtrace. Any idea > what is going wrong? If I remember correctly, the cursor was at the end > of the line and there was a note inset on the next line when the crash > happened. Well the backtrace is very clear and it is the EmptyPargraphMechanism or the removing of a double space hittung us here. We want to set the cursor to the pos 184 of the paragraph which most probably does not exist anymore. It should be easy to trace the problem with an example file, but a "stable" version does not abort there we'll put the cursor on the end of the paragraph. Only "development" version will have that assert so this shouldn't hit our users on 1.2.0 final, isn't it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ panic: can't find /
Re: bug in displaying of picture
On 23-Apr-2002 Angus Leeming wrote: > Yes. Remember that I had to rewrite the code pretty-well from scratch and > that meant learning how it worked as I went along. I just came up with a > solution that was logically correct. > > Storing the "modified" images in the graphics inset and use of > boost::shared_ptr will make all more transparent. 1.3 stuff. Well I don't know, do you care about insets in the undo buffer? Every undo instance can have an inset which refers to the image. And one more thing why do you don't reload the image if we don't have a GC for it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ The more I want to get something done, the less I call it work. -- Richard Bach, "Illusions"
