[kepler-dev] Icons in the *DataSource actors

Mon Jan 9 17:06:49 PST 2006

Hi, Dan:

This is possible solution. But it maybe make this button response time too 
long if there is no cache for the metadata.

In eml datasource actor, attributeChange method will trigger metadata 
download(no matter you open a existed workflow or drag a search result to 
cavas) and when metadata download finished the metadata will be parsed by 
eml parser. During the parsing, the data url will be digisted and 
downloaded into local system. So my suggestion is attributeChange only 
trigger metacat downloading, but not parse it. The parsing process will be 
moved to initialize method. After that, when you open a workflow, only 
metadata download, but data download will happend in execution.

Jing

Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101

On Mon, 9 Jan 2006, Dan Higgins wrote:

> Date: Mon, 09 Jan 2006 15:23:12 -0800
> From: Dan Higgins <higgins at nceas.ucsb.edu>
> To: Jing Tao <tao at nceas.ucsb.edu>
> Cc: Matthew Brooke <brooke at nceas.ucsb.edu>,
>     'Kepler-Dev' <kepler-dev at ecoinformatics.org>
> Subject: Re: [kepler-dev] Icons in the *DataSource actors
> 
> Jing,
>   Good Point.
>
>   Maybe we could have the 'GetMetadata' button method download the metadata 
> if it has not been cached?
>
> Dan
>
> Jing Tao wrote:
>
>> Hi, Dan:
>> 
>> I agree with you that move the data download process from attributeChange 
>> to initialize will speed up the opening of workflow. But I have a comment 
>> about this:
>>
>>>    Note that we also need to consider what happens when someone loads
>>> an existing workflow with datasource actors for the first time.
>>> Currently, the data and metadata is downloaded when such an existing
>>> workflow is first opened, just as if it was dragged from the actor list.
>>> In this case, we wouldn't even need to get the metadata immediately
>>> since all the ports should be described in the associated MOML. So maybe
>>> we can put off all the downloading until workflow execution.
>>> 
>> 
>> I think we still need metadata immeidately in this senario, otherwise the 
>> "Get Metadata" button in datasource actor will fail.
>> 
>> Jing
>> 
>> 
>> 
>> 
>> 
>>> Dan
>>> 
>>> ---
>>> 
>>> Matthew Brooke wrote:
>>> 
>>>> Laura (also Kevin & Dan) -
>>>> 
>>>> Sorry - the states that I know about are 'busy' (currently red), 'ready'
>>>> (currently yellow) and 'error' (currently pink). Not sure if there are
>>>> any more.
>>>> 
>>>> I also think I recall seeing a discussion on IRC or by email about
>>>> having the datasources *not* get their data before the workflow is run -
>>>> was that conversation between Dan and Kevin? Can either of you guys
>>>> summarize what you decided?
>>>> 
>>>> m
>>>> 
>>>> 
>>>> Laura L. Downey wrote:
>>>> 
>>>> 
>>>>> Before I make a recommendation I'd like to understand what "states" 
>>>>> these
>>>>> icons have to display?
>>>>> 
>>>>> And it does seem a bit unusual to me to have processes doing something 
>>>>> when
>>>>> the user hasn't instructed the workflow to execute.  But I'm not 
>>>>> familiar
>>>>> with these specific actors or the specific workflow you are referencing.
>>>>> 
>>>>> Is it some kind of polling thing?
>>>>> 
>>>>> On a general note, I pretty much agree with Matthew's suggestion of 
>>>>> having
>>>>> the icons fit in with the general scheme then doing something else to
>>>>> indicate state changes (highlighting, superimposing, putting some symbol
>>>>> above or below that indicates state change etc.)  There are a variety of
>>>>> ways we might do this.
>>>>> 
>>>>> Laura L. Downey
>>>>> Senior Usability Engineer
>>>>> LTER Network Office
>>>>> Department of Biology, MSC03 2020
>>>>> 1 University of New Mexico
>>>>> Albuquerque, NM  87131-0001
>>>>> 505.277.3157 phone
>>>>> 505.277-2541 fax
>>>>> ldowney at lternet.edu
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: kepler-dev-bounces at ecoinformatics.org
>>>>> [mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Matthew 
>>>>> Brooke
>>>>> Sent: Monday, January 09, 2006 2:16 PM
>>>>> To: Kevin Ruland; kepler-dev at ecoinformatics.org
>>>>> Subject: Re: [kepler-dev] Icons in the *DataSource actors
>>>>> 
>>>>> 
>>>>> Kevin -
>>>>> 
>>>>> I'd noticed (and ignored ;-) the eml200datasource actor; I agree with
>>>>> you that it's not visually compatible with the new icon scheme, and had
>>>>> meant to discuss it with Laura.
>>>>> 
>>>>> I'm wondering if a better way to do this would be to use an assigned
>>>>> icon that doesn't change, but then the actor superimpose something on
>>>>> top of it that gives the user some feedback on status/progress (instead
>>>>> of switching out the entire icon or changing its color).
>>>>> 
>>>>> This way, the background icon would always "fit" with the color scheme,
>>>>> and if the icons change in future, we probably won't need to change
>>>>> anything specifically for these actors, since they are superimposing
>>>>> their "status message" on top of the icon.
>>>>> 
>>>>> Laura - do you have any comments?
>>>>> 
>>>>> m
>>>>> 
>>>>> 
>>>>> 
>>>>> Kevin Ruland wrote:
>>>>> 
>>>>> 
>>>>>> Matthew, et al
>>>>>> 
>>>>>> Both Eml200DataSource and DarwinCoreDataSource actors have hard coded
>>>>>> icons.  They are not exactly using the same code but it looks like one
>>>>>> was cribbed from the other.  They set the folder shape, then make calls
>>>>>> to control color/text changes to indicate state.
>>>>>> 
>>>>>> Since the icon system is/has gone through a major overhaul, I would 
>>>>>> like
>>>>>> to discuss how we can get compatible icons for these actors.  I think 
>>>>>> it
>>>>>> is still good for them to be able to control some indication of state
>>>>>> since they do perform background tasks even when the workflow is not
>>>>>> running.
>>>>>> 
>>>>>> BTW - by "compatible" I mean in the visual sense.  These icons are very
>>>>>> boxy and the colors are much too vibrant -- they would look horrible
>>>>>> with the new icons.
>>>>>> 
>>>>>> Kevin
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>> 
>>> 
>
>
>
>