Jeremy Katz wrote:
On Sat, 2006-06-17 at 09:01 +0200, dragoran wrote:
1)Make them somehow threaded...
The gui sometime does not respond or even redraw when some "huge work"
is done in the background (even on a dual opteron box).Would spiltind
the gui from the backend stuff into seperate thread help? the gui can be
updated / rewdrawn while the other thread is doing the work.
It could "help", but there's a significant cost in code complexity and
difficulty in debugging things. I'm not fully convinced that it's worth
the cost especially as it becomes much less of an issue with a
compositing manager running.
how would a cm help here?
Really, it's better to try to get to where areas that take a long time
actually have a way of providing feedback of progress -- if you can
identify specific operations where things are taking a while and leading
to the UI not refreshing, please file them as separate bugs and I can
look into each case -- in most of them, I expect that there are ways to
resolve them that don't involve the complexity of threads
ok this seems to happen when pup is downloading from a slow mirror;
doing a ldconfig that takes long;
doing a restorecon after selinux-policy update etc.
will try to track them; provide more info an fill bugs.
2)Why does pirut close itself after it has done a task? for pup its ok
to be closed after it has completed updates but pirut? After installing
an app sometime I want to delete an other one or install a second one. I
know that I can select many tasks at once but I see no reason why pirut
should close it self.
There's a bug/rfe filed about this and I'm planning to get to it in the
FC6 cycle... just needed to get test1 out first.
ok good news; what about cd/dvd support? wasn't this planned as a fc5
update? (at least the wiki says so)
3)Pup should show more info on updates like description a "normal" user
may get confused by just seeing a name like hal, dbus or libXX. If pup
could somehow show a description of what this package are this would be
solved.
Work is underway to make all of the update information available to pup
(and even just yum) so that you can see what the purpose of the update
is, the severity, etc.
ok
Jeremy
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
