On 25-3-2015 00:23, Tomas Mikula wrote:
I'm sure you could make it work this way, but 1) it is a lot of work
and 2) it is very fragile. It will break when ListView internals
change or when the ListView is loaded with a different skin on
restart. So it's a matter of how badly John wants this
On 22-3-2015 13:53, John Hendrikx wrote:
On 22/03/2015 09:59, Tom Eugelink wrote:
On 22-3-2015 00:12, John Hendrikx wrote:
What I do need however is a way to restore the control to the exact same state
it was in before (the same amount of pixels scrolled, the same item at the top,
the same
On Tue, Mar 24, 2015 at 6:47 PM, Tom Eugelink t...@tbee.org wrote:
On 22-3-2015 13:53, John Hendrikx wrote:
On 22/03/2015 09:59, Tom Eugelink wrote:
On 22-3-2015 00:12, John Hendrikx wrote:
What I do need however is a way to restore the control to the exact same
state it was in before
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
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
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,
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
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
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.
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
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
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
On 22/03/2015 09:59, Tom Eugelink wrote:
On 22-3-2015 00:12, John Hendrikx wrote:
What I do need however is a way to restore the control to the exact
same state it was in before (the same amount of pixels scrolled, the
same item at the top, the same item at the bottom).
That is an
Hi John,
if your app has something like pages this could work. You could use a
StackPane and put the first page (for example a list view) into it. When a
state change occurs (for example a list item is clicked and we move over to
a detail view) we could put this second page over the first page in
On 22-3-2015 00:12, John Hendrikx wrote:
What I do need however is a way to restore the control to the exact same state
it was in before (the same amount of pixels scrolled, the same item at the top,
the same item at the bottom).
That is an interesting use case. Can you describe it a bit
On 22-3-2015 13:53, John Hendrikx wrote:
On 22/03/2015 09:59, Tom Eugelink wrote:
On 22-3-2015 00:12, John Hendrikx wrote:
What I do need however is a way to restore the control to the exact same state
it was in before (the same amount of pixels scrolled, the same item at the top,
the same
On 22/03/2015 16:18, Tom Eugelink wrote:
On 22-3-2015 13:53, John Hendrikx wrote:
On 22/03/2015 09:59, Tom Eugelink wrote:
On 22-3-2015 00:12, John Hendrikx wrote:
What I do need however is a way to restore the control to the exact
same state it was in before (the same amount of pixels
On 14/03/2015 08:31, Tom Eugelink wrote:
Hi Tomas,
I have looked into it, but not yet attempted, but I did do a lot of
custom controls. And I agree that it is dubious that a control is a
node, and has the properties that come with it. I try to maintain a
strict separation in my controls in
On 21-3-2015 17:01, John Hendrikx wrote:
On 14/03/2015 08:31, Tom Eugelink wrote:
Hi Tomas,
I have looked into it, but not yet attempted, but I did do a lot of custom
controls. And I agree that it is dubious that a control is a node, and has the
properties that come with it. I try to
So Skins prevent us from getting visual details of the Control (such
as scroll position, position of item on screen, ...), because it is
Skin-specific, but at the same time they fail to customize the look
feel, because visual presentation leaks into the Control anyway.
On Sat, Mar 21, 2015 at
I don't understanding how you see that.
On 21-3-2015 18:47, Tomas Mikula wrote:
So Skins prevent us from getting visual details of the Control (such
as scroll position, position of item on screen, ...), because it is
Skin-specific, but at the same time they fail to customize the look
feel,
On Sat, Mar 21, 2015 at 2:10 PM, Tom Eugelink t...@tbee.org wrote:
I don't understanding how you see that.
On 21-3-2015 18:47, Tomas Mikula wrote:
So Skins prevent us from getting visual details of the Control (such
as scroll position, position of item on screen, ...), because it is
A page based view can perfectly be a list view; I would have no problem having
a paging skin or a scrollbar skin for ListView.
On 21-3-2015 19:46, Scott Palmer wrote:
But that's not right. A *List* is 'a container for an unbounded list of
items. A ListView is a specific type of control
But that's not right. A *List* is 'a container for an unbounded list of
items. A ListView is a specific type of control that gives you a view to that
list *in a specific way*. It has properties in addition to the list itself.
It *should* have a scroll position because that is a property of
My point is that there are many ways to display the same data set, but they
shouldn't all be crammed into a single control type. Particularly one that
changes radically based on the skin just because the data model can be
represented by the same data structure. For a ListView it could still
For me, I'd like to simply change the Look and Feel and have the same
data presented differently (perhaps related to space restrictions,
orientation, user preferences). Currently, this can be achieved by
changing the Control, or maybe only change the Skin, depending on how
radical the
Hi Tomas,
I have looked into it, but not yet attempted, but I did do a lot of custom
controls. And I agree that it is dubious that a control is a node, and has the
properties that come with it. I try to maintain a strict separation in my
controls in JFXtras; controls only have functional
I could say how I _feel_ differently about some things, but it's not
important how I feel. What is important is that it comes down to
practical problems. The layout details often leak and are not details
anymore. Sometimes you would like to know if an item of a ListView is
currently displayed. Or
A quick poll:
Has anyone ever implemented a custom skin for some of the more complex
controls like ListView, TableView, TreeView, TextArea?
The problem I have with the Control/Skin architecture is that a
Control, being a Node in the scene graph, cannot be a pure model (in
the MVC sense) - it is
29 matches
Mail list logo
