Bug 99447 – [GTK] Guard GTK specific members in GeolocationProviderGeoclue class for the common use.

• Status: NEW
• Component: WebKitGTK

[Byungwoo Lee]

Currently, GeolocationProviderGeoclue class implemented with gtk-oriented features.

But Geoclue provides dbus API, so some other port can also implement the class.

For the common use, it is better to hide GTK-oriented implementations in the class.

[Byungwoo Lee]

Created attachment 174355 [details]
Patch

[Dominik Röttsches (drott)]

Would it make sense to generalize the implementation altogether, just use dbus, and remove the GTK/glib-wrapped implementation? (CC'ed some GTK people.)

[Byungwoo Lee]

(In reply to comment #2)
> Would it make sense to generalize the implementation altogether, just use dbus, and remove the GTK/glib-wrapped implementation? (CC'ed some GTK people.)

As my understanding, GeoClue already provides GTK API, and it uses GDBus.
If some more generalization is needed, wrapper for the GTK geoclue objects(e.g. GeoclueMaster, GeoclueClient, GeocluePosition etc) seems to be needed.

Is there anyone who can give the clear point about this?

[Dominik Röttsches (drott)]

(In reply to comment #3)
> (In reply to comment #2)
> > Would it make sense to generalize the implementation altogether, just use dbus, and remove the GTK/glib-wrapped implementation? (CC'ed some GTK people.)
> 
> As my understanding, GeoClue already provides GTK API, and it uses GDBus.
> If some more generalization is needed, wrapper for the GTK geoclue objects(e.g. GeoclueMaster, GeoclueClient, GeocluePosition etc) seems to be needed.
> 
> Is there anyone who can give the clear point about this?

I assumed you were planning to upstream/implement a generalized implementation based directly on DBus, not on the GTK API. Is that what you were planning to do?

If so, then we could perhaps phase-out the GTK specific implementation at some point. That was my suggestion.

[Byungwoo Lee]

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Would it make sense to generalize the implementation altogether, just use dbus, and remove the GTK/glib-wrapped implementation? (CC'ed some GTK people.)
> > 
> > As my understanding, GeoClue already provides GTK API, and it uses GDBus.
> > If some more generalization is needed, wrapper for the GTK geoclue objects(e.g. GeoclueMaster, GeoclueClient, GeocluePosition etc) seems to be needed.
> > 
> > Is there anyone who can give the clear point about this?
> 
> I assumed you were planning to upstream/implement a generalized implementation based directly on DBus, not on the GTK API. Is that what you were planning to do?
Yes, sure!

> 
> If so, then we could perhaps phase-out the GTK specific implementation at some point. That was my suggestion.
Yes I understood.
As you already know, e_dbus doesn't provide geoclue feature yet.

So I planned to support geolocation feature as below.
1. make some e_dbus wrapper to use e_dbus.
2. make geoclue object (GeoclueMaster...) with the e_dbus wrapper.
3. implement GeolocationProviderGeoclue class with the geoclue object.

I think you mentioned about the #2. (is it?)

If it is acceptable on GTK side, I also think your suggestion is better :)

[Dominik Röttsches (drott)]

(In reply to comment #5)
> 
> > If so, then we could perhaps phase-out the GTK specific implementation at some point. That was my suggestion.
> Yes I understood.
> As you already know, e_dbus doesn't provide geoclue feature yet.
> 
> So I planned to support geolocation feature as below.
> 1. make some e_dbus wrapper to use e_dbus.
> 2. make geoclue object (GeoclueMaster...) with the e_dbus wrapper.
> 3. implement GeolocationProviderGeoclue class with the geoclue object.
> 
> I think you mentioned about the #2. (is it?)

Well, I actually mean: If you use e_dbus and gtk is using gtk-dbus - wouldn't it make sense to just use dbus without any framework specific wrappers and share the implementation? What do you think?

Otherwise, yes, at least the WebKit-side GoeClue objects should be shared and based on the respective e_dbus or gtk-dbus wrappers.

> If it is acceptable on GTK side, I also think your suggestion is better :)

Any opinions on this from the GTK side?

[Byungwoo Lee]

(In reply to comment #6)
> Well, I actually mean: If you use e_dbus and gtk is using gtk-dbus - wouldn't it make sense to just use dbus without any framework specific wrappers and share the implementation? What do you think?

I'm not sure that this need to be re-implemented on GTK side, because geoclue already provide GTK wrapper.
I'm not a GTK port developer, so I need some opinion of GTK developers about this :)

[Martin Robinson]

Comment on attachment 174355 [details]
Patch

I'm not sure this patch makes sense. GeolocationProviderGeoclue is a geoclue implementation of a geolocation provider. Geoclue is a library that depends on using GLib. There's nothing specific to GTK+ in this file that I can see. If you want to make a geolocation provider that doesn't use Geoclue (and by exetension GLib), then you should make an entirely new provider.

I'm also curious about the direction this is moving. Is the EFL port trying to remove all GLib dependencies? That would require switching to the cURL networking back-end, for instance.

[Byungwoo Lee]

(In reply to comment #8)
> (From update of attachment 174355 [details])
> I'm not sure this patch makes sense. GeolocationProviderGeoclue is a geoclue implementation of a geolocation provider. Geoclue is a library that depends on using GLib. There's nothing specific to GTK+ in this file that I can see. If you want to make a geolocation provider that doesn't use Geoclue (and by exetension GLib), then you should make an entirely new provider.

Ok, the comment makes some confusion. 'to remove glib dependency' is the purpose of this patch.
geoclue also provides the DBus API, and EFL have e_dbus module.
So EFL seems to be able to use geoclue without glib dependency.

> 
> I'm also curious about the direction this is moving. Is the EFL port trying to remove all GLib dependencies? That would require switching to the cURL networking back-end, for instance.

As my understanding, 'do not make glib dependency if possible' is the EFL guide. And I heard that there was a discussion about using geoclue glib library, and the conclusion was not using the glib library because geoclue has DBus API.

Please let me know if I have some misunderstanding.

[Martin Robinson]

(In reply to comment #9)

> As my understanding, 'do not make glib dependency if possible' is the EFL guide. And I heard that there was a discussion about using geoclue glib library, and the conclusion was not using the glib library because geoclue has DBus API.
> 
> Please let me know if I have some misunderstanding.


For me, the stability of the C API is more reassuring than that of the DBus API. I'd rather have this code in another file.

I'm still curious what your plans with libsoup are. Are you going to switch to the cURL backend?

[Byungwoo Lee]

(In reply to comment #10)
> For me, the stability of the C API is more reassuring than that of the DBus API. I'd rather have this code in another file.

Yes C API looks more popular than dbus API. (Actually it is very hard to find the document or reference for the dbus API)
Do you think using current class is better if EFL want to use geoclue?
How about your opinion dominik and other EFL guys?

> 
> I'm still curious what your plans with libsoup are. Are you going to switch to the cURL backend?

I don't have any plan about libsoup now. Is it weird to you that trying not to use geoclue glib API but still using libsoup?

[Martin Robinson]

(In reply to comment #11)

> I don't have any plan about libsoup now. Is it weird to you that trying not to use geoclue glib API but still using libsoup?

Indeed, if you plan to eliminate dependencies on GLib you have a lot of work to do.

[Byungwoo Lee]

(In reply to comment #12)
> Indeed, if you plan to eliminate dependencies on GLib you have a lot of work to do.

For the clarification, I haven't consider about 'removing entire GLib dependency from EFL port' in this patch.
As you said, 'removing all GLib dependancy from EFL port' is very big thing.
Sorry for the confusion if you got such point from my comment :)
(I just planned to use geoclue without glib dependency on EFL port.)