On Thu, Mar 20, 2003 at 05:38:44PM +, John Levon wrote:
> minipage is 45% of column width. Minipage is inside a table column that
> we have just altered to have a fixed width of 2 inches. The width of
> this column dictates the minipage width which dictates the breaking of
> the cell which dict
Can somebody give me a brief summary of how/why this works ?
Especially, why can't we "reinitLyXText" when lt is non-null ?
thanks
john
People are encouraged to try this one !
Note the horrible hack in updateableinset.C. I have to admit I can't
convince myself of why this works, but it does ... and it has to be
better than all the CID code (which this patch does *not* remove - the
CID code totals at least another 80 lines)
OK ?
On Thu, 20 Mar 2003, Helge Hafting wrote:
> > I was actually expecting all quotes to change when I changed this setting
> > since it was under the Laout->Document... AFAIK, all the other settings
> > affects the entire document, and not just stuff that you add.
>
> If it changed all, how would
On Thu, Mar 20, 2003 at 06:08:44PM +0100, Andre Poenitz wrote:
> > And how does it alter its *parent* when needed ? And its parent's parent ?
>
> Ok, maybe I am realling missing the point:
>
> In what circumstances does an inset have to alter its parent [that can't be
> handled in the two-phase,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 20 March 2003 18:45, John Levon wrote:
> On Thu, Mar 20, 2003 at 04:13:23PM +0100, Jos van den Oever wrote:
>
> > I just crashed lyx 1.3.1. The recipe is easy:
>
> xforms frontend ?
>
> > - open lyx
> > - press Alt-F to open the File men
On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote:
> And how does it alter its *parent* when needed ? And its parent's parent ?
Ok, maybe I am realling missing the point:
In what circumstances does an inset have to alter its parent [that can't be
handled in the two-phase, parent-after-ch
On Thu, Mar 20, 2003 at 05:04:35PM +, John Levon wrote:
> And how does it alter its *parent* when needed ?
Nothing knows about its parent except what it gets passed in the info
structure.
By returning something in the info structure. When the parent starts doing
its calculations, the sizes o
On Thu, Mar 20, 2003 at 04:21:55PM +, John Levon wrote:
> Well Juergen I've given this some testing, and I haven't triggered
> "Darn, CID" yet. Do you have, by any chance, some suggestions for
> operations that might cause the CHANGED_IN_DRAW to happen ?
D'oh, didn't try too hard did I ...
m
On Thu, Mar 20, 2003 at 05:50:05PM +0100, Andre Poenitz wrote:
> Handling an LFUN just changes the structure of the doc, the postion of the
> cursor, whatever. It does not care about visual appearance at all.
>
> If the handling is finished, we do a full redraw. [Later we might be a bit
> more cl
On Thu, Mar 20, 2003 at 04:14:38PM +0100, Juergen Vigna wrote:
> As I told you in my earlier mail some informations you have only when
> you are in the real draw function,
At the top most draw function, we would split drawing in two phases. So the
first phase knows "everything" already.
> This is
On Thu, Mar 20, 2003 at 02:59:04PM +, John Levon wrote:
> > Not more than once per redraw.
>
> OK, what is your magical solution to the inset update problem. With
> details please ...
Simple: There is no inset update problem as there won't be an inset update.
Handling an LFUN just changes t
On Thu, Mar 20, 2003 at 04:13:23PM +0100, Jos van den Oever wrote:
> I just crashed lyx 1.3.1. The recipe is easy:
xforms frontend ?
> - open lyx
> - press Alt-F to open the File menu
> - press i (for import, which is not acivated and the cause of the problem)
Why isn't the menu activated ?
It
On Thu, Mar 20, 2003 at 11:01:23AM +0100, Helge Hafting wrote:
> Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is
> reproducible
Sheesh, well I'm a genius I made a wrong patch, fixed it, then
applied the wrong patch anyway and didn't notice. Great !
Expect a fix soon
t
On Thu, Mar 20, 2003 at 05:30:23PM +0100, Juergen Vigna wrote:
> Draw + x()!
Ohh, Inset::x() ! Right ... which types of insettext actually care about
their x() position ? As I mentioned in my other mail + patch, a simple
test of a few scenarios couldn't cause any "trouble"
> Only hours come on t
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 vari
Well Juergen I've given this some testing, and I haven't triggered
"Darn, CID" yet. Do you have, by any chance, some suggestions for
operations that might cause the CHANGED_IN_DRAW to happen ?
I'm going to commit this (maybe with an abort on CID ?) in a bit, and if
nothing happens after people li
On Thu, Mar 20, 2003 at 04:19:02PM +0100, Juergen Vigna 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 spo
Hello lyx developers,
I just crashed lyx 1.3.1. The recipe is easy:
- open lyx
- press Alt-F to open the File menu
- press i (for import, which is not acivated and the cause of the problem)
- press right arrow
crash
I've tested on SuSE 8.0 and RedHat phoebe-3 (latest beta).
Good luck with furthe
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
On Thu, Mar 20, 2003 at 04:07:25PM +0100, Juergen Vigna wrote:
> I said "most of the times", didn't I?
Ooops, so you did !
> 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.
Are you awar
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
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 InsetT
On Thu, Mar 20, 2003 at 03:47:01PM +0100, Andre Poenitz wrote:
> > This is (incorrectly) assuming that just splitting the thing into two
> > doesn't mean we don't need to do things multiple times still.
>
> Not more than once per redraw.
OK, what is your magical solution to the inset update pro
On Thu, Mar 20, 2003 at 02:23:17PM +, John Levon wrote:
> This is (incorrectly) assuming that just splitting the thing into two
> doesn't mean we don't need to do things multiple times still.
Not more than once per redraw.
> > Secondly, why should it do the calculation twice?
> > The draw ste
Christian Ridderström wrote:
Hi
I'm confused by the behavour of quotes... First there is the
difference in behaviour when comparing a Standard environment to the
Lyx-Code envionment. Here's how it works for me:
Another aspect of this is how the UI works. The setting
(Layout->Document->Language-
On Thu, Mar 20, 2003 at 03:02:55PM +0100, Andre Poenitz wrote:
> First of all, "twice" might be better than what we have now.
This is (incorrectly) assuming that just splitting the thing into two
doesn't mean we don't need to do things multiple times still. It's all
very well to talk about some
On Thu, Mar 20, 2003 at 01:51:50PM +, John Levon wrote:
> > the drawing part. At this point probably all insets need the separation of
> > their individual draw() functions into metrics() and [real] draw().
>
> Net effect: the insettexts run through all the calculations entirely
> twice. Does
On Thu, Mar 20, 2003 at 11:01:23AM +0100, Helge Hafting wrote:
> Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is
> reproducible
> with one of my files, the backtrace is at the end of this message.
Damnit, how the hell did this happen :(
I'll look into it - time to build 1.3
On Thu, Mar 20, 2003 at 09:33:29AM +0100, Juergen Vigna wrote:
> IMO this should be pretty safe to apply.
OK thanks. (Review from someone who follows the code is very helpful to
me :))
regards
john
On Thu, Mar 20, 2003 at 09:24:20AM +0100, Andre Poenitz wrote:
> On Wed, Mar 19, 2003 at 05:35:09PM +, John Levon wrote:
> > LFUN_INSET_MODIFY needs to do an updateInset() on the given inset,
> > it may change shape (e.g. minipage). This requires moving updateInset()
> > into InsetBase I guess
On Thu, Mar 20, 2003 at 09:32:01AM +0100, Andre Poenitz 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.
>
> But a two-stage approach is, isn't it?
Andre, how do you possibly expect me to be
On Thu, Mar 20, 2003 at 09:27:59AM +0100, Juergen Vigna wrote:
> 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.
heh :))
At this stage I just want to understand the basics fi
On Thu, Mar 20, 2003 at 09:17:12AM +0100, Andre Poenitz wrote:
> the drawing part. At this point probably all insets need the separation of
> their individual draw() functions into metrics() and [real] draw().
Net effect: the insettexts run through all the calculations entirely
twice. Doesn't so
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?
I
On czwartek 06 marzec 2003 12:10 am, [EMAIL PROTECTED] wrote:
> Hello,
>
> With CJK-LyX-1.3.0, lyx crashes while loading a long lyx file created with
> CJK-LyX-1.2.1. Sometimes lyx loads the file, but still it crashes during
> scrolling down or up inside the file. No backtrace debug statements,exce
Hi
I'm confused by the behavour of quotes... First there is the
difference in behaviour when comparing a Standard environment to the
Lyx-Code envionment. Here's how it works for me:
Environment Key Lyx Xdvi
Standard "a" -> ``a"a
Lyx-Code "a" -> ''a'' a
I can s
Closing an external inset in lyx-1.3.1 or 1.3.2cvs may crash. It is
reproducible
with one of my files, the backtrace is at the end of this message.
I'm using gcc/g++ 3.2 and qt3 from debian unstable.
The crash is reproduced like this:
Start lyx, open file
scroll to the external inset
bring up the
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: htt
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
| Open newfile
| enter Ctrl space
| hit enter
| hit backspace
| boom
| current 1.4CVS
Crash or assert?
(it is an assert if it says "abort" instead of segfault...)
--
Lgb
Duh! Please apply.
Alfredo
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v
retrieving revision 1.1136
diff -u -p -u -r1.1136 ChangeLog
--- ChangeLog 2003/03/19 18:43:55 1.1136
+++ ChangeLog 2003/03/20 08:53:34
@@ -1,
On Thu, Mar 20, 2003 at 09:36:38AM +0100, Juergen Vigna wrote:
> 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
On Thu, Mar 20, 2003 at 03:06:48AM +, John Levon wrote:
> On Wed, Mar 19, 2003 at 09:35:15PM +, John Levon wrote:
>
> > This is fun. Insets like InsetMinipage and InsetERT can have e.g.
> > INSET_MODIFY applied to them. This can actually alter its size. It
> > actually needs to tell its co
On Wed, Mar 19, 2003 at 09:35:15PM +, John Levon wrote:
> So it's looking very much like Andre's two-stage thingy at this point,
> just to solve a tiny bit of this :(
"Alejandro's two-stage thingy".
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor
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 dr
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
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
On Wed, Mar 19, 2003 at 05:35:09PM +, John Levon wrote:
> LFUN_INSET_MODIFY needs to do an updateInset() on the given inset,
> it may change shape (e.g. minipage). This requires moving updateInset()
> into InsetBase I guess ...
No problem.
Andre'
--
Those who desire to give up Freedom in or
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
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-
On Wed, Mar 19, 2003 at 05:12:56PM +, John Levon wrote:
> > 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
> >
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
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 sta
52 matches
Mail list logo
