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. 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. > Best Regards, > Phil Hart > > 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 <[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] >> 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 > > -- Everything is Original.
_______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
