Bug 150087 – [GTK] Fix build for ENABLE_FULLSCREEN_API=OFF

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Sergio Villar Senin]

[GTK] Fix build for ENABLE_FULLSCREEN_API=OFF

[Sergio Villar Senin]

Created attachment 262984 [details]
Patch

[WebKit Commit Bot]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

[Carlos Garcia Campos]

Why do we allow to build with fullscreen API disabled? Does it have any external dependency? or is it unstable or experimental feature?

[Sergio Villar Senin]

(In reply to comment #3)
> Why do we allow to build with fullscreen API disabled? Does it have any
> external dependency? or is it unstable or experimental feature?

No idea, but in any case that's a project decision, isn't it?

[Darin Adler]

My view is that not every platform needs to support all ENABLE flags on and off. A feature can be “required always on” for a particular platform even before we remove the ability to turn it off entirely. And it would be OK to do that for GTK if the folks working on that platform prefer to do that.

[Martin Robinson]

I think in the case of GTK+ it only makes sense to ensure that things build with combinations of the public CMake flags. Complicated permutations of the private ones can quickly grow out of hand and make the project harder to maintain. At least, that is what I believe we were aiming for when we made some private and some public.

[Michael Catanzaro]

(In reply to comment #6)
> I think in the case of GTK+ it only makes sense to ensure that things build
> with combinations of the public CMake flags. Complicated permutations of the
> private ones can quickly grow out of hand and make the project harder to
> maintain. At least, that is what I believe we were aiming for when we made
> some private and some public.

Yes, that's half the intent behind the public/private option split: so that we have a much smaller subset of compilation options to support. (The other advantage is that the user has far fewer options to think about.) It would be good for other ports to adopt this strategy as well.

(In reply to comment #4)
> (In reply to comment #3)
> > Why do we allow to build with fullscreen API disabled? Does it have any
> > external dependency? or is it unstable or experimental feature?
> 
> No idea, but in any case that's a project decision, isn't it?

I can't think of any reason to disable this feature. Even if you don't imagine your users entering fullscreen mode, what is the harm of compiling it in? If there is some good justification to have it disabled (besides to avoid compiling a couple files), then maybe it should be a public option.

[Michael Catanzaro]

Comment on attachment 262984 [details]
Patch

If we're going to add #ifdefs to allow turning off ENABLE_FULLSCREEN_API, then we should make the option public. But we should only make it public if there's a very strong reason to allow turning it off. We have enough build options already.

[Sergio Villar Senin]

Let's close this.