info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
AndroWish app data viewing
77 views
Skip to first unread message
Gerhard Reithofer
Mar 31, 2019, 12:08:05 PM3/31/19
to
Hi,
I my app I need to display data from a database. Simple entries can be
used to read a record from db and fill into the entries.
But in some field longer texts are stored which exceed the entry size.
In a "normal" Tk program I could use a balloon help mechanism like
BWidget's dynamic help. When keeping the cursor for 1 second over an
extra long entry a text window pops up and displays the complete
content of that field.
Now to the problem: In AndroWish typically no "Mouse Cursor" exists and
therefore I cannot easy "activate" the toolhelp by moving the cursor
over the entry.
Any hint how to achieve this in a intuitive and simple way?
TIA,
Gerhard
--
Gerhard Reithofer - Techn. EDV Reithofer - http://www.tech-edv.co.at
I my app I need to display data from a database. Simple entries can be
used to read a record from db and fill into the entries.
But in some field longer texts are stored which exceed the entry size.
In a "normal" Tk program I could use a balloon help mechanism like
BWidget's dynamic help. When keeping the cursor for 1 second over an
extra long entry a text window pops up and displays the complete
content of that field.
Now to the problem: In AndroWish typically no "Mouse Cursor" exists and
therefore I cannot easy "activate" the toolhelp by moving the cursor
over the entry.
Any hint how to achieve this in a intuitive and simple way?
TIA,
Gerhard
--
Gerhard Reithofer - Techn. EDV Reithofer - http://www.tech-edv.co.at
Rich
Mar 31, 2019, 2:25:07 PM3/31/19
to
Gerhard Reithofer <gerhard....@tech-edv.co.at> wrote:
> In a "normal" Tk program I could use a balloon help mechanism like
> BWidget's dynamic help. When keeping the cursor for 1 second over an
> extra long entry a text window pops up and displays the complete
> content of that field.
>
> Now to the problem: In AndroWish typically no "Mouse Cursor" exists
> and therefore I cannot easy "activate" the toolhelp by moving the
> cursor over the entry.
>
> Any hint how to achieve this in a intuitive and simple way?
A few ideas come to mind:
> In a "normal" Tk program I could use a balloon help mechanism like
> BWidget's dynamic help. When keeping the cursor for 1 second over an
> extra long entry a text window pops up and displays the complete
> content of that field.
>
> Now to the problem: In AndroWish typically no "Mouse Cursor" exists
> and therefore I cannot easy "activate" the toolhelp by moving the
> cursor over the entry.
>
> Any hint how to achieve this in a intuitive and simple way?
1) Add a small icon to the start (or end) of entries with bindings on
the icon that "expands" the view to show everything.
2) Use label widgets during display so that the -wraplength parameter
can wrap the long text into a multi-line label (and grid or pack
widgets so that growing/shrinking labels work for the overall
display). With a binding on tap to swap in (or pop up) an entry
widget (or a text widget acting as a multi-line entry) to edit the
contents.
3) Bind to long-press (is this possible on AndroWish?) on an entry to
show an expanded display of what is in the entry.
How intuitive each are highly depends upon the users experience and
willingness to experiment. The 'small icon' is likely most intuitive,
as there is something visible as a reminder. The "tap to edit" mode
(#2) seems to fit with how a lot of Android GUI's handle data entry.
Long press is likely the least discoverable (as there is nothing
visible to suggest that long pressing will do anything) and will
sometimes depend highly on the willingness of your end users to
experiment.
Gerhard Reithofer
Apr 1, 2019, 12:38:07 PM4/1/19
to
Hi Rich,
thanks for these ideas.
On Sun, 31 Mar 2019, Rich wrote:
> Gerhard Reithofer <gerhard....@tech-edv.co.at> wrote:
> > In a "normal" Tk program I could use a balloon help mechanism like
...
> > Any hint how to achieve this in a intuitive and simple way?
>
> A few ideas come to mind:
>
> 1) Add a small icon to the start (or end) of entries with bindings on
> the icon that "expands" the view to show everything.
This was my 1st attempt but in practical use the "zoom-in icon" was
either hard to push (too small) or it covered more than expected space
from the precious screen area (too large).
> 2) Use label widgets during display so that the -wraplength parameter
> can wrap the long text into a multi-line label (and grid or pack
> widgets so that growing/shrinking labels work for the overall
> display). With a binding on tap to swap in (or pop up) an entry
> widget (or a text widget acting as a multi-line entry) to edit the
> contents.
That would have been my next approach.
I'm afraid that the "dynamic size changes" could disturb the user as the
"same field" content is not always on the "same place". One possibility
could be a "dynamic size change" (maybe animated) when the user moves
the cursor into the entry text as you describe (see also below).
> 3) Bind to long-press (is this possible on AndroWish?) on an entry to
> show an expanded display of what is in the entry.
Was also on my plan but I couldn't it get to work (the [sdltk
touchtranslate] should map long press to e. g. mouse button 3) and I
found no working example to trigger an event when "pressing" at the
entry packground.
> How intuitive each are highly depends upon the users experience and
> willingness to experiment. The 'small icon' is likely most intuitive,
> as there is something visible as a reminder. The "tap to edit" mode
> (#2) seems to fit with how a lot of Android GUI's handle data entry.
> Long press is likely the least discoverable (as there is nothing
> visible to suggest that long pressing will do anything) and will
> sometimes depend highly on the willingness of your end users to
> experiment.
As I found that the tklib's tooltip function also triggers when
positioning the cursor into the entry ("tap to edit" as you call it) or
onto the label I will use this 1st to achieve my goal.
The BWidget dynamic help does not work that way in my AndroWish dialogs.
In my app only one specific value will be changed (visually marked)
therefore the tooltip text cannot cover the editable area in general.
In combination with a line wrapping function (can be found the tcler's
wiki) the complete field content will be displayed well readable when
taping to the "output field" ;-) :-)
Thank you very, very much,
thanks for these ideas.
On Sun, 31 Mar 2019, Rich wrote:
> Gerhard Reithofer <gerhard....@tech-edv.co.at> wrote:
> > In a "normal" Tk program I could use a balloon help mechanism like
> > Any hint how to achieve this in a intuitive and simple way?
>
> A few ideas come to mind:
>
> 1) Add a small icon to the start (or end) of entries with bindings on
> the icon that "expands" the view to show everything.
either hard to push (too small) or it covered more than expected space
from the precious screen area (too large).
> 2) Use label widgets during display so that the -wraplength parameter
> can wrap the long text into a multi-line label (and grid or pack
> widgets so that growing/shrinking labels work for the overall
> display). With a binding on tap to swap in (or pop up) an entry
> widget (or a text widget acting as a multi-line entry) to edit the
> contents.
I'm afraid that the "dynamic size changes" could disturb the user as the
"same field" content is not always on the "same place". One possibility
could be a "dynamic size change" (maybe animated) when the user moves
the cursor into the entry text as you describe (see also below).
> 3) Bind to long-press (is this possible on AndroWish?) on an entry to
> show an expanded display of what is in the entry.
touchtranslate] should map long press to e. g. mouse button 3) and I
found no working example to trigger an event when "pressing" at the
entry packground.
> How intuitive each are highly depends upon the users experience and
> willingness to experiment. The 'small icon' is likely most intuitive,
> as there is something visible as a reminder. The "tap to edit" mode
> (#2) seems to fit with how a lot of Android GUI's handle data entry.
> Long press is likely the least discoverable (as there is nothing
> visible to suggest that long pressing will do anything) and will
> sometimes depend highly on the willingness of your end users to
> experiment.
positioning the cursor into the entry ("tap to edit" as you call it) or
onto the label I will use this 1st to achieve my goal.
The BWidget dynamic help does not work that way in my AndroWish dialogs.
In my app only one specific value will be changed (visually marked)
therefore the tooltip text cannot cover the editable area in general.
In combination with a line wrapping function (can be found the tcler's
wiki) the complete field content will be displayed well readable when
taping to the "output field" ;-) :-)
Thank you very, very much,
Harald Oehlmann
Apr 1, 2019, 1:01:47 PM4/1/19
to
Am 01.04.2019 um 18:37 schrieb Gerhard Reithofer:
> As I found that the tklib's tooltip function also triggers when
> positioning the cursor into the entry ("tap to edit" as you call it) or
> onto the label I will use this 1st to achieve my goal.
> The BWidget dynamic help does not work that way in my AndroWish dialogs.
>
> In my app only one specific value will be changed (visually marked)
> therefore the tooltip text cannot cover the editable area in general.
> In combination with a line wrapping function (can be found the tcler's
> wiki) the complete field content will be displayed well readable when
> taping to the "output field" ;-) :-)
>
> Thank you very, very much,
> Gerhard
>
Could you share your solution on the wiki like on a "AndroWish tooltip
> As I found that the tklib's tooltip function also triggers when
> positioning the cursor into the entry ("tap to edit" as you call it) or
> onto the label I will use this 1st to achieve my goal.
> The BWidget dynamic help does not work that way in my AndroWish dialogs.
>
> In my app only one specific value will be changed (visually marked)
> therefore the tooltip text cannot cover the editable area in general.
> In combination with a line wrapping function (can be found the tcler's
> wiki) the complete field content will be displayed well readable when
> taping to the "output field" ;-) :-)
>
> Thank you very, very much,
> Gerhard
>
solution" page ?
Thanks,
Harald
two...@gmail.com
Apr 1, 2019, 2:42:57 PM4/1/19
to
On Sunday, March 31, 2019 at 9:08:05 AM UTC-7, Gerhard Reithofer wrote:
> therefore I cannot easy "activate" the toolhelp
I struggled with longpress and a few other issues with buttons. I'm
> therefore I cannot easy "activate" the toolhelp
sure there's a better way, but if all else fails there's two low level
events one can bind with:
<<FingerUp>>
<<FingerDown>>
These can be bound to a particular widget, in my case I bind them to
my buttons.
I replace all -command attributes of my buttons (using [winfo children]
to find them) with a helper proc that is sent such things as up/down
and the -command attribute, which I then set to null. Thus I have complete
control over my buttons and have been able to implement longpress, repeat,
and I can also verify that the down and up were for the same button (to
detect a swipe gesture and not inadvertently invoke a button).
I create some other events and bindings per widget to specify which
buttons can be longpressed or repeated. If none of these are set, I just
invoke the normal -command that I had saved as a parameter with my up/down
bindings.
I also had trouble with providing feedback on a longpress so I just use
borg toast "message"
This might be useful as a "tool help" mechanism.
Gerhard Reithofer
Apr 2, 2019, 6:08:06 AM4/2/19
to
Hallo Harald,
On Mon, 1 Apr 2019, Harald Oehlmann wrote:
> Am 01.04.2019 um 18:37 schrieb Gerhard Reithofer:
> > As I found that the tklib's tooltip function also triggers when
...
> > In combination with a line wrapping function (can be found the tcler's
> > wiki) the complete field content will be displayed well readable when
> > taping to the "output field" ;-) :-)
...
> Could you share your solution on the wiki like on a "AndroWish tooltip
> solution" page ?
There's not much to show, its just the use of a LabelEntry and
tklib's tooltip.
---
# tooltiptest.tcl
#
package require BWidget
package require tooltip
set lval "This is a rather long entry text to demontrate the"
append lval " behavior of the tooltip function in an AndroWish"
append lval " application. Locating the the cursor inside of the"
append lval " entry displays the content as tooltip text again."
set t [toplevel .top]
set le [LabelEntry $t.le -label "Content" -text $lval]
set lb [label $t.lb -text "Tap to label or entry to read..."]
tooltip::tooltip $le [join [linebreak $lval 30] "\n"]
pack $le $lb
---
The linebreak function is the one from RS.
https://wiki.tcl-lang.org/page/Additional+string+functions#85de7bc7fe7346022a9a2903e106256b5c07d57175e9a0e3aca1808cff9f0d17
I don't think its worthwhile to publish this on the Wiki.
In one word it is: use an entry with tcllib's tooltip.
In my case its perfect becaue I do not want to "edit" the texts where
the tooltip window could be disturbing (not tested).
Bye,
On Mon, 1 Apr 2019, Harald Oehlmann wrote:
> Am 01.04.2019 um 18:37 schrieb Gerhard Reithofer:
> > As I found that the tklib's tooltip function also triggers when
> > In combination with a line wrapping function (can be found the tcler's
> > wiki) the complete field content will be displayed well readable when
> > taping to the "output field" ;-) :-)
> Could you share your solution on the wiki like on a "AndroWish tooltip
> solution" page ?
tklib's tooltip.
---
# tooltiptest.tcl
#
package require BWidget
package require tooltip
set lval "This is a rather long entry text to demontrate the"
append lval " behavior of the tooltip function in an AndroWish"
append lval " application. Locating the the cursor inside of the"
append lval " entry displays the content as tooltip text again."
set t [toplevel .top]
set le [LabelEntry $t.le -label "Content" -text $lval]
set lb [label $t.lb -text "Tap to label or entry to read..."]
tooltip::tooltip $le [join [linebreak $lval 30] "\n"]
pack $le $lb
---
The linebreak function is the one from RS.
https://wiki.tcl-lang.org/page/Additional+string+functions#85de7bc7fe7346022a9a2903e106256b5c07d57175e9a0e3aca1808cff9f0d17
I don't think its worthwhile to publish this on the Wiki.
In one word it is: use an entry with tcllib's tooltip.
In my case its perfect becaue I do not want to "edit" the texts where
the tooltip window could be disturbing (not tested).
Bye,
Gerhard Reithofer
Apr 2, 2019, 7:08:05 AM4/2/19
to
Wow,
On Mon, 1 Apr 2019, two...@gmail.com wrote:
> On Sunday, March 31, 2019 at 9:08:05 AM UTC-7, Gerhard Reithofer wrote:
> > therefore I cannot easy "activate" the toolhelp
...
> <<FingerUp>>
> <<FingerDown>>
...
> I replace all -command attributes of my buttons (using [winfo children]
> to find them) with a helper proc that is sent such things as up/down
> and the -command attribute, which I then set to null. Thus I have complete
> control over my buttons and have been able to implement longpress, repeat,
> and I can also verify that the down and up were for the same button (to
> detect a swipe gesture and not inadvertently invoke a button).
>
> I create some other events and bindings per widget to specify which
> buttons can be longpressed or repeated. If none of these are set, I just
> invoke the normal -command that I had saved as a parameter with my up/down
> bindings.
a very basic approach. I love these solutions even if the are much work
but they behave exactly as they are designed for ;-)
> I also had trouble with providing feedback on a longpress so I just use
>
> borg toast "message"
Regarding feedback I'm still a fan of "status lines" and/or "labels" at
defined positions which can be also be used on the desktop. AndroWish
is usually only one small part from more complex solutions.
> This might be useful as a "tool help" mechanism.
It was, THX :-)
On Mon, 1 Apr 2019, two...@gmail.com wrote:
> On Sunday, March 31, 2019 at 9:08:05 AM UTC-7, Gerhard Reithofer wrote:
> > therefore I cannot easy "activate" the toolhelp
> <<FingerUp>>
> <<FingerDown>>
...
> I replace all -command attributes of my buttons (using [winfo children]
> to find them) with a helper proc that is sent such things as up/down
> and the -command attribute, which I then set to null. Thus I have complete
> control over my buttons and have been able to implement longpress, repeat,
> and I can also verify that the down and up were for the same button (to
> detect a swipe gesture and not inadvertently invoke a button).
>
> I create some other events and bindings per widget to specify which
> buttons can be longpressed or repeated. If none of these are set, I just
> invoke the normal -command that I had saved as a parameter with my up/down
> bindings.
but they behave exactly as they are designed for ;-)
> I also had trouble with providing feedback on a longpress so I just use
>
> borg toast "message"
defined positions which can be also be used on the desktop. AndroWish
is usually only one small part from more complex solutions.
> This might be useful as a "tool help" mechanism.
0 new messages