[MonoDevelop] Suggested change to navigation drop-down behaviour

[IBBoard]

Replies in-line :)

On 03/07/10 15:10, Mike Krüger wrote:
> Hi
>> 1) It would be nice to be able to click to show the list and click to
>> hide. Currently the second click hides and re-opens the list, but the
>> widget renders more like a toggle button.
> I'll look into that - seems to be a bug.
>>
>> 2) Delegates seem to be handled a bit strangely. 
> Ok put delegates on the list (the invoke is a method I internally
> generate for delegate types - shouldn't show up).

I did wonder whether it was something internal that didn't make sense to
users.

>> 3) If I add a region to my code then it breaks the click on the first
>> button (the file). Clicking on the file only shows the region as an
>> option, which means you can't use the nav to get to methods and classes
>> outside regions
> The first box just shows the regions and let's you select arbitrary
> regions - but doesn't filter the following ones (doesn't make real sense
> after trying it).

If the first box is regions, or just the file name if there aren't any
regions, then I think you might need to keep the file name option or
something similar as a "no region" option, since some people will region
some but not all of their code.

> It's a bit tricky to show the regions - that's why it's a bit
> unintuitive, but I think this behavior is the best solution. If anyone
> has a better idea I would like to hear it.

What I was expecting was for it to be in the nav hierarchy at whatever
point it was at in the logical context of the code. More on that below,
but perhaps I'm making incorrect assumptions on region usage.

>> 4) Regions seem to show at the start of the list rather than where they
>> are in the hierarchy. If I put a region inside the class and put my
>> cursor on the class then I can't see the region in the nav, but if I
>> click in the region then the nav shows the region first, then the class,
>> then the methods of the class that are within the region.
>>
>>    
> That's because regions are more file specific than type specific ...
> putting the regions into the type hierarchy wouldn't give a good
> overview of the regions - wouldn't it ? I prefer to have the regions
> separate for the files - is this wrong (I would like some opinions about
> that after trying out the current SVN version).

I see what you mean in that way, but at the same time then I might use
regions to break up and group methods within my class. If that's the
case and if I have multiple classes per file then navigation would seem
to make more sense to me if it showed the regions within the class so
that you could see the file was structured as:

File -> Namespace -> Class -> Region -> Method

or even mixing region levels in one class:

File -> Namespace -> Class -> Region -> Method
                  -> Region -> Delegates

Or the really horrendous nesting:

File -> Region -> Namespace -> Region -> Class -> Region -> Methods
                                               -> Region 2 -> Methods
                                      -> Delegates
                            -> Region B -> Different class ...

At the moment the navigation will show all of those regions as top level
items and not let you get at anything outside the regions once you've
clicked on one unless you click in the text editor. What I'd expect and
find it easier to work with for navigation is something closer to the
ASCII nesting above where each region appears at the level in the code
hierarchy as it is written at.

Hopefully that explains what I meant. I can whip up some code samples if
the text isn't clear :)


>> The general behaviour of being more flexible in length and looking more
>> like a widget designed for a purpose instead of a bunch of widgets used
>> to make something approximately right (even if that is what Visual
>> Studio does) is definitely an improvement. The region handling is also
>> going in the right direction, even if it isn't quite there yet. Overall,
>> it looks good so far :)
>>
>>    
> Nice to hear that this is going in the right direction. The great
> strength of the new control is that it is better than the old one
> showing the current position & taking less space for the same job.
> I'm not 100% satisfied with it yet,  but I've some months left to
> streamline it for the 2.6 release :)
> (As well as the version control file views)
> 
> Regards
> Mike

I'll see what I can do to help and contribute and hopefully not annoy
you too much :)