Android update request -- bounty with cash payment

[IntnsRed]

I'm saddened to see that Klaus or whoever doesn't seem to want to update the Hacker's Keyboard any more.

I use the app because of its one-of-a-kind, stellar DVORAK keyboard layout -- no other reason. (?!) But unfortunately, the English completion add-on is broken, and it seems the Hacker's Keyboard is due to die an outdated death on some future "upgrade" of Android.

I've got $50 or perhaps a bit more that I'll happily contribute as a "bounty" to encourage someone (Klaus?) to update the app. I need no features or bug fixes (aside from the English completion add-on being updated to work with modern Android), just to have the app/add-on updated to work.

Any others willing to contribute a "bounty"? Perhaps we can make it worthwhile for Klaus or someone to update this fine app.

[TPS]

@IntnsRed: @ecm-pushbx has noted in #901 (comment) onwards that they've fixed a few things, including what you've mentioned. Maybe support the continued development there?

[asl97]

I use the app because of its one-of-a-kind, stellar DVORAK keyboard layout -- no other reason. (?!) But unfortunately, the English completion add-on is broken, and it seems the Hacker's Keyboard is due to die an outdated death on some future "upgrade" of Android.

If all you want is just the layout, it isn't hard to port it over to something like AnySoftKeyboard.

I ported the compact layout in just a few minutes and include the other two in a few more minutes.

I've got $50 or perhaps a bit more that I'll happily contribute as a "bounty" to encourage someone (Klaus?) to update the app. I need no features or bug fixes (aside from the English completion add-on being updated to work with modern Android), just to have the app/add-on updated to work.

Any others willing to contribute a "bounty"? Perhaps we can make it worthwhile for Klaus or someone to update this fine app.

I doubt the days worth of work and understanding the changes between android version needed to port hackerkeyboard would be worth doing for just $50.

The only kind of people who would do so are those who would are interested in getting HK working on newer version of android.

[TPS]

The only kind of people who would do so are those who would are interested in getting HK working on newer version of android.

Which is why I mentioned @ecm-pushbx, who's already done such, in spite of GPlay's artificial limiting of HK.

[asl97]

The only kind of people who would do so are those who would are interested in getting HK working on newer version of android.

Which is why I mentioned @ecm-pushbx, who's already done such, in spite of GPlay's artificial limiting of HK.

you missed the front part, "to port hackerkeyboard".

All ecm did was patch a few functions, not port it to modern android, and ecm last touched on it on Mar 2023.

master...ecm-pushbx:hackerskeyboard:master

ecm also already state he doesn't know how much work it would take to modernize the code base.

Any chance that it will be updated on Google Play?

Hi, just wanted to quickly reply. I think that the targeted Android platform version is too old for the Play store. I don't know how much work it would be to update that. I also don't know generally what is entailed in getting an app published there. This is the very first time I did any work on an Android app.

Originally posted by @ecm-pushbx in #901 (comment)

---

I am just saying @IntnsRed is better off looking for people to port the layout if that's all he wanted, chances are that it's easier to find people who know how and might even be willing to do so for free since it's mostly be a copy and paste from some part of hackers keyboard into an addon for AnySoftKeyboard.

I did the compacted layout because I wanted it and I added the 'default' and full layout to make it a 'complete-ish' pack that would satisfy what most user would be looking for.

#875 (comment)

[ecm-pushbx]

ecm also already state he doesn't know how much work it would take to modernize the code base.

*she

[SeventhM]

The only kind of people who would do so are those who would are interested in getting HK working on newer version of android.

To be fair, enough of those kinds of people exists that it may happen eventually... maybe... Idk

I got HK up to a newer version of gradle and have kinda been bumbling my way around warnings android studio gives me. Works so far, but the keys themselves don't look too great anymore. I gotta go over eventually and see what I broke. Eventually, I may see if porting from java to kotlin is worthwhile, but that'll be a ton of effort

Most of my progress will probably be on https://github.com/SeventhM/hackerskeyboard/tree/workingBranch

For the record, I've spent... basically zero amount of seconds actually reading the code and understanding what's going on... so... this might take a while before I get my version of HK up to a working standard

[SeventhM]

Ok, been working on other projects here and there, but working back on this, I think I'm at the point where I can do a progress update

• I accidentally went too fast in trying to update some of the code, and it lead to the keyboard not showing up at all. So for now I've rolled everything back and am working on updating stuff a bit slower

• Currently I'm trying to update many of the menus to the newer android libraries. Annoyingly, wherever I look it's "this got deprecated, so use this, which got deprecated, so rewrite half the code this way, which got deprecated". Some of it looks easy enough to put back together after doing some reading, some of it (namely SeekbarPerference) is a pain going through all of the information and trying to figure out what should go where since most of the functionality is expected to be split across 2-3 separate classes now

• I may have found a way to get the dictionaries working. The only problem is I have no clue where the code for those dictionaries are. It's not in Klaus's repos, that's for sure. Also, I kinda would have a few issues with the dictionaries even if I could find them

  1. They would be so old by now that I'm sure there's at least something in a more modern dictionary (or even just AnySoft's dictionaries) that it might be worth updating the word list anyways. At least, that's my viewpoint with a completely unknown way of seeing things; I have no clue how a dictionaries works. I barely know how the keyboard I'm editing works
  2. They're so old by now that they too likely would take just as long to update as anything else in the keyboard

  Whatever the case is, I would need to actually find the dictionaries in the first place to see if I can get it to work

• I managed to have the settings key crash the app. Whoops. I need to check why it's doing that (I suspect some safety change that came along with updating the app to modern standards). But that'll have to be after I finish updating all the menus and they don't crash on me by just opening

• With some of the updates, something told me I had to update the minimum supported version. Once I push the changes, I will no longer support android version before *checks notes* Android 4.4. I hope no one is running a phone that old, and if you are, please get your phone's battery checked out in case it's barely able to charge

[asl97]

AnySoftKeyboard/AnySoftKeyboard#3740 (comment)

menny commented:
The release is available on the Play Store: https://play.google.com/store/apps/details?id=com.anysoftkeyboard.languagepack.hackerkeyboardlayout&pli=1

Oh hey, would you look at that, the three basic hackerkeyboard layouts for AnySoftKeyboard I worked on is now out on the play store.

Just saying it's easier to just port the layout to another 'modern' keyboard, they just might not fully support special keys.

But then again, what apps other than rdp/vnc would need keys like f1-f12, which would be better off with a physical keyboard anyway.

[klausw]

@SeventhM - the issues you are describing are exactly the kind of thing which made me reluctant to try to update the code. The source is ancient (it's based on the Android 2.3 Gingerbread LatinIME from 2010) and a lot has changed in Android since then.

About the dictionaries, I don't remember the full history for them. If I recall, this was largely a repackaging of dictionaries distributed with Android at the time, and they are also ancient. The Ukrainian and Turkish dictionaries were external contributions, I found the following building instructions in an old mailing list message:

I've finally dug up the dictionary building tool, turns out it was already compiled as part of my Android AOSP directory. Just for future reference, the tool's source is in packages/inputmethods/LatinIME/tools/, and the binary is in out/host/linux-x86/bin/makedict .
makedict -s Dicts-src/dict-src-uk.xml -d Dicts/main-uk.dict

Overall I agree with @asl97 that it seems much more reasonable to move on to a more modern maintained keyboard.

[SeventhM]

Overall I agree with @asl97 that it seems much more reasonable to move on to a more modern maintained keyboard.

You say that as if

1. You think I'm a reasonable person. This is more or less a side project born out of frustration and done solely after seeing how to update gradle in a different app. There's nothing reasonable going on here
2. I want the layout and not the functionality. I've moved on to Gboard a long time ago and tbh there's not a lot where I explicitly need HK's layout. But arrow keys, a PC-like shift key, the home/end key, Ctrl-C/Ctrl-V is kinda the main reason I still put up with HK despite how outdated it is. Porting the layout just doesn't cut it for me, and trying to actually learn how the keyboard works to get those keys working in AnySoft likely would take a similar amount of time than copy pasting edits from stack overflow where it makes sense for the deprecated stuff. Like I said, so far, besides some stuff regarding Activities that had changes, the only deprecated thing that really a massive headache so far is SeekbarPerference because some of the code that was supposed to cover various stuff got split between two classes that aren't as easy to stitch back together as say, the old deprecated PerferenceActivity

[asl97]

You say that as if

2. I want the layout and not the functionality. I've moved on to Gboard a long time ago and tbh there's not a lot where I explicitly need HK's layout. But arrow keys, a PC-like shift key, the home/end key, Ctrl-C/Ctrl-V is kinda the main reason I still put up with HK despite how outdated it is. Porting the layout just doesn't cut it for me, and trying to actually learn how the keyboard works to get those keys working in AnySoft likely would take a similar amount of time than copy pasting edits from stack overflow where it makes sense for the deprecated stuff. Like I said, so far, besides some stuff regarding Activities that had changes, the only deprecated thing that really a massive headache so far is SeekbarPerference because some of the code that was supposed to cover various stuff got split between two classes that aren't as easy to stitch back together as say, the old deprecated PerferenceActivity

VID_20240314_032341.mp4

• arrow key - already exists
• PC-like shift - do you mean shift locking or characters (changable by layout)?
• Home/End key - it's in the quick menu, pretty sure it's addable to layout
• Ctrl+C, Ctrl+V, Ctrl+A, etc - they all works

Not sure what else specifically you need, unless you mean the f1-f12 keys, alt, super/win and other keys in the fn layout which is rarely if ever used by android apps

Just goes to show it worth trying rather than assume it doesn't exist/works, it's easier to copy paste the layout code from HK to ASK than to scout stack overflow for codes to update the code base.

[TPS]

There's nothing reasonable going on here

@klausw, & @ALL: If those of us who love & use HK were reasonable people, you wouldn't see the usage nymbers you do. HK is as much part of our psychological Android framework at least as much as our launcher or preferred device brand/model.

Reminds me of those scenes when there's a transition in royal leadership.

The king is dead! Long live the king!

[SeventhM]

• do you mean shift locking or characters

Using shift + arrow key for highlighting. Particularly, Crtl+shift+home is very common for me when making longer write-ups is one of the main reasons for switching to HK. And your video uses a gesture to access the quick menu when I'd very much perfer a button and tend to disable most gestures in most apps

• Home/End key - it's in the quick menu, pretty sure it's addable to layout

HK's extra keys menu is accessible from a clear and obvious button. You're telling me I gotta actually add this stuff separately? Also, does ctrl+home or ctrl+end work correctly?

[SeventhM]

Actually, let me clarify something to make it very clear: my goal isn't to just get what I was doing working again. This is a side project that I do because I feel like it. If anything banging my head against the wall because of AndroidX is a win-win because I get to (attempt to) learn AndroidX. I'm not really interested in the immediate solution unless you can say, for certain, that another keyboard provides one-to-one parity. Even if all the other keys worked the same, the lack of shift highlighting keys is an instant deal breaker

There's also the discussion of trying to argue what is easier or harder. Upgrading gradle versions was easy. Android Studio literally has a tool for doing it automatically and there's very little manual intervention. Converting the menus to AndroidX is relatively straightforwards once you know what to do. Even SeekbarPerference was somewhat simple once I got the right link and it's just some particulars I have to sort through to get it working because of how it expects you to split the functions and how HK uses it in a way that some seem not to. Moving to AnySoft is more *reasonable* because all it would be is the layout with most of the rest of the maintenance handled for you. Moving to AnySoft wouldn't necessarily be easier, though with the exception of a few fringe cases, some of which I'd rather the challenge and knowledge I'd gain working on HK anyways

I know you want to talk about the work you've done that you're proud of, but we have very different end goals

[asl97]

And your video uses a gesture to access the quick menu when I'd very much perfer a button and tend to disable most gestures in most apps

Do you see that smiley button? that open the smiley keyboard.
you can add a button to open specific keyboards.

you don't even need to use the quick menu, just add the home and end button directly to the keyboard in the layout

HK's extra keys menu is accessible from a clear and obvious button. You're telling me I gotta actually add this stuff separately?

you make it sound like HK's extra keys menu isn't a layout and just exists.

fun fact, it is a layout and it didn't just exists in android, 'this stuff' was created and added by HK 'separately': https://github.com/klausw/hackerskeyboard/blob/master/app/src/main/res/xml/kbd_compact_fn.xml

so of course if you want the layout, it need to be copy over, which I didn't see much point since the whole set of Fn keys doesn't work and I didn't want to hurt the likelihood of getting the basic layout merged into ASK.

I know you want to talk about the work you've done that you're proud of, but we have very different end goals

That sounds more like you, ie wanting to talk about your work, you clearly have different end goals from OP (@IntnsRed) which seem very clear to be layout specific and not functionality.

I use the app because of its one-of-a-kind, stellar DVORAK keyboard layout ... English completion add-on

[SeventhM]

fun fact, it is a layout and it didn't just exists in android, 'this stuff' was created and added by HK 'separately'

Am aware, but the functionality of the shift key isn't a layout, the possibility to open from a notification (assuming I get that working) isn't a layout. Finding weird uses of some of the extra keys (did you know most browsers, even on mobile, accept f5 correctly) isn't a layout. And again, if the only goal here was learning what could be an upgrade, that's counted as a win in my books

That sounds more like you, ie wanting to talk about your work, you clearly have different end goals from OP

Ok, but I, and ecm's previous post, made it pretty clear we're looking to update the *app*, not the layout. I've mentioned multiple times I barely even took any amount of time trying to figure out how the keyboard even works. I'm not going around trying to push people onto AnySoft any second they get. You're the one trying to argue with me on what is the correct move here when I made it plenty clear I don't really care about that. You're the one trying to push your PR to AnySoft when I've deliberately not made an apk and have explicitly made clear it'll take me time before I'm done. You're the one trying to push what I should or shouldn't be doing when I'm just out here noting where I am on updating HK

[asl97]

Am aware, but the functionality of the shift key isn't a layout

It just a shift key, it's not magic

Finding weird uses of some of the extra keys (did you know most browsers, even on mobile, accept f5 correctly) isn't a layout.

keyword 'some', it depends on the app implementing handling of those extra keys, HK isn't doing anything special, it just passing the keycode

If an app doesn't handle f5, no amount of change to HK is gonna make f5 magically works.

just saying it isn't a layout is dumb cause it is just a layout on HK.

If it isn't working on ASK, it's probably because it's doing something stupid or it doesn't handle and pass the keycode on properly.

Ok, but I, and ecm's previous post, made it pretty clear we're looking to update the app

That's just what you want and not what this issue is really about, let me point out the key part again.
#939 (comment)

I use the app because of its one-of-a-kind, stellar DVORAK keyboard Layout ... English completion add-on is broken ... due to die an outdated death ... just to have the app/add-on updated to work.

Here it is again in point form, what the issue is asking for

• Specific DVORAK Layout
• Working English completion
• still being updated app that shouldn't just die soon

I made it plenty clear I don't really care about that. You're the one trying to push your PR to AnySoft when I've deliberately not made an apk and have explicitly made clear it'll take me time before I'm done.

you clearly don't care about what this issue is about

You're the one trying to push what I should

Am I really?

when I'm just out here noting where I am on updating HK

When I'm just out here noting that contributing to ASK isn't a deadend and most likely the easier path to address not only OP needs, but also reaches the play store.

In case you didn't notice, menny posted his/her comment within 24 hours of mine, I was merely posting an update on what happen to said mentioned HK layout port on ASK.

My comment was in no way adressing to yours and it's yours whose implying ctrl+c and ctrl+v and such doesn't work on ASK.

#939 (comment)

get those keys working in AnySoft

Only then did I post a comment address a comment from you

---

Also Dvorak on AnySoftKeyboard

AnySoftKeyboard/AnySoftKeyboard@main...asl97:AnySoftKeyboard:Hacker_Keyboard_Pack

[SeventhM]

It just a shift key, it's not magic

Yes, but that key is probably the key that I need working if you're to say "just move to a different keyboard". Again, that not working is an instant dealbreaker; any advantages HK or ASK has over that or far more niche in my eyes over Gboard and isn't worth caring about. And frankly, a half functional HK still has a better layout in my eyes over ASK, so I'm just not interested in the suggestion to just move on

Here it is again in point form, what the issue is asking for

If your point here is "you're off topic" then just say it directly and let's not waste people's time. I never implied in any way whatsoever that I was focused on getting the layout working, so arguing this point down on me is a waste off time. This very clearly comes off as telling me what I should or should not do with my own fork of HK.

Only then did I post a comment address a comment from you

And then I gave you my response: I don't care. Simple as that. Worst care, I get to learn more about the backend, have an extra project to fill time. Best case, I resurrect an old keyboard from the grave, even if it's just on my own phone for me. You're the going on and on and on that this works in ASK or that works in ASK and talking past me. My simple response to you is simply "I don't give a damn, I'm working on my project". If the goal is to push me out to stay on topic, that's fair. Otherwise, you're the one pushing your work in ASK as if I should care, as if my goals lines up perfectly with OP's or even as if OP necessarily will switch to ASK just for your layout. I didn't respond to you, I responded to Klaus. If you're goal was to give your thoughts on what the op should do, you've already done your part, and this argument with me is a complete waste of time. If your goal is to try to push the idea that my efforts isn't needed, well, I don't care, I'm working on my fork of HK anyways, so go away and go bother someone else

Btw

• Specific DVORAK Layout
• Working English completion
• still being updated app that shouldn't just die soon

Let's talk about that

1. Your PR was merged on September 23rd, 2023. It only got published Yesterday, March 12th, 2024. If I literally started working by the time this issue started, I genuinely probably could've gotten a working build faster than ASK could've published your layout, and that's despite you having a major head start. Most of time has been spent doIng other stuff like updating Unciv or playing some other game or whatnot. If your viewpoint on the subject is solely about these three points, then the only counterargument against work restarting in someone's fork (similar to the situation with Cromite) is a question of whether I or anyone else will actually commit to updating their fork as time goes on
2. ASK hasn't had new publish since January 2022, and their last play store update dates to November 2021. I'm sorry, but there's plenty of Chromium browser clones or basic file managers or basic music players or whatever that does nothing but release their app year after year to keep up with the time. Even the aging barely functioning Dolphin Browser can pretend to update every year. If it wasn't for a thread like this, I would've assumed ASK is just as dead as HK. So if your suggestion is just "go use ASK, its newer", I'm going to ignore you. And if that was your viewpoint before yesterday when your layout actually got published, then you're telling a likely non-programmer to go doing something that they'll likely never do given how daunting someone might view just trying to find the layout. Hell, I can only find the layout because I have to pass by the file a few times, and even then I haven't entirely memorized which folder it is
3. That third point seems mighty assuming that "newer" means "appstore". TPS mentioned ecmpushbx's work and OP was never seen again. Who are you to say what they mean by a newer version for a more modern Android? If you want to position yourself as an alternative to a project like mine, go ahead. But I'm updating HK, simple as that, so arguing with me about what I'll do is a waste of time

[SeventhM]

Progress report:

• Decided to ignore my nemesis SeekBarPreference
• In theory, I have an easy way to convert PreferenceActivity to something that works with androidx.
  1. Convert them to FragmentActivity (I needed a function out of it, that's why I'm using it instead of Actitvity. I'll get back to that).
  2. Add subclass that extends PreferenceFragmentCompat. The standard practice is for it to contain something like

  @Override
      public void onCreatePreferences(@Nullable Bundle savedInstanceState, @Nullable String rootKey) {
          setPreferencesFromResource(R.xml.prefs, rootKey);
      }

  3. In the main class, give it a variable that has the fragment. In onCreate, standard practice is to run

      getSupportFragmentManager().beginTransaction().replace(android.R.id.content, fragment).commit();

• Problem 1: Uh... We can't do anything else with the fragment right now. fragment.getContext is not done initializing until the activity's onCreate function is done. We gotta wait until something like onResume before we can finishing initializing... Assuming this is the right way to do it
• Let's take a break and talk about SeekBarPreference

The problem with this file is that it extends DialogPreference. I don't know the technical details, but starting with androidx, this got split into two separate files: PreferenceDialogFragmentCompat, which handles user input, and DialogPreference, which handles the actual code. Quick problem: the two functions that were left to PreferenceDialogFragmentCompat both actually handle the underlying code. And being as lazy as I am, I don't feel like figuring out where this stuff should properly go. I was thinking this over when I realized... The proper way of handling this is just having PreferenceFragmentCompat (remember, from our previously Preference activities) handle this as so:

        @Override
        public void onDisplayPreferenceDialog(@NonNull Preference preference) {
            if (preference instanceof SeekBarPreference) {
                DialogFragment dialogFragment = SeekBarDialog.newInstance(preference.getKey());
                dialogFragment.setTargetFragment(this, 0);
                dialogFragment.show(getParentFragmentManager(), getTag());
            } else super.onDisplayPreferenceDialog(preference);
        }

Note, the setTargetFragment line is deprecated. I'll investigate later, I just want the settings menu to open at all. This means any time we're creating a new instance of the Fragment, we also always have the DialogPreference. Nice. I have no clue the proper way of having it, but, I'm just going to lazily pass in the perference and call it a day. One more thing off the checklist to fix. Back to bullet points on my progress

• Problem 2: Uh... HK doesn't use a theme for it's menus. This sounds like a minor problem, but actually it crashes the app because we used getSupportFragmentManager() which really wants an app theme to support older devices. I can look into how to use getFragmentManager() (and then I don't even need FragmentActivity, I can just use Activity directly), but it is an interesting question of which devices I do or don't support by doing so. Something I need to look into

TLDR;

1. Most of the hard work in getting the menus running is done
2. SeekBarPreference is dealt with. I can finally move on to other stuff (such as tracking down some of the resources. Complicated story
3. I misjudged the problem with dictionaries. Looking and ecm's work there is interesting. I'll definitely copy some of their work before I push to GitHub. For the record, what I noticed was Android Studio whining about nonfunctioning JNI references. Not sure if the issue is how to link them changed over the years to just be easier or what, but I linked them back up already
4. I can probably push my changes tomorrow if someone wants to review my changes and/or wants to build the app. Pretty sure the settings key will still crash the keyboard, though... Still need to look into it

[SeventhM]

Progress report: Ok, actually, looking at where I am and how much I have done, there's very little actually left to fix that's actually noteworthy. I might just throw an apk on my fork, make an issue about steps to upgrade (in case someone wants to know what's going on in my fork), and then carry on with what I was doing. The main thing that makes me less interested in fix more minor stuff is just that some of the code google deprecated but never actually made a good alternative for (specifically the "setTargetFragment" line in my last update), and more or less there genuinely isn't much left to work on besides bug fixing, maybe some layout stuff, and maybe some conversions from inches to actual pixel sizes (something I did before I reset my work but it looked awful the first time I tried

I'm currently looking into to seeing how much effort converting to Kotlin might be. Seems like auto-conversion is more or less going fine, very few stuff needs manual edits (often times just turning stuff into lateinit variables). Though looking at the code... Man do I like Kotlin so much more than Java. Much cleaner language imo

I still need to actually take the time to hunt down the dictionary situation. I have mostly been only doing tests on a backup phone where I hadn't already had the old English completion dictionary. Now that the app is a bit more stable, I'll probably install it on my main phone that does have the old dictionary. I doubt it'll work, but who knows

Lastly, it doesn't look like I can solve the problem of being unable to open the keyboard from a notification. Most likely, I'll have have to make use of accessibility settings now. I need to spend some time researching some other keyboards that do something of the sort, especially since Julow/Unexpected-Keyboard#497 gave up halfway. That'll take much more time

[TPS]

If interested, follow @SeventhM's updates @ SeventhM#3