Advance notice: Changes to the Source Window classes

Advance notice: Changes to the Source Window classes

[Fernando Nasser]

Please feel free to comment on these changes.

In the first stage of Source Window rewrite, the following classes will
be created/changed:

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.

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.


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

Re: Advance notice: Changes to the Source Window classes

[Steven Johnson]

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

Will do...

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

Will this mean that a user can customise Insight with their own (local to their
project) set of menus? Without having to add stuff into Insight proper.

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

Will this mean that we will be able to finally see assembler code when Insight
has no symbol information for the location of PC.


Steven Johnson

Re: Advance notice: Changes to the Source Window classes

[Fernando Nasser]

Steven Johnson wrote:
> 
> Fernando Nasser wrote:
> >
> > Please feel free to comment on these changes.
> >
> >
> 
> Will do...
> 
Thanks.

> > 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.
> >
> 
> Will this mean that a user can customise Insight with their own (local to their
> project) set of menus? Without having to add stuff into Insight proper.
> 
Partially true: you will be able to add "plug-in" windows to the View menu.

There are two goals:

1) Allow us to configure or not Windows that should only exist for certain targets
or that showld be configured differently for each target.

2) Allow "plug-in" windows (conditionally) to the View menu.


> > 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.
> >
> 
> Will this mean that we will be able to finally see assembler code when Insight
> has no symbol information for the location of PC.
> 

Yes, you've got it.  I am cleaning things up so I can work on it without
breaking things.


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

Re: Advance notice: Changes to the Source Window classes

[Keith Seitz]

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

Re: Advance notice: Changes to the Source Window classes

[Fernando Nasser]

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