IntelliPrompt Member List Tab Groups

Interesting ideas, anyone else have thoughts on this topic too?

I think that goes hand in hand with what would be needed to support the most recently used functionality we were discussing in the other thread.

As far as i see it, you would add multiple groups to the intellisense list, and each group would then have a 'tab' property. So you would probably have a 'tabs' list associated with the intellisense object, which could either be statically set up by the application at load time, or dynamically as the intellisense list is filled.

If you are doing this, it might be nice to have multiple representations - text & icon, text only, icon only.

Just my 2p worth.

I like the idea, but I would try to decouple the notion of IntelliPrompt 'groups' from their actual presentation style (e.g. tabs). Certainly with the WPF SyntaxEditor, there could be several different ways of presenting different IntelliPrompt 'groups' or 'filters', thanks to WPF's support for custom templates. Default implementations using tabs could be provided with both the WinForms and WPF SyntaxEditors.

Can you expand a bit on what you mean? Because that's what I was getting at - being able to say which tab a group was added to by setting the tab property for each group. Then if all were assigned to a single tab, or if they were null perhaps, then you wouldn't have tabs.

Or are you saying about being able to render them in some other manner?

Quote:
Can you expand a bit on what you mean? Because that's what I was getting at - being able to say which tab a group was added to by setting the tab property for each group. Then if all were assigned to a single tab, or if they were null perhaps, then you wouldn't have tabs.

Or are you saying about being able to render them in some other manner?

In WPF, there is significant distinction between the logical and visual aspects of any UI control. How the control is actually presented depends completely on the template provided. I simply recommend following this paradigm.

Boyd had suggested the option to break down IntelliPrompt members into separate tabs, as in the VB.NET code editor. The presentation model he is suggesting essentially breaks down the IntelliPrompt members into different 'groups' or 'filters', each one represented by a tab. I am simply suggesting that we follow the WPF philosophy where all controls are 'lookless' by default. Disregard the idea of how those groups/filters are presented (e.g. as separate tabs) and focus simply on the logical requirement (support for IntelliPrompt member groups/filters). Leave any references to 'tabs' out of the core language/syntax framework. Think less about how it will be presented visually, and more about the logical organization (which is similar to the grouping mechanism in ICollectionView).

Basically, I am suggesting that each IntelliPrompt item/member could subscribe to multiple 'groups', and the IntelliPrompt source could define several 'filters' which restrict the items shown to those in a fixed set of groups. The default IntelliPrompt presenter in WinForms would be responsible for creating and displaying a tab for each filter. The WPF IntelliPrompt template could choose any number of ways to present a filtered IntelliPrompt control, but by default it would use tabs.

I hope that makes sense.

Well explained.

Yep that makes sense. Sorry if this is a dumb question - but how would you envisage those filters being programmed? And what benefit does that actually give? Because yeah ok I said tab, but if you called it 'representation group' then you would still have a list of objects which would contain the items what you might want to render on a tab...

So what would be the benefit of creating filters?

And please don't get me wrong, it sounds like a fantastic idea, i'm just obviously missing something and hoping you can fill me in!

My apologies for the delayed response. The idea is that one could customize the IntelliSense prompt, allow the user to filter the items that show up based on various attributes or 'groups' to which the items may subscribe. This could allow filtering based on item type, visibility, etc. Consider this mockup prompt.

Note that I'm not suggesting that the above mockup is actually a good idea, but if the API is flexible enough, then it would be pretty easy to implement something similar by applying a custom style or template to the WPF IntelliSense control.

Mike

[Modified at 08/27/2008 11:45 AM]

No worries glad to discuss it with you - always like getting good ideas and style from like minded individuals! :)

Yep sorry I think I haven't made myself clear. I'm sold on the benefits of the presentation being abstracted - and I do think your mockup makes a lot of sense btw!

But what I was wondering is how filters would work. The way I was thinking was that you would have groups, items would be in groups, and a 'tab' (or whatever) would display one or more groups.

So - pseudo code style:

Item itemA = new Item("Item 1");
Item itemB = new Item("Item 2");
Item itemC = new Item("Item 3");
Item itemD = new Item("Item 3");

Group groupA = new Group("Group 1");
Group groupB = new Group("Group 2");

groupA.Items.Add(itemA);
groupA.Items.Add(itemB);

groupB.Items.Add(itemC);
groupB.Items.Add(itemD);

........

then, when showing the intelliprompt list:

IntelliPromptTab tabA = new IntelliPromptTab("Tab 1");
IntelliPromptTab tabB = new IntelliPromptTab("Tab 2");

tabA.Groups.Add(groupA);
tabB.Groups.Add(groupA);
tabB.Groups.Add(groupB);

IntelliPromptMemberList.Tabs.Add(tabA);
IntelliPromptMemberList.Tabs.Add(tabB);

IntelliPromptMemberList.Show();

...............

So I get that it wouldn't really be called tab - that would be abstracted out - but how would the idea of filtering work in the above example (ish)? :)

Also, just tying it into the other thread - how do you think the 'most recently used' functionality would work? I am guessing that it would work the same. Thinking about it, I think it wouldn't make a lot of difference if the usage count was stored at the group level or the item level. You would still want to initially focus on the item with the most usages that matched what had been typed in...

Why not use the ICollectionView to represent a group? It has built-in support for filtering that is a standard way to filter collections in WPF.

Hi Boyd,

We could very well use ICollectionView (in fact I mentioned it in one of my posts above). But for that to work, we still need a mechanism for IntelliSense prompt items to subscribe to different groups. We could then provide a custom GroupDescription implementation to use with ICollectionView's grouping capabilities.

Cheers,
Mike

That's what I was implying... have the SE implementation of a 'Group' implement the ICollectionView interface and allow it to control the filtering.

Mike, definitely a cool mockup. I like it and what about taking it one step further. There are three types of people, those who want lots of filtering capabilities like that, those who maybe just want them occasionally for specific member list displays, and those who are old school and don't want them at all.

How about if we put a several pixel bar at the top of the prompt with the ListBox right below it. If you hover over the bar, it slides out the filtering UI similar to how auto-hide works in Docking. Maybe we put a pin button on there somewhere too so you can have it persist and just be visible all the time.

This way those who don't want to use it never see it, those who want to use is occasionally can slide it out and have it slide back when done, and those who always want it can pin it.

---

Good ideas on the grouping/filtering too.

Nice idea with the auto-hiding of the filter panel. Again, the beauty of WPF is that the presentation view can be easily customized based on what the customer wants. The requirements for an IntelliSense prompt may vary significantly based on whether the SyntaxEditor is being used for a DML/DDL language like SQL, a custom scripting language, or traditional programming languages. The customer could even change the IntelliSense prompt template in real time based on context. That's why I suggested focusing on a flexible object model that would allow the user to customize how the IntelliSense prompt is organized.

I like the auto-hide panel idea. Any thoughts on how this might be persisted by the host application? Maybe it could become part of the syntaxlanguage class, that way when the xml is stored / loaded persistence of pinning for the various groups would be automatic - as would the usage counters you would need for proper VS style intellisense... Not sure if that would be 'clean' or not from your point of view?

What is the current concensus on how the object model looks like? If i'm reading it right, we have items, which belong to item groups, which in turn are included in representation groups, with representation groups implementing icollectionview?

-------------

edit -> Just thinking - would filtering be available under WinForms / .Net 2.0 if ICollectionView was used, or would that become a WPF only feature?

[Modified at 08/27/2008 02:42 PM]

If by "representation groups" you mean filters (a reduced view of the items based on membership in a specified set of groups), then you and I are in sync.

I think so - here's a worked example. I use SE for a SQL editor, so i'll use that as a basis.

I might have some groups called 'tables', 'views', 'stored procedures', 'scalar functions', 'table functions'

So when I expand after 'SELECT * FROM ' i might want tab 1 (representation group 1) to include just 'tables'. Tab 2 might be called 'all selectable objects' - and that would include tables, views, table functions. Tab 3 might be called 'All' which would contain the same as Tab 2, plus some syntactic additions like users (for ss2000), schemas (ss2005+), databases, linked servers.

So - whether the objects that represent those tabs are manual collections into which I add the groups I want, or filters whereby I say 'i'd like groups x, y and z' wouldn't make an awful lot of difference to me...

So I guess yeah, I do mean filters. I think.

Sorry, will have to get more into WPF...

Matt makes a good point about cross-framework support for filtering. A WPF-only construct would be bad for the "common model" design goal. Instead of implementing ICollectionView, perhaps you can just model it instead.

I forgot that ICollectionView was added in .NET 3.0. Since the core framework will presumably need to run on vanilla .NET 2.0, Boyd is quite correct.

Would it be possible to have the 'add the groups to the tabs' method for the .NET 2 people, and let the WPF people take advantage of the ICollectionView?

Because if the items themselves and the groups they are in are part of the core object model - then the representation groups / filters would really be part of the presentation, and that would be very different between WPF and .NET 2 anyway...

We could always just make our own interface that had some identical things to the key parts of ICollectionView. Then have the WPF version implement ICollectionView as well as our interface.

Sounds good to me.

Have you guys given any more thought to the MRU lists for selecting most used entries like VS does? My thoughts are that if it was part of the syntax language, then the MRUs could be persisted by serialising the syntax language to XML. Alternatively, it could be the application's responsibility to persist MRU lists, if they were accessible through the object model.

Thinking about it some more, a proprietary implementation of the filters would probably be better than using ICollectionView. Performance could probably be maximized that way. You probably want to use object references (like an IntelliSenseItemGroup class) rather than strings to represent group names, too. With potentially hundreds of items or more in the results list, filtering with string comparisons would be unnecessarily costly. As long as the filters can be declaratively defined in XAML, all will be good.

I had another thought related to IntelliSense. If any of you are ReSharper users, you are probably familiar with the word-based results filtering ReSharper's IntelliSense prompt. Essentially, you can find an item much faster by keying in the first letter(s) of each word in an identifier. For instance, if you to type "NPC" (or "NPropCh", etc.), the list would show only items matching the pattern /N[_a-z0-9]*P[_a-z0-9]*C[_a-zA-Z0-9]*/. Returned items would include NotifyPropertyChangedEventArgs, NotifyPropertyChangedEventHandler, NotifyPropertyChangingEventArgs, etc. It would be really cool if the Actipro Syntax Editor's IntelliSense API had built-in support for this sort of results filtering. The rules could vary by language--it might break an identifier down into separate words based on changes in casing, use of underscores, etc. It's really an ingenius way to speed up searching; I've created a similar system for searching the navigation pad in our Smart Client, and the users love it.

BTW, those of you who are not ReSharper users should go download the trial version. Now. It will triple your productivity :).

Mike

We're starting to look into designing the features of the next gen member list now. I notice VS 2010 calls the feature "completion". Probably since the member list only displays if there is more than one or no matches when you hit ctrl+space. Do you like that name?

Also now would be the time to list any other features not in SE4 that you'd like to see related to member lists/completion. Maybe post them in a new thread. Thanks!

Both VS and ReSharper use the term "Completion List" specifically to describe the symbol/member/type popup. The term "IntelliSense" encompasses other popups as well (such as the method signature/parameter lists). I think it makes sense to follow the same naming scheme:

"Completion List" for symbol/member/type popup
"Parameter List" for method signature/parameter popup

I think Mike's right on the money :)

Will start a new thread with an idea / thought...