Re: [RFA] New Event Model Prototype

[Jim Ingham <jingham@apple.com>]

Fernando & Keith,

Yes, this is what I had in mind.

One of the other things that I was thinking to handle in GDBWin was the 
logic of tracking all the windows that logically belong to a single 
thread, or a single processor - when we get to the point were gdb & 
insight can support that.  That lives above the level of ManagedWin, 
since ManagedWin doesn't know that this variable display & this register 
display & this stack display belong to thread 1, etc...  Someone needs 
to do this, since it would be great to be able to hide info about one 
thread, then reveal it again.  Ditto for processors (like the CPU & the 
DSP, or multiprocessor systems or what not...

But it is also quite appropriate for it to inherit from GDBEvent.

You can do busy-ing from plain Tk, without BLT busy, but is is much more 
labor intensive, since you have to go tell each widget not to 
respond...  This is the sort of thing that having some more 
responder-chain based framework makes really easy (like MacApp, 
PowerPlant, Cocoa, etc...)  But with Tk, you really have to go disable 
everything, AND go spin the cursor on everything...  Not as convenient.  
But "busy" makes this utterly trivial.

BTW, Ioi has surfaced recently and released an update to Tix...  I don't 
know whether this represents much work or not, but it is interesting 
anyway...

Note also that BLT is already in the Cygnus repository, IIRC.  So it is 
just a matter of adding it to the Insight slice of the tree.  AND, it 
would be kind of cool to have the graphing capabilities easily 
available.  You could really easily hook up some of the variable history 
stuff that DDD does, but in BLT it would more slick & active...  For 
instance, BLT has a strip chart, so you could do live tracing with 
breakpoints with "continue" commands that feed into the strip chart.

If we were still doing the tracepoint stuff, for instance, it would be 
neat to take all the points that a given variable was collected, plot 
them, and then allow the user to click on the plot points to put the 
rest of gdb into the state where the value was measured with that 
value...

Enough drivel for now...

Jim

> Keith Seitz wrote:
>>
>> On Fri, 13 Apr 2001, Fernando Nasser wrote:
>>
>>> Keith Seitz wrote:
>>>> it seems that it really would be better to call it something like
>>>> GDBEvent or GdbEvent (gdbevent.it[hb]).
>>
>>> Jim's suggestion is to create _another_ new file (gdbevent.it? or
>>> whatever),
>>> not to rename GDBWin.  He even suggested that GDBWin inherits from 
>>> this,
>>> so the objects that are windows do not have to explicitly get 
>>> GDBEvents
>>> in.  Conversely, non-windows objects can inherit GDBEvents directly.
>>
>> Hmmmm.... Ok, I think I see where this is headed. I can only think of 
>> one
>> or two uses for this right now, but maybe more opportunities for this
>> will arise in the future.
>>
>> So, I'll make a new GDBEvent and have GDBWin inherit from that. Then 
>> I'll
>> move the GDBWin event stuff into these files and leave GDBWin empty,
>> since we don't have anything for it just yet. (I presume we intend to 
>> add
>> some sort of default busy/idle handling and some such.)
>>
>> Am I getting closer?
>
> I think you've nailed it.
>
> The busy/idle handling is badly needed.  Jim wanted to use BLT's "busy"
> for that, but we wanted to convert out of Tix so we don't grow the
> source tree too much.  The only thing that is holding us is the Tix tree
> in the variables.tcl, for which we wanted to use the BLT tree (the other
> Tix widgets have corresponding iwidgets available).
>
> Cheers,
> Fernando
>
> --
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb