intfiction.org

The Interactive Fiction Community Forum
It is currently Thu Dec 14, 2017 10:13 am

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 48 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Fri Aug 11, 2017 9:34 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
chrisryan wrote:
Shifting focus between input elements would still trigger the soft keyboard, I believe.


Your statement isn't making sense to me. As I (speculate) understand the issue, the sequence is this:

1. User is at > prompt of story, types in "go west", sent to Glulx to advance the story turn / frame
2. input element removed or focus to nothing by the web app
3. Android OS responds by hiding the keyboard
4. Glulx responds with next turn / frame of the story to draw
5. input element is added + focus put on input by the web app
6. Android OS responds by activating the keyboard at the newest > prompt

I'm suggesting step 2 changes: shift focus to another input field on the HTML page. Changing focus between two input fields of an HTML page, like using [tab] key on a keyboard when entering a username and password for login to Amazon.com - does not make the keyboard hide and reappear.

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 9:45 am 
Offline

Joined: Fri Jul 28, 2017 9:04 am
Posts: 32
I see what you're saying, however your description can't be the entirety of the issue, because it gets stuck in a hide/show loop that persists after the input is recreated and the next turn has been rendered. It would not actually be a big issue if the keyboard hid and showed again one time between turns, IMO. Annoying, but not unplayable.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 9:48 am 
Offline

Joined: Tue Jul 28, 2015 1:05 pm
Posts: 1008
I believe that none of these issues occur with parchment (for z-machine games). Have you tried looking at parchment code?

_________________
-My IFDB name is Mathbrush.

Anyone can make interactive fiction; if you've made a game and need a review on IFDB, let me know!


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 9:51 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
chrisryan wrote:
I see what you're saying, however your description can't be the entirety of the issue, because it gets stuck in a hide/show loop that persists after the input is recreated and the next turn has been rendered. It would not actually be a big issue if the keyboard hid and showed again one time between turns, IMO. Annoying, but not unplayable.


You and I are on different pages. 1) The prompt of City of Secrets and similar that goes crazy. 2) Other 'routine stories' that don't have the crazy behavior, but I still noticed briefly that the keyboard goes away and comes back in routine interaction.

To describe #1 crazy behavior there would be more than the 6 steps going on. But the general issue I'm raising could be the same: Is the input field being removed, disabled, or otherwise? On a hard keyboard / USB / Bluetooth - that works OK, but on a soft keyboard with Android - that's possibly the problem: Android believes there is no need for the keyboard any more.

At this point, what I'm asking for clarity on: What happens to the HTML input field after a user types in a response and presses [enter] key. Is it being removed, disabled, what?

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Last edited by allensocket on Fri Aug 11, 2017 10:01 am, edited 1 time in total.

Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 9:59 am 
Offline

Joined: Fri Jul 28, 2017 9:04 am
Posts: 32
I see, thanks for the clarification.

Maybe lines 727-766 in the update function of glkote.js are involved?


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 10:02 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
craiglocke wrote:
I believe that none of these issues occur with parchment (for z-machine games). Have you tried looking at parchment code?


Not recently. However, I would point out that the issue with Z-machine is that they are almost always "classic two-window layout". This is why a lot of interpreters don't support .z6 stories. And why Android had gone a decade with little to no ability to run Glulx stories - because once you get into Glulx stories like 2010's Best of Three - you have to get much more into Glk features like timers, multiple windows, multiple input sources, etc. Android apps like Son of Hunky Punk, Twisty 1, Text Fiction, etc - all only support two windows, and only one of those windows takes input. That one window can also be practically any size. It becomes much more complex once you have 8 windows in defined places on the screen and multiple places to put a cursor or mouse.

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 10:08 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
chrisryan wrote:
Maybe lines 727-766 in the update function of glkote.js are involved?


Looks like the relevant code. I have not looked at it before. We could sprinkle console logging into each of these functions.

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 10:15 am 
Offline
User avatar

Joined: Wed Oct 14, 2009 4:02 am
Posts: 2436
Whether the keyboard should be hidden after you've entered a command or hidden and then shown only when you tap the screen is a personal preference. Some prefer to have it always visible, others prefer to maximise the space on their phones for reading. Ideally the terps would let you choose.

That's a separate matter from the race conditions shown in City of Secrets. I'd recommend filing a separate issue for the first, but leaving it to be dealt with after the much more serious buggy behaviour of the second is fixed.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 10:18 am 
Offline
User avatar

Joined: Fri Sep 30, 2016 7:02 pm
Posts: 404
Location: USA
Dannii wrote:
Whether the keyboard should be hidden after you've entered a command or hidden and then shown only when you tap the screen is a personal preference. Some prefer to have it always visible, others prefer to maximise the space on their phones for reading. Ideally the terps would let you choose. That's a separate matter from the race conditions shown in City of Secrets.


Social gate-keeping here? Since the six steps I was discussing before happen extremely fast, keyboard goes away, keyboard comes back - like on the order of 1/100th of a second, why do you think it's not a relevant discussion? I can't imagine user preference to flap the keyboard and flash the screen. The discussion I initiated was about a proposed fix of having a hidden input control and setting focus to it if indeed there is no input field at all set with focus (which is still an 'unconfirmed theory' as to the behavior I'm witnessing and trying to interpret conceptually).

_________________
Glulx interpreter Android apps are in open beta testing! Three apps to watch for: Incant!, Thunderword, and Thunderword enhanced Text Fiction.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Fri Aug 11, 2017 10:24 am 
Offline

Joined: Sat Jan 23, 2010 4:56 pm
Posts: 5507
Quote:
At this point, what I'm asking for clarity on: What happens to the HTML input field after a user types in a response and presses [enter] key. Is it being removed, disabled, what?


(This is about traditional single-window line input.)

The input element is removed at the accept_inputcancel() stage and then a new one is created at the accept_inputset() stage. These are called from the same function (glkote_update), so there's no time interval in which the browser presents a DOM with no input line. However, mobile browsers are obviously still uncomfortable with it.

I guess the direct solution is to keep the input element in the DOM and just move it. I'm not sure if that will actually work, however. The discussion of the CoS-character-input case seems to imply that jQuery's implementation of "move an element within a DOM" will still cause a keyboard close on Android!


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 48 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group