Feature - Implemented "modernize" item manager tables

[roippi]

Mmkay. r11020 adds the new stuff and applies it to RestorativeItemPanel.

Go crazy with the nitpicky feedback. "This and this should be center-aligned" "I don't want to be able to reorder columns" "It should remember my column order between restarts" etc are all valid feedback. Optionally request new features/columns/whatever. No promises I'll actually do it, but hey. I'm trying to get this dialed in before I apply it to the rest of the item manager.

For fun, a known issues post:

- No item colorizations are applied
- Multiple row selection model is not the same as in the List-style interface. I know. This is swing implementing selection modes differently in JTables and JLists. I can probably override it.
- When highlighting a cell that is too small for the text it contains, the renderer will poorly display the contents.

 

[Rinn]

You probably don't need to have the autosell price formatted as (x meat), the parentheses are weird and it should be implied the number corresponds to meat. I'd want to see separate columns for mp and hp restore amount as well. It would also be nice to have a column that shows the last historic price that mafia stores.

Actually, if you can make columns optional like in windows explorer just throw as many columns in there as you can and only make the extremely important ones enabled by default.

 

[roippi]

I can ditch the parentheses. As for getting rid of "meat" as well.. I don't know, it can be visually difficult to differentiate between autosell and quantity if both columns are just numbers. Plus, years of looking at it in the list format have trained my eyes to seek out the "meat"

Yes, I've considered adding the ability to dynamically add columns. It is, of course, possible but complicated.

 

[Rinn]

Maybe look into using a JXTable instead of a JTable? I think it handles a lot of the functionality you would want.

 

[roippi]

Haha. Why yes it does.

 

[roippi]

So, point of order: due to how it's coded, using JXTable requires importing the SwingX package into mafia. The -entire- SwingX package, which is ~400ish files and some nonzero number of megabytes. Is that an issue? I know it won't affect the compiled bytecode but I want to make sure it's okay to bloat the source tree like that.

Edit: well, I think I can actually prune down the number of dependencies to around 100.

 

[lostcalpolydude]

I like the word "meat" in the autosell column.

 

[Veracity]

I pulled in the revision, recompiled, started KoLmafia, and logged in. I immediately noticed that my Adventure Frame was about twice as tall as it used to be. I looked at each of my startup tabs - Adventure, gCLI, Purchases, Skill Casting, and Preferences - and didn't see anything taking up an unusual amount of real estate.

Then I noticed the Recovery Items tab on the Skill Casting Frame and, lo, there it was: All my numerous recovery items in a nice new table, with the screen stretched vertically enough to not require a scroll bar.

I shrunk it back to the old size, a familiar and perfectly reasonable size, a desirable size, and a vertical scroll bar appeared, as expected. I was fine with that. I don't mind scrolling to look at my restoratives.

Can we get back the old behavior of starting out with a "normal" height and a Scroll Bar, if necessary, if there are more restoratives than would fit in that height?

 

[fronobulax]

Can we get back the old behavior of starting out with a "normal" height and a Scroll Bar, if necessary, if there are more restoratives than would fit in that height?

It is with fear and trepidation that I post this because almost by definition, I have lost a Battle of Wits with you the instant I enter The Arena, and memory is just a mini-game in that Battle. But...

At one point windows were sized based upon content and some window, I think Daily Deeds, was big enough to make the resulting desktop window size unusable (at least for me). The solution, as I remember, was the preference rememberDesktopSize which would remember the size and override the calculated size. A side effect is that the large window that was driving the size would have scroll bars when it did appear. So I'm not sure whether the old behavior you recall is a result of setting rememberDesktopSize to true, or whether it was a side effect of some other window being the one that "drove" the size of your desktop or whether the new window behaves differently enough that rememberDesktopSize is not working as expected.

 

[Veracity]

So I'm not sure whether the old behavior you recall is a result of setting rememberDesktopSize to true, or whether it was a side effect of some other window being the one that "drove" the size of your desktop or whether the new window behaves differently enough that rememberDesktopSize is not working as expected.

> get rememberDesktopSize

false

This is new behavior.

 

[roippi]

I'd fix that immediately but I'm in the middle of migrating my local copy to JXTable. As soon as I push that, it should fix resizing issues.

 

[fronobulax]

This is new behavior.

Just to clarify for me, is the new behavior the result of the Skill Casting frame now being the biggest window of the set of windows that you have as part of your initial desktop or do you think there is a different cause?

 

[Veracity]

The Skill Casting frame is now the largest frame. That is because the Recovery Items tab no longer comes up with a default initial size and a scroll bar (if it would otherwise be bigger).

Consider the Store Manager. That has a default size which is big enough to show, oh, 14 items. That is because the various panels and tables and such all have various default sizes/limits on them and, taken as a set, that's how big that table comes up as. If I have more than 14 items in my store, I have a scroll bar and have to scroll to look. If I resize the Store Manager frame, all the tables and tabs resize to show more or fewer rows.

That is how all of our frames and panels and tabs should work. And that is how the Skill Casting Frame used to work, until the Recovery Items tab was given a new kind of table and, apparently, not given appropriate size/row constraints.

I assume the "rememberDesktopSize" setting is for people with small displays that cannot handle the default constraints. Or something. I've never needed it; in the past, every time I've resized a Frame, KoLmafia has remembered the size & position of it just fine. Maybe I am misremembering; it certainly remembers the position, but perhaps not the size, and I've never noticed or cared that if I set a frame to larger than usual, it didn't come up that big next time.

In any case, the Skill Casting Frame / Recovery Items panel do not obey when I resize them and restart. I've never needed to resize them before; they have always been well behaved when embedded as a tab in my Adventure Frame. That is not true any more.

As I said, this is new behavior.

roippi has already indicated that he understands and will fix it, so you and I need not "debate".

 

[roippi]

We don't actually have restorative ranges in a datafile, do we?

 

[Theraze]

Nope... it's been repeatedly mentioned as an eventual task, but nobody's formalized it yet.

 

[Veracity]

We have average restoration for various items/skills/methods in moods/HPRestoreItemList.java and moods/MPRestoreItemList.java.

Having actual ranges in a data file and building those tables at execution time from that data would be better. Restoration could work the same as ever, if we wanted, and we could display and the ranges elsewhere.

 

[Theraze]

Among other benefits of Veracity's suggestion, eventually people who prefer a more pessimistic healing range might be able to tell mafia to use the lower bounds of healing ranges and not have to worry about the infinite loops on seltzer purchases anymore.

 

[roippi]

Kay, I'm ready to push this. I'm really happy with all the features that the switch to JXTables provides. It's way cool.

Except that.. well, the swingx package is 489 files. Only 4 MB, but it's the principle of the thing. I only need -one- import from it.

We only need the JXTable class and its dependencies. The problem is that there's all manner of cyclical dependencies in the swingx package. I've tried to compile the .class file and analyze it with a couple of dependency analyzers. Unfortunately none of the tools I've found are particularly user-friendly. I have figured out that it minimally depends on >150 files. So I'm likely to give up trying to reduce the payload pretty soon and commit the whole package, unless that's a problem.

 

[roippi]

Kay, convinced myself to commit it. We can revert it if it bothers anyone.

r11031 is the library commit, r11032 swaps the restorative panel to use JXTable.

Edit: looks like this increased the size of the .jar by around a MB. Not terribly pleased with that, as that's a straight 25% increase in bandwidth for Fewyn's server. The increased functionality might be cool enough to justify all this, I'll let others decide.

 

[AlbinoRhino]

Looks and works great roippi. Can't wait to see it in general use.