efl/src/lib/emotion/efl_canvas_video.eo

107 lines
4.5 KiB
Plaintext
Raw Normal View History

class @beta Efl.Canvas.Video extends Efl.Canvas.Group
implements Efl.File, Efl.Audio_Control, Efl.Player, Efl.Playable,
Efl.Gfx.Image, Efl.Gfx.Image_Load_Controller
{
[[Efl canvas video class]]
methods {
@property option {
[[Sets options for the current module.
This function allows one to mute the video or audio of the
emotion object.
Please don't use this function, consider using
@Efl.Audio_Control.mute instead.
]]
set {
2014-08-06 03:56:01 -07:00
}
values {
opt: string; [[The option that is being set. Currently
supported options: "video" and "audio".]]
val: string; [[The value of the option. Currently only
supports "off" (?!?!?!)]]
2014-08-06 03:56:01 -07:00
}
}
@property engine {
[[Initializes an emotion object with the specified module.
This function is required after creating the emotion object,
in order to specify which module will be used with this
object. Different objects can use different modules to
play a media file. The current supported modules are
gstreamer and xine.
To use any of them, you need to make sure that support for
them was compiled correctly.
It's possible to disable the build of a module with
--disable-module_name.
See also @Efl.File.file.
]]
set {
return: bool; [[$true if the specified module was successfully
initialized for this object, $false otherwise.]]
2014-08-06 03:56:01 -07:00
}
values {
module_filename: string; [[The name of the module to be
used (gstreamer or xine).]]
2014-08-06 03:56:01 -07:00
}
}
}
implements {
Efl.Object.constructor;
Efl.Gfx.Entity.position { set; }
Efl.Gfx.Entity.size { set; }
Efl.File.load;
Efl.File.unload;
Efl.File.file { set; }
Efl.File.loaded { get; }
Efl.Player.playing { get; set; }
Efl.Player.paused { get; set; }
Efl.Player.playback_position { get; set; }
Efl.Player.playback_progress { get; set; }
Efl.Audio_Control.volume { get; set; }
Efl.Audio_Control.mute { get; set; }
Efl.Playable.length { get; }
Efl.Playable.seekable { get; }
Efl.Gfx.Image_Load_Controller.load_size { get; }
Efl.Gfx.Image.ratio { get; }
Efl.Gfx.Image.smooth_scale { get; set; }
2014-08-06 03:56:01 -07:00
}
events {
frame,decode: void; [[Called when the frame was decoded]]
position,change: void; [[Called when the position changed]]
length,change: void; [[Called when the length changed]]
frame,resize: void; [[Called when the frame was resized]]
playback,start: void; [[Called when playback started]]
playback,stop: void; [[Called when playback stopped]]
volume,change: void; [[Called when volume changed]]
channels,change: void; [[Called when the channels changed]]
title,change: void; [[Called when the title changed]]
progress,change: void; [[Called when the progress changed]]
ref,change: void; [[Called when ref changed]]
button,num,change: void; [[Called when button number changed]]
button,change: void; [[Called when button changed]]
open,done: void; [[Called when the files was opened]]
position,save,done: void; [[Called when the position was saved]]
position,save,fail: void; [[Called when saving the position failed]]
position,load,done: void; [[Called when the position loaded]]
position,load,fail: void; [[Called when loading the position failed]]
}
2014-08-06 03:56:01 -07:00
}
/* FIXME: Need to be added:
emotion: emotion EAPI macro to EMOTION_API in Emotion library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-09-20 06:19:07 -07:00
EMOTION_API double emotion_object_buffer_size_get (const Evas_Object *obj);
EMOTION_API const char *emotion_object_progress_info_get (const Evas_Object *obj);
2014-08-06 03:56:01 -07:00
Everything starting from (needs to be added):
emotion: emotion EAPI macro to EMOTION_API in Emotion library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-09-20 06:19:07 -07:00
EMOTION_API int emotion_object_audio_channel_count (const Evas_Object *obj);
2014-08-06 03:56:01 -07:00
Should this be part of player or emotion object?
emotion: emotion EAPI macro to EMOTION_API in Emotion library Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass ```__attribute__ ((visibility ("default")))``` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as ```__atttribute__((visibility("default")))```. However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
2020-09-20 06:19:07 -07:00
EMOTION_API void emotion_object_event_simple_send (Evas_Object *obj, Emotion_Event ev);
2014-08-06 03:56:01 -07:00
Deliberations:
Should this really implement the image interface?
*/