Forum Replies Created
-
Posts
-
No idea sorry – are you using original Ted2?
Try a fresh unzip?
Reboot?
All config files are in the ‘bin’ directory – see ted2.config.json and ted2.state.json.
You probably want to delete ted2.state.json and restore ted2.config.json from github or orignal release.
Can you post the contents of those files here before you do?
He’s talking about something different here, ie: whether a function pointer is null or not, not an object.
I have no general problem with this change – I think it was disabled because it confused the c++ compiler but it should be easy enough to fix.
Another thing to note is that you can actually call a ‘null’ function pointer – it will perform a ‘NOP’ and return a Null value of the return type.
Ok, diddy2 published but again no docs.
Please run makedocs before zipping!
I’m not a huge fan of the modules system yet in Monkey2 yet though. I think the ability to organize in subfolders is a must, as my modules folder is already a jumbled mess.
You *can* use subfolders within a module no problem – see std, mojo etc. So you could stick all your ‘modules’ inside a single ‘jmd’ module, where the main jmd.monkey2 file #imports all the bits, ala std, mojo etc.
The main difference is that you can’t build individual ‘parts’ of a module this way, but in my experience this hasn’t been a problem as yet. When it is, I’ll investigate.
The upside is that importing/linking jmd is easier/faster because it’s just linking with one archive, and sticking your stuff up on something like module manager is much easier as it’s just one ‘chunk’.
> I have always liked developing apps in a single source file.
I try to avoid this if possible, as I find it too tempting to use globals which end up being hard to ‘unpick’ when you’re splitting things up into multiple files, eg: mx1 mojo.graphics! But that’s probably just me…
jondecker and peterigz activated.
Docs don’t do anything yet, but the idea is to be able to view them from the module reference section eventually.
Diddy2 is in the works, we could try that if you want
Ok, have enabled uploads for you and Shane.
Hi Mark, I have a module I would like to upload.
First 3rd party module published!
It’s missing the docs though. I’ll add an extra check for this tomorrow, unless there’s some reason you couldn’t makedocs it?
Also, the support link doesn’t work.
> Hi Mark, I have a module I would like to upload.
Ok, try now.
Please read instructions at bottom of page first!
Anyone got a module they want to try uploading?
It’s wordpress/bbpress crazy ‘auto-embed’ system.
It’s nice when it works, but that’s only about 37% of the time so I think I’ll have to disable it everywhere.
I’d start with pseudo modules ‘inside’ the app folder. You can code them pretty much the same way you’d code a real module – ie: have a root src file that imports other module files.
Then, when everything’s stabilized a bit you can think about making them real modules.
‘Links’ to modules will eventually be fixed, and it may be possible to have some kind of ‘auto-updating’ of modules when they’re imported, but for now it’s sanest to work on new module code as part of an app project so you don’t have to remember to update modules all the time.
I have tried my best with mx2 to make it easy to move files around without upsetting a project too much. You should only have to modify some import statements, and maybe some usings, so you try a few ways to organize things until you come up with something that works for you.
This is what I’ve done with ‘mojox’ – see ted2/mojox. All I really need to do to ‘modularize’ this is move the mojox folder to /modules and change my #import “mojox/mojox” to #import “<mojox>”.
View is in mojo.app, it’s actually the base class of Window.
If you can create a new theme by modifying just the theme.monkey2 file I’ll definitely add it to the release. But this is all likely to change in the long run (Style.Get should be in theme, and it should be possible to serialize a theme etc) so don’t get too carried away!
See source code for mojo.app.Skin for loading android style 9-patches. The Style class also has a ‘Skin’ property for setting skins. Padding rect goes ‘inside’ the skin, Margin rect goes ‘outside’.
Also, editor colors are inconveniently in ted2/mx2document.monkey2 so you’ll have to hack that too if you want to change editor colors.
You can make a pull request, but I wont be accepting any major architectural changes in the near future – sorry if I gave the wrong impression there.
If you are wanting to improve the look of the GUI, any tweaks to mojox/theme.monkey2 would be most welcome. The ‘Style’ system actually offers a lot of flexibility here, including the ability to use ‘nine-patch’ style images for any class of view. But this stuff is still undocced and a little rough so it might not be easy going.
You are free to release your own version though, perhaps I should start a monkey2 ‘projects’ forum for things like this?
>Should locals not be freed automatically when the function is exited?
You need to image.Discard() images when you’ve finished with them.
This will be partially automated in future so you’ll be able to discard ‘groups’ of resources with one call, but for now images should be discarded manually.
Some people think GC should deal with this, but I disagree. VRAM is precious and I don’t think it’s a good idea to trust the release of VRAM to the vaguaries of the GC system. In fact, this is a pretty good example of why – the app wont actually be consuming that much system ram, so it may well have alloced a LOT of VRAM by the time it gets around to GC-ing – by which time it may be too late.
