[gui-dev] layout patch

[Felix Berger]

Hi,

while looking around how things are done in Limewire I did polished the
ListEditor and the StandardListEditor.

The changes for the StandardListEditor are:

* use gridbag layout to make the (add, remove) buttons on the right have the
same horizontal size.
* Removed button row implementation for this purpose, made
ButtonRow.BUTTON_SEP public so the buttons still have the same distance from
each other
* Use Actions internally
* no interface changes

The changes for ListEditor are:

* use gridbag layout for nicer layout of the buttons, the insets can still be
tweaked
* disable remove button when nothing is selected
* enter key in editor field triggers add action
* delete key in list triggers remove action
* use actions internally
* no public interface changes

It's all in one patch.

Regards,
Felix

[Sam Berlin]

Hi Felix,

Thanks very much for sending this in. The change looks very nice. As
a small detail, when adding components using a constraint, you can use
the method:

myContainer.add(myComponent, myConstraint);

That removes the need to cast the layout back to a GridBagLayout and
removes the extra line of setConstraints. GridBagConstraints are also
cloned when they're added, so there's no need to create a new one prior
to each component-adding.

Other than that, this looks very good! It'll be added into CVS
sometime later today.

In the future, you may want to use the codepatch at limewire.org
mailing list for sending patches. No big difference, but it helps us
organize the messages a little better.

Thanks,
Sam

Post by Felix Berger
Hi,
while looking around how things are done in Limewire I did polished the
ListEditor and the StandardListEditor.
* use gridbag layout to make the (add, remove) buttons on the right have the
same horizontal size.
* Removed button row implementation for this purpose, made
ButtonRow.BUTTON_SEP public so the buttons still have the same
distance from
each other
* Use Actions internally
* no interface changes
* use gridbag layout for nicer layout of the buttons, the insets can still be
tweaked
* disable remove button when nothing is selected
* enter key in editor field triggers add action
* delete key in list triggers remove action
* use actions internally
* no public interface changes
It's all in one patch.
Regards,
Felix
--
Try Debian GNU/Linux!
http://www.felix.beldesign.de/
<layout.patch>_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev

[Felix Berger]

Post by Sam Berlin
myContainer.add(myComponent, myConstraint);

I only realized that after sending the patch :-)

Post by Sam Berlin
That removes the need to cast the layout back to a GridBagLayout and
removes the extra line of setConstraints. GridBagConstraints are also
cloned when they're added, so there's no need to create a new one prior
to each component-adding.

I think I did that in one or two places, but most of the time I wanted to make
sure I have a new instance in order to have the correct default values for
the unset fields.

Post by Sam Berlin
In the future, you may want to use the codepatch at limewire.org
mailing list for sending patches. No big difference, but it helps us
organize the messages a little better.

Sure. I also wanted to propose to move the private bindKey method I introduced
in ListEditor to GUIUtils and make it static there. I also would like to use
it for the StandardListEditor's remove action without introducing code
duplication. The signatures could be:

public static void bindKeyToAction(JComponent c, KeyStroke k, Action a, int
focusScope)
{
InputMap inputMap = c.getInputMap(focusScope);
ActionMap actionMap = c.getActionMap();
if (inputMap != null && actionMap != null) {
inputMap.put(key, a);
actionMap.put(a, a);
}
}

And a convenience wrapper:

public static void bindKeyToAction(JComponent c, KeyStroke k, Action a)
{
bindKeyToAction(c, k, a, JComponent.WHEN_FOCUSED);
}

I just noticed that I used the wrong constant in the patch I sent. I think
it's best to use the local binding WHEN_FOCUSED.

Question: Is it possible to use the LimeJTable without inheriting an
AbstractTableMediator? The padded main_panel that has to be used then makes
the table unnessecarily small so that it doesn't align with the other
components in the options panes.

Regards,
Felix