[Terminal] Add a menu option to allow the user to give the terminal a custom name

[scottmc]

It would be nice to be able to rename a terminal window something more useful than "Terminal 1", "Terminal 2", etc. Seems to me there's a way to do this from a command line? Even if there is, it would still be nice to be able to click on the terminal window and find an option to rename it and then type a new name for it in. I often find myself with 3+ terminals open at the same time and I forget which terminal was doing what.

[scottmc]

The way to set the name from the command line is: Terminal -t "New window name" & not sure if there's a way to rename it after it's running though.

[bonefish]

In r25987 I reenabled support for setting the window title. You can do that via:

echo -e '\E]0;WindowTitle\a'

[hey68you]

contains 4 files (3 header and 2 source).

[hey68you]

I've just added a patch for the GUI aspect of this enhancement. It contains 2 new files:

SetTitleDlg.cpp SetTitleDlg.h

It also modifies 3 existing files: TermWindow.cpp TermWindow.h TermConst.h

In TermWindow.h, it was required to change the member function _ActiveTermView() of the TermWindow class from 'private' to 'public'

Is that ok?

Please note that this is my first patch or contribution to Haiku so please let me know how I've done good or bad.

Regards, hey68you

[stippi]

Please never attach .zips, since those cannot be read within the bug tracker. Could you please re-attach the patch as is?

[scottmc]

applied patch and tried to build but got this error during jam:

Link generated/objects/haiku/x86/release/apps/terminal/Terminal 
generated/objects/haiku/x86/release/apps/terminal/TermWindow.o: In function `TermWindow::SetTitleRequested(void)':
TermWindow.cpp:(.text+0x3447): undefined reference to `SetTitleDlg::SetTitleDlg(BRect, TermWindow *)'

[monni]

Looks like you forgot to update Jamfile to include added source file

[scottmc]

fixed diff file, had to add SetTitleDlg.cpp to the Jamfile

[scottmc]

Replying to monni:

Looks like you forgot to update Jamfile to include added source file

Yeah that was it, updated terminal.diff file attached.

[hey68you]

I just reattached the 2 new files (too fix my bad indents to be tabs).

I don't have over-write privileges.

[stippi]

Thanks! I deleted the original patches for you.

[scottmc]

This patch works well enough to satisfy the original ticket. The renaming of tabs is a bit quirky though, as if you have more than one tab the tab name gets updated when you open a new tab. In gnome's terminal the current window name and the current tab match, but I suspect that's a different issue as it happens with the echo -e '\E]0;WindowTitle\a' as well. Also the terminal menu with the Set Title... perhaps could use a horizontal line about it?

[hey68you]

I think that the new updated file ("TermWindow.cpp") should fix that quirkiness described by scottmc above.

Now the tab name is immediately updated upon pressing the ok button on the new dialog that I added in the patch above (or when you enter the "echo -e .." at the command line.

What the change does is to just call the tabview's invalidate method which forces the redraw of the tab label immediately. (Where as before it didn't get redrawn until the tab lost focus).

[stippi]

Hm. Such problems should rather be fixed in the respective classes. BTab in this instance.

[hey68you]

Hi Stephan,

Then this bug seems to exist on BeOS R5 also ( as I found the problem there too and compiled my patches on R5 which fixes the problem).

Anyway, does this mean I (or somebody else) should enter a separate bug?

Regards, hey68you

[stippi]

I may be confused how you change the name of a BTab. IIRC, you have to change the name of the child view, correct? In that case, invalidating the BTab is fine. If there is some SetName() method, then it should take care of invalidating itself, no matter if the BeOS version forgot to do it.

[stippi]

Oh, I mean if there is a BTab::SetName() method...

[hey68you]

If I'm not mistaken I think we do need to invalidate the container BTabView (i.e. it's not a bug). Quoting the BeBook:

SetLabel()    
Can be augmented to take notice when the tab's label is changed. You should always call the inherited version of the function before your 
implementation returns. 

The existing Terminal code doesn't have an augmented version of the BTab::SetLabel() method which I assume would do the invalidating of the BTabview container view upon noticing a new text for the label.

So is it ok that I'm calling fTabView->Invalidate() on my own straight after modifying the label text using the un-augmented BTab::SetLabel() method ???

[scottmc]

any updates to report on this one?

[heto]

Looking at BTab, it has no way of knowing which BTabView it belongs to, so it can't invalidate it. Therefore I assume that the application is supposed to do the invalidation, as I don't think the BTab can go just draw itself when the label is changed.

I'll attach a patch that fixes the update issue with echo -e '\E]2;title\a'. Compared to the file posted earlier, it only invalidates the region that belongs to the tab whose title just got updated, which should reduce flicker and avoid re-drawing the whole tabview. It also doesn't lock the window as I don't think this is required with invalidate.

With regards to the original suggestion, I think an in-place renaming by double-clicking the tab is a more sensible option than a menu option and a dialog. I'll see if I can implement this in the couple following days.

[heto]

fix the issue of the tab not updating when a command-line application changes its label

[heto]

implement in-place renaming of tabs by double-clicking the tab

[heto]

That patch implements renaming the tabs by double-clicking a tab. After that a BTextControl gets created on the tab, so the user can type in a new name. Once that control is invoked (because the user pressed return or changed focus), the control is removed, the new title is set, and the focus is set back to the terminal view.

[stippi]

The new patch goes into a neat direction, and thanks for the cleanup! I've implemented something similar with a popup window for another project. The popup window has the benefit that the control can grow outside the window boundaries. Thanks a lot for your work!

[hey68you]

Nice work. I hope my code, even though it won't be used in the end, was helpful in some way.

However, does anyone think that my implementation (a menu option and a dialog) would also be useful (i.e. how does a user know to double-click to change the title?)?

...By the way, the menu-option is given in both gnome-Terminal and konsole (kde) - not that we're competing with them :)

[hey68you]

...on second thought...

We really do need the menu-option also to fulfill this ticket because there is no way to change the title via the GUI when there is just a single session (no tab to double-click upon).

[leavengood]

I have looked at and tested the patch from heto and I agree with hey68you that there is still a need for a menu item and dialog for a single session Terminal window. I may investigate trying to combine these patches in a nice way.

I will therefore also take ownership of this ticket.

[scottmc]

any progress on this one Ryan?

[leavengood]

Well I did apply the patch from heto as I said, but it had some bugs and as I said we probably still need a menu item and a dialog box. I was thinking of combining these patches by having the dialog box just become a hovering edit box over the terminal title in the double-click case, and a normal dialog box when the menu item is clicked. But that might be too complicated.

Another issue is I think the whole terminal window and terminal tab naming needs to be combined. Basically instead of a Terminal 1 with with a Shell 1 and Shell 2 tab, and then a Terminal 2 window with another Shell 1 and Shell 2 tab, it would be a Terminal 1 window with a Terminal 1 and Terminal 2 tab (and the title would change with tab selection) and then a Terminal 3 and 4 tab in the other window.

Anyhow because all this is very much new features, I don't want to worry about it before the alpha 1 release. Even though I promised hey68you I would try to get some of his patch in alpha 1, it will have to wait until alpha 2. Of course I don't know how much of his patch will remain with the changes I want to make ;)