Androwish and my toy program

[Bill Waddington]

Hey again,

First, is there an Androwish newsgroup? My newsreader (and I) can't
find it if it's out there.

Second, I show up here every 5 or 10 years and scribble up some tcl/tk
code... and ride off into the sunset. I don't have the vocabulary to
even ask the questions properly - and I apologize for that.

Even so, I've received exceptional and generous help here - and no
good deed goes unpunished ;)

My KanjiQuiz code seems to run fine in windows - either straight-up
tcl or via FreeWrap. I've taken a quick shot at a stand-alone apk
with AndroWish. It actually works, but...

On my Lenovo Yoga Tab 3 Pro, any button press turns a button white,
and it stays that way until some other button is pressed. This
doesn't happen in either approach on windows.

I do see something perhaps related on Ubuntu. A button turns white on
mouse-over - whether clicked or not - and shows the expected color
when the mouse moves away. This isn't particularly desirable, but at
least buttons aren't stuck on white.

I'll keep exploring that in case it leads me down the right path - but
if this rings a bell with anyone, I'd appreciate hearing about it.

Code available via this page. Not asking anyone to dig into it - but
certainly wouldn't mind ;)

http://www.beezmo.com/geezblog/?p=1842

thanks and regards,
Bill
--
William D Waddington

"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

[undro...@gmail.com]

Bill,

a q'n'd workaround could be to add the line

event generate .kq.guessbutton$buttonindex <Leave>

right after where the button's background color is changed in order to force a mouse leave event to switch off the active color.

Maybe it makes sense to enter a ticket in www.androwish.org

Best regards,
Christian

[Roderick]

On Wed, 10 Oct 2018, Bill Waddington wrote:
>
> On my Lenovo Yoga Tab 3 Pro, any button press turns a button white,
> and it stays that way until some other button is pressed. This
> doesn't happen in either approach on windows.

In FreeBSD with (self compiled) Tcl 8.6 the background of button
gets white when the cursor on it, and only in this case. All seems
to work as intended.

The problem I have is different: a lot of Kanjis are not represented by
font.

Nice educational toy programm! :)

Rodrigo

[Rich]

Bill Waddington <william.w...@beezmo.com> wrote:
> On my Lenovo Yoga Tab 3 Pro, any button press turns a button white,
> and it stays that way until some other button is pressed. This
> doesn't happen in either approach on windows.
>
> I do see something perhaps related on Ubuntu. A button turns white
> on mouse-over - whether clicked or not - and shows the expected color
> when the mouse moves away. This isn't particularly desirable,

It is standard UI practice (or at least was, before Google/Apple ruined
UI practice with their colorless, borderless, invisible 'material'
design ideas). The subtle color chage is to indicate to a user that
their mouse has entered a 'clickable zone'.

> but at least buttons aren't stuck on white.
>
> I'll keep exploring that in case it leads me down the right path -
> but if this rings a bell with anyone, I'd appreciate hearing about
> it.

You are almost there.

Check out the 'options' manpage, and look at the definition of the
-activebackground and -activeforeground options.

It would appear that your tablet is causing Tk to believe there is a
mouse cursor hovering over the button after a finger press, and so Tk
applies the two 'active' colors to the button.

I see at least two possible fixes (there may be more)

1) figure out how to get the tablet to stop pretending there is a
hovering mouse cursor at the location of a finger press

2) when on Android, reconfigure the active colors to be identical to
the non-hovering mouse colors (continue reading the options man
page for details) and then, even on android, when there is a
virtual hovering mouse, you won't have a white color showing up.

[Bill Waddington]

On Wed, 10 Oct 2018 12:45:19 -0700 (PDT), undro...@gmail.com wrote:

Hi Christian,

I'll try the q'n'd and consider entering a ticket. "Ticket" sounds
serious. Is it appropriate for asking questions, or is it normally for
bug reports?

I'm nowhere near qualified to call this a bug. More likely PEBKAC on
my part ;)

Thanks much for your help - and for helping me out over on the Lenovo
forums with my last toy. Years ago... Very kind of you.

[Rich]

Roderick <hru...@gmail.com> wrote:
> The problem I have is different: a lot of Kanjis are not represented
> by font.

This may not be Tcl related, but rather may be that your font file
simply does not have glyphs for those characters.

[two...@gmail.com]

On Wednesday, October 10, 2018 at 11:53:10 AM UTC-7, Bill Waddington wrote:

> On my Lenovo Yoga Tab 3 Pro, any button press turns a button white,
> and it stays that way until some other button is pressed. This
> doesn't happen in either approach on windows.
>

I've used androwish for a few years now, and from the beginning I questioned the unnatural look of a button push. I wondered how anyone could not notice that.

I found that until you do something to some other widget, the buttons stay stuck on the button down color.

I resolved this with an ugly hack - I use introspection to find and modify the -command attribute of all my buttons to add a prefix command that changes the pushed button from enabled to disabled and back with a 100 ms delay between them. Then, the horror, I issue an update command. This does correct the look, though I suspect there's a gotcha somewhere in there by forcing with the update. Still, it works for me.

[Bill Waddington]

On Wed, 10 Oct 2018 12:45:19 -0700 (PDT), undro...@gmail.com wrote:

>Bill,
>
>a q'n'd workaround could be to add the line
>
> event generate .kq.guessbutton$buttonindex <Leave>
>
>right after where the button's background color is changed in order to force a mouse leave event to switch off the active color.

...

The event q'n'd works wonderfully! Yay! I haven't fixed all the
buttons yet but a quick test on the guess buttons worked :)

Now to deal with the mouse-over thing. Maybe can change to depressed
or something else that doesn't toggle the color.

thanks!

[Bill Waddington]

On Wed, 10 Oct 2018 13:24:31 -0700 (PDT), two...@gmail.com wrote:

>On Wednesday, October 10, 2018 at 11:53:10 AM UTC-7, Bill Waddington wrote:
>
>> On my Lenovo Yoga Tab 3 Pro, any button press turns a button white,
>> and it stays that way until some other button is pressed. This
>> doesn't happen in either approach on windows.

...

>I found that until you do something to some other widget, the buttons stay stuck on the button down color.

Christian's "event" quick-and-dirty fix (up-thread) worked for me.
Maybe give that a try?

[Rich]

Bill Waddington <william.w...@beezmo.com> wrote:
> On Wed, 10 Oct 2018 13:24:31 -0700 (PDT), two...@gmail.com wrote:
>
>>On Wednesday, October 10, 2018 at 11:53:10 AM UTC-7, Bill Waddington wrote:
>>
>>> On my Lenovo Yoga Tab 3 Pro, any button press turns a button white,
>>> and it stays that way until some other button is pressed. This
>>> doesn't happen in either approach on windows.
> ...
>>I found that until you do something to some other widget, the buttons
>> stay stuck on the button down color.
>
> Christian's "event" quick-and-dirty fix (up-thread) worked for me.
> Maybe give that a try?

Just change the color for the -activeforeground and -activebackground
options to be the same color used for -foreground and -background
respectively.

Then the color won't change (well, it will, but it will change to the
same color that was already there, so you won't see a difference).

[Bill Waddington]

On Wed, 10 Oct 2018 15:13:14 -0700, Bill Waddington
<william.w...@beezmo.com> wrote:

>On Wed, 10 Oct 2018 12:45:19 -0700 (PDT), undro...@gmail.com wrote:
>
>>Bill,
>>
>>a q'n'd workaround could be to add the line
>>
>> event generate .kq.guessbutton$buttonindex <Leave>
>>
>>right after where the button's background color is changed in order to force a mouse leave event to switch off the active color.
>...
>
>The event q'n'd works wonderfully! Yay! I haven't fixed all the
>buttons yet but a quick test on the guess buttons worked :)

...

Oops. Spoke too soon. The event addition does solve the problem of a
button sticking at white until something else pressed - but it
introduces another problem :(

Once I generate a leave event on a button it goes unresponsive to
another click until the mouse moves out and back in (Windows) or
another button pressed (Android). Well - not quite unresponsive. A
2nd click turns it white until mouse moved out.

digging...

[Rich]

Bill Waddington <william.w...@beezmo.com> wrote:
> On Wed, 10 Oct 2018 15:13:14 -0700, Bill Waddington
> <william.w...@beezmo.com> wrote:
>
>>On Wed, 10 Oct 2018 12:45:19 -0700 (PDT), undro...@gmail.com wrote:
>>
>>>Bill,
>>>
>>>a q'n'd workaround could be to add the line
>>>
>>> event generate .kq.guessbutton$buttonindex <Leave>
>>>
>>>right after where the button's background color is changed in order
>>> to force a mouse leave event to switch off the active color.
>>...
>>
>>The event q'n'd works wonderfully! Yay! I haven't fixed all the
>>buttons yet but a quick test on the guess buttons worked :)
> ...
>
> Oops. Spoke too soon. The event addition does solve the problem of
> a button sticking at white until something else pressed - but it
> introduces another problem :(
>
> Once I generate a leave event on a button it goes unresponsive to
> another click until the mouse moves out and back in (Windows) or
> another button pressed (Android). Well - not quite unresponsive. A
> 2nd click turns it white until mouse moved out.
>
> digging...

Just change the -activebackground and -activeforeground colors to be
identical to the -background and -foreground colors used by the widget.

Then you'll see no color change, and you won't have to do any event
trickery.

[Bill Waddington]

On Thu, 11 Oct 2018 18:47:49 -0000 (UTC), Rich <ri...@example.invalid>
wrote:

Thanks Rich, that's beginning to sink in...

Colors change on the fly so I'll have to be a bit careful. I'll give
it a try.

thanks

[Rich]

If you mean you do script driven color changing to make things appear
different, then instead of making the color change manually:

.widget.name configure -foreground blue

create a proc to wrap up changing everything at once, i.e. (note: can
be trivially extended to change both foreground and background at once):

proc color-change {w value} {
$w configure -foreground $value
$w configure -activeforeground $value
}

and then use your wrapper proc everywhere you want to make a color
change.

[two...@gmail.com]

On Thursday, October 11, 2018 at 11:37:33 AM UTC-7, Bill Waddington wrote:

> Oops. Spoke too soon. The event addition does solve the problem of a
> button sticking at white until something else pressed - but it
> introduces another problem :(
>
> Once I generate a leave event on a button it goes unresponsive to
> another click until the mouse moves out and back in (Windows) or
> another button pressed (Android). Well - not quite unresponsive. A
> 2nd click turns it white until mouse moved out.
>
> digging...

Due to this and a few other touch needs, I ended up doing a recursive scan for all my buttons (via winfo children) and save and blank out the -command attributes that a pair of touch up and down bindings of my own will invoke instead. This lets me provide my own feedback where needed, and I can also detect a long press - for auto-repeat or alternate functions.

Using my own bindings also solve a problem with pinches or swipes that can inadvertently trigger a button. By saving the widget that the down touch occurred over and comparing with the widget on the next touch up, I can reduce the number of incorrect button pushes.

[Bill Waddington]

On Thu, 11 Oct 2018 18:57:48 -0000 (UTC), Rich <ri...@example.invalid>

I haven't set up a wrapper proc yet - but a quick test on the two
buttons that don't change color looks promising.

They don't go numb after the first click and the look consistently the
way I want them to. Tested on Win and Android. This is by just
matching active background color with button color. No event command.

Will make the other changes and report back.

(you only need to tell me something 5 or 6 times for it to catch...)

Thanks,

[Bill Waddington]

On Thu, 11 Oct 2018 18:57:48 -0000 (UTC), Rich <ri...@example.invalid>

Thank you sir!

That approach seems to fix the lingering white button problem on
Android and also the white button mouse-over issue in Ubuntu 18.04.

I've got some clean up to do and a new FreeWrap exe to generate, but
the apk is up on the blog, downloaded to my Lenovo tab, and working as
desired. So far... will bang on it for the next few days to confirm.

many thanks to all,

[Gerald Lester]

Bill,

So for jumpping in so late, but if you use themed widgets (aka ttk::
ones) you don't have the mouse-over issues either (at least I'm not
seeing it).

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald...@kng-consulting.net |
+----------------------------------------------------------------------+

[Bill Waddington]

On Wed, 10 Oct 2018 11:53:05 -0700, Bill Waddington
<william.w...@beezmo.com> wrote:

http://www.beezmo.com/geezblog/?p=1842

The toy is running fine on Win and Lin and I've managed an apk via
Androwish that runs on my tablet and phone :)

The tablet has plenty of screen real estate so the Win/Lin version is
OK. The phone screen doesn't have enough pixels so I've reduced font
sizes to a reasonable level in a phone version.

But... the button data changes as the user plays with the toy and some
content just can't be hacked up to fit properly - or is unreadable if
hacked up to fit. I'm going to work up code that can split long lines
at " " (which is less than desirable) along with " {" which is
preferred, for the cases that can't be handled any other way...

I need panning (I think) but don't understand at what level of this
pile (tcl/tk - Androwish - Android) that magic happens. Just running
bareback my Samsung S7 will "pinch" to expand (which doesn't help) but
doesn't pinch to zoom out and won't pan.

I take it that isn't something the OS handles, as I had hoped :( Where
in this mess should that be implemented - and anyone have a link or
two? I've searched and read a bunch but am still lost in the weeds.

Thanks!

yours in ignorance,

[Rich]

Bill Waddington <william.w...@beezmo.com> wrote:
> On Wed, 10 Oct 2018 11:53:05 -0700, Bill Waddington
> <william.w...@beezmo.com> wrote:
>
> I need panning (I think) but don't understand at what level of this
> pile (tcl/tk - Androwish - Android) that magic happens. Just running
> bareback my Samsung S7 will "pinch" to expand (which doesn't help) but
> doesn't pinch to zoom out and won't pan.
>
> I take it that isn't something the OS handles, as I had hoped :( Where
> in this mess should that be implemented - and anyone have a link or
> two? I've searched and read a bunch but am still lost in the weeds.

Most OS'es don't handle panning (or most of the UI 'work'). That stuff
is usually handled by library code running on top of the raw OS
provided interface.

As for panning in your little app, one straightforward way to provide
panning would be to pack/grid everything into a frame. Then place the
frame into a canvas.

The canvas element allows for panning, so with some reasonable bindings
for touch events, you could "pan around" within the canvas your 'frame'
holding your app, and what you'd see on screen is a viewport of the
size of the screen into your larger frame.