Gnome Shell扩展开发:monitor对象inFullscreen状态及相关API咨询
Hey there, let's tackle your GNOME Shell extension questions one by one—since the imports.ui.* docs are pretty sparse, I’ll lean on the code and debugging tricks I’ve picked up over time.
monitor.inFullscreen (and Keeping Maximize Separate) First off, good news: GNOME Shell already distinguishes between fullscreen windows and maximized windows natively, so monitor.inFullscreen won’t flip to true when a window is maximized. That property only triggers when a window enters "true fullscreen" mode (think video players, games, or apps that hide all window decorations and take over the entire display).
To track when this happens, use GObject's property notification system—since Monitor is a GObject subclass, you can listen for changes to the in-fullscreen property:
const { Meta } = imports.gi; // Grab the primary monitor (or loop through all monitors if needed) const primaryMonitor = Meta.Display.get_default().get_primary_monitor(); // Set up the listener primaryMonitor.connect('notify::in-fullscreen', () => { if (primaryMonitor.in_fullscreen) { console.log('Monitor just entered fullscreen mode!'); // Add your custom logic here } else { console.log('Monitor exited fullscreen mode.'); } });
Maximized windows won’t trigger this, so you don’t have to add extra checks to filter those out.
queueDeferredWork? queueDeferredWork is GNOME Shell’s way of scheduling non-urgent tasks to run later, outside of critical paths like window animations or workspace switches. The goal is to avoid jank by pushing heavy or non-time-sensitive work to the end of the current event loop cycle, or the next idle period.
You can test it directly in the lg REPL with something like:
global.queueDeferredWork(() => { console.log('This runs after the current batch of UI updates is done!'); });
In extensions, use this when you need to update UI elements, process data, or run any code that doesn’t need to block the current user interaction.
You’re right—the switch-workspace signal fires as soon as the switch starts, not when it’s finished. For a signal that triggers after the switch (and any animations) are fully done, use the workspace-switched signal on Meta.Display:
const { Meta } = imports.gi; const display = Meta.Display.get_default(); display.connect('workspace-switched', (display, newWs, oldWs) => { console.log(`Successfully switched to workspace ${newWs.index()} (from ${oldWs.index()})`); // Your post-switch logic goes here });
If you need even tighter timing (right when the animation finishes, before any follow-up UI tweaks), you can listen to workspace-switch-animation-completed on the global object instead.
imports.ui.* Exploration Since official docs are lacking, use the lg REPL to dig into the code directly. Type viewSource(imports.ui.main) to pull up the main UI module’s source, or print an object’s properties with print(Object.keys(imports.ui.main)) to see what’s available. Studying popular extensions (like those on GNOME Extensions) is also a great way to learn how others use these internal APIs.
内容的提问来源于stack exchange,提问作者Sassan

