Re: Androwish Label Font

Liste des GroupesRevenir à cl tcl 
Sujet : Re: Androwish Label Font
De : csaba.nemethi (at) *nospam* t-online.de (nemethi)
Groupes : comp.lang.tcl
Date : 29. May 2025, 10:33:44
Autres entêtes
Message-ID : <10199lo$3em3$1@tota-refugium.de>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
Am 29.05.25 um 02:33 schrieb Michael Niehren:
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.
--
Csaba Nemethi  https://www.nemethi.de  mailto:csaba.nemethi@t-online.de

Date Sujet#  Auteur
27 May 25 * Re: Androwish Label Font12Harald Oehlmann
27 May 25 +- Re: Androwish Label Font1Harald Oehlmann
28 May 25 +* Re: Androwish Label Font9nemethi
28 May 25 i`* Re: Androwish Label Font8undroidwish
28 May 25 i `* Re: Androwish Label Font7nemethi
28 May 25 i  `* Re: Androwish Label Font6undroidwish
29 May 25 i   `* Re: Androwish Label Font5nemethi
29 May 25 i    `* Re: Androwish Label Font4nemethi
30 May 25 i     `* Re: Androwish Label Font3undroidwish
31 May 25 i      `* Re: Androwish Label Font2nemethi
31 May 25 i       `- Re: Androwish Label Font1undroidwish
2 Jun08:17 `- Re: Androwish Label Font1Harald Oehlmann

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal