[free42] Bugs and feature requests

[SammysHP]

Just a minor issue: I found an inconsistent behavior of back in the printout in 2.0.22c. Usually the back action is executed on release, but in the printout already on press.

In addition of tapping on the LCD, what about adding a new entry to the calculator function list to open the native menu? Or even better: Adding the top level functions of the native menu to a new menu in the calculator? This would remove some issues related to different versions of Android and also allows a more consistent user experience (on the same platform by not leaving the simulated calculator and even between different platforms because there are less native menus). Also it adds the ability for example to open the printout programmatically.

[Thomas Okken]

(01-27-2019 01:56 PM)SammysHP Wrote:  Just a minor issue: I found an inconsistent behavior of back in the printout in 2.0.22c. Usually the back action is executed on release, but in the printout already on press.

That has got to be the most nit-picky Free42 bug report ever. I like it. Unfortunately, I don't know how to fix that in a way that would work in all Android versions back to 2.2. If any Android expert can enlighten me, I'm listening.

(01-27-2019 01:56 PM)SammysHP Wrote:  In addition of tapping on the LCD, what about adding a new entry to the calculator function list to open the native menu? Or even better: Adding the top level functions of the native menu to a new menu in the calculator? This would remove some issues related to different versions of Android and also allows a more consistent user experience (on the same platform by not leaving the simulated calculator and even between different platforms because there are less native menus). Also it adds the ability for example to open the printout programmatically.

The whole point of the new main menu is that it should work, and work the same, on all versions of Android, old and new, including oddballs like the Amazon Fire HD. Are you saying it doesn't?

[SammysHP]

(01-27-2019 10:25 PM)Thomas Okken Wrote:  Unfortunately, I don't know how to fix that in a way that would work in all Android versions back to 2.2. If any Android expert can enlighten me, I'm listening.

Usually activity switching via back works automatically. I'll look into the code when I have time.

(01-27-2019 10:25 PM)Thomas Okken Wrote:  Are you saying it doesn't?

Probably it will work (cannot verify because I have not so many versions of Android available for testing). The idea is to remove the break between the simulated environment and the native host with respect to user experience. Similar to a VR world were you don't want to be interrupted by text menus.
I think I will have to look at the code to see how difficult it would be to mix platform specific code with the core, but it already happens for the location function so it might be easy.

[SammysHP]

(01-27-2019 01:56 PM)SammysHP Wrote:  Just a minor issue: I found an inconsistent behavior of back in the printout in 2.0.22c. Usually the back action is executed on release, but in the printout already on press.

First of all, after looking at the code I realized that there is just a single activity and the code switches between different views.

Code:


    public boolean onKeyDown(int keyCode, KeyEvent event) {
        if (printViewShowing && keyCode == KeyEvent.KEYCODE_BACK) {
            doFlipCalcPrintout();
            return true;
        } else {
            return super.onKeyDown(keyCode, event);
        }
    }

It might be enough to use onKeyUp().

(01-27-2019 01:56 PM)SammysHP Wrote:  In addition of tapping on the LCD, what about adding a new entry to the calculator function list to open the native menu? Or even better: Adding the top level functions of the native menu to a new menu in the calculator?

Actually this might be harder than I originally thought, because the relevant code is distributed between the core and the shell. But nevertheless the code is cleanly structured and an extension should be possible.

The first question is, what should be implemented exactly?

• Just a function to open the menu? NMENU, docmd_open_native_menu(), shell_open_native_menu()
• Or a function that opens a submenu with all menu commands?
• Or functions for specific functions?
  • Open printout: SPRNT, docmd_open_printout(), shell_open_printout()
  • Clear printout: CLPO, docmd_clear_printout(), shell_clear_printout()
  • Open preferences: PREFS, docmd_open_prefs(), shell_open_prefs()
  • Copy: COPY, docmd_copy(), shell_copy()
  • Paste: PASTE, docmd_paste(), shell_paste()
  • Open menu (for everything else): NMENU, docmd_open_native_menu(), shell_open_native_menu()
    

Some of these (like NMENU, SPRNT) could be added with FLAG_NO_PRGM (that should prevent the function from being used in a program?), while others (COPY, PASTE) might be helpful in programs (automatically copy a result to the clipboard).

The second question: Are you even interested in such additions? Some are just eye candy (stay in the virtual calculator for some actions), but others (copy, paste) are useful functions in some scenarios.

PS: When I have time I will try to fix my Android development environment that I sadly haven't used for years and will try to build free42 for Android myself.

[Thomas Okken]

(02-02-2019 11:16 AM)SammysHP Wrote:  It might be enough to use onKeyUp().

Yes, that sounds right. I could override onKeyUp() and onKeyDown(), too, using the latter to swallow the key-down on the back button, probably unnecessary, but it might be a good idea to prevent the framework from getting confused. Or maybe it would have the exact opposite effect. A bit of experimentation is probably needed.

There is a callback onBackPressed() or something like that, which takes care of all this confusion, but unfortunately it was introduced in Android 5, and Android 4 is far from dead so shouldn't just be ignored.

(02-02-2019 11:16 AM)SammysHP Wrote:  The second question: Are you even interested in such additions?

I don't think pulling shell functionality into the core will be an improvement.

[SammysHP]

(02-02-2019 12:21 PM)Thomas Okken Wrote:  I don't think pulling shell functionality into the core will be an improvement.

Understandable (although having access to the clipboard programmatically would be fantastic).