One question leads to another:
Where is the call to self.__progress_pulse_stop() corresponding to line 566?
It sounds like every call to pulse_stop coincides with an
unset_busy_cursor() so there must be a set_busy_cursor which is called
after line 566 so that __progress_pulse_stop is called.
Is it possible to tidy this up by moving __progress_pulse_start to after
set_busy_cursor is called for the first time?
Padraig
On 07/15/09 14:50, Michal Pryc wrote:
Padraig O'Briain wrote:
Just one more question.
You have added a call to self.__progress_pulse_stop() to
unset_busy_cursor().
Should the call to self.__progress_pulse_start() be inside
set_busy_cursor()?
Could be, but when PM is started and busy cursor is not yet there we
are showing pulsing progress:
566 + self.__progress_pulse_start()
Michal
Padraig
On 07/15/09 13:59, Michal Pryc wrote:
New webrev:
http://cr.opensolaris.org/~migi/progress_in_statusbar_15_Jul_v2/
Padraig O'Briain wrote:
The tooltip and accessible name of the progress_cancel button look
wrong.
Changed.
The dotted line or focus indicator that I reported seems to depend
on where focus was when Reload was pressed. If focus was in
category view I see dotted line around the category treeview.
You added call to
while gtk.events_pending()
gtk.main_iteration(False)
to _add_pkgs_to_lists.
I know that there are similar calls there already but I believe
that this is wrong as this code is not executed in the main thread
so will cause problem for accessibility.
Will time.sleep(0) work instead?
In the thread this loop was in two places, I did remove it and the
PM is working smooth on my virtualbox.
Lines 3496 and 3500 are both
self.__progress_pulse_stop()
Removed, as unset_busy_cursor is invoked and I have moved this _stop
to that function.
Is this necessary?
What is the relationship between self.set_busy_cursor() and
self.__progress_pulse_start()?
Are they always called together? If so, could the called to
self.__progress_pulse_start() be moved into set_busy_cursor()?
Moved it.
thanks
Michal
Padraig
On 07/15/09 10:41, Michal Pryc wrote:
Padraig,
New webrev:
http://cr.opensolaris.org/~migi/progress_in_statusbar_15_Jul_v1/
Comments inline.
Padraig O'Briain wrote:
Should similar changes be made for Update Manager and use of
progressdialog in beadm and reposit
Currently no, if we want to it's separate bug.
ory dialog.
I have noticed that when I press Reload there is a dotted line
(like a focus indicator) around the area where the package list
is displayed while the reload is happening. I do not see this if
I run package manager from t
I have tried this on build 118 and I don't see this behaviour. (I
couldn't reproduce this on 111b)
he gate.
What build of OpenSolaris are you using?
First I was using 111b, but this webrev is prepared using latest 118.
You remove lines 3 and 4 of packagemanager.glade which I believe
John added recently.
Most of the changes in packagemanager.glade seem to be like that:
i.e. undoing of changes John did recently which have nothing to
do with the the changes you made.
This makes it very difficult to review the changes. Can you make
these changes on build 117 so we do not have this problem?
I've just merged necessary glade changes, so now it should be
straigh forward.
packagemanager.py:
You removed some constants at the start of the file. Should the
comments at lines 26 to 33 be changed or removed?
Removed.
What is the purpose of __on_main_window_check_resize?
I did explain in the previous e-mail.
I ran pylint on packagemanager.py and it threw up some errors and
warnings. Can you fix these?
Fixed. Now it's 10.0/10.0.
best
Michal Pryc
On 07/13/09 16:47, Michal Pryc wrote:
Hi,
Over the phone Padraig told me that this webrev do not apply
cleanly to the gate.
Cleanly applying webrev:
http://cr.opensolaris.org/~migi/progress_in_statusbar_13_Jul_v1/
best
Michal
Michal Pryc wrote:
Hi,
Bug:
http://defect.opensolaris.org/bz/show_bug.cgi?id=6972
CR:
http://cr.opensolaris.org/~migi/progress_in_statusbar_13_Jul/
Currently instead of progress dialog the progress for
loading/refreshing catalog is in statusbar. The position of
this progress is still subject to change, but the logic will stay.
Also there is hidden cancel button. When the api will allow us
to use cancel for search, the user will be able to click on
this cancel button. That is why we need lines:
457-458 and related function in the packagemanager.py.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
