-
Notifications
You must be signed in to change notification settings - Fork 271
Conversation
<label class="opt"> | ||
<input id="badge" type="checkbox" name="badge"> | ||
Enable badge | ||
</label> | ||
</div> | ||
<div class="col-sm-12"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you remove these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I've changed slightly how the settings page is organised, because otherwise having an input with a label ended up making the other side have a blank line.
Will post screenshots later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't that be better to do in a further PR? I mean, the rest of the PR is definitely wanted (granted, after some more back-and-forth) but UI stuff is usually more opinionated and might delay, even for a few days. I prefer small and split PRs that can be merged quickly, avoiding author frustration :-)
But your call if you think it cannot be split.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've changed it back to what it was before and it works like I would have expected it to, which is odd. So I've reverted this.
Edit: actually, was editing the wrong repository. The problem with keeping them on col-sm-12 is that we end up with this:
If we do it the way I've dne it, we get this:
If you think that there will be lots of discussion over the new format, then I'll take it out. But I really don't like how it looks in the first place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a strong opinion on this. (However I find it ugly whatever the solution but that's not your fault)
I'm fine with that so you can keep your change, but at some point, when we properly discuss configuration (or even before that), a UX/UI pass on the settings page will be much appreciated!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think both of them are ugly, but I prefer it after my change. So if no one else has a big objection, I'll keep that in this PR.
Yeah, we really should look at the UI/UX of the settings in general. Could be done in conjunction with adding server syncing (we could have optional overrides for individual clients for example).
But let's leave that to the other discussion. I'll add an issue if no one else has.
Hey @YaManicKill, thanks for this great contribution!
I wonder. It's probably nice to have a way to set them differently on desktop and mobile (although mobiles don't support notifications very well so far), but it might also be a pain to set them individually on all devices/browsers.
What are you planning to do exactly? Can't wait to have this merged in! :-) A nice idea for a future PR could be a tag input such as this but this is waaay off the topic of this PR! |
Alrighty. I think it's something we should probably look into allowing certain settings to copy across browsers, but I'm happy to keep this without that just now, as it's not that difficult to copy them over different machines manually. But not ideal in the long run.
Just I'm not happy with the placement of the highlights input. I'll post screenshots probably tomorrow once I've recovered from my business trip. |
Agreed, but you live to fight for another day :-) Also, this needs some design and decision making (to make sure we have the best possible UX), and I don't want to delay this PR for something not directly related. But clearly I agree with you! |
Awesome! I can't wait but no pressure, I can't promise I'll be always be able to review on time anyway. |
Ok, I've updated with the changes you suggested, let me know if you think it's in a mergable state now :-) |
@@ -382,6 +386,20 @@ $(function() { | |||
} | |||
} | |||
|
|||
if ($.cookie("highlights") !== null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use the existing settings
cookie object, it will be easier to switch to another storage method in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, what do you think @YaManicKill?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think this would be the best way to do things. I've done this in #603, let me know what you think about how it's done there. I can just do it the same way.
Hey @YaManicKill, great, that looks very good! One minor comment away, but nothing big. |
I'll update this this weekend with the settings change I made in #603 (not doing this in a seperate cookie) and we can hopefully get it merged before the fork. |
Alright, that should be this in a good state to merge, I think. I've changed how we do the saving of the setting, so it saves in the same cookie, and now the saving and reading from the cookie works for more than just checkboxes. Let me know if there's anything else, but I think this should be good. |
@YaManicKill, care to move this to https://github.com/thelounge/lounge? Ultimately this could be a package in itself, but since it's already in a working condition, why not. |
Oh yeah, of course. I'll get this ported over this evening. |
A couple of issues with this PR still.
But thought I'd stick it up now to see what people think.