[openbeos] Re: ShowImage Bloat? [was: Re: Build Farm]
- From: "Sikosis" <phil@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 13 Jan 2004 07:54:27 +1000 EST
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:
