[openbeos] Re: ShowImage Bloat? [was: Re: Build Farm]

Personally, I don't see the problem here. I always thought ShowImage 
had too little features for me to use it. 

ie. I use ThumbBrowse to view my pics and use something else when 
editing like Artpaint or WonderBrush.

The Next/Prev feature for multiple page TIFFs, I must say, is great. 
Think - faxes ... we use a fax program (at work) that saves items as 
multiple page tiffs - previously I couldn't view them.

Slideshows are pretty much common place these days. I like being able 
to run a slideshow on say, a bunch of photos I just took with my 
digital camera - rather than having to click through them all.

Cheers

Sikosis
http://obos.gravity24hr.com/

> > >Hehe interesting definition of bloat. The issue of bloat is 
> > > whether 
> > > the 
> > >feature you're adding is actually useful for the core purpose of 
> > > the 
> > >app. Whether slideshows are necessary to "Show Images" is 
> > > certainly 
> > >questionable, IMHO.
> > >  
> > >
> > The origin of "bloat" is that software (or, if you really want to 
> > go 
> > to 
> > the original definition, anything) grows in size. I asked the 
> > Translation Kit team about the size and, IIRC, we were a little 
> > over 
> > R5 
> > and a little under the Dan0 file sizes. That seemed pretty 
> > reasonable 
> > to me.
> 
> OK then.
> 
> When I think of bloat I think in terms of features and not binary 
> sizes, but that might just be me :-)
> 
> > >>Believe me - there is no one 
> > >>who supports the "less is more" approach of BeOS than the admin 
> > > > team. 
> > >>We 
> > >>don't want another Windows or Linux.
> > >>
> > >
> > >I agree "less is more". And you are using that as an argument to 
> > > defend 
> > >adding features? :-)
> > >  
> > >
> > less is more is not an absolute maxim. If it were, we would use MS-
> > DOS. :-)
> 
> Yeh, good point.
> 
> > The whole crux of the issue came about that TIFF files can store 
> > multiple images. With that ability added to the translator (fixing 
> > one 
> > of Be's bugs), the ability to view more than one image became 
> > necessary 
> > in ShowImage. As a result, we added prev/next. Which is a good 
> > thing.
> 
> Yes.
> 
> > A slideshow is little more than prev/next with a timer. Still not 
> > too 
> > big 
> > of a deal, really.
> 
> I think viewing a slideshow is a different task than viewing an image 
> -
>  I certainly know in advance if I want a slideshow or not.
> 
> I was showing someone some pictures I had in a BeOS folder and wanted 
> to show them as a slideshow. Instead of just "Open With"ing them with 
> (the yet to be created) SlideShow, I had to open one of them in 
> OpenShowImage, select "full screen", then select "fit to window", 
> then 
> select "view as slide show". So maybe some improvents in the 
> interface 
> would help the situation, but it still seems like a distinct task to 
> me. 
> 
> > >But seriously, bloat doesn't happen overnight. The problem will be 
> > > in 
> > >the R3 timeframe, when ShowImage has features for editting images, 
> > >adding layers, adding text, exporting HTML image maps, etc, etc - 
> > > all 
> > >of which will have been justified by saying "it's not much more 
> > > than 
> > >the previous version - but believe me, we don't want bloat!"
> > >  
> > >
> > We all know and fear this. Everyone has a "critical feature". From 
> > multi-user to an integrated IDE to networking with Macs. There is 
> > no 
> > "bad" feature.
> 
> Yes, that's true.
>  
> > >However, some of the things in OBOS's ShowImage are unquestionable 
> > >improvements - zooming images for one. However, I don't think that 
> > > it 
> > >is implemented in a very BeOS way - it would be nice if there was 
> > > an 
> > >ArtPaint-style zoom bar in the status area to make zooming images 
> > > more 
> > >interactive. The multi-page image features may be useful for a 
> > > very 
> > >small subset of images, but again I think the interface would be 
> > > better 
> > >in the status bar (little numbered page icons). If the image only 
> > > has 
> > >one page, then hide all of the menu for navigating multi-page 
> > > images.
> > >  
> > >
> > Since my BFS got corrupted (still fixing it), I haven't seen the 
> > newest 
> > iterations. If you don't like the UI, though, you should file a bug 
> > report on it. Posting stuff in here gets lost in the shuffle.
> 
> Yeh, OK. I need to test the latest binary myself.
>  
> > >And I think the slideshow feature is really another app. I never 
> > > open 
> > >ShowImage to view one file and then suddenly want to view a 
> > > slideshow. 
> > >I know in advance whether I want to view one or two specific 
> > > images, 
> > > or 
> > >if I want to have a look at all my holiday photos. I think the 
> > >slideshow would be best handled by a seperate app. There is 
> > > nothing 
> > > to 
> > >stop the apps working together - a slideshow button in showimage 
> > > that 
> > >launches the slideshow app with a list of all the image files in 
> > > the 
> > >current directory, and starts the show.
> > >  
> 
> > So, a seperate app that contains all of the functionality of 
> > ShowImage 
> > plus SlideShow, seems less bloated to you?
> 
> Yes it does.
> 
> In the same way that a separate app that contains all the 
> functionality 
> of ShowImage plus some editing functions (ArtPaint), is better than 
> adding all the editing functions directly to ShowImage itself.
> 
> The seperate app could have a simple UI, uncluttered with ShowImage 
> specific features (it would always be full screen, would always size 
> to 
> fit, wouldn't need to bother with dragging cuttings about). ShowImage 
> itself could have a single command ("Run Slideshow"), that hands over 
> to the other app for all the specific settings relating only to the 
> Slideshow, making ShowImage a lot less cluttered too.
> 
> I think Windows does quite well at this - the "File and Picture 
> Viewer" 
> or whatever it's called, allows zooming, rotating 90 degress, and 
> clicking a button to launch an editor (usually Paint), and another 
> button to launch a slideshow. That's it. Because they are seperate 
> apps, it's also possible to start a slideshow directly from explorer 
> without having to load the picture viewer for one file first.
> 
> > Honestly, someday, we will have a KeyNote/PowerPoint app, too. 
> > Complex 
> > slideshows belong in there. For now, though, a few dozen (guessing) 
> > lines of code that enable users to shuffle through their images 
> > doesn't 
> > seem too much overkill to me. It isn't a gut wrenching change.
> 
> But to do a "nice" slideshow app needs more thought and more 
> slideshow-
> specific UI bits that really would be bloat for the 99% of times 
> people 
> run ShowImage just to look at one image.
>  
> > >Try to define ShowImage now - is it an image viewer or a slideshow 
> > >displayer? Now try justifying adding these useful slideshow 
> > > features 
> > > in 
> > >"*ShowImage* R2":
> > >* User-definable caption for each picture based on a BeOS 
> > > attribute
> > >  
> > >
> > This sounds like a good idea to me, honestly. As a person who takes 
> > a 
> > lot of pictures, I would like a set of "standards" like People 
> > files 
> > for 
> > pictures. Date taken, people in the picture, etc. If we had such a 
> > standard, it would make sense to have ShowImage show those 
> > attributes. 
> > Much like BeMail/MDR uses people files.
> 
> There is already info in most digital camera images in the EXIF 
> header. 
> Date and time take, exposure, flash used, thumbnail, etc.
>  
> > >* Transitions
> > >  
> > >
> > As add-ons, maybe that does make sense.
> 
> But not in ShowImage, surely?
> 
> > >* Changing the order pictures are displayed in
> > >  
> > >
> > This goes hand in hand with the above - if you can insert 
> > transitions, 
> > you have to show them. If you show them, you should be able to d&d 
> > to 
> > reorder them.
> > 
> > >* Displaying files stored in different directories
> > >  
> > >
> > It will do this already, I think. If you select files from 
> > different 
> > places and drag them onto showimage, what happens?
> 
> The version I've got didn't do anything. Might have changed in the 
> latest one though.
>  
> > >I think most people would call them "bloat" for ShowImage. 
> > > However, 
> > >given a show image with navigation consisting of "Prev Image, Next 
> > >Image, View Slideshow" and a seperate slideshow app specifically 
> > >designed for the purpose (say with a list view listing the files 
> > > to 
> > > be 
> > >displayed, allowintg drag-and-drop to add files or change the 
> > > order), 
> > >it is much easier to justify new slideshow-specific features for 
> > > the 
> > >slideshow-specific app.
> > >  
> > >
> > There is a hard line to draw, I will agree. ShowImage is about 
> > showing 
> > images. It seems to me that the better we show images, the better. 
> > We 
> > could certainly make a showimage that is smaller and simpler. It 
> > would 
> > even be pretty easy. In fact, some other developer might have taken 
> > a 
> > different direction - they might, for example, have made ShowImage 
> > open 
> > multiple instances of itself for image files with multiple images. 
> > Maybe 
> > that is better. Maybe it is not. I am not sure. There is always a 
> > different way with a different set of tradeoffs. In this case, 
> > though, 
> > the app didn't grow significantly, it adds to the user experience 
> > and 
> > is 
> > more useful to everyone. Certainly zooming is.
> 
> I definately agree about the zooming. That is something that is 
> always 
> useful whatever image you're viewing for whatever reason.
> 
> Multi-page images is a slightly grey area (because it applies to so 
> few 
> files), but it seems sensible to include it in the main app (still 
> viewing one image file).
> 
> Slideshow is the most out-of-place IMHO, mainly because wanting to 
> view 
> a slideshow is not the same thing as wanting to view an image.
> 
> Simon
> 
> -----------------------------------------
> Email provided by http://www.ntlhome.com/
> 
> 
>

Other related posts: