[sldev] Landmarks and Navigation Update 2008-05-29

[Matthew Dowd]

In one sense, I'm not to bothered if the assets are symbolic links to landmarks in a new system or landmarks in a new system are symbolic links to assets in the inventory - as long as from the end user perspective you can manipulate landmarks as assets in the inventory, within object contents and within scripts (e.g. landmark givers etc.)
 
However, in another this seems overly complicated (essentially create a new asset-like system for landmarks, create a new type of asset to be a pointer to the new landmark types, add integrity code so that you don't get hanging pointers, convert all existing landmarks into the new landmarks and replace with pointers etc....) for what is essentially a UI/presentational issue.
 
As others have said, at present the inventory handling code is too tightly integrated with the folder listing UI code. This needs to be refactored - we need a (hierarchical) collection(-like) object/class which allows the manipulation of the (filtered) inventory, and then a number of different UI classes which can operate on this class (including the current inventory folder UI, and new landmark UIs). There shouldn't be any need to change how landmarks work server-side, unless I'm missing something?
 
Matthew
 
 


Date: Sat, 31 May 2008 21:20:04 +0200From: mrfrans at gmail.comTo: sldev at lists.secondlife.comSubject: Re: [sldev] Landmarks and Navigation Update 2008-05-29What could be done is having the inventory assests be a pointer to the landmark in the new landmark system.-- Jeroen FransThe Vesuvius Grouphttp://www.thevesuviusgroup.comhttp://www.linkedin.com/in/mrfransSL: Frans Charming 
_________________________________________________________________

http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080531/0d9e8e8a/attachment.htm