tcl-core

[TCLCORE] TIPs looking for implementations

[Donal K. F. <don...@ma...>]

We're getting there!

After much hard work by many people, the massive tranche of TIPs that
have been voted through are nearly all implemented. There are a few left
at this stage though, so I'm shaking the tree...

These are the TIPs in the Accepted state (where there's implementation
involved; there are non-implementation TIPs in that state too).

   141: Multiple Initial-Files in tk_getOpenFile
   171: Change Default <MouseWheel> Bindings Behavior
   244: PNG Photo Image Support for Tk
   308: Tcl Database Connectivity (TDBC)
   332: Half-Close for Bidirectional Channels

(This is based of http://wiki.tcl.tk/20966 which is where we're keeping
a work-roster of Accepted TIPs and critical bugs...)

Now, to dig into the details of each of them. (They're all different
from each other; you can't generalize.)

  * TIP#141 is a hold-over from 8.5; we need to decide if we're going to
    act on this by implementing it, withdrawing it, or do something else.

  * TIP#171 should be easy to act on; I've not done it yet because I'm
    not the relevant maintainer.

  * TIP#244 requires a chunk of effort to get done, especially as it
    might result in changes in Tcl too to handle the building. This is
    probably the biggest single concern right now.

  * TIP#308 isn't constrained to the same extent as the other TIPs on
    this list because of its non-standard status: it can be allowed to
    slip to later than 8.6b1.

  * TIP#332 has an implementation promised, probably by the end of
    tomorrow (it's in the tests-and-docs stage). I'm not worried about
    it.

Maintainers! If you can help out with any of these, please do!

Is your favourite TIP not on that list? Well, that means one of two
things. Either it's done (modulo implementation issues) or its not going
into Tcl/Tk 8.6 (well, not without a very hard argument).

Donal

Re: [TCLCORE] TIPs looking for implementations

[Kevin K. <ke...@ac...>]

Donal K. Fellows wrote:

>   * TIP#141 is a hold-over from 8.5; we need to decide if we're going to
>     act on this by implementing it, withdrawing it, or do something else.

What's lacking is a Windows implementation, as I understand it.
The other platforms are done.  I looked at what it would take on
Windows, and it's very, very nasty; the native dialog just doesn't
appear to be intended to be driven that way. (It looks *possible*,
but involves ugly reaching into the guts of that dialog box.)

>   * TIP#171 should be easy to act on; I've not done it yet because I'm
>     not the relevant maintainer.

Didn't we do these changes already? Why not? Jeff??

>   * TIP#308 isn't constrained to the same extent as the other TIPs on
>     this list because of its non-standard status: it can be allowed to
>     slip to later than 8.6b1.

TIP #308 also is still holding precisely *because* of that status.
Reasonably complete, documented, implementations (with test suites)
of the TDBC base classes, and the tdbc::odbc and tdbc::sqlite3 sample
drivers are all ready to go; what remains is to sort out the
toolchain issues of building independent packages. I believe dgp
is committed to working on that, and I'm of course willing to
give him whatever help I can.

-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIPs looking for implementations

[Joe E. <jen...@fl...>]

Kevin Kenny wrote:
> Donal K. Fellows wrote:
> >   * TIP#171 should be easy to act on; I've not done it yet because I'm
> >     not the relevant maintainer.
>
> Didn't we do these changes already? Why not? Jeff??

I (for one) still have unanswered questions about the
proposed TIP#171 implementation.  Specifically:

| instead of going through all sorts of rigamarole at
| the scripting level to redirect MouseWheel events
| to the widget under the pointer on Windows, wouldn't
| it make more sense to simply not redirect them to
| the focus window in the first place (see tkEvent.c,
| InvokeFocusHandlers)?  That's how it's currently done
| on OSX.  I suspect it also interferes with some of
| the ttk::* widgets.

I agree with the TIP#171 Rationale (paraphrased: "On
Windows, mouse wheel scrolling should affect the widget
under the pointer [just like it does on X11 and OSX]
instead of the widget with keyboard focus.")  But the
proposed implementation smells really bad to me.

(The proposed implementation looks like a usable stopgap
solution for Tk <= 8.5, but long-term it is -- I suspect --
something we're just going to have to undo later.)


--JE

Re: [TCLCORE] TIPs looking for implementations

[Koen D. <ko...@re...>]

Joe English wrote:
> Kevin Kenny wrote:
>> Donal K. Fellows wrote:
>>>   * TIP#171 should be easy to act on; I've not done it yet because I'm
>>>     not the relevant maintainer.
>> Didn't we do these changes already? Why not? Jeff??
> 
> I (for one) still have unanswered questions about the
> proposed TIP#171 implementation.  Specifically:
> 
> | instead of going through all sorts of rigamarole at
> | the scripting level to redirect MouseWheel events
> | to the widget under the pointer on Windows, wouldn't
> | it make more sense to simply not redirect them to
> | the focus window in the first place (see tkEvent.c,
> | InvokeFocusHandlers)?  That's how it's currently done
> | on OSX.  I suspect it also interferes with some of
> | the ttk::* widgets.
> 
> I agree with the TIP#171 Rationale (paraphrased: "On
> Windows, mouse wheel scrolling should affect the widget
> under the pointer [just like it does on X11 and OSX]
> instead of the widget with keyboard focus.")  But the
> proposed implementation smells really bad to me.
> 
> (The proposed implementation looks like a usable stopgap
> solution for Tk <= 8.5, but long-term it is -- I suspect --
> something we're just going to have to undo later.)

In case anyone is interested in it, I use the C patch below to achieve basically the same as TIP 171, but whithout all the [focus] voodoo going on in that TIP's implementation.


Index: generic/tkEvent.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/generic/tkEvent.c,v
retrieving revision 1.37
diff -u -r1.37 tkEvent.c
--- generic/tkEvent.c   8 Nov 2008 18:44:39 -0000       1.37
+++ generic/tkEvent.c   25 Nov 2008 11:34:05 -0000
@@ -246,17 +246,7 @@
        return 1;
     }
 
-    /*
-     * MouseWheel events are not focus specific on Mac OS X.
-     */
-
-#ifdef MAC_OSX_TK
-#define FOCUS_DIRECTED_EVENT_MASK (KeyPressMask|KeyReleaseMask)
-#else
-#define        FOCUS_DIRECTED_EVENT_MASK (KeyPressMask|KeyReleaseMask|MouseWheelMask)
-#endif
-
-    if (mask & FOCUS_DIRECTED_EVENT_MASK) {
+    if (mask & (KeyPressMask|KeyReleaseMask)) {
        (*winPtrPtr)->dispPtr->lastEventTime = eventPtr->xkey.time;
        *winPtrPtr = TkFocusKeyEvent(*winPtrPtr, eventPtr);
        if (*winPtrPtr == NULL) {
Index: win/tkWinX.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/win/tkWinX.c,v
retrieving revision 1.58
diff -u -r1.58 tkWinX.c
--- win/tkWinX.c        27 Apr 2008 22:39:17 -0000      1.58
+++ win/tkWinX.c        25 Nov 2008 11:34:08 -0000
@@ -1006,6 +1006,16 @@
     ThreadSpecificData *tsdPtr = (ThreadSpecificData *)
            Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));
 
+    /* Redirect mousewheel events to the window containing the cursor. */
+    if (message == WM_MOUSEWHEEL) {
+        POINTS rootPoint = MAKEPOINTS(lParam);
+        POINT pos;
+        pos.x = rootPoint.x;
+        pos.y = rootPoint.y;
+        hwnd = WindowFromPoint(pos);
+        winPtr = (TkWindow *) Tk_HWNDToWindow(hwnd);
+    }
+
     if (!winPtr || winPtr->window == None) {
        return;
     }
@@ -1103,11 +1113,6 @@
        break;
 
     case WM_MOUSEWHEEL:
-       /*
-        * The mouse wheel event is closer to a key event than a mouse event
-        * in that the message is sent to the window that has focus.
-        */
-
     case WM_CHAR:
     case WM_UNICHAR:
     case WM_SYSKEYDOWN:

Re: [TCLCORE] TIPs looking for implementations

[Michael K. <mi...@mu...>]

On Tue, 16 Dec 2008, Donal K. Fellows wrote:

>  * TIP#244 requires a chunk of effort to get done, especially as it
>    might result in changes in Tcl too to handle the building. This is
>    probably the biggest single concern right now.

I've started stubbing out TkPNG to work with-or-without the API specified 
by TIP#234, though I can't guarantee to get that done by Dec 19 
(especially with Pascal's site still down so I don't have 234's sample 
implementation to work with or reference).

Mainly this involves changing the ckalloc'ed buffers to byte array 
Tcl_Objs and implementing versions of some of the 234 APIs within 244, but 
wrapped in #ifdefs so that TkPNG can be built standalone or against zlib 
in the core.  It may then need minor changes depending on how 234 actually 
gets implemented to deal with partial reads/writes (e.g. whether it keeps 
a copy of leftover data for the next call or holds a reference to the 
input data Tcl_Obj may affect where I can store the next chunk of data to 
feed to StreamPut).

TIP#244 shouldn't require changes in Tcl to handle the building that I can 
think of--that's all on the #234 (zlib) side, unless zlib being optional 
at build time was still on the table (I though it wasn't) and you for some 
reason still want to build #244 into Tk with #234 disabled in Tcl.  That 
wouldn't be my recommendation. :P

...or, maybe you meant #234 rather than #244 in your statement.

--
Michael Kirkham
President & CEO
Muonics, Inc.
http://www.muonics.com/

Re: [TCLCORE] TIPs looking for implementations

[Donal K. F. <don...@ma...>]

Michael Kirkham wrote:
> I've started stubbing out TkPNG to work with-or-without the API specified 
> by TIP#234, though I can't guarantee to get that done by Dec 19 
> (especially with Pascal's site still down so I don't have 234's sample 
> implementation to work with or reference).

I had a lot of trouble with Pascal's site too. Luckily, I discovered
that Google Code Search had a cached copy. :-) I've greatly cleaned up
the code and included it in the HEAD of Tcl.

> Mainly this involves changing the ckalloc'ed buffers to byte array 
> Tcl_Objs and implementing versions of some of the 234 APIs within 244, but 
> wrapped in #ifdefs so that TkPNG can be built standalone or against zlib 
> in the core.  It may then need minor changes depending on how 234 actually 
> gets implemented to deal with partial reads/writes (e.g. whether it keeps 
> a copy of leftover data for the next call or holds a reference to the 
> input data Tcl_Obj may affect where I can store the next chunk of data to 
> feed to StreamPut).

It retains references to Tcl_Objs according to the "Hairy Monster"
style, so you'll need to both a) avoid passing refcount 0 objects in,
possibly by wrapping and Incr/Decr pair around the StreamPut, and b) not
reuse objects that you pass in. Don't be afraid to use new objects
though; their allocation path is reasonably optimized...

(No, I don't think I can change how it does reference management. It's
moderately tricky. Do badger me to put some notes on this in the C-level
documentation...)

> TIP#244 shouldn't require changes in Tcl to handle the building that I can 
> think of--that's all on the #234 (zlib) side, unless zlib being optional 
> at build time was still on the table (I though it wasn't) and you for some 
> reason still want to build #244 into Tk with #234 disabled in Tcl.  That 
> wouldn't be my recommendation. :P
> 
> ...or, maybe you meant #234 rather than #244 in your statement.

Right now, the #234 implementation isn't yet done to the degree to which
it should be. In particular, there's a need for more autogoo and a
compatibility inclusion of the zlib sources from a known good version.
(I've done enough that it can detect whether what is available on the
system is sufficient to support #234's features, but not actually the
replacement stuff yet: I'm not on a platform where I need to do that...)
Oh, and there's one feature not yet done.

But from your comments I think you're able to get on and use the APIs
that are there and working already. Well, so long as you are on a
platform with a good enough system zlib. :-)

Donal.