[Mono-docs-list] Tab Navigation

Miguel de Icaza miguel@ximian.com
Mon, 15 Nov 2004 20:23:25 -0500


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

The history.cs file is 63 lines of code.  The history manipulation is a
trivial piece of the code, so creating two classes to manage the history
seemed to overdone.

The long story is that in general, am not a fan of over-engineering and
over-architecting.  I like code that does that it is supposed to do

If we need to make changes, I would love to hear the limitations that
you have faced, so we can make those changes. 

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

The `history.cs' file is the GUI class that manages both UI and the
history.   Splitting it in two seems a bit pointless.

There are two different implementations of PageVisits: the reason is
that there are two sources of history events: the tree on the right
which uses nodes, and urls which come from the browser.

The details of this are hidden behind this.

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

Your design should be changed so that each "Tab" owns its own history
(the history as I said controls both the node and the pages), and when
you open a new window, just start with a fresh history.