I checked with Michal and this works as expected with LargePrint themes.
This webrev looks good to me.
Padraig
On 07/20/09 15:33, Michal Pryc wrote:
Padraig,
Could you take a look at this webrev.
http://cr.opensolaris.org/~migi/6972_progress_in_statusbar_v3/
I have changed the progress to have minimum size set to 24. Otherwise
the progress would increase/decrease size of statusbar.
best
Michal
jmr wrote:
Michal looks good, one comment below:
JR
Michal Pryc wrote:
John,
I have made another webrev:
http://cr.opensolaris.org/~migi/progress_in_statusbar_17_jul/
Should use meaningful name in the glade file and PM not just hbox29:
350 + self.w_statusbar_hbox =
w_tree_main.get_widget("hbox29")
Changed to statusbar_hbox.
How do we cancel now?
1974 + def __on_progress_cancel_clicked(self, widget):
1975 + """ stub function for cancel operations """
1976 + return self
1977 +
Added logic to show/hide cancel button if the api is cancelable and
fire the cancel thread if it is. Currently it's not so the button
it's always hidden.
Ok - what about in the __progress_pulse() in the while loop shouldn't
you check if its become cancelable here? Move this into a func
__check_if_can_be_canceled() and call it where needed.
Should we check before that (count + 0.0)/total < 1.0 and > 0.0
3696 +
self.w_status_progressbar.set_fraction((count + 0.0)/total)
If it is greater then 1.0 (which should not happen) it will be 1.0
if less the 0.0 it will be 0.0.
Ok
Michal
JR
Padraig O'Briain wrote:
This looks good to me.
Padraig
On 07/15/09 16:33, Michal Pryc wrote:
Padraig O'Briain wrote:
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 fo
Padraig,
http://cr.opensolaris.org/~migi/progress_in_statusbar_15_Jul_v3/
I have moved few things around and now __progress_pulse_start is
called from set_busy_cursor and __progress_pulse_stop from
unset_busy_cursor.
best
Michal
r 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
