On Saturday, March 27, 2004, at 01:26 PM, [EMAIL PROTECTED] wrote:
Anyway, the biggest problem I've come across so far is that a group can be at most 32000 pixels high, which effectively limits my "slides plus EXIF" template to 137 templates stacked vertically. Really there's no reason RunRev shouldn't be able to support multi-thousands of images on screen simultaneously so that one need not resort to hokey hacks to display large amounts of data.
FWIW- I don't really want to argue for either method here, but it's not really a hokey hack. Most modern list managers, spreadsheets, and anything else that wants to display a lot of data pages the data through a fixed number of elements in some fashion: you'd be in a lot of trouble if your database manager loaded 2 millions rows to be prepared for your scrolling... so while it may work for your application, paging data and "faking out" the user is actually more like standard memory-saving practice.
- Brian
There's really no reason why this couldn't be handled by Revolution as it currently exists. Imagine being able to create a scrolling group of very lightweight objects (probably just id and rect are all you need). Then as objects are scrolled into and out of view, Revolution would tell you to render them or de-render them. It already knows which of my groups are on and off screen, and if there were "Render()" and a "De-render()" methods (or Show() and Hide() or whatever you want to call them...) that I could override then I could do what you're suggesting without having to resort to hokey hacks.
And with respect to interface design, what is the limit of information to be presented to the user? Sooner or later, the number of images is going to reach a point that interferes with usability, on several fronts: the thumbnails will be too small to be recognizable, the number of images will confuse and overwhelm the user, etc. The development and design questions we ask ourselves (or should ask ourselves, anyway) every day address these issues. How do we balance the power of the application with the usability of the interface?
J.
I see no reason to create an artificial barrier to someone who wants to add 1000 or more photos to an album in my product (and what max would you pick if it were your product?). As it is I have an iPhoto library with 3000 pictures in it, and I find it very usable. And the only reason it doesn't have more is that iPhoto bogs down with about 3000 pictures and I haven't sprung for the next version in which the problem is apparently fixed.
But speaking of numbers and UI problems: Is there a problem with a Word document with 200 pages in it? Or an email program with 10,000 saved messages in it? Or a weblog with 100 entries? Or a HyperCard stack with 10,000 cards in it? Or an address book with 600 addresses? I have all those things and have no problems with the UI of any of those programs. And I hope I've done a reasonable job with the UI of this photo album product such that large numbers of photos in an album are also not going to be a problem.
Now if there weren't that 32000 pixel limit on scrolling groups...
-- Frank
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
