changed factorial to reciprocal and keypad change

[FrankBuss]

I think most people need the reciprocal function more often than the factorial function. This pull request changes this.

Another change: now it is faster to use it like a normal calculator for single argument functions, no need to hit the enter key again. Example of the old behaviour (brackets are used for buttons and the enter key) :

1+2 [cos] [enter]

New behaviour:

1 + 2 [cos]

The result is only calculated, if the full expression was selected, otherwise it is the old behaviour, that the function is only inserted, in case you want to insert more.

The last different to a "normal" calculator is fixed with the second commit: if you enter "90 [sin]" on a normal calculator, it calculates the result. With Qalculate you had to enter "[sin] 90"
Still a minor difference to a normal calculator: If you enter "10 [cos]", it doesn't work, you have to enter "[cos] 10 [enter]". This is fixed now, you can enter "10 [cos]" and it shows the result.

Note that I don't have experience with GTK, so maybe take a look at it if the code looks good, and then accept the pull request, if you like the changes. And I didn't check it in RPN mode, and maybe there are other side effects for it which I'm not aware of, but at least works for me, now I can use it as a replacement for kcalc.

Maybe would be a good idea to allow to configure the keys, or some spare keys? A user could then configure a factorial key, if needed, or any other function.

[hanna-kn]

I liked your ideas and I have merged your code.

I have afterwards altered the is_number function to first unlocalize expressions (to allow different decimal marks) and allow negative numbers. Also, the text cursor most now be at the end of the expression for keypad functions to act on numbers. I am not sure in exactly which situations this behaviour is desirable.

Your changes do not affect the RPN mode.

I have previously decided to keep the keypad simple as it should in most situations be more efficient to just use the keyboard (although the situation might be different with touchscreens).

[FrankBuss]

Thanks. Right, for a touchscreen it might be useful to have a customizable keypad. An iPhone version would be cool, but looks like there is no GTK for iOS, and Apple might not like it anyway, but would prefer their look-and-feel, with the swiping menus etc. Would be a complete new project, but some components could be refactored and extracted to be used from the GTK and the iOS version, like how the user interacts with the expression field and the buttons, or the formula renderer.

[hanna-kn]

I've got (early) plans for an Android version. It would be with an entirely new GUI.

The biggest challenge is to make libqalculate more platform-independent. The dependency on glib and CLN needs to be removed.

[FrankBuss]

If you use Qt, it would run on Android, iOS, Linux, Window and Mac, without changes (I've used this in many cross platform projects for Linux/Windows/Mac and it really needs no source code change). But you are right, might still need some changes for mobile phones, because of different GUI styles the user expects.

Don't know if CLN is a problem. Looks like some people compiled it for Windows, so should be fairly portable. Removing glib dependencies might need more work. Many features like date functions etc. are really nice and easy to use in Qt, but might be bad, if libqalculate depends on the Qt framework.

[hanna-kn]

qalculate-gtk is already available for Mac OS and there is an old fork that runs on Windows. GTK, along with a long list of dependencies, can with some effort be compiled for Windows.

I've written another application (Eqonomize!) with Qt as only dependency and it compiles and runs without problem on Windows and Android, but the traditional UI really does not fit Android.

A future cross-platform version of Qalculate! will likely use Qt instead of glib (which is only used in a few places in the library code) and some UNIX-specific code. It should be possible to make the use of Qt or glib a compile-time choice. The GUI will also probably use Qt, but not the traditional widgets. GMP will be used directly instead of CLN.