Feature Request: Show actual monitor names instead of generic "Screen 1", "Screen 2"

[kaovilai]

Feature Description

Currently, Deskreen displays generic screen names like "Screen 1", "Screen 2", "Screen 3" when selecting which display to share. This makes it difficult for users with multiple monitors to identify which screen they're selecting, especially when monitors are of the same resolution.

It would be much more user-friendly to display actual monitor names like:

• "LG UltraFine"
• "Dell U2720Q"
• "Samsung TV"
• "Built-in Retina Display"

Current Behavior

When selecting a screen to share, users see:

• Screen 1
• Screen 2
• Screen 3

Proposed Behavior

Display actual monitor model names:

• LG 27UK850
• Dell U2720Q
• MacBook Pro Built-in Display

Technical Analysis

Root Cause

Electron's desktopCapturer.getSources() API only provides generic names. The screen names come directly from this API call in app/features/DesktopCapturerSourcesService/index.ts:

const capturerSources = await desktopCapturer.getSources({
  types: [
    DesktopCapturerSourceType.WINDOW,
    DesktopCapturerSourceType.SCREEN,
  ],
  thumbnailSize: { width: 500, height: 500 },
  fetchWindowIcons: true,
});

Proposed Solution

Create a native Node.js addon that queries OS-specific display APIs to get friendly monitor names:

macOS Implementation:

// Using Core Graphics
CFStringRef displayName = CGDisplayCopyDisplayName(displayID);

Windows Implementation:

// Using Windows Display Configuration API
DISPLAYCONFIG_TARGET_DEVICE_NAME targetName;
DisplayConfigGetDeviceInfo(&targetName);

Linux Implementation:

// Using X11/XRandR or Wayland protocols
// More fragmented, depends on display server

Implementation Approach

1. Create Native Module (native-display-names):

   • Use node-gyp for building
   • Implement platform-specific code for each OS
   • Return a mapping of display IDs to friendly names

2. Integrate with Deskreen:

   // In DesktopCapturerSourcesService
   import { getDisplayNames } from 'native-display-names';
   
   const displayNames = await getDisplayNames();
   const sources = await this.getDesktopCapturerSources();
   
   // Map display IDs to friendly names
   sources.forEach((source) => {
     if (source.type === DesktopCapturerSourceType.SCREEN) {
       const friendlyName = displayNames[source.display_id];
       if (friendlyName) {
         source.name = friendlyName;
       }
     }
   });

3. Update UI Component:

   • Modify SharingSourcePreviewCard to display the enhanced names
   • Add fallback to generic names if native module fails

Benefits

1. Improved User Experience: Users can immediately identify which physical monitor they're selecting
2. Reduced Errors: Less chance of selecting the wrong screen
3. Professional Feel: Makes the application feel more polished and aware of the user's setup

Alternatives Considered

1. Electron Modification: Submit PR to Electron to add this feature to core

   • Pros: Benefits all Electron apps
   • Cons: Long approval process, may not be accepted

2. System Command Workarounds: Parse output from system commands

   • Pros: No native code needed
   • Cons: Fragile, platform-specific, may break with OS updates

Implementation Complexity

• Estimated Effort: 2-3 weeks for native module development
• Platforms: macOS, Windows, Linux
• Dependencies: node-gyp, platform-specific SDKs

References

• Similar request for Electron core: Allow Mac accessibility for apps other than VoiceOver electron/electron#7206
• Example macOS implementation: node-mac-displays
• Windows Display Configuration API documentation

[kaovilai]

I've created a corresponding issue in the Electron project to track this feature request upstream: electron/electron#47793

This will help get the attention of the Electron maintainers for implementing this feature at the framework level, which would benefit all Electron applications including Deskreen.

[pavlobu]

@kaovilai Thank you!
I'm impressed by your productivity recently on Deskreen project.
The problem is that the current project is really outdated in terms of packages and libraries used.
And the version of electron is really outdated.
Also the builds for latest Apple Silicon are producing .dmg with broken executables. It is due to outdated libraries.
It's a lot of work to update all of the dependencies up to date and remove outdated ones.

[pavlobu]

I'm currently working on changing a business model of the project, but community version would stay as is and will get updates from community members only.
The free version of Deskreen with updated libraries that I'm working on will not be open sourced as well as the pro version.
Your feature will be included if you manage to figure out this issue. This relates to all other features added by community members. If they are well done, meaningful and give value to users - it will be included in mantained freemium versions of Deskreen.

In future, as soon as I finish migrating to freemium business model of Deskreen, I will share pro version for free to most active community members as a giveaway as thanks for their support. So far you are the most active code contributor @kaovilai well done! And sadly you are the only one except me.

Also I will be doing giveaways of pro version to people who did at least some financial contribution to project. There are not many of them as well.

[kaovilai]

Thanks for your comments.

[kaovilai]

So IIUC, free OSS (archived?) as in this repo.
freemium and pro are not OSS, and likely can't be contributed to openly here.

[kaovilai]

Will all the versions be based off similar libraries at least such that if there is a feature request, I can submit here, and you can take the idea/implementation to your freemium?

[pavlobu]

Will all the versions be based off similar libraries at least such that if there is a feature request, I can submit here, and you can take the idea/implementation to your freemium?

Uhh,
Honestly with how badly it went with the community version I wanted this project to be archived. But if I archive - it would basically mean the end of the community version.
I consider at least updating the dependency libraries and they will be the same across all versions of Deskreen - community, free and pro.

Keeping community version up to date with dependency libraries will motivate good willed people like you to share their ideas and evolve the project further.

The features would be different though in all three versions

Cheers

[pavlobu]

@kaovilai
Thanks for raising these questions.

[kaovilai]

Barrier to contribute is lessening with coding agents :)

[pavlobu]

Agreed on that,
My problem was not the barrier of contribution,
the problem is that community is only taking and not giving and the second problem is that I started getting rude insults from people because of not maintaining the project for free

[pavlobu]

So your unexpected and promising appearance is giving me hope that this is not over yet. @kaovilai
and thank you for that

[kaovilai]

Here's a project with OSS, freemium, and Pro, complementary (virtual display) to Deskreen.

https://github.com/waydabber/BetterDisplay/wiki/List-of-free-and-Pro-features

MonitorControl is the OSS, BetterDisplay is paid. Might give you some ideas.