Collectible Card Game Headquarters

Tentative target release date: Friday December 27.

So as anyone who's updated their source recently might have seen, I've made some really good progress at improving filters for Deck Editor, as well as consolidating them into the ItemManager control for re-use in the Workshop and other places.

I've merged the Color and Type buttons in with the other "Add filters" button filters such that you can now hide them, while at the same time improving the appearance of the other filters. I also fixed it so the Color and Type filters no longer wrap if the pane is too narrow, instead decreasing the button widths and the font size if needed. I also added a new CMC toggle buttons filter that works just like the Color and Type filters, making it easy to focus on specific areas of your curve while also displaying card counts for CMCs 0,1,2,3,4,5,6+, allowing you to easily see your curve without switching to the Statistics pane.

Here's what it currently looks like:


Note that I still need to add back the Pack filter button for the Spell Shop, but its on my TODO list. After that, I hope to make the boolean logic field editable, support saving the current filters in the preferences (as well as saving and loading from separate files, similar to layouts), and then start working on a Card View that can be used instead of the List View if you select it from the combo box.

Let me know if you have any questions, concerns, or suggestions.

Thanks.
-Dan

Looks good to me. Thanks Dan.

Then, a little outside the scope of your current work, but thought I'd suggest it while you're working in the deck editors. Would it be possible to add the "add card" button to the current deck section allowing the user to increase a card's count without having to find it again in the available cards. It has been a common request, but its beyond my current skill unfortunately. Constructed mode would be the easiest mode to implement it, while draft, sealed and quest would first have to check that the card is still available before the button would be enabled.

moomarc wrote:Looks good to me. Thanks Dan.

Then, a little outside the scope of your current work, but thought I'd suggest it while you're working in the deck editors. Would it be possible to add the "add card" button to the current deck section allowing the user to increase a card's count without having to find it again in the available cards. It has been a common request, but its beyond my current skill unfortunately. Constructed mode would be the easiest mode to implement it, while draft, sealed and quest would first have to check that the card is still available before the button would be enabled.

I'm working on general Deck Editor usability improvements, so it's not out of scope. It's also a good idea.

What I'd actually rather do, if people are open to it, is add "-" and "+" clickable labels to the quantity column on either side of the number, allowing you to adjust the quantity without first selecting the row. I can also include some additional items in the right-click menu to allow adding more of a particular card. There's not enough room for more buttons above the table though. How's that sound?

Also, would anybody want an "Add 10" options for basic lands (and cards like Relentless Rats that don't have a limit of 4)? Or maybe just a more general "Add X cards" submenu that lists the numbers 1-10 and an "Other" item that prompts you to enter a number?

Thanks for the input.

I like the idea of the inlined +/- buttons. Just keep them as narrow as possible to reduce the space it uses in the table.

So the inlined +/- buttons idea ended up leading me off on a small tangent. The result was adding a new Favorite column before the Name column in Catalog, where you can click on a gray star outline icon to mark a card as a favorite and change the icon to a filled gold star. Favorite cards will sort to the top by default (assuming the first column is the primary sort column with descending sort order, which is now the Forge default), making it much easier to find the cards you like using the most. Favorites will also be saved between sessions in a new card.preferences file, so you can build up and maintain this favorites list over time.

Here's a snapshot of what this feature looks like. In this example, I've favorited three of my favorite cards for green decks, such that they appear at the top of the list above all other cards.


I'm definitely curious to hear feedback on this one. Hopefully I'm not the only person who will find this useful (though if I am, the column will be hidable).

Thanks.
-Dan

Dan, those stars must not change any class in core module, because "being player's favourite card" is not an intrinsic property of a paper card. Only those properties are intended to be kept in classes declared in core.
So, please implement that without changing anything in common modules.

I have rolled back your changes from forge-core, but didn't yet remove if from in game card class, because game module is not separated yet.

Should you change the core module again without a solid reason, I'll have to raise the question of pre-moderation of commits to ceratain modules.

Max mtg wrote:Dan, those stars must not change any class in core module, because "being player's favourite card" is not an intrinsic property of a paper card. Only those properties are intended to be kept in classes declared in core.
So, please implement that without changing anything in common modules.

I have rolled back your changes from forge-core, but didn't yet remove if from in game card class, because game module is not separated yet.

Should you change the core module again without a solid reason, I'll have to raise the question of pre-moderation of commits to ceratain modules.

I put that logic in core because I want it to be sharable between the desktop and mobile modules eventually. Putting it in forge-gui wouldn't allow that, and there's no other module where it would be supported. I made it a separate HashMap indexed by card name, and simply added a getPrefs function to IPaperCard for ease of access from DeckEditor logic. I even kept the file path as a constant on forge-gui so it could be stored at a different location on a mobile device. How exactly is all that breaking the rules?

You make it seem like I just throw code wherever I feel like it, but I do put thought into it. I'm just working with the code base as it is. It bugs me that you belittle my contributions so much because they don't fit into the code pattern you're envisioning. I don't mind moving things around if they make sense somewhere else, but don't just take out my changes and then yell at me about it. You can just send me a message requesting I move it somewhere else and explain your reasons.

I've put a lot of time and energy into improving Forge, so I'd appreciate a little more respect from you. Your threat to moderate my contributions just because I can't read your mind is extremely insulting.

Dan, there's no problem in adding a fifth module with auxiliary classes to be used by interactive applications you're developing, be it Swing gui app or android one. Feel free to add a module! The problem is that core module's role does not suppose any "customization" added to core classes and/or interfaces - only essential cards' and sets' data should be there, nothing else.

I do recognize that your changes make Forge look better. It's amazing that you find so much time to spend on the project and it's an enjoyment to see your additions working properly. Unfortunately, unlike many users who see only the exteriors I also have to care about the internal tidiness of code and for that reason reject changes that do not fit in their place. This includes adding methods to improper classes. You may find an example of such class that has been expanded without control in forge.game.Card - it has actually more that 8000 lines.

Certainly it is a pity when some features' code is rejected after you had finished them. I am sorry that you consider this disrespectful. Yet, I have no other choice, especially taking into consideration that the technical part of the upcoming changes is rarely discussed here.

Thank you for the complements. I'm sorry if I came off super defensive about your reaction to the changes I made. I guess I was just frustrated because I had tried to come up with an implementation that would be acceptable to you and not muddy up core classes, and yet I fell short of that goal. That's why I used the HashMap as you had suggested back when I did the Workshop and we went through this for CardScriptInfo. I admittedly didn't considered adding another module, however at this point I will wait to do so until these new preferences would need to be referenced by the Android module.

Is there a document or wiki out there that describes what should go where in this new module structure? If not, might I suggest one be created. That would provide a good reference for me and other developers to make sure we're not putting code in the wrong place in the future.

For now, I'll just stay out of forge-core, forge-game, and forge-ai if possible, and run any changes by you if I would need to make any. I'm really not trying to make your job more difficult. I respect your dedication to keeping the code organized and paving a path towards network play and now mobile support with this modularization project.

Alright, the +/- buttons for the Deck Editor are done. Let me know what you think.


Thanks.
-Dan

I just committed an improvement to FDialog to use rounded borders and show the theme background texture (with the theme overlay color applied to prevent it being too opaque). I also made it so the main overlay is shown while the dialog is open. The result looks something like these:


Now that I'm happier with the look of these dialogs, my next step will be to translate other non-skinned message boxes to use this new look. Please let me know if you have any questions or concerns about this.

Thanks.
-Dan

drdev wrote:I just committed an improvement to FDialog to use rounded borders and show the theme background texture (with the theme overlay color applied to prevent it being too opaque). I also made it so the main overlay is shown while the dialog is open. The result looks something like these:

The attachment FDialog.png is no longer available

Now that I'm happier with the look of these dialogs, my next step will be to translate other non-skinned message boxes to use this new look. Please let me know if you have any questions or concerns about this.

Thanks.
-Dan

 
I updated to the head rev.

I went to the deck editor and clicked on the import button and forge crashed:

UnsupportedOperationException | Open

Code: Select all

Forge Version:    SVN
Operating System: Mac OS X 10.7.5 x86_64
Java Version:     1.7.0_21 Oracle Corporation

java.lang.UnsupportedOperationException: PERPIXEL_TRANSPARENT translucency is not supported.
   at java.awt.Window.setShape(Window.java:3692)
   at java.awt.Dialog.setShape(Dialog.java:1344)
   at forge.view.FDialog.paint(FDialog.java:62)
   at javax.swing.RepaintManager$3.run(RepaintManager.java:807)
   at javax.swing.RepaintManager$3.run(RepaintManager.java:784)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:784)
   at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:757)
   at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:706)
   at javax.swing.RepaintManager.access$1000(RepaintManager.java:62)
   at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1651)
   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:727)
   at java.awt.EventQueue.access$200(EventQueue.java:103)
   at java.awt.EventQueue$3.run(EventQueue.java:688)
   at java.awt.EventQueue$3.run(EventQueue.java:686)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:697)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:154)
   at java.awt.WaitDispatchSupport$2.run(WaitDispatchSupport.java:182)
   at java.awt.WaitDispatchSupport$4.run(WaitDispatchSupport.java:221)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.awt.WaitDispatchSupport.enter(WaitDispatchSupport.java:219)
   at java.awt.Dialog.show(Dialog.java:1082)
   at java.awt.Component.show(Component.java:1651)
   at java.awt.Component.setVisible(Component.java:1603)
   at java.awt.Window.setVisible(Window.java:1014)
   at java.awt.Dialog.setVisible(Dialog.java:1005)
   at forge.view.FDialog.setVisible(FDialog.java:93)
   at forge.gui.deckeditor.controllers.CCurrentDeck.importDeck(CCurrentDeck.java:126)
   at forge.gui.deckeditor.controllers.CCurrentDeck.access$6(CCurrentDeck.java:120)
   at forge.gui.deckeditor.controllers.CCurrentDeck$8.run(CCurrentDeck.java:111)
   at forge.gui.toolbox.FLabel._doMouseAction(FLabel.java:311)
   at forge.gui.toolbox.FLabel.access$4(FLabel.java:308)
   at forge.gui.toolbox.FLabel$4.onLeftClick(FLabel.java:353)
   at forge.gui.toolbox.FMouseAdapter.mouseReleased(FMouseAdapter.java:184)
   at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:290)
   at java.awt.Component.processMouseEvent(Component.java:6505)
   at javax.swing.JComponent.processMouseEvent(JComponent.java:3321)
   at java.awt.Component.processEvent(Component.java:6270)
   at java.awt.Container.processEvent(Container.java:2229)
   at java.awt.Component.dispatchEventImpl(Component.java:4861)
   at java.awt.Container.dispatchEventImpl(Container.java:2287)
   at java.awt.Component.dispatchEvent(Component.java:4687)
   at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
   at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
   at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
   at java.awt.Container.dispatchEventImpl(Container.java:2273)
   at java.awt.Window.dispatchEventImpl(Window.java:2719)
   at java.awt.Component.dispatchEvent(Component.java:4687)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:729)
   at java.awt.EventQueue.access$200(EventQueue.java:103)
   at java.awt.EventQueue$3.run(EventQueue.java:688)
   at java.awt.EventQueue$3.run(EventQueue.java:686)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
   at java.awt.EventQueue$4.run(EventQueue.java:702)
   at java.awt.EventQueue$4.run(EventQueue.java:700)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:699)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)


 

Looks like setShape is not currently supported on Mac: http://stackoverflow.com/questions/8472273/java-code-does-not-work-on-mac-os-x

I just committed a fix (r24039) to surround the setShape call in a try/catch block. That way the dialog's corners won't extend beyond the rounded border on any OS that supports setShape, such as Windows (not sure about Linux). For Mac, the background and titlebar will just have to extend slightly beyond the rounded border, but that shouldn't look too bad. If it does look bad, let me know and I'll update the code to show a non-rounded border on Mac.

Thanks for letting me know about the crash.

EDIT: Committed a tweak to the fix in r24040 to avoid a try/catch block after reading this article about the use of setShape: http://docs.oracle.com/javase/tutorial/ ... ndows.html

Hey Dan,

I noticed the new filters don't save their state when closing and returning to them. Was this intentional? It was a bit surprising to me the first time I had to refilter the Card Shop as I got used to not needing to do it in the middle of a session.