8u-dev repo unlocked; one more week for automatic 8u -- 9 syncing

2015-03-23 Thread Kevin Rushforth
The 8u-dev repo is now unlocked after today's sanity testing. As a reminder the automatic syncing of changesets from 8u-dev -- 9-dev will continue for one more week. Any changeset pushed to 8u-dev before 1am next Monday, Mar 30, will make its way to 9-dev without your needing to do anything.

Re: The trouble with Skins

2015-03-23 Thread Tomas Mikula
Thank you, Richard, for your response. On Mon, Mar 23, 2015 at 2:07 PM, Richard Bair richard.b...@oracle.com wrote: tl;dr; I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to

Re: The trouble with Skins

2015-03-23 Thread Tom Eugelink
On 23-3-2015 20:30, Tomas Mikula wrote: Control does not know what API is available on the Skin I have many controls that require a skin that implements a certain interface (refresh() is often present). Granted, this is not something that is compiler checkable via the setSkin method, but it

Re: The trouble with Skins

2015-03-23 Thread Tom Eugelink
Suppose control would support have generics type, to make the requirement on the Skin formal. ControlT extends Skin ControlAgendaSkin Then getSkin would expose information for every skin the control has, without polluting the control's API. Would that work for you? Tom On 23-3-2015 22:03,

Re: The trouble with Skins

2015-03-23 Thread Tomas Mikula
Sure, it is a workaround that works, but I don't think type cast should be the recommended way to do this (or to do anything). Tomas On Mon, Mar 23, 2015 at 4:15 PM, Tom Eugelink t...@tbee.org wrote: On 23-3-2015 20:30, Tomas Mikula wrote: Control does not know what API is available on the

Re: The trouble with Skins

2015-03-23 Thread Tomas Mikula
Yes, I think that would be much better than the current situation. On Mon, Mar 23, 2015 at 5:08 PM, Tom Eugelink t...@tbee.org wrote: Suppose control would support have generics type, to make the requirement on the Skin formal. ControlT extends Skin ControlAgendaSkin Then getSkin would

Re: The trouble with Skins

2015-03-23 Thread Richard Bair
tl;dr; I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view details.

Re: The trouble with Skins

2015-03-23 Thread Richard Bair
Sounds like this may be a case of where view details become essential to the operation of the control, then define the Control to always include those specific view details.” On Mar 23, 2015, at 11:45 AM, Robert Krüger krue...@lesspain.de wrote: On Mon, Mar 23, 2015 at 7:07 PM, Richard

Re: The trouble with Skins

2015-03-23 Thread Robert Krüger
On Mon, Mar 23, 2015 at 7:07 PM, Richard Bair richard.b...@oracle.com wrote: tl;dr; I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view

Re: The trouble with Skins

2015-03-23 Thread Tom Eugelink
On 23-3-2015 19:07, Richard Bair wrote: In the end, I lean toward keeping the Control API as view-agnostic as possible, but where view details become essential to the operation of the control, then define the Control to always include those specific view details. Thanks for sharing the