इस पेज का अनुवाद Cloud Translation API से किया गया है.

विंडो मैनेजमेंट एपीआई की मदद से कई डिसप्ले मैनेज करना

कनेक्ट किए गए डिसप्ले के बारे में जानकारी पाना और उन डिसप्ले के हिसाब से विंडो की पोज़िशन तय करना.

Thomas Steiner

Window Management API

विंडो मैनेजमेंट एपीआई आपको अपनी मशीन से कनेक्ट किए गए डिसप्ले की सूची बनाने और खास स्क्रीन पर विंडो रखने की सुविधा देता है.

इस्तेमाल के सुझाए गए उदाहरण

उन साइटों के उदाहरण जो इस एपीआई का इस्तेमाल कर सकते हैं:

Gimp जैसे कई विंडो वाले ग्राफ़िक एडिटर, बदलाव करने वाले अलग-अलग टूल को सही जगह पर रख सकते हैं.
वर्चुअल ट्रेडिंग डेस्क, मार्केट के रुझानों को कई विंडो में दिखा सकते हैं. इनमें से किसी भी विंडो को फ़ुलस्क्रीन मोड में देखा जा सकता है.
स्लाइड शो वाले ऐप्लिकेशन, डिवाइस की मुख्य स्क्रीन पर प्रज़ेंटर के नोट और बाहरी प्रोजेक्टर पर प्रज़ेंटेशन दिखा सकते हैं.

Window Management API का इस्तेमाल करने का तरीका

समस्या

विंडो को कंट्रोल करने का समय-समय पर आज़माया गया तरीका, Window.open(), माफ़ करें, यह अन्य स्क्रीन के बारे में नहीं जानता. इस एपीआई के कुछ पहलू थोड़े पुराने लगते हैं. जैसे, इसका windowFeatures DOMString पैरामीटर. इसके बावजूद, यह एपीआई पिछले कई सालों से हमारी मदद कर रहा है. किसी विंडो की पोज़िशन तय करने के लिए, निर्देशांक को left और top (या screenX और screenY) के तौर पर पास किया जा सकता है. साथ ही, अपनी पसंद के साइज़ को width और height (या innerWidth और innerHeight) के तौर पर पास किया जा सकता है. उदाहरण के लिए, बाईं ओर से 50 पिक्सल और ऊपर से 50 पिक्सल पर, 400×300 वाली विंडो खोलने के लिए, इस कोड का इस्तेमाल किया जा सकता है:

const popup = window.open(
  'https://example.com/',
  'My Popup',
  'left=50,top=50,width=400,height=300',
);

window.screen प्रॉपर्टी की मदद से, मौजूदा स्क्रीन के बारे में जानकारी पाई जा सकती है. यह प्रॉपर्टी, Screen ऑब्जेक्ट दिखाती है. मेरे MacBook Pro 13″ पर यह आउटपुट दिखता है:

window.screen;
/* Output from my MacBook Pro 13″:
  availHeight: 969
  availLeft: 0
  availTop: 25
  availWidth: 1680
  colorDepth: 30
  height: 1050
  isExtended: true
  onchange: null
  orientation: ScreenOrientation {angle: 0, type: "landscape-primary", onchange: null}
  pixelDepth: 30
  width: 1680
*/

टेक्नोलॉजी से जुड़े ज़्यादातर लोगों की तरह, मुझे भी काम करने के नए तरीके के हिसाब से अपने आपको ढालना पड़ा है. साथ ही, मैंने अपने घर में एक निजी ऑफ़िस भी सेट अप किया है. मेरा खाता नीचे दी गई फ़ोटो पर दिया गया है (अगर इसमें आपकी दिलचस्पी है, तो मेरे सेटअप के बारे में पूरी जानकारी देखें). मेरे MacBook के बगल में मौजूद iPad, Sidecar की मदद से लैपटॉप से कनेक्ट है. इसलिए, जब भी ज़रूरत पड़े, मैं iPad को दूसरी स्क्रीन में तुरंत बदल सकता हूं.

दो कुर्सियों पर स्कूल की बेंच. स्कूल की बेंच पर जूते के बॉक्स में एक लैपटॉप रखा है. इसके आस-पास दो iPad रखे हैं. — मल्टी-स्क्रीन सेटअप.

अगर मुझे बड़ी स्क्रीन का फ़ायदा लेना है, तो ऊपर दिए गए कोड सैंपल में मौजूद पॉप-अप को दूसरी स्क्रीन पर दिखाया जा सकता है. मैं इसे इस तरह करता/करती हूं:

popup.moveTo(2500, 50);

यह अनुमानित अनुमान है, क्योंकि दूसरी स्क्रीन के डाइमेंशन का पता लगाने का कोई तरीका नहीं है. window.screen से मिली जानकारी में सिर्फ़ डिवाइस में पहले से मौजूद स्क्रीन की जानकारी शामिल होती है, न कि iPad की स्क्रीन की. रिपोर्ट की गई बिल्ट-इन स्क्रीन का width 1680 पिक्सल का था, इसलिए 2500 पिक्सल की जगह बदलने से विंडो को iPad पर शिफ़्ट हो सकता है. ऐसा इसलिए, क्योंकि मुझे पता चला है कि यह मेरे MacBook की दाईं ओर बना है. आम तौर पर, इसे कैसे किया जा सकता है? हालांकि, अनुमान लगाने के बजाय, एक बेहतर तरीका है. यह तरीका, Window Management API है.

सुविधा की पहचान

यह देखने के लिए कि Window Management API काम करता है या नहीं, इनका इस्तेमाल करें:

if ('getScreenDetails' in window) {
  // The Window Management API is supported.
}

`window-management` की अनुमति

ध्यान दें: window-placement अनुमति का पुराना नाम अब काम नहीं करता.

Window Management API का इस्तेमाल करने से पहले, मुझे उपयोगकर्ता से अनुमति लेनी होगी. window-management अनुमति के लिए, Permissions API से इस तरह क्वेरी की जा सकती है:

let granted = false;
try {
  const { state } = await navigator.permissions.query({ name: 'window-management' });
  granted = state === 'granted';
} catch {
  // Nothing.
}

अनुमति के पुराने और नए नाम वाले ब्राउज़र इस्तेमाल में होने के दौरान, अनुमति का अनुरोध करते समय, नीचे दिए गए उदाहरण की तरह ही, डिफ़ेंसिव कोड का इस्तेमाल करना न भूलें.

async function getWindowManagementPermissionState() {
  let state;
  // The new permission name.
  try {
    ({ state } = await navigator.permissions.query({
      name: "window-management",
    }));
  } catch (err) {
    return `${err.name}: ${err.message}`;
  }
  return state;
}

document.querySelector("button").addEventListener("click", async () => {
  const state = await getWindowManagementPermissionState();
  document.querySelector("pre").textContent = state;
});

ब्राउज़र, नए एपीआई के किसी भी तरीके का इस्तेमाल करने के पहले, अनुमति का अनुरोध डाइनैमिक तौर पर दिखाने का विकल्प चुना सकता है. ज़्यादा जानने के लिए आगे पढ़ें.

`window.screen.isExtended` प्रॉपर्टी

यह जानने के लिए कि मेरे डिवाइस से एक से ज़्यादा स्क्रीन कनेक्ट हैं या नहीं, मैं window.screen.isExtended प्रॉपर्टी को ऐक्सेस करता/करती हूं. यह true या false दिखाता है. मेरे सेटअप के लिए, यह true दिखाता है.

window.screen.isExtended;
// Returns `true` or `false`.

`getScreenDetails()` तरीका

अब मुझे पता है कि मौजूदा सेटअप मल्टी-स्क्रीन है. इसलिए, Window.getScreenDetails() का इस्तेमाल करके दूसरी स्क्रीन के बारे में ज़्यादा जानकारी पाई जा सकती है. इस फ़ंक्शन को कॉल करने पर, अनुमति का एक प्रॉम्प्ट दिखेगा. इसमें मुझसे पूछा जाएगा कि क्या साइट को मेरी स्क्रीन पर विंडो खोलने और प्लेस करने की अनुमति दी जा सकती है. यह फ़ंक्शन एक प्रॉमिस दिखाता है, जो ScreenDetailed ऑब्जेक्ट के साथ रिज़ॉल्व होता है. मेरे MacBook Pro 13 में, कनेक्ट किए गए iPad के साथ, इसमें दो ScreenDetailed ऑब्जेक्ट वाला screens फ़ील्ड शामिल है:

await window.getScreenDetails();
/* Output from my MacBook Pro 13″ with the iPad attached:
{
  currentScreen: ScreenDetailed {left: 0, top: 0, isPrimary: true, isInternal: true, devicePixelRatio: 2, …}
  oncurrentscreenchange: null
  onscreenschange: null
  screens: [{
    // The MacBook Pro
    availHeight: 969
    availLeft: 0
    availTop: 25
    availWidth: 1680
    colorDepth: 30
    devicePixelRatio: 2
    height: 1050
    isExtended: true
    isInternal: true
    isPrimary: true
    label: "Built-in Retina Display"
    left: 0
    onchange: null
    orientation: ScreenOrientation {angle: 0, type: "landscape-primary", onchange: null}
    pixelDepth: 30
    top: 0
    width: 1680
  },
  {
    // The iPad
    availHeight: 999
    availLeft: 1680
    availTop: 25
    availWidth: 1366
    colorDepth: 24
    devicePixelRatio: 2
    height: 1024
    isExtended: true
    isInternal: false
    isPrimary: false
    label: "Sidecar Display (AirPlay)"
    left: 1680
    onchange: null
    orientation: ScreenOrientation {angle: 0, type: "landscape-primary", onchange: null}
    pixelDepth: 24
    top: 0
    width: 1366
  }]
}
*/

कनेक्ट की गई स्क्रीन की जानकारी, screens कलेक्शन में उपलब्ध होती है. ध्यान दें कि iPad के लिए left की वैल्यू 1680 से शुरू होती है, जो बिल्ट-इन डिसप्ले की width वैल्यू से मेल खाती है. इससे मुझे यह तय करने में मदद मिलती है कि स्क्रीन को एक-दूसरे के बगल में, एक-दूसरे के ऊपर वगैरह किस तरह व्यवस्थित किया जाए. अब हर स्क्रीन के लिए डेटा उपलब्ध है. इससे यह पता चल सकता है कि वह isInternal है और isPrimary वाली है या नहीं. ध्यान दें कि ज़रूरी नहीं है कि पहले से मौजूद स्क्रीन ही प्राइमरी स्क्रीन हो.

currentScreen फ़ील्ड एक लाइव ऑब्जेक्ट है, जो मौजूदा window.screen से जुड़ा है. ऑब्जेक्ट, स्क्रीन के बीच विंडो के प्लेसमेंट या डिवाइस में हुए बदलावों के हिसाब से अपडेट होता है.

ध्यान दें: Chromium के सबसे नए एपीआई लागू करने की सुविधा, "Internal Display 1" जैसे कम जानकारी वाले प्लेसहोल्डर के बजाय, "Built-in Retina Display" जैसे प्लैटफ़ॉर्म से मिले स्क्रीन लेबल दिखाती है.

`screenschange` इवेंट

अब बस एक चीज़ की कमी है. मुझे यह पता लगाने का तरीका चाहिए कि मेरी स्क्रीन का सेटअप कब बदला. एक नया इवेंट, screenschange, ठीक यही करता है: यह तब ट्रिगर होता है, जब स्क्रीन कॉन्स्टेलेशन में बदलाव किया जाता है. (ध्यान दें कि इवेंट के नाम में "स्क्रीन" की संख्या कई है.) इसका मतलब है कि जब भी कोई नई स्क्रीन या मौजूदा स्क्रीन (Sidecar के मामले में, फ़िज़िकली या वर्चुअल तौर पर) प्लग इन या अनप्लग की जाती है, तब यह इवेंट ट्रिगर होता है.

ध्यान दें कि आपको नई स्क्रीन की जानकारी को अलग-अलग समय पर देखना होगा. screenschange इवेंट खुद यह डेटा नहीं देता. स्क्रीन की जानकारी देखने के लिए, कैश मेमोरी में सेव किए गए Screens इंटरफ़ेस से लाइव ऑब्जेक्ट का इस्तेमाल करें.

const screenDetails = await window.getScreenDetails();
let cachedScreensLength = screenDetails.screens.length;
screenDetails.addEventListener('screenschange', (event) => {
  if (screenDetails.screens.length !== cachedScreensLength) {
    console.log(
      `The screen count changed from ${cachedScreensLength} to ${screenDetails.screens.length}`,
    );
    cachedScreensLength = screenDetails.screens.length;
  }
});

`currentscreenchange` इवेंट

अगर मुझे सिर्फ़ मौजूदा स्क्रीन में हुए बदलावों (यानी, लाइव ऑब्जेक्ट currentScreen की वैल्यू) में दिलचस्पी है, तो मैं currentscreenchange इवेंट को सुन सकता/सकती हूं.

const screenDetails = await window.getScreenDetails();
screenDetails.addEventListener('currentscreenchange', async (event) => {
  const details = screenDetails.currentScreen;
  console.log('The current screen has changed.', event, details);
});

`change` इवेंट

आख़िर में, अगर मुझे सिर्फ़ कंक्रीट की स्क्रीन में बदलाव करना है, तो मैं उस स्क्रीन का change इवेंट सुन सकता हूँ.

const firstScreen = (await window.getScreenDetails())[0];
firstScreen.addEventListener('change', async (event) => {
  console.log('The first screen has changed.', event, firstScreen);
});

फ़ुलस्क्रीन मोड के नए विकल्प

अब तक, requestFullScreen() के नाम से जाने जाने वाले तरीके का इस्तेमाल करके, एलिमेंट को फ़ुल स्क्रीन मोड में दिखाने का अनुरोध किया जा सकता था. यह तरीका options पैरामीटर लेता है, जिसमें FullscreenOptions को पास किया जा सकता है. अब तक, इसकी सिर्फ़ प्रॉपर्टी navigationUI है. Window Management API, एक नई screen प्रॉपर्टी जोड़ता है. इससे यह तय किया जा सकता है कि फ़ुलस्क्रीन व्यू को किस स्क्रीन पर शुरू करना है. उदाहरण के लिए, अगर आपको प्राइमरी स्क्रीन को फ़ुलस्क्रीन में दिखाना है, तो:

try {
  const primaryScreen = (await getScreenDetails()).screens.filter((screen) => screen.isPrimary)[0];
  await document.body.requestFullscreen({ screen: primaryScreen });
} catch (err) {
  console.error(err.name, err.message);
}

पॉलीफ़िल

Window Management API को पॉलीफ़िल नहीं किया जा सकता. हालांकि, इसके आकार में बदलाव किया जा सकता है, ताकि आप नए एपीआई के लिए खास तौर पर कोड लिख सकें:

if (!('getScreenDetails' in window)) {
  // Returning a one-element array with the current screen,
  // noting that there might be more.
  window.getScreenDetails = async () => [window.screen];
  // Set to `false`, noting that this might be a lie.
  window.screen.isExtended = false;
}

एपीआई के अन्य पहलू, जैसे कि स्क्रीन में बदलाव होने से जुड़े अलग-अलग इवेंट और FullscreenOptions की screen प्रॉपर्टी, काम न करने वाले ब्राउज़र में कभी ट्रिगर नहीं होगी या चुपचाप अनदेखा कर दी जाएगी.

डेमो

अगर आप मेरे जैसे लोग हैं, तो आप अलग-अलग क्रिप्टो करंसी के डेवलपमेंट पर खास ध्यान देते हैं. (असल में, मुझे यह प्लान बिलकुल पसंद नहीं है, क्योंकि मुझे यह ग्रह बहुत पसंद है. हालांकि, इस लेख के लिए मान लें कि मुझे यह प्लान पसंद है.) मेरी क्रिप्टो करंसी को ट्रैक करने के लिए, मैंने एक वेब ऐप्लिकेशन बनाया है. इससे मुझे ज़िंदगी की हर स्थिति में बाज़ार के बारे में जानने की सुविधा मिलती है. जैसे, अपने बेड के आराम से उस जगह पर जहाँ मेरा सिंगल-स्क्रीन सेटअप है.

बिस्तर के आखिर में बड़ी टीवी स्क्रीन है. इसमें लेखक के पैर दिख रहे हैं. स्क्रीन पर, नकली क्रिप्टो करंसी ट्रेडिंग डेस्क. — आराम करते हुए बाज़ार देखना.

क्रिप्टो करंसी के मामले में, मार्केट में कभी भी उतार-चढ़ाव हो सकते हैं. अगर ऐसा होता है, तो मैं तुरंत अपने डेस्क पर जा सकती हूं, जहां मेरे पास कई स्क्रीन का सेटअप है. किसी भी मुद्रा की विंडो पर क्लिक करके, दूसरी स्क्रीन पर फ़ुलस्क्रीन व्यू में तुरंत पूरी जानकारी देखी जा सकती है. यहां मेरी हाल ही की एक फ़ोटो दी गई है, जो YCY bloodbath के दौरान ली गई थी. इसने मुझे पूरी तरह से पीछे कर दिया और मुझे अपने हाथों को मेरे चेहरे पर रख दिया.

एक लेखक, घबराते हुए चेहरे पर हाथ रखे हुए, नकली क्रिप्टो करंसी ट्रेडिंग डेस्क को देख रहा है. — पंकी, वाईसीवाई ब्लडबाथ देखते हुए.

यहां एम्बेड किए गए डेमो को चलाया जा सकता है या glitch पर इसका सोर्स कोड देखा जा सकता है.

सुरक्षा और अनुमतियां

Chrome की टीम ने Window Management API को डिज़ाइन और लागू किया है. इसके लिए, वेब प्लैटफ़ॉर्म की बेहतर सुविधाओं के ऐक्सेस को कंट्रोल करना में बताए गए मुख्य सिद्धांतों का इस्तेमाल किया गया है. इनमें उपयोगकर्ता कंट्रोल, पारदर्शिता, और काम करने के तरीके से जुड़े सिद्धांत शामिल हैं. Window Management API, किसी डिवाइस से कनेक्ट की गई स्क्रीन के बारे में नई जानकारी दिखाता है. इससे, उपयोगकर्ताओं के फ़िंगरप्रिंट की जानकारी इकट्ठा करने की सुविधा बढ़ जाती है. खास तौर पर, उन उपयोगकर्ताओं के लिए जिनके डिवाइसों से लगातार कई स्क्रीन कनेक्ट रहती हैं. इस निजता से जुड़ी चिंता को कम करने के लिए, एक्सपोज़ की गई स्क्रीन प्रॉपर्टी को सामान्य प्लेसमेंट के इस्तेमाल के उदाहरणों के लिए, ज़रूरत के मुताबिक सीमित किया गया है. मल्टी-स्क्रीन की जानकारी पाने और अन्य स्क्रीन पर विंडो प्लेस करने के लिए, साइटों को उपयोगकर्ता की अनुमति लेनी होगी. Chromium, स्क्रीन के लेबल की पूरी जानकारी दिखाता है. हालांकि, ब्राउज़र में कम जानकारी वाले या खाली लेबल भी दिख सकते हैं.

ऐप्लिकेशन पर उपयोगकर्ताओं के कंट्रोल की जानकारी

उपयोगकर्ता अपने सेटअप के एक्सपोज़र का पूरा कंट्रोल रखता है. वे अनुमति के प्रॉम्प्ट को स्वीकार या अस्वीकार कर सकते हैं. साथ ही, ब्राउज़र में साइट की जानकारी देने वाली सुविधा का इस्तेमाल करके, पहले दी गई अनुमति को वापस ले सकते हैं.

एंटरप्राइज़ के लिए कंट्रोल

Chrome Enterprise के उपयोगकर्ता, Window Management API के कई पहलुओं को कंट्रोल कर सकते हैं. इन पहलुओं के बारे में, Atomic Policy Groups सेटिंग के काम के सेक्शन में बताया गया है.

पारदर्शिता

ब्राउज़र की साइट की जानकारी में यह जानकारी दिखती है कि विंडो मैनेजमेंट एपीआई का इस्तेमाल करने की अनुमति दी गई है या नहीं. साथ ही, Permissions API की मदद से भी इसकी जानकारी हासिल की जा सकती है.

अनुमति का बना रहना

ब्राउज़र ने अब भी अनुमति दी है. ब्राउज़र की साइट जानकारी की मदद से, अनुमति रद्द की जा सकती है.

सुझाव/राय दें या शिकायत करें

Chrome की टीम, Window Management API के इस्तेमाल से जुड़े आपके अनुभवों के बारे में जानना चाहती है.

हमें एपीआई के डिज़ाइन के बारे में बताएं

क्या एपीआई में कोई ऐसी चीज़ है जो आपकी उम्मीद के मुताबिक काम नहीं करती? क्या आपके आइडिया को लागू करने के लिए, कोई तरीका या प्रॉपर्टी मौजूद नहीं है? क्या आपका सुरक्षा मॉडल के बारे में कोई सवाल या टिप्पणी है?

इससे जुड़े GitHub रेपो पर, कोई खास समस्या दर्ज करें या किसी मौजूदा समस्या में अपनी राय जोड़ें.

लागू करने से जुड़ी समस्या की शिकायत करना

क्या आपको Chrome में इस सुविधा को लागू करने में कोई गड़बड़ी मिली? या क्या लागू करने का तरीका, स्पेसिफ़िकेशन से अलग है?

new.crbug.com पर गड़बड़ी की शिकायत करें. इसमें ज़्यादा से ज़्यादा जानकारी शामिल करें. साथ ही, गड़बड़ी को दोहराने के लिए आसान निर्देश दें. इसके बाद, Components बॉक्स में Blink>Screen>MultiScreen डालें. Glitch, तुरंत और आसानी से समस्या की जानकारी शेयर करने के लिए बहुत अच्छा है.

एपीआई के लिए सहायता दिखाना

क्या आपको विंडो मैनेजमेंट एपीआई इस्तेमाल करना है? सार्वजनिक तौर पर सहायता करने से, Chrome टीम को सुविधाओं को प्राथमिकता देने में मदद मिलती है. साथ ही, इससे अन्य ब्राउज़र वेंडर को यह पता चलता है कि इन सुविधाओं को उपलब्ध कराना कितना ज़रूरी है.

WICG के Discourse थ्रेड पर बताएं कि आपको इसका इस्तेमाल कैसे करना है.
हैशटैग #WindowManagement का इस्तेमाल करके @ChromiumDev को ट्वीट भेजें और हमें बताएं कि उनका इस्तेमाल कहां और कैसे किया जा रहा है.
अन्य ब्राउज़र वेंडर से एपीआई लागू करने के लिए कहें.

मददगार लिंक

धन्यवाद

Window Management API स्पेसिफ़िकेशन में बदलाव करने वाले लोगों में विक्टर कोस्टन, जोशुआ बेल, और माइक वाटरमैन शामिल हैं. एपीआई को माइक वाटरमैन और ऐड्रियन वॉकर ने लागू किया था. इस लेख की समीक्षा जो मेडली, फ़्रैंसुआ बफ़ोर, और केस बेस्केस ने की. इन फ़ोटो के लिए, लॉरा टोरेंट पुइग को धन्यवाद.