LBRYCommunity/lbry-desktop
1
0
Fork 0
Code Issues 596 Pull requests 6 Projects Releases 238 Packages Wiki Activity

Fix glitchy follow button behaviour #2990

Closed
ICTman1076 wants to merge 4 commits from master into master
pull from: master
merge into: LBRYCommunity:master
Conversation 14 Commits 4 Files changed 2 +3
ICTman1076 commented 2019-10-06 19:32:56 +02:00 (Migrated from github.com)
Copy link

PR Checklist

Please check all that apply to this PR using "x":

  • I have checked that this PR is not a duplicate of an existing PR (open, closed or merged)
  • I have checked that this PR does not introduce a breaking change
  • This PR introduces breaking changes and I have provided a detailed explanation below

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting)
  • Refactoring (no functional changes)
  • Documentation changes
  • Other - Please describe:

Fixes

Issue Number: #2677

What is the current behavior?

Hovering over a very particular part of the button caused the text to change, which made the element smaller, which made it so you were no longer hovering over it, causing it to change to bigger text, which made it so you were hovering over it, causing a feedback loop and creating a glitchy visual bug.

What is the new behavior?

Now, the smaller text has a tiny bit of barely noticeable letter spacing, and the larger bit has had a tiny bit of letter spacing removed, to make the two states the same width, meaning the label remains the same size.

Other information

I made another PR previous to this one which may seem similar, but was actually broken because it added character spacing where it wasn't appropriate. I also fine-tuned the numbers in this one so that the width of the element doesn't just look the same width, but is the exact same width (with 3 d.p. accuracy).

## PR Checklist <!-- For the checkbox formatting to work properly, make sure there are no spaces on either side of the "x" --> Please check all that apply to this PR using "x": - [x] I have checked that this PR is not a duplicate of an existing PR (open, closed or merged) - [x] I have checked that this PR does not introduce a breaking change - [ ] This PR introduces breaking changes and I have provided a detailed explanation below ## PR Type What kind of change does this PR introduce? - [x] Bugfix - [ ] Feature - [ ] Code style update (formatting) - [ ] Refactoring (no functional changes) - [ ] Documentation changes - [ ] Other - Please describe: ## Fixes Issue Number: #2677 ## What is the current behavior? Hovering over a very particular part of the button caused the text to change, which made the element smaller, which made it so you were no longer hovering over it, causing it to change to bigger text, which made it so you were hovering over it, causing a feedback loop and creating a glitchy visual bug. ## What is the new behavior? Now, the smaller text has a tiny bit of barely noticeable letter spacing, and the larger bit has had a tiny bit of letter spacing removed, to make the two states the same width, meaning the label remains the same size. ## Other information I made another PR previous to this one which may seem similar, but was actually broken because it added character spacing where it wasn't appropriate. I also fine-tuned the numbers in this one so that the width of the element doesn't just look the same width, but is the exact same width (with 3 d.p. accuracy). <!-- If this PR contains a breaking change, please describe the impact and solution strategy for existing applications below. -->
neb-b commented 2019-10-07 04:36:16 +02:00 (Migrated from github.com)
Copy link

I tested and it looks a lot nicer. It doesn't work for non-english languages, but this is still an improvement. Can you add an note in this file? Then it's ready to merge.
https://github.com/lbryio/lbry-desktop/blob/master/CHANGELOG.md

I tested and it looks a lot nicer. It doesn't work for non-english languages, but this is still an improvement. Can you add an note in this file? Then it's ready to merge. https://github.com/lbryio/lbry-desktop/blob/master/CHANGELOG.md
👍 1
ICTman1076 commented 2019-10-07 08:35:47 +02:00 (Migrated from github.com)
Copy link

All done @seanyesmunt. I'll take a look into fine-tuning it for other languages, maybe even dynamically calculating the spacing if I can.

All done @seanyesmunt. I'll take a look into fine-tuning it for other languages, maybe even dynamically calculating the spacing if I can.
kauffj commented 2019-10-07 17:42:34 +02:00 (Migrated from github.com)
Copy link

@seanyesmunt @ICTman1076 this solution will not work for international users.

I believe a more general solution would be to render the button with all possible text, inspect the width of each render, then fix the width to the largest text.

@seanyesmunt @ICTman1076 this solution will not work for international users. I believe a more general solution would be to render the button with all possible text, inspect the width of each render, then fix the width to the largest text.
ICTman1076 commented 2019-10-07 18:38:12 +02:00 (Migrated from github.com)
Copy link

I just went through each of the languages currently available, and the problem is that the largest possible text is more than double of the smallest possible text. That would mean that you could have up to a whole character's worth of letter-spacing in between each letter, which would not look good. If you want a solution that works for all languages, you'll either have to ditch letter-spacing and set the width to a fixed width (which would then introduce lots of blank space which also wouldn't look great), or work out the exact letter spacing needed for each language, rather than just one for all languages, or use react to calculate it dynamically. I don't know how to do the latter in react, but I feel that would be the best option.
Here's a table of the widths of that element in hover and normal state for each language before this PR. I don't know if that helps, but you may as well see it

I just went through each of the languages currently available, and the problem is that the largest possible text is more than double of the smallest possible text. That would mean that you could have up to a whole character's worth of letter-spacing in between each letter, which would not look good. If you want a solution that works for all languages, you'll either have to ditch letter-spacing and set the width to a fixed width (which would then introduce lots of blank space which also wouldn't look great), or work out the exact letter spacing needed for each language, rather than just one for all languages, or use react to calculate it dynamically. I don't know how to do the latter in react, but I feel that would be the best option. [Here's a table of the widths of that element in hover and normal state for each language before this PR.](https://i.ibb.co/wMCKVtY/image.png) I don't know if that helps, but you may as well see it
ICTman1076 commented 2019-10-07 19:03:49 +02:00 (Migrated from github.com)
Copy link

Not sure why travis failed - there's been no code changes 🤔

Not sure why travis failed - there's been no code changes 🤔
neb-b commented 2019-10-08 15:42:53 +02:00 (Migrated from github.com)
Copy link

@kauffj I think that can end up looking worse than what we have currently, you can get large empty spaces with small text in the button. This at least fixes it for English, which is the majority of users.

@kauffj I think that can end up looking worse than what we have currently, you can get large empty spaces with small text in the button. This at least fixes it for English, which is the majority of users.
👍 1
tzarebczan commented 2019-10-10 21:11:32 +02:00 (Migrated from github.com)
Copy link

Will follow up via email, thanks again for the contribution!

Will follow up via email, thanks again for the contribution!
kauffj commented 2019-10-10 23:29:40 +02:00 (Migrated from github.com)
Copy link

@seanyesmunt I don't want to start a riff over something so minor, but I'm pretty disinclined to merge this.

To clarify my previous answer, I don't mean to calculate the width for all languages, I mean for the user's currently set language, calculate the width for just those two words, and fix it to the larger of the two.

Alternatively, come up with another design for this altogether.

@seanyesmunt I don't want to start a riff over something so minor, but I'm pretty disinclined to merge this. To clarify my previous answer, I don't mean to calculate the width for all languages, I mean for the user's currently set language, calculate the width for just those two words, and fix it to the larger of the two. Alternatively, come up with another design for this altogether.
neb-b commented 2019-10-14 16:50:32 +02:00 (Migrated from github.com)
Copy link

@ICTman1076 Do you think you would be able to implement the solution that @kauffj has suggested?

@ICTman1076 Do you think you would be able to implement the solution that @kauffj has suggested?
ICTman1076 commented 2019-10-14 19:56:50 +02:00 (Migrated from github.com)
Copy link

I can definitely take a look at the very least - I'm not sure it'll look great with some of the languages with a bigger difference in width between the two states, but I'll see what happens

I can definitely take a look at the very least - I'm not sure it'll look great with some of the languages with a bigger difference in width between the two states, but I'll see what happens
neb-b commented 2019-10-16 16:51:52 +02:00 (Migrated from github.com)
Copy link

@ICTman1076 instead of tracking the width of both buttons first, we could just calculate the width on the initial text and set the width of the button

Then once a user hovers and a new text shows up, if it's bigger than the current width, overwrite the saved with with this new larger width.

It could jump once, but nothing after that.

@ICTman1076 instead of tracking the width of both buttons first, we could just calculate the width on the initial text and set the width of the button Then once a user hovers and a new text shows up, if it's bigger than the current width, overwrite the saved with with this new larger width. It _could_ jump once, but nothing after that.
kauffj commented 2019-10-16 23:28:19 +02:00 (Migrated from github.com)
Copy link

👏 👏 👏 best idea yet @seanyesmunt!

:clap: :clap: :clap: best idea yet @seanyesmunt!
ICTman1076 commented 2019-10-27 19:36:28 +01:00 (Migrated from github.com)
Copy link

I'll give it a shot - I'm quite new to react so this may end up never happening, or done completely wrong, but it's worth an attempt lol
(sorry for the delay, been busy recently)

I'll give it a shot - I'm quite new to react so this may end up never happening, or done completely wrong, but it's worth an attempt lol (sorry for the delay, been busy recently)
🎉 1
neb-b commented 2019-11-19 22:29:30 +01:00 (Migrated from github.com)
Copy link

I'm going to close this. @ICTman1076 Feel free to re-open if you would like to keep working on it!

I'm going to close this. @ICTman1076 Feel free to re-open if you would like to keep working on it!

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
accessibility

   
app-parity

   
area: creator

   
area: daemon

   
area: design

   
area: devops

   
area: discovery

   
area: docs

   
area: installer

   
area: internal

   
area: livestream

   
area: performance

   
area: proposal

Work is part of a proposal

  
area: reposts

   
area: rewards

   
area: search

   
area: security

   
area: subscriptions

   
area: sync

   
area: ux

   
area: viewer

   
area: wallet

   
BEAMER

Beamer is waiting on you!

  
channel

   
comments

   
community PR

   
consider soon

Discuss this issue at the next planning meeting, then remove this label

  
core team

   
css

   
dependencies

   
electron

   
Epic

   
feature request

   
first-timers-only

   
good first issue

   
hacktoberfest

Welcome to Hacktoberfest

  
help wanted

   
hub-dependent

   
icebox

Long-term storage

  
Invalid

   
level: 0

   
level: 1

No knowledge of the existing code required

  
level: 2

Some knowledge of the existing code is recommended

  
level: 3

Significant knowledge of the existing code is recommended

  
level: 4

Intimate knowledge of the existing code is recommended

  
merge when green

   
needs: exploration

Solution unclear, needs research

  
needs: grooming

Issue needs to be groomed before work can start

  
needs: priority

Priority level needs to be defined

  
needs: repro

Issue needs step-by-step instructions on how to reproduce in latest code

  
needs: tech design

Needs technical design signoff before implementation can begin

  
notifications

   
odysee

   
on hold

Temporarily paused

  
playlists

   
priority: blocker

Issue is blocking release, do ASAP

  
priority: high

Work needs to be moved into sprint ASAP

  
priority: low

Work should be done but can stay in the backlog for now

  
priority: medium

Work needs to be done within 2-3 sprints

  
protocol dependent

   
recsys

   
redesign

general redesign not prioritize for anyone release

  
regression

   
resilience

   
sdk dependent

Requires work on lbry-sdk repo

  
Tom's Wishlist

   
trending

   
type: bug

Existing functionality is wrong or broken

  
type: discussion

A conversation. No specific changes requested

  
type: improvement

Existing (or partially existing) functionality needs to be changed

  
type: new feature

New functionality that does not exist yet

  
type: refactor

Minimal user-visible changes, but significant internal work

  
type: task

Either work that's not related to the code, or a small chore that does not fit into other categories

  
type: testing

Solution needs additional user testing

  
unplanned

Work that was not planned into the spirnt, took priority over planned work

  
windows
No labels
accessibility
app-parity
area: creator
area: daemon
area: design
area: devops
area: discovery
area: docs
area: installer
area: internal
area: livestream
area: performance
area: proposal
area: reposts
area: rewards
area: search
area: security
area: subscriptions
area: sync
area: ux
area: viewer
area: wallet
BEAMER
channel
comments
community PR
consider soon
core team
css
dependencies
electron
Epic
feature request
first-timers-only
good first issue
hacktoberfest
help wanted
hub-dependent
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
merge when green
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
notifications
odysee
on hold
playlists
priority: blocker
priority: high
priority: low
priority: medium
protocol dependent
recsys
redesign
regression
resilience
sdk dependent
Tom's Wishlist
trending
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
windows
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbry-desktop#2990
No description provided.
Delete branch "master"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?