Needs new maintainers about f.lux-indicator-applet

[synthor]

Nice move, Kilian.

I definately am up for it, but still am quite new to Git/Github and don't know all the processes yet. If nobody else would volounteer for it, I would just try do it.

Think that asking you for help wouldn't be a big deal.

Thorsten

[Kilian]

@ntc2, @NHellFire and @ev1l0rd: All of you are active in this repository. How do you feel about the above plans and would you participate?

[ntc2]

@Kilian: I'm afraid I'm too busy to promise to take on any real responsibility here.

I have been using the indicator applet for a few weeks now and have tweaked some small things, as needed, to get it working for me. I would like to make some small enhancements -- like showing in the GUI what start and end times were computed based on zip code or latitude + longitude, and making the transition from full brightness (day time) to blue filtered (night time) more gradual -- but I have no idea when I'd actually get around to it.

Re node.js, are you saying you plan to port the applet to JavaScript?

[noirscape]

@Kilian: I have only bumped up the distro version each time in launchpad. I will continue doing so (and provide mirrors when someone elses PPA goes live by cloning the package to my PPA), but as I'm pretty much a dummy on linux development beyond bash scripting, I won't be able to help you update.

Also, @synthor: committing stuff to git (and github afterwards) is usually as easy as running the following commands in your directory:

 git add -A # Stages all changes for commit.
 git commit -m "messagehere" # Commits everything with the message 'messagehere'
 git push origin branch # Sends everything to github. Change branch to the current branch. github uses master by default.

tl;dr: I will keep up a mirror, but won't be able to help development.

[Kilian]

@ntc2 yes, I have a far better grasp at making and maintaining javascript applications, and the communication model to the xflux binary should be much simpler. For the python/gtk version I'm looking for someone that can and wants to make such improvements, together with having a firmer grasp on the code. I dont think it should be someone’s day-task to do so, but having more people involved and with access to update the code seems a good idea.

@ev1l0rd The reason I don't do that is because I can not guarantee that it still works on more recent ubuntu versions; it requires proper testing and updating. If you've found that it works that's actually pretty useful.

Other people that have worked on pullrequests: @Mystro256, @daTokenizer, @aaferrari and @petracvv what do you think of the above idea(s)?

[synthor]

@ev1l0rd Thanks, but that is not the deal. I already contributed to some repositories. At work I have an own git server and manage the code in that. No external contrubutions which I have to handle...so maybe it's time now for the next step.

I haven't created a fork yet, because I saw there are a lot of them already. Bet someone fixed that .pid bug already. Would be nice if this changes would be merged into this (main) repository.

[synthor]

@Kilian Let me have a look on the interface, if I find the time for it. xflux is propritary or? I found no further information or documentation. If you have something handy you're welcome.

Edit: If yes, searching for an open source solution or creating a free xflux derivate would be better than digging around with that binary.

[Kilian]

Merging back all the pull request is something that the new github org could do, If many people look into merging small parts back into the main repository, it's manageable. There are some PID-related fixes waiting in the pull requests so it's worth checking those out.

F.lux and the xflux binary are proprietary and built by @herf and Lorna, but this project has their blessing. The documentation has been a combination of the binary it's output, the options their mac version offers and simply asking them.

[synthor]

But regarding that I also removed that searching for the old pid file and killing this process bug, I will submit a pull request. That problem was/is larger than the place of the pid file itself. ;)

Edit: Thx for further info @Kilian

[synthor]

Searched for xflux alternatives and found redshift. Installed it, and works like a charm. Even automaticly sets coordinates depending on libgssglue1. It even changed the color temperature now, whereas xflux didn't. It only did exactly at the time of dusk, which is +2 hours from now on here.

[herf]

Hi everyone - I'm ready to update the xflux binary with something like the version we're using for Android. Has every feature in the Mac version and some extras too. There's a new communication API (based on abstract sockets).

90% of what's wrong with this project so far is I picked a blocking pipe to send/receive commands, and when that pipe fills up, we use 100% CPU and nothing works after that. So the new thing is fully async and a lot better.

All that is needed is to update the UI and communication protocol to match.

[almereyda]

Yes, I also see the xflux path much more convenient than a redshift one.

From looking at the issues, I see mainly packaging requests for different distributions and package managers. Ubuntus, Feboras, Debians and CentOSes should at least be provided. I have had good experiences with packages out of the OpenSUSE build pipeline.

Insofar it is only questionable why the xflux community relies on a non-open source binary to achieve the goal of colour temperature aware desktop rendering. Native Wayland support'd be another topic, too.

Where's a list of most urgent issues to be resolved for this repo, before being completely able to hand over to the community?

General issues would be:

• #7 high cpu usage for fluxgui
• #16 No multi-monitor Support (Linux)
• #28 xflux sources?
• #46 PPA needs the multi-monitor update, duplicate of #16
• #56 setup.py renames xflux64/32 whenever it runs
• #57 Dual screen support, duplicate of #16
• #66 applet fails to launch silently
• #68 High usage of processor, duplicate of #7

Notable Pull Requests:

• #44 Fix #28, #40

Next step would be sorting Distribution specific errors.

[Kilian]

@synthor redshift has GUIs available, but I'm neither interested in using it (xflux is superior in its color management) or writing a gui for it (as there are already gui's for it) Simply, this repository or the new community repository is not the place for that. :)

@almereyda has the right idea (thanks for the clear message!) Packaging (and testing etc) for multiple systems is a totally different beast from building things. General issues in short would be:

• updating the xflux binary (with help of @herf)
• update the gui to no longer use a subproces and dbus, but use a non-blocking communication channel to xflux. This should fix 80% of the issues, the rest being either real bugs or packaging/distribution requests.
• take stock on if the api's we use for the indicator-applet are as they should be, or if we should switch to something like systray for better support on multiple distributions (or both, there is a pull request available that does this.)
• get packages for different distributions.

[synthor]

I didn't know that the author of xflux is under us. Tried to find some information on Duckduckgo but wasn't successful with that. So I looked out for an alternative. There was no intention to move the project from xflux to redshift. Just brainstormed a bit.. :)

[Kilian]

No harm done!

[synthor]

@Kilian I created a PR #72 as replacement of #69, which fixes the xflux renaming bug. Please merge it and close #69.

Strangely I forked from @Mystro256 at home. That's where this strange pid file/killing random process on boot comes from. You already have merged the appropriate PR into master. :)

[synthor]

@Kilian And finally I found the reason why a clone of your repo does not run on (X)Ubuntu 14.04: the xflux binary in /usr/bin/local has simply no execution permission.

Chmod +x and it will start.. :)

Edit: The fix for that is also in my pull request.

[Kilian]

See, this is why I need help ;) awesome. What I want to do is actually set up the community repository, and then I'll also add you, and we can make that pullrequest number 1. Sounds like a plan?

[synthor]

Go for it. :)

@Mystro256's pull request also looks nice. I will watch them all later, if I find the time.

[synthor]

@Kilian Reminder.. 👻

[Kilian]

I've been busy offline, will pick this up soon :)

[aaferrari]

Unfortunately I can not take charge of the program maintenance because I'm not very familiar with the fluxgui code (and I'm too busy with other things), but I compromise to keep updated the Gentoo ebuild in this overlay.
Regarding the program itself, I am very satisfied with it, the only thing that I would add would be the ability to automatically pause it when certain programs are in full screen (soon will have an open issue about if someone is interested in implementing this functionality).

Where's a list of most urgent issues to be resolved for this repo, before being completely able to hand over to the community?

General issues would be:

• #7 high cpu usage for fluxgui
• #16 No multi-monitor Support (Linux)
• #28 xflux sources?
• #46 PPA needs the multi-monitor update, duplicate of #16
• #56 setup.py renames xflux64/32 whenever it runs
• #57 Dual screen support, duplicate of #16
• #66 applet fails to launch silently
• #68 High usage of processor, duplicate of #7

Most of the issues on multimonitor support would believe that already were resolved in the latest versions of xflux, the #56 is due to this commit that I sent a few months ago to include the 32-bit version of xflux (I apologize for not having these details in mind, but I see that @synthor already resolved), and #66 is possible that there been resolved with the aforementioned commit (more precisely with the fluxapp.py modification that I did when checks whether a previous instance is running).

[Kilian]

The new community repository now exists at https://github.com/xflux-gui/xflux-gui

@herf @synthor @ntc2 @aaferrari I have invited you all to join the github organisation. Do not feel obliged to join or if you do, like you have to actively participate.

I have copied over the repository, but none of the pull requests or issues are linked. @synthor we found pull request #1, can you shoot that in soon? I will update this repository to link to the new one.

[ntc2]

@Kilian I was going to merge some documentation related pull requests (https://github.com/xflux-gui/xflux-gui/pulls 11 and 12) and apparently I don't actually have write access to the repo.

[Kilian]

@ntc2 sorry! apparently being a member of the organisation doesn't automatically mean write access. You should have full access now.

[ntc2]

@Kilian Thanks, I merged some pull requests!