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. 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 > 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. > 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. Jeremy -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
