On Tue, Nov 11, 2003 at 09:40:11AM +0100, Alfredo Braunstein wrote:
> But they *are* decoupled. The cursor is needed only on fitCUrsor (and we
> need it there). When you scroll with the scrollbar, there is no fitCursor
> involved (except from cursor_follows_crollbar, that is)
That's what I was ref
Andre Poenitz wrote:
> On Tue, Nov 11, 2003 at 08:52:59AM +0100, Alfredo Braunstein wrote:
>> Andre Poenitz wrote:
>>
>> > On Mon, Nov 10, 2003 at 11:51:31PM +0100, Alfredo Braunstein wrote:
>> >> One of the problems I see is that the insets lose track of their
>> >> position if we scroll away.
>
On Tue, Nov 11, 2003 at 09:35:53AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> What about absolute *document* coordinates everywhere? What are the
> >> drawbacks?
> >
> > Probably none as they are equivalent to screen coordinates + y_top.
> >
> > Or, more precisely: If there a
Andre Poenitz wrote:
>> What about absolute *document* coordinates everywhere? What are the
>> drawbacks?
>
> Probably none as they are equivalent to screen coordinates + y_top.
>
> Or, more precisely: If there are drawbacks we'd see them with screen
> coordinates as well.
Should we do just tha
On Tue, Nov 11, 2003 at 09:15:12AM +0100, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> >> Don't you think we should just move to absolute screen coordinates
> >> everywhere? This scheme looks robust and simple...
> >
> > But this is exactly the problem right now: if you scroll with
Alfredo Braunstein wrote:
>> Don't you think we should just move to absolute screen coordinates
>> everywhere? This scheme looks robust and simple...
>
> But this is exactly the problem right now: if you scroll with the
> scrollbar, the coordinates where the cursor is remain invalid, and so a
>
On Tue, Nov 11, 2003 at 08:52:59AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Mon, Nov 10, 2003 at 11:51:31PM +0100, Alfredo Braunstein wrote:
> >> One of the problems I see is that the insets lose track of their position
> >> if we scroll away.
> >>
> >> Maybe a solution wo
On Tue, Nov 11, 2003 at 08:55:28AM +0100, Alfredo Braunstein wrote:
> THere is a lot of other not removed dead code (all fuctions called
> fit.*ursor for instance, there are like 10 of them scattered around, in
> src/ src/insets/, src/frontends/), but there is some that seems to serve to
> some par
Andre Poenitz wrote:
> On Tue, Nov 11, 2003 at 12:24:37AM +0100, Alfredo Braunstein wrote:
>> But we need to rationalize the update calls anyway, and when we do that,
>> we can add an LCursor::update_cache method or something to update the
>> cache at the exact moment we want (I think after an upd
Andre Poenitz wrote:
> On Mon, Nov 10, 2003 at 11:51:31PM +0100, Alfredo Braunstein wrote:
>> One of the problems I see is that the insets lose track of their position
>> if we scroll away.
>>
>> Maybe a solution would be to cache the absolute y position of the tip
>> inset in LCursor as soon as
On Tue, Nov 11, 2003 at 12:24:37AM +0100, Alfredo Braunstein wrote:
> But we need to rationalize the update calls anyway, and when we do that, we
> can add an LCursor::update_cache method or something to update the cache at
> the exact moment we want (I think after an update, in workAreadispatch).
On Mon, Nov 10, 2003 at 11:51:31PM +0100, Alfredo Braunstein wrote:
> One of the problems I see is that the insets lose track of their position if
> we scroll away.
>
> Maybe a solution would be to cache the absolute y position of the tip inset
> in LCursor as soon as it is push()ed.
>
> If this
Alfredo Braunstein wrote:
> One of the problems I see is that the insets lose track of their position
> if we scroll away.
>
> Maybe a solution would be to cache the absolute y position of the tip
> inset in LCursor as soon as it is push()ed.
>
> If this seems reasonable I would try to do it tom
13 matches
Mail list logo
