[openbeos] Re: [glasselevator] ShowImage Bloat?

Hello all,

I feel that I want to apologize since I feel that this continued issue in 
ShowImage could be 
addressed by something that I have been working on for some time but have not 
yet completed.  
I wanted to wait to bring it up when I had a nice comprehensive proposal, but 
perhaps now is 
the right time instead.  Please send all replies to the glass elevator list as 
this is an R2 design 
issue.

First a bit of motivation: there are a number of applications that incorporate 
some sort of a list of 
files to process, these include: slideshow apps, media apps.  A quick short 
list would include: 
SoundPlay, Cl-Amp, VideoLAN Client, ImageShow, etc., and now OBOS ShowImage.

Each of these applications provides its own method for constructing and 
manipulating the list of 
files.  Some methods, such as SoundPlay are quite comprehensive, with sorting, 
randomizing, drag 
and drop editing, and saving the list as its own file.  Others are less 
comprehensive, such as the 
OBOS ShowImage or the VideoLAN Client playlist.

This is unfortunate from a number of perspectives: that of the app coder, the 
end user, user 
interface design, and an independent aesthetic perspective. (at least according 
to my aesthetic)

My thought for addressing this was to have a scripting suite (a la 
"suite/vnd.Be-application", 
"suite/vnd.Be-looper") and an associated "playlist" edit application.  The edit 
application would 
be able to manipulate the list without starting the application, and all lists 
would have a 
common mimetype.  The playlist could be targeted to any application that 
handled files of the 
types that were on the playlist.  The playlist application would support a 
variety of 
manipulations (a la SoundPlay/CL-Amp).  It would also support various criteria 
for advancing 
through the playlist. (play for 5 seconds, play until "complete", random order, 
sequential order, 
etc.)

The playlist application would use the scripting suite to control and 
communicate with the 
target application.  The burden on the application developer to support this 
scripting suite 
would be kept minimal.  It would likely include a very small set of operations 
such as:

1. set/clear a flag to mark whether files should be opened in their preferred 
settings (dimensions, 
for example) or in the current application settings.
2. accept a new file to replace the current file
3. notify the playlist application when the file is "completed"
4. show/hide application controls/menus

BApplication, BLooper, BHandler all provide their own suites and we could 
potentially use a 
new class to make implementing the suite easier for an application developer.  
I do not have 
much experience with suites so I have no concrete proposal related to this.

My goal was to have OBOS MediaPlayer be the first example of an application 
implementing 
this scripting api.  To this end I made a version of a nplay interface some 
time ago that 
supported being controlled by an independent playlist application.  It simply 
used messaging 
though and not the scripting api.  I think the scripting api would have been a 
more correct 
choice.

Unfortunately, I still don't have the time to flush this out as I have taken on 
other priorities.  I 
invite those who think that the approach may be promising to try to flush out 
the details and 
possible make a more concrete proposal or implementation.  I think that I've 
written most of 
what I had worked out so far, but if someone has a question about this they can 
feel free to ask 
and if I left something out I'll try to clarify.  As I stated in the beginning, 
this isn't meant to be a 
finished proposal by any means, and I am sure there are issues that need to be 
addressed.

Andrew

Other related posts: