color property changed in TImeline svn 2.1 version

[jcorreia]

Hi,
I have updated timeline from svn to have the mouse scroll
functionality (by the way, it´s awesome), but now the color from
events is changing the color text instead of the bars color.
How can I do this now ? is there a new property now ?

Thanks,
Jcorreia

[LarryK]

Hi,

I'm fixing this now, will have it done later today.

It looks like someone added a new event property "textColor" which
changes the color of the label on the Timeline (not bubble).

The event property 'color' will change the bar color and the label
color if the "textColor" property is not there.

Note that for some bars (where isDuration = true), an opacity value
will be applied to the bar in addition to its color property. The
opacity lightens the color. The default opacity is 20% for such bars.
It can be overridden, I'm also updating the docs.

Stay tuned,

Larry

[Michael Nosal]

The opacity is for imprecise duration events, so that the "fuzzy"
part of a duration event is represented using a more translucent
version of the bar color.
--Mike

[LarryK]

Hi Jcorreia,

Fix checked in. Rev 1569.
See announcement: http://groups.google.com/group/simile-widgets/browse_thread/thread/6d15bdb636e6bf2f
==>> Please test it and let me know any issues.

Hi Mike,

Thanks for the info re imprecise duration events. What I don't quite
get is why setting isDuration true makes the event
imprecise.

I vaguely remember reading a post that one of the features of 2.0 was
that latestStart and earliestEnd were no longer needed? Maybe the idea
is that instead of switching from using start to latestStart for an
imprecise event, you can now continue to use start, but set isDuration
to true.

But if that is the case, maybe it'd be clearer to rename isDuration to
isImprecise (better isFuzzy)?
(Of course, such a change would be implemented by adding the new
attribute, the old attribute should always be available for backwards
compatibility with older data sets.)

==>> Is the above the current design idea? If so, we should change the
docs to mark latestStart and earliestEnd as obsolete.

Comments appreciated,

Larry

[jcorreia]

Hi,
Thanks for fixing this :)
I will test it and give some feedback..
jcorreia

[jcorreia]

Another thing that I´ve noticed is that someone commented the
'hightlightcolors' from css and js files. With this move my
filters.js is not rendering the filter by colors option..
Can you check this also ?
Thanks

[LarryK]

Hi,

Which css file?
I just looked in
http://simile-widgets.googlecode.com/svn/timeline/trunk/src/webapp/api/timeline-bundle.css

and I see a bunch of highlight-decorator css statements. They are not
commented out.

Also, which js file?
(not the bundle file, which individual file)?

BTW, the source refers to an event's "tape" -- my plan is to switch to
this nomenclature rather than "bar".

While I was investigating the issue of setting the background color of
event tapes (in file original-painter.js), I noticed in the overview
painter (overview-painter.js) that the background color settings of
the event tapes was commented out.

==>> Anyone know anything about that?

Thanks,

Larry

[LarryK]

Hi jcorreia,

You wrote:
Thanks,
The color bars now works, with an exception ;)
I have an overview band, and in that the color bars aren´t changing.

Please post a url to an example. Probably issue of z-axis

Regards,

Larry

[Jon Crump]

On Wed, 17 Sep 2008, LarryK wrote:

> I vaguely remember reading a post that one of the features of 2.0 was
> that latestStart and earliestEnd were no longer needed? Maybe the idea
> is that instead of switching from using start to latestStart for an
> imprecise event, you can now continue to use start, but set isDuration
> to true.
>
> But if that is the case, maybe it'd be clearer to rename isDuration to
> isImprecise (better isFuzzy)?
> (Of course, such a change would be implemented by adding the new
> attribute, the old attribute should always be available for backwards
> compatibility with older data sets.)
>
> ==>> Is the above the current design idea? If so, we should change the
> docs to mark latestStart and earliestEnd as obsolete.

I'm not exactly sure what's being suggested, but let me register my
opinion here in the strongest possible terms that latestStart and
earliestEnd are not obsolete. When David was originally planning the
development of timeline I offered the desideratum that timeline should be
able to represent dates and spans with terminusPostQuem and
terminusAnteQuem properties. David wisely chose latestStart and
earliestEnd instead, in order to implement a representation like this:

http://home.myuw.net/jjcrump/Timelines/itinerary/earliest_latest.html

in medieval or ancient history especially (but also true for any age) the
date of an event or some evidence may be uncertain, but can be narrowed
down to a date after which it MAY have occured (terminus post quem), a
date before which it MAY have occured (terminus ante quem), a date after
which it MUST have occured and and before which it MUST have occured. That
timeline offers this flexibility is one of its most attractive features.

The second two examples are meant to show that a point date can
represented as 'fuzzy', ie, may have occured any time within the span
shown; as opposed to an event that spans a duration of time.

One of the things I'd like to see in future development is the capacity to
represent terminus ante quem by itself. This might look something like
this: a point date with a tape that fades off into nothing in the past.
the length of that tape could be established by means of some kind of
fuzzy metric indicating degrees of uncertainty, ie 'at some time before
this date'. (days, months, years?, or perhaps a percentage of span of time
currently displayed).

just my 2 cents,
Jon

[LarryK]

Hi Jon,

Thanks, your post is very helpful--I had not seen usage or explanation
of all four date attributes previously. I'd like to add your Timeline
to the examples in the source. -- Let me know if you wouldn't want
that.

I agree with you about not removing any capabilities. I'm more trying
to understand how to make use of the capabilities that are there.

Regarding display of just a terminus ante quem:
As a workaround, you can do that now, as you describe, by use of the
new tapeImage and tapeRepeat attributes I added. Just create an image
which starts on the left side as white and becomes darkest on the
right side. Width depends on how far back in time you want the tape to
extend to. Only issue that I can think of is that the label will be in
the past, not at the terminus ante quem.

But updating the original-painter.js file to shift the label to the
right side of the tape for terminus ante quem events wouldn't be hard.

Thanks again for a helpful post,

Larry

[James Howison]

FWIW I also have events that must have occured before another event.
I'm working on showing work in open source teams, so not quite
medieval history :)

The suggestion of a way to do fading backwards is a great one.

Thanks,
James

[jcorreia]

Hi, Larry
sorry for the late reply.
I´ve noticed that you already have checked this because of your entry
here :
http://code.google.com/p/simile-widgets/issues/detail?id=16

This feature should be optional for whom might want it as you
commented.

Let me know if you need something else.

Thanks
Jcorreia

[jcorreia]

The file I was refering is
\timeline\timeline\trunk\src\webapp\api\scripts\themes.js

you have
highlightColors: [
// "#FFFF00",
// "#FFC000",
// "#FF0000",
// "#0000FF"

If you leave it this way, the highlight colors of filters.js won´t
appear. If you uncoment they will appear, but they are broken and not
working.
Highlightcolors filter is not working as you can check in jfk example.

Thanks,
Jcorreia

On 18 Set, 15:11, LarryK <wex...@kluger.com> wrote:
> Hi,
>
> On Sep 18, 4:47 am, jcorreia <tang...@gmail.com> wrote:
>
> > Another thing that I´ve noticed is that someone commented the
> > 'hightlightcolors'  from css and js files. With this move my
> > filters.js is not rendering the filter by colors option..
> > Can you check this also ?
> > Thanks
>
> Which css file?

> I just looked inhttp://simile-widgets.googlecode.com/svn/timeline/trunk/src/webapp/ap...
>

[LarryK]

Hi Jcorreia,

Thank you for your posts.

I think there are two separate issues, yes?
1) Overview event painter ignores color attribute.
http://code.google.com/p/simile-widgets/issues/detail?id=16

Status: someone commented out the code at some point. Reason unknown.

2) Highlighting colors, when filtering, don't work
I filed issue 19:
http://code.google.com/p/simile-widgets/issues/detail?id=19


Unfortunately, I don't have time right now to work either issue. If
you'd like to work on the sw, that'd be great.
-- For both issues, the first thing would be to look backin time using
svn browsing and look at the comments from the person who changed the
sw to remove the features. My guess is that they were not working
right due to other changes in the code base. So the relevant event
attributes are now ignored. eg the fixes for the issues are probably
more than simply uncommenting the source.

You can either obtain check in permission, or just send in patches to
the mailing list and others (including me) will test and then checkin
the software.

Thanks,

Larry

[jcorreia]

Hi,
yes they are two different things.

unfortunately I don´'t have the javascript knowledge to fix that
issues, but I can help tracking the changes in svn if you tell me the
files I should check out :)

[culver]

I am not sure if this is the same problem that I am having.

In my tests using the setup controls, highlighting works only on the
overview layout but not for the original or detailed painters. The
filter works in all three. I reviewed the js files, reviewed the
groups discussions, and the wiki but haven't found any obvious errors.

Is any one else having this problem, or it it just me? Is there some
global control that has it disabled?

Need help,

Hunt

On Sep 22, 12:56 pm, LarryK <wex...@kluger.com> wrote:
> Hi Jcorreia,
>
> Thank you for your posts.
>
> I think there are two separate issues, yes?

> 1) Overview event painter ignores color attribute.http://code.google.com/p/simile-widgets/issues/detail?id=16

> > If you leave it this way, thehighlightcolors of filters.js won´t

> > appear. If you uncoment they will appear, but they are broken and not
> > working.

> > Highlightcolorsfilteris not working as you can check in jfk example.

>
> > Thanks,
> > Jcorreia
>
> > On 18 Set, 15:11, LarryK <wex...@kluger.com> wrote:
>
> > > Hi,
>
> > > On Sep 18, 4:47 am, jcorreia <tang...@gmail.com> wrote:
>
> > > > Another thing that I´ve noticed is that someone commented the
> > > > 'hightlightcolors'  from css and js files. With this move my

> > > > filters.js is not rendering thefilterby colors option..

[culver]

Disregard my last post. I resolved the issue. In the latest version
of Timeline, someone had commented out (temporarily I assume) a line
of code in original-painter.js although it probably should be enabled
for most users.

The line of code was in the
Timeline.OriginalEventPainter.prototype._createHighlightDiv function
call, and the line is

div.style.background = color;

Users should check their local Timeline webapp and will want to modify
this line of code to enable highlighting events.

Later,
Hunt

[Larry Kluger]

Hmmm. Wasn't me. But in any case, I have made the change you suggest in the latest version (rev 1628) on the trunk.

Thanks for sleuthing it.

Regards,

Larry

[Michael Osterman]

Hi all,

I've tracked this down to a check r1326 "separation of javascript and css.":
http://code.google.com/p/simile-widgets/source/detail?path=/timeline/trunk/src/webapp/api/scripts/themes.js&r=1326

I checked out a clean copy of trunk, and it looks like this commit was the one that killed the highlight function. Even uncommenting the four colors doesn't fix everything, as only the overview band gets the highlighting, but not the "zoomed in" version.

I also grabbed the revision previous to this, and other behavior with regard to highlighting, such as a setting a "color" property in the JSON/XML only works on one band, but not all.

Can those of you who are elbows-deep in the code review this commit and evaluate whether the changes made should be rolled back? I think the intent was good, but it looks like it wasn't fully tested for all the ways in which it might break functionality.

Best,
Mike