Add Brave Browser - Githubissues

horzadome commented 5 years ago

Alternative to syncing each Brave version individually, we could also sync them all at once because they're all in $XDG_CONFIG_HOME/BraveSoftware and have the same process name.

horzadome commented 5 years ago

note, I've seen #175 , but it appears that they fixed cache location and it's in .cache now

graysky2 commented 5 years ago

Since the modular design allows for users to make their own configs as you have, I'm at a point where I don't want to add more officially supported browsers due to the overhead associated with maintaining them.

ryanerwin commented 5 years ago

I was easily able to sync my Brave Browser profile by copying the /usr/lib/psd/browsers/chromium file as you suggested in #207

1) Is there a way to store our custom browser configs inside ~/.config/psd? When I move my profile to another machine, it's easy to forget to move some custom files in /usr/lib/...

2) Would be great to update the documentation page and the github README with a note about how to add support for custom browsers

Ennoia11 commented 5 years ago

+1

Alexander-Shukaev commented 4 years ago

Not sure why it is such a pain to merge this PR. What does it cost you really?

graysky2 commented 4 years ago

Not sure why it is such a pain to merge this PR. What does it cost you really?

It's pain when something breaks if things with the browser change and then I have to go digging to figure out why. Why is it such a pain for you to just use the drop-in you created?

Alexander-Shukaev commented 4 years ago

Why is it such a pain for you to just use the drop-in you created?

Have to modify /usr/share/ for that, which is not how system customizations are supposed to be done.

I don't think you should put a burden like this on yourself alone. You could for example, also have an additional directory to pull those browser files from, e.g. /usr/share/psd/contrib/browsers/. For those you'd not be responsible but rather their active users, someone will always pop up an fix stuff when it breaks, it's not rocket science in the end of the day. Otherwise, #271 also looks promising.

However, without either of these happening, it's cumbersome to deal with new additions at the moment. Just for the record, my /usr is always mounted as read-only. There could be other restrictions such as permissions.

graysky2 commented 4 years ago

I like the idea of providing a contrib dir, but it would be up to the user to manually copy one to /usr/share/psd/ ... this is no different than other software providing code as such.

My point is as stated:

It's pain when something breaks if things with the browser change and then I have to go digging to figure out why. Why is it such a pain for you to just use the drop-in you created?

Alexander-Shukaev commented 4 years ago

My point was to rather have /usr/share/psd/contrib/browsers/ installed as part of the stock distribution of this package. Then it's up to the user whether to use browsers defined there or not (also given the potential stability notice) as per their custom configuration. Thus, no need to tamper with /usr/share/.

graysky2 commented 4 years ago

@Alexander-Shukaev - OK, that is what I plan to do, thanks for this suggestion

Alexander-Shukaev commented 4 years ago

@graysky2, that's great! Glad to assist.

felipec commented 3 years ago

My point was to rather have /usr/share/psd/contrib/browsers/ installed as part of the stock distribution of this package. Then it's up to the user whether to use browsers defined there or not (also given the potential stability notice) as per their custom configuration.

But /usr/share is not a location a user is supposed to modify. Only ~/.local/share/.

Alexander-Shukaev commented 3 years ago

But /usr/share is not a location a user is supposed to modify. Only ~/.local/share/.

We know that. Modifying browser templates has little value as the configuration they carry is static. I understand that you insist on having a user directory to put your custom templates in, I do also agree that this could be useful and is Unix-friendly behavior. However, in the end of the day, just having most (all?) the browser templates coming from the official package is also not bad. The current approach just motivates one to contribute any new browser here, have it reviewed, merged, and then packaged as part of whatever Linux distribution. Why should everyone have their own (likely exactly identical) definition of brave browser in ~/.local/share/, WTF?

horzadome commented 3 years ago

Why should everyone have their own (likely exactly identical) definition of brave browser in ~/.local/share/, WTF?

Though I agree that it would be cool to nudge people to contribute, I'm more of a "give them options" kinda BOFH. Not all users have admin privileges, this is a per-user service, so it might be good practice to enable non-admin users to create configs. Maybe leave a little readme there to nudge them to contribute or something.

felipec commented 3 years ago

However, in the end of the day, just having most (all?) the browser templates coming from the official package is also not bad.

Nobody is suggesting to remove that functionality (have you looked at the patches?).

The current approach just motivates one to contribute any new browser here, have it reviewed, merged, and then packaged as part of whatever Linux distribution.

Wrong. @graysky2 said he doesn't want to that any more: quote "I'm at a point where I don't want to add more officially supported browsers".

Why should everyone have their own (likely exactly identical) definition of brave browser in ~/.local/share/, WTF?

Because 1) @graysky2 refuses to make the configuration official, and 2) users are not supposed to modify /usr/share.

At the end of the day the important question is this: why are you opposed to giving users more options?

graysky2 / profile-sync-daemon

Add Brave Browser #240