Bug - Fixed MaximizerFrame sized too small on linux

I

IronTetsubo

Member
By default for me (linux running openJDK 1.6), the maximizer frame is sized juuust small enough to drop off the "pullable/buyable" radio button and the "all consumables" radio button. :) I for a long time had been annoyed that the maximizer "didn't" support pulling items from your closet, and had meant to look into the code as it seems such and odd omission. Recently, I happened to be using kolmafia on windows, and went "wow! Someone added that feature, I must have missed the commit.". Then I went back to linux and was dumbfounded until I happened to resize the window. Blew my mind! So I'm hoping a tweak by someone who knows swing can fix to to properly size the window so that all the options are displayed, so other poor saps who have been missing out on the powers of the maximizer are also happily surprised by this "new" feature.

I spent a while poking at this trying to come up with a patch to help, but the swing stuff is waay beyond my java skillset. The "easy" fix is to change the size of the MaximizerPanel creation, but that seems like the wrong approach as there's got to be a way to tell java "make it big enough so everything actually shows up" without hardcoding a size. I'm of course happy to provide further details or test suggested builds. Changing the right Dimension to 450 (from 420) was sufficient size difference to fix it for me.
 
IronTetsubo said:
The "easy" fix is to change the size of the MaximizerPanel creation, but that seems like the wrong approach as there's got to be a way to tell java "make it big enough so everything actually shows up" without hardcoding a size.
Click to expand...

Hmm I know there's a pack() method in swing that pretty much does what you're describing. I could possibly fiddle with things and come up with a patch for you to test against, but it'd likely be no better than any educated fiddling you might make. On the other hand, this is probably something that would take a dev who is familiar with the class about 30 seconds to do.
 
I'll plead Swing incompetence as well. That said, I think it is safe to say that, in general and unless overridden by preferences, mafia will initially size any window so that its contents fit and can be displayed (or use a scroll bar). So while waiting for someone competent to show up, I might play with some of the look and feel options as well as whether the maximizer is a standalone window or a tab. These might be workarounds, or they might not.
 
Yeah, googling around about this got me the pack() method, but trying that out as a part of the MaximizerFrame initialization didn't seem to make a difference, I kept digging for a bit, but quickly got lost in a twisty maze of Java classes, all alike. :) If you do have any better luck with it, spectacular. It's less of a big deal now that I realized the problem and can resize the window as needed, but man it would have saved me some time had I known that feature existed.

I did not try the maximizer as a tab - this is as a standalone window. I'm assuming that as a tab it would show up fine (as the main kolmafia window is of course much larger on my screen, so I can't imagine it would cut anything off), but I'll try that out as well.
 
There are many reasons why Swing is so hard to understand. Layout Managers are a big reason - once you get them, you kind of get Swing. It's mostly downhill from there, at least.

Here's the issue, in more-or-less plain english. There's a window, which has a frame in it, which has a bunch of panels in it, each of which have a bunch of components in them. To wit, some of those components are themselves panels, which in turn have embedded components. This layering can make it difficult to understand which element is dictating the size of the thing that's not being sized properly.

In this case, after a minute of looking at the code, here's the deal:
-MaximizerFrame employs a BorderLayout. The north panel dictates its width dimension. MaximizerPanel is in its north panel.
-MaximizerPanel extends GenericPanel, which extends ActionVerifyPanel.
-ActionVerifyPanel uses a blend of BoxLayout and GridLayout to lay out its components.

This last point is important because the arguments to ActionVerifyPanel are needed to constrain its size - its layout manager does not know how to "take all available space". So without a rewrite of MaximizerPanel that avoids using GenericPanel, our options are limited to hardcoding the desired size.

The preceding message has been an essay on why I'm changing a 420 to a 450. r11375
 
You must log in or register to reply here.
Back
Top