Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [nebula-dev] [CompositeTable] fast scrolling behaves oddly

Hi Tom,

yes, that's what I did (checked out the latest cvs, inserted my changes,
created a patch..
I just checked out the latest cvs, applied my patch and did not have any
troubles. Did you apply the 2nd patch
(not the first one in the list. I included this to show only what changes
I inserted. The current changes rely another patch I did in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=173558 and I therefore put a
second patch, that includes both changes (patch to bug 173558 & the
current bug)

Greetings
André

> Hi Andre,
>
> I'm having problems applying your patch against the latest checkout from
> nebula. I get merging conflicts all over the InternalCompositeTable.
> Does the patch apply for you cleanly on a checkout from cvs?
>
> Tom
>
> André Dietisheim schrieb:
>> Hi tom
>>
>> I just checked my patch and a demo-snippet into bugzilla:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=176466
>>
>> I couldn't add you to cc's as your list-email was not accepted. Thanks
>> for the testing!!!
>>
>> Regards
>> André
>>
>>
>>> yeah. since yesterday ;-) Should I check out from CVS and do what
>>> afterwards?
>>>
>>> Tom
>>>
>>> David J. Orme schrieb:
>>>> This sounds correct.  Wow, you really have deeply understood how
>>>> CompositeTable works.  Please file a bug and I'll test on Win32.  Is
>>>> there anyone out there with a Mac?
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Dave Orme
>>>>
>>>> -------
>>>> thanks a lot for the positive feedback! Always nice to hear :-)
>>>>
>>>> I have a more pickier problem I just managed to solve for GTK+ (I'll
>>>> test things on Win32 asap) and I would appreciate a lot your ideas
>>>> on this issue & my possible fix as this one gets deeper into
>>>> compositeTable and SWT. But take your time! I really do not want to
>>>> put more stress on you than you certainly already have :-(
>>>>
>>>> The issue can be experienced when you scroll the table by
>>>> mouse-wheel very fast and you scroll the current row outside the
>>>> viewport. It gets more frequent the more widgets are visible (the
>>>> more complex a row is). The issue is that an arbitrary scrolled-in
>>>> row (after the current row was scrolled out) gets focused and gets
>>>> 'current row' - I clearly tracked it down to focusGained() in
>>>> InternalComposite. I believe that the newly focused row is actually
>>>> the one that got scrolled out and was repositioned to the top (and
>>>> refreshed with new model-content). I believe that this is due to
>>>> deferredSetFocus() that gets delayed a lot and gets executed only
>>>> when the row was repositioned and scrolled in (on the top) again.
>>>> My possible fix (tested for GTK) is to keep track of the control to
>>>> focus delayedly (asyncExec) by setting the instance variable
>>>> this.toFocus. Furthermore to clear that instance variable on row
>>>> departure & fire a focusOut-event on the other hand. I try to
>>>> prevent any deferredSetFocus() that would focus any control that was
>>>> departed and is visible again, when asyncExec finally gets executed.
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> nebula-dev mailing list
>>>> nebula-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/nebula-dev
>>> _______________________________________________
>>> nebula-dev mailing list
>>> nebula-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/nebula-dev
>>>
>>>
>>>
>>
>>
>
>
>
>
> !DSPAM:45ed45f385491811889055!


-- 
André Dietisheim
Stv-Bereichsleiter Products

Puzzle ITC GmbH
Eigerplatz 4
CH-3007 Bern
Telefon +41 31 370 22 00
Mobile  +41 76 423 03 02
Fax     +41 31 370 22 01

Puzzle ist Mitglied der ODF Alliance:
<http://www.puzzle.ch/odfalliance/>




Back to the top