[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Proposal: Playobject standardization
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2000-12-29 13:36:22
[Download RAW message or body]

   Hi!

On Fri, Dec 22, 2000 at 08:10:32PM -0800, Charles Samuels wrote:
> 
> We should standardize all playobjects, particularly for video.
> 
> ArtsPlayObject
> 	int length();
> 	string title();
> 	string author();
> 	string property(string )
> 	sequence<string> properties();
> 	...
> 	class VideoPlayObject
> 		void setParent(Wid);
> 		void setWindowPrefs(int);
> 		int window();
> 		void setTitle(Wid);
> 		int framerate();
> 		int width();
> 		int height();
> 		...
> 	class AudioPlayObject
> 	...
> 
> And any other methods we could find useful, of course.
> 
> Also, this goes along with the future, including stream support, "input 
> stream playobjects" and such.

I agree that "we should". It would maybe be useful if you could come up
with a concrete proposal, which we can put into the CVS. If you have things
like embedding, of course a working implementation of at least one PlayObject
that supports it would be good when we agree to use it.

Two remarks:

1. Probably it would be the best to let a PlayObject be a "collection" of
various interfaces. For instance, I could imagine the following:

- PlayObject       => has seek/pause/halt/... and so on
- AudioPlayObject  => produces a left/right stream
- VideoPlayObject  => supports changing size/fullscreen mode/...
- EmbedPlayObject  => supports X11 style embedding
- StreamPlayObject => can play a stream (rather than taking media from file)

That way, for instance, an mp2 playobject which supports all of the above
capabilities would be declared as

interface MP2PlayObject : PlayObject, AudioPlayObject,
    VideoPlayObject, EmbedPlayObject, StreamPlayObject
{
}

and apps like noatun could then add controls for the various capabilities,
and DynamicCast(...) to find out whether a playobject can do "foo" as well.

When we are not using inheritance, but a "collection" of interfaces, it
should be no problem to add new capabilities later without breaking
binary compatibility.

2. There are dynamic invocations in MCOP, so you can actually replace this

interface X {
 	string property(string )
 	sequence<string> properties();

	/** supports properties title and author **/
}

with this:

interface X {
	attribute string title, author;
};

In C++, if you want to set the title (without knowing that there is a title
attribute), you can do so using

  DynamicRequest(x).method("_set_title").param("new title").invoke();

I just wanted to mention that this is there, we don't necessarily need to
use that. The idea of hints in interfaces would enable us to add more
information, though (which is what autogenerated effect uis require, too),
like

interface X {
	attribute string title [ visible=true, caption="Title" ];
	attribute string author [ visible=true, caption="Author" ];
};

Note that hints in interfaces are unimplemented currently - I intend to do
this some time, but have not had the time yet. But they can be useful for
instance for specifying which attributes to show, and in what way to show
and edit them (i.e. min/max values for attributes, or fields that only
accept a filename).

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]