-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
My current general issues with MiniPlaner #46
Comments
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:
|
Hi, sorry for the delay. I totally understand all of your points.
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.
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.
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.
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.
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. |
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.
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.
Agreed.
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.
Totally. It's basically tsvs at the moment, easy to adapt.
|
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 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.
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. |
Hi guys,
I would like to use this to explain some of the problems I am currently having with the project. Please do not consider this to be any kind of attack or something, it's just my honest opinion...
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.
This is most definately a personal issue of mine and in itself no big problem.
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.
"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.
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?
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!
The text was updated successfully, but these errors were encountered: