elementary-dev-community team mailing list archive

[xapantu <xapantu@xxxxxxxxx>]

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