← Back to branch summary

~ubuntu-branches/ubuntu/vivid/aptitude/vivid

« back to all changes in this revision

Viewing changes to src/generic/controllers/README

  • Committer: Bazaar Package Importer
  • Author(s): Michael Vogt
  • Date: 2011-06-22 12:32:56 UTC
  • mfrom: (1.8.6 sid)
  • Revision ID: james.westby@ubuntu.com-20110622123256-8aox9w9ch3x72dci
Tags: 0.6.4-1ubuntu1
* Merge from debian unstable.  Remaining changes:
  - debian/05aptitude: never autoremove kernels
  - drop aptitude-doc to Suggests
  - 03_branding.dpatch: ubuntu branding
  - 04_changelog.dpatch: take changelogs from changelogs.ubuntu.com
  - 09_ubuntu_fortify_source.dpatch: Suppress a number of warnings (turned
    into errors by -Werror) triggered by Ubuntu's default of
    -D_FORTIFY_SOURCE=2.
  - 11_ubuntu_uses_sudo.dpatch: fix status line of 'Become root' menu entry
    to not refer to su.
  - 12_point_manpage_to_doc_package.dpatch: point Finnish manpage to the
    correct place for further info
  - 14_html2text_preferred.dpatch: switch back to html2text in favor of
    elinks, since html2text is in main and elinks isn't.
* dropped 01_intltool_update.dpatch
* updated 15_ftbfs_new_apt

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/generic/controllers/README
 
1
This directory contains "controllers".  These are non-GUI objects that
 
2
manage GUI objects by connecting to their signals and updating them as
 
3
appropriate.  Using controllers to manage GUI elements rather than
 
4
creating new widget types has several benefits:
 
5
 
 
6
  1) It allows logic that involves several collaborating widgets to be
 
7
     localized into a single code module.  e.g., the widgets involved
 
8
     in performing a package search might be in different parts of the
 
9
     GUI rather than in a single container, but a single controller
 
10
     can manage all of them.
 
11
 
 
12
  2) It can make it easier to reuse logic in a new context (due to 1).
 
13
 
 
14
  3) It can simplify some memory management considerations, by using
 
15
     classes whose lifetimes are detached from the lifetimes of the
 
16
     physical widgets they manage.
 
17
 
 
18
  4) If controllers don't interact explicitly with GUI objects, they
 
19
     can be unit-tested.  e.g., the controller could interact with the
 
20
     GUI via an abstract interface, and the unit test could provide an
 
21
     implementation of this interface that is entirely non-interactive.
 
22
 
 
23
This directory, being in the generic section of the aptitude source
 
24
code, should not contain references to any UI-level objects.
 
25
 
 
26
For at least some of aptitude's code, 4) will require refactoring,
 
27
which should be done opportunistically as usual.
 
28
 
 
29
Controllers might provide an interface to the outside world; if so,
 
30
they should declare that interface as an abstract class in their
 
31
header file, deriving from sigc::trackable.  This reduces compile-time
 
32
build dependencies and allows the controller to be mocked out for
 
33
testing.
 
34
 
 
35
Unlike views, controllers are implemented in this directory.  This is
 
36
because controllers are less likely to have multiple implementations,
 
37
and also because they won't contaminate the abstract interface file
 
38
with GUI dependencies (whereas view implementations by definition must
 
39
be constructed from GUI objects).