Home	Sort by relevance Sort by last modified time

Full Search Definition Symbol File Path History   | | Help

    Searched full:screens (Results 26 - 50 of 768) sorted by null

12 3 4 5 6 7 8 91011>>

/external/chromium_org/chrome/browser/chromeos/login/screens/
mock_screen_observer.h	10 #include "chrome/browser/chromeos/login/screens/screen_observer.h" 16 // screens.
reset_screen.h	12 #include "chrome/browser/chromeos/login/screens/reset_screen_actor.h" 13 #include "chrome/browser/chromeos/login/screens/wizard_screen.h"
wrong_hwid_screen.h	12 #include "chrome/browser/chromeos/login/screens/wizard_screen.h" 13 #include "chrome/browser/chromeos/login/screens/wrong_hwid_screen_actor.h"
gaia_screen.cc	5 #include "chrome/browser/chromeos/login/screens/gaia_screen.h"
mock_error_screen.cc	5 #include "chrome/browser/chromeos/login/screens/mock_error_screen.h"
mock_update_screen.h	8 #include "chrome/browser/chromeos/login/screens/screen_observer.h" 9 #include "chrome/browser/chromeos/login/screens/update_screen.h" 10 #include "chrome/browser/chromeos/login/screens/update_screen_actor.h"
controller_pairing_screen.h	10 #include "chrome/browser/chromeos/login/screens/controller_pairing_screen_actor.h" 11 #include "chrome/browser/chromeos/login/screens/screen_context.h" 12 #include "chrome/browser/chromeos/login/screens/wizard_screen.h"
host_pairing_screen.h	9 #include "chrome/browser/chromeos/login/screens/host_pairing_screen_actor.h" 10 #include "chrome/browser/chromeos/login/screens/screen_context.h" 11 #include "chrome/browser/chromeos/login/screens/wizard_screen.h"
mock_eula_screen.cc	5 #include "chrome/browser/chromeos/login/screens/mock_eula_screen.h"
mock_network_screen.cc	5 #include "chrome/browser/chromeos/login/screens/mock_network_screen.h"
/external/chromium_org/content/public/test/
content_browser_test_utils_mac.mm	16 if ([[NSScreen screens] count] > 0) { 18 [[[NSScreen screens] objectAtIndex:0] frame].size.height -
/frameworks/base/docs/html/training/basics/supporting-devices/
index.jd	2 page.tags=layouts,resources,screens,localization 20 <li><a href="{@docRoot}training/multiscreen/index.html">Designing for Multiple Screens</a></li> 42 <dt><b><a href="screens.html">Supporting Different Screens</a></b></dt>
/external/chromium_org/third_party/webrtc/modules/desktop_capture/win/
screen_capture_utils.h	18 // Output the list of active screens into |screens|. Returns true if succeeded, 20 bool GetScreenList(ScreenCapturer::ScreenList* screens);
/frameworks/base/docs/html/training/design-navigation/
multiple-sizes.jd	6 previous.title=Planning Screens and Their Relationships 11 meta.tags="multiple screens" 22 <li><a href="#multi-pane-layouts">Group Screens with Multi-pane Layouts</a></li> 24 <li><a href="#group-screens">Group Screens in the Screen Map</a></li> 30 <li><a href="{@docRoot}training/multiscreen/index.html">Designing for Multiple Screens</a></li> 37 <p>The exhaustive screen map from the previous lesson isn't tied to a particular device form factor, although it can generally look and work okay on a handset or similar-size device. But Android applications need to adapt to a number of different types of devices, from 3" handsets to 10" tablets to 42" TVs. In this lesson we explore reasons and tactics for grouping together multiple screens from the exhaustive map.</p> 41 <h2 id="multi-pane-layouts">Group Screens with Multi-pane Layouts</h2> 49 <p>3 to 4-inch screens are generally only suitable for showing a single vertical pane of content at a time, be it a list of items, or detail information about an item, etc. Thus on such devices, screens generally map one-to-one with levels in the information hierarchy (<em>categories</em> &rarr; <em> (…)     [all...]
descendant-lateral.jd	37 <p>One way of providing access to the full range of an application's screens is to expose hierarchical navigation. In this lesson we discuss <em>descendant navigation</em>, allowing users to descend 'down' a screen hierarchy into a child screen, and <em>lateral navigation</em>, allowing users to access sibling screens.</p> 46 <p>There are two types of sibling screens: collection-related and section-related screens. <em>Collection-related</em> screens represent individual items in the collection represented by the parent. <em>Section-related</em> screens represent different sections of information about the parent. For example, one section may show textual information about an object while another may provide a map of the object's geographic location. The number of section-related screens for a given parent is generally small.</p> 66 <p>For section-related screens, offering touchable and keyboard-focusable targets in the parent is generally the most straightforward and familiar kind of touch-based navigation interface. Examples of such targets include buttons, fixed-size list views, or text links, although the latter is not an ideal UI (user interface) element for touch-based navigation. Upon selecting one of these targets, the child screen is opened, replacing the current context (screen) entirely. Buttons and other simple targets are rarely used for representing items in a collection.</p> 75 <p>A common, button-based pattern for accessing different top-level application sections, is the dashboard pattern. A <em>dashboard</em> is a grid of large, iconic buttons that constitutes the entirety, or most of, the parent screen. The grid generally has either 2 or 3 rows and columns, depending on the number of top-level sections in the app. This pattern is a great way to present all the sections of the app in a visually rich way. The large touch targets also make this UI very easy to use. Dashboards are best used when each section is equally important, as determined by product decisions or better yet, real-world usage. However, this pattern doesn't visually work well on larger screens, and requires users to take an extra step to jump directly into the app's content.</p> 89 <p>For collection-related screens, and especially for textual information, vertically scrolling lists are often the most straightfor (…)     [all...]
index.jd	31 <dt><strong><a href="screen-planning.html">Planning Screens and Their 33 <dd>Learn how to choose which screens your application should contain. Also learn how to choose which screens should be directly reachable from others. This lesson introduces a hypothetical news application to serve as an example for later lessons.</dd> 36 <dd>Learn how to group related screens together on larger-screen devices to optimize use of available screen space.</dd> 43 practices for the <em>Back</em> button and temporal navigation, or navigation to previous screens 47 <dd>Learn how to create screen wireframes (low-fidelity graphic mockups) representing the screens in a news application based on the desired information model. These wireframes utilize navigational elements discussed in previous lessons to demonstrate intuitive and efficient navigation.</dd>
screen-planning.jd	1 page.title=Planning Screens and Their Relationships 38 <p>Once you define the information model, you can begin to define the contexts necessary to enable users to effectively discover, view, and act upon the data in your application. In practice, one way to do this is to <em>determine the exhaustive set of screens</em> needed to allow users to navigate to and interact with the data. The set of screens we actually expose should generally vary depending on the target device; it's important to consider this early in the design process to ensure that the application can adapt to its environment.</p> 40 <p>In our example application, we want to enable users to <strong>view</strong>, <strong>save</strong>, and <strong>share</strong> <em>categorized</em> <strong>stories</strong> and <strong>photos</strong>. Below is an exhaustive list of screens that covers these use cases.</p> 57 <p>Now we can define the directed relationships between screens; an arrow from one screen <em>A</em> to another screen <em>B</em> implies that screen <em>B</em> should be directly reachable via some user interaction in screen <em>A</em>. Once we define both the set of screens and the relationships between them, we can express these in concert as a screen map, which shows all of your screens and their relationships:</p> 65 <p>If we later wanted to allow users to submit news stories or upload photos, we could add additional screens to this diagram.</p> 70 <p>At this point, it's possible to design a completely functional application from this exhaustive screen map. A simplistic user interface could consist of lists and buttons leading to child screens:</p>
/frameworks/base/docs/html/training/wearables/ui/
layouts.jd	10 <li><a href="#different-layouts">Specify Different Layouts for Square and Round Screens</a></li> 30 and round screens. Any content placed near the corners of the screen may be cropped on round 31 Android Wear devices, so layouts designed for square screens do not work well on round devices. 35 <p>For example, figure 1 shows how the following layout looks on square and round screens:</p> 39 square screens does not work well on round screens.</p> 56 <p>The text does not display correctly on devices with round screens.</p> 69 on both screen shapes without having views cropped near the edges of round screens.</p> 95 <h2 id="different-layouts">Specify Different Layouts for Square and Round Screens</h2> 98 different layout definitions for square and round screens. This class detects the screen shap     [all...]
/external/chromium_org/chrome/browser/chromeos/login/ui/
oobe_display.h	34 // Interface which is used by WizardController to do actual OOBE screens 35 // showing. Also it provides actors for the OOBE screens. 68 // Pointers to actors which should be used by the specific screens. Actors
/frameworks/base/tests/DpiTest/
AndroidManifest.xml	20 <supports-screens android:smallScreens="true" /> 21 <compatible-screens> 26 </compatible-screens>
/packages/apps/Email/res/values/
colors.xml	17 <!-- See also values-xlarge for specializations for xlarge screens --> 18 <!-- See also values-xlarge for specializations for xlarge screens --> 20 <!-- Account setup screens -->
/sdk/eclipse/plugins/com.android.ide.eclipse.tests/src/com/android/ide/eclipse/adt/internal/editors/layout/refactoring/testdata/
manifest-expected-completion16.txt	3 compatible-screens 11 supports-screens : The "supports-screens" specifies the screen dimensions an application supports.
/external/chromium_org/third_party/WebKit/ManualTests/
screen-availLeft.html	24 <p>On a two-monitor system, configure the menu bar to be on the right screen. Then drag this window between screens. When on the left screen, screen.availLeft should be negative.</p>
/frameworks/base/docs/html/design/style/
devices-displays.jd	40 <p>So where do you begin when designing for multiple screens? One approach is to work in the base 43 size, and then scale down and figure out the UI compromises you'll need to make on smaller screens.</p> 45 <p>For details about designing layouts for larger screens, see the <a 52 <a href="{@docRoot}training/multiscreen/index.html">Designing for Multiple Screens</a> and
/frameworks/base/docs/html/guide/practices/
screens-support-1.5.jd	3 parent.title=Supporting Multiple Screens 15 <li>There are some simple steps you should take to enable support for multiple screens in 21 <li><a href="#strategies">Adding Multiple Screens Support</a></li> 27 href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple Screens</a></li> 38 screens, using alternative resources for different screen configurations.</p> 57 mode</a> and instead support multiple screens, but also maintain compatibility with Android 1.5 and 69 <h2 id="strategies">Adding Multiple Screens Support</h2> 78 lowest version that includes support for multiple screens) and test your application on each 86 devices and multiple screens. </li> 93 platform's multiple screens support, even though it is technically using an earlier version of th     [all...]

Completed in 2934 milliseconds

12 3 4 5 6 7 8 91011>>