Needs new maintainers

[Kilian]

Hi guys,

Since writing f.lux-indicator-applet I've been doing less and less python. The current version, with all the great additions from people, is not something I want to or can maintain, at least not by myself.

It is my intention to rewrite the bindings to xflux in node so I can have a better interface and easier (to me) to manage code. I do not know when that happens though, and it's a waste to let all the great suggestions and pull requests go to waste on this version.

So I'm looking for other people to step in. I want to start a github organisation and we can have a team of people to manage and maintain the code. I'd like to be involved, obviously, but this way, I'm not a bottleneck.

So, who's up for it?

Kilian

[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:

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

Notable Pull Requests:

• Fix #28, #40 #44 Fix xflux sources? #28, RPM-based systems : dependencies #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.