Re: Status for long-running operation
- From: Jeffrey Barish <jeff_barish earthlink net>
- To: gtk-list gnome org
- Subject: Re: Status for long-running operation
- Date: Fri, 17 Sep 2010 19:01:34 -0600
Lex Trotman wrote:
> On 18 September 2010 08:22, Jeffrey Barish <jeff_barish earthlink net>
> wrote:
>> Jeffrey Barish wrote:
>>
>>> My application has one operation that runs for a long time (~1 minute).
>>> During this time, the user is not allowed to do anything. Nevertheless,
>>> I felt that it was important to give the user some feedback that the
>>> application is still alive and that the operation is running. My
>>> solution was to print a message in a TextBuffer and follow the message
>>> with a string
>>> of dots that grows in length by one every second. To get the TextView
>>> to update, I used events_pending/main_iteration. This all works nicely.
>>> However, because of the events_pending/main_iteration statements, the
>>> entire
>>> GUI is now alive. Thus, the user is able to do things that disrupt the
>>> long-running operation. Basically, what I want is a way to get the
>>> TextView to update so that I can update the progress indicator but for
>>> everything
>>> else still to be locked out. Is there a way to do this?
>>
>> Here's a possibility that seems to work:
>>
>> I used event_handler_set to define an event handler that filters out all
>> events (by not calling main_do_event) except EXPOSE while the
>> long-running operation is underway. I wish that there were a way to
>> restore the default event handler, but there is only a set method.
>> Anything bad about this solution?
>> --
>> Jeffrey Barish
>
> You should show progress and block the application by showing a modal
> dialog containing a progress bar.
>
> Cheers
> Lex
Good point. The TextView is where I put all messages, so I didn't want to
put the progress indicator in a different place, if I could avoid it.
My solution still seems to be working, but I worry about having all events
go through my filter all the time because it seems a bit inefficient.
--
Jeffrey Barish
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]