Minor redesign (css) #647
No reviewers
Labels
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
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbry-desktop#647
Loading…
Reference in a new issue
No description provided.
Delete branch "css_patch"
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?
Changes
A bunch of minor
CSS
fixes and additional changes.Fixes
Additional changes
Todo
@kauffj I re-open this because -> #639 would take a while to get merged,
You can merge this right now 🙃
This is a really great and deep change set that has got me only more excited for the next design!
Some detailed feedback and questions below.
@ -9,9 +9,14 @@ Web UI version numbers should always match the corresponding version of LBRY App
## [Unreleased]
### Added
* Add setting to automatically purchase low-cost content without a confirmation dialog
* New custom styled scrollbar (#574)
I like overall style and that it doesn't overlap header, but can it be wider and/or get wider on hover?
I understand the text is selected to make this copyable, but it also gives the user an implication that they can type in this field. Can we somehow express/provide both?
I agree we ought to make a change here to give a stronger indication how to open these.
But what if the change should just be to match card behavior of discover page? These card elements are really quite similar, so we should just be consistent in the effect/UI we provide.
@ -9,3 +9,3 @@
color: var(--text-color);
font-family: 'Source Sans Pro', sans-serif;
font-family: 'Roboto', sans-serif;
line-height: var(--font-line-height);
Bold move. Is this to move us inline with MD? Or do you just think this is appropriate font?
@ -16,7 +15,19 @@ $height-file-tile: $spacing-vertical * 6;
padding-top: $spacing-vertical * 1/3;
margin-left: $height-file-tile + $spacing-vertical / 2;
}
I'm not sure we need to retain this if we match the behavior of discover, but if there is a new styling here specific to
file-tile__row
, we ought to make it a BEM class name and dropmeta
.Does this need to be abstracted?
Would consider making this a little larger?
@ -0,0 +1,57 @@
/* Tabs */
nav.sub-header
Like this element!
I think this change added underlining to text button icons (e.g. the ones in
FileActions
). I think this can look poor with some icons, so should just be avoided.@ -9,3 +9,3 @@
color: var(--text-color);
font-family: 'Source Sans Pro', sans-serif;
font-family: 'Roboto', sans-serif;
line-height: var(--font-line-height);
lbry it's already usign
MD
so yes I think it's appropriate.Ok I was just testing / experimenting with some stuff but yeah I'll remove it
@ -16,7 +15,19 @@ $height-file-tile: $spacing-vertical * 6;
padding-top: $spacing-vertical * 1/3;
margin-left: $height-file-tile + $spacing-vertical / 2;
}
Ok, I'll remove it, this was just a simple experiment 👍
Ok ^
ok, I'll revert this, but at least header can't have underline text 🙃
@ -9,3 +9,3 @@
color: var(--text-color);
font-family: 'Source Sans Pro', sans-serif;
font-family: 'Roboto', sans-serif;
line-height: var(--font-line-height);
This PR isn't dropping
MD
, but instead doing some enhancement to it,this would probably change when we implement the @nizuka01
design
Agree, but a tile and a card are two different things...
Would you considering removing the
uri
from the tile component ?we could add a menu / or a set of actions to the tile component...
a small button
Get uri
orShare
@kauffj ? ^
IMO looks better (more clean) without the uri:
Note
This component needs a set of actions (edit, remove, share...)
As an user I would like to have a section to manage all my claims ( downloaded / published ),
currently I only can edit or remove if I go to claim page, the app needs to be more flexible with this.
Also this is a must thing to have if we ever integrate a
Bookmarks
/Watch-list
featureMore notes
I don't think the user should be allowed to type a directory / file, it's better letting the file dialog handle this to ensure that the file / directory exists, considering the current validation system...
😛
@ -9,9 +9,14 @@ Web UI version numbers should always match the corresponding version of LBRY App
## [Unreleased]
### Added
* Add setting to automatically purchase low-cost content without a confirmation dialog
* New custom styled scrollbar (#574)
Ok, increased the size, if users start to report some problems with this
I'll make it more wider, but I think it's ok for now
I was unclear; I agree users should not be allowed to type in this field.
Is there a style we can apply that indicates BOTH copyable AND readonly?
@btzr-io I am fine with dropping the URI from
FileTile
. It would actually probably be pretty easy to add inFileActions
to those cards... not sure if that's actually a good idea or not.@kauffj I'm still confused about the support behavior:
Do we actually need to support our own claims ?
Note
There are too many buttons in
fileActions
,I guess is time to bring back the
menu
component or do something smart 😛Duplicated content
@btzr-io I think
dd8ab64
could cause user confusion ("why is the support button missing on my content?")And yes... let's fix FileActions!
I merged this, since it's a clear step up from the current app. I opened two issues regarding outstanding changes that I think are still worth making:
https://github.com/lbryio/lbry-app/issues/656
https://github.com/lbryio/lbry-app/issues/657