[Mark SiblyKeymaster]

It’s possible the BackgroundColor style for Mojo.ToolButton style class is not transparent.

[Mark SiblyKeymaster]

Try building mx2cc first, then modules (if that’s possible).

mx2cc has been updated so it can build asm files. If you haven’t rebuilt it, the asm files used by new Fiber will probably be treated as assets not built.

I shouldn’t have commited the new fiber stuff without also commiting new mx2cc binaries…my bad.

[Mark SiblyKeymaster]

Yay!

[Mark SiblyKeymaster]

I’m *nearly* there with defender, but of course there have been many changes since XMAS.

I also keep finding things I want to fix along the way – I’ve currently been diverted by audio and have decided to sort that out ASAP as SDL_Mixer just isn’t powerful enough.

I’m going for openal to start with, which alas means an additional dll for windows and maybe linux builds, but this gets added automatically for you.

The upside is it’s builtin to macos/ios/emscripten and I’m familiar with it. I’ve also found out you can easily stream (via polling alas) your own data ala vsynth so I want to support that too.

But ALL of this has been interupted by an android issue with monkey1 so I’m currently working on nested jobs…

[Mark SiblyKeymaster]

Yes!

[Mark SiblyKeymaster]

Yes, will be added SOON.

[Mark SiblyKeymaster]

Any chance you can send me the project? Try and get it as ‘small’ as possible first please!

I doubt the fields are ‘overlapping’, but there’s a chance debugger output could be incorrect so that could be confusing things.

It could also be a GC issue. You could try enabling the #define BBGC_DEBUG 1 in modules/monkey/native/bbgc.h and rebuilding everything. This will cause the app to leak ALL memory allocated (so the bug better happen fast!) but it will bring up an error if a chunk of memory is incorrectly re-used.

[Mark SiblyKeymaster]

No idea sorry – building and running the default ‘simple console app’ works fine here.

[Mark SiblyKeymaster]

Could it be related to this?

http://apple.stackexchange.com/questions/111168/how-to-change-the-cursor-hotspot-in-os-x-10-8-5-mountain-lion

Sounds like a ‘just the way it is’ issue…that’s what I’d always assumed anyway.

[Mark SiblyKeymaster]

You should be activated too wiebow.

[Mark SiblyKeymaster]

I can’t see where you’re actually calling ‘RequestDir’ so it’s hard to say what’s wrong.

But there is an issue to do with the native mojo.requesters functions you may be encountering. These have to be run on the GUI thread on some targets (macos I think…) so due to the way the fiber system used to work (ie: fibers were really threads) I had to wrap them like this if I wanted to be able to call them from a fiber:

Monkey

Method RequestFile:String( title:String,filters:String,save:Bool,path:String="" ) Local future:=New Future<String> App.Idle+=Lambda() future.Set( mojo.requesters.RequestFile( title,filters,save,path ) ) End Return future.Get() End

1 2 3 4 5 6 7 8 9 10 11

Method RequestFile:String( title:String,filters:String,save:Bool,path:String="" )   Local future:=New Future<String> App.Idle+=Lambda() future.Set( mojo.requesters.RequestFile( title,filters,save,path ) ) End Return future.Get() End

What this does is ‘switch back’ to main thread (App.Idle callbacks always run on the main thread) to run the native requester, and then switch back to the original fiber after the requester completes. Note that this was a special case fix that was only necessary due to limitations of system requesters (and the old fiber system). With the new fiber system, this wrapper should no longer be necessary as fibers are no longer threads (so you can now safely render on fibers too!).

So if you’ve placed your StringDialog.Run call inside an App.Idle+=Lambda somewhere, you’ll actually be running the dialog on the main thread – possibly the complete opposite of what you were thinking! If you’ve done this, the fix is simply to call StringDialog.Run() directly instead of inside App.Idle. To start with, try calling it at the top of OnFileNew() or OnFileOpen() or something for testing.

Ted2 fiber creation is actually handled by the ‘Action’ system. By default, when you Trigger() an action (which is what clicking a button or selecting a menu item etc do) a new fiber will be created to run the ‘Triggered’ callbacks (see Action.Trigger() source). Since all menus, buttons and hotkeys are implemented via actions, the action code is always called on a fiber and can therefore safely ‘suspend’ itself whenever it wants.

Actually, once Ted2 is up and running, the only code that runs on the main fiber is the OnBlahEvent handlers in mojox. These typically result in an action being triggered somewhere so all/most of the code in MainWindow ends up running on a fiber. Actually, it occurs to me this is not true in some case, eg: TabView.TabChanged doesn’t start a fiber I think, and probably should.

[Mark SiblyKeymaster]

Check out the TextDialog.Run() function for an example of a modal dialog.

The key thing is that Run() MUST be called on a fiber because it blocks. The bit that actually blocks is the “Local r:=result.Get()” line.

[Mark SiblyKeymaster]

Sorry about that – more wordpress weirdness, should be fixed now.

[Mark SiblyKeymaster]

Si, new code up at github contains a rewrite of the fiber code that will currently break on the pi.

For pi fibers, you’ll need to select the correct native/asm files (in modules/std/fiber) and #import them in fcontext.monkey2.

There should be suitable asm for pi in there (there’s a bunch, it’s ripped from boost) if not we’ll need to write our own!

The new fiber system should be a LOT faster than the old one, and way more tunable re: stack size etc.

[Mark SiblyKeymaster]

To use “letterbox” layout, you need to also provide an ‘OnMeasure:Vec2i() Override’ method, or mojo wont know what size you want the letterbox ‘content’ to be, ie: the size of the window and the size of the letterbox are 2 different things. Adding this fixes the problem here:

Monkey

Method OnMeasure:Vec2i() Override Return New Vec2i( 1024,768 ) End

1 2 3 4

Method OnMeasure:Vec2i() Override Return New Vec2i( 1024,768 ) End

The default OnMeasure() returns (0,0) which is likely to cause problems! I may change this (or maybe add a check for silly letterbox sizes?) but the solution remains the same – OnMeasure should be implemented when using “letterbox” layout.

Note the Fullscreen property is @hidden as it’s still under development (sorry if I used it in a banana). There will definitely be *some* way to do this (I quite like the idea of a ‘Flags’ property so you can update any flag after window creation) so use it for now but it may be flaky. Actually, the fact that it’s working here means that it’s broken(!) as it’s ignoring the (0,0) letterbox size you requested!

[Author]

Posts