diff options
author | Daniel Burrows <dburrows@debian.org> | 2008-10-29 09:16:17 -0700 |
---|---|---|
committer | Daniel Burrows <dburrows@debian.org> | 2008-10-29 09:16:17 -0700 |
commit | cf760f50bf8963da7c35a061ba3b2a162c0fe2cd (patch) | |
tree | 27961cebaa3f14caf7356bd168f6ecc6fbe18909 /src/cmdline/cmdline_util.cc | |
parent | 0a17acce0bf192c2b7ece3b5f74b474aaa187b3e (diff) | |
download | aptitude-cf760f50bf8963da7c35a061ba3b2a162c0fe2cd.tar.gz |
Massive refactoring and redesign to properly support background downloads in the GUI and running dpkg in a terminal.
This should probably have been split into a lot of smaller commits, but
it's too late now.
The GUI now runs downloads in a background thread, just like the curses
interface. In fact, it is *just* like the curses interface: the code of
ui_download_manager and download_thread has been parameterized so that it
can be used from either the curses frontend or the GUI frontend. These
files should eventually migrate to the generic directory. Some of the
parameterization left ugly stuff behind, like refcounted_progress and the
wacky redesign of the curses progress class (which took place solely so
that it could be unified with the GTK+ one). It may be worth taking some
time to clean this code up.
In addition, the code for download_install_manager has been refactored
again. Instead of exposing the different parts of "finish", which would
eliminate any hope of having a unified ui_download_manager harness, the
"finish" method (for all download managers) is now explicitly continuation
based, and the install manager uses this feature to break up the download.
The function that runs dpkg in a terminal now takes a continuation to be
invoked in the main thread, so it can fork dpkg in a subprocess, and then
call the continuation when the subprocess terminates. This means we don't
need to mess around with threads at all in the dpkg-terminal-creation
process, a huge relief. It also fits in with the generally continuation-y
feel of a lot of the aptitude code, and everyone loves continuations in
their GUI programs anyway!
Note: in this commit, I've adopted a policy of always returning right
after I invoke the continuation, to make it clear in the code what's
going on and to minimize the chances of a future edit screwing this up.
(if I really wanted to get serious about that, of course, I would write
an INVOKE_CONTINUATION macro...)
A few other minor things were touched up here: for instance, the program
no longer enters an infinite loop after running dpkg, and more download
events are logged. There's still more work to do around the edges:
changelog downloading from the GUI is broken, and the download status
tab is all messed up. Also, I'd like to support the status pipe from
dpkg (but I think that's a post-0.5 thing).
Diffstat (limited to 'src/cmdline/cmdline_util.cc')
-rw-r--r-- | src/cmdline/cmdline_util.cc | 15 |
1 files changed, 13 insertions, 2 deletions
diff --git a/src/cmdline/cmdline_util.cc b/src/cmdline/cmdline_util.cc index 30a78875..d4e8cd7d 100644 --- a/src/cmdline/cmdline_util.cc +++ b/src/cmdline/cmdline_util.cc @@ -75,7 +75,7 @@ void ui_solution_screen() file_quit.connect(sigc::ptr_fun(cwidget::toplevel::exitmain)); progress_ref p = gen_progress_bar(); - do_new_package_view(*p.unsafe_get_ref()); + do_new_package_view(*p->get_progress().unsafe_get_ref()); do_examine_solution(); ui_main(); @@ -371,6 +371,15 @@ namespace } } +namespace +{ + template<typename T> + void assign(const T &val, T *target) + { + *target = val; + } +} + download_manager::result cmdline_do_download(download_manager *m, int verbose) { @@ -403,7 +412,9 @@ download_manager::result cmdline_do_download(download_manager *m, do { pkgAcquire::RunResult download_res = m->do_download(); - finish_res = m->finish(download_res, progress); + m->finish(download_res, &progress, + sigc::bind(sigc::ptr_fun(&assign<download_manager::result>), + &finish_res)); } while(finish_res == download_manager::do_again); |