libvisual-devel — libvisual mailinglist for developers

Re: [Libvisual-devel] Re: xmms plugin

[Duilio J. P. <dp...@fc...>]

> VisUI is too much for the next release, So I think it's most important
> to fix the small issues, and get the XMMS plugin stable (fix GL
> at startup and such)... And also stress test it a bit to see if there
> aren't any crashes left anylonger... If you have time, It might also be
> nice to use GtkCList and the method xmms uses to check for double 
> clicks to morph to plugins. I think that this is quite important because
> right now there isn't an intuitive way to start a different plugin.

Ok, I will work on this. I have tried to do it without with the current
GtkList, listen on the GDK_BUTTON_PRESS event and using a timer for to
detect the double, and it works well on configure dialog alone, but it
is trashed by SDL when the SDL screen is created (probably SDL sets
again the X event listeners). So I will rewrite this to use GtkCList. I
will be on travel this weekend, I hope can do this before, but not shure
:-(

> I'll be doing some more cleanups in libvisual itself and then I want to
> do a bugfix release. After that I want to work on the following items:
> 
> 1. VisUI
> 2. VisVideo scaler, both NEAREST and BILINEAR methods. (need this for 
>    good coverart supprt within amarok.)
> 3. Portability fixes.
> 4. All kind of things that comeup within this cycle.
> 
> What is your idea about this ?
> 
> Cheers,
> Dennis

I think are all good ideas! I suggest add one more: review all the API
functions looking for pointer arguments that will not be changed, and
change them to 'const'.


Bye,
Duilio.

[Libvisual-devel] Preview of Python/C++ wrappers

[Gustavo S. B. <gu...@gs...>]

Hello,

Tomorrow I'll have an exam so what I started to play with? Yes, you guess=
:
Python and C++ wrappers! :D

I do not plan to code the C++, just started to play with it while I was
looking for help with the Python version, they're quite similar, but the
python version is more complete... If someone have interest in C++
version, you can follow this code.

The Python version is incomplete also, Color, Palette and Video are
complete, other are pending. So until now I can't have a simplesdl
working, but I hope to have one by next week.
   It uses classes to represent VisColor, VisPalette and VisVideo and the
operations related to them, methods follow C API and I have some
aliases set up, like is_depth_supported() -> depth_is_supported().
Errors are translated into exceptions. Every Class/method have its own
docstring (python documentation).


For the Python wrapper you need the PyRex pre-compiler...

Files:
 http://tux08.ltc.ic.unicamp.br/~gustavo/libvisual-c++.tar.bz2
 http://tux08.ltc.ic.unicamp.br/~gustavo/libvisual-python.tar.bz2

--=20
Gustavo Sverzut Barbieri
------------------------------------------
Engenharia de Computa=E7=E3o 2001 - UNICAMP
Grupo Pr=F3 Software Livre - UNICAMP
Mobile: (19) 9165 8010
Jabber: gsb...@ja...
ICQ: 17249123

[Libvisual-devel] Semi PRE 0.1.7 release.

[Dennis S. <sy...@yo...>]

Heya Guys...

I've put online some packages:

http://www.plasser.nl/synap/libvisual/snapshots/0.1.7/

For those who don't run CVS but want to *hint* test the upcoming 0.1.7 
release :)


Cheers,
Dennis

Re: [Libvisual-devel] Website Admin Backend now (sort of) online.

[Dennis S. <sy...@yo...>]

On Wed, 2004-10-06 at 20:43 +0100, Andrew Godwin wrote:
> I don't know how many of you this applies to, but there you go. Plus it gets 
> archived this way...
> 
> The first stage of the content management manager (admin backend) is now 
> online. It's quite basic, but it's a big step up from editing databases by 
> hand; now, creation/editing/deletion of content is possible.

Wow, cool, can you mail me the user/passwd for login (in private mail).

> The idea of the system is that each page is made up of several content items; 
> for example, the main page has an 'about' item and a 'news' item. Hence, the 
> 'pages' are simply containers for the 'content items'.

Sounds good.

> What's missing:
> 
> 'Old News' option on the main page.
> Menu editor (it's currently only DB-editable).
> Nicer page editor (select content from title, edit content if you need to).
> User admin (for the main administrator, of course)
> Gallery (for screenshots).
> 
> And probably more.
> 
> Again, this is only basic. But you can post news and edit the current content, 
> and that's better than nothing.
> 
> Of course, this is login-limited; and, at the moment, any user can do all 
> functions. I don't know what you want to do re user accounts, Dennis, so...
> There will be restrictions in the future (i.e. only news, only content, etc.).

Nah, just global acounts will do, Every person I'll grant access to the
page I thrust well anough :), Tho I want different users so we can have
something like 'posted by .....', so not just one global 'admin' user.

Cheers,
Dennis

[Libvisual-devel] Website Admin Backend now (sort of) online.

[Andrew G. <and...@bl...>]

I don't know how many of you this applies to, but there you go. Plus it gets 
archived this way...

The first stage of the content management manager (admin backend) is now 
online. It's quite basic, but it's a big step up from editing databases by 
hand; now, creation/editing/deletion of content is possible.

The idea of the system is that each page is made up of several content items; 
for example, the main page has an 'about' item and a 'news' item. Hence, the 
'pages' are simply containers for the 'content items'.

Editing of news items and content items is pretty simple; you choose the item, 
click edit, and get a nice WYSIWYG editor to play around with. However, page 
editing is currently a textbox where you change the list of content IDs.

I recommend, if you do use it, to only use it to add news (which is 
automatically done in date order) and edit current content. 

What's missing:

'Old News' option on the main page.
Menu editor (it's currently only DB-editable).
Nicer page editor (select content from title, edit content if you need to).
User admin (for the main administrator, of course)
Gallery (for screenshots).

And probably more.

Again, this is only basic. But you can post news and edit the current content, 
and that's better than nothing.

Of course, this is login-limited; and, at the moment, any user can do all 
functions. I don't know what you want to do re user accounts, Dennis, so...
There will be restrictions in the future (i.e. only news, only content, etc.).

Oh, and it's at /v2/admin.php.

Andrew

Re: [Libvisual-devel] VisError

[Duilio P. <dp...@fc...>]

> IMHO these visual_log() serves just for debug, but not for the
> programmers and methods to enable programmers to get the error messages
> should be allowed.

Shure, that's the only purpose of visual_log(). For checking function's
preconditions, we have visual_log_return_{val_}if_fail(). Still missing an
unified framework for the values that this methods will return, which is
exactly what you propose.
> * Better Error Handling:
>
> Take a look at visual_video_new:
>
>                video = visual_mem_new0 (VisVideo, 1);
>
> Great, you allocated nothing, NULL is returned and where is it checked?
> Nowhere...

visual_mem_new0() never returns NULL, if cannot get it a new chunk of
memory, it shows a message an raises an error.
> What about visual_video_new_with_buffer()?
>
>        VisVideo *visual_video_new_with_buffer (int width, int height,
> VisVideoDepth depth)
>        {
>                VisVideo *video;
>                int ret;
>
>                video = visual_video_new ();
>
> Uncaught error...
>
>                visual_video_set_depth (video, depth);
>
> another...

This is true.

>                visual_video_set_dimension (video, width, height);
>
> even another...

Another one.

>                video->screenbuffer = NULL;
>                ret = visual_video_allocate_buffer (video);
>
> another...
>
>                if (ret < 0) {
>                        /*
>                         * Restore the flag set by visual_video_new().
>                         */
>                        video->flags =
>                        VISUAL_VIDEO_FLAG_EXTERNAL_BUFFER;
>                        visual_video_free (video);
>                        return NULL;
>                }
>
>                return video;
>        }

I think your idea is right. I guess Dennis has not done this yet waiting
for 0.1.8, the really, really cleaned up release :-)
Bye,
Duilio.

[Libvisual-devel] Made a libvisual beep media player plugin.

[Dennis S. <sy...@yo...>]

Made a rough port of the xmms plugin to BMP.

the player: http://www.sosdg.org/~larne/w/Main_Page

I've got to put the port in CVS.. will do that later today


Cheers,
Dennis

Re: [Libvisual-devel] VisError

[Gustavo S. B. <gu...@gs...>]

Dennis Smit said:
> Added the VisError subsystem to CVS. It consists out of:
>
> visual_error_raise
> visual_error_set_handler
>
> I've put these in lv_error.c, lv_error.h because at a
> later stage we might want to add more error handling
> stuff, thus having it in it's own files is better.
>
> Thanks for the suggestion regarding the error handler
> Duilio.


I'm converting the C API to Python, but I want to keep thing OO using
classes and errors via Exceptions... but I found out that I cannot really
check what error occurred and looking at the code, many errors are not
caught.

IMHO these visual_log() serves just for debug, but not for the programmer=
s
and methods to enable programmers to get the error messages should be
allowed.

* Enabling programmers to get the error messages/code:

     The best way IMO is to create a table relating error codes to
messages and functions should return the corresponding error (maybe
-1 * errorcode).
     Right now, every error is -1 and there is no way to know what happen=
ed!
     We could have this function:

        const char *visual_get_error_message( int errcode )
        {
           if ( errcode < 0 ) errcode *=3D -1;
           if ( errcode >=3D visual_error_messages_size ) errcode =3D 0;
           return visual_error_messages[ errcode ];
        }

     And the table as:

        int visual_error_messages_size =3D 3;
        char visual_error_messages[][] =3D {
           "Success.",
           "Unknow Error.",
           "Can not allocate memory."
        };

     This way old functions will return "Unknow Error." until they're
updated.

      To handle functions that return pointers we could have them changed
to _r( ..., int *errcode ) and the version without _r uses the
global error variable visual_errcode, the "_r" stands for
"reentrant", just like libc ones. For example:
         int visual_errcode =3D 0;

         VisVideo *visual_video_new_r( int *errcode )
         {
                 VisVideo *video;

                 video =3D visual_mem_new0 (VisVideo, 1);
                 if ( video =3D=3D NULL )
                 {
                         *errcode =3D -2;
                         return NULL;
                 }

                 video->screenbuffer =3D NULL;

              /*
               * By default, we suppose an external buffer will be used.
               */
              video->flags =3D VISUAL_VIDEO_FLAG_EXTERNAL_BUFFER;

              return video;
      }

      VisVideo *visual_video_new()
      {
              return visual_video_new( &visual_errcode );
      }




* Better Error Handling:

Take a look at visual_video_new:

                video =3D visual_mem_new0 (VisVideo, 1);

Great, you allocated nothing, NULL is returned and where is it checked?
Nowhere...


                video->screenbuffer =3D NULL;

Segfault! What the user/programmer knows? Nothing.

What about visual_video_new_with_buffer()?

        VisVideo *visual_video_new_with_buffer (int width, int height,
VisVideoDepth depth)
        {
                VisVideo *video;
                int ret;

                video =3D visual_video_new ();

Uncaught error...

                visual_video_set_depth (video, depth);

another...

                visual_video_set_dimension (video, width, height);

even another...

                video->screenbuffer =3D NULL;
                ret =3D visual_video_allocate_buffer (video);

another...

                if (ret < 0) {
                        /*
                         * Restore the flag set by visual_video_new().
                         */
                        video->flags =3D VISUAL_VIDEO_FLAG_EXTERNAL_BUFFE=
R;
                        visual_video_free (video);
                        return NULL;
                }

                return video;
        }



But since we believe programmers don't do mistake, it's okay... It should
be used just to enforce our code does the right thing.
   If we do the right checking on every entry point, things can be assume=
d
to be all right, but as visual_video_new_with_buffer() is an entry
point and we don't check we can't be sure it will work later.


What do you think?

--=20
Gustavo Sverzut Barbieri
------------------------------------------
Engenharia de Computa=E7=E3o 2001 - UNICAMP
Grupo Pr=F3 Software Livre - UNICAMP
Mobile: (19) 9165 8010
Jabber: gsb...@ja...
ICQ: 17249123

Re: [Libvisual-devel] Random design questions:

[Burkhard P. <pl...@ip...>]

> Well the point is that it's not abstract, if we were
> forcing the user to access everything directly through
> the fields of the structures, every small change in the structure
> would mean that every plugin needs to be updated...

What needs to be updated?
If the priv member isn't renamed, the code must only be
recompiled. If the direct accessable members are put at the
beginning of the struct and arent't changed, even recompilation
isn't necessary.

If a stable ABI is desired, you'll need access functions
for everything (macros arent't enough).
In this case, I would recommend to make the struct completely
anonymous (put only a forward declaration in the .h file and
the struct definition into the .c file). In this case, gcc will
not allow to access any struct members directly from another
.c file.

-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102

Re: [Libvisual-devel] Re: xmms plugin

[Dennis S. <sy...@yo...>]

On Tue, 2004-10-05 at 22:18 -0300, Duilio Javier Protti wrote:
> I see... I was believed that extraction and generation of UI would be
> doing it automatically by libvisual, but if this is responsibility of
> the developer, I think that VisUI is the right way.
> We must work on this next?

VisUI is too much for the next release, So I think it's most important
to fix the small issues, and get the XMMS plugin stable (fix GL
at startup and such)... And also stress test it a bit to see if there
aren't any crashes left anylonger... If you have time, It might also be
nice to use GtkCList and the method xmms uses to check for double 
clicks to morph to plugins. I think that this is quite important because
right now there isn't an intuitive way to start a different plugin.

I'll be doing some more cleanups in libvisual itself and then I want to
do a bugfix release. After that I want to work on the following items:

1. VisUI
2. VisVideo scaler, both NEAREST and BILINEAR methods. (need this for 
   good coverart supprt within amarok.)
3. Portability fixes.
4. All kind of things that comeup within this cycle.

What is your idea about this ?

Cheers,
Dennis

Re: [Libvisual-devel] VisError

[Dennis S. <sy...@yo...>]

On Tue, 2004-10-05 at 15:21 -0300, Duilio Protti wrote:
> > Added the VisError subsystem to CVS. It consists out of:
> >
> > visual_error_raise
> > visual_error_set_handler
> >
> > I've put these in lv_error.c, lv_error.h because at a
> > later stage we might want to add more error handling
> > stuff, thus having it in it's own files is better.
> 
> Now what we have too much headers files on libvisual, probably would be a
> good point to move all headers to an 'include' directory within CVS.

Do we have too many headers ?, I'm not sure about this, I had this idea
before, but on the other hand... Why is it needed ? Having them in one
dir keeps the .h, .c pairs nice als close to each other, (That is how I
personally feel about it atleast..)

Cheers,
Dennis

Re: [Libvisual-devel] Random design questions:

[Dennis S. <sy...@yo...>]

On Wed, 2004-10-06 at 11:26 +0200, Burkhard Plaum wrote:
> In all cases, the programmer has to write one line,
> so typing time is hardly saved. Using
> 
> BlahPriv *priv = plugin->priv;
> 
> has the advantage, that everyone knows what's going on,
> even without reading documentation. I use this method
> in my whole code.

Well the point is that it's not abstract, if we were
forcing the user to access everything directly through
the fields of the structures, every small change in the structure
would mean that every plugin needs to be updated...

Dennis

Re: [Libvisual-devel] Random design questions:

[Burkhard P. <pl...@ip...>]

Dennis Smit wrote:
> Heya list,
> 
> I've got some things I'd like to discuss:
> 
> Currently in plugins we often do BlahPriv *priv = plugin->priv;
> 
> what do you people think about having something like:
> 
> BlahPriv *priv = VISUAL_PLUGIN_PRIVATE (plugin);
> 
> or, would it nicer to make a define in the
> style of visual_plugin_get_private (plugin);, to be in
> style with the rest of the accessor methods ?
> 
In all cases, the programmer has to write one line,
so typing time is hardly saved. Using

BlahPriv *priv = plugin->priv;

has the advantage, that everyone knows what's going on,
even without reading documentation. I use this method
in my whole code.


-- 
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: +49 711 685-2187
Fax.:            -3102

Re: [Libvisual-devel] Re: xmms plugin

[Duilio J. P. <dp...@fc...>]

> There will be a VisUIContainer
> kinda thing (don't take things to literally
> btw, I'm just sketching).
> 
> You can pack other VisUIContainers in that
> like a VisUIGroup.
> 
> (we will keep it very basic)
> 
> For example:
> ___
> VisUIContainer *uicont = visual_plugin_get_ui_container (plugin);
> 
> VisUIGroup *uigroup = visual_ui_group_new ("Sexy configs");
> VisUILabel *uilabel = visual_ui_label_new ("Something: ");
> VisUIText *uitext = visual_ui_text_new (paramentry);
> VisUIBox *uibox = visual_ui_box_new (VISUAL_UI_HBOX);
> 
> visual_ui_box_pack (uibox, uilabel);
> visual_ui_box_pack (uibox, uitext);
> visual_ui_group_add (uigroup, uibox);
> 
> visual_ui_container_add (uicont, uigroup);
> ___
> 
> 
> And have some good API to get extract the userinterface data
> so you can easily build it within your app.

I see... I was believed that extraction and generation of UI would be
doing it automatically by libvisual, but if this is responsibility of
the developer, I think that VisUI is the right way.
We must work on this next?


Bye,
Duilio.

Re: [Libvisual-devel] Random design questions:

[Duilio J. P. <dp...@fc...>]

> what do you people think about having something like:
> 
> BlahPriv *priv = VISUAL_PLUGIN_PRIVATE (plugin);
> 
> or, would it nicer to make a define in the
> style of visual_plugin_get_private (plugin);, to be in
> style with the rest of the accessor methods ?

I like more the last method.


Bye,
Duilio.

[Libvisual-devel] Libvisual VisUI system, proposal draft.

[Dennis S. <sy...@yo...>]

Heya Fellahs!

I made a draft for VisUI. I'd like to know what you guys think about 
this:

http://libvisual.sf.net/VISUI_DRAFT


Please take a look at it and comment on it :)

Cheers,
Dennis

Re: [Libvisual-devel] New Libvisual Website Up

[Dennis S. <sy...@yo...>]

Alright, Thanks a lot for the current site! it's awesome!

Can't wait for the admin stuff ;)

Cheers,
Dennis

On Tue, 2004-10-05 at 20:58 +0100, Andrew Godwin wrote:
> It's done.
> 
> I have a halfway-done admin backend here, but there's no user validation (so 
> anyone could use it :-s ). It should be finished soon.
> 
> In the meantime, if you want to add some news, either send me a message or 
> load up the DB and have a shot at it ;)
> 
> Andrew

[Libvisual-devel] New Libvisual Website Up

[Andrew G. <and...@bl...>]

It's done.

I have a halfway-done admin backend here, but there's no user validation (so 
anyone could use it :-s ). It should be finished soon.

In the meantime, if you want to add some news, either send me a message or 
load up the DB and have a shot at it ;)

Andrew

[Libvisual-devel] Random design questions:

[Dennis S. <sy...@yo...>]

Heya list,

I've got some things I'd like to discuss:

Currently in plugins we often do BlahPriv *priv = plugin->priv;

what do you people think about having something like:

BlahPriv *priv = VISUAL_PLUGIN_PRIVATE (plugin);

or, would it nicer to make a define in the
style of visual_plugin_get_private (plugin);, to be in
style with the rest of the accessor methods ?

Also, would there be defines, functions to make plugin creation easier ?

anyone suggestions ?

Cheers,
Dennis

Re: [Libvisual-devel] Libvisual Website

[Dennis S. <sy...@yo...>]

On Tue, 2004-10-05 at 19:58 +0100, Andrew Godwin wrote:
> I'm going to switch the site in the next hour or so... I'll just write some 
> generic mailing list instructions, unless you have something more specific in 
> mind?

Just give links to the subscribe page at the sf.net project site, for 
both the user and devel list. Make sure you make clear that devel
relates to software  development, and user for user specific questions..
That'll do it for sure..

Thanks
Dennis

Re: [Libvisual-devel] Libvisual Website

[Andrew G. <and...@bl...>]

I'm going to switch the site in the next hour or so... I'll just write some 
generic mailing list instructions, unless you have something more specific in 
mind?

Andfew

Re: [Libvisual-devel] VisError

[Duilio P. <dp...@fc...>]

> Added the VisError subsystem to CVS. It consists out of:
>
> visual_error_raise
> visual_error_set_handler
>
> I've put these in lv_error.c, lv_error.h because at a
> later stage we might want to add more error handling
> stuff, thus having it in it's own files is better.

Now what we have too much headers files on libvisual, probably would be a
good point to move all headers to an 'include' directory within CVS.

Bye,
Duilio.

[Libvisual-devel] VisError

[Dennis S. <sy...@yo...>]

Added the VisError subsystem to CVS. It consists out of:

visual_error_raise
visual_error_set_handler

I've put these in lv_error.c, lv_error.h because at a
later stage we might want to add more error handling
stuff, thus having it in it's own files is better.

Thanks for the suggestion regarding the error handler
Duilio.


Cheers,
Dennis

Re: [Libvisual-devel] Re: the visual_log_error entry.

[Dennis S. <sy...@yo...>]

You're actually right on this, ofcourse when we handle it in the
error handle, it won't work when verboseness is set to absolutely
nothing. I'll add an API to set the error handler.

Thanks,
Dennis

On Sun, 2004-10-03 at 18:17 -0300, Duilio Javier Protti wrote:
> Ok, this is a good possibility. Another one would be to still raising
> an error after showing the error message, but allow setting the error
> handler, maybe adding to lv_libvisual module:
> 
> void visual_set_error_handler (...);
> 
> and a private function like:
> 
> void lv_abort();
> 
> Probably this approach would be more flexible.
> 
> 
> Bye,
> Duilio.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Libvisual-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libvisual-devel

Re: [Libvisual-devel] Libvisual Website

[Dennis S. <sy...@yo...>]

Great, can't wait to see more! :)

Keep up the good work!

On Tue, 2004-10-05 at 17:05 +0100, Andrew Godwin wrote:
> > Ok, now a few requests:
> >
> > 1. an: [older news] feature.
> Will add this after the admin interface; currentely, there's only three news 
> items ;)
> 
> > 2. an extra site: "Team".
> Will do via admin interface. Anyway, you need to write stuff in it.
> 
> > 3. remove "Email" and rename it to contact and have a description how to
> > 	join the mailing lists.
> Will do that now.
> 
> >
> > 4. Add an 'documentation' entry. We will put some docs there, both
> > 	user and devel docs.
> See 2)
> 
> OK, back to coding...
> 
> Andrew