Hi guys

I made a Dockerfile for the lounge, based on Alpine linux. It's quite space saving

root@vps: ~ # docker ps -s --format "{{.Names}}: {{.Size}}"
w7pea_lounge: 4.013 kB (virtual **719.7 MB**)
alpine_lounge: 0 B (virtual **66.81 MB**)

It's here. I could make a pull request but I'm not sure where I should put that in thelounge sources?

Currently printed like: xPaw sets mode +o test, which would be better to be like xPaw has given channel operator to test

      "port": "1025",

that should be

      "port": 1025,

This code would be moved to templates: https://github.com/thelounge/lounge/blob/1e8ca51d47f78e30e8d429cfc164258386e0f5d7/client/js/lounge.js#L204-L215

This will allow for easier styling, and saner way of adding html elements where needed, for example when user changes his name currently its like <a>xPaw</a> changed their name to test, where test is not a clickable link as it should be. Plus, in the future where we will add hostmasks, we'd want them to be hideable by CSS if so desired.

One less library. And the data we store doesn't need to be in a cookie.

I imagine this might be a limitation with IRC, but if you are connected to something like ZNC, and you connect with another client and send a PM to someone, it doesn't go to thelounge so you end up with a very confusing looking history.

It might not be possibly to sort out, but worth bringing up.

https://github.com/Shuo-IRC/Shuo

Maybe @Xe and @floogulinc could help us, at least to list the missing pieces :-)

@xPaw's work on actions (erming/shout#588) is a huge improvement, but I noticed some issues/regressions that could be improved. Listing them here as they are all defects around the same subject:

• 1. When joining a channel, the statement to indicate the topic is "#channel has changed the topic to ...". This is only true when the topic is actually changed, when joining the wording should be different.
  

• 2. When colored nicknames are enabled in the settings, nicks in actions are not colored:

  Before	After

• 3. As shown by the previous screenshots, action are now in black. They should be displayed in gray as before to not get as much attention as normal message.

• 4. From the pre-Shout/The Lounge days I can remember, I think I used to see "[nick] has changed the topic..." instead of "[channel] has changed the topic...", i.e. is the nick that changed the topic last saved along with the topic? If so that's what should be displayed instead!

https://github.com/thelounge/lounge/blob/1e8ca51d47f78e30e8d429cfc164258386e0f5d7/client/js/lounge.js#L818-L825

This should just happened whenever a new message is received or something like that.

When being kicked out of a channel, the channel stays open. Then trying to close the channel is impossible, because it is emitting a /close event while the channel is not open on the server:

(Do not try to reproduce this on you normal running instance or you will have to restart the server to get rid of it.)

I would not want the channel to be closed by itself, because I might not want to lose the scrollback, and I would not know I was kicked out (since the channel would close instantly). Instead, the server should not try to quit the channel if not actually on this channel.

At the moment, /client/js/libs/jquery/bootstrap.js is only used for transitions and tooltips. Once #62 is complete, we should probably replace it with hint.css and CSS transitions or something

All's in the title, this is a feature request.

I can fold user list but not the left hand channel list. If I split my screen in half with something else, half of lounge is about channel names and message time. So I'ld like a button to fold it like user list.

We need to enforce consistent coding style within css files.

http://stylelint.io/

There are two solutions to this:

1. If we want to autocomplete on users that just joined/quit:
   • It needs to simply push newly added users into nicks, but instead, it overwrites the whole array.
2. If we don't want to push users that quit/joined into autocompletion:
   • Simply don't overwrite users data.

I'm more inclined towards the second option.

A message like &lt;<span will easily cause it to fail. <[color code here]test> will too.

It turns out log.js contains a call to moment().zone, which is deprecated. It should use moment().utcOffset instead, as per moment/moment#1779. Please stand by for PR.

Error
    at Moment.zone (/usr/local/lib/node_modules/thelounge/node_modules/moment/moment.js:850:105)
    at Object.module.exports.write (/usr/local/lib/node_modules/thelounge/src/log.js:19:22)
    at Client.emit (/usr/local/lib/node_modules/thelounge/src/client.js:90:9)
    at Client.<anonymous> (/usr/local/lib/node_modules/thelounge/src/plugins/irc-events/welcome.js:14:10)
    at Client.emit (events.js:129:20)
    at Client.<anonymous> (/usr/local/lib/node_modules/thelounge/node_modules/slate-irc/lib/plugins/welcome.js:14:11)
    at Client.emit (events.js:129:20)
    at Client.onmessage (/usr/local/lib/node_modules/thelounge/node_modules/slate-irc/index.js:386:8)
    at Parser.emit (events.js:107:17)
    at Parser.online (/usr/local/lib/node_modules/thelounge/node_modules/slate-irc-parser/index.js:88:8)

Update: pending PR -- #37

Would allow disabling notifications, joins/quits/kicks, etcetera per separate channel.
#9 adds a context menu that has a button for settings which will help with this.

FYI, I haven't looked to see how colors for the colored nicknames are handled.

However, in terms of UX, it's very noisy and insignificant to have a checkbox to enable colored nicknames.

This checkbox should be removed, enabling colored nicknames by default. Then, colors should be set in the CSS file (if it's not already the case) so that a theme can decide they want to disable colored nicknames by setting the same color for the whole range.
This also allows theme creators to have full control over the nickname colors (again, if it's not already the case).

the build task does not compile the file client/js/lounge.templates.js

running the command it is supposed to spawn manually does successfully compile the file which suggests that the task is not running at all when using grunt.

this is on Windows 10 with node.exe in the system PATH.

Add commands:

• /j alias for /join
• /list command erming/shout#635

So, thought I'd get a proper issue up for discussion on the module system that we will end up using.

There are 2 cases that we need to solve. These may use the same system, or they may use a different one.

1. Modularising the client

There are 2 parts to this: 3rd party libraries and lounge.js

Now, the next question is whether we want to be building this into 1 or 2 bundles, or whether we want to have them stay modularised, give thelounge http2 support and make that the default.

As a quick recap for those that don't know the difference between http 1.1 and http 2:

• http 1 can't download multiple files at once. Browsers have a hack to allow at most 10 to download simulataneously, because of this it is standard practice to concatenate as much as possible, and download as few files as possible, as this speeds it up
• http 2 has multiplexing and can download many, many files in parallel, and the standard practice for this is not concatenating, but keeping modules seperate as that speeds up downloading.

If you look at global http2 usage you'll see that >70% of people can use http 2. And if we focus on http2, http1 will still work, it'll just be a little slower than normal.

So, for us to decide what to do about modularising the client, we need to decide if we want to focus on http 1 or 2 just now.

2. Packages

So, @astorije brought up the point with me that it would be ideal to have a situation where a user can just install a new client package in thelounge and not need to reload the server to have it running. So, we need a way to dynamically include them on the browser (not needing a build step).

One option for this would be SystemJS, as that runs in the browser and allows you to include things programatically using any of the usual module systems.

With all of these, we then need to decide on what syntax of module we want to code in.

Personally, I would suggest that we code everything in the same module syntax, as that means that people don't have to learn 1 syntax for core features and 1 syntax for packages. Any of the systems we use (browserify, rollup, systemjs) all support both commonjs and ES6 modules.

Seeing as browsers will support ES6 modules in the future (none support it yet), and probably not commonjs modules, I would suggest using ES6. This also allows us to use tree shaking if we wish in the future.

So, we need to decide:

• Module syntax?
• Bundle client JS or not?
• If bundle, how many bundles?
• What to use to allow programmatic modules for packages?

Lots of issues, PRs, discussions and disagreements have an impact on settings. In this fork alone, I can mention #57, #70, #28, #49, #80, #44, #70, ... and we are only 2-week old!

This is only going to get worse as we improve theme management (or create theme management for that matter) and add packages, who will have their own settings, potentially affect existing settings, ...

Before we start adding dozens of settings to the current setting page, we need to discuss the long-term goals.

I have been building a mockup of the settings page slightly revisited. I propose we discuss its style, content, interactions, underlying structure, usability, ... (but the CSS/HTML is gross, this is just a mockup :P)
I will update the mockups as the discussion evolves.

One very important aspect is to keep user-friendliness as we evolve, or we will end up being a cluttered application as most IRC clients are. Defaults should be sensitively chosen to enhance the experience of any new user (of The Lounge or IRC altogether). Considering a private instance of The Lounge can be maintained by one administrator and used by many users, it's not crazy to think The Lounge may be used to introduce new folks to the IRC world :-)
Also, not everything should be a setting ("Better settings" does not mean "more and more settings" :p). Any UI-specific choice should ideally be the responsibility of a theme author, and may be overridden using custom styling.
However, advanced and very advanced users should be able to find happiness here too. When it comes to styling, a custom style field should give them the ability to make changes to a very fine-grained extent. We might want to be able to do the same thing for the settings overall: if all interactive elements for settings (checkbox, inputs, ...) match to an underlying data structure, some settings might be so advanced that they should be edited in a text field directly (like the custom styling, but for settings themselves). This might be an impractical idea after discussion, but focusing on keeping the UI slick and simple is key here.

Also, everything that appears on the settings page, apart from the profile section obviously, is device-specific. Therefore, everything should be stored in the localStorage and not be synced with the server. We could argue that some settings should be synced on the server and some should not, but that would lead to confusing settings and very difficult specificities to handle. I propose we start like this and improve with server sync later. Doing the other way around would prevent users to have different settings on different clients altogether, while this way allows for more freedom.

As packages will arise, they will come with their own settings. Packages should not mess with other packages' settings, so we might want to namespace/prefix them. For example:

general:
  showMode: true
  ...
emoticons:
  enabled: true
  ...

As core features move to separate (but officially supported / part of the GitHub org) packages, they need to fallback to their old name (example: general.notificationsEnabled -> notifications.enabled) to not affect existing users.
We need to decide if we want to allow packages to have their settings entries spread across the settings tabs or under a Settings button for each package.

That's all I got for now. It's rather long already, but praise my stupidity for having lost all my notes right before opening this issue!
I hope that you'll like my mockups and that we can peacefully discuss to reach consensus :-)

Example

Currently, newly added channels are just added to the bottom. This is quite strange, especially with private conversations inbetween.

Instead, in the first pass: All channels should be sorted first, and then private conversations. Sorted alphabetically.

In a second pass, we could sort the channels by the amount you use / message in them or something similar. That would make sorting more relevant.
For sure we can sort the private conversations to have the ones with the most recent message first. That’s how any mobile messenger like WhatsApp, Signal etc does it.

Early 2015 erming made 64 commits to a dev branch that never made it to master. The diff is at https://github.com/erming/shout/compare/dev.

It would be great to go through each of them and see what we can do with that.

Listing here all the commits, with the following legend:

1. Not looked at yet
2. Not interesting for The Lounge potentially with a very short explanation
3. Interesting for The Lounge, and either not cherry-picked/implemented yet or cherry-picked but not merged (add PR link)
4. Interested, cherry-picked and merged

Can someone help me with that? :-)

1. Cleaning up f66dab1
2. Cleaning up f9868bf
3. Update grunt build 3aa25b4
4. Code formatting 0091e0f
5. Add config 86317e1
6. Add travis 9bf9023
7. Add socket.io c012640
8. Render template 7d671da
9. Update config 122719b
10. Configurable root path 3e478c2
11. Update README.md 57663bb
12. Create lots of files d812357
13. Add models 48900eb
14. Add .editorconfig 8422020
15. Use tape 21c417f
16. Update cli 2888a26
17. Add templates e5a153a
18. Update grunt 73a5b11
19. Update grunt 1c3746c
20. Add event-emitter d8b7498
21. Add tests adb351c
22. Remove files c650c87
23. Add inputs 8af1aea
24. Add client class 27541a9
25. Update README.md 4db8f71
26. Add helper 9396368
27. Update help b7c93b3
28. Add manager bcccc04
29. Export cli commands 1ac5d30
30. Add files ac952b0
31. Add events fe42b59
32. Add events 1fe0946
33. Update README.md 8376f6b
34. Minor changes 3dc9444
35. Update README.md c68f7f4
36. Update lodash be1c2bd
37. Add message event e941f6b
38. Add mode event 6618f8f
39. Remove faucet 19c0396
40. Update mode event 82bf208
41. Add motd event 286be74
42. Add names event 397935a
43. Add nick event b00ac6f
44. Add notice event 224e7c0
45. Add part event bd0b66a
46. Add quit event 67e4677
47. Add topic event 58b294b
48. Add welcome event d693344
49. Add whois event c70871a
50. Update README.md 1de5fc6
51. Add command-line tests eb68a78
52. Add init command 1567548
53. Add glob package c037e88
54. Update config 569385d
55. Implement 'shout init' cli command f2af49e
56. Add cli commands 84e5dcd
57. Add start page 4fc9f47
58. Add login ea89d2f
59. Add connect page 8cc7b6a
60. Refactoring 91ccd88
61. Add client connect 226a110
62. Fix broken tests after fresh install 4ecc3b2
63. Rename function for creating new users 1920b59
64. Update lodash template 34e1016

Can be based on erming/shout#382

Currently most of the code is in a single file with a lot of anonymous functions. Anon functions make it harder to debug/view stacktraces when analyzing stuff. Having a neat structure where each element is in a separate namespace/scope would be preferred.

Currently we don't have a date separator. So either in PM's or channels when we see a message we don't know if it was sent today or 10 days earlier.

We can't add this kind of information to a mouseover information box for the date info due to adding more burden to the script either

So, I think at least a HR or similar line separating messages when a new day starts would be good.

for example, if you send {color color green}http://example.com, the link will remain blue, not green as dictated by the color code.

I'm thinking we should have:

#chat a {
    color: inherit;
    text-decoration: inherit;
}

This will make links match color of the text in all cases. Which is not a bad idea, as links won't be as eye catchy.

I occasionally see my connection dropped, but it does not say which connection.
From the log: "Error: This socket has been ended by the other party"

Would be better to identify which of the connections was dropped, preferably by the display name of the connection as it appears in the left pane.

Currently it's xPaw says:, change it to xPaw (#shout-irc) says:

This should only happen if target is a channel, and not a query window.

Useful for Lounge's demo instance, and admins that plan on running a public server.

This needs to disable ip/port fields (and possibly SSL?), and also completely ignore sent values on the server, and always use config defaults (to prevent editing shenanigans).

The user list on the right is most of the time correctly sorted, except when a user joins the channel. For example:

It looks like something as simple as clicking on another open channel and going back to it re-sorts the list, but not right when the user joins.

Using tab to auto-complete a name doesn't just complete names from users in the channel, but it also completes names from users you have a private conversation open with. Investigating now

Actions have the sender's nickname to the right of the bar which separates nicknames and messages.

When an Action contains a Highlight, the action displays correctly except the nickname appears to the left of the aforementioned bar.

Here's an example

(Here's an example from the other side, courtesy of IRC user vectr0n)

This is likely a minor fix to move the name back across the bar. I would also encourage changing the color to the red highlight color. The placement of the nick and the star icon both clearly indicate that it's an Action, but nothing indicates that it's a Highlight except the sound and badge. I believe we would be better served by having Actions that contain Highlights appear red.

Show all info on server chan instead of just motd and notice messages.

PS: The good snipping tool!

Discussion continued from #48:

Just a thought, what if he got rid of that close button completely? It would avoid accidentally clicking it while trying to focus the channel. There's already a dedicated Leave button when channel is in focus, and #9 adds a way to close channel in a context menu.

Add host info for people who join a chan,

v0l (v0@ip) has joined

Also add quit messages

• All connection messages should be shown in server window
• Use exponential back off
• Do not reconnect on errors like "bad password"
• Re-join all previous channels
• Existing chan.id must be reused for networks/channels/query windows when reconnecting to maintain history.

So, irccloud has a nice feature where it shows you pastebin text in the chat as a preview sort of thing. That would be quite nice. Probably would have to limit it, and I'm not sure if there's an easy way to tell when soemthing is a pastebin (Rather than just like supporting different pastebins individually) but something interesting to look into. Would be really nice.

This code: https://github.com/thelounge/lounge/blob/f87d605b53332a3478eed8efaa676337971c510f/client/js/lounge.js#L228-L247

That click event needs to be bound globally instead of binding it for every message.

I would like to keep the codebase smaller but not having extra font files.

Crypto uses Inconsolata-g, Morning and Zenburn use Open Sans. The default font, which is Lato, is not bad by any means and is a good default for all these themes.

This should simplify things for #80

https://github.com/kiwiirc/irc-framework

@prawnsalad is working on a new framework for use in his Kiwi IRC client, and has suggested that combining efforts would be a good idea towards better clients altogether.

slate-irc is practically dead, and would require a lot of work to add many of the features that are already supported in irc-framework (mostly IRCv3 stuff, including SASL, server-time and others.)

This line specifically: https://github.com/thelounge/lounge/blob/2201e2b941bd13427c38d6934b84ceda245aa20e/src/client.js#L69-L71

This would mean that restarting the server wouldn't require users to re-login.

For example:

1. Hide user list.
2. Restart the client.
3. User list is now visible, but if the visibility state was saved, it would stay hidden.

We currently only use it once in /client/js/libs/handlebars/parse.js, we can probably create our own function or find one online that doesn't require a whole library to use.

Couldn't summarize this well in the title, sorry.

So I connect to my ZNC through Lounge. This works great! However...if I need to restart Lounge for whatever reason, when I launch it again and sign in via the web...I have no logs waiting for me when I get back.

If I use a dedicated client like Hexchat, I can see everything that happened in ZNC when I get back. Lounge seems to actually log me out of every server/channel on ZNC until I relaunch Lounge or ZNC attempts auto-reconnects.

Not sure if this is a configuration issue on my side, a bug, or a feature I need to be requesting. Whichever it is, then...please advise. :)

https://developer.mozilla.org/en-US/docs/Web/Manifest

Example file: https://github.com/SteamDatabase/steamstat.us/blob/gh-pages/manifest.json

Currently the button is only visible on mobile devices, however it could be desirable to hide channels on desktop too.