[openbeos] Re: Build Farm

Simon Taylor wrote:

There are a few more pieces in beta that you can play with.
Media Kit



Media Kit in Beta? As in with codecs and everything? I knew it was possible to play mp3s in Media Player, but didn't think the whole thing was in beta.


The release of Media Kit was called an alpha. It didn't have the codec stuff, but IIRC everything else was there.

As far as ShowImage, the bloat vs non-bloat has been discussed at length offlist. The long and short of it is that the file size between R5, Dano and ours is nearly nothing. If we can implement more features in less space, well, I think we have done OK. :-)


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.

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. :-)
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. A slideshow is little more than prev/next with a timer. Still not too big of a deal, really.

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.

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.

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?
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.

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.

* Transitions


As add-ons, maybe that does make sense.

* 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?

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.



Other related posts: