Option to lock the window title #386

Closed
opened 7 months ago by spwhitton · 8 comments

Hi,

Thanks for foot!

I have some scripts which match on the window title, and with the terminal emulator I was using previously, I could set --title=foo and programs running in the terminal would not be able to override that. But foot's --title is only the initial window title.

Could we have another option which sets the title permanently? Would be useful with scripts/bindings like mine.

Thanks.

Hi, Thanks for foot! I have some scripts which match on the window title, and with the terminal emulator I was using previously, I could set --title=foo and programs running in the terminal would not be able to override that. But foot's --title is only the initial window title. Could we have another option which sets the title permanently? Would be useful with scripts/bindings like mine. Thanks.
Collaborator

Wouldn't it make more sense to match on the --app-id?

Wouldn't it make more sense to match on the `--app-id`?
dnkl added the
enhancement
label 7 months ago
Poster

Well, I'm not sure -- shouldn't the app id always be set to 'foot'? Do you know what the semantics of the app id field are? Some googling suggests that it is whatever subdirectory of ~/.config the app would use, which in this case would still be 'foot'.

Well, I'm not sure -- shouldn't the app id always be set to 'foot'? Do you know what the semantics of the app id field are? Some googling suggests that it is whatever subdirectory of ~/.config the app would use, which in this case would still be 'foot'.
Collaborator

Do you know what the semantics of the app id field are?

Only from what I've read in xdg-shell.xml, which suggests a few use cases but doesn't really state any strict semantics.

shouldn't the app id always be set to 'foot'?

I guess it depends on the context. I only change it when I'm using foot as a "wrapper" for some other program and thus consider the app-id to apply to that rather than foot itself. I guess there are some use cases where that wouldn't be appropriate though.

Although I do think having the ability to set the title permanently (or prevent the client from changing it) would be a useful feature to have.

> Do you know what the semantics of the app id field are? Only from what I've read in [`xdg-shell.xml`](https://github.com/wayland-project/wayland-protocols/blob/6be6e00c0294e075e7b689167e08b52bf55ffccb/stable/xdg-shell/xdg-shell.xml#L642-L664), which suggests a few use cases but doesn't really state any strict semantics. > shouldn't the app id always be set to 'foot'? I guess it depends on the context. I only change it when I'm using foot as a "wrapper" for some other program and thus consider the app-id to apply to that rather than `foot` itself. I guess there are some use cases where that wouldn't be appropriate though. Although I do think having the ability to set the title permanently (or prevent the client from changing it) would be a useful feature to have.
Owner

On Sway at least, I believe using the app ID is the norm for scripting and/or writing window rules.

But, on e.g. GNOME, the app ID is used, among other things, to group application instances into taskbar groups. Using a different app ID means the window ends up in a different taskbar group.

I guess sometimes that is exactly what you want, but in other cases it's not. So, yeah, I can definitely see why being able to use something other than the app ID can be useful.

Some googling suggests that it is whatever subdirectory of ~/.config the app would use, which in this case would still be 'foot'.

In foot's case, changing the app ID does not change foot's behavior in any way; it still reads the same config files.

On Sway at least, I believe using the app ID is the norm for scripting and/or writing window rules. But, on e.g. GNOME, the app ID is used, among other things, to group application instances into taskbar groups. Using a different app ID means the window ends up in a different taskbar group. I guess sometimes that is exactly what you want, but in other cases it's not. So, yeah, I can definitely see why being able to use something _other_ than the app ID can be useful. > Some googling suggests that it is whatever subdirectory of ~/.config the app would use, which in this case would still be 'foot'. In foot's case, changing the app ID does not change foot's behavior in any way; it still reads the same config files.
Owner

If we choose to implement this, do we need both a command line option, and a foot.ini option? My guess is "yes, we do".

If we choose to implement this, do we need both a command line option, and a `foot.ini` option? My guess is "yes, we do".
Poster

If we choose to implement this, do we need both a command line option, and a foot.ini option? My guess is "yes, we do".

I think so -- seems that someone setting up a terminal with a fixed title might want to set that and a number of other options in a config file, and pass --config to foot.

> If we choose to implement this, do we need both a command line option, and a `foot.ini` option? My guess is "yes, we do". I think so -- seems that someone setting up a terminal with a fixed title might want to set that and a number of other options in a config file, and pass --config to foot.
Collaborator

There's now an --override command-line option (see #584), which can be used to set any config option, so I think just adding a new config option may suffice.

I'm guessing now that --override exists, the only reason to add new command-line options would be because they're likely to be used frequently and/or because they could benefit from shell auto-completion.

There's now an `--override` command-line option (see #584), which can be used to set *any* config option, so I think just adding a new config option may suffice. I'm guessing now that `--override` exists, the only reason to add new command-line options would be because they're likely to be used frequently and/or because they could benefit from shell auto-completion.
dnkl referenced this issue from a commit 3 months ago
Owner

With -o,--override, things are now much simpler, and I think we can go ahead and implement this.

With `-o,--override`, things are now much simpler, and I think we can go ahead and implement this.
dnkl closed this issue 3 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.