[openbeos] Re: ShowImage Bloat

> I've been following this entire ShowImage discussion with a little 
> bit of
> interest.  Just a few quick points:
> 
> 1) Disk space may be cheap, but that's no reason to waste it.  Anyone 
> who
> has worked with large media files knows that every byte counts.

Hmm, OK. I don't think thats a very good argument when we're talking 
the order of a few kB. The user is more likely to say - "ow, I've run 
out of space - better delete that app I don't use any more" than to say 
"noooo I've run out of space - and it's all the fault of whoever added 
the slideshow to ShowImage!"

When I'm talking about a dislike of bloat, it has much more to do with 
the experience of using the app (more features do not necessarily 
enhance that) than the exact size of the binary.

> 2) The fact that this debate has gone on for so long indicates that 
> there
> obviously needs to be a clearer definition of what OpenBeOS R1 is 
> aiming
> for...  Is it to be an opensource implementation of BeOS R5, an 
> opensource
> implementation of Dan0, or are we aiming for something more?

My personal view is that R1 is a reimplementation of R5. That does not 
mean that it is a clone of R5 - but a reimplementation of R5's API and 
general features. That means moving networking to the kernel is a good 
move (same basic API for coders, better implementation), along with the 
host of other improvements being made for R1. That definition also 
rules out things like multi-user support for R1.

Something like adding features to ShowImage is certainly within the 
realm of R1. For me that would mean supporting more file formats 
(multipage tiffs is one example), and zooming support.

[different mail]
> - Michael
> Print Kit leader who thought improving ShowImage could not hurt...

Michael (and Michael :-)) I really do appreciate the work you have 
done. This thread has rather glossed over some of the very useful 
additions to ShowImage that you have made. Thanks.

And, to be honest, I don't even really have a problem with the 
slideshow feature. At the moment it feels a bit "tagged on as an 
afterthought", which I admit I'm never very fond on in apps. However 
I'm sure the interface to it could be improved, and then I would have 
no problem with it at all (although I would still prefer a seperate 
app).

The reason I have continued this debate is that I feel it's important 
to recognise that adding more features does not necessarily equate to a 
better app. That is especially true for BeOS apps, where simplicity is 
the name of the game. For me, one of the best features of the OS is 
that each app has a clearly defined task and carries it out very 
simply. I know the limitations of ShowImage, but apart from the lack of 
zooming, I am happy with it. I have never loaded an image into 
ShowImage and thought "I wish there was an invert function here" - 
instead before openning the image in ShowImage, I think "I need to 
invert that image, I'll use ArtPaint". The right tool for the right 
job.

With open source comes a lot of freedom - unfortunately that means any 
developer can take the source and add a specific feature that they 
think might be useful to them occasionally. And the "feature creep" 
thing means it's a lot harder to get features removed than it is to get 
them added. The problem is that most users (even me) welcome new 
features if they're introduced very slowly, version by version. And 
without someone to oversee all the changes with a very clear idea of 
what the app should be (like a company, for example), the features will 
keep coming and coming. By OBOS R4/R5 the OS won't be shipped with an 
image viewer. It may well have a combined ImageViewer/Slideshow/
PrintWizard/WebOptimisator/HTMLImageMapGenerator/FilterApplier app 
called "ShowImage", but hey, it's been improved, so it "could not 
hurt".

The last few times people have wanted to see some photos I've got in a 
folder, I've used OpenShowImage to do a slideshow of them. So surely 
that means I'm happy there's a new feature added? Not really. I would 
much prefer a dedicated app - it seems much more logical to select all 
the files and open them with "OpenSlideShow" than to open one of them 
in ShowImage and fight around with the interface oriented towards 
viewing-one-image-in-a-window to get them to display as a slide show. I 
maintain that the two tasks of "viewing an image file" and "running a 
slideshow" do not often overlap, and are therefore much better suited 
to two seperate apps.

Look at how SoundPlay uses ArmyKnife to edit attributes on MP3s. Most 
times you play MP3s, you don't want to edit attributes. In the same 
way, when ripping CDs you may well want to fine tune the attributes 
without playing the files. The tasks are clearly related - but are 
seperate enough that it is better to split them into two apps with a 
little bit of integration (the "Attribute Editor..." menu link in 
SoundPlay), than to clutter one app's interface with all the stuff 
required for the other non-core task.


Simon

ps: I love the way the OBOS devs are at least open to this discussion. 
I can't imagine trying to argue in linux-land that the best way to go 
is with a very simple app with barely any features besides viewing an 
image.


-----------------------------------------
Email provided by http://www.ntlhome.com/

Other related posts: