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

thanks a lot for the precise feedback! Good to hear the bug is gone on
OSX, too :-)

Regards
André

> Hi,
>
> Ok. I see you created a patch only for the single file and so the module
> path was not included in your patch and I had to selected the file
> itself to apply the patch.
>
> Everything working smoothly on MacOSX, the only very small issue I see
> is a white small white line in the Table row directly above the text
> which is coming from the text-elements border I guess and you can't do
> anything against it.
>
> Another small problem is that the row is only highlighted when you click
>  in an area with a control e.g. the text control doesn't fill the
> complete hight on MacOSX and when clicking in the area above the text
> widget the row is not colored. Maybe the mouse listener should also
> listen to clicks outside the control area.
>
> Nevertheless nice work.
>
> Tom
>
> André Dietisheim schrieb:
>> 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:45ed788022686491211187!


-- 
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