Re: [Simile-Widgets] Re: alpha release of exhibit 2.3

[Jeff Roehl]

Hey, David!

Is there a way to dictate the size of a single picture in the timeline? If not, 
is there a way to dictate a single uniform size for all icons in a single band 
without affecting the icon size in other bands?

Sort of like what you can do in HTML, like this:

<img src="planets.gif" width="145" height="126" />  


What I want to do is include a bunch of pictures in a timeline band that are 
all of different sizes.

I would like to display them all as 40 by 40 pixel squares. Basically big icons.

I have tried:

    theme.event.instant.iconWidth = 20;
    theme.event.instant.iconHeight = 20;

In the theme, but that only seems to change how close surrounding text is to 
the icons, sort of like a margin setting. It doesn't actually change the size 
of the graphics.

I tried the following in the XML timeline data (maxheight and maxwidth):

<event 
start="Dec 25 1776 00:00:00 GMT" 
image="http://upload.wikimedia.org/wikipedia/commons/thumb/9/95/800px.jpg" 
icon="http://upload.wikimedia.org/wikipedia/commons/thumb/9/95/800px1.jpg?maxheight=25&mode=fillcrop&maxwidth=25";
 >
</event>


But this had no effect.

Is there something I am missing?
 
Thanks 
Jeff Roehl
jroe...@yahoo.com
(818) 912-7530


>________________________________
> From: David Karger <kar...@mit.edu>
>To: simile-widgets@googlegroups.com 
>Cc: Ryan Lee <ryan...@zepheira.com> 
>Sent: Tuesday, July 10, 2012 10:01 AM
>Subject: Re: [Simile-Widgets] Re: alpha release of exhibit 2.3
> 
>OK, per ryan's request, I'm re-launching the proposal for an exhibit 2.3 
>(or 2.2.1) release.
>I've listed the proposed major changes previously.
>
>Stefano Mazzochi was kind enough to set up a code review site: 
>http://codereview.appspot.com/5673046/
>I request anyone with an interest in the topic to visit and comment.
>
>This list has gotten busier recently with a bunch of relatively 
>low-level code discussion.  If you're a non-programmer who is finding 
>this a burden, please let us know.
>
>In particular, out of respect for the many non-programmers on the list, 
>who I doubt will be interested in coding nitpicks, I'd like to suggest 
>that email discussion of the code (if any) be directed to the 
>simile-widgets-dev mailing list.
>
>On 7/9/2012 7:49 PM, Ryan Lee wrote:
>> On 2012-07-07 21:12 , David Karger wrote:
>>> On 7/7/2012 2:01 AM, Ryan Lee wrote:
>>>> On 2012-07-03 13:02 , David Karger wrote:
>>>>> This discussion thread has been silent since March, and I would really
>>>>> like to bring it to some resolution.
>>>>>
>>>>> To recap, I posted (at http://trunk.simile-widgets.org/) a proposed
>>>>> release of exhibit 2.3 with various bug fixes and feature additions.
>>>>> Concerns were raised that it was inappropriate to add features as this
>>>>> would make it harder for e3 to achieve feature parity/compatibility.  I
>>>>> accepted this argument and formulated a proposal to exclude the
>>>>> egregious feature additions from the release while including those bug
>>>>> fixes I considered important.   I've quoted that specific proposal
>>>>> below.
>>>>>
>>>>> The discussion then branched into the broader topic of how to manage the
>>>>> commit process, with stefano helpfully posting the proposed change for
>>>>> review at http://codereview.appspot.com/5673046/ .  But nobody has
>>>>> contributed to that review, and several months ago the discussion ground
>>>>> to a halt and nothing has happened since.  I consider this a bad
>>>>> outcome.
>>>>   From what I recall, I ended up hearing about this when I was added to
>>>> the cc list in the middle of an ongoing conversation.  It seemed to me
>>>> you switched pursuing this topic to an entirely different list; are you
>>>> sure you reached the appropriate audience?  It doesn't seem as helpful
>>>> to your goals to start a discussion here, then propose its resolution
>>>> elsewhere.
>>> If you look back to the proposed resolution I quoted here, it was
>>> originally posted on this same mailing list on february 9.
>> I'm referring to the actual practical resolution of putting up the code
>> to review.  I'm well aware of the mail you've sent to this
>> list; I find it an odd choice that when you were actually pursuing a
>> concrete path forward, it was announced to a different one.
>>
>>>>> So, can anyone who cares weigh in?  If nobody does, I guess that's a
>>>>> sign that I'm free to make the decision on my own....
>>>> I don't see how not receiving any participation could be perceived as a
>>>> community endorsement to resolve this however you want on your own.  It
>>>> seems rather the opposite.
>>>> All I've heard here is that time has passed with no further community
>>>> input, which leaves me where we began.
>>> No further community input on the proposed release, right.
>> Like I said, that's kind of a big sign you shouldn't just dismiss.  My
>> point about the code review announcement is that there may be other
>> reasons you haven't heard anything further on it.
>>
>>> On the other
>>> hand, I've certainly seen "community input" in the form of complaints
>>> that the painter is down, or something doesn't work in IE8, or that an
>>> xml importer is desired, etc.   It was that input that drove much of
>>> what I wrote.
>> That's fantastic and an attitude and behavior I'm fully behind - but
>> it's not the topic at hand.  Great intentions do not set the boundaries
>> for releases.
>>
>>>>    I'd be quite happy to see a
>>>> 2.2.1 bugfix-only release to meet the needs of current Exhibit 2 users;
>>>> I think it's important for that class of users to know they're being
>>>> watched out for.
>>> Yes, I have acquiesced to the objective of a bugfix release.  I don't
>>> care if it's called 2.3 or 2.2.1.   The point of my proposal was to try
>>> to define what constitutes bug fixes.
>> That's what the code review is for, no?
>>
>> As noted above, I think your initial steps in this direction were
>> insufficient.  Make a proper announcement of the review to this list,
>> point to the URL, let's agree upon a reasonable deadline.  I'll commit
>> to taking some time to enter into the process.  I hope others will as well.
>>
>>> Thus my proposal was to push out the changes that
>>> 1. replace the buggy html importer with one that actually works
>>> 2. address the bug that map-view stops working when painter is down, by
>>> switching to canvas (granted, if I had predicted the demand for
>>> bugfix-only I wouldn't have switched to gmaps v3 at the same time, but I
>>> still would like to push out the fix).
>>> 3. fix the bug of unstable table sorting
>>> 4. fix the bug of referring to simile.mit.edu (which is unreliable) in
>>> simileAjax
>>> 5. "fix" bugs in old jquery by replacing with new jquery
>>>
>>> Then comes the grey area.  Is it a bug for exhibit to fail if someone
>>> forgets a label?  I think so, and want to include the feature that
>>> generates labels for items without them.  Adding a csv importer isn't a
>>> bug fix, but has been a requested feature.  It is entirely independent
>>> of other code, so would it matter?  Ditto for inline import of data.
>
>
>-- 
>You received this message because you are subscribed to the Google Groups 
>"SIMILE Widgets" group.
>To post to this group, send email to simile-widgets@googlegroups.com.
>To unsubscribe from this group, send email to 
>simile-widgets+unsubscr...@googlegroups.com.
>For more options, visit this group at 
>http://groups.google.com/group/simile-widgets?hl=en.
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"SIMILE Widgets" group.
To post to this group, send email to simile-widgets@googlegroups.com.
To unsubscribe from this group, send email to 
simile-widgets+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/simile-widgets?hl=en.