gDesklets

Merge lp://staging/~ballogy/gdesklets/optional-use-gconf-appindicator into lp://staging/gdesklets

optional-use-gconf-appindicator
Merge into 0.3x

Proposed by Balló György on 2012-03-04

Status:	Needs review
Proposed branch:	lp://staging/~ballogy/gdesklets/optional-use-gconf-appindicator
Merge into:	lp://staging/gdesklets
Diff against target:	98 lines (+24/-22) 3 files modified configure.ac (+0/-7) main/TrayIcon.py (+8/-5) shell/plugins/PackageInstaller/Downloader.py (+16/-10)
To merge this branch:	bzr merge lp://staging/~ballogy/gdesklets/optional-use-gconf-appindicator
Related bugs:	Link a bug report

Reviewer	Review Type	Date Requested	Status
gDesklets Core Team		2012-03-04	Pending
Review via email: mp+95809@code.staging.launchpad.net

Commit message

Use gconf and appindicator optionally

Description of the change

This change:

1. Makes it possible to use gdesklets without gconf. If gconf-python present on runtime, then gdekslets try to load proxy setting, otherwise not.

2. Instead of checking the availability of python-appindicator on build time, do it on runtime. In this case if python-appindicator installed later, then it's automatically used, otherwise the status icon shown. This patch is useful for distributions other than Ubuntu, where python-appindicator is not installed by default, but the user may installs it later.

Revision history for this message

Bjoern Koch (h.humpel) wrote on 2012-03-11:

First if all: sorry for the late reply... :/.

Anyway... to me this looks pretty good and (IMHO) we could merge these changes.
But I guess we will first have to discuss this on the ML.

Revision history for this message

Ronny Lorenz (raumzeit) wrote on 2012-03-13:

I dont mind merging those changes into gdesklets. The gconf modification
seems reasonable to me but maybe we should make the optional
appindicator stuff behave differently. With the currently proposed
changes the drawback will be that during compile time one can not decide
to never ever use appindicator at all. It will be loaded and used as
soon as its modules are available during runtime...
I dont know if this is what we intend to do? It would be nice to still
be able to deactivate appindicator by all means.

Just my 2cents

Ronny

On 03/11/2012 11:09 AM, Bjoern Koch wrote:
> First if all: sorry for the late reply... :/.
>
> Anyway... to me this looks pretty good and (IMHO) we could merge these changes.
> But I guess we will first have to discuss this on the ML.