On Mon, 24 Aug 2009 17:03:02 +0100
Richard Hughes <hughsient gmail com> wrote:
> In the last few weeks I subclassed GCancellable into a ZifCancellable
> object, which allowed me to complete a personal project. I now want to
> do the same for PackageKit, and think perhaps the functionality should
> be abstracted and pushed upstream into Glib as it's the second time
> I'm doing this. I'm asking for your opinions to see if it's the sort
> of thing you want in Glib.
>
> For me, a "task" can often do actions that cannot be cancelled for
> some time (when dealing with hardware and calling out to other
> programs), so for PackageKit, the install method:
>
> * depsolves (user can cancel)
> * downloads a package (user can cancel)
> * installs the package using rpm/apt/etc (user CANNOT cancel)
> * updates databases (user can cancel)
>
> And in the UI, we want to make the [Cancel] button insensitive for
> some of the actions rather that letting the user click it and wait for
> ages with no feedback.
>
> The only functionality that ZifCancellable adds is two methods:
>
> void zif_cancellable_set_hint (GCancellable *cancellable, gboolean
> can_cancel); gboolean zif_cancellable_get_hint (GCancellable
> *cancellable);
>
> And added the "hint-changed" signal
>
> void hint_changed_cb (GCancellable *cancellable, gboolean can_cancel,
> gpointer user_data)
>
> Better names welcome. Anyway, I would appreciate your opinions on this
> and if it would be accepted upstream.
Hm, I wonder if 'hint' isn't a too generic name for this. Maybe
something like 'active' and g_cancellable_{get,set}_active() would be
better. However, I wonder if you couldn't simply use the newly added
g_cancellable_{connect,disconnect}() methods for this. Make
the UI element(s) insensitive, disconnect the job from the GCancellable
and when you want the task to become cancellable again, reverse this.
What you did with ZifCancellable clearly is more convenient though, I'd
agree with that.
- Jannis
Attachment:
signature.asc
Description: PGP signature