03:26 wlb: wayland-protocols Merge request !200 closed (Add none mode to xdg-decoration)
03:40 orowith2os[m]: I wish content-type used a bitmask on the content types
03:41 orowith2os[m]: looking at adding an additional content type, and it's not mutually exclusive with the other content types
03:41 orowith2os[m]: or, future other content types
03:46 wlb: wayland-protocols Merge request !246 opened by Dallas Strouse (orowith2os) content-type: Add "sensitive" content type https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/246
15:19 danieldg: there are likely windows that will sometimes show sensitive content and sometimes not: consider a password prompt that has a "show password" button - it becomes sensitive when you click that
17:33 kennylevinsen: Such content is also not safe on screen though
17:35 kennylevinsen: I wonder if screen share blocking is not mostly user preference, e.g. I wouldn't want to share chats, emails other browser tabs not relevant to the sharing session, they are not "sensitive"
17:48 orowith2os[m]: kennylevinsen: most of those also aren't dangerous to share
17:49 orowith2os[m]: Iffy, sure, but not dangerous
17:52 danieldg: there's no one-size-fits-all scenario here: if you're in private then nothing needs to be obscured on the screen, vs if I'm doing a presentation I don't want anything beyond the thing I'm showing to be visible
17:53 orowith2os[m]: danieldg: if you're doing a presentation, you're likely to also have a dedicated monitor workspace or way for apps to display their content and their content alone on there
17:53 orowith2os[m]: (and opening new windows on that dedicated workspace could/should not be allowed, imo - drag em over explicitly)
17:54 kennylevinsen: orowith2os[m]: the damage caused by sharing my email inbox would be far greater than the damage caused by accidentally showing, say, a password
17:54 kennylevinsen: So "danger" is subjective
17:55 orowith2os[m]: that is also true, and kinda nonsolvable unless the web has a similar "content-type" hint
17:55 kennylevinsen: (I can change the password and is guarded by a second factor, I cannot u share sensitive content)
17:55 kennylevinsen: My point is that "sensitive" is context specific
17:55 orowith2os[m]: maybe it would be better to just have plain content types - can always expand them to e.g. documents and email
17:56 kennylevinsen: I wonder if it's the right approach to try to mark content as "sensitive"
17:57 kennylevinsen: vs e.g. single-window sharing
17:58 danieldg: yeah, single-window sharing is more intuitive and actually does what marking sensitive seems to be trying to do
17:59 orowith2os[m]: an idea for marking content as sensitive would actually be letting the compositor know to provide a warning when sharing content marked as such
17:59 orowith2os[m]: not that single-window sharing is a bad idea - it's definitely better here, but not exclusive to a sensitive content type
18:00 danieldg: orowith2os[m]: but why not have that warning all the time?
18:00 danieldg: if it's not overly intrusive, it is nice to have a 'here's what you will be sharing' preview
18:00 orowith2os[m]: mmmmm, yeah, thinking about it, it's kinda a non-issue
18:00 orowith2os[m]: screensharing is already an explicit user action, by requirement
18:00 kennylevinsen: I think I'd have a hard time knowing what content should be marked sensitive, and as a user a hard time trusting that stuff is marked sensitive and would be excluded
18:01 orowith2os[m]: I'll go forward with more dedicated content types then
18:02 orowith2os[m]: needs an updated content-type protocol for protocol errors though
18:02 orowith2os[m]: if someone doesn't get on that before I do
18:06 kennylevinsen: orowith2os[m]: it might be good to have some example uses on both sides to show what behavior such types enable
18:07 orowith2os[m]: mm, I brought it up elsewhere, and a problem that was seen with content-type is that there's no "use" for content-type, apparently?
18:07 orowith2os[m]: e.g. the game content type could use a frame timing protocol, photo goes for HDR, video also does frame timing
18:09 danieldg: I could see it being useful for things like window placement rules in sway (put all games on the smaller 120Hz monitor not the bigger 60Hz one)
18:09 orowith2os[m]: mm
18:10 orowith2os[m]: could be useful in the recent GNOME Mosaic mockups
18:10 danieldg: not sure how much that would really be used as opposed to just appid-specific rules
18:10 orowith2os[m]: appid-specific rules are not something i think anybody wants to get into here
18:11 orowith2os[m]: I don't think a compositor would like if if they had to list off every video player under the sun in order to use their tiling rules properly
18:11 danieldg: no, the appid-specific stuff would be user-entered
18:11 orowith2os[m]: also not mutually exclusive
18:11 danieldg: or maybe inferred ("you opened org.foogame on DP-2 last time")
18:12 kennylevinsen: orowith2os[m]: the original use of the content-type protocol is setting KMS props which tells the monitor what content is being displayed - so that's the source of the types
18:13 orowith2os[m]: Ah, thanks
18:13 orowith2os[m]: Where should I look for a full list?
18:14 kennylevinsen: It was made generic as there could be other uses, but that's how the current list came to exist - having a similar "this type would allow compositors to be smart about XYZ" use case might be useful for new types
18:15 kennylevinsen: Hang on
18:16 kennylevinsen: orowith2os[m]: https://drmdb.emersion.fr/properties/3233857728/content%20type
18:17 orowith2os[m]: Awwww, no amdgpu support
18:17 orowith2os[m]: I should go bug Lina about supporting it in the Asahi kernel driver
18:17 orowith2os[m]: Thanks
18:18 kennylevinsen: Not sure if any compositors set it as a result of the content type protocol though
18:18 zamundaaa[m]: KWin does
18:19 zamundaaa[m]: Dallas Strouse (she/her) 🧑‍🏫: afaik there's patches for amdgpu to fix that
18:20 orowith2os[m]: Mutter doesn't support the protocol (yet), I can at least expose it to clients hopefully
18:20 orowith2os[m]: I'll look at doing so when an updated version is available
18:20 kennylevinsen: Other uses like enabling/disabling VRR also come to mind
18:20 kennylevinsen: But not sure what a compositor would do in response to "email" for example
18:25 orowith2os[m]: Mm, workspace management?
18:25 orowith2os[m]: I'd like to see it in GNOME
18:26 orowith2os[m]: A dedicated VRR or frame timing protocol seems more appropriate for that use case, but like with many things here, not mutually exclusive
18:26 danieldg: is 'place email on workspace 2' any better or worse than 'place thunderbird on workspace 2'?
18:27 orowith2os[m]: I'd argue better
18:27 danieldg: setting power savings modes might also be a thing compositors do that may not fit with client control
18:28 orowith2os[m]: I like to try out tons of random apps, so having non-app-specific window management (with specific where desired) would be nice
18:28 zamundaaa[m]: Dallas Strouse (she/her) 🧑‍🏫: content type is not really suitable for that sort of thing. It's too dynamic for that
18:29 zamundaaa[m]: Or do you want your browser window to be put into a different workspace when you open a web mail client / youtube / whatever?
18:30 orowith2os[m]: I was thinking more something that tied that together with the window manager
18:30 danieldg: maybe if it's opening a "chrome app" window just for the email client?
18:30 danieldg: (imo that's a dumb feature but someone must like it)
18:30 orowith2os[m]: This is probably fit for another protocol, but the browser can say "hey, I'm a web browser, and I'm playing video. Tell me if you'd like me to move myself or my tab out to another workspace"
18:30 zamundaaa[m]: danieldg: but that is not what the content type is suitable for
18:31 orowith2os[m]: In any case
18:31 orowith2os[m]: It's just one use case
18:31 zamundaaa[m]: You'd need something more like an 'app type' protocol for window management tasks
18:34 zamundaaa[m]: The content type protocol is more meant for what the hdmi content type thing is for, like changing the latency policy, changing upscaling filters, thag sort of thing
18:34 orowith2os[m]: Doesn't mean it should be limited to that either
18:34 orowith2os[m]: I'm going to need to rework the protocol anyways, so we can also make this an app-type protocol rather than content-type in the process
18:35 orowith2os[m]: Afaik most other properties a compositor would expect for window management already exist in other places
18:37 zamundaaa[m]: I don't want app type instead of content type
18:37 zamundaaa[m]: We need both
18:37 orowith2os[m]: (Content-type can be a part of app-type too)
18:37 orowith2os[m]: So app-type: browser, content-type: video
18:38 orowith2os[m]: Or app-type: game, content-type: shooter
18:38 zamundaaa[m]: That doesn't make sense
18:38 zamundaaa[m]: You could be playing a shooter in a browser
18:38 zamundaaa[m]: App and content type are completely separate things
18:39 orowith2os[m]: ~~sub-content-type?~~
18:40 orowith2os[m]: What do you think would be a good design here?
18:42 danieldg: keep it simple if possible, and ideally have an expected "what should this do" for everything
18:42 orowith2os[m]: Simple, I can do
18:42 orowith2os[m]: "what should this do" is more subjective
18:43 orowith2os[m]: Should probably be more "what *may* this do, on top of compositor decisions"
18:43 zamundaaa[m]: Dallas Strouse (she/her) 🧑‍🏫: just make a new app type protocol. Or I guess a compositors could already get that kind of information from .desktop files?
18:43 orowith2os[m]: Oooh, true
18:43 orowith2os[m]: Read a desktop file for the app type, and check the content type from the protocol
18:44 zamundaaa[m]: Yep
18:45 orowith2os[m]: So then, are there any additional content types we might want to have?
18:45 orowith2os[m]: On top of a better protocol design so it can actually expand :0
18:45 orowith2os[m]: *:p
18:50 danieldg: maybe a "document" or "reading" type where color accuracy is less important and you should more aggressively apply color temperature stuff?
18:51 orowith2os[m]: "document" seems appropriate
18:52 danieldg: it'd also apply to things like termials, IDEs
18:52 orowith2os[m]: I'm not so sure on that
18:53 orowith2os[m]: But could work just as well
18:53 orowith2os[m]: Especially paired with the desktop file categories
18:53 danieldg: what would you consider source code besides a document?
18:55 orowith2os[m]: A colorful document
18:55 orowith2os[m]: Mmm
18:55 orowith2os[m]: Never mind
18:55 danieldg: sure, it needs a separate application category, but I wouldn't consider the content (that is, it's a bunch of text that you read) to be different
18:56 orowith2os[m]: Yeah
18:56 orowith2os[m]: Just hit me
18:56 orowith2os[m]: (and that's why I need to hold more discussions like this....)