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: 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: 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: 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: 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, 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: 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: 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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: 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: 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 ). ~Jrgen 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) ~Jrgen Great! When? JMarc -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jrgen 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: 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. 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: 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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: 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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: 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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?
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: [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: [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: [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 mapLyXText, BufferView) a single LyXText entry I don't think that you add a lot more redability if you change this. 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: 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[ 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
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: 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: 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: 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 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: 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: 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: [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: CutPastepress 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: Cutpaste 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: [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 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 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: [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
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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: 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: 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: 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: 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
