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


Keith Seitz wrote:
> 
> 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!
> 

And thank you.  Part of these things come from your suggestions, as well as some
other people who may be recognizing their ideas in this.  Thank you all.


> 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?
> 

The idea is to make it possible to use GDBMenuBar (and GDBToolBar) in other
windows as well.  The main reason to have our own widget is to add some features
to make it easier to disable/enable things.


> > 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.
> 

In my perception a "menu bar" as menus in it, and a toolbar is an icon oriented
widget.  That is where the names came from.

I am not picky with the names, I can change them if you like.
The GDBMenuBar is a generic MenuBar.  Of course, the Source Window will have
only one, as will any other window that uses this class.
Likewise, GDBToolBar is a generic toolbar handler.

The GDBSrcBar is something specific for the Source Window to use.  Should I take
the "GDB" prefix from the name, reserving the "GDB" prefix just for classes that
are really generic?


> 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".
> 

That is the idea.

And I thought of the possibility of using 2 of these to implement the Source Window
toll bar because of the address box in the middle.

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

Please don't!  You are a very important part of this process.


> >
> > 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.)
> 

It is everybody's nightmare.  I will take an incremental approach for it.
First to be sure things continue to work, and also so I can cope with the
complexity.

I have a feeling (I may be wrong) that as we reorganize it things will look
gradually less complicated.


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

Thanks for your encouragement.  I will probably need it :-)

There is lots of people to give thanks for being able to do this (you included).


-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

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