| On 28/09/2011 20:43, Milosz Derezynski wrote: Hello Phil,
      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
            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?). 
 
      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
              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! 
 
 What are your views on
    http://developer.gnome.org/gtk-tutorial/stable/x2200.html ?
 
 
      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
            open-source-soul-searching process. 
 
      
    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 <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
 
 
 
 
        --  
        Everything is Original.
       
 |