Re: GCancellable hints



Am Mon, 24 Aug 2009 18:14:11 +0200
schrieb Jannis Pohlmann <jannis xfce org>:

> 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.

I think you should go a step further to make this more than a generic
boolean, call it g_cancellable_get_unstoppable, and let
g_cancellable_cancel return_if_fail if you try to cancel something you
shouldn't cancel.

Incidentally a signal isn't needed, notify::stoppable is all you need.

ciao,
    Christian


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]