Forum Replies Created
-
AuthorPosts
-
Not really. Ideally, that kind of thing needs a native environment or you could get weird results.
I’m not really seeing much in the commit log. Even the changes necessary to the Windows API and for C++20 compliance look relatively benign so I’m not sure why it works in 0.6.3 but not in 0.7.0. Right now, the best I can say is that the ongoing overhaul should fix it as that will pretty much rewrite most of the internals and replace the GUI.
Haven’t thought about it too much, been busy with other tasks. We could simply replace the list with a standard open file dialogue box that other programs use. If we want to keep it, we’ll definitely want to fix it to actually search in the path specified by the settings window (why it was written otherwise is beyond me). That could be fixed by simply passing the path variable to it, will check on that. There’s also a third, more complex option: implement project workspaces where each workspace saves a list of plugins to filter out based on configuration. Many new land projects have a set grouping they work with, for instance.
Okay, I pulled the release off of GitHub. I’ll update the threads in the morning.
In all likelihood, ill probably hold off on doing another release until after the overhaul has made more progress due to how unwieldy the code is at the moment
Still haven’t looked into the changes but it’s going to be pulled regardless.
Okay, I’ll put it on ice as soon as I get to the computer — probably tomorrow. Not sure what’s going on but I’ll take a look at the changes and see if they enlighten me. If not, it’ll probably stay in alpha until I finish modernizing the code as it should go away as we switch GUI toolkits and get rid of the nonstandard stuff, as well as fixing up the various warnings. I was really hoping to be able to have 64-bit release out, though
Are you able to reproduce issue #38? Since it sounds like 0.6.3 is working, that mostly narrows it down to one of two things: missing Unicode support (not likely as abot is using ASCII) or the Windows API updates that had to be done. It also sounds similar to an issue I found while packaging 0.6.3 and put on the back burner as it was mostly worked around as part of #31: just using the same directory and ignoring the settings screen
I’ll go ahead and reversion it as an alpha release. It may take a while before it can be fixed if it’s more than just the API changes due to how the code is laid out.
And 0.7.0 has been released 🙂
And all of the appropriate announcements have been made 🙂
Nope. Wasn’t able to find much on the community forums: just about everything I found dealt with doing restoration on your own, which isn’t feasible for me. I’ll probably need to reach out to that list and see what they say
In related news, this got announced last week: https://www.nintendo.com/us/store/products/legend-of-zelda-limited-edition-vinyl-8lp-set-127813/
No details about the pressings but I’m sure they’ll be fine
Used to have that happen all the time with old mice that simply used the rubber ball since it’d suck dirt up into the works. A simple cleaning always did the trick 🙂
Much harder now as it’s not as easy to access the mechanism 🙁
Sure, we can mirror it. That would definitely help.
Redistribution is definitely allowed per the license:
For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights.Yep. Went ahead and uploaded it here. GitHub is cranking away now so I’ll fix the tags tomorrow and finish publishing the new version 🙂
And updated the description of the DevIL mirror to comply with the license
So, new error today: looks like SourceForge is blocking the automatic download of DevIL from the CI but I can grab it fine with wget locally. Will need to come up with a new way of getting it. I’d rather not add DevIL back into the repository if I can help it. And I was just about to publish version 0.7.0, too 🙁
Looks like we have msitools over here. Will need to look into it
Looks like the fee is only required if the organization is making money so we should be good for now. 🙂
The biggest blocker to having support for other compilers at the moment is the generated code. VS uses its Class Wizard to generate it which isn’t supported by other setups. That’s still on the list. As I recall, MinGW required additional libraries to build stuff that makes heavy use of the Windows API so we’ll need to sort it all out when we get there.
Works for me. I’ll go ahead and start cleaning things up in preparation for 0.7.0 and then squash the CMake branch since the commit log is so messy. Afterwards, I’ll make a new commit bumping up the version number to 0.7.0.
For future versions, I’ll be setting things up to use CMake’s configure file command so that we can just pass the version number to the CMake build command. The code uses several different macros to handle the version number so we’ll need to do some hunting. It’ll also mean adjusting the resource file to use the variables as well but that’s a fairly simple matter (will reply to the resource file comment shortly!) 🙂
Edit:
Added a link to the cross-compilation issue 🙂
MSIX is for the Windows Store as opposed to a standard downloadable installer. May be something to consider down the road, however. It would require more work to get things running and I’m not entirely sure how to set the CI up for it. We can certainly add it to the tracker, though, as a long-term goal. It took Gimp years before they submitted it to the Windows Store, for instance 🙂
Edit: added to the tracker 🙂
I can ask the LOOT folks about the pros and cons as I’m sure they’ve done some consideration already. 🙂
Here’s the list of software that the Windows CI supports out of the box: https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md
There are some package managers in there but I’m unfamiliar with them so I’m not entirely sure how they work.
Anything in there that seems useful, in addition to what we’re already using? As wget isn’t included, we’re using aria2 which supports a similar syntax as wget.
Been a bit of a rough week so I haven’t been able to look too much into the installers yet. Hopefully next week will be better!
I have yet to watch Sweeney Todd. Missed out on the stage version, too. 🙁
Really need to fix that
Florida oranges aren’t doing so hot lately. Citrus greening is hitting the state pretty hard, even home grown ones. On the bright side, the fig trees are doing great
I generally don’t have issues with the wildlife beating me edibles in the wild: plenty of beauty berries still available. Really need to try making jam one day…
Used to harvest blackberries but the city cleared the bushes that I have access to, as well as most of the low hanging grape vines. Fortunately, I can still find some grapes that I can reach 🙂
It looks like you can use
wine cmd <batchfile>.batto run it under wine but I don’t currently have Wine installed.Should run the same on Windows server as it does on regular Windows. Just a thought: any plans on a PowerShell version? It looks like Microsoft is trying to replace the batchfile language with PowerShell scripts.
Sorry, been busy with trying to figure out how to proceed with MWEdit. The installer business has kind of thrown me for a loop.
Yeah, we may need to forgo CPack as its feature set seems rather limiting. Its Inno support does look better than its WiX support, even though it is very much in the early stages (the docs definitely need some proof-reading). Wouldn’t give us the pretty MSI integration but the docs on using WiX (even the ones on the official Firegiant site) aren’t the best and it was hard for me to follow them when I read them yesterday. I’m just not very good at release engineering.
CPack also has decent NSIS support if we want to try to continue using it instead of simply splitting out the operation.
CMake sets up their shortcuts via template files: https://gitlab.kitware.com/cmake/cmake/-/tree/master/Utilities/Release/WiX?ref_type=heads
Not yet sure how they do it, I’m still analyzing things. It would help if this stuff were documented but alas.
Gimp, on the other hand, uses Inno Setup (as does LOOT) but Inno doesn’t create MSI files, which would be nice for integration. BOSS used NSIS but the syntax was pretty ugly.
CPack has an option, CPACK_WIX_PATCH_FILE, to add a WiX XML fragment to the files. We may be able to leverage that feature. Will take a look at that article when I get the chance and will poke around the web some as well. 🙂
There isn’t a whole lot of information regarding the features to use fragments, though. We may need to do some trial and error.
Okay, made those changes: https://github.com/deathssoul/MWEdit/actions/runs/18993040962
All files should now go in
MWEdit/instead ofMWEdit/bin/and I updated the commands for shortcut creation. 🙂Perfect! Will get that fixed and then we can do a final test before the version bump and the update script test 🙂
No idea how to get the executable in the root of the MWEdit directory using CPack but I’ll add it to the wishlist!
Edit:
Looks like it’ll take the
.option to the destination setting. Will try that for the next test to clean up the layout someDid the shortcuts work before? We definitely want the options. Apologies, the shortcuts are probably the least documented part of CPack.
Does the license show up properly now?
Okay, here’s a new attempt: https://github.com/deathssoul/MWEdit/actions/runs/18967509920
It should put all files in the bin directory (will add a note to look for the extra data files elsewhere on the tracker later) and hopefully it fixes the issues with desktop shortcuts and Start Menu entries. I also changed the
LICENSEfile toLICENSE.txtas the docs make it sound like a file extension is required for importing even though standard practice is to leave the extension off on *nix.Thanks. That’s probably due to me using the DATA file type. The install system on CMake is poorly documented for anything other than *nix, sadly. I may be able to force them into the same directory, will look into it. Eventually, we’ll want to clean up the directory structure some but that requires more work in the code to look for the required data files elsewhere. Windows is a bit restrictive on DLLs so we’re probably out of luck on that front.
Did some looking yesterday and it looks like I used the wrong commands for the Start Menu and Desktop shortcut options. WiX has its own options but you need to use properties instead of variables for it: https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-installed-files
Don’t know how to use them yet but I’ll see if I can figure it out. Hopefully those fix that issue. My guess is the poor documentation is a result of CPack just not being used a whole lot: most projects write their own installer scripts separate from CMake.
-
AuthorPosts
