See reddit for example

Alt+[0-9] might not be the best keyboard shortcut to switch between buffers. With my usual keymap (Canadian French), the @ character is entered with right Alt+2, so I cannot input a @ now.

Unless there's a way to differentiate between left and right Alt, we should change this ASAP because it's very annoying.

Long messages of one single word without whitespaces create an horizontal scrollbar (doesn't wrap).

CSS3's word-wrap: break-word should help.

Somehow visually highlight the line if the user's nickname or one of the hotwords was contained in it to make it easier to spot

Example:
https://www.dropbox.com/s/pzn35c8armj14g6/Screenshot%202013-10-28%2013.41.30.png

When you receive a (private/targeted) message and you're not focussing on the buffer that created the event (be it because you're looking at a different buffer or because you're in a different browser tab), make the title reflect this event like Gmail and Facebook do.

Is the following behaviour desired after the following sequence?

WeeChat already has unread notifications.

1. connect to glowing-bear; you see the notifications count for each buffer
2. click on every buffer with a notification count and it disappears
3. disconnect from glowing-bear
4. connect to glowing-bear

Notification counts are still there.

When there are too many buffer names, an horizontal scrollbar appears and we cannot see all of them until we scroll.

Suggestion: could the buffers be on the right side, sorted somehow, with the possibility of showing/hiding the whole column?

Media contents is shown within a "Show additional content" box right now.

Users could prefer other display modes:

• inline with the text flow
• when hovering the URL that triggered the content embedding
• in a separate column

Plugins could, for each message, actively register additional contents (HTML) in the current context so that, once the plugin system has called every plugin, it can put this contents wherever the user wants to.

Something like:

function myPluginOnChatMessage(context) {
    if (content.getRawMessage().match(/.../)) {
        context.addMediaContents({ ... });
    }
}

Implement a nick list, ideally in a right column, for IRC buffers.

Set monospace font for all monospace text for the following because it looks better, more modern, but is generally not the browser default:

• Linux : Ubuntu Mono
• Windows : Consolas
• OS X : Monaco

I don't believe WeeChat relays share this information in general, but at least for nicks, this would be possible since we have the nick list.

Expected behaviour when users meow and mix exist (~ means space here because GitHub is swallowing all my spaces):

Caret is at the very beginning of the input textbox. Type m then press Tab, autocompletes for meow:~. Press Tab again, changes meow:~ for mix:~. Press Tab again, goes back to meow:~. Caret is always set after :~ in all those situations.

When caret is elsewhere, same behaviour, but without :.

Actually, sending <foo> won't work, because ng-bind-html on the bufferline sanitizes the content first. The text from the user input needs to be (html) escaped before sending it.

The app should support responsive web design. IMO this is must-have feature, to feel confortable with any window size.

Depending on the browser size, the buffer and nick lists can be displayed/hidden.
For instance, the app is known to work on a tablet, it'd be great to hide the buffer list on portrait mode and display it on landscape mode.

Implement command history, per buffer, with up and down arrows going back/forward in the history.

Steps:

1. open WeeChat
2. connect to it with glowing-bear
3. close WeeChat (glowing-bear is disconnected)
4. open WeeChat again
5. connect to it with glowing-bear

The buffers are all duplicated. This is wrong.

The main buffer view, when full, currently creates a scrollbar for the whole page, whereas it should create a scrollbar for its own viewport and leave the fixed input bar at the bottom.

Why not fixing the input bar using display: fixed?

This is a suggestion to add support for various themes.

A theme would be a single CSS file (which may be the result of several LESS/SASS files, see #20) that controls pretty much all the look of this application:

• background color
• fonts
• connection page look
• preferences page look (if it exists)
• list of buffers look and position (left/right/top should all be easily possible)
• nick list look and position
• input bar style (and possibility of hiding the Send button)
• main buffer view look

I guess the CSS file location could be modified in the preferences to apply a theme instantly without downloading anything manually (saved in local storage).

@vivien won't like me for this, but having color schemes could be an option too, for instance if someone wants more pastelish colors instead of the default, oversaturated ones of terminals which are hurting my fragile eyes. In my defense, you can do exactly this with popular terminal emulators like GNOME terminal, urxvt, Terminator or PuTTY. Here's a screenshot:

See? Yes, if you set the red as green here, grep will output matches in green. People like me usually prefer schemes like Solarized because we're not using VT-100s like @vivien.

So to make this really easy for theme designers, very simple classes should be attached to strategic elements. The designer should also be aware of the "default state" of the application look, i.e. the reset values when no theme is applied. This is important because, for example if the core's CSS forces an element's line-height to 150%, whereas the browser default is usually normal, the designer will need to manually force it back to normal to retrieve the default value (or use a reset sheet).

We don't want this to become like old MySpace CSS "skins".

The core CSS should only be used for things that a theme should never change, like rules to force the input bar at the bottom and have a buffer view that takes all the viewport's height.

Title says enough.

Buffer view is for the moment as large as possible, making long messages very large if the browser is maximized.

I suggest we put a reasonable max-width on the view.

It would be nice to be able to type as soon as we click on a buffer name to view it.

When focusing on a buffer (e.g. when reading it), we should send a /buffer <name> (e.g. /buffer irc.freenode.#weechat-fr) in order to replicate the focus on weechat-curses and by this way clear the buffer from the hot list (this will remove the notification on weechat-curses).

To have an efficient usage of this app, if could add 2 new keybindings:

Alt+b to focus on the buffer list search input, and Alt+Space (not sure about that one yet) to focus on the message input bar. This last once is useful when we previously clicked in the buffer and thus loose the focus.

Add a page of user preferences, saved/loaded to/from local storage.

We will need to figure out what should be controlled by the user preferences. Things like suffix for nick completion, chosen theme, display mode of media contents, etc.

When trying to connect to the WeeChat relay with a wrong hostname/port, no error message is displayed but the console outputs Relay error undefined.

I'm currently not able to identify where the problem come from, but somethime i have to reload the index page to be able to receive data from weechat after pressing the connect button, else the page is empty like if i put a wrong password

Channels might be sorted by irc server.
Maybe Like :

• FREENODE
  • #toto
  • #tata
• FREENODE2
  • #toto

Also, user could sort channels like he wants (drag and drop ???)

Thanks !

WeeChat (and most chat clients) usually look like this:

00:19:03  -- | Mode ##unavailable [+FPcmnt]                          
00:19:03  -- | Channel created on Thu, 30 Mar 2006 07:52:16          
00:21:06 <-- | coderhs ([email protected]) has quit (Ping timeout: 
             | 264 seconds)                                          
00:21:34 --> | HannahLittleLady                                      
             | (414a56a6@gateway/web/freenode/ip.65.74.86.166) has   
             | joined ##unavailable                                  
00:22:17 <-- | HannahLittleLady                                      
             | (414a56a6@gateway/web/freenode/ip.65.74.86.166) has   
             | quit (Client Quit)                                    

00:12:27  someone | hi there 
00:12:33     eepp | oh hi  
00:14:20  someone | how are you doin'  
00:14:35     eepp | couldn't be better 

There's a clear left column where nicks, timestamps and some symbols are put while the actual text is left-aligned in another column.

This project currently doesn't do this, making it more difficult for the eye to follow a conversation.

Add various keyboard shortcuts which can be found in WeeChat, like switching from a buffer to another.

For some reason, there's sometimes black text that looks invisible on a dark background.

When a message matches a plugin and this message contains /nfsw/i, override the user/core setting and make the additional content collapsed.

This implies some brainstorming and refactoring of the plugins architecture: for instance, the settings should be per instance of additional content, not per plugin.

Write a plugin to support Asciinema embedding.

See this.

The scrolling function runs before all images in the buffer is loaded so the scrolling will be initially correct, but then images are loaded it is wrong.

Any url (good luck to find the killer url matching regex) should be displayed as a valid href, instead of being a plugin (previously implemented by @tmatth on #2).

Suggestion: add a disconnect button to send a quit message to WeeChat and go back to the connection landing page.

Buffers do not appear or strange bugs happen intermittently when connecting or at random times. We lose the connection with WeeChat, or it doesn't seem to sync anymore.

Use models as a layer of abstraction between weechat commands and the controllers

Playing with z-index doesn't seem to change anything, at least on Chromium/Linux.

As the CSS file is growing, using SASS or LESS would ensure a better and more maintainable structure.

This is somehow hard to reproduce, but:

1. connect using a wrong port number (or wrong host)
2. immediately connect using the correct infos.

Then, it's possible that the error caused by 1 fires after 2, which goes back to the login screen even if you successfully connected. I actually experienced that: I saw the buffers and everything, and then it went back to the login screen because I tried with a wrong port the first time.

I guess, once connected, that all connection errors should be ignored.

Optionally play sound on notifications when not focussing?

When connecting, a wrong password displays no message.

You just don't know what's going on. Your whole world seems to be falling down. And then you realize that people you've known forever don't see things the way you do. And then you die.

Plugins should be written as separate JS files, in js/plugins/ for example.

We may use javico.js to display notification count.
http://lab.ejci.net/favico.js/

Suggestion to show permanently somewhere, once connected, the connected host:port. Something like "Connected to 192.168.50.33:1234".

Messages should be preformatted, without collapsing whitespaces, to mimic most IRC clients, including WeeChat.

When you resize your browser windows and decrease the width, on low width size the channel content disappear and the channel list take all the windows.

In the same way, if the channel topic is bigger then the windows width, the topic will overwrite the channel content.

Project needs minimal documentation on how to setup a functional websocket relay

The page should inform the user on the minimum required version of WeeChat. And maybe check and validate it?
If I'm not mistaken this is 0.4.2.