[Webkit-unassigned] [Bug 91844] [WK2][GTK][EFL] Share WebKit2-GTK plugin process implementation with EFL port

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Sep 24 07:37:05 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=91844





--- Comment #54 from Simon Hausmann <hausmann at webkit.org>  2012-09-24 07:37:30 PST ---
(In reply to comment #49)
> (In reply to comment #48)
> > (In reply to comment #47)
> > > (In reply to comment #46)
> > > > (In reply to comment #45)
> > > > > (In reply to comment #35)
> > > > > > (From update of attachment 164363 [details] [details] [details] [details] [details] [details])
> > > > > > I'm not sure about some of the files, the implementation is the same because it's currently unimplemented, not because the implementation is expected to be common to all ports in a unix platform. PluginProcess/unix/PluginProcessMainUnix.cpp should probably be X11 instead of Unix, but it requires a lot of #ifdefs so I'm not sure whether it would be better to keep separate files without #ifdefs. Note also that Qt port could also share code common to unix platform, like in Platform/CoreIPC/unix/ConnectionUnix.cpp, but it seems to me that most of the files shared here are not for platform specific code, but for port specific code.
> > > > > 
> > > > > PluginProcessMainUnix seems to be more "unix" than "x11" because X11 support adds only error handling.
> > > > > Sometimes it's hard to point the best solution: port, backend, operating system.
> > > > > What's your suggestion?
> > > > 
> > > > My suggestion is to keep separate files instead of a "common" file full of #ifdefs
> > > 
> > > A lot of proposed changes have common source. I think PluginControllerProxyUnix.cpp, and PluginProcessUnix.cpp can be EFL and Gtk as before because of platform initialize, and destroy, but others may stay as is. Do you agree with it?
> > 
> > They have a common source because they are unimplemented not because they are supposed to have a common implementation for unix platform. 
> > The code is also the same as the Qt files, if we are going to share the unimplemented files, we should include the Qt files as well.
> 
> Because of:
> 1. Possible differences in unsupported functions
> 2. No good suffix for common files
> 3. For Unix suffix Qt source should be merged which implies a lot of macros
> I think that finally previous solution will be better.
> 
> Simon, do you agree with that?

I agree that there is not much value in calling a file with only notImplemented() files FooUnix.cpp, but splitting it up in *Efl and *Gtk.cpp doesn't make much sense to me neither. There could be a NotImplemented.cpp file like in WebCore, but you really have to ask yourself: What is the code going to look like in the future?

This is in a nutshell about implementing an X11 specific "standard", which for all means and purposes is tied to Unixy platforms.

For files like Source/WebKit2/UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp I really don't see a point in having the code duplicated between Efl and Gtk. (I won't r+ that, but maybe somebody else will)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list