Bug 11467 – patch to make the kde support optional in the Qt build

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[Simon Hausmann]

This patch makes the linkage against the kde libraries and the use of KDE classes optional for the Qt build.

[Simon Hausmann]

Created attachment 11297 [details]
patch to allow a qt-only build without kde dependencies

[Simon Hausmann]

Created attachment 11298 [details]
new patch to make compilation with kde optional

[Simon Hausmann]

Comment on attachment 11298 [details]
new patch to make compilation with kde optional

The difference to the previous patch are just adaptions to the coding style

[Enrico Ros]

I'm coming up with the network fetcher on Resource Hangle too. I'll add some patches soon. Plus, as we discussed with Nikolas, I'll make ResourceHanhleManagerQt and ResourceHandleManagerKDE, each to be linked with the right implementation.
Enrico Ros

[Maciej Stachowiak]

Comment on attachment 11298 [details]
new patch to make compilation with kde optional

r=me

Have you considered making a platform/kde directory and factoring some of this so that there can be kde and pure-qt versions of some things?

Also, I would suggest refactoring the qt port to not need ResourceHandleManager, the Qt and KDE versions of ResourceHandle could directly each handle an underlying platform loader. This is the direction things are moving in for the other ports. This is ok to land though.

[Simon Hausmann]

(In reply to comment #5)
> (From update of attachment 11298 [details] [edit])
> r=me
> 
> Have you considered making a platform/kde directory and factoring some of this
> so that there can be kde and pure-qt versions of some things?

Yes exactly, that is the plan for the future.

> Also, I would suggest refactoring the qt port to not need
> ResourceHandleManager, the Qt and KDE versions of ResourceHandle could directly
> each handle an underlying platform loader. This is the direction things are
> moving in for the other ports. This is ok to land though.
> 

Yes, that is definitely the next step, making the ResourceHandles a bit more intelligent themselves instead of delegating everything to the otherwise useless 'Manager'. For the Qt/KDE port we would probably end up letting ResourceHandleInternal inherit from QObject so we can bind it to signal/slot/timer based network backends.

Enrico, what's the status of your patch? Shall we see about getting mine in first as a start or are you already done anyway?

[Enrico Ros]

Land yours asap.
I'm merging the patches but since they involve QThread I'm debugging the whole stuff. (I didn't like to place all on gui's event loop). So the patch is quite finished, implementing Storage and Network/HTTP loading, but then I have to learn how to edit the changelog and make a 'standard' patch like yours.
So just go ahead, I'll try to get ready.
Btw: the buildsystem .pro/.pri, based on yours is debugged and up-to-date to head, but I can't make a patch since I don't know where to put these files and maybe the config.h.qmake. May I send you stuff so you can review and make a patch ?

[Simon Hausmann]

(In reply to comment #7)
> Land yours asap.
> I'm merging the patches but since they involve QThread I'm debugging the whole
> stuff. (I didn't like to place all on gui's event loop). So the patch is quite
> finished, implementing Storage and Network/HTTP loading, but then I have to
> learn how to edit the changelog and make a 'standard' patch like yours.
> So just go ahead, I'll try to get ready.

Okay.

> Btw: the buildsystem .pro/.pri, based on yours is debugged and up-to-date to
> head, but I can't make a patch since I don't know where to put these files and
> maybe the config.h.qmake. May I send you stuff so you can review and make a
> patch ?

Sure! I'd be happy to help with that.

[Anders Carlsson]

Committed revision 17553.