| /pdk/apps/TestingCamera2/ |
| README.txt | 20 panes are grouped in lists by category, and can be added, removed, or collapsed from view
23 The left pane contains target panes along with the app's overall log pane. The right pane contains
24 camera, request, burst, and utility panes.
39 2.1. Camera panes
46 2.2. Target panes
48 Target panes represent various destinations for camera data. The kind of destination desired, and
76 2.3. Request panes
78 Request panes are used to set up the configuration for a single camera capture request. It includes
80 for the camera to send the request to, and then which of the configured target panes to use for
101 2.4. Burst panes
[all...] |
| /pdk/apps/TestingCamera2/src/com/android/testingcamera2/ |
| PaneTracker.java | 28 * Tracks currently-available panes of various kinds, for other panes to find targets/etc.
37 * Various events panes might alert other panes about
89 * Notify all panes that the UI orientation has changed
108 * Interface for clients to listen to additions and removals of panes
|
| PaneLayout.java | 37 * A simple linear layout to hold a set of control panes, with the ability to
38 * add more panes, and to serialize itself in/out of configurations.
59 // Unhide all panes
65 // Hide all panes
|
| /frameworks/base/docs/html/training/design-navigation/ |
| multiple-sizes.jd | 51 <p>Larger screens such as those found on tablets and TVs, on the other hand, generally have much more available screen space and are able to present multiple panes of content. In landscape, panes are usually ordered from left to right in increasing detail order. Users are especially accustomed to multiple panes on larger screens from years and years of desktop application and desktop web site use. Many desktop applications and websites offer a left-hand navigation pane or use a master/detail two-pane layout.</p>
53 <p>In addition to addressing these user expectations, it's usually necessary to provide multiple panes of information on tablets to avoid leaving too much whitespace or unwittingly introducing awkward interactions, for example 10 x 0.5-inch buttons.</p>
70 <p class="note"><strong>Implementation Note:</strong> After deciding on the screen size at which to draw the line between single-pane and multi-pane layouts, you can provide different layouts containing one or multiple panes for devices in varying screen size buckets (such as <code>large</code>/<code>xlarge</code>) or varying minimum screen widths (such as <code>sw600dp</code>).</p>
72 <p class="note"><strong>Implementation Note:</strong> While a single screen is implemented as an {@link android.app.Activity} subclass, individual content panes can be implemented as {@link android.app.Fragment} subclasses. This maximizes code re-use across different form factors and across screens that share content.</p>
85 <p>The most straightforward strategy is to simply stretch each pane's width to best present the content in each pane in the portrait orientation. Panes could have fixed widths or take a certain percentage of the available screen width.</p></li>
90 <p>A variation on the stretch strategy is to collapse the contents of the left pane when in portrait. This works quite well with master/detail panes where the left (master) pane contains easily collapsible list items. An example would be for a realtime chat application. In landscape, the left list could contain chat contact photos, names, and online statuses. In portrait, horizontal space could be collapsed by hiding contact names and only showing photos and online status indicator icons. Optionally also provide an expand control that allows the user to expand the left pane content to its larger width and vice versa.</p></li>
100 <p>The last strategy is to vertically stack your normally horizontally-arranged panes in portrait. This strategy works well when your panes aren't simple text-based lists, or when there are multiple blocks of content running along the pri (…)
[all...] |
| /external/lldb/utils/vim-lldb/python-vim-lldb/ |
| vim_panes.py | 2 # This file contains implementations of the LLDB display panes in VIM
33 # FIXME: define interface for interactive panes, like catching enter
136 self.panes = {}
140 return name in self.panes
142 def prepare(self, panes = []):
143 """ Draw panes on screen. If empty list is provided, show all. """
150 for name in self.panes:
151 if name in panes or len(panes) == 0:
157 self.panes[name].prepare(
[all...] |
| vim_ui.py | 20 # Default panes to display
30 # Container for panes
33 # All possible LLDB panes
42 """ Activate UI: display default set of panes """
|
| /development/samples/Support4Demos/src/com/example/android/supportv4/widget/ |
| SlidingPaneLayoutActivity.java | 44 * can then access both panes by physically sliding the content pane into view or out of the way
45 * or implicitly by moving focus between the two panes. This can greatly simplify development
51 * should open the panes, revealing the left pane for normal interaction. From this open state
53 * both panes were fully visible in the activity window and navigate to the activity one level up
59 * sliding utility drawers for extended navigation options and actions, the panes of a
61 * both panes to be visible all the time on a sufficiently wide screen, DrawerLayout and its
|
| /packages/apps/UnifiedEmail/src/com/android/mail/ui/ |
| TwoPaneLayout.java | 87 * panes to switch between.
248 // all panes start GONE in initial UNKNOWN mode to avoid drawing misplaced panes
304 * Sizes up the three sliding panes. This method will ensure that the LayoutParams of the panes
321 * @param width the available width to layout the children panes
354 * Translate the panes to their ending positions, can choose to either animate the translation
356 * @param deltaX The ending translationX to translate all of the panes except for drawer.
358 * because in landscape mode the drawer doesn't actually move and rest of the panes simply
373 * Animate the panes' translationX to their corresponding deltas. Refer t
[all...] |
| /development/samples/training/ContactsList/res/layout/ |
| activity_main_twopanes.xml | 18 <!-- Main Activity two-pane layout. This layout has two panes, a ContactsListFragment on the left
|
| /device/generic/goldfish/camera/ |
| EmulatedFakeCameraDevice.h | 139 * Precalculated values related to U/V panes.
151 /* Defines number of Us and Vs in a row inside the U/V panes.
152 * Note that if U/V panes are interleaved, this value reflects the total
|
| EmulatedFakeCameraDevice.cpp | 124 /* Calculate U/V panes inside the framebuffer. */
161 /* Number of items in a single row inside U/V panes. */
351 /* Fill U, and V panes. */
388 /* Offset of the current row inside U/V panes. */
390 /* Fill U, and V panes. */
|
| JpegCompressor.h | 84 /* Strides for Y (the first element), and UV (the second one) panes. */
|
| Converters.cpp | 116 * y, u, and v point to Y,U, and V panes, where U and V values are interleaved.
129 * y, u, and v point to Y,U, and V panes, where U and V values are interleaved.
|
| /frameworks/base/docs/html/tools/performance/hierarchy-viewer/ |
| index.jd | 173 <li>If not already open, the Hierarchy View panes open.<br>
174 The example screen in Figure 4 shows an example of these panes.</li>
211 <li>Double-click your application in the Windows tab. This populates the panes with the
216 <li>You can adjust the sizes of the panes and ADM will preserve your
231 <strong>Figure 7. </strong>Hierarchy Viewer panes.
239 <li>The rest of the panes:
|
| /packages/apps/Calendar/res/values/ |
| config.xml | 35 <!-- A global var used to set the main layout theme (one pane vs multiple panes) -->
|
| /packages/apps/Calendar/res/values-w600dp-h879dp/ |
| config.xml | 35 <!-- A global var used to set the main layout theme (one pane vs multiple panes) -->
|
| /packages/apps/Calendar/res/values-w960dp-h527dp/ |
| config.xml | 35 <!-- A global var used to set the main layout theme (one pane vs multiple panes) -->
|
| /development/samples/training/ContactsList/src/com/example/android/contactslist/ui/ |
| ContactsListActivity.java | 31 * can fit two panes also load {@link ContactDetailFragment}.
41 // If true, this is a larger screen device which fits two panes
|
| /development/samples/Support4Demos/res/values/ |
| strings.xml | 174 <string name="sliding_pane_layout_summary">This activity illustrates the use of sliding panes. The content pane may be slid to one side on narrow devices to reveal the left pane used to select content. Sliding panes can be used to fit a UI intended for wider screens in a smaller space. Tapping the Action Bar\'s Up button at the left side of the bar will navigate up in the hierarchy, represented by the left pane. If you rotate the device to landscape mode, on most devices you will see that both panes fit together side by side with no sliding necessary.</string>
|
| /development/samples/Support7Demos/res/values/ |
| strings.xml | 122 <string name="sliding_pane_layout_summary">This activity illustrates the use of sliding panes.
124 select content. Sliding panes can be used to fit a UI intended for wider screens in a
127 mode, on most devices you will see that both panes fit together side by side with no sliding
|
| /external/lldb/utils/vim-lldb/doc/ |
| lldb.txt | 22 there are also commands to display or hide informational debugger panes.
|
| /frameworks/base/docs/html/tools/debugging/ |
| debugging-ui.jd | 131 You should see four panes:
363 In it, you see three panes:
439 The panes are not automatically refreshed when you change one of the View objects or go to
441 <strong>Refresh Screenshot</strong> at the top of the window. This will change the panes
446 To automatically refresh the panes while you are debugging, set
|
| /prebuilts/python/darwin-x86/2.7.5/lib/python2.7/lib-tk/test/test_ttk/ |
| test_widgets.py | 376 self.assertEqual(self.paned.panes(), (str(child), str(child2)))
379 self.assertEqual(self.paned.panes(), (str(child2), str(child)))
382 self.assertEqual(self.paned.panes(),
386 panes = self.paned.panes()
388 self.assertEqual(panes, self.paned.panes())
394 self.assertEqual(self.paned.panes(),
[all...] |
| /prebuilts/python/linux-x86/2.7.5/lib/python2.7/lib-tk/test/test_ttk/ |
| test_widgets.py | 376 self.assertEqual(self.paned.panes(), (str(child), str(child2)))
379 self.assertEqual(self.paned.panes(), (str(child2), str(child)))
382 self.assertEqual(self.paned.panes(),
386 panes = self.paned.panes()
388 self.assertEqual(panes, self.paned.panes())
394 self.assertEqual(self.paned.panes(),
[all...] |
| /frameworks/base/docs/html/training/implementing-navigation/ |
| descendant.jd | 47 <p>Handset touchscreens are most suitable for displaying one screen at a time (either the master or the detail screen); this concern is further discussed in <a href="{@docRoot}training/design-navigation/multiple-sizes.html">Planning for Multiple Touchscreen Sizes</a>. Descendant navigation in this case is often implemented using an {@link android.content.Intent} that starts an activity representing the detail screen. On the other hand, tablet displays, especially when viewed in the landscape orientation, are best suited for showing multiple content panes at a time: the master on the left, and the detail to the right). Here, descendant navigation is usually implemented using a {@link android.app.FragmentTransaction} that adds, removes, or replaces the detail pane with new content.</p>
|
