[openbeos] Re: [glasselevator] ShowImage Bloat?
- From: "Andrew Bachmann" <shatty@xxxxxxxxxxxxx>
- To: glasselevator-talk@xxxxxxxxxxxxx
- Date: Mon, 12 Jan 2004 20:47:57 -0800 PST
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:
- » [openbeos] Re: [glasselevator] ShowImage Bloat?
