Issue 117073: -w winname: optional window title bar text
Patch Set 1 #
MessagesTotal messages: 14
I'd rather not. Why should acme have this option but none of the other programs? If this functionality is truly important, it should be done in a more general way. One distasteful option would be to define that the window size can have a '#window title' suffix. I don't like that option either, but it would be better than special-casing acme. Maybe an even better option will present itself given time.
Sign in to reply to this message.
On 2009/09/15 16:24:51, rsc wrote:
> I'd rather not.
As you like. It meets my need on the computers I use. Will I need to reapply
my patch each time I download a new version of plan9port which changes acme.c?
If so I'll write a little sam script to do so, but I guess keep it private.
> Why should acme have this option
Here's my use case. I run acme once on each computer I'm logged in to. This
creates several windows just marked "acme", which I can only distinguish by
remembering the order in which I started them (which may be different each time
I reboot, twice per workday), or by actually selecting the window to refresh
(which can be slow over a VPN connection to work).
So in the script I run which calls acme, I pass it the name of the dump file I
restore from, and the directory in which I start acme. This ends up in the
window title, to help me quickly find the context I want, and reminds me where
acme is "rooted".
> but none of the other programs?
If this is the issue I'll code this option into each GUI program. The code is
easy enough.
<rant>Acme is the only GUI program I use from plan9port. It is also the only
program I use which demands that only one copy of it run at a time. This is an
obnoxious, stupid restriction, made bearable only by Dump and -l. I understand
that it mounts a filesystem, but maybe an even better solution to an exclusive
lock (eg /mnt/acme.$apid) will present itself given time.</rant>
> Maybe an even better option will present itself
> given time.
How about something like X11 resources? ;)
% cat .riosources
acme.title "My title for acme"
The problem here is that the whole goal of the option is that it's different for
each running acme. Even just including the load file name (or `{hostname} if
there's no load file), in the window title would improve it enough to meet my
use case.
Sign in to reply to this message.
On 2009/09/15 17:59:03, jdc wrote: > On 2009/09/15 16:24:51, rsc wrote: > > I'd rather not. > > As you like. It meets my need on the computers I use. Will I need to reapply > my patch each time I download a new version of plan9port which changes acme.c? > If so I'll write a little sam script to do so, but I guess keep it private. Mercurial MQ extension works really well for things like this. Once you have added your patches to MQ, you can hg qpop -a # unapply all MQ patches hg pull -u hg qpush -a # apply all MQ patches to update p9p to the latest version with your private patches applied.
Sign in to reply to this message.
Having thought about this for a week, I think the answer is to make -W accept an optional window name. I think the changes would be: * in $PLAN9/src/cmd/devdraw/winsize.c, make parsewinsize accept text after the final coordinate as the window title (a new parameter). * change the two calls to parsewinsize to let it override the label. * change intro(1) to document the new syntax for -W
Sign in to reply to this message.
On 2009/09/22 04:39:43, rsc_swtch wrote: > Having thought about this for a week, I think the answer is to > make -W accept an optional window name. I think the changes > would be: > > * in $PLAN9/src/cmd/devdraw/winsize.c, make parsewinsize > accept text after the final coordinate as the window title > (a new parameter). > > * change the two calls to parsewinsize to let it override the label. > > * change intro(1) to document the new syntax for -W jason, are you interested in doing this or have you moved on?
Sign in to reply to this message.
> jason, are you interested in doing this or have you moved on?
I've mostly moved on: I'm content with re-applying my change, and I have a bunch
of very specific information I record there. A bit of bookkeeping, things I
can't change about the environment in which acme started.
However, it occurs to me that the difficulty here is not so much that we need
user input and a more complicated command line, but that we need some way to
usefully tell apart acme sessions when we only have the window title to
distinguish them. This is the case in windowing systems which know no better
than to have a status bar, for instance.
To do this, we might gather some information available to acme when it starts.
Since an acme session is unique to a machine and a namespace, presenting these
two details might suffice to distinguish all the acme sessions a user can run.
For example, a title bar might look like the result of this echo (hostname first
because usually there's only one acme session per host).
echo acme `{hostname} `{namespace}
If the user loaded a file, we might report its basename as well, since that's no
doubt significant to the user.
echo acme `{basename loadfile} `{hostname} `{namespace}
This avoids option changes unique to acme, keeps acme as the first word in the
title for users who have only one session or don't care, and is an acceptable
replacement for me to the details I shove in there now.
Sign in to reply to this message.
my counter proposal (see the review log) was equally generic.
Sign in to reply to this message.
> my counter proposal (see the review log) was equally generic. To me your proposal is more generic, since you don't specify what the title should contain. This no doubt would please some, but Acme's had no user-supplied window title to date, so it obviously hasn't bothered (m)any other people. To me the "text after the window size" part feels a bit of a hack, like it works around not easily being able to add an option to all the programs (which happens to be true), and not wanting to complicate the command line or API (which is good design). My proposal provides additional information, for those who need it, with no additional effort on their part, and no changes to documents or the command line or code, other than the code just around where acme sets its title. It does complicate the window title itself, but that's the point.
Sign in to reply to this message.
no thanks - i don't want to change the default behavior.
Sign in to reply to this message.
On 2009/12/04 21:15:42, rsc wrote: > no thanks - i don't want to change the default behavior. Two further ideas, which don't change anything if only one acme runs, or if it doesn't load a file. These could even be used together if you felt generous. :) (1) It would complicate the implementation, but we could only print the extra information if acme finds that there's another namespace on the machine which also has acme. So your first acme would get "acme" in the title, and if that's all you ever used nothing would change for you. If you started another acme on the same machine, it would discover the other namespace with acme, and add the namespace to the title bar. If the namespace has the machine name or IP address, then we've also identified the machine. (2) Since I use load files a lot, I could distinguish between almost all sessions just by the load file's basename. So the title bar would have only one of two formats. If the user did not load a file, the title bar would contain just "acme", as it does today. If the user loaded a file, then this is already available inside acme (perhaps only a single quick function to strip it down to its basename), and the title bar would contain "acme loadfile". This is a change to the default behavior, but only if the user loads a file, and even then it's limited to one word, the basename of the loaded file, which would presumably have a high amount of meaning to the user.
Sign in to reply to this message.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
