Opened 11 years ago

Closed 9 years ago

Last modified 9 years ago

#2389 closed enhancement (fixed)

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

Reported by: scottmc Owned by: bonefish
Priority: low Milestone: R1
Component: Applications/Terminal Version: R1/Development
Keywords: Cc: rossi@…, henrimoi@…
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description

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.

Attachments (7)

hey68you_GUI_patch_for_Terminal_App_#2389.zip (14.7 KB) - added by hey68you 10 years ago.
contains 4 files (3 header and 2 source).
terminal.diff (4.2 KB) - added by scottmc 10 years ago.
fixed diff file, had to add SetTitleDlg.cpp to the Jamfile
SetTitleDlg.2.cpp (1.8 KB) - added by hey68you 10 years ago.
SetTitleDlg.2.h (641 bytes) - added by hey68you 10 years ago.
TermWindow.cpp (24.0 KB) - added by hey68you 10 years ago.
update-tab.diff (495 bytes) - added by heto 10 years ago.
fix the issue of the tab not updating when a command-line application changes its label
rename-tab.diff (7.3 KB) - added by heto 10 years ago.
implement in-place renaming of tabs by double-clicking the tab

Download all attachments as: .zip

Change History (38)

comment:1 Changed 11 years ago by 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.

comment:2 Changed 11 years ago by bonefish

Priority: normallow

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

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

comment:3 Changed 10 years ago by rossi

Cc: rossi@… added

Changed 10 years ago by hey68you

contains 4 files (3 header and 2 source).

comment:4 Changed 10 years ago by 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

comment:5 Changed 10 years ago by stippi

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

comment:6 Changed 10 years ago by 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 *)'

comment:7 Changed 10 years ago by monni

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

Changed 10 years ago by scottmc

Attachment: terminal.diff added

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

comment:8 in reply to:  7 Changed 10 years ago by 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.

Changed 10 years ago by hey68you

Attachment: SetTitleDlg.2.cpp added

Changed 10 years ago by hey68you

Attachment: SetTitleDlg.2.h added

comment:9 Changed 10 years ago by hey68you

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

I don't have over-write privileges.

comment:10 Changed 10 years ago by stippi

Thanks! I deleted the original patches for you.

comment:11 Changed 10 years ago by 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?

Changed 10 years ago by hey68you

Attachment: TermWindow.cpp added

comment:12 Changed 10 years ago by 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).

comment:13 Changed 10 years ago by stippi

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

comment:14 Changed 10 years ago by 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

comment:15 Changed 10 years ago by 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.

comment:16 Changed 10 years ago by stippi

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

comment:17 Changed 10 years ago by 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 ???

comment:18 Changed 10 years ago by scottmc

any updates to report on this one?

comment:19 Changed 10 years ago by heto

Cc: henrimoi@… added

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.

Changed 10 years ago by heto

Attachment: update-tab.diff added

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

Changed 10 years ago by heto

Attachment: rename-tab.diff added

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

comment:20 Changed 10 years ago by 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.

comment:21 Changed 10 years ago by 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!

comment:22 Changed 10 years ago by 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 :)

comment:23 Changed 10 years ago by 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).

comment:24 Changed 10 years ago by leavengood

Owner: changed from jackburton to 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.

comment:25 Changed 10 years ago by scottmc

any progress on this one Ryan?

comment:26 Changed 10 years ago by 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 ;)

comment:27 Changed 9 years ago by mmadia

Has a Patch: set

comment:28 Changed 9 years ago by bonefish

Owner: changed from leavengood to bonefish
Status: newin-progress
Version: R1/pre-alpha1R1/Development

Looking into this.

comment:29 in reply to:  28 Changed 9 years ago by leavengood

Replying to bonefish:

Looking into this.

Thanks Ingo. I think my concerns from that comment above are still valid so maybe you can take that into account and sort things out as far as terminal window and tab naming.

comment:30 Changed 9 years ago by bonefish

Resolution: fixed
Status: in-progressclosed

Fully implemented around hrev39513.

comment:31 Changed 9 years ago by scottmc

nicely done.

Note: See TracTickets for help on using tickets.