Display profile fields #2271

Closed
kphrx wants to merge 0 commits from gitlab-mr-iid-1004 into develop
Member

refs #149

  • Rebasing after merge the #2262.
refs #149 * [x] Rebasing after merge the #2262.
Owner

please use classnames instead of tags

please use classnames instead of tags
Owner

this could use a text-align: right, some users have field names set to single emoji which makes whole thing ugly.

this could use a `text-align: right`, some users have field names set to single emoji which makes whole thing ugly.
Owner

i feel like this is superfluous, just leave fields_html one

i feel like this is superfluous, just leave `fields_html` one
Owner

both of them could use a :title="user.fields[index].name (or .value obviously) if field data overflows there's no way to read it fully.

otherwise might make text use multiple lines instead of eliding it.

both of them could use a `:title="user.fields[index].name` (or `.value` obviously) if field data overflows there's no way to read it fully. otherwise might make text use multiple lines instead of eliding it.
Author
Member

Added d2e334da

Added d2e334da
Author
Member
a15baa89
Author
Member

Added bfdf7c87

Added bfdf7c87
Author
Member

Replaced 87940ead

Replaced 87940ead
Owner

checking in on this

checking in on this
Owner

looks fine to me, ready to merge @kPherox ? I'm a bit lost with what the merge order should be with many profile field related things

looks fine to me, ready to merge @kPherox ? I'm a bit lost with what the merge order should be with many profile field related things
Author
Member

#2271 and #2264 should not affect each other. So I think any merge order is okey.

#2271 and #2264 should not affect each other. So I think any merge order is okey.
Author
Member

TypeError is thrown because remote account's source fields is empty array. Need to convert fields to plain text in frontend or backend.

`TypeError` is thrown because remote account's source fields is empty array. Need to convert fields to plain text in frontend or backend.
Author
Member

Fixed 064b5981

Fixed 064b5981
Owner

what's this, again?

what's this, again?
Owner

i think we already have an html sanitizer in place

i think we already have an html sanitizer in place
Author
Member

fields_text for tooltip of fields.

Currently, pleroma backend doesn't have source fields for remote users, and local users can use html tags in fields. So I thought it was necessary for plain text.

`fields_text` for tooltip of fields. Currently, pleroma backend doesn't have source fields for remote users, and local users can use html tags in fields. So I thought it was necessary for plain text.
Owner

use escape-html, it should be used elsewhere in the file

use `escape-html`, it should be used elsewhere in the file

Don't know if this is a problem of recent changes in the frontend, but this looks a bit weird / out of place at them moment with develop merged in.

Screenshot_2020-06-15_dontbulling_me

Don't know if this is a problem of recent changes in the frontend, but this looks a bit weird / out of place at them moment with develop merged in. ![Screenshot_2020-06-15_dontbulling_me](/attachments/d78db264-a30a-46ed-abd4-88a3b256f75d)
Owner

does a completely different thing, what we want is <a>shpposter.club</a> becoming shpposter.club and not &lt;a&gt;shpposter.club&lt;/a&gt;

does a completely different thing, what we want is `<a>shpposter.club</a>` becoming `shpposter.club` and not `&lt;a&gt;shpposter.club&lt;/a&gt;`
Owner

doesn't look like it, we have unescape and escape and html processor, but not something that just strips the tags

doesn't look like it, we have unescape and escape and html processor, but not something that just strips the tags
Owner

it's not really a problem, that's just how it looks like when you have shorter entries. here's what it looks like "in the wild"

image

it's not really a problem, that's just how it looks like when you have shorter entries. here's what it looks like "in the wild" ![image](/attachments/75b38615-852b-424a-947f-649816a99e6c)
132 KiB

True, looks more sensible with longer entries.

True, looks more sensible with longer entries.

Why does this need to be stripped anyway?

Why does this need to be stripped anyway?
Owner

the title attribute wants a plaintext version of it, the actual field value will still use emojified html

the title attribute wants a plaintext version of it, the actual field value will still use emojified html
Owner

I'm looking into it a bit to see if it can be made nicer, it's a bit awkward on mobile

I'm looking into it a bit to see if it can be made nicer, it's a bit awkward on mobile
Owner

image

what do you think of this?

![image](/attachments/ac3e1263-08dc-4ef0-b05f-919a6129ad88) what do you think of this?
214 KiB

I like it more than the original, makes it clearer that these are profile fields and not just some random text floating around

I like it more than the original, makes it clearer that these are profile fields and not just some random text floating around
Owner

works decent on mobile too I guess, picture with longer fields

localhost_8080_users_9gOkLxPxM19NQGrII4_iPhone_5_SE_

works decent on mobile too I guess, picture with longer fields ![localhost_8080_users_9gOkLxPxM19NQGrII4_iPhone_5_SE_](/attachments/b9c6cbe4-6343-47c6-b313-6443677020d7)
Owner

I'll make a new MR with the modifications, since I can't push into @kPherox's branches, but I think it should be just about done

I'll make a new MR with the modifications, since I can't push into @kPherox's branches, but I think it should be just about done
Author
Member

I has set to allow commits from members who can merge into the target branch, but doesn't work it?

I has set to allow commits from members who can merge into the target branch, but doesn't work it?
Owner

ah, I didn't know that's possible! no need for that then

ah, I didn't know that's possible! no need for that then
Owner

it kinda looks bad but then again the feature itself is kinda shit anyway, can't win.

it kinda looks bad but then again the feature itself is kinda shit anyway, can't win.
Owner

very constructive thank you

very constructive thank you

The 'allow commits form members' thing does work, but it's a bit annoying to use. I gave you developer access, @kPherox, so you can just branch in the main repo next time so this is easier.

The 'allow commits form members' thing does work, but it's a bit annoying to use. I gave you developer access, @kPherox, so you can just branch in the main repo next time so this is easier.
Owner

somehow figured out how to push local changes to remote branch, I'm a git pro now

somehow figured out how to push local changes to remote branch, I'm a git pro now
Owner

added unescape so that &gt; will be > in the text fields like it should

added unescape so that `&gt;` will be `>` in the text fields like it should

LGTM

LGTM
Owner

sorry i really don't have much to add right now, i am however thinking about full profile redesign and how to make it more consistent and eye-pleasing overall. More presentable.

Fields don't really fit in there but then barely anything fits. I can at least say that frames are somewhat better than what was before

sorry i really don't have much to add right now, i am however thinking about full profile redesign and how to make it more consistent and eye-pleasing overall. More presentable. Fields don't really fit in there but then barely anything fits. I can at least say that frames are somewhat better than what was before
Owner

LGTM too

LGTM too

yay

yay
Owner

Kind of a nitpick: I think it's a bit weird to have this kind of separation between the key and the value, I think joining the border between the key and value would be better, I guess this would mean a table instead of a definition list.

Kind of a nitpick: I think it's a bit weird to have this kind of separation between the key and the value, I think joining the border between the key and value would be better, I guess this would mean a table instead of a definition list.
Author
Member

I think a definition list is a better way to express a profile fields, so I'll try adjusting the css so that the key-value looks like one.

I think a definition list is a better way to express a profile fields, so I'll try adjusting the css so that the key-value looks like one.
Owner

I started doing that originally but the css was getting ugly, figured it's clear enough when you never have more than two columns and with the text alignment it'd still be clear as day

I started doing that originally but the css was getting ugly, figured it's clear enough when you never have more than two columns and with the text alignment it'd still be clear as day

I'd rather get this in now and play with the css later, otherwise this will wait around for another 6 months...

I'd rather get this in now and play with the css later, otherwise this will wait around for another 6 months...
Author
Member

before: 632f62ee
Screen_Shot_2020-06-18_at_20.01.37

after: eed58a7b
image

before: 632f62ee ![Screen_Shot_2020-06-18_at_20.01.37](/attachments/05d402be-0471-46a9-bf00-85106748e5a3) after: eed58a7b ![image](/attachments/dba969ec-70d0-4854-8297-ca576243286c)
Owner

looks better in 99% cases, but on chrome it creates 1px gaps between the separating line and top/bottom lines on some zoom levels which is the issue I encountered with the approach when trying it out

however I don't think it's big enough of a deal to block the merge request if people prefer this look

image

looks better in 99% cases, but on chrome it creates 1px gaps between the separating line and top/bottom lines on some zoom levels which is the issue I encountered with the approach when trying it out however I don't think it's big enough of a deal to block the merge request if people prefer this look ![image](/attachments/8bdf8a14-9ce7-4667-9de5-4246ae6dc079)

The new one does indeed look better. I only noticed the gap because i knew where to look :) I think this is ready.

The new one does indeed look better. I only noticed the gap because i knew where to look :) I think this is ready.
Owner

random idea: how about this layout:
image

random idea: how about this layout: ![image](/attachments/8c6c8941-09dd-49b8-ad1c-07566113a1e7)
Owner

don't bother I'd say, it'd be a way to make it look even more one sided and cramped

don't bother I'd say, it'd be a way to make it look even more one sided and cramped
Owner

at least it won't cut off the the field "key"

at least it won't cut off the the field "key"

Just for comparison, here is how soapbox and mastodon do it:

###Soapbox:

Screenshot_2020-06-18__1__lain_mastodon_online_lain_com_1_

###Mastodon:

Screenshot_2020-06-18_Mastodon

Just for comparison, here is how soapbox and mastodon do it: ###Soapbox: ![Screenshot_2020-06-18__1__lain_mastodon_online_lain_com_1_](/attachments/e457dbf9-c882-43c7-957f-edf164c03d21) ###Mastodon: ![Screenshot_2020-06-18_Mastodon](/attachments/2ff865d9-f973-4561-93dd-62b4fe938ebb)
Owner

keeping them short is a good idea regardless, unless you want to encourage people to set them to lengths that are cut off in mastodon. the min width of the key column is set to this width consciously

keeping them short is a good idea regardless, unless you want to encourage people to set them to lengths that are cut off in mastodon. the min width of the key column is set to this width consciously

yeah, long keys are possible but lead to display problems on pretty much every client

yeah, long keys are possible but lead to display problems on pretty much every client
Owner

Well, looks good to me 👍

Well, looks good to me 👍

I like!

I like!
Owner

merging it finally, further improvements in further MRs mmkay

merging it finally, further improvements in further MRs mmkay

Pull request closed

Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
7 participants
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
pleroma/pleroma-fe!2271
No description provided.