I don't think the other side needs to be a special subclass of a block,
nor does it need any attributes that makes it different from another block
John
Phillip J. Eby wrote:
You guys need to clarify what you're proposing the other side should
be called. A BranchPoint is the place where a Branch gets plugged in,
so that would seem to imply you're proposing the other side be called
Graft. :)
At 03:26 PM 10/10/2005 -0700, Andi Vajda wrote:
+1 on GraftPoint as well, that makes us 3 now....
Andi..
On Mon, 10 Oct 2005, Ted Leung wrote:
I'm catching up on mail and didn't see a vote result, so...
I'm +1 for GraftPoint...
By my count it's:
BranchPoint - 4
Branch - 2
BranchPoint Block - 1
DetailBranch - 1
BranchBlock - 1
GraftPoint - 2
On Oct 6, 2005, at 11:26 AM, Katie Capps Parlante wrote:
BranchPoint/Branch/DetailBranch as described below.
Cheers,
Katie
Bryan Stearns wrote:
(Clarification: I'm interpreting PJE's suggestion as "BranchPoint"
for the class currently named TrunkParentBlock, which hosts a
"Branch" (the class currently named "TrunkSubtree", which I hadn't
mentioned previously to keep the discussion simple. There's a
related class currently, DetailTrunkSubtree, which would naturally
become "DetailBranch" under this scheme.)
...Bryan
Alec Flett wrote:
+1 for BranchPoint, followed by Branch if there is an instant-runoff
Alec
Bryan Stearns wrote:
Thanks to everyone who responded to my message below. Because
there were so many suggestions, and new suggestions were made as
recently as this morning, I'm putting them all up for vote:
John suggested:
- TreeSocket
- TreeRoot
- TreeRootSocket
- SocketBlock
Alec suggested:
- BranchBlock
- SwitchBlock
Philippe suggested:
- TrunkRoot
Katie suggested:
- TreeHook
- TreeExtensionPoint
- PlantationPoint
- ExtensionBlock
Donn suggested (and Jeffrey & Phillipe +1'd):
- BranchPointBlock/BranchBlock
PJE suggested "visual extension point" and "GUI plugin point",
leading to classnames, but later evolved Donn's suggestions to:
- BranchPoint/Branch
So: please vote for your favorite, today.
...Bryan
Bryan Stearns wrote:
Many people have complained that the TrunkParentBlock mechanism
has a crappy name. I'm soliciting new names.
Here's an overview of the mechanism to help you understand what
it's for:
CPIA represents the UI world as a hierarchy of blocks: the root
of the hierarchy is a block that corresponds to the outermost
frame window, and every two-dimensional space within is
represented by a child block in this hierarchy.
For the most part, huge chunks of this hierarchy are "static":
For instance, the sidebar is composed of a little sub-hierarchy
of blocks whose relationship is invariant; some blocks may not
always be visible, but the hierarchy always looks like this:
- SidebarContainer
- Sidebar
- PreviewAndMiniCalendar
- PreviewArea
- MiniCalendar
However, in other places in our grand hierarchy of blocks, we
need to be able to dynamically change a subtree hanging off
that particular point. It happens that there are three places
where we do this currently:
- The most obvious case of this is the detail view: depending
on what kind of item you've got selected in the summary or
calendar, a particular "tree of blocks" is built for displaying
that kind of item, and that's what you see in the detail view.
- If you think about it, you'll realize that this also happens
at the point between the sidebar and the main content area:
depending on what collections or views you've got selected in
the sidebar, you'll see a different tree of blocks displayed in
the main content area: the summary table + DV, the calendar +
DV, the repository viewer, etc.
- We also have one of these points at the very root of the
block hierarchy; this is the way John implemented "skins".
So, back to naming: The block off of which we hang these trees
of blocks is currently named TrunkParentBlock, because it's the
parent to a single block, the 'trunk', of one of these trees of
blocks.
We can't use "view", which already has special meaning for
certain blocks at other points in the tree.
Any other ideas?
Thanks,
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
