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.