GModule are not usable.

[David Delassus]

GModule was a great idea. Every protocols were managed by a module (a dynamic library) which is loaded at runtime. It make Cream-Browser lighter an more customizable (you don't want the support of gopher, just don't load it).

But there is an inconvenient. Imagine, the module WebKit depend of libwekitgtk (a shared library too), now when you load this module, libwebkitgtk won't be loaded. The only solution I found is to link every dependencies to Cream-Browser, it's like activating the module support at build-time. You loose the interest of modules.

I decided to drop the module support. Now modules are selected at build-time (yeah I know :( ). However, you're still able to active them or not via the config file.

Sorry, one of the killer feature just disappear :(

[Custom Processing Unlimited]

I'm sure it can be implemented later on... For now, put it to the side, but there's no reason to think it can't ever be used in the future...

--
If "custom" was mass produced... it would just be a "product line."
Custom Processing Unlimited

[Elouan Pignet]

I can surf without this killer feature ;)

2011/6/23 Custom Processing Unlimited <cpu...@gmail.com>

--
You received this message because you are subscribed to the Google
Groups "cream-browser development" group.
To post to this group, send email to
cream-bro...@googlegroups.com
To unsubscribe from this group, send email to
cream-browser-d...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/cream-browser-devel?hl=en
 
http://cream-browser.net

[David Delassus]

It's done, the GModule support was replaced by a static modules support.

GObject proposes a very good way to implement interface. Now modules are just GObject which
implements this virtual class.

Here is the commit : http://bit.ly/j3bRxz

PS: The module webkit is done, Cream-Browser isn't usable yet but it's coming.