Re: Making a smaller ComboBox
So, I guess no one knows how to remove the gap between the text and the button
in ComboBox?
That probably means it’s a bug since padding can be removed from all sides
except for between the text and the button.
Cheers,
Mikael Grev
On 23 Jul 2014, at 16:11, Mikael Grev g...@miginfocom.com wrote:
Hello all!
(FYI this question has also been asked here without any correct answers:
http://stackoverflow.com/questions/24852429/making-a-smaller-javafx-combobox )
I'm trying to make a smaller version of the ComboBox but the gap between the
text and the arrow button is constant no matter what I do.
If I use the css:
.combo-box-base *.arrow-button {
-fx-padding: 0 0 0 0;
-fx-background-color: pink, pink, pink, pink;
}
the arrow button gets smaller but the ComboBox itself still have the same
size, only increasing the gap between the arrow and text to compensate.
If I do
.combo-box .list-cell {
-fx-padding: 0 0 0 0;
-fx-border-insets: 0 0 0 0;
}
The combo get a smaller height but the width remain fixed.
Is there any way to make the preferred size of the combo smaller by reducing
the size between the text and arrow?
I have a screenshot of the ComboBox attached.
Cheers,
Mikael Grev
Re: [API REVIEW REQUEST] RT-19659 - [TabPane] Support for draggable tabs
That is decidedly awesome! Is there some other way of deciding whether to to do one or the other? I mean one might want to reorder but not drag to another pane. Cheers, Mikael On 30 Jul 2014, at 10:09, Tom Schindl tom.schi...@bestsolution.at wrote: No - it allows also to drag the tab to another TabPane as well and in future outside the window to detach it. Tom On 30.07.14 10:07, Eric Le Ponner wrote: Hi Tom, I wonder if we should really use the wording « dnd ». The feature is really to enable the user to re-order the tabs inside a TabPane, right ? So may be: public boolean isTabReorderingEnabled(); public void setTabReorderingEnabled(boolean tabReorderingEnabled); public BooleanProperty tabReorderingEnabledProperty(); Eric PS: I’m assuming you don’t expect this gesture to work between two different TabPanes. Le 30 juil. 2014 à 09:35, Tom Schindl tom.schi...@bestsolution.at a écrit : Hi, I'd like you to review the API proposed to make TabPane Tabs draggable. The proposed public API only allows to put the TabPane in DnD mode: public boolean isDndEnabled() public void setDndEnabled(boolean dndEnabled) public BooleanProperty dndEnabledProperty() Tom
Re: [API REVIEW REQUEST] RT-19659 - [TabPane] Support for draggable tabs
Wouldn’t you still need to specify the “kind” of drag you are moderating? With just a boolean on/off now, a later API where one needs to say what kinds of drags (reorder, between tabpanes and drag out) would be hard to create. One don’t want an API with a master switch AND one for each kind of drag IMO. Cheers, Mikael On 30 Jul 2014, at 10:47, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, The proposed API only allows to turn on/off dragging all together. For your usecase I'd envision a future API which would allow one to control the aspects you are asking for like. The API i currently have in mind is but I have not yet explored: // Would allow to cancel dragging of certain tabs tabDndDragStartCallback: BiFunctionTabPane,Tab,Boolean // Would allow to cancel the dragging of the tab outside the container // == only allows reordering tabDndDragExitedCallback: BiFunctionTabPane,Tab,Boolean // Would allow the SOURCE to cancel the dragging to a specific target // (could make tabDndDragExitedCallback obsolete) tabDndDragOverTargetCallback: BiFunctionTabPane, Tab, Boolean // Would allow to cancel the drag over in the TARGET tabDndDragOverCallback: BiFunctionTabPane,Tab,Boolean // Would allow to cancel the dropping of a tab in a container tabDndDropCallback: BiFunctionTabPane,Tab,Boolean Tom On 30.07.14 10:27, Mikael Grev wrote: That is decidedly awesome! Is there some other way of deciding whether to to do one or the other? I mean one might want to reorder but not drag to another pane. Cheers, Mikael On 30 Jul 2014, at 10:09, Tom Schindl tom.schi...@bestsolution.at wrote: No - it allows also to drag the tab to another TabPane as well and in future outside the window to detach it. Tom On 30.07.14 10:07, Eric Le Ponner wrote: Hi Tom, I wonder if we should really use the wording « dnd ». The feature is really to enable the user to re-order the tabs inside a TabPane, right ? So may be: public boolean isTabReorderingEnabled(); public void setTabReorderingEnabled(boolean tabReorderingEnabled); public BooleanProperty tabReorderingEnabledProperty(); Eric PS: I’m assuming you don’t expect this gesture to work between two different TabPanes. Le 30 juil. 2014 à 09:35, Tom Schindl tom.schi...@bestsolution.at a écrit : Hi, I'd like you to review the API proposed to make TabPane Tabs draggable. The proposed public API only allows to put the TabPane in DnD mode: public boolean isDndEnabled() public void setDndEnabled(boolean dndEnabled) public BooleanProperty dndEnabledProperty() Tom
Re: Skin layoutChildren: when to get bounds of child nodes?
Richard,
Is there a sequence diagram (or similar) where the layout process is described
in detail?
It’s hard to in text get a clear and precise view on how the layout process in
the Node hierarchy is happening.
The sequence diagram would be good to have as a constraint for building layout
panes. Otherwise its easy to time things incorrectly with strange layout
artefacts as a result.
It’s especially important for devs to know which methods are called for the
pre-layout (size measuring) phase and them for the actual layout phase.
Cheers,
Mikael
On 28 Jul 2014, at 07:38, Martin Sladecek martin.slade...@oracle.com wrote:
The super.layoutChildren should size every child of the control (which is
VBox), but not child's children. The control must finish the layout before
children can do theirs. If you need to do layout on some child before that,
you can call .layout() on it. It will do it's layout using it's current size.
You should have all the bounds correct after that call.
But that would not work in your case anyway. You have both childs in a HBox,
which takes care of resizing the children. This means you need to layout the
HBox to get children size and in order to do that, you need HBox to be at
it's final size, which will happen during the VBox layout. So your steps
would be:
1) super.layoutChildren() - VBox is resized to Controls content size
2) now the VBox is resized, you can call vbox.layout()
3) now HBox is resized, so call hbox.layout()
4) children are resized. They have correct layout bounds now. But in order to
get correct boundsInParent (but maybe you really need layout bounds?), you
need to call .layout() on children too.
Even if you do all these steps, calling setPrefWidth() on child2 marks the
whole tree dirty again. Because HBox needs to resize child2 using it's new
PrefWidth. This also means, HBox prefwidth will be different, so it's parent
(VBox) must do the same. Ditto with the control. Also, the HBox (VBox,
control) may not have enough size to resize child2 to it's pref width, so
child1 might be shrinked as a result, which breaks your invariant. You are
basically changing the input for HBox's layout (child2.pref size) based on
it's output (child1 size), which makes this a loop.
So in order to really make this work, you need to manage the child nodes
directly and compute your layout by yourself. This can be done either by
using your own subclass of Pane and overriding it's layoutChildren. Or if you
want to do everything in Skin's layoutChildren, you can make the children
unmanaged, but then it doesn't really matter where they are in the
scenegraph, HBox won't be managing them.
Hope this helps!
-Martin
On 25.7.2014 18:56, Richard Bair wrote:
Hmmm. The first question I have is whether boundsInParent is really what you
want to use, vs. layout bounds. But assuming it is what you want, why are
the bounds zero? This is during the layout pass, which is the right place to
be doing what you’re doing. The super layoutChildren call will size
everything based on the contentX, contentY, contentWidth, contentHeight
(http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/4b8d06211312/modules/controls/src/main/java/javafx/scene/control/SkinBase.java).
Is it possible that the parent itself is size 0? boundsInParent should
always be invalidated automatically whenever the width/height/transforms/etc
changes. If not that is definitely a bug (that you can write a simple test
case for to prove).
But my first guess is maybe the parent is size 0 as well, due to something
else (maybe the pref size of the control is 0 to start with or something…)
Richard
On Jul 24, 2014, at 3:34 AM, Werner Lehmann lehm...@media-interactive.de
wrote:
Hi,
inside a control skin I have the following code pattern:
protected void layoutChildren(...)
{
super.layoutChildren(...);
Node child1 = ...
Bounds bip = child1.getBoundsInParent();
if (!animating) {
Node child2 = ...
child2.setTranslateX(bip.getMinX();
child2.setPrefWidth(bip.getWidth());
}
}
The skin scene graph looks roughly like this:
VBox
HBox { ..., child1, ...}
child2
...
Everything is layouted just fine but I want to adjust child2.translateX and
prefWidth based child1 bounds. This does not work initially because
boundsInParent returns zero components leading to incorrect initial display
of the control.
Seems as if boundsInParent is not yet updated. I guess I could use a
binding for that but it would conflict with an animation I also have on
translateX and prefWidth.
Maybe there is a better time to make those adjustments on child2?
Rgds
Werner
