This is the mail archive of the insight@sources.redhat.com mailing list for the Insight project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Advance notice: Changes to the Source Window classes


Fernando Nasser wrote:
> 
> Please feel free to comment on these changes.
> 

First: let me say, "God bless!" Someone's working on Insight and taking
it in the right direction!! Thank you!

This all sounds really, really good. I presume that we're going to have
classes for actual menus and buttons, from which we can inherit basic
properties? Are you planning on roughing out an interface for these
super classes that we can peek at?

> GDBMenuBar   -  New class.  Menus in which entries have the ability to be
>                 grayed and that can be present or not depending on target
>                 or operating system
> 
> GDBToolBar   -  Likewise for buttons.  Similar to the current one but without
>                 the menu part and without the routines that add entries
>                 specific to the Source Window.
> 
> GDBSrcBar    -  Uses by composition, not inheritance, the two classes above
>                 to create the menu and buttons used in the SourceWindow.
>                 A file with plug-in window definitions will be read so
>                 special windows for specific targets and operating systems
>                 can be added to the menu/toolbar.

Maybe this is a nomenclature problem (for me), but do you mean that
GDBMenuBar is the source window's menu or it is some generic class which
you may use to construct menus (and then, logically, GDBSrcBar can add
these objects to itself for display on the Source Window)? If so, I
think I would be more comfortable with calling these "GDBMenu" and
"GDBToolbarButton" or something. "GDBMenuBar" is a little misleading (if
my assumption is correct, that is): the source window should only have
one menu bar.

Contrast this now with "GDBToolBar": the source window need NOT have
only one toolbar, but we still need a generic button class to construct
toolbars. Of course, this button class would be very, very simple, but
it should expedite explanations of all the nuiances regarding the
toolbar buttons' behaviors when, for example, the inferior is "running"
or "stopped".

I suspect you probably had this all in mind, and I should probably just
go away and wait for the patches to show up! ;-)

> 
> ViewCache    -  The cache part of srctextwin, with the addition of MEMORY
>                 type which implements disassembly from memory.
> 
> SrcTextWin   -  In this first step, it is just stripped from the cache
>                 (which is created and used as an object) and handles the
>                 MEMORY case.
> 
> SrcWin       -  Just a few methods renamed.

Ahh, my old nemesis, SrcTextWin and "LoadFromCache". Yich. I feel for
you! Oddly, this should have been a very, very easy and simple thing to
do, but it turns out to be the biggest darn headache! (I know: try
'clearing' the SrcWin cache sometime: it took me days to figure
something out.)

Wow, really, really great to see some effort go into untangling this
embarrassing mess! Keep up the good work!

Keith

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]