beta builds?

[wsu-cb]

Would it be possible to make beta/pre-release builds available now? I would like to be able to publish my GMT Space Empires .gbx, but it depends on some new features.

I'm afraid I'm not motivated to work on the WinState #42 problem since I still have hopes of eventually porting to wxWidgets which will almost certainly require another WinState rewrite.

That leaves the HiDPI #19 problem. Do you see that as a showstopper?

[DLLarson]

Hi Bill,

Would it be possible to make beta/pre-release builds available now? I would like to be able to publish my GMT Space Empires .gbx, but it depends on some new features.

If you'd like to publish betas please give it a go. I believe you have the access level to do so. If not we can change that real quick. I'm heads down studying the graphics code (and doing occasional PR inspections of course.)

That leaves the HiDPI https://github.com/CyberBoardPBEM/cbwindows/issues/19 problem. Do you see that as a showstopper?

Right now the code works fine as is but you get the tiny stuff on High DPI screens.

I'm initially focusing on how I can do the integer multiple approach we discussed. But I can't give an estimate on when It'll be ready yet.

If that works we would probably want a way to turn it off just-in-case which may mean the file format would need to carry an additional flag or perhaps it could be stores as a registry setting. It seems like it should be an application level setting so maybe the registry would be the right place to put it. In that case it wouldn't impact any beta's you publish.

-Dale

[wsu-cb]

If you'd like to publish betas please give it a go. I believe you have the access level to do so. If not we can change that real quick. I'm heads down studying the graphics code (and doing occasional PR inspections of course.)

Have we firmly decided that this is CB 4.0, not CB 3.5?

Also, is there github documentation for making a release? I have no idea how one does that.

If that works we would probably want a way to turn it off just-in-case which may mean the file format would need to carry an additional flag or perhaps it could be stores as a registry setting. It seems like it should be an application level setting so maybe the registry would be the right place to put it. In that case it wouldn't impact any beta's you publish.

That does seem like a system, not .gam/.gbx, setting.

[DLLarson]

Have we firmly decided that this is CB 4.0, not CB 3.5?

I'm good with that. I think that adding the multi-face pieces and expanding the number of possible pieces are pretty big deal changes.

Also, is there github documentation for making a release? I have no idea how one does that.

I was just building them manually and posting them. But I'm pretty sure Github has the capability of creating releases since it already knows how to build the code. Here's what I could find for documentation:

https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases https://github.com/marketplace/actions/automatic-releases

That does seem like a system, not .gam/.gbx, setting.

Agreed. We'll go with that.

-Dale

[wsu-cb]

Also, is there github documentation for making a release? I have no idea how one does that.

I was just building them manually and posting them. But I'm pretty sure Github has the capability of creating releases since it already knows how to build the code. Here's what I could find for documentation:

https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases https://github.com/marketplace/actions/automatic-releases

It would be great to use the builds that Github is already generating, but those links don't provide clear info on how to do that. I see some documentation about preserving build output at https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#uploading-build-and-test-artifacts, but it talks about things like billing, so I hesitate to try any of those actions myself. Also, I have never written Github workflows, so that would probably require significant research time. I think I will have to manually build and upload from my personal machine.

[DLLarson]

Also, I have never written Github workflows, so that would probably require significant research time. I think I will have to manually build and upload from my personal machine.

What I did to figure out how to do the build was to look for similar projects and saw what they did.

I think it's fine to build them yourself until we figure it out. That's what I was doing. I've found that GitHub actions are mega-powerful but they can be as clear as mud when it comes to figuring them out. It's a declarative language.

GH Actions seem a lot like Ansible. I use Ansible to manage my backup server running Linux on top of ZFS mass storage with zraid. Anytime I need to putz with it I gotta relearn the Ansible model again. The knowledge fades without constant exposure.

The color picker is working real nice now. Now I have to get to the tougher stuff.

-Dale

[wsu-cb]

I think it's fine to build them yourself until we figure it out. That's what I was doing. I've found that GitHub actions are mega-powerful but they can be as clear as mud when it comes to figuring them out. It's a declarative language.

My impression of declarative languages, based on GNU make and Yocto recipes: For simple things, they make things simpler. For complicated things, they makes things more complicated. Overall, I think I prefer procedural systems, but I guess we don't get to make that decision here.

The color picker is working real nice now.

Congratulations.

Now I have to get to the tougher stuff.

https://libquotes.com/lois-mcmaster-bujold/quote/lbn5o8y

[DLLarson]

Nice Quote! and oh...how so true.

[wsu-cb]

I have been working on a draft pre-release at https://github.com/CyberBoardPBEM/cbwindows/releases/edit/untagged-1cbf94f8eea40c2a4204. I started by looking at the release for v3.5-prerelease-3, but I have some issues to discuss:

1. I am currently calling the version 4.0-alpha.4+a4350fb and then appending a descriptor like .64bit.debug to describe the build variants. That doesn't match your previous names. Does that bother you?
2. Should we create a branch for 4.0 updates? I think we should eventually, but not yet.
3. Should I create the tag explicitly locally and then push it, or should we let Github do it automatically (which is how the draft is currently set)?
4. I don't really see a reason to provide the .pdb files. Anyone who understands Windows development well enough to use .pdb files can do the build themself. Can we leave them out?

[DLLarson]

(1)...That doesn't match your previous names. Does that bother you?

Nope. I trust you to create a better scheme. I'm not wed to mine. My only suggestion would be to name them in such a way that can those names can be automated.

(2) Should we create a branch for 4.0 updates? I think we should eventually, but not yet

I would say not until the moment an official release happens. Then it should exist so fixes can happen to the release code without worrying about including incomplete features from master. Of course master will also have the fix applied.

(3) Should I create the tag explicitly locally and then push it, or should we let Github do it automatically (which is how the draft is currently set)?

I'm not really sure. So long as the end result is the same I don't think it matters. But whatever will be supported best when the process automated should be considered.

(4) I don't really see a reason to provide the .pdb files. Anyone who understands Windows development well enough to use .pdb files can do the build themself. Can we leave them out?

Sure. None the PDB's are required. But I think offering the debug executables is desirable because they contain sanity asserts--but they can be a separate package. I don't think the debug version should be created for the final release though. These are just my opinions and I'm won't cling to them if they get in the way. It just seems like during betas the asserts and such used to detect inconsistencies would have the most value to ensure busted output files aren't created.

-Dale

[wsu-cb]

(1)...That doesn't match your previous names. Does that bother you?

Nope. I trust you to create a better scheme. I'm not wed to mine. My only suggestion would be to name them in such a way that can those names can be automated.

If I were writing a Linux shell script, I think it would be easy to generate this. In the context of Github actions, I have no idea.

(2) Should we create a branch for 4.0 updates? I think we should eventually, but not yet

I would say not until the moment an official release happens. Then it should exist so fixes can happen to the release code without worrying about including incomplete features from master. Of course master will also have the fix applied.

That's pretty close to what I was thinking.

(3) Should I create the tag explicitly locally and then push it, or should we let Github do it automatically (which is how the draft is currently set)?

I'm not really sure. So long as the end result is the same I don't think it matters. But whatever will be supported best when the process automated should be considered.

As in (1), I have no idea what is practical to automate.

(4) I don't really see a reason to provide the .pdb files. Anyone who understands Windows development well enough to use .pdb files can do the build themself. Can we leave them out?

Sure. None the PDB's are required. But I think offering the debug executables is desirable because they contain sanity asserts--but they can be a separate package. I don't think the debug version should be created for the final release though. These are just my opinions and I'm won't cling to them if they get in the way. It just seems like during betas the asserts and such used to detect inconsistencies would have the most value to ensure busted output files aren't created.

My view is that both beta and release builds should generate both debug and release executables. The docs should encourage downloading debug executables for beta releases, and release executables for releases. In other words, during the test phase, the sanity checking should be prioritized, but for a release performance should be prioritized. However, I think we should provide both variants. I can easily imagine asking a user to run a debug build to check for any asserts if the user reports a difficult-to-reproduce bug.

[DLLarson]

If I were writing a Linux shell script, I think it would be easy to generate this. In the context of Github actions, I have no idea.

Then don't worry about for now. It's minor in the scheme of things. I'm sure GitHub actions can handle most what we through at it. It's not lightweight--which is part of the problem of just walking up and using it.

As in (1), I have no idea what is practical to automate.

Ditto my previous comment.

That's pretty close to what I was thinking.

Lets go with that then.

My view is that both beta and release builds should generate both debug and release executables.

Then let's do that then. Not a problem.

An aside... I may have a way to do the integer scaling without touching the low level rendering stuff by simply scaling up the resulting memory DC used to render the boards. Here's a taste of where I'm at (I'm only working on CBDesign at the moment to test my ideas):

Note that I haven't addressed the tile/marker/piece trays yet.

-Dale

[wsu-cb]

Another question: Do we really need to upload .zip/.tar.gz files of the source code? The release should specify the git commit id and/or corresponding tag, so users that want source code can download a .zip using the "Code" button on https://github.com/CyberBoardPBEM/cbwindows or the corresponding button for a particular commit id.

[DLLarson]

Do we really need to upload .zip/.tar.gz files of the source code?

Nope... For a couple reasons. It's not GPL'ed so there is no requirement to supply source (a big reason I avoided it). Just the same, the astute person could just obtain the source using the SHA git ID or they could use the release's tag.

-Dale

[wsu-cb]

I have now finished a draft of the prerelease at https://github.com/CyberBoardPBEM/cbwindows/releases/tag/untagged-7340a97ea45ac7b491a4. Could you please review it?

Note: I tried to order the files with the 64 bit files first since I want to encourage their use, but it appears that Github automatically sorts files by name. Even when uploading the 64 bit files first, and the 32 bit files afterwards, the 32 bit files sort to the top of the Assets. At least for now, I don't think I want to artificially change the filenames to force the 64 bit files ahead of the 32 bit files, but I'm not aware of any other mechanism for changing the file order.

[DLLarson]

Note: I tried to order the files with the 64 bit files first since I want to encourage their use, but it appears that Github automatically sorts files by name.

Not much you can do there. I like the package naming.

I forgot about some of those other extras (geomorphic and rotations) you added. Nice!

The only item I'm fuzzy on is this one: "handle the boards in Peter Lomax Ogre/GEV". Does a gamebox already exist like that or does this update make supporting those style of boards in geomorphic mode possible when it wouldn't work before. If I'm fuzzy on it I think other people may not understand it at all.

I downloaded the 64 bit version and ran it against my scaling test file and it works (of course without DPI stuff.)

I think it also might be good to add a comment about not having support for scaling high density displays such as 4k monitors. That it will be in a future release.

Note that the screen shots for I posted are scaling views at integer multiples like we discussed. The screenshots are 2x view scaling as displayed on my 1.5x scaled display (rounded up). I think it looks pretty good so fractional scaling shouldn't be needed.

-Dale

[wsu-cb]

The only item I'm fuzzy on is this one: "handle the boards in Peter Lomax Ogre/GEV". Does a gamebox already exist like that or does this update make supporting those style of boards in geomorphic mode possible when it wouldn't work before. If I'm fuzzy on it I think other people may not understand it at all.

This entry is in reference to https://github.com/CyberBoardPBEM/cbwindows/pull/78#discussion_r830675602, and the .gbx is in your library, as noted in https://github.com/CyberBoardPBEM/cbwindows/pull/78#issuecomment-1073350008.

I downloaded the 64 bit version and ran it against my scaling test file and it works (of course without DPI stuff.)

:-)

I think it also might be good to add a comment about not having support for scaling high density displays such as 4k monitors. That it will be in a future release.

I have added a "Known issues" section to the draft. Please review it.

Note that the screen shots for I posted are scaling views at integer multiples like we discussed. The screenshots are 2x view scaling as displayed on my 1.5x scaled display (rounded up). I think it looks pretty good so fractional scaling shouldn't be needed.

Can you tell yet whether CB can automatically choose a reasonable scaling factor, or will the user need to specify the scaling?

[DLLarson]

I have added a "Known issues" section to the draft. Please review it.

Looks good.

Can you tell yet whether CB can automatically choose a reasonable scaling factor, or will the user need to specify the scaling?

So far the detection works fine and the visual results are decent. I lifted the detection basics from some Microsoft sample code. I'm just rounding to the closest integer of the ratio between the monitor's DPI and 96 dpi (Windows standard.) In my case it rounds to 2 or double the 96dpi sizes that you see in the tile tray above.

or will the user need to specify the scaling?

I think the only thing that may be needed is a way to turn the scaling off for some inevitable oddball situation we can't imagine at the moment. At any rate that would just be a UI addition of some sort. The code to do the scaling doesn't care where the number comes from.

-Dale

[wsu-cb]

I have added a "Known issues" section to the draft. Please review it.

Looks good.

Does that mean I may push the "Publish release" button and see what happens?

So far the detection works fine and the visual results are decent. I lifted the detection basics from some Microsoft sample code. I'm just rounding to the closest integer of the ratio between the monitor's DPI and 96 dpi (Windows standard.) In my case it rounds to 2 or double the 96dpi sizes that you see in the tile tray above.

I think the only thing that may be needed is a way to turn the scaling off for some inevitable oddball situation we can't imagine at the moment. At any rate that would just be a UI addition of some sort. The code to do the scaling doesn't care where the number comes from.

-Dale

I wasn't so much asking about the code doing the scaling, as whether we could expect most users to be able to run CB "out of the box". It sounds like we have a very good chance of that, which is what I was hoping.

[DLLarson]

Does that mean I may push the "Publish release" button and see what happens?

Sure! Let it rip.

It sounds like we have a very good chance of that, which is what I was hoping.

Yep. That my goal. So we never have to hear about it. :)

-Dale

[wsu-cb]

Interesting. I didn't upload the "Source code" files; Github must generate them automatically.

[DLLarson]

Github must generate them automatically.

Well that's interesting. Well at least we don't have to be concerned by that. That may have happened to me before but I totally missed it.

-Dale