[Mono-docs-list] Tab Navigation

[Joshua Tauberer]

Hi, Mario.  I'm finally getting around to looking at the tab navigation 
patch.  It was a good idea.

First some comments about using it.

When I open a new tab it shows a "blank" page.  It should either show 
the Mono Documentation root page, or it should show the same page that 
is currently being shown.  Maybe it's just me, but the height of the 
tabs themselves is really large -- about two lines high, but only one 
line of text will be displayed in them.

Also, the titles of the tabs is problematic.  When I look at the members 
listing for a type, the tab title is "Members" which makes it impossible 
to distinguish it from other tabs showing the members of other types. 
(Okay, I even suggested how to get the titles, I know.)   You may need 
to grab the parent node's text in the tree too.  You'll have to play 
around with it to see what works best.

The New Tab tool should be on the toolbar too.

You can't be editing in more than one tab at a time.  When you try to 
edit in a second tab, you get a blank area.  You can go two routes: make 
editing work in multiple tabs, or just really limit it to one tab. 
Limiting it to one tab is better for now, and if you do this you should 
be able to keep more of the code related to editing unchanged.

(Maybe better yet, when the user clicks an "[edit]" link, put the 
editing widgets into another tab, so you can switch between editing 
something and the page you were editing.  Otherwise, you could go the 
easy route and just hide the tabs entirely when the user is in editing 
mode.)

I haven't quite figured out how you have the back and forward buttons 
tied nicely with the active tab, but good work there.

Now for comments about the code itself.  Some of this stuff gets picky.

You made a lot of things 'internal', but they should just be 'public'. 
Browser.exe isn't meant to be referenced by another assembly, so there's 
no real distinction, so public is easier to follow (and everything else 
seems to be either public or private).  Try to keep widgets private.

There were a few lines in the diff that were only different by a 
trailing space.  Try to remove these before sending the diff so there 
aren't lines marked as different that didn't really change.

In browser.glade, it looks like a lot of things were unnecessarily 
changed.  Do we need <requires lib="gnome"/> and the new <property.../> 
nodes at the top and elsewhere?  (I don't know what they do.)  Also lots 
of id attributes changed.  It's easier to follow diffs without changes 
like this.  Can you revert the file and make only the changes you need 
by hand?

And, as I said above, it would be good to keep more of the editing code 
unchanged, especially if the user can still only edit one thing at a time.

So... good luck!

-- 
- Joshua Tauberer

http://taubz.for.net

** Nothing Unreal Exists **



Mario Sopena Novales wrote:
> Hallo guys!
>   I've posted a week or so saying I was working on displaying multiples tabs on
> a page (thanks Joshua). In the way of getting it I have found something in the
> code of monodoc I dislike. The actual implementation of the History.
> 
> There is an object History that is supposed to managed the history (any magic
> here), but for me makes no sense that this object shall manage too the code of
> the buttons back and forward. Shouldn't the events of the buttons been managed
> by the browser itself? For me makes sense that the History was an object that
> manages only history data (a real abstraction of a history) and not GUI data
> too.
> 
> Besides that, what is suppose that the class PageVisit should do? It is only for
> letting the object History to call the browser to actualize himself? Isn't this
> a mess or I'm missing something? If the implementation of the History were
> managing only history data, and the browser, GUI data, I think the browser could
> actualize himself. What do you think? I'm missing the point?
> 
> Ok, at this point, somebody is thinking what the h... smokes this guy? Well, I,
> actually, don't smoke, but all of this comes from my implementation of tabs. I
> want to make a Tab object (and a list of them) that manages all of the data
> related to a tab (his history and a reference to the areas for rendering the
> content by the moment). With the actual implementation of history I'm not
> pretty sure of how to do that.
> 
> That's all. If anyone has arrived here, please post an answer (or send me money,
> it's up to you).
> 
> Bye!
> 
> Mario Sopena
>