My current general issues with MiniPlaner about miniplaner

[mkroening]

To be honest I have only found MiniPlaner after I had already written AltarPlanner in the last years, which I am using myself and which produces astonishing results, but is not very user-friendly. AltarPlanner is dormant though since I am generalizing the idea of planning a roster (not only altar servers) and incorporating calendar-integration with RosterPlanner which I am designing from scratch once again with everything I have learned during AltarPlanner development (not publicly yet). Both are written in Java and leverage the excellent OptaPlanner constraint solver. I currently plan using JavaFX for UI in RosterPlanner as I did in AltarPlanner, but the project is very modular and leaves the possibility for other front-ends.

I really like MiniPlaner gaining traction as free software again though and really enjoy improving it by porting it to Linux and reworking the build and packaging system, but I won't be deploying this project myself and don't think the code base is easy to adapt to all of your proposed features.

Regarding your list:

1. While C++ has many pitfalls regarding memory management when coming from Java, I actually think that the understanding of objects and classes in Java is a big help when diving into C++. One has to get familiar with the Syntax though, but that comes with time. If you want to talk about certain concepts in C++ feel free to write me an email, and we can talk. :)
2. I agree that wxWidgets becomes less suitable the bigger the project becomes and I personally dislike that you often have to account for platform-differences yourself instead of having a true cross-platform library, but I don't think MiniPlaner will ever migrate to another GUI-library, as wxWidgets is deeply woven even into the planning-core of MiniPlaner. (Might be slightly off-topic, but here an interesting story about migrating dolphin-emu away from wxWidgets: The Legend of Dolphin: A Lens Between Worlds)
3. It should be possible to detect and convert old datasets if need be for a new format, don't you think?
4. What would these many people do exactly? There is MiniInterface.php for servers to enter their absences. Do you have many irregular inputs for masses?

[yannikschaelte]

Hi,

sorry for the delay. I totally understand all of your points.

1. Used Language
   I have only a very very rough understanding of C++ and my attempts to understand it have been only moderately successful so far.
   I'm writing an exam in/about Java in a few weeks and I'm just confusing myself with C++ right now.

Fun fact: MiniPlaner 1.0 was written in Java, but completely different structure and bad assignment algorithm, no use investing time in. In principle, Java and C++ are really close though, so easy to switch.

This is most definately a personal issue of mine and in itself no big problem.
2. GUI
The graphical user interface: I'm honestly not a big fan of the standard elements used by WxWidgets . WxWidgets is old and confusing in my eyes. It doesn't allow (at least for me) to design the software the way I would like to use it: modern, lean and clear. Nevertheless, I am aware of what the purpose of this is.

During development, emphasis was put on a clear separation of model and view (ok, kind of ...). Thus, reimplementing the view e.g. in Qt would take some time, but should be straightforward. But yes, the library is also used throughout the non-GUI code, so one would need to rewrite a considerable part.

3. "Legacy issues"
   I really thank Yannick for all that MiniPlaner can do. Nevertheless, there are some corners that are not round and which in my opinion can still take some work. See especially 4). Again, on its own no big deal. But to implement new functions and to stay compatible to old datasets appears difficult to me.

The old datasets are admittedly well readable but overly simplistic design and outdated. From my perspective it would be no problem to rewrite the way data are stored (--> MiniPlaner 3.0), with optionally a script to transform to the new format, if possible.

4. Multiple users
   In my community, many (about 20) people would need to have regular access to the software so that we can use it widely and effectively. And this is only from the servers. I almost think it would be better to have a holistic solution for everyone: The parish office creates an appointment and automatically schedules pastor, organist, lector, sacristan, communion helper and servers. Or is that too far-fetched?

In my opinion, it would make the most sense to have a web-hosted solution, which would allow interaction between planers and minis. Back in the days, that was too much effort for the targeted user group, in addition leading to hosting costs and data security issues. Self-hosted would be no option for most users.
In theory, again no big problem moving to a web gui. Would however probably mean completely rewriting most parts. There are web-based solutions like https://haneke.de/ministranten-planung-software.html or https://www.messdiener-plan.de/, which you might want to look into.

What my plan is? My big idea? No clue! While jogging a few days ago I actually thought about whether it wouldn't be more sensible to write a kind of "MiniPlaner" 2.0 in Java or even web-based. Or the existing project would have to be radically overhauled over time. Because, once again, the individual problems could be solved by us...

I know that you have invested a lot of your time and heart and soul in the last few weeks here and I would be happy to hear your honest opinion!

As stated above, in principle I agree that optimally one would move to a web-based solution, and in general to not code larger non-performance-critical projects in C++. Personally, I would not invest much time here with improving the MiniPlaner, since I have various other projects at the moment. I would however be available to assist. If you want to derive from this work on a fork or only re-use parts of it, feel free to do so.

[yannikschaelte]

To be honest I have only found MiniPlaner after I had already written AltarPlanner in the last years, which I am using myself and which produces astonishing results, but is not very user-friendly. AltarPlanner is dormant though since I am generalizing the idea of planning a roster (not only altar servers) and incorporating calendar-integration with RosterPlanner which I am designing from scratch once again with everything I have learned during AltarPlanner development (not publicly yet). Both are written in Java

Will this be a user-installed program? Is distribution via jars requiring a java runtime on the host system (sorry, bit rusted with java)?

I don't know where you are going with your planner, but in general I think self-hosted is more trustworthy for users as they know where their minis' data are, but if one invests sufficient time, then a server solution may be better in the long run.

and leverage the excellent OptaPlanner constraint solver. I currently plan using JavaFX for UI in RosterPlanner as I did in AltarPlanner, but the project is very modular and leaves the possibility for other front-ends.

Sounds like an amazing project. Sorry, did not have time yet to look into it. If you can use ideas from MiniPlaner like the scheduler, or simplifications like series masses, or anything, feel free to use those. If you have questions, I am also happy to discuss/help.

I really like MiniPlaner gaining traction as free software again though and really enjoy improving it by porting it to Linux and reworking the build and packaging system, but I won't be deploying this project myself and don't think the code base is easy to adapt to all of your proposed features.

Regarding your list:

1. While C++ has many pitfalls regarding memory management when coming from Java, I actually think that the understanding of objects and classes in Java is a big help when diving into C++. One has to get familiar with the Syntax though, but that comes with time. If you want to talk about certain concepts in C++ feel free to write me an email, and we can talk. :)

Agreed.

2. I agree that wxWidgets becomes less suitable the bigger the project becomes and I personally dislike that you often have to account for platform-differences yourself instead of having a true cross-platform library, but I don't think MiniPlaner will ever migrate to another GUI-library, as wxWidgets is deeply woven even into the planning-core of MiniPlaner. (Might be slightly off-topic, but here an interesting story about migrating dolphin-emu away from wxWidgets: The Legend of Dolphin: A Lens Between Worlds)

Agreed. From my side, MiniPlaner will not move to another library, since it works for the current users well enough, and I myself am not actively using it anymore, being out of mini service.

3. It should be possible to detect and convert old datasets if need be for a new format, don't you think?

Totally. It's basically tsvs at the moment, easy to adapt.

4. What would these many people do exactly? There is MiniInterface.php for servers to enter their absences. Do you have many irregular inputs for masses?

[mkroening]

Will this be a user-installed program? Is distribution via jars requiring a java runtime on the host system (sorry, bit rusted with java)?

Well currently AltarPlanner is being distributed via several jars and requires a JRE. In the long run RosterPlanner will be distributed bundled with a custom runtime (created with jlink) in native installers/packages (generated with jpackage).

I don't know where you are going with your planner, but in general I think self-hosted is more trustworthy for users as they know where their minis' data are, but if one invests sufficient time, then a server solution may be better in the long run.

I think so too. The main goal for now is creating a client-side JavaFX desktop application. The project is coming up very modular though, with only the GUI module depending on JavaFX, so it should be possible to write a web based front end in the future, but that's not my focus for now.

Sounds like an amazing project. Sorry, did not have time yet to look into it. If you can use ideas from MiniPlaner like the scheduler, or simplifications like series masses, or anything, feel free to use those. If you have questions, I am also happy to discuss/help.

Thanks a lot! I think I have encountered and solved most of these problems with AltarPlanner but RosterPlanner will focus generalizing and leveraging standards, like iCal for recurrences. I still have to look into the inner workings of MiniPlaner though, which could give another interesting perspective on this.