[Gtk-sharp-list] Re: [Mono-devel-list] A larger patch for the monodoc-browser

[Ben Maurer]

Miguel,

The difference between "copy" and "select all" is that copy selects the
things that are currently highlighted, select all highlights everything
(but does not copy). (there is probably something like this in evo, I
don't know because I am on Outlook/Windows right now).

As for the "expand/collapse all", I agree that expanding "all" is not
useful, however, collapsing all can be (that should not be time
consuming). However, I think that it is more appropriate to show these
types of options when the node in the treeview is right clicked on.
However, this feeling is from my years of Windows GUI experience, and
might not be at all related to the Gnome guidelines. 

Personally, I think that the indexing code should not be the sort of
"provider" mode that you are thinking of. Doing that would mean that
just to _display_ the index would require memory for a million index
items!!! There is a company called Syncfusion that makes a grid
component for SWF. The component, they brag, is able to handle BILLIONS
of items. How do they do it? Each data provider implements something
like this:

public abstract class DataProvider {
	abstract DataItemCollection GetDataItems (int begin, int
numItems);
	abstract int Count {get;}
}

So I think we would want to have something like:

pubic abstract class IndexProvider {
	abstract IndexItemCollection GetItemsStartingWith (string str,
int numItemsAbove, int numItemsBelow);
	abstract int Count {get;}
}

The important thing to note is that you would _not_ need to convert all
the data to C# objects, only the ones that you need to use at the
moment. 

Sincerely,
Ben Maurer

-----Original Message-----
From: gtk-sharp-list-admin@lists.ximian.com
[mailto:gtk-sharp-list-admin@lists.ximian.com] On Behalf Of Miguel de
Icaza
Sent: Tuesday, May 20, 2003 5:24 PM
To: Philip Van Hoof
Cc: mono-devel-list@ximian.com; gtk-sharp-list@lists.ximian.com;
duncan@ximian.com
Subject: [Gtk-sharp-list] Re: [Mono-devel-list] A larger patch for the
monodoc-browser

Hello Philip,

   [ Gtk# TreeModel experts: there is some help I need here]

   Thanks a lot for your patch submission, and I want to apologize for
my slow reply time.  Here are some of my comments:

> - I added a few menu-items
>   (I've already send a patch with these changes a few hours ago)
> 
> 	File->Exit
> 	Edit->Copy
> 	Edit->Select All
> 	View->Expand All
> 	View->Collapse All
> 	Help->About

What is the difference between "Select all" and "Copy"?

I am not sure I like the idea of having "View/Expand All", that is
likely a very time consuming process.  I would be ok with "View/Expand
all children" though.

> - I finished the "Index"-tabpage: If you type in "System" and enter
then
>   the listbox will be filled with all the classes in the namespace
>   "System". Clicking on such an item will take you to it's
>   documentation. Note: You can use Regular Expressions here.

I think that this is really a "Search" feature.  

That being said, my long term plans are to use a text indexing engine
that would index the contents, so the search is performed on that,
rather than being performed on the captions which is not as useful.  So
this would just be a temporary solution.

As for the Index: I have checked in my code for creating an index, but
it is not completed yet.  The new indexing code principle is that each
provider would "populate" the table of contents with information that
people would look for.   Once the data is populated, a compact index is
written out.  Then this is used to present a list that the user can
browser, or can be used to dynamically search the index. 

Very much like the Microsoft help  browser for the .NET framework.

Now, the shortcomings (and you are free to get involved here):

	* The providers are not populating all the data they should,
	  currently they are only doing this for the proof-of-concept,
	  bootstrap phase.

	* There is no compression of text.  And there is quite a lot of
	  redundancy, so index files are very large.
	
	* I have not written the widget to display this information.

	  Since the index might contain millions of rows, it is not
	  possible to load the information in memory, nor use the
	  standard "Gtk.TreeModel" stores, because it would just consume
	  too much memory to just display.

	  Few options:

		* Create a wrapper that would allow C# code to implement
	  	  the tree models with managed code, without having
		  to "populate" them.

		* Create a new list-widget (not hard to do, but would be
	  	  a duplication of effort) for browsing it.

So could you rework your patch a bit to cope with this?

You did a great job.  I wonder if I can get you interested on taking on
some of the other pieces missing in Monodoc (there is a "NOTES" file in
monodoc/browser with various pending items).

Miguel.
_______________________________________________
Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list