patch merged to master

Hi Cristiana,

Just had a look at the fix I suggested, and I don't think is very good :( Basically, the delay in opening the log is too short for a progress window. I am really sorry about this: I should have kept this in mind. 

Could we replace it with a 'busy-interactive pointer? They are explained here: 

http://developer.gnome.org/hig-book/3.5/feedback-types.html.en#pointer-feedback

The idea would be I can still interact with Hob while the log is being opened (e.g. maybe I want to open a bug or edit the image, and I can click on those options until the log file is ready for me to look at). 

Let me know if you think that would work. 

Thanks!

Hello Belen,

As it is implemented you can still interact with Hob while the log is opening. Also, on the dialog, there is a "Cancel" button( to cancel the process for opening the log). This feature helps you a lot when you have a big log file. I really think it is better with this dialog than a pointer.

Cristiana 

(In reply to comment #2)
> Hi Cristiana,
> 
> Just had a look at the fix I suggested, and I don't think is very good :(
> Basically, the delay in opening the log is too short for a progress window.
> I am really sorry about this: I should have kept this in mind. 
> 
> Could we replace it with a 'busy-interactive pointer? They are explained
> here: 
> 
> http://developer.gnome.org/hig-book/3.5/feedback-types.html.en#pointer-
> feedback
> 
> The idea would be I can still interact with Hob while the log is being
> opened (e.g. maybe I want to open a bug or edit the image, and I can click
> on those options until the log file is ready for me to look at). 
> 
> Let me know if you think that would work. 
> 
> Thanks!

Hi Cristiana,

I agree that the progress window is a good solution when opening the log file takes a long time. The problem is that, when the delay is very short, you just see a progress window flashing in front of your eyes and you don't really have time to process what's going on. It is particularly bad when you open a log file you already opened before, because in those cases the file opens almost immediately. 

Maybe we can do something about the above. For example,

- If you are opening a log file you already opened before, we don't display a progress window (we use an interactive pointer)

- We display an interactive pointer for 2 seconds. If the log file is not ready by then, we display the progress window for a minimum of 4 seconds (after those 4 seconds, if the file is ready, we open the log file and close the progress window at the same time).

By the way, the other thing I've noticed in my Hob instance is that the progress window disappears a couple of seconds before the log file opens, which is a bit strange (there is a 2 second pause when I don't know what's going on). Is there any way of closing the progress window only when the log file is coming up (and not before then)?

Hello Belen,
  I will reopen this bug, cause it seems we have to improve it more. But, related to the thing thet you've noticed that the
progress window disappears a couple of seconds before the log file opens, can you please give me more details about how you generated that log file? I don't think I saw this when I have tested it.

Thank you.


(In reply to comment #4)

> Hi Cristiana,
> 
> I agree that the progress window is a good solution when opening the log
> file takes a long time. The problem is that, when the delay is very short,
> you just see a progress window flashing in front of your eyes and you don't
> really have time to process what's going on. It is particularly bad when you
> open a log file you already opened before, because in those cases the file
> opens almost immediately. 
> 
> Maybe we can do something about the above. For example,
> 
> - If you are opening a log file you already opened before, we don't display
> a progress window (we use an interactive pointer)
> 
> - We display an interactive pointer for 2 seconds. If the log file is not
> ready by then, we display the progress window for a minimum of 4 seconds
> (after those 4 seconds, if the file is ready, we open the log file and close
> the progress window at the same time).
> 
> By the way, the other thing I've noticed in my Hob instance is that the
> progress window disappears a couple of seconds before the log file opens,
> which is a bit strange (there is a 2 second pause when I don't know what's
> going on). Is there any way of closing the progress window only when the log
> file is coming up (and not before then)?

Created attachment 928 [details]
open-log-delay.ogv

Hi Cristiana,

I've attached a video showing what happens when I click the 'Open log' button (open-log-delay.ogv). After I click the button, you get a fleeting view of the progress window, then there is a delay of about 2-3 seconds before the log file opens.

I hope this helps.

Belen

(In reply to comment #6)
> Created attachment 928 [details]
> open-log-delay.ogv

Hello Belen,

Can you please give me some information about your system/distribution? Do you run it within a virtual machine?

Thanks,
Cristiana

Nope: running Fedora 17 64-bit with Gnome 3.4.2 on a Lenovo ThinkPad T410

Is there any other info you need?

Cheers

Belen

(In reply to comment #8)
> Hello Belen,
> 
> Can you please give me some information about your system/distribution? Do
> you run it within a virtual machine?
> 
> Thanks,
> Cristiana

You can do better assuming that you can depend on GTK+ 2.14.  What are the minimum requirements?

Assuming you can require 2.14, then gtk.show_uri() should be just what you want (at the end of http://developer.gnome.org/pygtk/2.24/gtk-functions.html)

def show_uri(screen, uri, timestamp)

@screen would be the screen that the window is on (do .get_screen() on any convenient widget, such as the button or top-level window)

@uri is the URI you want to open - file:///some/path/to/the/log.txt

@timestamp is the timestamp of the event.  If you're reacting to user input you'll either have a timestamp in the event handler, or gtk.get_current_event_time() will extract the timestamp of the current event.

As the progress window disappears to quickly I'd change the cursor to a full busy cursor whilst whatever the progress bar was for happens, then switch back to a normal cursor (well, no cursor, so inherit the default) and use gtk.show_uri().  That will start up whatever the handler for a text file is (*should* be the same as xdg-open) and show a busy-in-background cursor whilst the application starts.

Thank you Ross! I have tried with this method but I receive the following error:
Traceback (most recent call last):
  File "/home/cvoicu/dev/poky/bitbake/lib/bb/ui/crumbs/imagedetailspage.py", line 410, in open_log_clicked_cb
    gtk.show_uri(None, log_file, gtk.gdk.CURRENT_TIME)
gio.Error: Operation not supported

I've searched this issue and this is what I've found:"you’re most likely missing gvfs, which contains the extension points for all non-file:// URI schemas.
... gvfs has to be installed in the same prefix as glib."

So I suppose that we can not use that. 

(In reply to comment #10)
> You can do better assuming that you can depend on GTK+ 2.14.  What are the
> minimum requirements?
> 
> Assuming you can require 2.14, then gtk.show_uri() should be just what you
> want (at the end of http://developer.gnome.org/pygtk/2.24/gtk-functions.html)
> 
> def show_uri(screen, uri, timestamp)
> 
> @screen would be the screen that the window is on (do .get_screen() on any
> convenient widget, such as the button or top-level window)
> 
> @uri is the URI you want to open - file:///some/path/to/the/log.txt
> 
> @timestamp is the timestamp of the event.  If you're reacting to user input
> you'll either have a timestamp in the event handler, or
> gtk.get_current_event_time() will extract the timestamp of the current event.
> 
> As the progress window disappears to quickly I'd change the cursor to a full
> busy cursor whilst whatever the progress bar was for happens, then switch
> back to a normal cursor (well, no cursor, so inherit the default) and use
> gtk.show_uri().  That will start up whatever the handler for a text file is
> (*should* be the same as xdg-open) and show a busy-in-background cursor
> whilst the application starts.

Well, you should have been using a file: URL, so that should have worked. Can you share the code that you used?

FWIW, from a python console, this works:

import pygtk; import gtk

w = gtk.Window()
w.show()
gtk.show_uri(screen=w.get_screen(), uri="file:///home/ross/test.txt", timestamp=0)

test.txt is opened in emacs, which is the editor I expected.

I forgot to add a "/". Now it works. Sorry and thank you!

(In reply to comment #13)
> FWIW, from a python console, this works:
> 
> import pygtk; import gtk
> 
> w = gtk.Window()
> w.show()
> gtk.show_uri(screen=w.get_screen(), uri="file:///home/ross/test.txt",
> timestamp=0)
> 
> test.txt is opened in emacs, which is the editor I expected.

Cristiana,

Can you update the comments about the issues that you still have?

Hello,

I'm stuck in implementing this issue, because I can't find a way to open a file and to know exactly the moment when it is opened. All calls I've found were asynchronously made.  It should be also independent of the distribution you are working on.

If anybody knows how to resolve this one, please fell free to comment.

Thank you,
Cristiana

You can't really know when it was opened - why do you want to know?

The intention is to add a progress bar/something else to indicate that a file is opening. I have to know when this process is finished in order to destroy the window with the progress bar/ to no show the loading pointer.

(In reply to comment #17)
> You can't really know when it was opened - why do you want to know?

Ah but that's where the magic comes in.  Don't show a busy cursor yourself, as gtk.show_uri() will automatically cause the busy cursor to appear and disappear when the loading has finished.

The assumption here is that the editor used support startup-notification, but if it doesn't then there is literally nothing you can do about it - you can never know when another process has actually displayed the document.

Thanks Ross! I didn't know that gtk.show_uri() cause the busy cursor. I think I've tested on small files. So I think I will implement this using this method, at least some users will see a busy cursor.

(In reply to comment #19)
> Ah but that's where the magic comes in.  Don't show a busy cursor yourself,
> as gtk.show_uri() will automatically cause the busy cursor to appear and
> disappear when the loading has finished.
> 
> The assumption here is that the editor used support startup-notification,
> but if it doesn't then there is literally nothing you can do about it - you
> can never know when another process has actually displayed the document.

I have sent for a review a patch that deletes the code for the first impelementation and uses gtk.show_uri() method which is showing a busy cursor. 
I gave up to implement a progress bar for this, because there is no way to know exactly when the opening process finishes.

merged to master. commit 4c1ebc7ca73f4ee069dc471a395073ba9a8ce00e

Verified on 8d6e55bf2192524bda84138b5356a2791adbbe61