Re: [freenet-dev] Github and code review
On 22/03/15 21:39, Ian Clarke wrote: On Sun, Mar 22, 2015 at 4:20 PM, Matthew Toseland mj...@cam.ac.uk wrote: But regardless, nothing in the process I've outlined would inhibit correcting problems like this. Ideally they'd be corrected at the code review stage, but if they make it past that then they can be corrected with a new branch, just like any other bugfix. No, they can't. Removing binaries (or worse, copyright-infringing files) requires rewriting the history. Why would removing a binary require rewriting the history, Because we don't want those files in the repository at all. We don't want everyone to have to download jars which are many years out of date and aren't used anyway when they clone the repository. and why would anyone commit a copyright-infringing file? Can happen with installers. Can happen with people taking short-cuts, although that's less likely as Freenet is fairly specialised. Can happen as a deliberate attempt to disrupt. Can even happen by accident. In my years of using Github I have never ever been in a situation that necessitated rewriting history. The possibility that someone might do something really dumb and easily avoidable should not dictate our code review policy. Everyone does this when they first use Git. For example, most of the members of my group project this year included multiple copies of huge third party javascript libraries, and even jars. Some of our contributors will be on that level - they won't initially know any better. This is simply because of lack of experience. If we have volunteers, many of them will have limited experience. This may also be true of paid developers, and certainly of most GSoC interns. 2. Disruptive changes to APIs. This has also happened. Especially if the description is incomplete, there is a significant risk of refactoring breaking other code (e.g. plugins; this was part of the problem with Xor's changes), introducing new APIs that don't make sense etc. Both code review and a decent continuous integration system should address this. This is a good continuous integration service that is free for OSS projects: https://travis-ci.org/ You can see how I use it on this other OSS project of mine: http://quickml.org/ Not all problems can be detected by automated tools. Sometimes it is necessary to change classes that are used by plugins, and some of those plugins are unofficial, i.e. third party. Yes, just like any other software project. What would make us any different, and why would that necessitate deviating from the process I've proposed (which is pretty-much standard practice among well-run dev teams already)? Your point was that continuous integration can detect all problems, so advance code review is unnecessary. This is not true. CI is worth a lot, but it doesn't solve all the problems being addressed here. And it is certainly not true that all well-run development teams accept unreviewed code! Wine doesn't, Linux doesn't, Steve's company doesn't, and I'd be pretty amazed if Google did. As for the rest, I will not be drawn into personal attacks. I care about Freenet and would like it to succeed, regardless of whether I am paid to work for it. Some of its goals may be naive in the modern world, but there is much potential here. Sadly I don't have time to volunteer at the moment; I'm only involved now because a major crisis has erupted and I had hoped I could contribute something. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On Sun, Mar 22, 2015 at 4:20 PM, Matthew Toseland mj...@cam.ac.uk wrote: But regardless, nothing in the process I've outlined would inhibit correcting problems like this. Ideally they'd be corrected at the code review stage, but if they make it past that then they can be corrected with a new branch, just like any other bugfix. No, they can't. Removing binaries (or worse, copyright-infringing files) requires rewriting the history. Why would removing a binary require rewriting the history, and why would anyone commit a copyright-infringing file? In my years of using Github I have never ever been in a situation that necessitated rewriting history. The possibility that someone might do something really dumb and easily avoidable should not dictate our code review policy. 2. Disruptive changes to APIs. This has also happened. Especially if the description is incomplete, there is a significant risk of refactoring breaking other code (e.g. plugins; this was part of the problem with Xor's changes), introducing new APIs that don't make sense etc. Both code review and a decent continuous integration system should address this. This is a good continuous integration service that is free for OSS projects: https://travis-ci.org/ You can see how I use it on this other OSS project of mine: http://quickml.org/ Not all problems can be detected by automated tools. Sometimes it is necessary to change classes that are used by plugins, and some of those plugins are unofficial, i.e. third party. Yes, just like any other software project. What would make us any different, and why would that necessitate deviating from the process I've proposed (which is pretty-much standard practice among well-run dev teams already)? I'm not sure I understand your point. That seems very unlikely to happen, we barely have budget for actual developers, let alone dedicated QA people. And really, who'd want that job anyway? Even setting aside budget and finding suitable people, coders should have primary responsibility for ensuring that their code is good. It's unhealthy to have a situation where coders think that ensuring their code is clean and robust is someone else's problem. That is precisely how every mature project works. Just because neither your business ventures nor your involvement in open source are mature doesn't mean there aren't projects out there - both open source (Linux, Wine) and businesses (Steve's employer, presumably Google, etc) - which care about code quality. Wow. Why would you say something so stupid in a forum where future employers could potentially see it? You forget that I've seen your code, it wouldn't come anywhere close to passing a code review by even the least experienced developer on my company's engineering team, so please don't presume to lecture me about code quality, or how mature software projects work. I really hope they teach you how to be less of an asshole during your computer science course, or you'll have a very hard time getting or keeping a job, either commercial or in academia. Your previous paragraph would be a firing offense at most companies. Professional engineering teams simply don't tolerate asshole behavior any more. Ian. -- Ian Clarke Founder, The Freenet Project Email: i...@freenetproject.org ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On Sat, Mar 21, 2015 at 7:42 PM, Matthew Toseland matt...@toselandcs.co.uk wrote: On 21/03/15 20:49, Ian Clarke wrote: That's part of it, but also that a branch should be created for each bugfix/feature, which ideally should be as small a unit of work as possible (that can be merged without breaking stuff). Absolutely. See e.g.: http://nvie.com/posts/a-successful-git-branching-model/ We try to stick to this ... or at least, that was the plan/consensus! Hmm, it doesn't sound like we do in practice, given that I believe there were pull requests with hundreds of commits which sounded like it was for much more than a single feature or bugfix. Anyway, the point isn't to complain about what happened in the past, just to agree on our process going forward. The problem is then we spend a lot of time undoing stuff. This can and does happen, and has happened, even relatively recently. It's part of the reason why most projects use a branch-and-merge model, rather than giving all the devs push rights. Ian. Why we might need to revert or reject changes: 0. Stupid stuff. E.g. committing jars to repositories. Committing jars to repositories is kind of careless, don't people have sensible .gitignore files? Can a .gitignore be committed to the repo? But regardless, nothing in the process I've outlined would inhibit correcting problems like this. Ideally they'd be corrected at the code review stage, but if they make it past that then they can be corrected with a new branch, just like any other bugfix. 2. Disruptive changes to APIs. This has also happened. Especially if the description is incomplete, there is a significant risk of refactoring breaking other code (e.g. plugins; this was part of the problem with Xor's changes), introducing new APIs that don't make sense etc. Both code review and a decent continuous integration system should address this. This is a good continuous integration service that is free for OSS projects: https://travis-ci.org/ You can see how I use it on this other OSS project of mine: http://quickml.org/ I agree that review capacity is potentially a bottleneck. There are different ways to solve this: - Have paid staff who review and merge stuff. That seems very unlikely to happen, we barely have budget for actual developers, let alone dedicated QA people. And really, who'd want that job anyway? Even setting aside budget and finding suitable people, coders should have primary responsibility for ensuring that their code is good. It's unhealthy to have a situation where coders think that ensuring their code is clean and robust is someone else's problem. - Don't accept pull requests if nobody can review them right now. This will absolutely cause a severe bottleneck, causing development to grind to a halt, and probably destroying morale in the process. Who wants to work their ass of on some code only for it to sit in a branch indefinitely? - Allow the reviewers to make reasonable demands for clear code. A pull request is a negotiation between the contributor and the maintainer. Of course, reviewers can point out unclean code, and a conscientious developer will want to commit good code so they'll fix it. If a coder is ignoring reasonable code review feedback then that might be grounds for removing commit access. Ian. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On Sun, Mar 22, 2015 at 6:44 AM, Arne Babenhauserheide arne_...@web.de wrote: Am Samstag, 21. März 2015, 12:45:39 schrieb Ian Clarke: It sounds like people are trying to use commits for code review, whereas they should be using Github pull requests. For huge changes we are using commits as a second level hierarchy: When the diff is too big to understand on its own, then the commits have to form an easy to follow story which allows understanding the change step by step. I think you've misidentified the problem and therefore the solution. The problem is that diffs would ever be too big to understand on their own, therefore the solution is that the diff should never be too big to understand on it's own. A branch/pull-request should rarely represent more than a few days of work, and thus should rarely take more than a few minutes to review. As such they unpaid devs cannot just sit down for 6 hours and read through a huge diff to understand it in its entirety. They need the diff more structured. A 6 hour code review is insane, and should never be necessary. - For any isolatable feature or bugfix, create a new branch just for that feature or bug request (perhaps put the bug id # in the name of the branch). *Do not combine multiple features or bugfixes into a single branch.* If it can be merged independently, it should have it's own branch. We get into a problem with this, when the changes get too extensive without being ready for merging into a release. It should never be necessary for changes to be that extensive. In my day-job we're working on a far more complex codebase than Freenet, and yet a branch/pull-request almost *never* represents more than 4 days of work, and therefore code reviews rarely require more than 10-20 minutes. Your scheme provides fast development of individual features, but does not provide information spread within the group: Only one person has seen the current version of the code. I don't understand that, anyone that wants to is free to look at the code/pull-requests. Longterm this needs to a situation where no one can understand the whole code well enough to change it efficiently, which in turn leads to pseudo-ownership over certain sub-sections of the code. If we're producing code that isn't comprehensible without external explanation, then we're not producing good code. Well written code shouldn't require an explanation, it should be self-explanatory. This book lays out some excellent guidelines for this kind of code, every programmer should read it: http://amzn.com/0132350882 Ian. -- Ian Clarke Founder, The Freenet Project Email: i...@freenetproject.org ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
Sure, but let's not get bogged down with complaining about the past, we all know it's been dysfunctional, let's focus on what we're going to do from now on. Ian. On Sun, Mar 22, 2015 at 2:06 AM, Florent Daigniere nextg...@freenetproject.org wrote: On Sun, 2015-03-22 at 07:36 +0100, Florent Daigniere wrote: On Sun, 2015-03-22 at 00:42 +, Matthew Toseland wrote: On 21/03/15 20:49, Ian Clarke wrote: On Sat, Mar 21, 2015 at 1:58 PM, Matthew Toseland matt...@toselandcs.co.uk wrote: Most of the above boils down to review the diff, not the history. That is probably sensible. That's part of it, but also that a branch should be created for each bugfix/feature, which ideally should be as small a unit of work as possible (that can be merged without breaking stuff). It only is if the diff is of reasonable size... which it is most of the time, *except* when it comes from paid devs. They code in their cave for months, drop a 100kloc diff doing way more than a single feature/bugfix onto the maintainer and expect it to be merged; I'm sure that refactoring is good but not when it's forked off for 6month... This is the problem we had recently with both toad's and xor's code. We're talking about dozens of features and bugfixes AND refactoring. What blocks development is that the refactoring isn't merged until their work is ready... and there's usually a good reason for it; they code first and think later (to be fair it's a common trait amongst devs working alone) which means that as long as they haven't tried it out they're not quite sure of what they want in terms of API... so it's only in a mergeable state when it works. Whether there's a single change per commit/branch/pull request doesn't matter as long as one of them is enforced. Until now the base unit was supposed to be one change per commit; I'm all for changing it to something else but that won't solve the problem unless it's enforced strictly. Florent Just to put some perspective on what I've written above: Here's toad's diff: https://github.com/freenet/fred/pull/287/files Here's xor's diff: https://github.com/freenet/fred/pull/319/files in both cases github gives up rendering it: Sorry, we could not display the changes to this file because there were too many other changes to display. and doesn't even display the commit count: This pull request is big! We're only showing the most recent 250 commits. As for the individual commits, there's plenty which are doing more than a bugfix/feature/single semantic change. Florent -- Ian Clarke Founder, The Freenet Project Email: i...@freenetproject.org ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On 22/03/15 19:22, Ian Clarke wrote: I think you've misidentified the problem and therefore the solution. The problem is that diffs would ever be too big to understand on their own, therefore the solution is that the diff should never be too big to understand on it's own. A branch/pull-request should rarely represent more than a few days of work, and thus should rarely take more than a few minutes to review. ... It should never be necessary for changes to be that extensive. In my day-job we're working on a far more complex codebase than Freenet, and yet a branch/pull-request almost *never* represents more than 4 days of work, and therefore code reviews rarely require more than 10-20 minutes. Unfortunately, sometimes it is necessary to make big changes. For example, my work last summer: We can't keep on using Db4o because it's been discontinued. We can't easily move to another object database because they are not standardised. In any case we need to rewrite it to a simpler structure for stability and performance reasons. But this meant rewriting a lot of core code, adding necessary infrastructure, and then implementing backward compatibility. Since this will break APIs, we may as well fix some of the other problems at the same time. Now, if I'd had time, I would have broken this up into a series of pull requests (or big commits) to be reviewed separately. However, most of them cannot be merged independantly - either they introduce new functionality that isn't used (so why should it be in the codebase?), or they break backwards compatibility (which is a largish chunk of work itself). It appears that time was a factor in Xor's case too - he was worried about starting his thesis soon. I believe Ian's answer will be that time is always a factor and the correct solution is to cut corners and hope for the best - we will clean up the code some day. Some day never comes, because there's always another deadline (for employees)... IMHO this is a management style which does not work with the kind of code that Freenet is, that modern OSS is, that Google's infrastructure is. It works well enough with code that doesn't need to be maintained, and it just about works if you can rewrite it completely every year, or ship it once and forget it. Re volunteers, if they know what the rules are and if maintainers respond quickly there's a good chance that they will help to solve the problems, and the code will get merged. Longterm this needs to a situation where no one can understand the whole code well enough to change it efficiently, which in turn leads to pseudo-ownership over certain sub-sections of the code. If we're producing code that isn't comprehensible without external explanation, then we're not producing good code. Well written code shouldn't require an explanation, it should be self-explanatory. This book lays out some excellent guidelines for this kind of code, every programmer should read it: http://amzn.com/0132350882 Yes, and allowing everyone to commit with no supervision is a perfect recipe for the sort of spaghetti code that we would like to avoid. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On Sun, Mar 22, 2015 at 1:36 AM, Florent Daigniere nextg...@freenetproject.org wrote: On Sun, 2015-03-22 at 00:42 +, Matthew Toseland wrote: On 21/03/15 20:49, Ian Clarke wrote: On Sat, Mar 21, 2015 at 1:58 PM, Matthew Toseland matt...@toselandcs.co.uk wrote: Most of the above boils down to review the diff, not the history. That is probably sensible. That's part of it, but also that a branch should be created for each bugfix/feature, which ideally should be as small a unit of work as possible (that can be merged without breaking stuff). It only is if the diff is of reasonable size... which it is most of the time, *except* when it comes from paid devs. Then that needs to change. With a feature/bugfix-per-branch approach the diffs should be reviewable in just a few minutes. If they aren't, then the coder is probably stuffing multiple features/bugfixes into a single branch and that's contrary to the guidelines I've outlined. Whatever happened in the past, what matters is what we do going forward. They code in their cave for months, drop a 100kloc diff doing way more than a single feature/bugfix onto the maintainer and expect it to be merged; I'm sure that refactoring is good but not when it's forked off for 6month... This is the problem we had recently with both toad's and xor's code. We're talking about dozens of features and bugfixes AND refactoring. Then that needs to change going forward. Whether there's a single change per commit/branch/pull request doesn't matter as long as one of them is enforced. The way Github's code review tools are designed, you definitely want it to be per branch (which will have a 1-1 relationship with a pull request), not per commit. Until now the base unit was supposed to be one change per commit; I'm all for changing it to something else but that won't solve the problem unless it's enforced strictly. You can't impose processes on people, they need to agree to them or it won't work. That being said, I don't know why any reasonable person wouldn't agree to what I've outlined. It's a tried and tested approach. Ian. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On 22/03/15 19:07, Ian wrote: On Sat, Mar 21, 2015 at 7:42 PM, Matthew Toseland matt...@toselandcs.co.uk wrote: 0. Stupid stuff. E.g. committing jars to repositories. Committing jars to repositories is kind of careless, don't people have sensible .gitignore files? Can a .gitignore be committed to the repo? But regardless, nothing in the process I've outlined would inhibit correcting problems like this. Ideally they'd be corrected at the code review stage, but if they make it past that then they can be corrected with a new branch, just like any other bugfix. No, they can't. Removing binaries (or worse, copyright-infringing files) requires rewriting the history. Rewriting the history is *BAD*. It makes it impossible for a third party to follow what is going on. It makes life extremely difficult/messy for our own developers, breaking their unfinished work when they pull from master. 2. Disruptive changes to APIs. This has also happened. Especially if the description is incomplete, there is a significant risk of refactoring breaking other code (e.g. plugins; this was part of the problem with Xor's changes), introducing new APIs that don't make sense etc. Both code review and a decent continuous integration system should address this. This is a good continuous integration service that is free for OSS projects: https://travis-ci.org/ You can see how I use it on this other OSS project of mine: http://quickml.org/ Not all problems can be detected by automated tools. Sometimes it is necessary to change classes that are used by plugins, and some of those plugins are unofficial, i.e. third party. I agree that review capacity is potentially a bottleneck. There are different ways to solve this: - Have paid staff who review and merge stuff. That seems very unlikely to happen, we barely have budget for actual developers, let alone dedicated QA people. And really, who'd want that job anyway? Even setting aside budget and finding suitable people, coders should have primary responsibility for ensuring that their code is good. It's unhealthy to have a situation where coders think that ensuring their code is clean and robust is someone else's problem. That is precisely how every mature project works. Just because neither your business ventures nor your involvement in open source are mature doesn't mean there aren't projects out there - both open source (Linux, Wine) and businesses (Steve's employer, presumably Google, etc) - which care about code quality. I repeat my earlier point: If we allow everyone to commit without review, we will spend a lot of our time (and commit history) undoing stuff. This is one of the reasons behind the rise of distributed version control in the first place. Git, and Github, are specifically designed to support pull requests. The implication is that the person merging the changes is not the same as the person posting them, and that they should be signed-off, i.e. reviewed. - Don't accept pull requests if nobody can review them right now. This will absolutely cause a severe bottleneck, causing development to grind to a halt, and probably destroying morale in the process. Who wants to work their ass of on some code only for it to sit in a branch indefinitely? - Allow the reviewers to make reasonable demands for clear code. A pull request is a negotiation between the contributor and the maintainer. Of course, reviewers can point out unclean code, and a conscientious developer will want to commit good code so they'll fix it. If a coder is ignoring reasonable code review feedback then that might be grounds for removing commit access. We are not using SVN. We are not using CVS. NOBODY uses Git and then gives everyone push access. It just doesn't make sense. The correct, standard workflow used by just about everyone is to fork and post a pull request, which may or may not be merged. I will reply to your points about big changes separately. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On 22/03/15 22:21, Roland Haeder wrote: On Sun, 22 Mar 2015 21:40:41 + Matthew Toseland mj...@cam.ac.uk wrote: On 22/03/15 19:22, Ian Clarke wrote: Unfortunately, sometimes it is necessary to make big changes. One good example is the initial import of all files for a new project. There you commit a huge chunk of files and directories. As I'm (different project) a newcomer to a project's development, I had started cloning the original repository (creating a personal clone) and started developing. I did this by committing carefully and I tried to avoid huge changes (not always possible, more below) to let them easily review them. Then I stepped towards them and my commits got rejected because I didn't make a feature branch or fix branch ... :-( That is kind of frustrating because my commits won't make it in. What I mean here is that the maintainer should not be so bureaucratic to newcomers as this could turn them away and they may never come back. The maintainer can then still review commits relatively easily by setting up a merge branch git checkout master # or wherever your development branch is git remote add rolands_code git://git.bla.example/some/foo.git --track master git checkout -b code_reviewed_okay/master git checkout master git checkout -b rolands_master git pull rolands_code This way you can check your code with changes from developer roland (yes, my name) without mixing it so quickly with your own code. Then start the review process by looking at each commit and cherry-pick it into code_reviewed_okay/master branch: git checkout code_reviewed_okay/master git cherry-pick xx git checkout rolands_master Then you can check them again (on functionality) in the review branch (as not all commits from rolands_master are in) and continue with next one. Maybe there is a better way. :-) But this way may work. After that merge all reviewed commits into master: git checkout master git merge -S code_reviewed_okay/master That seems to be a fine way to me. My 2 cents. :-) Your code should not be rejected because it is on master on your own repository IMHO. However, if you are going to make multiple pull requests you really need to use separate branches. If you have several different changes on the same branch then you definitely need to separate them out before making a pull request. However, this is pretty easy using git branch, git reset and git cherry-pick. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On Sun, 22 Mar 2015 22:27:24 + Matthew Toseland mj...@cam.ac.uk wrote: Your code should not be rejected because it is on master on your own repository IMHO. However, if you are going to make multiple pull requests you really need to use separate branches. If you have several different changes on the same branch then you definitely need to separate them out before making a pull request. However, this is pretty easy using git branch, git reset and git cherry-pick. Okay, I will try it then later. Thank you. :-) signature.asc Description: PGP signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Github and code review
On Sun, 22 Mar 2015 21:40:41 + Matthew Toseland mj...@cam.ac.uk wrote: On 22/03/15 19:22, Ian Clarke wrote: Unfortunately, sometimes it is necessary to make big changes. One good example is the initial import of all files for a new project. There you commit a huge chunk of files and directories. As I'm (different project) a newcomer to a project's development, I had started cloning the original repository (creating a personal clone) and started developing. I did this by committing carefully and I tried to avoid huge changes (not always possible, more below) to let them easily review them. Then I stepped towards them and my commits got rejected because I didn't make a feature branch or fix branch ... :-( That is kind of frustrating because my commits won't make it in. What I mean here is that the maintainer should not be so bureaucratic to newcomers as this could turn them away and they may never come back. The maintainer can then still review commits relatively easily by setting up a merge branch git checkout master # or wherever your development branch is git remote add rolands_code git://git.bla.example/some/foo.git --track master git checkout -b code_reviewed_okay/master git checkout master git checkout -b rolands_master git pull rolands_code This way you can check your code with changes from developer roland (yes, my name) without mixing it so quickly with your own code. Then start the review process by looking at each commit and cherry-pick it into code_reviewed_okay/master branch: git checkout code_reviewed_okay/master git cherry-pick xx git checkout rolands_master Then you can check them again (on functionality) in the review branch (as not all commits from rolands_master are in) and continue with next one. Maybe there is a better way. :-) But this way may work. After that merge all reviewed commits into master: git checkout master git merge -S code_reviewed_okay/master That seems to be a fine way to me. My 2 cents. :-) signature.asc Description: PGP signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] C# Tray App (Probably) Feature-Complete
I tried the new tray icon in Windows 7 x64, Windows 8.1 x64, and the Windows 10 x64 Technical Preview build 9926. Tested: Open Freenet, Start Freenet, Stop Freenet, View log file, Preferences, Hide icon and Exit. Everything worked. My only complaint is that Open Freenet launched IE instead of FF, which was set as the default. The Preferences Browser dropdown choices are Auto and Internet Explorer with no information on how to add other options. Should there be a one time prompt when clicking Hide icon that informs the user that Freenet is still running in the background, and explains how to restore the icon or start/stop Freenet? On Thu, Jan 1, 2015 at 1:49 PM, Steve Dougherty st...@asksteved.com wrote: The C# Windows tray application is now more-or-less feature-complete. Feedback and suggestions would be appreciated! In the coming days I plan to document this more and do a more thorough writeup of its capabilities. Signed binary: https://downloads.freenetproject.org/FreenetTray-testing-3b30923.exe Source: https://github.com/freenet/wininstaller-innosetup/tree/csharp/FreenetTray To test it put it in the directory Freenet is installed in. It will add a tray icon which controls the node, similar to the existing tray application, but shinier. For instance, this one distinguishes between a clean shutdown and a crash, and has a more informative response to crashes. It supports launching Chrome, Firefox, Opera, and IE in privacy mode. It's around 800 LOC. (Not counting those the resources and Windows Forms designer generate.) Currently if Freenet takes more than 3 seconds between being started and FProxy listening on its port a balloon tip will pop up to show that Freenet is starting. 3 seconds might be a bit short, but my hope was to maintain a sense of interactivity. (On my machine FProxy takes ~1.6 seconds after starting to listen on its port.) On that note the refresh rate of the startup page should be increased - it seems like it's currently around 10 seconds, which is a long time to stare at it. - Steve ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
