STR #2360: Proposal re. Events Diagnostics

STR #2360

Application:	FLTK Library
Status:	5 - New
Priority:	1 - Request for Enhancement, e.g. asking for a feature
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Unassigned
Summary:	Proposal re. Events Diagnostics
Version:	2.0-feature
Created By:	rainbowsally
Assigned To:	Unassigned
Fix Version:	Unassigned
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Post File

#1	rainbowsally 08:39 May 01, 2010

event-toys-2.0-r7513.tar.gz
21k

Trouble Report Comments:

Post Text

#1	rainbowsally 05:20 May 01, 2010

Events diagnostics. ----------------- In run.cxx we see the following. #if 0 // set to 1 to dump to console non 0 events from this function # define DUMP_EVENTS # include <stdio.h> #endif And in the fltk::handler code we see this. #ifdef DUMP_EVENTS static unsigned long evtnum=0L; if (event) printf("event name = %8lu %s\n", ++evtnum, fltk::event_name(event)); #endif ----------------- It's clear that this needs to be compiled-in and will only ever be used by developers. Not only that but there isn't much that can be done with such a simplified display. Like, what object is getting receiving this event, and did it process it? So I propose (and will do it) a diagnostic event hook, that runs before any of the other stuff (not just an add_event_handler() which only runs AFTER an object misbehaves and as a hook it can be set and reset even in a system that's already been compiled. Why should we put this into the released system? Because there ARE no developers! If we want any, we need to make it a bit more feasible to explore what's already here, and it's a beauty! Tons of problems, but all of them minor. So! I'm beginning phase 4 of My Life And Times with fltk. It is no longer possible to continue with an unmodified base system, and this adds to the danger of more missing files, more dysfunctional demos, etc. as we forget that we have features others don't. But if I can create an installer that will work with Knoppix Live (and it should) I'll upload what I have (the ENTIRE system - as it is on my drives) so that anyone that is interested can see a working example WITH all the parts present. What fltk v 2.0 was 'supposed' to be. (All the parts except maybe plugins and/or themes--started but not finished yet. That may take a bit more time.) It will install into a user's $HOME folder. No globals. No superuser privileges. And comes with an uninstaller that doesn't rely on presence of the installation files. I will NOT write the official release, however. But once you have working code it's much easier to modify it than to get it to work in the first place. THANK YOU Bill Spizak and others! :-) More on this zero-risk Live CD test installation later. For now I'm just explaining why I think I need to make one significant change (not just a bug fix) to how the events dispatcher works. I made this 'hook' recommendation in v1, was surprised to see that we do have it in v2 (in addition to the debugging #define above), but the built-in handler hook runs too late to be of much help in the case of the misbehaving scrollbars. Curious? Want more info? Don't understand? Think it won't work? See handler_link in (I think it was) run.cxx. We're going to put another similar link, named 'handler_hook' that runs before, and possibly instead of the normal fltk::handler() by making the normal handler the one and only address in the hook, which can then be gotten by simply replacing it by a new hook, much as Windows (in straight C) does subclassing by means of Get/SetWindowLong().

#2	rainbowsally 08:38 May 01, 2010

[Not sure I'm doing this right... but here goes...] re: Events diagnostics. 'Tis done. And here's what we can now see. I'll tell you what I know about it in a sec, but notice that we get a 'MOVE' event from fltk with a null window pointer below. I'll group the events so that the XEvent that triggers the fltk response is at the top. fltk::Window = 0x0804B598, fltk::xevent = 21 ReparentNotify fltl::Window = 0x0804B598, fltk::event = 0 fltk::NO_EVENT fltl::Window = 0x00000000, fltk::event = 11 fltk::MOVE fltk::Window = 0x0804B598, fltk::xevent = 22 ConfigureNotify fltl::Window = 0x0804B598, fltk::event = 0 fltk::NO_EVENT fltk::Window = 0x0804B598, fltk::xevent = 19 MapNotify fltl::Window = 0x0804B598, fltk::event = 0 fltk::NO_EVENT fltk::Window = 0x0804B598, fltk::xevent = 9 FocusIn fltk::Window = 0x0804B598, fltk::xevent = 11 KeymapNotify fltl::Window = 0x0804B598, fltk::event = 0 fltk::NO_EVENT fltk::Window = 0x0804B598, fltk::xevent = 12 Expose fltl::Window = 0x00000000, fltk::event = 11 fltk::MOVE fltk::Window = 0x0804B598, fltk::xevent = 19 MapNotify fltl::Window = 0x0804B598, fltk::event = 0 fltk::NO_EVENT fltk::Window = 0x0804B598, fltk::xevent = 12 Expose fltl::Window = 0x00000000, fltk::event = 11 fltk::MOVE fltk::Window = 0x0804B598, fltk::xevent = 33 ClientMessage fltl::Window = 0x00000000, fltk::event = 11 fltk::MOVE ---------------- In version 1 I saw these FL_NO_EVENTS flowing through quite often and they are not a problem. You can set your callbacks to receive them when you select them (in fluid) to go off on [no event] and [always], or something to that effect. I can't remember exactly, but bottom line here is that this is normal behavior. But what I never did see is a null window pointer, especially one with a MOVE type. This may actually be ok in version 2. I don't know yet, but what I want to point out at this point is that WE CAN SEE!! :-) Here's the modified files to play with so far, if you so desire. Keep backups. Best to merge the code rather than replace your entire file, but live dangerously if you like. This should be ok with the "current" fltk v-2.0. (merged with r7513) If these files don't work for you, hang on. We'll get something to play with working eventually. [I'll try to send the files in another post.] ------------ Now comes the long journey... what do images, scrollbars and other widgets that aren't updating properly have in common? Why aren't they "getting the message" to update themselves. Well, scrollbars DO correct themselves when you resize the window. So that's where I'll start. Object = scrollbar, event = resize, and let's see how and why that works. This may take a while...