ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
junaid has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
iomari891 has quit [Quit: WeeChat 3.8]
iomari891 has joined #wayland
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
mblenc has joined #wayland
MrCooper has quit [Remote host closed the connection]
kts has joined #wayland
MrCooper has joined #wayland
mblenc1 has joined #wayland
<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
mblenc has quit [Read error: No route to host]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
sevz has joined #wayland
fmuellner has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
Leopold has joined #wayland
junaid has quit [Remote host closed the connection]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc1 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Such content is also not safe on screen though
<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"
<orowith2os[m]>
kennylevinsen: most of those also aren't dangerous to share
<orowith2os[m]>
Iffy, sure, but not dangerous
<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
<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
<orowith2os[m]>
(and opening new windows on that dedicated workspace could/should not be allowed, imo - drag em over explicitly)
<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
<kennylevinsen>
So "danger" is subjective
<orowith2os[m]>
that is also true, and kinda nonsolvable unless the web has a similar "content-type" hint
<kennylevinsen>
(I can change the password and is guarded by a second factor, I cannot u share sensitive content)
<kennylevinsen>
My point is that "sensitive" is context specific
<orowith2os[m]>
maybe it would be better to just have plain content types - can always expand them to e.g. documents and email
<kennylevinsen>
I wonder if it's the right approach to try to mark content as "sensitive"
<kennylevinsen>
vs e.g. single-window sharing
<danieldg>
yeah, single-window sharing is more intuitive and actually does what marking sensitive seems to be trying to do
<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
<orowith2os[m]>
not that single-window sharing is a bad idea - it's definitely better here, but not exclusive to a sensitive content type
<danieldg>
orowith2os[m]: but why not have that warning all the time?
<danieldg>
if it's not overly intrusive, it is nice to have a 'here's what you will be sharing' preview
<orowith2os[m]>
mmmmm, yeah, thinking about it, it's kinda a non-issue
<orowith2os[m]>
screensharing is already an explicit user action, by requirement
<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
<orowith2os[m]>
I'll go forward with more dedicated content types then
<orowith2os[m]>
needs an updated content-type protocol for protocol errors though
<orowith2os[m]>
if someone doesn't get on that before I do
<kennylevinsen>
orowith2os[m]: it might be good to have some example uses on both sides to show what behavior such types enable
<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?
<orowith2os[m]>
e.g. the game content type could use a frame timing protocol, photo goes for HDR, video also does frame timing
<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)
<orowith2os[m]>
mm
<orowith2os[m]>
could be useful in the recent GNOME Mosaic mockups
<danieldg>
not sure how much that would really be used as opposed to just appid-specific rules
<orowith2os[m]>
appid-specific rules are not something i think anybody wants to get into here
<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
<danieldg>
no, the appid-specific stuff would be user-entered
<orowith2os[m]>
also not mutually exclusive
<danieldg>
or maybe inferred ("you opened org.foogame on DP-2 last time")
<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
<orowith2os[m]>
Ah, thanks
<orowith2os[m]>
Where should I look for a full list?
<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
<orowith2os[m]>
I should go bug Lina about supporting it in the Asahi kernel driver
<orowith2os[m]>
Thanks
<kennylevinsen>
Not sure if any compositors set it as a result of the content type protocol though
<zamundaaa[m]>
KWin does
<zamundaaa[m]>
Dallas Strouse (she/her) 🧑🏫: afaik there's patches for amdgpu to fix that
<orowith2os[m]>
Mutter doesn't support the protocol (yet), I can at least expose it to clients hopefully
<orowith2os[m]>
I'll look at doing so when an updated version is available
<kennylevinsen>
Other uses like enabling/disabling VRR also come to mind
<kennylevinsen>
But not sure what a compositor would do in response to "email" for example
<orowith2os[m]>
Mm, workspace management?
<orowith2os[m]>
I'd like to see it in GNOME
<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
<danieldg>
is 'place email on workspace 2' any better or worse than 'place thunderbird on workspace 2'?
<orowith2os[m]>
I'd argue better
<danieldg>
setting power savings modes might also be a thing compositors do that may not fit with client control
<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
<zamundaaa[m]>
Dallas Strouse (she/her) 🧑🏫: content type is not really suitable for that sort of thing. It's too dynamic for that
nerdopolis has joined #wayland
<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?
<orowith2os[m]>
I was thinking more something that tied that together with the window manager
<danieldg>
maybe if it's opening a "chrome app" window just for the email client?
<danieldg>
(imo that's a dumb feature but someone must like it)
<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"
<zamundaaa[m]>
danieldg: but that is not what the content type is suitable for
<orowith2os[m]>
In any case
<orowith2os[m]>
It's just one use case
<zamundaaa[m]>
You'd need something more like an 'app type' protocol for window management tasks
<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
<orowith2os[m]>
Doesn't mean it should be limited to that either
<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
<orowith2os[m]>
Afaik most other properties a compositor would expect for window management already exist in other places
<zamundaaa[m]>
I don't want app type instead of content type
<zamundaaa[m]>
We need both
<orowith2os[m]>
(Content-type can be a part of app-type too)
<orowith2os[m]>
So app-type: browser, content-type: video
<orowith2os[m]>
Or app-type: game, content-type: shooter
<zamundaaa[m]>
That doesn't make sense
<zamundaaa[m]>
You could be playing a shooter in a browser
<zamundaaa[m]>
App and content type are completely separate things
<orowith2os[m]>
~~sub-content-type?~~
<orowith2os[m]>
What do you think would be a good design here?
<danieldg>
keep it simple if possible, and ideally have an expected "what should this do" for everything
<orowith2os[m]>
Simple, I can do
<orowith2os[m]>
"what should this do" is more subjective
<orowith2os[m]>
Should probably be more "what *may* this do, on top of compositor decisions"
<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?
<orowith2os[m]>
Oooh, true
<orowith2os[m]>
Read a desktop file for the app type, and check the content type from the protocol
<zamundaaa[m]>
Yep
<orowith2os[m]>
So then, are there any additional content types we might want to have?
<orowith2os[m]>
On top of a better protocol design so it can actually expand :0
<orowith2os[m]>
*:p
hays has quit [Remote host closed the connection]
<danieldg>
maybe a "document" or "reading" type where color accuracy is less important and you should more aggressively apply color temperature stuff?
<orowith2os[m]>
"document" seems appropriate
<danieldg>
it'd also apply to things like termials, IDEs
<orowith2os[m]>
I'm not so sure on that
<orowith2os[m]>
But could work just as well
<orowith2os[m]>
Especially paired with the desktop file categories
<danieldg>
what would you consider source code besides a document?
<orowith2os[m]>
A colorful document
<orowith2os[m]>
Mmm
<orowith2os[m]>
Never mind
<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
<orowith2os[m]>
Yeah
<orowith2os[m]>
Just hit me
<orowith2os[m]>
(and that's why I need to hold more discussions like this....)
kts has quit [Quit: Leaving]
junaid has joined #wayland
hays has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
DPA has quit [Ping timeout: 480 seconds]
DPA has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
iomari891 has joined #wayland
psykose has joined #wayland
junaid has quit [Remote host closed the connection]
mblenc has joined #wayland
sima has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
iomari891 has quit [Remote host closed the connection]