DatePicker UI #1039#1042
Conversation
Test Results 1 626 files ±0 1 626 suites ±0 1h 38m 25s ⏱️ + 14m 44s For more details on these failures and errors, see this check. Results for commit d02fc83. ± Comparison against base commit c3a9151. ♻️ This comment has been updated with latest results. |
| * | ||
| * @since 4.11 | ||
| */ | ||
| public class FontUtils { |
There was a problem hiding this comment.
Although added methods looks useful, I would avoid introducing new API during this change just to not mix two different discussions.
There was a problem hiding this comment.
Deleting it and then re-creating it doesn't sound very appealing.
Any other options?
There was a problem hiding this comment.
@ruspl-afed what would you like me to do?
There was a problem hiding this comment.
Sorry, I missed your reply here. However, I do not understand it.
My point was to not introduce new API here, and focus on the UI itself.
And this doesn't mean deletion and re-creation, it means moving new type to an internal package for further API-related discussion.
There was a problem hiding this comment.
I think it should be ok now
There was a problem hiding this comment.
Now we have two FontUtils types. I suppose we need inly one, located at internal.commons.ui
There was a problem hiding this comment.
Sigh, the refactor move only committed the new location, leaving the original location (and references) in place.
I've been seeing this recently, I do a commit only to have some of the changed files suddenly appear as unstaged afterwards.
Both in Windows and Ubuntu
There was a problem hiding this comment.
The only thing to do here is to squash to single commit
gnl42
force-pushed
the
1039-DatePicker-UI
branch
2 times, most recently
from
38ca3b8 to
8c605f5
Compare
|
Wondering if we should treat fixture discovery failure as a "disabled/skipped" test? |
ruspl-afed
force-pushed
the
1039-DatePicker-UI
branch
from
9c3c465 to
d02fc83
Compare
2 participants
Got tired of seeing the DatePicker (and friends) truncated in Windows:
Linux/MacOs was better but also had some issues:
With these changes it looks like:
and
and
The DatePicker popup was cleaned up a bit as well from:
For some reason that I don't understand, the Mylyn-Runtime.launch version differs slightly in appearance from when Mylyn is installed in an Eclipse instance.