On 28/09/2011 20:43, Milosz Derezynski wrote:
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".
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.
If you are offering, and still available, for a usability
assessement when I have finished this, I would be delighted.
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
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?).
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.
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
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!
What are your views on
Um, no soul searching involved: I would be delighted if others could
use and modify the source code. :)
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
Thanks for your input.
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
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.
On Wed, Sep 28, 2011 at
9:40 AM, Phil Hart <philhart@xxxxxxxxxxxx>
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
Many Thanks In Advance,
gtk-list mailing list
Everything is Original.
gtk-list mailing list
Everything is Original.