WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
94560
[EFL] Support slider tick mark snapping
https://bugs.webkit.org/show_bug.cgi?id=94560
Summary
[EFL] Support slider tick mark snapping
KwangYong Choi
Reported
2012-08-20 19:13:33 PDT
Support slider tick mark snapping by implementing RenderThemeEfl::sliderTickSnappingThreshold().
Attachments
Patch
(3.70 KB, patch)
2012-08-20 19:28 PDT
,
KwangYong Choi
no flags
Details
Formatted Diff
Diff
Patch
(3.74 KB, patch)
2012-08-21 19:04 PDT
,
KwangYong Choi
no flags
Details
Formatted Diff
Diff
Patch
(3.74 KB, patch)
2012-08-21 22:08 PDT
,
KwangYong Choi
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
KwangYong Choi
Comment 1
2012-08-20 19:28:43 PDT
Created
attachment 159591
[details]
Patch I set threshold value 5. It's natural, I think. Chromium port uses 5 also.
Raphael Kubo da Costa (:rakuco)
Comment 2
2012-08-21 07:39:39 PDT
Comment on
attachment 159591
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=159591&action=review
> Source/WebCore/platform/efl/RenderThemeEfl.cpp:817 > + static const int threshold = 5; > + > + return threshold;
Why not `return 5', perhaps with a comment explaining where the number came from?
KwangYong Choi
Comment 3
2012-08-21 17:43:07 PDT
(In reply to
comment #2
)
> (From update of
attachment 159591
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=159591&action=review
> > > Source/WebCore/platform/efl/RenderThemeEfl.cpp:817 > > + static const int threshold = 5; > > + > > + return threshold; > > Why not `return 5', perhaps with a comment explaining where the number came from?
I refer to already merged code above this method. int RenderThemeEfl::sliderTickOffsetFromTrackCenter() const { static const int sliderTickOffset = -12; return sliderTickOffset; } What shall I do? change it to 'return 5;' with a comment?
Raphael Kubo da Costa (:rakuco)
Comment 4
2012-08-21 18:29:12 PDT
Comment on
attachment 159591
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=159591&action=review
>>> Source/WebCore/platform/efl/RenderThemeEfl.cpp:817 >>> + return threshold; >> >> Why not `return 5', perhaps with a comment explaining where the number came from? > > I refer to already merged code above this method. > > int RenderThemeEfl::sliderTickOffsetFromTrackCenter() const > { > static const int sliderTickOffset = -12; > > return sliderTickOffset; > } > > What shall I do? change it to 'return 5;' with a comment?
Yes, that looks clearer.
KwangYong Choi
Comment 5
2012-08-21 18:32:26 PDT
(In reply to
comment #4
)
> (From update of
attachment 159591
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=159591&action=review
> > >>> Source/WebCore/platform/efl/RenderThemeEfl.cpp:817 > >>> + return threshold; > >> > >> Why not `return 5', perhaps with a comment explaining where the number came from? > > > > I refer to already merged code above this method. > > > > int RenderThemeEfl::sliderTickOffsetFromTrackCenter() const > > { > > static const int sliderTickOffset = -12; > > > > return sliderTickOffset; > > } > > > > What shall I do? change it to 'return 5;' with a comment? > > Yes, that looks clearer.
OK. I will.
KwangYong Choi
Comment 6
2012-08-21 19:04:47 PDT
Created
attachment 159843
[details]
Patch
Gyuyoung Kim
Comment 7
2012-08-21 19:20:30 PDT
(In reply to
comment #3
) int RenderThemeEfl::sliderTickOffsetFromTrackCenter() const { static const int sliderTickOffset = -12; return sliderTickOffset; } In my opinion, above style is also good. But, *return 5* is being used by chromium port. So, if there is no objection, looks good to me.
Raphael Kubo da Costa (:rakuco)
Comment 8
2012-08-21 19:34:21 PDT
Comment on
attachment 159843
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=159843&action=review
> Source/WebCore/platform/efl/RenderThemeEfl.cpp:815 > + // It's natural to use 5 px for threshold.
Erm, that doesn't sound very convincing. You can say you are using the same threshold value as the Chromium port, or explain why 5px makes more sense than any other value.
KwangYong Choi
Comment 9
2012-08-21 22:08:12 PDT
Created
attachment 159857
[details]
Patch Modified comment.
Raphael Kubo da Costa (:rakuco)
Comment 10
2012-08-21 22:20:44 PDT
Comment on
attachment 159857
[details]
Patch Looks OK to me now.
Kenneth Rohde Christiansen
Comment 11
2012-08-22 05:14:16 PDT
Comment on
attachment 159857
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=159857&action=review
> LayoutTests/platform/efl/fast/forms/datalist/range-snap-to-datalist-expected.txt:-8 > value for 42 is <500 > value for 43 is <500 > value for 44 is <500 > -value for 45 is <500
Why do we need a platform expected result? like do we still differ? Like how are the Android values for instnace?
> Source/WebCore/platform/efl/RenderThemeEfl.cpp:817 > +LayoutUnit RenderThemeEfl::sliderTickSnappingThreshold() const > +{ > + // The same threshold value as the Chromium port. > + return 5; > +}
So this sounds as we can share the result
KwangYong Choi
Comment 12
2012-08-22 05:41:51 PDT
Comment on
attachment 159857
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=159857&action=review
>> LayoutTests/platform/efl/fast/forms/datalist/range-snap-to-datalist-expected.txt:-8 >> -value for 45 is <500 > > Why do we need a platform expected result? like do we still differ? Like how are the Android values for instnace?
Actually, there is no common expected result for this test. And, only Chrome port has a platform expected result which is same as EFL for now.
WebKit Review Bot
Comment 13
2012-08-22 05:48:24 PDT
Comment on
attachment 159857
[details]
Patch Clearing flags on attachment: 159857 Committed
r126292
: <
http://trac.webkit.org/changeset/126292
>
WebKit Review Bot
Comment 14
2012-08-22 05:48:28 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug