My initial thought was to reduce all input images by a fixed factor
supplied by the caller (I would use 3% for my own application),
along with a fixed spacing between images again supplied by the
caller (again, 10px for my own application). If I can figure out how
to use a user-supplied renderer, I will of course incorporate it.
It should be part of the design from the start, not an optional afterthought. That said, the default renderer needs to be thought out well as well, since the ideal goal is that people do not need to write an own renderer, since that will cause that widget to look mostly uniform in most of the applications. Ideally, the API for a custom renderer should be thought out in such a way that even if the designer of a custom renderer goes much out of his way to make it look a specific way, the combined logic and semantics, and final rendition, of the widget would enforce some kind of standard towards the look of the thumbnails.
The API itself could be initially borrowed from the CellRenderer architecture. But if all of the above would be factored into the initial design there would be some degree of departure from the TreeView-CellRenderer architecture (not neccessarily bad, but it's always good to keep things as familiar as possible for future API users).
I know this sounds very abstract, but if 2 people who are good up the usability ladder would focus on this for a week or two,
it could be done. I would offer myself to do the usability work, if you wish (but most likely not over the course of the next month, and starting again in November; maybe you could find some other usability person to do it?).
My own style is to develop from the base code, and my current
thinking revolves around GtkImage, GtkScrollbar and GtkTable, but I
need to think through the issues, and try a few experiments, before
I can come to a well-informed decision.
To be completely blunt, this sounds like a bad idea. Ideally, this widget would be written from scratch or perhaps based on GtkIconView, but I can't imagine anything good from how you describe it. If you're interested in why particularily, please say so and I'll explain why I think it's a bad idea! Don't hesitate!
For what it is worth, I am using Code::Blocks 10.05 in a Windows 7
64-bit environment (gah!) while fighting issues on multiple fronts.
Once I have "defeated the enemy(ies)", I will be looking to port to
Ubuntu. Then, and only then, might I have something that might be
considered useful. My ideal, which is probably unrealisable, is to
have something that could be incorporated into Gtk itself. (Me,
ambitious? Yes, but I have got to have *something* to aim at!)
Ambition is always good but as with all open source, you eventually need to let this go the open-source-soul-searching process.
Regards,
Milosz
On 28/09/2011 16:27, Milosz Derezynski wrote:
Just want to throw in my "vote": I also would be very
much for having such a widget, but still leaving the thumbnail
rendering routine open to implementation (with a standard default
renderer present).
To be a little preemptive: In case someone says nuh-uh too
fast: I've never coded with Cocoa, but I imagine that the/a
CoverFlow widget exists in the library and doesn't need to be
reimplemented each time.
These days, thumbnails could be used for quite a lot of
stuff.
Also, as a last, completely intuitive and at the moment not
rationalizeable thought (I'll try it to flesh out in an upcoming
message): Please, please don't base the code for the ThumbView
widget on anything Nautilus. Please.
Regards
Milosz
On Wed, Sep 28, 2011 at 9:40 AM, Phil
Hart
<philhart iinet net au>
wrote:
Hello
Everybody,
I want (need?) a scrollable (both vertical and horizontal)
widget for displaying thumbnails which also re-arranges them
depending on how many thumbnails wide is chosen in an
up-down counter. (Gigapan stitcher users will know what I am
talking about.)
Is there anything similar already around - if not, I will
write one (and if I regard it as good enough, I will also
publish the source code).
Many Thanks In Advance,
Phil
_______________________________________________
gtk-list mailing list
gtk-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-list
--
Everything is Original.
_______________________________________________
gtk-list mailing list
gtk-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-list
