AsciiJakob / NoDistractions

Simple, bloat-free website blocker with a focus on intuitiveness
https://addons.mozilla.org/en-US/firefox/addon/nodistractions-website-blocker/
MIT License
3 stars 1 forks source link

Feature request: Remember status on browser startup #4

Closed tuurep closed 2 months ago

tuurep commented 4 months ago

Hi! I love your extension, it's almost ideal for what I'm trying to do with a 'distracting website blocker'.

I have one fundamental issue though: I tend to close and reopen firefox constantly, and would like the addon to stay at the same status it was when I last closed.

However right now the settings only allow either starting disabled every time, or enabled every time.

Do you think this is solvable?

tuurep commented 3 months ago

I implemented this in a fork, here:

https://github.com/tuurep/NoDistractions-fork/commit/2703934d0758e20cecb31a79f48653f4df23093e

I want to contribute if you're interested, but:

tuurep commented 3 months ago

I'm now happy with what I've added in the fork:

https://addons.mozilla.org/en-US/firefox/addon/nodistractions-fork/

Let me know if the added features look like something you might want to add, and if you want to combine efforts.

AsciiJakob commented 2 months ago

Hi! I love your extension, it's almost ideal for what I'm trying to do with a 'distracting website blocker'.

That's awesome to hear! This is the only project I have where people have actually given me positive feedback and which feels like it has really brought more goodness into the world. It always really makes me motivated. Lately I've just been messing about with writing lower level programs that don't really serve any purpose just for fun - websites and extensions actually end up with users, though, and that is really awesome, even if it means I might have to write css xD.

I tend to close and reopen firefox constantly, and would like the addon to stay at the same status it was when I last closed.

That sounds like a reasonable feature suggestion. I personally never close my browser so this is not something I have sought after, but I totally see why this would be useful for users like you.

Do you think this is solvable?

Absolutely!

I had an issue where every time I make a change to a file, an "end of file newline" gets added so it creates a diff

This sounds like a classic Unix vs Windows problem. I think it's related to CRLF versus LF, which are different End of Line sequences. Pretty sure you should be able to change which one is used in your editor; my Visual Studio Code is using CRLF for the project. Though I find it a little worrying that your editor is not automatically detecting which End of Line sequence is used, it feels like that should be something it would do. May I ask which editor you are using?

I made a pretty opinionated change where I removed the option "Enable on browser startup" because to me it's not useful when persisting the status between browser sessions works

You are absolutely correct that it should replace the old "Enable on browser startup" functionality. The way you've changed it makes more sense anyways, and I would imagine that the new functionality would be prefered in more situations than not.

As for the code changes things seem good, but there are two changes i propose. First of all I think it may be prefered to have a setting for "remember last enabled status" (maybe: "Remember enabled status on browser exit" or something). When this setting is disabled, website blocking would always be disabled on browser startup. This option would best be set to true on startup, meaning your feature would be the default behaviour. Alternatively, it could be made the other way around, with an option like "Don't remember status on browser exit". I suppose it doesn't matter much.

I also noticed that the status property is sort of redundant now that we are storing lastEnabledStatus in localstorage, as we could technically just rely on that. But it is probably worth keeping this status property if we are making lastEnabledStatus something optional, as per my last proposal. So this could be left untouched in that case.

Aside from that, I don't see any issues with the code. As soon as you implement the setting (or, if you'd like, I can implement that myself) feel free to open a merge request 👍. Also may I ask your intention behind distributing your fork on the Mozilla Addon Store? Of course you are free to do so, I am just wondering whether it's about (a) making the new features available to yourself and others while you were waiting for it to get merged into the extension or (b) you want to do a sort of spin-off extension with your own vision. I suspect your intention is (a), at which I am sympathetic, I just think it might be preferable to avoid confusion with users looking for the extension. I am unsure if this is just in Firefox Developer Edition or if it has been merged into Stable Firefox, but there should be a way to use a local built ZIP file for an extension while also having it persistent between browser sessions. Either way, now that I've fixed my notifications it won't be too long till it gets implemented.

I also noticed you were working on custom CSS for the blocking page, perhaps you want to open a feature suggestion about this?

I also just had a different feature idea, which I just posted in #6. If you want to you can investigate it, but it's kind of boring and I am not even sure if the feature is worth the work.

If you would like faster back-and-forth messages I can email you my discord username if you'd prefer that kind of communication (I would prefer not to post it publicly). Could be useful for quick questions.

Thank you for the interest in the extension!

tuurep commented 2 months ago

Yeah we can talk in discord, you can email in tuure.piitulainen@gmail.com

May I ask which editor you are using?

NeoVim. Lets talk about that EOF-issue, we need to figure this out first :smile:

I also noticed that the status property is sort of redundant now that we are storing lastEnabledStatus in localstorage, as we could technically just rely on that. But it is probably worth keeping this status property if we are making lastEnabledStatus something optional, as per my last proposal. So this could be left untouched in that case.

Some real good points here.

Also may I ask your intention behind distributing your fork on the Mozilla Addon Store? Of course you are free to do so, I am just wondering whether it's about (a) making the new features available to yourself and others while you were waiting for it to get merged into the extension or (b) you want to do a sort of spin-off extension with your own vision.

Yeah the fork is public in case that this project would be abandoned and never see any further development, which is very common in open source :smile: So I was willing to carry the torch if that was the case, but now it definitely looks like we can merge my stuff and I can remove that fork, especially since it looks like no one but me installed it.

I am unsure if this is just in Firefox Developer Edition or if it has been merged into Stable Firefox, but there should be a way to use a local built ZIP file for an extension while also having it persistent between browser sessions.

This has been a pain point in hacking firefox extensions actually, I think what you describe is only available on the Developer Edition. However on Stable it's possible to send an addon as unlisted and wait for an automated review that takes ~1 min. I've done that sometimes, but with this NoDistractions (fork) I felt like it reached a pretty feature-complete point (minus the idea on CSS customization) so I wanted to make it public :smile:

AsciiJakob commented 2 months ago

NeoVim. Lets talk about that EOF-issue, we need to figure this out first 😄

I think this would be best to figure out on discord. I emailed you my username.

This has been a pain point in hacking firefox extensions actually, I think what you describe is only available on the Developer Edition. However on Stable it's possible to send an addon as unlisted and wait for an automated review that takes ~1 min. I've done that sometimes, but with this NoDistractions (fork) I felt like it reached a pretty feature-complete point (minus the idea on CSS customization) so I wanted to make it public 😄

Unsigned extensions can be installed in the Developer Edition, Nightly, and ESR versions of Firefox, after toggling the xpinstall.signatures.required preference in about:config. To use this feature your extension must have an add-on ID.

Yep looks like the unlisted addon method would be the easiest. And it's totally true what you said about open source software being left dead unfortunately, but in this this case it was just my notifications xD.

AsciiJakob commented 2 months ago

Pull request #10 has been merged and has implemented the core functionality. There is one more thing to figure out though: what to do with EnableOnStartup.

As of right now: If the new RememberLastStatus option is disabled, then the extension will always start disabled. The question is if we should have the option to choose between the old EnableOnStartup setting or whether you want the RememberLastStatus option. The benefit of this is that the users could choose to have the extension always be active on browser startup, which would otherwise not be possible.

AsciiJakob commented 2 months ago

I managed to add back EnableOnStartup in a way that still makes the addon easy to understand using radio dials for choosing one of three options:

The whole commit difference is available here: https://github.com/AsciiJakob/NoDistractions/compare/0e61ad7..1750e52

The only thing left now is quite trivial: making sure that if the user had enableonstartup enabled previously, then the new startupBehaviour setting will be changed to enableOnStartup, and afterwards making sure that the old enableOnStartup setting is removed. If you want you may implement this yourself, I think I'm gonna take a look at #9 for now

AsciiJakob commented 2 months ago

Backwards compatibility for enableOnStartup has now been implemented in 8b393a5

This feature should now be fully implemented and will be present in the next release. This issue will now be closed. Thank you for your contribution!