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: 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: 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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: 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. 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. 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?)
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: 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: 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: 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: [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 map 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: 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: 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: 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: 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: 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: 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: 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
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
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: [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: [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: 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: 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: 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: 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: 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: 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: 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()
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: [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: [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: 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: 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: [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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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: 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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: 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: 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: 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: 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: 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Holding patch
I have still this patch in my tree. Ok to apply?
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
? diff.patch
? qt-build
? xforms-build
? src/ext_l10n.h
Index: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.549
diff -u -p -r1.549 ChangeLog
--- src/insets/ChangeLog6 Jan 2003 14:02:23 - 1.549
+++ src/insets/ChangeLog7 Jan 2003 16:19:41 -
@@ -1,3 +1,8 @@
+2002-12-17 Juergen Vigna <[EMAIL PROTECTED]>
+
+ * insettext.C (localDispatch): hopefully fixed cursor up down
+ movement on leaving other insets.
+
2003-01-06 Michael Schmitt <[EMAIL PROTECTED]>
* insettext.C: fix inconsistent usage of spaces, colons, capitalization,
Index: src/insets/insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.338
diff -u -p -r1.338 insettext.C
--- src/insets/insettext.C 6 Jan 2003 14:02:24 - 1.338
+++ src/insets/insettext.C 7 Jan 2003 16:19:42 -
@@ -1223,20 +1223,10 @@ Inset::RESULT InsetText::localDispatch(F
}
break;
case FINISHED_DOWN:
- {
- LyXText *lt = getLyXText(bv);
- if (lt->cursor.irow()->next()) {
- lt->setCursorFromCoordinates(
- bv, lt->cursor.ix() + inset_x,
- lt->cursor.iy() -
- lt->cursor.irow()->baseline() +
- lt->cursor.irow()->height() + 1);
- lt->cursor.x_fix(lt->cursor.x());
+ if ((result = moveDown(bv)) >= FINISHED) {
updateLocal(bv, CURSOR, false);
- } else {
bv->unlockInset(this);
}
- }
break;
default:
result = DISPATCHED;
Re: [PATCH] fix page up/down across tables
John Levon wrote: I mean that if you can't fix the bug you shouldn't label the fix a bad idea. But it is a bad idea in my opinion (the fix in general I mean not the particular code lines), anyway I just want to have the lines there so that I don't have to download an earlier version to see how to fix it, as now I have a Pentium 4 2.56 GHz 512MB Ram at home ;) I've no real problem with including #if 0 stuff, even if it's pointless as it will undoubtedly just sit there eating screen estate for months I hope not :) anyway we need a general fix for PgUp/Down to scroll on real screen estate and not on cursor rows, but that's probably something for 1.3.x (x > 0) or 1.4.x and not for right now. So for now your fix "as temporary solution" is ok. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] fix page up/down across tables
John Levon wrote: On Fri, Dec 20, 2002 at 09:58:08AM +0100, Juergen Vigna wrote: Well I don't think this patch is a good idea and if we insert it that way I at least want a #warning there and I would like to have the old code there #if 0 out as the existing code should be the right on and the new code is a big regression. Where's your patch ? Do I have to include the #if 0 ... #else ... #endif in your patch or what do you mean? I don't think that all you do is gold isn't it, ahh and I forgot sorry for not beeing that active lately! BTW.: Why do I need to send a patch for a patch? Do we have new rules? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] fix page up/down across tables
Andre Poenitz wrote: On Fri, Dec 20, 2002 at 01:26:02AM +, John Levon wrote: This works OK for me. Note it fixes only one mode of failure - several other cases are still broken. But those are not regressions, this is. OK ? Looks ok. Well I don't think this patch is a good idea and if we insert it that way I at least want a #warning there and I would like to have the old code there #if 0 out as the existing code should be the right on and the new code is a big regression. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: xforms 0.88
Angus Leeming wrote: We also asked what were the problems you were having with upgrading and you never answered... xforms claims to be api-compatible, so if you have a problem it should be fixed. That's hard to do without info... I don't think it's an xforms problem (althought you cannot compile 0.88 programs using 1.0 without source code modifications), it's more a my problem to not have that much spare time :( Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: xforms 0.88
Lars Gullik Bjønnes wrote: I thought you switched to xforms 1.0 now? Nope and I don't have the time right now to get a new version for my mailer program and recompile and test it to be able to use it with xforms 1.0 (if yet supported by it). I told you so earlier you didn't believe me ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: xforms 0.88
Andre Poenitz wrote: On Tue, Dec 17, 2002 at 09:27:12AM +0100, Juergen Vigna wrote: Well I take it xforms 0.88 is no longer supported, is it? Since yesterday or so. Well then someone else has to test the 2 patches of Alfredo on xforms :( Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
xforms 0.88
Well I take it xforms 0.88 is no longer supported, is it? I just tried to recompile lyx and it gives me xforms errors about unknown functions. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH] Visualize small/med/bigskips
John Levon wrote: Ping me again just after 1.4.0cvs opens and I'll apply it. Did you look at the patch? I think this will surely not introduce any bugs I would opt to include it now (just my opininon). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [PATCH][RFC] Use locale codec for Qt key insert
John Levon wrote: It would be great if people could give this a go. It Works For Me. I did not yet look at the patch, but I have a question. Are you talking about having the menues and translated strings displayed good or are you talking about writing texts in other languages? If the first your patch may be ok, if it is the last one then surely it is not ok. I WANT to have my menues and the rest in en_US (as that is my standard LANG environment althought I'm living in Italy and my mother tongue is german ;), but I HAVE TO write text in other languages then english (german/italian), and this is surely possible with the xforms frontend, if this is not possible with the QT frontend it is a really big limitation and we can never have qt as your choosed first frontend. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Cursor movement in nested insets
I will commit this 2 patches soon. Just one comment next time please include the ChangeLog entries I did it this time this is a pro as then they will contain you name and not mine ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Cursor movement in nested insets
Alfredo Braunstein wrote: John Levon wrote: On Thu, Dec 12, 2002 at 06:59:42PM +0200, Dekel Tsur wrote: Yes, the problem is only with cursor down. I careated a bug for this. Thankfully, it's not a 1.3 regression After some disentangling, I think I've found the reason (insetext not returning DISPATCHED after its child processed the event). I've tested it a little and seems to work nicely. Please test (patch). If it works correctly I would say we should apply this. patch2 corrects the inversion of LFUN_WORDFINDBACKWARD and LFUN_WORDFINDFORWARD. Cut'n Paste bug it seems ;) This should be applied! Thanks for your help! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: LyXLookupString
Lars Gullik Bjønnes wrote: Juergen Vigna <[EMAIL PROTECTED]> writes: | only 1.0 version of xforms (then I will have the time to use only qt | version of LyX as I need 0.88 version of xforms still for some other old | programs. For compiling them, or running them? For compiling them. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: LyXLookupString
Angus Leeming wrote: Agreed. Lars is suggesting setting up an entirely separate tree. I anticipate having #ifdefs in LyX's xforms frontend for the foreseeable future. Having said that, did we come to a consensual view on what version of xforms to support in LyX 1.3? I'd prefer to throw out both 0.88 and 0.89. The former because it's really old and doesn't have image support. The latter because there is no clean separation between 0.88 and 0.89. The functionality comes with 0.89.5. It seems ridiculous to have to justifying that to a user of 0.89.2 for which no other 0.89 binary was released. Justifying use of 1.0 can be done on both political as well as practical grounds. Shall I just go ahead and strip the #ifdefs out? Well I would prefer to wait for 1.4.0. We are more or less in codefreeze and I would not like to remove this lines just now (and maybe create more problems). Other than that I have still 0.88 installed and compile with it ;) as surely have other people too. I would like to release 1.3.0 which still suports all version but announce that the next version will support only 1.0 version of xforms (then I will have the time to use only qt version of LyX as I need 0.88 version of xforms still for some other old programs. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: New insights in tablular problems?
Michael Schmitt wrote: Hello, I think I have finally found a tabular bug that is easily reproducible and - hopefully - easy to debug. (And I hope all known tabular problems are related to each other. ) - Open file "tableerror.lyx"; - for i = 1 to 25: - move cursor down to the i-th cell/row (with the keyboard) - click on another X application such that the LyX windows looses the focus - click on the LyX window title bar such that LyX gets back the focus At some point in time, LyX will scroll the document, even though this is totally unnecessary. In some cases, the cell with the cursor inside will even be moved out of screen. Moreover, watch the cursor: you can see it jump occasionally. Any ideas why this happens? Well I tried all of it and I don't see any strange behaviour this with standard xforms-0.88 version ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: autoconf 2.56
Lars Gullik Bjønnes wrote: Then allow 2.56 too in the autogen script. It is nice that we allow only autoconf version that we know work there. Well yes the problem is that I don't know if autconf 2.56 does need automake 1.6. Do you know more than me about that? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: autoconf 2.56
Jean-Marc Lasgouttes wrote: "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> I installed automake 1.6 and had to upgrade also to autoconf Juergen> 2.56, now autogen.sh tells me that autoconf 2.56 is not Juergen> supported by LyX, are we serious about that? Probably not. Try it. I compiled both xforms and qt version from scratch with autoconf 2.56 and automake 1.6 and it worked. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
autoconf 2.56
I installed automake 1.6 and had to upgrade also to autoconf 2.56, now autogen.sh tells me that autoconf 2.56 is not supported by LyX, are we serious about that? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: bug
Andre Poenitz wrote: On Thu, Dec 12, 2002 at 10:01:03AM +0100, Alfredo Braunstein wrote: I mean the paragraph where the formula is. Rephrasing it, I would expect the same behaviour if the cursor if just before or after a math inset than if its inside. Does it makes sense? A bit, but all I can offer is to put the cursor immediately in front of the inset as "directly going to the start of the enclosing paragraph" would need more code in areas I do not want to touch right now. What we would need is some sort of FINISED_BUT_UNDISPATCHED status as return from the inset or and IMO this would be better to rethink all this strategy so that we should be able to only return DISPATCHED or UNDISPATCHED from the inset. Shouldn't be to hard but this may be a thought for 1.4.0. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Letter - My Address
Lars Gullik Bjønnes wrote: With letter you have to use the template... without you are doomed to miss required layouts and their order... IMO this could be a real enhancement for LyX, some sort of order of layout tags and also to be able to define a Layout which has to be inserted in the final LaTeX output (obligatory layouts) also if they are not in the actual document. Someone could make an enhancement proposal on LyXZilla ;) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: xforms 1.0 final released
Jean-Marc Lasgouttes wrote: So what was the final decision on this? I think we should get rid of 0.88 now, since it is the most problematic. Note however that this will cause problems for people who use solaris and for cjk-lyx, because of shortcomings ion xforms support for input methods. But this problems have to be faced and solved anyway. Why do we have to remove support now? We have all in place IMO this could wait till 1.4.0 (as then also xforms 1.0 will have a larger acceptance). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Code Freeze
Moritz Moeller-Herrmann wrote: Hmm, life would become easier for lyx and other projects, if lyx used standard sizes. Also most if not all of the KDE icons are available as SVG, so you could just rerender them for the lyx size. Hmm if you tell us the rule for "standard" size? As much as I know also all major Desktop Environments and Window Managers (CDE, KDE, GNOME, Fvwm, WM, ...) all of them use different "standard" sizes. If you tell us to use KDE style size or GNOME style size or maybe LyX style size #:O) we can decide and probably we will decide for LyX style size ;) I just want to point out that before us others should agree on a standard size then application which can use more than one "toolkit" and LyX now can, won't have this type of problems. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Patch: alignment in fixed width columns in a table
Alain Castera wrote: [snip] Unless somebody points me to a better method, I will go on this way as it seems to me that it is the simplest way to obtain wysiwym display of fixed width columns in a tabular. When it will be possible to test it, it will still be time to discard everything ;-) I read all of the above and am still confused. You want to do this all to have WYSIWYG (more or less) on screen isn't it? Why do we need more variables for this? Couldn't we just have some parameters that tell the draw function what it should draw? As the final output is all right I don't see a necessity to add more buttons to the layouts. What do others think and more what do you think? Would it be possible to have WYSIWYG without resorting to adding more buttons to the layouts? Note : the patch force column alignment to switch to "block" anytime you enter the InsetTabular::tabularFeatures function with argument feature == SET_PWIDTH. The corresponding line of code should be deleted, or at least executed only if tmplen.zero(). Could you explain this and/or send a patch? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Patch: alignment in fixed width columns in a table
Alain Castera wrote: Investigating further on how to display these settings, I am now in trouble and need your advice : Tabular is now a case (but not the only one) where the alignment may be given by the "context" (e.g. the owner of the text inset, or the layout ...). In such case, it is impossible to distinguish between "default" alignment and an explicit "justified" block alignment, both being represented by ALIGN_BLOCK and both being exported as ... nothing. So my question are : - Is it possible to force a text to be justified when the layout defaults to another alignment (this works well in case of tabular cells for other alignment because of the precedence of the LaTeX commands) ? - If the answer is yes ( please give me the magic : minipage? parbox?), shouldn't we make a distinction in the paragraph's parameters between "block" (i.e. justified) and "default" (in which case somebody will have to change the pop-up menu) ? Hope I am clear enough. Sorry for the late reply. Anyway I don't really grap what you mean. Does somebody else have some knowledge to help him? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: segfault on saving new document
Darren Freeman wrote: One more thing. Load a file. Click File->Save As You guessed it. *BOOM* Seems like saving to a new disc file is what kills it, except for some reason when you created a new one by invoking lyx with the filename. Whoever knows why this is, please help! Too many segfaults and I won't get anything done =) I can reproduce this here too, I'll try to debug it :) (it only happens if I select a new filename from the filebrowser an already existing one with double-click in the Save As Dialog!) Thanks for your report! Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: FormTabular (longtabular)
Juergen Spitzmueller wrote: I wonder if the attached patch fixes a lot of cut'n'paste bugs. If not, I do not understand the longtabular stuff at all. Please have a look. Well it's a bit hard to read but it seems this are cut&paste bugs fixed. Seems pretty safe to me to apply and you surely tested it, didn't you? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: the qt key problem
John Levon wrote: People with these problems need to find EVERY failing case and add it into the table. Well I think in first place we have to investigate WHY it doesn't work for some people. As I told you it works for me with qt3. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Patch: alignment in fixed width columns in a table
Alain Castera wrote: I am this bad boy, I guess. Yes I still remembered it was an .fr but I couldn't remember the name ;) But I am not guilty for that : Earlier, the alignment menu in tabular proposed Left, Center and Right only, the default being left. As I promised to implemented "fixed width alignment" with minimal changes, I kept this setting ... (Ok, the real reason was that I didn't want to take any risk in the necessary modifications of the xforms part of the code, while I didn't noticed that the default (left) was in fact justified and not left aligned ;-) > I don't understand, what bug (shame on me:-) ? I would say this implement > an obviously missing feature, but may be am I missing some point. > Well before we always had a Block alignment (default) and left was only if we selected it in the paragraph layout, so in regard of the old behaviour this is a bug ;) What is still pending is the wysiwym display of these features. I proposed to add a flag "formatDisplayOnly" to the text inset/paragraph, in order to use the actual display mechanism (the one which is involved when you set the alignment via the paragraph setting) without modifying the LaTeX output, but this approach requires a better knowledge than mine of the internal structure of LyX code if one doesn't want to break the encapsulation too much. Anyway, I really need these features, so if you think that wysiwym is mandatory, please feel free to ask me for some help and I will do my best. It is not mandatory right now, but if you could try to make it work and you do it in a clean way why not add it ;) Greets, Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BUG: Umlauts in qt-lyx
John Levon wrote: On Thu, Nov 21, 2002 at 04:33:32PM +0100, Juergen Vigna wrote: Well but you have to try this patch as you told us it is buggy, won't you? I can only test and confirm or not confirm the claims, but you said it reintroduces a bug so you would have to explain us that. Herbert said it doesn't, because of changes elsewhere Well anyway I just compiled the latest version and I don't have any problems to insert äöüÄÖÜ in lyx. So I would really like to know what the real problem is. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BUG: Umlauts in qt-lyx
John Levon wrote: I wouldn't know how to try it. It took me long enough to work out how to get my keyboard to compose umlauts :( I'm really really lame with this stuff Well but you have to try this patch as you told us it is buggy, won't you? I can only test and confirm or not confirm the claims, but you said it reintroduces a bug so you would have to explain us that. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Patch: alignment in fixed width columns in a table
Dekel Tsur wrote:
Block alignment is the default, so you don't need to write anything.
Namely, the column specifier is e.g. p{4cm}
For other alignments, you need to write >{\centering}p{4cm}
Oh I understand now. This is due to the patch written by ???
(fill name here) which I said I didn't like very much but it
was better than nothing. Earlier we could change alignment only
over the paragraph settings. Isn't it?
Well this fixed definitively a bug I surely give my go for it as
it seem pretty safe to apply.
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BUG: Umlauts in qt-lyx
Herbert Voss wrote: I know that #:O), but not all hosts have a decent installation of latin15 fonts yet I have a quite recent RedHat 7.3 (with all updates) and also there are problems with latin15, so that I think we should leave default latin1 fonts until we can make sure that latin15 is supported generally good enough. When it is no problem to insert an Eurosymbol in any qt-window, it should also be no problem to insert it in the lyx-qt one. Sure you're right maybe for your installation but can you assure us that on all other installtion there will be no problem, I don't think so right now. Anyway you're right for your installtion and IMO we have to fix this problem, obviously! the umlaut problem is a general one and has nothing to do with latin1 or latin15 Ok good so I can try it here locally too (and John too); BTW: I ordered already my new P4 2.53 ;) so in maybe 2 weeks I can start doing something at home too #:O) Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BUG: Umlauts in qt-lyx
Herbert Voss wrote: it is the setting to get the Euro symbol work I know that #:O), but not all hosts have a decent installation of latin15 fonts yet I have a quite recent RedHat 7.3 (with all updates) and also there are problems with latin15, so that I think we should leave default latin1 fonts until we can make sure that latin15 is supported generally good enough. Obviously you are free to change this for your local installation. But my real question was if the problems you have with umlauts are only with the 15 fonts or also with latin1 fonts. Ciao, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: BUG: Umlauts in qt-lyx
Herbert Voss wrote: -german german "German" false iso8859-1 de "" -ngerman ngerman "German (new spelling)" false iso8859-1 de "" +german german "German" false iso8859-15 de "" +ngerman ngerman "German (new spelling)" false iso8859-15 de "" Hello Herbert! What I don't like here is the iso8859-15 change IMO this should still default to iso8859-1 at least in the default configuration! Do you have this problem also with latin1 or only with latin15? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Patch: alignment in fixed width columns in a table
Dekel Tsur wrote: Currently, when creating a fixed width column n a tabular, the possible alignments are left, right and center. It is not possible to have block alignment. The following patch fixes that. OK to apply ? What I miss here is the LaTeX output for the BLOCK alignment, I don't see it in the patch. What for is it if it's not in the LaTeX output? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Patch for scroll lookup in insettabular
This patch should fix the lookup when a tabular cannot scroll to the right location. This might have the effect that we're not always displaying what we really want (but this is to be demonstarted), but surely that is better then having a endless loop inside LyX. Jürgen P.S.: This should also fix #615 (John's earlier mail bug 1 in it's list) -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Index: src/insets/insettabular.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.C,v retrieving revision 1.231 diff -u -p -r1.231 insettabular.C --- src/insets/insettabular.C 4 Nov 2002 02:12:34 - 1.231 +++ src/insets/insettabular.C 18 Nov 2002 14:21:20 - @@ -1563,7 +1563,7 @@ void InsetTabular::resetPos(BufferView * #warning This should be fixed in the right manner (20011128 Jug) #endif // fast hack to fix infinite repaintings! - if (in_reset_pos > 10) + if (in_reset_pos > 0) return; int cell = 0;
Re: 1.3.0 release bugs
John Levon wrote: If there are bugs that should be on this list but aren't, tell me. infinite loop trying to search http://bugzilla.lyx.org/show_bug.cgi?id=615 page down for large tables broken http://bugzilla.lyx.org/show_bug.cgi?id=618 - need guru help I don't think this is easy to fix. We would have to redo the whole page-up/down scroll routine to not scroll on lyx-rows but on real screen heigth. The example is really a special one because the tabular is on the last row of the document. If you would have another row below the tabular you'll see the scrolling works. Also if you enter the tabular scrolling also works. So this is basically a general page-up/down key scroll error and not really connected in particular to a tabular. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: tiny...
Andre Poenitz wrote: This saves a few chars. Ok to apply? I like the old way more, but it surely seems correct. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: lyx-devel src/: ChangeLog undo_funcs.C
Dekel Tsur wrote: On Fri, Nov 08, 2002 at 03:51:03PM +, [EMAIL PROTECTED] wrote: Log message: Backed out a change of my last patch which I now see is not correct. This should fix the undo bugs we see. This should also be done for 1.2.2. Is it OK to apply this patch ? Yes please do so. IMO this fixes the bug we see and Jean-Marc will be surely happy. (as told earlier it just removes the buggy part of my earlier patch). 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
j.heidemeier wrote: o.k. - you are the developper. Well yes but I won't have the time to implement this :( But reffering to your last mail your solution for the optional argument is not clear to me. If we interpret the first word of a caption in a cell as optional argument, how do we omit it - as it is optional we dont have to enter it. Maybe it is better to take the convention that the contents of col. 1 is the fixed argument and the contents of column 2 ist the optional argument in a caption row. What about tabulars with just one column? If you don't have an optional argument start with a hard space. I know this is suboptimal, so if people don't like it give us a better idea. An optional argument inset would be best IMO. 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
j.heidemeier wrote: Hello Juergen, tnx for the quick reply. #:O) In principle yes (thats the way I made it in my report) but as longtable only have a footer and lastfooter and no firstfooter tag you have the problems with the list of tables (multiple entries in the lot or wrong pagenumbers). Several years ago there was a thread in USENET about the toc problem, where the author of longtable package explained why it ist difficult to have a firstfooter in longtable and that table-captions definitly _ARE ABOVE THE TABLE_ due to typographic reasons. So the solution was to manully edit the aux file. Well anyway we have then to insert the button in all 4 posibilities and not only to the headers (therefore the question). I see your point, but I'm not shure how to visualize the fact that the caption row is not in a cell but a caption above the table. That was the reason why I proposed separate entry fields. It is (relatively) easy to change the visual on screen, LyX is not WYSIWYG and so we don't have to take care all is equal to the _real_ output afterwards. As Header/Footer definitions are made now I also can put them _anywhere_ in the tabular and they the are correctly put into the latex/docbook file, if the author just doesn't care where to put them he surely does not care to see them where he put them. The same is for caption, the important part is the we *can* insert them and that the real output is right. I really would like to enhance the visual feedback about what are header/footer rows (maybe painting the rows with different backgrounds) in future, but for now this is not really important and can always be added later it's just a missing feature. BTW should we do the emails in German or English I would prefer English as I really would like that discussions like this take place also on the mailing list. Maybe others do not answer but all of them read it and more than one other is interested in the outcome ;). Myself reads most of the posts to lyx-devel althought I don't have the time to follow all of the treads I try to filter out what I'm interested in and if I really see that the discussion goes in a direction I don't like than I can always send a mail telling my fellow co-developers my opinion. Greets, 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
Hello Joachim!
Let me summarize what I understood from your mail:
We can have a caption for longtables in the firstHeader and a different
one in a normal Header (or if I ommit the FirstHeader then the other one
is valid for all of them).
Question: Is it possible to have a Footer-Caption?
I don't like the solution to implement this feature. I don't want
text input fields for this type of stuff. The text should be inputed
directly in the tabular (as then one has all option open regarding
fonts etc.).
I see the solution of this to put another button inside the FirstHeader/
Header rows which tells the tabular that this row of the (F)Header is
a caption row and then the output routine can handle this transparently.
We can say that the first word of this row will bee the [] text (hard
spaces do not interrupt a word so you can actually have more then one
real word inside the [] see lists) and the rest will be the {} text.
The above should be _really_ easy to implement.
Let me know how you like the idea,
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Mitterstrich 151/A
I-39050 SteineggWeb: http://www.lyx.org/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: [Bug 425] link fails with undefined symbols when using gcc withnon-gnu linker
John Levon wrote: On Thu, Oct 31, 2002 at 04:47:19PM +0100, Jean-Marc Lasgouttes wrote: Now, _this_ is a problem... I hope lars can transfer it to the new aussie. Michael described it as "hell" to set up too. To start we just need the tarball from Michael, should be no problem to set it up from his installation. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
