added ability to give libvlc initializing options ('--no-xlib' for ex…

[passenger94]

…ample) + test

[ccoupe]

which file/script are you using for testing start blocks? OSX needs to test those because it sometimes exhibits different timing/drawing behaviors.

[passenger94]

you can use the video test files in Test folders they are perfect for that, i needed to have a look more urgently at start event because of those ones ! (Testing is not yet completely ready, still some threading issue from time to times, - vlc and pulse audio server related here - )

Everything start event related is happening in canvas.c, only native part is the drawing_queue in gtk.c, i didn't touched at that but it's obviously part of the drawing cycle Every time a draw event occurs (it's gtk decision - gtk_queue_draw or whatever on osx- ),, at the end of that drawing, shoes_canvas_paint_call emits a start event : i.e. calls shoes_canvas_send_start, everything is hapening in there, with a hidden big surprise : we have to deal with 2 canvas ! (it's related to the nested slot concept, still not yet totally clear on that)

If everything is working, we don't need timer(0) anymore, only slot.start {}, so you can test against app or demo using that timer trick one can do this kind of voodoo now :

@mainstack.clear { tagline "Be patient it's going to take time ..." }
        @mainstack.start { |slot| ## wait for tagline above to come to screen
            do_long_stuff              ## prepare some non gui stuff
            build_stack                  ## we got what we need to rebuild @mainstack
            @mainstack.start {        ## wait for mainstack to be on screen
                @header.remove        ## rebuid header on top of @mainstack
                @build_header.call 
            }
        }
        .......

start inside start ..... in predictable manner

[passenger94]

for this to work on OSX we need to replace the gtk specific : https://github.com/Shoes3/shoes3/blob/master/shoes/canvas.c#L1852 with the osx equivalent, looks like it should be something like : https://github.com/Shoes3/shoes3/blob/master/shoes/native/cocoa.m#L596

either by means of ifdef, or creating clean native methods for this would be cool, before the 3.3.1 release, @ccoupe , is it possible ?

[ccoupe]

Everything is possible. I'd like to get my Windows font fixes into 3.3.1 too. I'll make some new betas and announce those with a note that a couple more features/fixes will show up in the released.

[passenger94]

yeah, no hurry :-) as you were about to release, i thought about a reminder that this feature is not complete

Also tests are not working on Windows because of some threading issue between tests and shoes and vlc (lots of people in there ...) only the tests are problematic

[passenger94]

Tests (the way i try to do it) don't wok on Windows (hangs) because of shoes_app_g_poll not being part of the game on that platform https://github.com/Shoes3/shoes3/blob/master/shoes/native/gtk.c#L853

if i use a g_timeout in place of a app_g_poll, on Linux, while it seems to work elsewhere, it hangs also at the same place in Tests (when waiting in a ruby thread for a slot start event , which in fact happens but thread in tests don't see it, entering in an infinite loop))

in regular Linux (using shoes_app_g_poll), all seems fine ... https://github.com/Shoes3/shoes3/blob/master/shoes/native/gtk.c#L631

What do you think, should i rethink my approach in test and try to find a portable way to do them ? Is it inherently wrong to wait in a ruby thread for a GUI event (even though it seems to work on linux) ?

Too bad Windows and Linux differs so much when creating the gtk main loop - is this a valid statement ?

[ccoupe]

Windows ruby and gtk differences of opinion of how to implement select and poll on windows (simulated file descriptors). I think I used Ruby fd's instead of gtk/glib/mingw. We are lucky it works at all (and those compiler warnings are hard to silence on Windows). Windows does not have native pthreads either so those have to be simulated and there can be different libraries involved in that. Sorting it out is quite difficult.

[passenger94]

Ok, i came up with something working on both platforms. This time i keep everything gui related exclusively in Shoes, and call test unit when shoes is ready, .... ... which make sense !!! :rotating_light: No more Threads ! Don't mix ruby threads in Shoes gui business ! is something i need to remember.

Glib has all sorts of cabalistic Ancient Woodoo invocations for Threading witchcraft, would it be reasonable to bring to Shoes some threading facilities - all we have right now are Timers - ? (don't know what is the situation on OSX)

[ccoupe]

gtk lore is rife with warnings to not update the gui in new threads. and that applies to Ruby threads and even more so on Windows.

I don't see much fun in trying to introduce Shoes specific thread abilities unless someone is willing to rewrite Ruby/w32 to use gtk/glib threads (and gio?) which would be a massive task to be maintained forever. Maybe something like a Shoes method/verbdo_in_gui(&blk) which is just asking for trouble.

FWIW, Shoes4 (jruby) OSX needs a command line flag --start-on-first-hread or something like that. Anecdotally, jruby/osx spins up more ruby threads before the gui gets running. Life is hard enough in Shoes/MRI.