Re: [Openrocket-devel] Thoughts on Decal management

[Bill K. <bk...@bi...>]

Actually the more I think about it the easier it might be. Your
getName() method got me thinking that we can already just treat the
String as if it were an opaque handle. At this point it really is, as
I have no idea if it refers to a file in a jar or the filesystem or
what.

Just like you have "public InputStream getBytes(String name)" if you
added "public long getModifiedTIme(String name)" to DecalRegistry I
can know when to reload a file.

The tricky part might be firing the ComponentChangeEvent for the right
Component[s] based upon whose appearances have which decals.

-Bill

On Sun, Dec 30, 2012 at 8:17 AM, Bill Kuker <bk...@bi...> wrote:
> Oops sent that too soon, trying to use tab :) Lemme try again.
>
> On Sun, Dec 30, 2012 at 8:16 AM, Bill Kuker <bk...@bi...> wrote:
>> If you wanted to go that way you might be able to avoid the appearance
>> builder needing a reference to the decal registry:
>>
>> class DecalProxy
>>
>>
>> On Sat, Dec 29, 2012 at 11:30 PM,  <kr...@su...> wrote:
>>> I was hoping we could get some kind of 'appearance change event' which would
>>> be fired. I can rig up the file polling system to only fire once.
>>>
>>> I have gone through a few mental exercises concerning the new code. It seems
>>> that to support the 'edit just this one' scenario is going to be tricky
>>> since the Decal object is immutable. I'm thinking the appearance builder
>>> will request an object from the DecalRegistry which is essentially opaque.
>>> It would then be used to request decal names and bytes from the registry.
>>> When one triggers the 'edit just this one' scenario, the opaque object
>>> doesn't change, but the data backing it in the registry does.
>>>
>>> This opaque could actually be an implementation of
>>>
>>> Class DecalImage {
>>> String getName();
>>> InputStream getBytes();
>>> }
>>>
>>> Class DecalProxy implements DecalImage {
>>> private DecalRegistry registry;
>>> public String getName() {
>>> return registry.getName(this);
>>> }
>>> public InputStream getBytes() {
>>> return registry.getBytes();
>>> }
>>> }
>>>
>>>
>>> The problem with this scheme is the AppearanceBuilder needs a reference to
>>> the DecalRegistry.
>>>
>>> Kevin
>>>
>>> Bill Kuker <bk...@bi...> wrote:
>>>>
>>>> Reloading all of them when one changes is no problem, but reloading
>>>> them all when "anything" changes [like the length of a nose cone]
>>>> would be bad, so I'd need something like a last changed stamp so I can
>>>> only reload an image if it has changed. If DecalRegistry had a single
>>>> lastChanged method that would do the trick.
>>>>
>>>> -Bill
>>>>
>>>> On Sat, Dec 29, 2012 at 10:43 PM,  <kr...@su...> wrote:
>>>>
>>>>
>>>>> Hey Bill,
>>>>>
>>>>> Bill Kuker <bk...@bi...> wrote:
>>>>>
>>>>>> That sounds fantastic. I wish Desktop.edit did the right thing, but
>>>>>> what can you do?
>>>>>>
>>>>>> It might make sense to
>>>>>> make Decal::getImage() return something fancier
>>>>>> than a string. I need some way to know when to call
>>>>>> DecalRegistry.getDecal(...) again because the image has changed,
>>>>>> because I "cache" the image data and need to reload it if the file has
>>>>>> changed. I put cache in quotes because really what I am doing is
>>>>>> uploading the image to the graphics hardware, and only re-upload it
>>>>>> when the image has changed. (Any caching in DecalRegistry would have
>>>>>> been useless to 3D.)
>>>>>
>>>>>
>>>>>
>>>>> I'm working on this right now. What 'more fancier' are you looking for?
>>>>> Do you want a last changed time stamp?  Is there anything wrong with
>>>>> reloading all images when one changes?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -Bill
>>>>>>
>>>>>> On Mon, Dec 24, 2012 at 9:30 AM, Kevin Ruland <kr...@su...>
>>>>>> wrote:
>>>>>>>
>>>>>>> Happy Holidays everyone!
>>>>>>>
>>>>>>> I'm traveling this week and won't have a laptop.  No code for me!
>>>>>>
>>>>>> But I will have email access.
>>>>>>
>>>>>>> I started writing a response to this email 3 times on 3 different
>>>>>>> computers and never finished it <sigh>.  Also, I thought I had ended
>>>>>>
>>>>>> up sending it, but since I didn't receive a copy, I figure something
>>>>>> bad happened.
>>>>>>
>>>>>>> I omitted all the discussion since this bit really seems to summarize
>>>>>>> all of that.  I agree with all of these bits, but there are some
>>>>>>
>>>>>> details
>>>>>>>
>>>>>>> which still need hammering.
>>>>>>>
>>>>>>> First, I am not happy with the Desktop.edit call and I doubt if it
>>>>>>
>>>>>> will
>>>>>>>
>>>>>>> even provide 20% of people with satisfaction.  It doesn't work at all
>>>>>>
>>>>>> on
>>>>>>>
>>>>>>> Linux.  On windows, it does open the default editor, however, it's
>>>>>>
>>>>>> very
>>>>>>>
>>>>>>> dependent on how the applications install themselves.  For example,
>>>>>>
>>>>>> on
>>>>>>>
>>>>>>> my windows box, I've installed The Gimp.  However, gimp does not
>>>>>>> put
>>>>>>> itself in the registry as the default editor - instead it supplies a
>>>>>>
>>>>>> new
>>>>>>>
>>>>>>> context menu item "Edit with Gimp".  So Desktop.edit() doesn't use
>>>>>>
>>>>>> the
>>>>>>>
>>>>>>> Gimp instead it uses Windows' Paint (yuck).
>>>>>>>
>>>>>>> I will implement a pretty sophisticated "Edit" dialog.  It will use
>>>>>>
>>>>>> one
>>>>>>>
>>>>>>> String preference which has two magic values or a command line. One
>>>>>>> magic value (unset or null) will be "open the fancy dialog".  Another
>>>>>>> magic value ("<SYSTEM EDITOR>"), will use Desktop.edit. Finally, a
>>>>>>> command line will include special handling for "%1" for filename
>>>>>>> substitution.
>>>>>>>
>>>>>>> The fancy dialog will have a:
>>>>>>> - text box to enter the command line
>>>>>>> - A file chooser to select the executable (this will then populate
>>>>>>
>>>>>> the
>>>>>>>
>>>>>>> command line text box)
>>>>>>> - a check box for "use system default editor" (this check box will
>>>>>>
>>>>>> only
>>>>>>>
>>>>>>> be visible if the Desktop.isSupported( Desktop.Action.Edit) is true)
>>>>>>> - a radio for "just this one or all"- the radio will only be visible
>>>>>>
>>>>>> if
>>>>>>>
>>>>>>> the same decal id is used in multiple components.
>>>>>>> - a button for "Cancel"
>>>>>>> - a button for "Do it"
>>>>>>> - a button for "Do it this way all the
>>>>>>> time" which will save the
>>>>>>
>>>>>> setting
>>>>>>>
>>>>>>> into preferences.
>>>>>>>
>>>>>>> The preference editor will have an entry with a radio for: "prompt",
>>>>>>> "use system editor", "text box to enter command line". I don't really
>>>>>>> want to put a file browser here, but it would be nice.
>>>>>>>
>>>>>>> So when you press "edit" in the Appearance tab - different things can
>>>>>>> happen depending on the setting of the preference and how many times
>>>>>>
>>>>>> the
>>>>>>>
>>>>>>> decal is used.
>>>>>>>
>>>>>>> 1) preference set and decal used once - do the edit thing.
>>>>>>> 2) preference set and decal used mutliple times - open simple dialog
>>>>>>> with two buttons "just this one", "edit all locations its used"
>>>>>>> 3) preference not set - use fancy dialog.
>>>>>>>
>>>>>>> The
>>>>>>> DecalRegistry will end up being a real registry.  It will
>>>>>>
>>>>>> basically
>>>>>>>
>>>>>>> keep track of which decal ids are used by which components.  It will
>>>>>>> also be used to get the bytes (which the 3d system needs as an
>>>>>>> InputStream).  Whenever the appearance on a component is modified, a
>>>>>>> call to the registry will be made to update the internal mapping.  If
>>>>>>
>>>>>> a
>>>>>>>
>>>>>>> decal is no longer used by any component, any associated file
>>>>>>
>>>>>> modified
>>>>>>>
>>>>>>> listeners will be removed.
>>>>>>>
>>>>>>> Kevin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/22/2012 5:19 AM, Sampo Niskanen wrote:
>>>>>>>>
>>>>>>>> Hi Kevin,
>>>>>>>> <
>>>>>>>
>>>>>>> Bunch of omitted text>
>>>>>>>
>>>>>>>> So wrapping up, how would this sound:
>>>>>>>>
>>>>>>>>
>>>>>>>> The component decal selection dialog would have an "Edit decal"
>>>>>>>> button.  Pressing it would:
>>>>>>>> - if the decal is used in multiple places, ask the user whether they
>>>>>>>> want to edit only the one decal or all of them
>>>>>>>> - save the decal into a temporary file (even if it is directly on
>>>>>>
>>>>>> the
>>>>>>>>
>>>>>>>> file system, me thinks)
>>>>>>>> - launch the image editor (either using Desktop or
>>>>>>>> from a
>>>>>>
>>>>>> user-defined
>>>>>>>>
>>>>>>>> program in the preferences)
>>>>>>>> - if launching fails, prompt the user to select which application to
>>>>>>>> use for editing, and store that to the preferences
>>>>>>>>
>>>>>>>> The File -> Export decal... item would allow selecting a decal from
>>>>>>>> the registry and saving it to a user-defined location on the disk.
>>>>>>>> This would not be automatically referenced from the document.  It
>>>>>>>> could contain a note that you can edit decals also directly from the
>>>>>>>> component dialog.
>>>>>>>>
>>>>>>>>
>>>>>>>> On the implementation side:
>>>>>>>>
>>>>>>>> - The components contain some kind of decal ID for referencing
>>>>>>
>>>>>> decals.
>>>>>>>>
>>>>>>>> This can either be directly the file name displayed in the UI (in
>>>>>>>> which case they must be guaranteed to be unique) or an object with a
>>>>>>>> name and some other properties.
>>>>>>>> - Each document contains a DecalRegistry / DecalResolver, which
>>>>>>>> converts the ID into bytes or an Image object.  (I'm a bit
>>>>>>
>>>>>> ambivalent
>>>>>>>>
>>>>>>>> on whether parsing the bytes into an image should be done by the 3D
>>>>>>>> code or the registry / loader.  I guess the registry needs to have
>>>>>>
>>>>>> the
>>>>>>>>
>>>>>>>> getImageBytes for saving anyway.  Which one does the 3D code more
>>>>>>>> naturally consume?)
>>>>>>>> - The registry listens to any changes in the files and fires
>>>>>>
>>>>>> necessary
>>>>>>>>
>>>>>>>> events to update the UI.
>>>>>>>>
>>>>>>>>
>>>>>>>> One detail that ideally should be taken into account in the
>>>>>>
>>>>>> listening
>>>>>>>>
>>>>>>>> abstraction:  We don't want to reload an image (or any other file)
>>>>>>>> while it is being written, so I'd suggest we delay firing the file
>>>>>>>> modification event for ~500ms after the file has changed the last
>>>>>>
>>>>>> time
>>>>>>>>
>>>>>>>> (i.e. if the file changes during the 500ms delay, wait another 500ms
>>>>>>>> until it to stops changing).  (This logic should be in the file
>>>>>>
>>>>>> system
>>>>>>>>
>>>>>>>> listening abstraction that Doug provided, not in the registry.)
>>>>>>>>
>>>>>>>>
>>>>>>>> Comments?
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Sampo N.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>>>>>>> Remotely access PCs and mobile devices and provide instant support
>>>>>>>> Improve your efficiency, and focus on delivering more value-add
>>>>>>
>>>>>> services
>>>>>>>>
>>>>>>>> Discover what IT Professionals Know. Rescue delivers
>>>>>>>> http://p.sf.net/sfu/logmein_12329d2d
>>>>>>>> ________________________________
>>>>>>>>
>>>>>>>> Openrocket-devel mailing list
>>>>>>>> Ope...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>>>>>> Remotely access PCs and mobile devices and provide instant support
>>>>>>> Improve your efficiency, and focus on delivering more value-add
>>>>>>
>>>>>> services
>>>>>>>
>>>>>>> Discover what IT Professionals Know. Rescue delivers
>>>>>>> http://p.sf.net/sfu/logmein_12329d2d
>>>>>>> ________________________________
>>>>>>>
>>>>>>> Openrocket-devel mailing list
>>>>>>> Ope...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>>>>>
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>>>>>> Remotely access PCs and mobile devices and provide instant support
>>>>>> Improve your efficiency, and focus on delivering more value-add
>>>>>> services
>>>>>> Discover what IT Professionals Know. Rescue delivers
>>>>>> http://p.sf.net/sfu/logmein_12329d2d
>>>>>> ________________________________
>>>>>>
>>>>>> Openrocket-devel mailing list
>>>>>> Ope...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>>>>
>>>>>
>>>>> --
>>>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>>>>
>>>>> ________________________________
>>>>>
>>>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>>>> MVC, Windows 8 Apps,
>>>>> JavaScript and much more. Keep your skills current
>>>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>>>> MVPs and experts. ON SALE this month only -- learn more at:
>>>>> http://p.sf.net/sfu/learnmore_123012
>>>>> ________________________________
>>>>>
>>>>> Openrocket-devel mailing list
>>>>> Ope...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>>>
>>>>
>>>> ________________________________
>>>>
>>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>>> MVPs and experts. ON SALE this month only -- learn more at:
>>>> http://p.sf.net/sfu/learnmore_123012
>>>> ________________________________
>>>>
>>>> Openrocket-devel mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/openrocket-devel
>>>
>>>
>>> --
>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.