Hi All,
We are going to adopt a glib based open source library for one of the Tizen 3.0
features.
The open source core library is using plugin based architecture and we wish to
provide Tizen Native APIs to write plugins too.
However we are facing one conflict with current Tizen coding idiom standard in
order to achieve the same.
I will describe the situation below:
The plugin loader of the glib based core library has the following requirements
to load a plugin:
- The glib based library loads the plugin with <name>_get_type()
symbol. Note, name should be different for every plugin.
- It also requires G_DEFINE_TYPE_WITH_CODE glib specific macro to
define a custom type for each plugin.
In order to achieve this we are going to provide implementation like:
- Put all glib specific macros for GType definition inside one macro.
- And make it mandatory for Tizen Native plugin developers to put that
macro inside their shared object code.
But if we go by this approach, then we need to include glib (and the glib based
core lib) headers inside our Tizen Native
public header file (or in plugin code), which may conflict with the current
Tizen Native coding idioms.
As per current coding idiom guidelines, we should not include 3rd party library
headers in Tizen Native public header files
and instead put all the implementations (and 3rd party lib headers, if any)
inside private impl class.
So we would like to get suggestion regarding:
- Whether its okay to include glib and 3rd party lib headers inside Tizen
Native public header, since this is a special case
OR
- Is there any alternative way to achieve this (i.e. without including
glib and 3rd party core lib headers inside Tizen Native public headers?)
Thanks in advance for your help.
- Manasij
Samsung R&D Institute India, Bangalore
manasij.r AT samsung.com
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
