Deck Editor GUI

[Rob Cashwalker]

In VB I've run into these sorts of layout problems. There are a number of fancy commercial layout controls that automatically stretch your GUI objects. But I've never really needed them. I just respond to the form/window resize event, and adjust the size and position of all the objects manually.

I don't know if there is an equivalent event in Java, but if there is, you can use that.
The card text and picture frames are always a set width, it's the grids that need to expand. So just dynamically calculate the left position of the card text and picture, then set the grid width to match.
Top-bottom wise, the top grid expands proportionately, the add/remove buttons drop to match, and the lower grid moves down and expands to meet to bottom of the window.

[Chris H.]

I think that GuiDisplay3.java is responsible for displaying the contents of the window where we play the game.

I have noticed in the past that when I grab the resize corner and expand and shrink the size of the window that the game card detail panel will remain the same width but the hight will resize. There appears to be a min and max value.

There may be some code here that could be added to the deck editor.

[Rob Cashwalker]

Yes, good observation. I remember someone posted that change a long while back, Tied to the resizable game area option.

[silly freak]

if I recall right, the original resizable display area was by me^^.

[in VB] There are a number of fancy commercial layout controls that automatically stretch your GUI objects. But I've never really needed them.

I think VB not being an OO language, layout managing might be a little tricky to configure. However, it's really easy in java, so I would really go that way

I just respond to the form/window resize event, and adjust the size and position of all the objects manually. I don't know if there is an equivalent event in Java, but if there is, you can use that.

Yes, there is, in the form of ComponentListener. However, as I said, layouting is not hard in Java, and manual layouting code lessens the flexibility:
-If you set the window's size manually, you specify the outer bounds. The content's size depends on the OS.
-If you do a flexible layout manually, you have to take care of all the child components yourself. besides that a button's needed size is also OS-dependent, adding/removing a child, or changing the layout, means rewriting the whole thing

[Rob Cashwalker]

if I recall right, the original resizable display area was by me^^.

I thought so... I just wasn't positive.

I think VB not being an OO language, layout managing might be a little tricky to configure. However, it's really easy in java, so I would really go that way

I don't think being OO enters into it. There are layout tools that make it really easy... but I just choose not to use them. It's just another ActiveX that needs to be installed with the app.
In VB each component has a left and top coordinate relative to the form, and a width and height property. So the number of coordinate calculations isn't too bad.
I don't know how the Java components are laid out, if they're left/top/width/height or left/top/right/bottom.

Yes, there is, in the form of ComponentListener. However, as I said, layouting is not hard in Java, and manual layouting code lessens the flexibility:
-If you set the window's size manually, you specify the outer bounds. The content's size depends on the OS.
-If you do a flexible layout manually, you have to take care of all the child components yourself. besides that a button's needed size is also OS-dependent, adding/removing a child, or changing the layout, means rewriting the whole thing

Coolness. I was just thinking that the deck editor window is so simple, it would just be a few lines of code to do it.

[silly freak]

ok, the deck editor is maybe not the most complicated thing. but still, there are nummerous child components, and each has to be resiized the right way. i have once written a handy app, where no layout management was available. only for really simple things, it was like 50 lines of code. and unlike in vb, layouting is java core and doesn't need additional libraries

okay, want to stop with my personal opinions here

[Chris H.]

I would like to say thank you to Silly Freak, Dennis and Rob for the advice, encouragement and kind words. I downloaded the web browser based tutorials from Sun and the pdf tutorials from the Eclipse site. It will take me awhile to absorb these learning materials.

Silly Freak has some great ideas for the Deck Editor. I can not predict how long it will take me to train myself to the point where I will be able to do this on my own. I'm taking this all at one small step at a time.

As I go through the training materials, I may decide to submit a minor code change similar to my recent submissions. There are still several windows/panels with text that truncates with an ellipses.

This is a more noticeable problem for those of us who use the Apple Macintosh line of computers. The Apple fonts appear to have a slightly wider pen stroke and need a little more room to display.

I am still studying the card detail panel. I think I will need to lower the text size from 14 to 13 point. I am also considering splitting the name from the cost and displaying this on two rows rather than on one. I would handle the card type the same way:

.

[mtgrares]

It sounds like you are making really good progress Chris and thanks to Silly Freak for sending me code a long time ago.

All of the user interface stuff could be updated. It would be nice to have a simple search feature for the deck editor, which would search all of the text of a card including the name, card type, card text but that would have to involve changing TableModel which is a little bit of a mystery. (I programmed it a long time ago but even then I updated something too many times and that is why it used to take so long to sort the cards in the deck editor. I took out one or two lines and phoof it worked alot faster). TableModel just extends DefaultJTableModel (I think) so you might have to read some tutorials about the JTableModel in order to make heads or tails of the code.

[mtgrares]

This is a more noticeable problem for those of us who use the Apple Macintosh line of computers. The Apple fonts appear to have a slightly wider pen stroke and need a little more room to display.

I believe that Apple uses anti-aliasing for fonts and Windows does not (or vice versa, just don't shoot me ) I read this recently and hopefully this random fact may help you out a little.

[Rob Cashwalker]

I am still studying the card detail panel. I think I will need to lower the text size from 14 to 13 point. I am also considering splitting the name from the cost and displaying this on two rows rather than on one. I would handle the card type the same way:

.

I like the split-line form you show in the attached image.

When I wrote the card image creator, I had to make the same sort of sacrifices in layout.... Layout more like a real card or more readable at scale? I chose to make the mana cost more important, and let the name wrap at the mana cost's left position. I used a Windows API method to draw the text, which given an oversized rectangle, it will actually tell you what the final dimensions actually are after drawing the text. So I draw the mana first, and use it's calculated left position as the right boundary for the name.

[Chris H.]

This is a more noticeable problem for those of us who use the Apple Macintosh line of computers. The Apple fonts appear to have a slightly wider pen stroke and need a little more room to display.

I believe that Apple uses anti-aliasing for fonts and Windows does not (or vice versa, just don't shoot me ) I read this recently and hopefully this random fact may help you out a little.

I think that I may have stumbled across an answer.

The Deck Editor (and other sections of Forge) is using a Logical font rather than a Physical font.

Physical and Logical Fonts

The Java Platform distinguishes between two kinds of fonts: physical fonts and logical fonts.
Physical fonts are the actual font libraries containing glyph data and tables to map from character sequences to glyph sequences, using a font technology such as TrueType or PostScript Type 1. All implementations of the Java Platform must support TrueType fonts; support for other font technologies is implementation dependent. Physical fonts may use names such as Helvetica, Palatino, HonMincho, or any number of other font names. Typically, each physical font supports only a limited set of writing systems, for example, only Latin characters or only Japanese and Basic Latin. The set of available physical fonts varies between configurations. Applications that require specific fonts can bundle them and instantiate them using the createFont method.

Logical fonts are the five font families defined by the Java platform which must be supported by any Java runtime environment: Serif, SansSerif, Monospaced, Dialog, and DialogInput. These logical fonts are not actual font libraries. Instead, the logical font names are mapped to physical fonts by the Java runtime environment. The mapping is implementation and usually locale dependent, so the look and the metrics provided by them vary. Typically, each logical font name maps to several physical fonts in order to cover a large range of characters.

Peered AWT components, such as Label and TextField, can only use logical fonts.

[Chris H.]

I felt that the labels displaying the total card count by category were in need of a minor change to make them more readable. This is just a minor change.

.