mtgred
New layout
Adds alternate layout for the jnet board.
There are three new settings, all default to off.
Enable new theme:
- Game log moved to left of screen
- Agendas tucked in behind name card
- Compressed the least used stats (core damage, bad pub, etc) and enlarged credits and clicks
- New agenda icon
- Indicate action button moved to side of chat box
- New undo action button (since this command is used a LOT)
- Added on hover descriptions to new buttons, agenda icon etc
- Card hover zoom moved closer to the card being hovered
- Moved RFG, Currents and play area to right middle of screen (to accommodate more assets)
- New icon for popups
- Flexbox hands better scale with large amounts of cards
- Simplified left, central and right panes DOM layout. This should make new layouts much easier in cyberfeeder
- Theme converted to CSS variables to allow custom themes (either through jnet later or cyberfeeder)
Shrink runner cards down to image (required new-theme to work):
- Cyberfeeder feature integrated with jnet that condenses runner cards down to just their image. Makes very high zoom levels more palatable
Condense basic actions to icons (required new-theme to work):
- New icons for all basic actions
- Basic actions moved below name box
New CSS is activated via a class on the main div, this allows all the new CSS to be turned on or off without affecting any of the existing styles while the theme is off
Since the board layout is changed significantly, I chose to use a separate file for it so I can be sure I dont break the existing board.
okay, i slept on this and i am not sure if it's a good idea. like, by itself it's a great idea. people should have choice, you obviously care deeply about it. however, it's 4k extra lines of code, a massive amount of it is duplicated, and it's unclear to me that this increased maintenance burden will be worth it in the long run. For example, if/when I figure out how to switch from "json" to pure edn game state changes, will I have to modify both sets of game board functions? Seems likely to me, which worries me.
What do you think? How do you plan on supporting both this and the other game board at the same time? (not to mention the pile of stylus css)
I think there are a few ways we can approach changes like this.
- Incremental changes to existing code, existing board slowly morphed into new layout. Some people would not like this.
- New layout completely separate to old one. Advantage is that its hard to break anything when you change a specific board since changes in one layout will not affect the other. Downside is you need to make changes that apply to both boards twice.
- Rewrite existing layout so that as much code can be reused as possible. This has the highest chance of breaking stuff in the initial PR and changes will now affect both boards at once. This is mostly beneficial but it will make it easy to break a layout when you make a change that affects both boards in different ways.
The main reason I chose to create new files and duplicate code was because this makes the review a lot easier. If I dont touch the existing board much then the only thing I can really break is the new functionality. I looked at all the changes in the last year on the main board and it would take less than 5 minutes to replicate them on a second board, so I evaluated the maintainence burden as small.
My rough plan is that I would keep improving the new board and leave the existing one mostly untouched. That means any changes I make wont break the existing board and if I am not supporting it or its not being used the new board can be deleted with minimal hassle.
I would be happy to do whichever option is your preference. I can dedup the files with minimal hassle, but there will still be two boards to maintain and that will undoubtably be more work even if there havent been many changes recently.
What are your thoughts?