Chat window patch

[Tank]

Hello everyone!

I've been playing OpenTTD in multiplayer a lot. Everytime I played, the in-game chat kinda annoyed me, because messages disappear automatically. There's the possibility to open the console and read the history, but I think it's not the way it should be done.

So I created a completely new chat messages window that uses the OpenTTD window system and provides a history for 50 lines of chat -- should be fairly enough. Also, messages do not disappear automatically. The window is automatically opened when a new message arrives. Using Ctrl+C, you can open and close the window quickly.

The attached screenshot shows the same chat window, but a bit scrolled in each.

Instructions
To make this work, you should use the latest SVN snapshot and be able to compile OpenTTD from the sources. I myself am using Linux -- in case you're under Windows, you should also know how to apply patches.

Save the .tar.gz (attached to this post) to the src/ directory and unpack it (e.g. tar -xvzf chat-patch-2.tar.gz). Now apply the patch using patch -p0 -i chat-patch-2.diff (or the method you prefer). Then recompile with make.

As an optional step you should change the chat message window dimensions in your openttd.cfg. Change network_chat_box_width and network_chat_box_height to more appropriate values. 380 for the width and 7 for the height are good values to start with. Note that the height value means lines, not pixels.

Translations
Currently the patch only contains translations for German and English languages. If you like the patch and want to use it in your language, add the language key STR_NETWORK_CHAT_WINDOW_CAPTION to the proper lang file and recompile.


Feel free to give feedback, would love to hear from you. =)

[audigex]

I'd prefer the shortcut to be something other than CTRL+C, for the simple reason that it's quite firmly ingrained that that stands for "copy" rather than "close"
Could it be mapped to something else, ctrl+enter perhaps.

[Tank]

Thanks for your reply.

Yes, Ctrl+C is mostly uncommon, since it's also associated with "Interrupt!" in Linux terminals. I thought Ctrl+C would be okay when you take the C as a "close". Ctrl+Enter sounds good to me. Maybe some other users can comment on this.

[Sacro]

Ctrl+W? Seems to be a fairly standard close window keypress.

[Zuu]

Isn't ctrl+enter already taken by team chat?

Ctrl + W sounds good to me.


Do you plan adding possibility to read backlog in the chat window? The problem you have is that you need to hook up global hotkeys for all actions which might not be desirable as they are a limited resource. The other option I can think of with trunk is to have one hotkey that opens a chat toolbar or something that has its window-hotkeys for the actions provided by the toolbar.

[Tank]

Ctrl+W really sounds good.

Indeed I've been thinking about the chat GUI in general. The current messages window isn't a real window compared to the GUI system that's used in OpenTTD. This could be changed to be a real window -- together with a close button. I guess it would be the most suitable solution, because you'll have advantages like a scrollbar for showing the chat history without going to the console or resizing the window on-the-fly without making changes to the config file.

What do you guys think of this idea?

[audigex]

What about an actual different window? So we can flick it to the background and alt-tab to it. A'la Continuum

[nicfer]

What about embedding it in the write message text form so when you press the Enter key a list with the recent messages appears above the text you are writting? If you want just to see the recent messages, you can simply press Enter, see what's been discussed and press again Enter to close the list.

[Tank]

audigex: I didn't get the point of that. Is that a separate program running?

nicfer: Actually not a bad idea, but what happens when a new message arrives? Pressing enter to read it sounds too complicated for me.

I've created a new window for displaying the chat for testing purposes. In my opinion this could be a good solution for reading current and older messages since a scrollbar can be used to view older messages. I attached a screenshot that shows how it looks like. The window is fully working except the scrollbar. Too late to continue.

[audigex]

I like it. Definately go with the sticky button, and will you be hiding the normal chat area when the window is open?

[Tank]

Yes, the old chat window is replaced by the new one completely. I think there's no need for the patch to keep the old window.

[Tank]

I actually completed the new chat window. Check out the first post in this thread to get it or see a screenshot.

[Zuu]

Looks nice, have you though about adding a resize widget and implementing resizing of the window. You can for example take a look on the sign list window how it is implemented there.

[Tank]

Yep, that was the plan at first. But when I took a deeper look into the code, I found out that wrapping text lines isn't that trivial. I think there's no function or method to wrap text on the fly depending on a fixed width and a maximum height (clipping). If I'm wrong, please correct me, and I'll implement resizing ASAP -- or if that really is a wanted feature, I could try to implement it myself.

[Zuu]

Okay then I understand why you have not made it resizable yet. Depending on how used you are to c-strings dealing with them can be quite tricky.

I quickly read through your patch and noticed that you write you write your '(' right after if, just as I do when I code my own programs. However in OpenTTD there should be a space between if and the bracket so it reads "if (". See the coding style document.

Code: Select all

+void ToggleChatWindow() {
+	Window *win = FindWindowById( WC_CHATMSG, 0 );
+	if( win ) {
+		delete win;
+	}
+	else {
+		ShowChatWindow();
+	}
+}

I'd recommend you to think over your goals. Is it to make a patch that implements a nice feature that some people will find nice enough that they will make their own compiled binaries with your patch and use, or if you aim for trunk inclusion. For the later you will be required to spend lot of time first polishing your patch, changing things that the devs think can be implemented in another way etc.

If you don't aim for trunk, complying with coding doc and making a good patch is still something nice, but you can be happy when you think you are done and be glad for the nice feedback you get from your users.

Think about what is your goal and how much time are you willing to spend on it.

[Tank]

At first, thank you for your reply.

Well, the primary goal was to eliminate my frustration against the chat messages window. Then I thought that there're maybe other users who also dislike it. So I published the patch. Of course it would be cool if it would make it into trunk, and yep, my coding style doesn't fit to the OpenTTD coding style. I've already taken a look at the wiki and would of course change the coding style of the patch if the devs/users think it should make it into trunk.

Before filing a ticket at the bugtracker, I'd like to get some more feedback, especially if this feature would be used by users. And of course if the devs think it actually can be merged into trunk.

Regarding to the resizing: On-the-fly wrapping of the lines can be definitely done. The question is if it's really needed, so if it's worth making the effort. Anyways, when you guys say "Yes, please!" then it's something I'd think about.

[Alberth]

Doesn't FormatStringLinebreaks() in gfx.cpp (line 586) do what you want?

[Tank]

It does wrap lines, yes, but it modifies the source string, which is bad in my case. When resizing the chat messages window, the messages themselves should be kept untouched. Imagine you change the size to a smaller one, which will wrap some text messages. Then you resize again to a larger size; the messages will still be wrapped. You had to remove all the newline characters.

A better function would be to draw lines which can be wrapped on the fly, so that the source strings aren't modified.

[Alberth]

What about splitting FormatStringLinebreaks() in two?
One function that computes where the next newline would be put, and another one that actually does that, and calls the former again with the remainder of the string.

Then you can use the first function too for wrapping without duplicating code.


(The other alternative may be to first make a copy of your string. Maybe as a first implementation this is not too bad, but you'd have to try it.)

[planetmaker]

Just as a remark and not in order to put off anyone: you are aware that the console offers a longer and more persistant backlog of the chat than what is shown ingame overprinted on the map? It's what I currently use, if I need to catch up on something... And it allows scrolling, too.