Yes I agree and I'm aware of the situation. Especially it is hard for V2 users.
Our real power is the simplicity. V3 is not easy to configure yet but simple. Once you get the idea it gives a lot of possibilities. We have a lot of small pieces that needs to be connected to build something. Before adding a feature I'm thinking twice (even more) if it can be done by using current features. If so I don't add additional features. That creates an abstraction and this is the reason of the complex configuration.
Look how I removed payment buttons and used automation commands instead. Ironically instead of writing code I've deleted code to implement the request and the reason of that change was the settle button. As you know we are using portrait mode for handheld devices and one of our users asked to disable settle button on tablets. Uh? In fact it can be solved easily by adding a simple setting to disable settle button but I know this is only the tip of the iceberg. They'll want settle button for managers or some people just don't want it at all. This is already possible with automation commands because of the wide mapping features so instead of adding that simple setting I've deleted whole code and switched it to commands. As a result of that code removal we gained bonus features. For example we can disable settle button for specific ticket states to implement proper workflow. Of course some users complained because of this change because creating a fast payment button was a single click. Now it needs a lot of configuration. I know it....
It can be easier with tooling as you suggested. What we need to do is just auto generating required data.
We used similar idea for menus or other areas at "Batch Create XYZ" screens. For example a "Batch Create Tax" tool can create required account templates, accounts and transaction templates from entered Tax Configuration lines. Instead of wizards I thought tooling should be text based so it can be shared. We are using this text file idea for generating default menus and tables on installation. That just needs improvement. At the end we can have a single text file for whole configuration. Even for rules, actions etc.. This is what called as DSL. You can read more about the idea here
http://www.primaryobjects.com/CMS/Article127.aspxHowever my current priority is the infrastructure. When I add features for ease of use before finishing the infrastructure I have to delete it later so that creates waste. Before implementing hammer I have to be sure nail works fine.
I hope we can have little more development, financial and social power to implement all ideas quickly, generate documentation and of course influence people. I don't like having undocumented code, undocumented features and a lot of missing other things too. When I first started SambaPOS I decided to give priority to "requests". We have thousands of installs but for me real SambaPOS user count is not more than 20. I thought if I can solve their problems I can solve everybody's problems. As a result three years of community interaction brought us here. I don't know yet if it was a bad idea or not but I believe we're still on the right track.
Sorry for the long post. I thought I have to explain my thoughts so we can create better solutions. Thank you for reading it.
