[Decapod] Capture screen interactions

michelle.dsouza at utoronto.ca michelle.dsouza at utoronto.ca
Thu Nov 19 02:27:32 UTC 2009


Hi Boyan,

This is really shaping up nicely. I think your strategy is very good.  
I took a look at your recent commit and I have a couple comments:

1. Capture is a component that has a simple enough interface that it  
likely does not require the use of the renderer. I would simply use a  
plain HTML template.

2. I think 'styles' are most useful for things that we plan to style  
programmatically. Do you think you'll be doing this for capture?  
Personally I would not bother putting the styles into the options  
block unless I was going to do something with them in the component  
javascript. I hope other folks will chime in if they disagree with me.

Hope this is helpful,

Michelle


Quoting Boyan Sheytanov <bsheytanov at gmail.com>:

> Hi,
>
> I'm currently working on integrating Capture and Thumbnail browser for
> Decapod. Here's an idea on what I am trying to achieve. Since I'm not
> sure I'm on the right track, please have a look at it and suggest
> improvements/other approaches for how things can be implemented.
> Here's the overview:
>
> 1. When a  thumbnail is selected, it should be shown in preview. That
> will be achieved by firing an event with the index of the selected
> image in the list of thumbnails (it is kept in the model). The index
> will be found by inspecting the DOM and with the help of hidden input
> fields as suggested in
> http://wiki.fluidproject.org/display/fluid/Talking+to+the+Server+Using+The+afterMove+Event
> This will also come handy because thumbnails can be manually reordered
> by the user. A listener in the Capture component will update the image
> shown in the preview area once that event is fired.
>
> 2. When a thumbnail is deleted, it should be removed from the file
> system and the view. This will be achieved by a change in the model
> (it will be removed from the list of images). An event will be fired
> and listened for in the thumbBrowser component. Probably some kind of
> confirmation should be shown, but this might go as a second pass.
>
> 3. Reordering the images should be reflected in the model (because
> it's more convenient to work with it rather than the DOM).
>
> 4. Capture should add an image to the model, haven't thought much
> about it yet. First want to get some of the other things working.
>
> 5... Other interactions like opening other screens (for fixing,
> comparing, etc.) will be implemented after these other screens are
> implemented.
>
> Hope I've explained my thought clearly. Do they seem sensible to you.
>
> Greetings,
>
> Boyan
>






More information about the fluid-work mailing list