Maniaplanet Forum

gouxim wrote:Short answer: it is a bit presumptuous from you to say this

Longer answer: I work with manialib on a daily basis, i have written it, and i work with netbeans which provides code hints and completion. So in the end, documenting it will not make coding easier for me. It will just be more things to write and maintain.

Okay, maybe my wording wasn't right (and I didn't meant to be insulting).
Just writing documentation afterwards takes quite some more time then when you do it directly when you're coding it (at least that's my experience). And until now Nadeo projects don't have the reputation to be properly documentated and that's something I find quite a pity

No offence taken. If it was a pure open source project, i would probably document it from the begining. But this is mainly our internal framework , which i open source because i figured some may find it interesting.

It's true that Nadeo has not a very good reputation for documenting things. We are a small team and always have to choose between documentation, features, etc. In this very competitive market, it's always hard to choose to work on documentation.

It's getting better though! For instance we started https://github.com/maniaplanet/documentation a few month back. I agree it's not ideal, but it's a good start imo.

gouxim wrote:Short answer: it is a bit presumptuous from you to say this

Longer answer: I work with manialib on a daily basis, i have written it, and i work with netbeans which provides code hints and completion. So in the end, documenting it will not make coding easier for me. It will just be more things to write and maintain.

Adding in the documentation the return type to the functions of classes will allow Netbeans to give you better tips, if not very often it can't determine the type of the value returned. Even if you don't write a full documentation writing that would help quite a lot. Then as you don't use getters it isn't something you need to do very often.
And as a big hater of public attributes(even throught I use them a lot), netbeans also generates getter and setters automatically(Quite stupidly it won't try to guess the type of the variables to add the correct documentation so need to write it which is stupid (maybe a configuration I haven't seen)). But I can understand the coding fast to give priority to features even throught there is something quite good existing so why to rush?

Great job anyway and please tell magnetik to realese a version of ManaiLive before he uses the new library XD we will never finish coding our eXtensions if pass our time changing stuff

I like the idea of developing it "open source" on github

Personally I don´t write my manialinks as php Objects, I hava a maniascript/manialink gui which generates xml for me. I only need php(or any other language) to pass some data to the manialink. So what I would like to see in the future is something like this:
btw do you have any plans to extract the StyleParser from manialib too and make it available through composer ? I think the StyleParser is the most used maniaplanet library out there and it´s a bit overkill to import manialib all the time.

Jojo

Jojo_44 wrote:So what I would like to see in the future is something like this:

Code: Select all

$ml = new Manialink('mls/someManialink.xml');
$quad = $ml->find('id of the quad');
$quad->setPosn($x, $y);

I think it is pretty easy to do in a separate package. You just have to load your XML with DOM, then recursively parse the tree and create associated ManiaLib objects based on tag names. Don't think it'd be fast though, performance-wise.

Jojo_44 wrote: btw do you have any plans to extract the StyleParser from manialib too and make it available through composer ? I think the StyleParser is the most used maniaplanet library out there and it´s a bit overkill to import manialib all the time.

We didn't. But that's a good idea, we will do that

gouxim wrote:https://github.com/maniaplanet/manialib ... a4bb3bd8ca

https://github.com/maniaplanet/manialib ... b535941357

It just makes more sense

Alignment and Relative Alignment in ManiaLib\Manialink

* Frame Size and Alignment emulates the behaviour of standard elements alignment in frames. With this you can create logical containers with a size, and position them using aligns and relative aligns (see below).

* Relative Alignment helps position an element relative to its parent container. For this, you need a frame with a size and a child with a size ; for instance you can put a quad in the "bottom right corner of a frame with a size".

I created a Gist to help understand these concepts visually.

Demo manialink: manialib-manialink:align
Gist with PHP source: https://gist.github.com/gou1/9970824

ManiaLib\Manialink split and depends on ManiaLib\XML

* XML-related stuff that had nothing to do with Manialinks is now in ManiaLib\XML at https://github.com/maniaplanet/manialib-xml
* ManiaLib\Manialink now depends on it through composer requirements
* Node::setTagName() is renamed Node::setNodeName() (same for all "$tagName" related stuff).
* Both packages are now tagged v0.1.0 so you can now require "~0.1" in composer, and it should be easier from now on not to break compat...

If you're not using internal stuff you should be fine

I created a 0.1 branch and release on both projects, so that people using current version can still work with it.
"master" branch now is going to break compatibility, and will eventually become the 1.x branch.

We're using Symfony EventDispatcher and updating manialib-xml (and therefore manialib-manialink) to use it. As said above, it breaks compat with v0.x.

Branches for that feature:
https://github.com/maniaplanet/manialib ... dispatcher
https://github.com/maniaplanet/manialib ... dispatcher

They will be merged in master eventually.