More colab-geared system then Sourceforge? Github?

So the person that made 2.0.1 was a ghost then?

If there are no official devs left, then why not create a new team.
I'm meaning those with a mind to actually get this started again, as I'm obviously not the only one. I'd like to get the individual who made 2.0.1 involved, as I gather they're an admin of these boards.

I was wondering why I'd not had any pings on this, i still don't think I've got following set up right, but then there was no responses.

Is there anyone else interested in doing this?

The code for Aurora's updated version of MSE is at github.com/Lymia/MagicSetEditor2.

I would be interested in contributing to reviving MSE development.

Fenhl thanks for the link. I'll tkae a look and merge the contents of that into the new repo I've made

bagz "hacking around" wouldn't really be appreciated, as I'll be doing a code cleanup so would like the codebase to stay maintainable one i'm done. But you could use this as an opportunity to learn and improve your C++; as there's always something to gain by code reviewing, or you could attempt fixes and get feedback.

I do C++ in my day-job, with a dose of many other languages. I'm no wizard, and this will be my first major project outside of uni and work, so I'll be using it to develop my skills as well. I intend for this to be very feedback-driven where everyone can learn bits form code review.

I know of at least one feature loss in 2.0.1: The Add Cards button used to have a dropdown for Add Multiple Cards with a menu of options. This is still available from the Cards toolbar but not from the ribbon button.

Hmm, i'll have a look at that. It should be fairly easy to find in the code disparity

just an update:

Been a mix of busy, apathetic, and having too many games come out at once. But i have given the code a bit of a look over.
I'm still making a decision on which codebase to use: base svn trunk, or lymia's 2.0.1.

My first issue either way is i don't know much about the framework it uses. wxWidgets is totally new territory for me, and i'm going to have to do a lot of reading in order to comprehend any of it, as it looks and seems to act very differently to the frameworks i know (winforms, win32, Qt, android activities)

One black mark against the svn trunk is it's age. Visual studio 2017 almost balked at the over 10-year-old solution format. However, in Lymia's fork, the solution project files don't exist, and she's put a lot into the make files, which points to one of two things: the more likely one is she's from a linux background and eschews the GUI approach of visual studio as i saw a lot of mentions of mingW32, the other option is that she did what cmakes does, but manually, and uses a solution that allows GUI project use outside the repo
So that pushes CMake up the todo list, and i've never created a project with cmake either. (I've built with it, using a project someone else made, and that's open source so i can look at that and learn from it)

My thoughts at the moment are to base the fresh codebase on lymia's 2.0.1 fork. This would allow us to keep the history, including all the older svn stuff, for reference, while including a lot of the build fixes that have been applied (as i expect that modern compilers didn't like the old codebase). This would mean the plan changes to this:

• Fork and pull Lymia's repo.
• Initialise the point I start at for Git-flow to aid development lifecycle
  
• Figure out how the current build system works - i suspect cygwin is heavily involved.
• Swap system to use Cmake to aid multiplatform development, and save my sanity by allowing me to use visual studio or eclipse
  
• Merge in whatever features were lost when development diverged.
  
• Decide what else needs done going forward

When you put it that way, i agree with using the base repo. it also means I don't have to pick through feature loss and reinstate it.

Windows has no "standard" way of building anything. It comes with no build tools as standard, and it's not common practice for the average user to build source code.
If you were to ask "what is the most native way?" i'd answer using the VC++ compiler that you can get from MS for free, and the most all-in-one way is to use visual studio.

That's not to say it's bad to build with any other compiler, but i may go as far as to say using mingw is probably the LEAST standard way, as it's practically forcing linux-like ways into windows. Again, not saying it's bad to do (in fact it's super useful), but "standard" is not the word I'd use to describe it.

The idea behind CMake is it would allow for any means of development on any platform: bare-bones text editor and command-line compile, all the way to generating an IDE project with all dependencies and paths set up.
I used it in an old job where the entire team was spread across Windows, Ubuntu, Red Hat and OSX, and the CMake build system allowed the same codebase to be easily imported into each dev's build preferred way of developing. The IDE project files never got into the codebase, as CMake would generate them elsewhere and they would reference the repo files in the original directory.

I'm very much in the camp of "I'm not using the command line if i can avoid it" and windows doesn't lend itself to that kind of development easily anyway. So sticking with just a makefile and forcing all Devs to use that is pretty much out of the question. CMake solves that by separating the source from the means of building on a platform.

The base sourceforce repo DOES contain visual studio files, and OLD ones at that. Lymia's fork has gotten rid of them, but not replaced them with anything that lends itself to being windows-friendly.

That was the plan. I've got some other projects that need my attention more urgently (the reason I've not focused on this yet) . But this seems like a good plan for when i get to it.

Allow me to clarify both:

There's a difference between hearing about the framework, and knowing much about it and how it works. I know what framework it uses; I've just never worked with wxWidgets before, so i don't know much about it. It'll just be a learning curve. In fact, I say exactly this in the post you quoted.

We also know the feature difference (the jpeg -> png thing, as well as a little feature loss apparently) - we're talking about the codebase itself and where lymia's fork branches off on the main codebase.

You are describing my level of skill as well. which is why this is taking time as it's a huge learning curve for me.