On 28/09/2011 20:43, Milosz Derezynski wrote:
Hello Phil,
A few words on your response, if I am allowed:
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.
Well thought-out: of course. And I think you also wrote "but still
leaving the thumbnail rendering routine open to implementation (with a
standard default renderer present)." which implies to me that , as you
say "that people do *not* need to write an own renderer".
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?).
If you are offering, and still available, for a usability assessement
when I have finished this, I would be delighted.
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!
Um, you commented that "Please, please don't base the code for the
ThumbView widget on anything Nautilus. Please.", hence the need to go
back to the base code.
What are your views on
http://developer.gnome.org/gtk-tutorial/stable/x2200.html ?
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.
Um, no soul searching involved: I would be delighted if others could use
and modify the source code. :)
Best Regards,
Phil Hart
Regards,
Milosz
Thanks for your input.
Phil Hart
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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://mail.gnome.org/mailman/listinfo/gtk-list
--
Everything is Original.
_______________________________________________
gtk-list mailing list
[email protected] <mailto:[email protected]>
http://mail.gnome.org/mailman/listinfo/gtk-list
--
Everything is Original.
_______________________________________________
gtk-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtk-list
