Oh right, it's the CORS not allowing the custom font to be loaded from Google fonts so it falls back to a wider one for me which results in the navbar overflow.
2020-05-19 14030, 2020
yvanzo
how broken?
2020-05-19 14005, 2020
Leo_Verto uploaded an image: image.png (90KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/GDIEVzlVbgOmrtmPxhfaSBFe >
2020-05-19 14009, 2020
Leo_Verto
Eh, not very. Just a bit of overflow.
2020-05-19 14058, 2020
Leo_Verto
But I'm not quite sure where I'm getting that same-origin header from. Might be a Firefox setting to default to that if nothing else is explicitly set.
2020-05-19 14048, 2020
Mr_Monkey
Leo_Verto: I'm not getting a CORS issue on Brave, Chrome or the latest version of Firefox. Are you on https:// ?
2020-05-19 14043, 2020
Leo_Verto
Yeah and I'm seeing the same behaviour on Chromium, might be something related to my particular setup.
2020-05-19 14027, 2020
reosarevok
Did anyone get their subscription email yet?
2020-05-19 14038, 2020
reosarevok
Wondering if that cron process didn't get turned on or if it's just slow today :)
anyway can you upload some iamges ot that ticket, sicne it's relevant
2020-05-19 14052, 2020
CatQuest
and it'be be sad if those ideas got lost in the chatlogs
2020-05-19 14015, 2020
CatQuest
you had some very nice ideas and I personally loved it
2020-05-19 14029, 2020
c1e0
Sure. I'll upload them in a while.
2020-05-19 14030, 2020
CatQuest
you'll remember that most everyone here wer epossitive to it
2020-05-19 14031, 2020
CatQuest
yay!
2020-05-19 14053, 2020
c1e0
I intend to design more badges over time. We'll see :)
2020-05-19 14058, 2020
CatQuest
coool!
2020-05-19 14032, 2020
v6lur_ joined the channel
2020-05-19 14054, 2020
c1e0 has quit
2020-05-19 14058, 2020
shivam-kapila
ruaok: Hey. Plz ping me when you are ready to give the project a kickstart :)
2020-05-19 14054, 2020
diru1100
Mo"in' !
2020-05-19 14001, 2020
samj1912 has quit
2020-05-19 14036, 2020
supersandro20000 has quit
2020-05-19 14002, 2020
supersandro2000 joined the channel
2020-05-19 14000, 2020
ruaok
shivam-kapila: hi!
2020-05-19 14024, 2020
shivam-kapila
Hey
2020-05-19 14041, 2020
ruaok
I've been thinking on where to start and there are a lot of things to consider.
2020-05-19 14042, 2020
shivam-kapila
Hm. What would you suggest to begin with?
2020-05-19 14029, 2020
ruaok
well, lets see. timescale needs to be my key focus this week. I think I've got a way forward, but I need to chat to alastair about it.
2020-05-19 14008, 2020
ruaok
the dashboard rework is going to be a bit more involved to plan, because with the changed focus it touches the work of Mr_Monkey as well as ishaanshah[m].
2020-05-19 14043, 2020
shivam-kapila
Yeah. I am also working on a rough UI mockup sideways to integrate all this with uniformity
2020-05-19 14051, 2020
ruaok
I feel that we should have a group chat about the UI bits to see how we can all work on related things without getting in each others ways.
2020-05-19 14003, 2020
shivam-kapila
Agreed
2020-05-19 14011, 2020
ruaok
exactly. and Mr_Monkey is working on brainzplayer, but not so much the UI.
2020-05-19 14035, 2020
ruaok
but he's quite good designing UI, so I'd like him to keep at least an eye on our work.
2020-05-19 14009, 2020
Mr_Monkey opens an eye
2020-05-19 14016, 2020
ruaok
but the more I think about it, the less I want to dive right into that -- I think we should stick to the schedule, at least for now.
2020-05-19 14031, 2020
shivam-kapila
BrainzPlayer ought to have a special reserved place in the UI which I am still thinking on. The player postion I suggested might need a change or some tweeks to keep it responsive
2020-05-19 14057, 2020
ruaok
Mr_Monkey: hola. part of shivam-kapila's project is to redo the user profile view, which is intertwined with brainzplayer.
2020-05-19 14000, 2020
ruaok
before too long I would love to have a chat, with at least you, shivam-kapila and myself. possibly even ishaanshah[m] and iliekcomputers.
2020-05-19 14008, 2020
Mr_Monkey
Sure
2020-05-19 14027, 2020
ruaok
later this week might be good. I need to get a few things off my plate in the meantime.
2020-05-19 14056, 2020
ruaok
shivam-kapila: let's start with the love/hate feature, in a branch off the timescale-rebased branch.
2020-05-19 14014, 2020
shivam-kapila
Okay
2020-05-19 14038, 2020
ruaok
my focus there is to re-work how the data is loaded for the listens page. but I think I will have a clear path forward after I chat with alastairp .
2020-05-19 14010, 2020
shivam-kapila
To lessen the so observed lag?
2020-05-19 14034, 2020
ruaok
yes. I reviewed it this morning and there is a lot of silly shit going on. which worked fine in influx, but less so in postgres.
2020-05-19 14055, 2020
shivam-kapila
Oh
2020-05-19 14000, 2020
ruaok
the fetching of min/max timestamps in order to decide pagination is clear a problem. :)
2020-05-19 14034, 2020
shivam-kapila
I had opened a ticket to redefine pagination too with a suggestive measure
2020-05-19 14035, 2020
ruaok
and I personally think that people are not really going to do a lot of paging between listen pages.
2020-05-19 14049, 2020
ruaok
shivam-kapila: yes, you can close that. we're not changing the approach. trust me.
2020-05-19 14003, 2020
shivam-kapila
Ok. Will do
2020-05-19 14034, 2020
ruaok
mainly because paging through listens is not a key feature. and my proposed changes will only affect people with few listens.
2020-05-19 14023, 2020
ruaok
let's start like this:
2020-05-19 14037, 2020
ruaok
1. create a new branch based off timescale-rebased.
2020-05-19 14014, 2020
ruaok
2. implement the database changes needed to implement the love/hate feature.
the idea is that when we release, we run the update script and start an updated container and then the love/hate feature will be live.
2020-05-19 14042, 2020
ruaok
by keeping a separate branch of just the UI changes, we keep our flexibility as to when we release the DB change parts.
2020-05-19 14009, 2020
shivam-kapila
+1 to that.
2020-05-19 14010, 2020
ruaok
I suspect that we may want to do them at the same time we make the switch to timescale. maybe not. we'll have to see, but for now lets keep it flexible.
2020-05-19 14045, 2020
ruaok
then next steps will be making the python module to access the new table. then the API parts.
2020-05-19 14058, 2020
ruaok
each one should be a separate PR, ok?
2020-05-19 14011, 2020
shivam-kapila
Yes. Understood
2020-05-19 14018, 2020
ruaok
that should be enough for 1 day of work, yes?
2020-05-19 14037, 2020
shivam-kapila
I guess so
2020-05-19 14056, 2020
shivam-kapila
I needed to ask something about the schema.
2020-05-19 14004, 2020
ruaok
i'll be around for the next most of the afternoon, I just need to make/eat lunch.
2020-05-19 14021, 2020
ruaok
let try and answer it now.
2020-05-19 14025, 2020
ruaok
otherwise after lunch
2020-05-19 14012, 2020
shivam-kapila
So I have suggested a schema `rating(user_name, recording_msid, score, created)`
2020-05-19 14047, 2020
shivam-kapila
I suspect we will also need to add an `additional_info` or `track_metadata`
2020-05-19 14002, 2020
ruaok
yes to the second part.
2020-05-19 14010, 2020
ruaok
the first part... not sure I like the naming.
2020-05-19 14020, 2020
ruaok
it isn't a rating -- we have 5 star ratings that we call ratings.
2020-05-19 14032, 2020
ruaok
I would actually call the table what we're calling the feature: lovehate
look at the files in the admin/sql dir to see how to make these changes. just follow suit.
2020-05-19 14007, 2020
shivam-kapila
Okay
2020-05-19 14021, 2020
ruaok
but the track_metadata and all that, its not the current focus -- we're focusing on the DB right now.
2020-05-19 14034, 2020
ruaok
so dont worry about that now, it could just lead to messy PRs
2020-05-19 14002, 2020
shivam-kapila
So I should add the column currently or leave it for now?
2020-05-19 14012, 2020
ruaok
which column?
2020-05-19 14019, 2020
shivam-kapila
track_metadata
2020-05-19 14051, 2020
iliekcomputers
messybrainz probably stores what you need already
2020-05-19 14056, 2020
ruaok
that is something that does into the JSON for sending listens to clients, no?
2020-05-19 14028, 2020
ruaok is confused what track_metadata is used for and what the question is
2020-05-19 14006, 2020
shivam-kapila
Its more pretaining to frontend
2020-05-19 14018, 2020
shivam-kapila
Let me explain with an example
2020-05-19 14018, 2020
ruaok
ok, out of scope for now.
2020-05-19 14023, 2020
ruaok
ok
2020-05-19 14059, 2020
shivam-kapila
Suppose I like a listen. The entries we store will be (user_name, recording_msid, score, created)
2020-05-19 14020, 2020
shivam-kapila
Now in actual we liked a recording and not a listen.
2020-05-19 14008, 2020
shivam-kapila
So we would want all the listens for that recording in front end update to liked when I like only 1 listen
2020-05-19 14014, 2020
shivam-kapila
So we would need to make a comparision to track name(more suitable in this case) so that all listens corresponding to a recording are liked when in actuall we liked only one listen
2020-05-19 14026, 2020
shivam-kapila
and stored the record also once only
2020-05-19 14057, 2020
shivam-kapila
Did I make myself clear or I messed up?
2020-05-19 14012, 2020
ruaok
yes, this gets very tricky -- because of mapping MSIDs to MBIDs and all of that.
2020-05-19 14040, 2020
shivam-kapila
Yes I would agree to that.
2020-05-19 14000, 2020
ruaok
I'm very much still working and thinking on that -- for now we don't need to worry about that and simple implement the feature that likes/hates a listen. leave the translation to a recording for later.
