Hi all, I would like to speak about granite…
I think it could be a good thing to define a few rules to avoid too much problems in the future, tell me what you think about them. - Avoid pushing directly in lp:granite for new features, I think it would be better if someone who implemented a new feature asked for merge, it will allow some review on the code. - Clearly define a coding style, it is not really important, but we should decide about that now. - Split the library in three libraries (and link them in a single one if we really want a single library) : core (logger, application…), draw (buffersurface), widgets (appmenu, modebutton). It will avoid wrong dependencies between the lib, it is better for a long term… - Ask and insist to get daily build of the documentation on valadocc.elementary.org :P I think we should also have more independents widget, the current AppMenu depends on Granite.Application, it is bad because we can't directly use the widgets in an other software, which doesn't use it… Let's imagine that we want to use AppMenu in Postler. But we don't want to use Granite.Application because it would require some work for nothing (since Postler doesn't use dconf ATM and has a more complicated structure). Currently, we can't just copy/use the file :( It's the same for marlin, for technical reasons (it is in C…), we don't want to use granite directly (to avoid a dependency too), but we can't just use the file from granite… it is quite annoying, and could be easily avoided :) Lucas -- Mailing list: https://launchpad.net/~elementary-dev-community Post to : [email protected] Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
