Hi together,
i played around with Androwish to build an TCL-App for Android.
I got it running, compiled my own version with some extra modules,
everything fine.
In my program code i set the used text font for the Label-Widgetes with
ttk::style configure TLabel -font Labelfont
in the same way as TEntry or TButton, but this font setting on the ttk::labels is not applied, all other's are running as expected.
If found an entry in the wiki from 2014 (http://wookie.tcl.tk/39493) which describes the same problem, but no solution.
Does anybody know (11 years later), what is going on here and maybe howto solve the problem ?
best regards
Michael
Am 27.05.2025 um 14:40 schrieb Michael Niehren:
Hi together,
i played around with Androwish to build an TCL-App for Android.
I got it running, compiled my own version with some extra modules,
everything fine.
In my program code i set the used text font for the Label-Widgetes with
ttk::style configure TLabel -font Labelfont
in the same way as TEntry or TButton, but this font setting on the
ttk::labels is not applied, all other's are running as expected.
If found an entry in the wiki from 2014 (http://wookie.tcl.tk/39493)
which
describes the same problem, but no solution.
Does anybody know (11 years later), what is going on here and maybe howto
solve the problem ?
best regards
Michael
I don't have this issue. It just works. This may be a style issue. I use AWDark on Androwish. My font definition is like this:
option add *TLabel.font LabelFont
I don't remember, why I use the option data base and do not use the
style configuration. Maybe, to be style agnostic.
Harald
Am 27.05.2025 um 14:40 schrieb Michael Niehren:
Hi together,
i played around with Androwish to build an TCL-App for Android.
I got it running, compiled my own version with some extra modules,
everything fine.
In my program code i set the used text font for the Label-Widgetes with
ttk::style configure TLabel -font Labelfont
in the same way as TEntry or TButton, but this font setting on the
ttk::labels is not applied, all other's are running as expected.
If found an entry in the wiki from 2014 (http://wookie.tcl.tk/39493)
which describes the same problem, but no solution.
Does anybody know (11 years later), what is going on here and maybe howto
solve the problem ?
best regards
Michael
I don't have this issue. It just works. This may be a style issue. I use AWDark on Androwish. My font definition is like this:
option add *TLabel.font LabelFont
I don't remember, why I use the option data base and do not use the
style configuration. Maybe, to be style agnostic.
Harald
Harald Oehlmann wrote:
Am 27.05.2025 um 14:40 schrieb Michael Niehren:
Hi together,
i played around with Androwish to build an TCL-App for Android.
I got it running, compiled my own version with some extra modules,
everything fine.
In my program code i set the used text font for the Label-Widgetes with
ttk::style configure TLabel -font Labelfont
in the same way as TEntry or TButton, but this font setting on the
ttk::labels is not applied, all other's are running as expected.
If found an entry in the wiki from 2014 (http://wookie.tcl.tk/39493)
which describes the same problem, but no solution.
Does anybody know (11 years later), what is going on here and maybe howto >>> solve the problem ?
best regards
Michael
I don't have this issue. It just works. This may be a style issue. I use
AWDark on Androwish. My font definition is like this:
option add *TLabel.font LabelFont
I don't remember, why I use the option data base and do not use the
style configuration. Maybe, to be style agnostic.
Harald
That's it Harald, many thanks to you. It works also without the AWDark
Theme. Maybe you can make an entry in the Wiki for that. It is nowhere documented.
I also find Androwish very interesting, but i am on my first steps with it.
By the way, another question, maybe you can help me too.
I want to use Csaba's scrollutil within the Android-App. I tried it with the scrollableframe, here is a litte code from that.
set sw [scrollutil::scrollarea $top.sw -borderwidth 0 -relief flat]
set sf [scrollutil::scrollableframe $sw.sf -fitcontentwidth 1]
$sw setwidget $sf
scrollutil::createWheelEventBindings all
scrollutil::enableScrollingByWheel $sf
My intension was that the user can scroll with 1 finger in the
scollabeframe, as this is the normal case on Android. But it seem's that
the Bindings are not working here. I can only scroll when i touch on the scrollbar and then go up/down.
There should be 3 bindings in Androwith with finger gesture
<<FingerDown>>: Triggered when a finger touches the screen.
<<FingerUp>>: Triggered when a finger is lifted.
<<FingerMotion>>: Triggered when a finger moves across the screen.
Do you also have an solution for that ?
...
To your question related to the scrollableframe: Try the following code:
foreach class {ScrollableframeMf ScrollableframeCf} isCf {0 1} {
bind $class <<FingerDown>> \
[list scrollutil::sf::onButton1 %W %x %y $isCf]
bind $class <<FingerMotion>> \
[list scrollutil::sf::onB1Motion %W %x %y $isCf]
bind $class <<FingerUp>> \
[list scrollutil::sf::onButtonRelease1 %W $isCf]
}
...
On 5/28/25 12:50, nemethi wrote:
... To your question related to the scrollableframe: Try the
following code:
foreach class {ScrollableframeMf ScrollableframeCf} isCf {0 1} {
bind $class <<FingerDown>> \
[list scrollutil::sf::onButton1 %W %x %y $isCf]
bind $class <<FingerMotion>> \
[list scrollutil::sf::onB1Motion %W %x %y $isCf]
bind $class <<FingerUp>> \
[list scrollutil::sf::onButtonRelease1 %W $isCf]
}
...
Csaba, please let's try with Button-2 bindings, since this is what
AndroWish emulates for swipe gestures e.g. when dragging a Text widget,
so your proposal becomes:
foreach class {ScrollableframeMf ScrollableframeCf} isCf {0 1} {
bind $class <2> \
[list scrollutil::sf::onButton1 %W %x %y $isCf]
bind $class <B2-Motion> \
[list scrollutil::sf::onB1Motion %W %x %y $isCf]
bind $class <ButtonRelease-2> \
[list scrollutil::sf::onButtonRelease1 %W $isCf]
}
The <<Finger...>> virtual events are more complex since they allow
for multi touch and pressure.
See https://androwish.org/home/wiki?name=sdltk+command for more
detailed information.
Hope this helps,
Christian
Many thanks, Christian! In the meantime I have found out why my
proposed solution fails and how to make it work, but your proposal to
use Button-2 bindings rather than <<Finger...>> virtual events appears
to be the better solution (I didn't know that the swipe gestures emulate <Button-2>, <B2-Motion> and <ButtonRelease-2> events).
Just for completeness, here is my corrected solution using <<Finger...>> events:
foreach class {ScrollableframeMf ScrollableframeCf} isCf {0 1} {
bind $class <<FingerDown>> { set motionCount 0 }
bind $class <<FingerMotion>> [format {
if {[incr motionCount] == 1} {
scrollutil::sf::onButton1 %%W %%x %%y %d
} else {
scrollutil::sf::onB1Motion %%W %%x %%y %d
}
} $isCf $isCf]
bind $class <<FingerUp>> [list scrollutil::sf::onButtonRelease1 %W $isCf]
}
If I understand the manual correctly, <<FingerDown>> events have no %x
and %y fields, hence the scrollutil::sf::onButton1 proc is now invoked
on the first <<FingerMotion>> rather than on the <<FingerDown>> event.
This makes the trick. But, as said, your proposal is in IMHO the better one.
On 5/28/25 19:44, nemethi wrote:
Many thanks, Christian! In the meantime I have found out why my
proposed solution fails and how to make it work, but your proposal to
use Button-2 bindings rather than <<Finger...>> virtual events appears
to be the better solution (I didn't know that the swipe gestures emulate
<Button-2>, <B2-Motion> and <ButtonRelease-2> events).
Just for completeness, here is my corrected solution using <<Finger...>>
events:
foreach class {ScrollableframeMf ScrollableframeCf} isCf {0 1} {
bind $class <<FingerDown>> { set motionCount 0 }
bind $class <<FingerMotion>> [format {
if {[incr motionCount] == 1} {
scrollutil::sf::onButton1 %%W %%x %%y %d
} else {
scrollutil::sf::onB1Motion %%W %%x %%y %d
}
} $isCf $isCf]
bind $class <<FingerUp>> [list scrollutil::sf::onButtonRelease1 %W
$isCf]
}
If I understand the manual correctly, <<FingerDown>> events have no %x
and %y fields, hence the scrollutil::sf::onButton1 proc is now invoked
on the first <<FingerMotion>> rather than on the <<FingerDown>> event.
This makes the trick. But, as said, your proposal is in IMHO the better
one.
Csaba, please read the fine print of the sdltk manpage. The problem is,
that most capacitive touchscreens detect more than one finger, many up
to 10.
And the <<FingerMotion>> description states (note the last sentence):
"A touch movement (sliding) event. The fields %x and %y are substituted
with the finger position scaled to {0...9999} of the device screen or viewport, %X and %Y with the motion difference scaled to
{-9999...+9999}, %t with the pressure scaled to {0...9999}, and %s with
the finger identifier {1...10}. These substitutions are performed for
all finger related touch events."
So taken the 4 to 6 states of freedom of all finger events I guess the
logic in the binding could become quite complicated. That was the main motivation to have the emulation of Button-2 in a lower layer, BTW.
Now that we have thought out some possible solutions, my hope is that
Michael will try it, giving us feedback if things works as he expects.
All the best,
Christian
undroidwish wrote:
On 5/28/25 19:44, nemethi wrote:
Many thanks, Christian! In the meantime I have found out why my
proposed solution fails and how to make it work, but your proposal to
use Button-2 bindings rather than <<Finger...>> virtual events appears
to be the better solution (I didn't know that the swipe gestures emulate >>> <Button-2>, <B2-Motion> and <ButtonRelease-2> events).
Just for completeness, here is my corrected solution using <<Finger...>> >>> events:
foreach class {ScrollableframeMf ScrollableframeCf} isCf {0 1} {
bind $class <<FingerDown>> { set motionCount 0 }
bind $class <<FingerMotion>> [format {
if {[incr motionCount] == 1} {
scrollutil::sf::onButton1 %%W %%x %%y %d
} else {
scrollutil::sf::onB1Motion %%W %%x %%y %d
}
} $isCf $isCf]
bind $class <<FingerUp>> [list scrollutil::sf::onButtonRelease1 %W
$isCf]
}
If I understand the manual correctly, <<FingerDown>> events have no %x
and %y fields, hence the scrollutil::sf::onButton1 proc is now invoked
on the first <<FingerMotion>> rather than on the <<FingerDown>> event.
This makes the trick. But, as said, your proposal is in IMHO the better >>> one.
Csaba, please read the fine print of the sdltk manpage. The problem is,
that most capacitive touchscreens detect more than one finger, many up
to 10.
And the <<FingerMotion>> description states (note the last sentence):
"A touch movement (sliding) event. The fields %x and %y are substituted
with the finger position scaled to {0...9999} of the device screen or
viewport, %X and %Y with the motion difference scaled to
{-9999...+9999}, %t with the pressure scaled to {0...9999}, and %s with
the finger identifier {1...10}. These substitutions are performed for
all finger related touch events."
So taken the 4 to 6 states of freedom of all finger events I guess the
logic in the binding could become quite complicated. That was the main
motivation to have the emulation of Button-2 in a lower layer, BTW.
Now that we have thought out some possible solutions, my hope is that
Michael will try it, giving us feedback if things works as he expects.
All the best,
Christian
Hi, be sure that i tried it !!!
it seem's that both implementations work, but the scollutil does not work as expected all over.
Take this little example:
------------
package require scrollutil_tile
wm state . normal
wm attributes . -fullscreen 1
foreach class {ScrollableframeMf ScrollableframeCf} isCf {0 1} {
bind $class <2> [list scrollutil::sf::onButton1 %W %x %y $isCf]
bind $class <B2-Motion> [list scrollutil::sf::onB1Motion %W %x %y $isCf]
bind $class <ButtonRelease-2> [list scrollutil::sf::onButtonRelease1 %W $isCf]
}
set sa [scrollutil::scrollarea .sa -borderwidth 0 -relief flat]
set sf [scrollutil::scrollableframe $sa.sf -fitcontentwidth 1]
$sa setwidget $sf
scrollutil::createWheelEventBindings all
pack $sa -side top -fill both -expand true -padx 10
set top [$sf contentframe]
frame $top.f -height 1500 -width 400 -bg red
pack $top.f -side top -expand true
frame $top.f1 -height 1500 -width 400 -bg green
pack $top.f1 -side top -expand true
frame $top.f2 -height 1500 -width 400 -bg blue
pack $top.f2 -side top -expand true -fill y
------------
there are 3 simple frames among each other. If i touch on the left or the right area of these frames, scrolling work's with both bindings. But if i touch on one of the 3 frames in the mid, there is no scrolling.
With the same code under a "normal" wish i can scroll with the mousewheel anywhere.
Michael, it is important to be aware of the difference between scrolling
with the mouse wheel and scanning with mouse button 1 or 2.
The scrolling with the mouse wheel works everywhere in the
scrollableframe as long as the widget under the pointer where the
scrolling started doesn't have the focus. In your example this is the
case in the whole scrollableframe window.
For scanning with mouse button 1 or 2 one has to click on a *free* area
of the scrollableframe window. In your example this means: to the left
or right of the red, green, and blue frames. Unfortunately, this is not explicitly mentioned in the documentation, but will be in the next
Scrollutil version. I will also think about a way to drop this
restriction, but this might be more complicated than it looks at first glance.
The fact that both scanning implementations work for you is a good news.
I will incorporate the one using mouse button 2 into the next
Scrollutil release, thus implicitly adding scan support via one-finger gestures on AndroWish.
Michael, it is important to be aware of the difference between scrolling
with the mouse wheel and scanning with mouse button 1 or 2.
The scrolling with the mouse wheel works everywhere in the
scrollableframe as long as the widget under the pointer where the
scrolling started doesn't have the focus. In your example this is the
case in the whole scrollableframe window.
For scanning with mouse button 1 or 2 one has to click on a *free* area
of the scrollableframe window. In your example this means: to the left
or right of the red, green, and blue frames. Unfortunately, this is not
explicitly mentioned in the documentation, but will be in the next
Scrollutil version. I will also think about a way to drop this
restriction, but this might be more complicated than it looks at first
glance.
The fact that both scanning implementations work for you is a good news.
I will incorporate the one using mouse button 2 into the next
Scrollutil release, thus implicitly adding scan support via one-finger
gestures on AndroWish.
Hi Csaba,
thanks for your explanations.
For my app i wanted to use 1 scrollable frame and inside that, there are
some sub frames which contains canvases and some labels or entry fields or whatever. All of these subframes are fully expanded one below the other, so there is no free place of the underlying scrolledframe, which means that
the scrolledframe is useless for scrolling.
So the "normal" behaviour on Android on scrolling up/down by wishing with 1 finger would currently not be possible.
Do i have understand right ?
Hi Michael,
I'm afraid you are right that scan support is currently no help if the scrollableframe window has no free area. On platforms other than
AndroWish this is not as dramatic because the user can scroll with the
mouse wheel (or via two-finger touchpad gestures) instead.
As already mentioned, I will try to eliminate the dependency on the
existence of a free area, but this is a nontrivial effort, which will
need pretty much work. I will let you know when I have anything new regarding this subject.
Best regards,
Csaba
...using> scrolling ...
It would be very nice to have that feature for Androwish. Androwish is a > very amazing project. So at the moment i have to build my app without
On 5/29/25 18:23, Michael Niehren wrote:
Michael, Csaba,
...using> scrolling ...
It would be very nice to have that feature for Androwish. Androwish is
a > very amazing project. So at the moment i have to build my app without
meanwhile I tried to redirect the <Button-2> and friends stuff to <MouseWheel> and friends in a non AndroWish enviroment but am afraid,
that it is not feasible since the expectation of touch screen events
for scrolling is, that the scrolled content follows the finger motion
more or less. The more the natural the scrolling will be. Thus I hope,
that Csaba finds a good way to deal with <Button-2> and friends.
Have a sunny weekend,
Christian
…
In the meantime I have made good progress in providing scan support for scrollableframe widgets using mouse button 2. The new stuff works regardless of whether the button was pressed over a free area of the scrollableframe or, e.g., over a label or frame widget. If it was
pressed over a widget having button 2 bindings (like listbox or text)
then it triggers a local scan *within that widget*, but with a quite
simple command invocation you can make sure that a scan *within the scrollableframe* will be triggered instead if the focus is not on the clicked widget. This is similar to the way mouse wheel events are
handled in scrollable widget containers.
I can send you this new stuff within the next few days.
That's it Harald, many thanks to you. It works also without the AWDark
Theme. Maybe you can make an entry in the Wiki for that. It is nowhere documented.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 170:42:30 |
| Calls: | 13,692 |
| Files: | 186,936 |
| D/L today: |
100 files (20,246K bytes) |
| Messages: | 2,411,676 |