On Wed, 5 Dec 2001, Andre Poenitz wrote:
> On Wed, Dec 05, 2001 at 11:57:30AM +0100, Juergen Vigna wrote:
> > Anyway I love "other" things much more then stacks #:O)
>
> Shouldn't this depend on you position in the stack?
>
> Andre', just thinking...
And nobody said there has to be just one stac
On Wed, Dec 05, 2001 at 11:57:30AM +0100, Juergen Vigna wrote:
> Anyway I love "other" things much more then stacks #:O)
Shouldn't this depend on you position in the stack?
Andre', just thinking...
--
André Pönitz .. [EMAIL PROTECTED]
On 05-Dec-2001 Allan Rae wrote:
> The insets allocated memory is at the same place isn't it? Wouldn't a
> signal connection be sufficient? Or a table of waiting-insets and the
> process they are waiting for a (UNIX) signal from?
The signal stuff would be a good way to eliminate the use of a o
On Wed, Dec 05, 2001 at 12:24:53PM +1000, Allan Rae wrote:
> I guess from this you are referring to the need to know which parts of
> the document are visible -- that is, which _rows_ are visible. Do we
> need a cursor for that?
No. A "full redraw" could start searching the cursor "path" towards
On Tue, 4 Dec 2001, Juergen Vigna wrote:
> On 04-Dec-2001 Juergen Vigna wrote:
>
> > And what if the inset-pointer changed in the meantime (Undo/Redo)?
The insets allocated memory is at the same place isn't it? Wouldn't a
signal connection be sufficient? Or a table of waiting-insets and the
pr
On Tue, 4 Dec 2001, Juergen Vigna wrote:
> On 04-Dec-2001 Allan Rae wrote:
>
> > Then we should only need to use the same two cursors to do anything.
> > The second one only needed for selections.
>
> We don't the stuff is a bit more complicated when updates and redraws
> are involved. But I woul
On Tue, Dec 04, 2001 at 10:38:14AM +0100, Juergen Vigna wrote:
> Well let's say that we agree that we could change something in the
> logic in the future (and I'm not sure it will be in 1.3 as I really
> would like to have the main-view GUIIfied in 1.3, some added features
> but nothing which red
On 04-Dec-2001 Andre Poenitz wrote:
> On Tue, Dec 04, 2001 at 10:38:14AM +0100, Juergen Vigna wrote:
>> Well let's say that we agree that we could change something in the
>> logic in the future (and I'm not sure it will be in 1.3 as I really
>> would like to have the main-view GUIIfied in 1.3, so
On Tue, Dec 04, 2001 at 10:38:14AM +0100, Juergen Vigna wrote:
> Well let's say that we agree that we could change something in the
> logic in the future (and I'm not sure it will be in 1.3 as I really
> would like to have the main-view GUIIfied in 1.3, some added features
> but nothing which redo
On Tue, Dec 04, 2001 at 10:35:23AM +0100, Juergen Vigna wrote:
>
> On 04-Dec-2001 Andre Poenitz wrote:
>
> > Inset rendering is a bit special, it's the only case of asynchronous
> > operation, isn't it?
>
> Well, ...
>
> > What about giving the "I am done" call back of the inset rendering a
>
On 04-Dec-2001 Juergen Vigna wrote:
> And what if the inset-pointer changed in the meantime (Undo/Redo)?
No IMO that theLockingInset() stuff is pretty good and easy. It only
goes one direction and is only there if we really enter an inset. We
could do it with the cursor, but IMO we would add co
On 04-Dec-2001 Andre Poenitz wrote:
> I am not talking about 1.2.
Well let's say that we agree that we could change something in the
logic in the future (and I'm not sure it will be in 1.3 as I really
would like to have the main-view GUIIfied in 1.3, some added features
but nothing which redoes
On 04-Dec-2001 Andre Poenitz wrote:
> Inset rendering is a bit special, it's the only case of asynchronous
> operation, isn't it?
Well, ...
> What about giving the "I am done" call back of the inset rendering a
> snapshot copy of the cursor from the moment where the inset is created
> and rend
On Tue, Dec 04, 2001 at 09:42:52AM +0100, Juergen Vigna wrote:
> Well honor whoever you want, but I would say that a text with a 1000's of
> lines and I don't know how much insets is a bit more complicated than
> a single line math inset, don't you?
No.
What is the problem with the concept of a
On Tue, Dec 04, 2001 at 09:38:02AM +0100, Juergen Vigna wrote:
> Now an insetgraphics inside [inset2] is requesing an update because
> it finished rendering. I don't see any cursor near [inset2], do you?
Inset rendering is a bit special, it's the only case of asynchronous
operation, isn't it?
Wh
On 04-Dec-2001 Allan Rae wrote:
> Then we should only need to use the same two cursors to do anything.
> The second one only needed for selections.
We don't the stuff is a bit more complicated when updates and redraws
are involved. But I would say if you know all of it why don't you start
codin
On 04-Dec-2001 Andre Poenitz wrote:
> Honour to whom honour is true: The concept is from the math cursor first
> implemented by Alejandro. And even after the rework, the math cursor does
> exactly this: Hold two stacks of "cursor positions" (one for the cursor,
> one for the selection anchor), e
On 04-Dec-2001 Allan Rae wrote:
> Or are you just thinking of insettabular and the no-mans-land between
> the cells? Then an insettabular::iterator should handle those more
> obtuse actions. If you have two cursors with one set to the first pos
> of an inset and the second set to the end of th
On 04-Dec-2001 Allan Rae wrote:
> So you are saying that setUpdateStatus(NONE) indicates that no update
> has been done so a FULL update is needed?
Nope! NONE just gives the minimal amount of Update I envise for this
call. Then setUpdateStatus has to decide if we need more than this minimal
amo
On Tue, Dec 04, 2001 at 04:35:39PM +1000, Allan Rae wrote:
> Andre's cursor-as-a-stack implementation should work fine for this and
> would remove a bunch of stuff from the code too it would seem.
Honour to whom honour is true: The concept is from the math cursor first
implemented by Alejandro.
On Mon, 3 Dec 2001, Juergen Vigna wrote:
> > I don't think so. An inset does not know which inset contains it.
>
> Nope! It knows about it as we have Inset * Inset::owner() which returns
> 0 for top-level-insets and the containing insets for insets down the tree.
> But this has nothing to do with
On Mon, 3 Dec 2001, Juergen Vigna wrote:
>
> On 03-Dec-2001 Andre Poenitz wrote:
>
> > Does anything needs this kind of focus that is _not_ in immediate
> > neighbourhood of the cursor?
> >
> > If so, why isn't the cursor used for such things?
>
> Because you could have the cursor before/after th
On Tue, Dec 04, 2001 at 12:53:11PM +1000, Allan Rae wrote:
> This convoluted logic seems a bit silly -- John and I have read
> setUpdateStatus() as setUpdateRequirement() and given the context it
> would seem more sensible to actually say how much of update we require
> rather than how much has b
On Mon, 3 Dec 2001, Juergen Vigna wrote:
> On 03-Dec-2001 John Levon wrote:
> > yup, if you can explain :
> >
> > 843 if (!the_locking_inset) {
> > 844 bool found = lt->updateInset(bv, inset);
> > 845 if (clear)
> > 846
On Mon, Dec 03, 2001 at 04:45:44PM +0100, Andre Poenitz wrote:
> > Yes, that's ugly, but not really complex ...
>
> Nested 'if' and '->' coming in bunches of three or four are complex enough
> for me...
that's the locking stuff which as Juergen said has nothing to do with owner()
john
--
"Fa
On Mon, Dec 03, 2001 at 04:39:49PM +0100, Juergen Vigna wrote:
> > hmm, yes. and that contradicts what Juergen just said.
>
> Me?
er, I got confused ...
john
--
"Faced with the prospect of rereading this book, I would rather have
my brains ripped out by a plastic fork."
- Charles C
On Mon, Dec 03, 2001 at 03:11:42PM +, John Levon wrote:
> > No, that would require the cursor being a representation of the _path_ from
> > the tree root to the current position. Sort of a stack: push inset when
> > entering an inset, pop when leaving one. The "actual position" is the top
> >
On 03-Dec-2001 John Levon wrote:
> frontends/Controllers/ControlGraphics.C
I've seen that therefore I didn't send the mail immediately but had a better
look and then decided that the fix is actually quite easy ;)
> ok, so I was on the right track, but missed some stuff.
Well yes let's say so
On 03-Dec-2001 John Levon wrote:
> Tree, single path down the tree, they are both no cleaner than the current
> system IMHO
I agree!
But "maybe" we don't really need the owner_ in inset. We can experiment
with this in the next development cycle.
> hmm, yes. and that contradicts what Juergen j
On Mon, Dec 03, 2001 at 04:04:38PM +0100, Juergen Vigna wrote:
> > inset->updateInset(some_other_inset)
> > AND
> > inset->updateInsetInInset(some_other_inset)
> > but that's just an implementation detail I think. I would prefer just to
> > hand off updateInset(some) to the locking inset and have
On Mon, Dec 03, 2001 at 04:02:35PM +0100, Andre Poenitz wrote:
> > that would require each cursor to know not only its container, but the tree
> > of containers...
>
> No, that would require the cursor being a representation of the _path_ from
> the tree root to the current position. Sort of a s
On 03-Dec-2001 John Levon wrote:
> yes, for example insetgraphics that have finished rendering (which is what
> the bug fixes ;)
Well let's say what the bug fixes in some really special case: the requested
graphics inset is exacly INSIDE bv->theLockingInset() (not inside an inset
of bv->theLock
On Mon, Dec 03, 2001 at 02:47:28PM +, John Levon wrote:
> On Mon, Dec 03, 2001 at 03:38:18PM +0100, Andre Poenitz wrote:
> > Does anything needs this kind of focus that is _not_ in immediate
> > neighbourhood of the cursor?
>
> yes, for example insetgraphics that have finished rendering (whic
On Mon, Dec 03, 2001 at 03:52:43PM +0100, Juergen Vigna wrote:
> > So if I look at all the insets as some kind of tree, the "interesting
> > spot" is someway down a path from the root to a leaaf, and
> > bv->theLockingInset() is some kind of short cut on that path?
>
> No bv->theLockingInset() i
On Mon, Dec 03, 2001 at 03:45:42PM +0100, Juergen Vigna wrote:
> Hmmm, ..., ok, ..., I see. What I don't find is the call of InsetGraphics to
> BufferView::Pimpl::updateInset()! Where is it called? That's the only way that
> could produce a call to updateInsetInInset. Could you point me to this,
On 03-Dec-2001 Andre Poenitz wrote:
> Does anything needs this kind of focus that is _not_ in immediate
> neighbourhood of the cursor?
>
> If so, why isn't the cursor used for such things?
Because you could have the cursor before/after the inset but not be
"inside" the inset! This is mainly ne
On 03-Dec-2001 John Levon wrote:
> But what insettext is saying is wrong - it DOES know how to update inset because
> the insetgraphics is a member of that insettext. Just because it hasn't locked inside
> the insettext (i.e. is not InsetText::the_locking_inset) doesn't mean it doesn't need
> up
On Mon, Dec 03, 2001 at 03:38:18PM +0100, Andre Poenitz wrote:
> > An inset that is locked demands that many operations should be requested
> > of it first. For example, updates on insets.
>
> Does anything needs this kind of focus that is _not_ in immediate
> neighbourhood of the cursor?
yes,
On Mon, Dec 03, 2001 at 03:41:41PM +0100, Juergen Vigna wrote:
> > The stuff is confusing ...
>
> Why? You explained it quite good!
that's because I spent way too much time trying to understand it :)
john
--
"Faced with the prospect of rereading this book, I would rather have
my brains rip
On 03-Dec-2001 John Levon wrote:
> The stuff is confusing ...
Why? You explained it quite good!
Jug
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-
On Mon, Dec 03, 2001 at 02:14:40PM +, John Levon wrote:
> > Can anybody please explain me the concept of "inset locking"?
>
> I think of it as focus.
Ok.
> An inset that is locked demands that many operations should be requested
> of it first. For example, updates on insets.
Does anything
On Mon, Dec 03, 2001 at 03:07:27PM +0100, Andre Poenitz wrote:
> Can anybody please explain me the concept of "inset locking"?
I think of it as focus.
An inset that is locked demands that many operations should be requested
of it first. For example, updates on insets.
The top-level is bv->theL
On Mon, Dec 03, 2001 at 01:52:54PM +, John Levon wrote:
> But what insettext is saying is wrong - it DOES know how to update inset
> because the insetgraphics is a member of that insettext. Just because it
> hasn't locked inside the insettext (i.e. is not
> InsetText::the_locking_inset) doesn'
On Mon, Dec 03, 2001 at 11:29:31AM +0100, Juergen Vigna wrote:
>
> On 01-Dec-2001 John Levon wrote:
> >
> > I think this patch is correct and the old code was wrong. An explanation
> > is in the ChangeLog.
> >
> > After Juergen/Lars/someone checks it, please apply !
>
> I feel that this is no
On 01-Dec-2001 John Levon wrote:
>
> I think this patch is correct and the old code was wrong. An explanation
> is in the ChangeLog.
>
> After Juergen/Lars/someone checks it, please apply !
I feel that this is not the right fix. You may be right that we have to fix
something there but your's j
I think this patch is correct and the old code was wrong. An explanation
is in the ChangeLog.
After Juergen/Lars/someone checks it, please apply !
Not sure about the InsetTabular code - that looks weird too, and might account
for this :
http://sourceforge.net/tracker/index.php?func=detail&aid=
46 matches
Mail list logo
