[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fenfire-dev] PEG NodeTypeManager (#3)
From: |
Tuomas Lukka |
Subject: |
Re: [Fenfire-dev] PEG NodeTypeManager (#3) |
Date: |
Wed, 10 Sep 2003 12:22:56 +0300 |
User-agent: |
Mutt/1.5.4i |
On Wed, Sep 10, 2003 at 11:57:58AM +0300, Asko Soukka wrote:
> ==========================================================================
> PEG view_nodetypemanager--humppake: NodeTypeManager
> ==========================================================================
>
> :Authors: Asko Soukka
> :Date-Created: 2003-09-09
> :Last-Modified: $Date: 2003/09/10 05:33:13 $
> :Revision: $Revision: 1.5 $
> :Status: Current
> :Stakeholders: tjl, mudyc
> :Scope: Minor
> :Type: Interface
>
> This PEG introduces a new interface to generalize the handling of
> different (visual) node types in Fenfire.
>
> The visualization of ImageScrollBlock in Fenfire requires a new
> nodetype besides the current node types for 2DCanvases (papers) and
> PageScrollBlocks (PDFs). Unfortunately, the selecting between those
> two node types is fixed in the current code. The interface introduced
> by this PEG is needed to generalize the way of handling several
> different node types and therefore make it easier to add new types
> also later on.
>
> Issues
> ======
>
> Are node types relevant anywhere else than in visualization?
>
> RESOLVED: Yes, they are. We have been planning the use of
> local keybindings depending on the type of the current main
> node (know also as *plane*, or *focus*).
>
> What methods the use of node type dependent keybindings would need from
> interface ``NodeTypeManager``?
>
> RESOLVED: The module handling keybindings has no particular use
> for
> AbstractNodeType2D designed for visualization (and it using it
> would
> make the architecture less flexible), but a simple Id
> specifying the node type would be enough and simpler to use:
>
> int getNodeTypeId(Object o);
>
> NOTE: The class implementing ``NodeTypeManager`` should define
> constants for
> return vales of ``getNodeTypeId``.
>
> RE-RESOLVED: String as the return value has less restrictions.
> Why int? Why not, e.g., String or URL?
>
> RESOLVED: Right. Int as the return value would be too dangerous,
> because we can't control that two distinct applitudes (developed
> without knowing each other) don't use overlapping values.
>
> Using string allows e.g. usage of URN-5 as an unique
> identifier for a node type.
>
> Let it be::
>
> String getNodeTypeId(Object o);
>
> RE-RESOLVED: Object as the return value has even less restrictions
> :)
>
> Why String? Why not Object?
>
> RESOLVED: Yeah, right... Using object allows e.g. usage of
> individual
> nodes as an unique identifier for a node type.
>
> Let it be::
>
> Object getNodeTypeId(Object o);
I already mentioned these: the issue should be complete or explicitly refer
to another issue. "Why int?" -- *WHAT* should be int?
Tuomas