Re: [Mixxx-devel] LateNight skin (was: release progress)
I was just watching my friend use Traktor with 4 decks and I noticed a nice feature I would like to have in Mixxx. When the library view is maximized, condensed views of the decks are shown on top. This would solve the minor issue I have when searching for tracks that I need to toggle away from the big library to see the BPM and key of the current track. On 06/09/2015 12:05 AM, re-cy...@hushmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So there's the space beneath the left deck - where the preview deck lives. The space on the other side is empty. Can the micaux array get shrunk a bit and fit over there? That would save some space, plus be nice and symmetrical. ~RAWRR On Mon, 08 Jun 2015 21:34:41 + re-cy...@hushmail.com wrote: On Mon, 08 Jun 2015 21:15:37 + Daniel Schürmann dasch...@mixxx.org wrote: If I recall it correct, it should help. This has also the benefit that you can see more tracks in the library. And whatever other controls as well... interesting. Am 08.06.2015 um 23:10 schrieb re-cy...@hushmail.com: Interesting re: CPU. What do you think about decreasing the height but keeping the width re: CPU? ~RAWRR On Mon, 08 Jun 2015 21:00:52 + Daniel Schürmann dasch...@mixxx.org wrote: Hi Markus, Nice mock-up. In the past we had issues with four full size Waveforms because the CPU usage increases with the size. So I am afraid that view does not suit to be part of Mixxx default skin. IMHO we have already more then enough view options in the LateNight skin. But there should be no problem with a recent devices. If this is the perfect skin for you use case, you are welcome to fork it. Thats the benefit of our skin engine. Kind regards. Daniel Am 08.06.2015 um 18:42 schrieb Markus Klösges: Any thoughts on the general outline I proposed? [master gain][balance][head mix][head gain][4/2 deck toggle] [Deck 1][Deck 1/2 mixer][Deck 2] waveform 1 waveform 2 waveform 3 waveform 4 [Deck 3][Deck 3/4 mixer][Deck 4] I'm using Mixxx without controller without scratching and so on, just simple crossfading with external mixer and so on. I would also prefer the option to have the (almost) screen- wide waveforms. I liked the 'old' 1.11 Latenight. Clearly that doesn't work out for 4 decks. I think one should not clutter a skin with dozens of config- options but better fork that skin (or decide for one, better, solution maybe). The option to get the bigLibrary is a real benefit for me and results in lesser need of a large library when everything is turned on. The only reason I have the mixer turned on is the crossfader and the preview-Buttons. On my machine, in 4 and 2 deck mode without the mixer there is some space where the mixxx logo is displayed. Would it be possible to get the crossfader (and maybe the cue-buttons) there? That would result in the big waveforms for me. Another option would be to make the waveforms (nearly) screen- wide and place pitch, EQ, Volume, Cue, on the left and right (as pitch was in 1.11). That would only leave crossfader, Master, Balance, HeadGain and Pre/Main from the mixer-section what could eventually be placed like proposed above where the mixxx logo is, in between of previewDeck and maybe Mics. [pitch/EQ/Vol Deck1] [Waveform 1] [pitch/EQ/Vol Deck2] [--] [Waveform 3] [--] [pitch/EQ/Vol Deck3] [Waveform 2] [pitch/EQ/Vol Deck4] [--] [Waveform 4] [--] [ Deck1 ] [ Deck2 ] [ Deck3 ] [ Deck4 ] [PreviewDeck] [ Crossfade/Master ] [Microphones] [Samplers] [Effects] [Library] I've done a quick sketch http://imgur.com/MruunAd I've not rescaled anything except some little changes and this dosn't get bigger than the current approach but gives much bigger waveforms. But I am unsure if this is out of scope for LateNight and should better be done in an other skin. What do you think? Cheers, Markus Am 08.06.2015 um 03:44 schrieb Be: I tested it and it helps, but adding these options feels like putting bandages on a bigger design issues that are not very easy to solve. There are so many buttons for skin options at the top that it's kinda overwhelming. However, I think trying to implement better solutions to those design challenges would take a lot of effort that shouldn't delay 1.12. Any thoughts on the general outline I proposed? [master gain][balance][head mix][head gain][4/2 deck toggle] [Deck 1][Deck 1/2 mixer][Deck 2] waveform 1 waveform 2 waveform 3 waveform 4 [Deck 3][Deck 3/4 mixer][Deck 4] On 06/06/2015 01:04 PM, Owen Williams wrote: thanks as in, you tested it and it works well? I don't want to commit without someone taking a look at it. On Sat, 2015-06-06 at 09:30 +, re-cy...@hushmail.com wrote: On Sat, 06 Jun 2015 00:29:14 + Owen Williams owilli...@mixxx.org wrote: I've posted a PR for some new
Re: [Mixxx-devel] LateNight skin (was: release progress)
At this point we've reached the end of the road for how flexible LateNight can be. It's fairly flexible already, and every bit of flexibility I try to add beyond that is causing ripple effects for other layouts. So for now, if you want to experiment with other options, I'd suggest you fork the skin and try moving the pieces around. It might be fun to resurrect LateNight-wide (which may still be in the developer_skins repo) and see if it can be made to behave better. On Tue, 2015-06-09 at 05:05 +, re-cy...@hushmail.com wrote: So there's the space beneath the left deck - where the preview deck lives. The space on the other side is empty. Can the micaux array get shrunk a bit and fit over there? That would save some space, plus be nice and symmetrical. ~RAWRR On Mon, 08 Jun 2015 21:34:41 + re-cy...@hushmail.com wrote: On Mon, 08 Jun 2015 21:15:37 + Daniel Schürmann dasch...@mixxx.org wrote: If I recall it correct, it should help. This has also the benefit that you can see more tracks in the library. And whatever other controls as well... interesting. Am 08.06.2015 um 23:10 schrieb re-cy...@hushmail.com: Interesting re: CPU. What do you think about decreasing the height but keeping the width re: CPU? ~RAWRR On Mon, 08 Jun 2015 21:00:52 + Daniel Schürmann dasch...@mixxx.org wrote: Hi Markus, Nice mock-up. In the past we had issues with four full size Waveforms because the CPU usage increases with the size. So I am afraid that view does not suit to be part of Mixxx default skin. IMHO we have already more then enough view options in the LateNight skin. But there should be no problem with a recent devices. If this is the perfect skin for you use case, you are welcome to fork it. Thats the benefit of our skin engine. Kind regards. Daniel Am 08.06.2015 um 18:42 schrieb Markus Klösges: Any thoughts on the general outline I proposed? [master gain][balance][head mix][head gain][4/2 deck toggle] [Deck 1][Deck 1/2 mixer][Deck 2] waveform 1 waveform 2 waveform 3 waveform 4 [Deck 3][Deck 3/4 mixer][Deck 4] I'm using Mixxx without controller without scratching and so on, just simple crossfading with external mixer and so on. I would also prefer the option to have the (almost) screen- wide waveforms. I liked the 'old' 1.11 Latenight. Clearly that doesn't work out for 4 decks. I think one should not clutter a skin with dozens of config- options but better fork that skin (or decide for one, better, solution maybe). The option to get the bigLibrary is a real benefit for me and results in lesser need of a large library when everything is turned on. The only reason I have the mixer turned on is the crossfader and the preview-Buttons. On my machine, in 4 and 2 deck mode without the mixer there is some space where the mixxx logo is displayed. Would it be possible to get the crossfader (and maybe the cue-buttons) there? That would result in the big waveforms for me. Another option would be to make the waveforms (nearly) screen- wide and place pitch, EQ, Volume, Cue, on the left and right (as pitch was in 1.11). That would only leave crossfader, Master, Balance, HeadGain and Pre/Main from the mixer-section what could eventually be placed like proposed above where the mixxx logo is, in between of previewDeck and maybe Mics. [pitch/EQ/Vol Deck1] [Waveform 1] [pitch/EQ/Vol Deck2] [--] [Waveform 3] [--] [pitch/EQ/Vol Deck3] [Waveform 2] [pitch/EQ/Vol Deck4] [--] [Waveform 4] [--] [ Deck1 ] [ Deck2 ] [ Deck3 ] [ Deck4 ] [PreviewDeck] [ Crossfade/Master ] [Microphones] [Samplers] [Effects] [Library] I've done a quick sketch http://imgur.com/MruunAd I've not rescaled anything except some little changes and this dosn't get bigger than the current approach but gives much bigger waveforms. But I am unsure if this is out of scope for LateNight and should better be done in an other skin. What do you think? Cheers, Markus Am 08.06.2015 um 03:44 schrieb Be: I tested it and it helps, but adding these options feels like putting bandages on a bigger design issues that are not very easy to solve. There are so many buttons for skin options at the top that it's kinda overwhelming. However, I think trying to implement better solutions to those design challenges would take a lot of effort that shouldn't delay 1.12. Any thoughts on the general outline I proposed? [master gain][balance][head mix][head gain][4/2 deck toggle] [Deck 1][Deck 1/2 mixer][Deck 2] waveform 1 waveform 2 waveform 3 waveform 4 [Deck 3][Deck 3/4 mixer][Deck 4] On 06/06/2015
Re: [Mixxx-devel] scrollbars
On 06/08/2015 09:24 PM, re-cy...@hushmail.com wrote: Is there any framework currently or on the horizon for *any* of the various scrollbars to be midi-scriptable? Perhaps with the control system redesign we've been planning for awhile now. Please file a wishlist bug on this so we can track it. Sincerely, Sean M. Pappalardo D.J. Pegasus Mixxx Developer - Controller Specialist smime.p7s Description: S/MIME Cryptographic Signature -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] LateNight skin (was: release progress)
Is mentioned earlier - I don't want (you) to clutter LateNight with dozens of configs. I think the proposed one should get another skin. LateNight as it is now is much more structured and easier to understand for new users than the suggested approach is - even if it has some advantages. Just wanted to give my two cents to this thread, didn't ment to rework LateNight - I think its fine for most users. Am 09.06.2015 um 16:23 schrieb Owen Williams: At this point we've reached the end of the road for how flexible LateNight can be. It's fairly flexible already, and every bit of flexibility I try to add beyond that is causing ripple effects for other layouts. So for now, if you want to experiment with other options, I'd suggest you fork the skin and try moving the pieces around. It might be fun to resurrect LateNight-wide (which may still be in the developer_skins repo) and see if it can be made to behave better. On Tue, 2015-06-09 at 05:05 +, re-cy...@hushmail.com wrote: So there's the space beneath the left deck - where the preview deck lives. The space on the other side is empty. Can the micaux array get shrunk a bit and fit over there? That would save some space, plus be nice and symmetrical. ~RAWRR On Mon, 08 Jun 2015 21:34:41 + re-cy...@hushmail.com wrote: On Mon, 08 Jun 2015 21:15:37 + Daniel Schürmann dasch...@mixxx.org wrote: If I recall it correct, it should help. This has also the benefit that you can see more tracks in the library. And whatever other controls as well... interesting. Am 08.06.2015 um 23:10 schrieb re-cy...@hushmail.com: Interesting re: CPU. What do you think about decreasing the height but keeping the width re: CPU? ~RAWRR On Mon, 08 Jun 2015 21:00:52 + Daniel Schürmann dasch...@mixxx.org wrote: Hi Markus, Nice mock-up. In the past we had issues with four full size Waveforms because the CPU usage increases with the size. So I am afraid that view does not suit to be part of Mixxx default skin. IMHO we have already more then enough view options in the LateNight skin. But there should be no problem with a recent devices. If this is the perfect skin for you use case, you are welcome to fork it. Thats the benefit of our skin engine. Kind regards. Daniel Am 08.06.2015 um 18:42 schrieb Markus Klösges: Any thoughts on the general outline I proposed? [master gain][balance][head mix][head gain][4/2 deck toggle] [Deck 1][Deck 1/2 mixer][Deck 2] waveform 1 waveform 2 waveform 3 waveform 4 [Deck 3][Deck 3/4 mixer][Deck 4] I'm using Mixxx without controller without scratching and so on, just simple crossfading with external mixer and so on. I would also prefer the option to have the (almost) screen- wide waveforms. I liked the 'old' 1.11 Latenight. Clearly that doesn't work out for 4 decks. I think one should not clutter a skin with dozens of config- options but better fork that skin (or decide for one, better, solution maybe). The option to get the bigLibrary is a real benefit for me and results in lesser need of a large library when everything is turned on. The only reason I have the mixer turned on is the crossfader and the preview-Buttons. On my machine, in 4 and 2 deck mode without the mixer there is some space where the mixxx logo is displayed. Would it be possible to get the crossfader (and maybe the cue-buttons) there? That would result in the big waveforms for me. Another option would be to make the waveforms (nearly) screen- wide and place pitch, EQ, Volume, Cue, on the left and right (as pitch was in 1.11). That would only leave crossfader, Master, Balance, HeadGain and Pre/Main from the mixer-section what could eventually be placed like proposed above where the mixxx logo is, in between of previewDeck and maybe Mics. [pitch/EQ/Vol Deck1] [Waveform 1] [pitch/EQ/Vol Deck2] [--] [Waveform 3] [--] [pitch/EQ/Vol Deck3] [Waveform 2] [pitch/EQ/Vol Deck4] [--] [Waveform 4] [--] [ Deck1 ] [ Deck2 ] [ Deck3 ] [ Deck4 ] [PreviewDeck] [ Crossfade/Master ] [Microphones] [Samplers] [Effects] [Library] I've done a quick sketch http://imgur.com/MruunAd I've not rescaled anything except some little changes and this dosn't get bigger than the current approach but gives much bigger waveforms. But I am unsure if this is out of scope for LateNight and should better be done in an other skin. What do you think? Cheers, Markus Am 08.06.2015 um 03:44 schrieb Be: I tested it and it helps, but adding these options feels like putting bandages on a bigger design issues that are not very easy to solve. There are so many buttons for skin options at the top that it's kinda overwhelming. However, I think trying to implement better solutions to those design challenges would take a lot of effort that shouldn't delay 1.12. Any thoughts on the general
Re: [Mixxx-devel] Fwd: Re: formating source Code with clang-format
On Tue, Jun 9, 2015 at 4:37 PM, Daniel Schürmann dasch...@mixxx.org wrote: Hi I have very bad experience in a similar size closed source project. The code was cluttered and the source control blame feature broken When a line is auto-formatted you can just blame from that revision to find the real line. How often do we run git blame versus argue about style on a PR? We finally revert all the auto formated stuff. It works beautifully at Google -- nobody wastes any time worrying about formatting while writing code or code reviewing for style issues anymore. It's a gigantic time saver. IMHO a code style checker will help to get around the noise in the PRs. We can also provide an auto-formater for manual use. I can remember that RJs biggest issue in the clang autotransformer was the alignment with the open parenthesis. If we set it just to double indent most issues should be solved (sove-able) IMHO the open parenthesis alignment needs a developer to check if the readability is actually improved. Basically, the way you do it is you say whatever clang-format does is correct and stop worrying about it. I know you dislike certain aspects of Google C++ style -- and in our previous discussions I've allowed you to just change our style guide because I didn't want to waste any more time arguing with you. So this is a solution to that problem. Uwe and I had a code style discussion during the review of the Sound Source branch. After Uwe relies on the Eclipse formatter, which also just uses double indent for line brakes all issues were gone. So there is no need to change our code style and reformat the whole Mixxx source to a new style. I disagree! Kind regards, Daniel Am 09.06.2015 um 22:08 schrieb RJ Ryan: I'm for this -- we waste too much time arguing about code style and spend way too much time cleaning up code. We do differ from Google C++ style in certain ways. I'm for eliminating most of the differences. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote: Hi, I did recently, as asked by RJ, added some coding style commit in a PR, particularly on the following rule: _Plain-text comments should be separated from the comment symbol by a single space. Commented-out code should have no space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Todayhttp://mixxx.org Mixxx-devel mailing listMixxx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
[Mixxx-devel] Fwd: Re: formating source Code with clang-format
Hi I have very bad experience in a similar size closed source project. The code was cluttered and the source control blame feature broken We finally revert all the auto formated stuff. IMHO a code style checker will help to get around the noise in the PRs. We can also provide an auto-formater for manual use. I can remember that RJs biggest issue in the clang autotransformer was the alignment with the openparenthesis. If we set it just to double indent most issues should be solved (sove-able) IMHO the openparenthesis alignment needs a developer to check if the readability is actually improved. Uwe and I had a code style discussion during the review of the Sound Source branch. After Uwe relies on the Eclipse formatter, which also just uses double indent for line brakes all issues were gone. So there is no need to change our code style and reformat the whole Mixxx source to a new style. Kind regards, Daniel Am 09.06.2015 um 22:08 schrieb RJ Ryan: I'm for this -- we waste too much time arguing about code style and spend way too much time cleaning up code. We do differ from Google C++ style in certain ways. I'm for eliminating most of the differences. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de mailto:max_li...@gmx.de wrote: On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote: Hi, I did recently, as asked by RJ, added some coding style commit in a PR, particularly on the following rule: _Plain-text comments should be separated from the comment symbol by a single space. Commented-out code should have no space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net mailto:Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
I'm for this -- we waste too much time arguing about code style and spend way too much time cleaning up code. We do differ from Google C++ style in certain ways. I'm for eliminating most of the differences. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote: Hi, I did recently, as asked by RJ, added some coding style commit in a PR, particularly on the following rule: _Plain-text comments should be separated from the comment symbol by a single space. Commented-out code should have no space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
On 06/09/2015 01:08 PM, RJ Ryan wrote: It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. Well shoot, let's do it in master tomorrow. Seriously. Sincerely, Sean M. Pappalardo D.J. Pegasus Mixxx Developer - Controller Specialist smime.p7s Description: S/MIME Cryptographic Signature -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
On 06/09/2015 10:08 PM, RJ Ryan wrote: I'm for this -- we waste too much time arguing about code style and spend way too much time cleaning up code. We do differ from Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote: Hi, I did recently, as asked by RJ, added some coding style commit in a PR, particularly on the following rule: _Plain-text comments should be separated from the comment symbol by a single space. Commented-out code should have no space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel --- Language:Cpp # BasedOnStyle: Google AccessModifierOffset: -2 AlignAfterOpenBracket: true AlignEscapedNewlinesLeft: true AlignOperands: true AlignTrailingComments: true AllowAllParametersOfDeclarationOnNextLine: true AllowShortBlocksOnASingleLine: false AllowShortCaseLabelsOnASingleLine: false AllowShortIfStatementsOnASingleLine: false AllowShortLoopsOnASingleLine: false AllowShortFunctionsOnASingleLine: Inline AlwaysBreakAfterDefinitionReturnType: false AlwaysBreakTemplateDeclarations: true AlwaysBreakBeforeMultilineStrings: true BreakBeforeBinaryOperators: None BreakBeforeTernaryOperators: true BreakConstructorInitializersBeforeComma: false BinPackParameters: true BinPackArguments: true ColumnLimit: 80 ConstructorInitializerAllOnOneLineOrOnePerLine: true ConstructorInitializerIndentWidth: 8 DerivePointerAlignment: true ExperimentalAutoDetectBinPacking: false IndentCaseLabels: true IndentWrappedFunctionNames: false IndentFunctionDeclarationAfterType: false MaxEmptyLinesToKeep: 1 KeepEmptyLinesAtTheStartOfBlocks: false NamespaceIndentation: None ObjCBlockIndentWidth: 2 ObjCSpaceAfterProperty: false ObjCSpaceBeforeProtocolList: false PenaltyBreakBeforeFirstCallParameter: 1 PenaltyBreakComment: 300 PenaltyBreakString: 1000 PenaltyBreakFirstLessLess: 120 PenaltyExcessCharacter: 100 PenaltyReturnTypeOnItsOwnLine: 200 PointerAlignment: Left SpacesBeforeTrailingComments: 1 Cpp11BracedListStyle: true Standard:Auto IndentWidth: 4 TabWidth:4 UseTab: Never BreakBeforeBraces: Attach SpacesInParentheses: false SpacesInSquareBrackets: false SpacesInAngles: false SpaceInEmptyParentheses: false SpacesInCStyleCastParentheses: false SpaceAfterCStyleCast: false SpacesInContainerLiterals: true SpaceBeforeAssignmentOperators: true ContinuationIndentWidth: 8 CommentPragmas: '^ IWYU pragma:' ForEachMacros: [ foreach, Q_FOREACH, BOOST_FOREACH ] SpaceBeforeParens: ControlStatements DisableFormat: false ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
Example: https://github.com/mixxxdj/mixxx/pull/616 On Tue, Jun 9, 2015 at 4:52 PM, Max Linke max_li...@gmx.de wrote: On 06/09/2015 10:08 PM, RJ Ryan wrote: I'm for this -- we waste too much time arguing about code style and spend way too much time cleaning up code. We do differ from Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote: Hi, I did recently, as asked by RJ, added some coding style commit in a PR, particularly on the following rule: _Plain-text comments should be separated from the comment symbol by a single space. Commented-out code should have no space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] Fwd: Re: formating source Code with clang-format
On Tue, Jun 9, 2015 at 4:43 PM, RJ Ryan rr...@mixxx.org wrote: I can remember that RJs biggest issue in the clang autotransformer was the alignment with the open parenthesis. If we set it just to double indent most issues should be solved (sove-able) FWIW this was Emacs code formatting, not clang-format. I don't believe I ever shared the results of my previous experiments with using clang-format in mixxx. BTW: https://bugs.launchpad.net/bugs/1392757 -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
If auto line breaking is done, I could support 120+. The old 80 char limit doesn't make sense anymore. On Tue, Jun 9, 2015, 3:03 PM Daniel Schürmann dasch...@mixxx.org wrote: After skimming though the PR, I can see my objections confirmed regarding auto formated line breaks. On the other hand I see that most other issues are handled well. I think I will support such mass refactoring, if it does not introduce line breaks. For my feeling we have no readability issues with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: Example: https://github.com/mixxxdj/mixxx/pull/616 On Tue, Jun 9, 2015 at 4:52 PM, Max Linke max_li...@gmx.de wrote: On 06/09/2015 10:08 PM, RJ Ryan wrote: I'm for this -- we waste too much time arguing about code style and spend way too much time cleaning up code. We do differ from Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote: Hi, I did recently, as asked by RJ, added some coding style commit in a PR, particularly on the following rule: _Plain-text comments should be separated from the comment symbol by a single space. Commented-out code should have no space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Todayhttp://mixxx.org Mixxx-devel mailing listMixxx-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] formating source Code with clang-format
I agree that 80 columns is restrictive with 4-space tabs. I personally like a variant of the Go formatting rules, which are basically don't worry about line length. I aim for 100, but if something is a few characters over, I let it go long. No one wants to scroll horizontally, but I also dislike heavily-wrapped statements. That said, I do like clang-format a lot, and I have eclipse set up to use it. I can just push ctrl-shift-f on any line, and it formats it for me. That way I can just write a messy line without regard for style, then let the software format it and add line breaks. Once we pick a set of clang settings, I don't want to do a lot of haggling about where clang fails -- just let it do what it wants and move on. I can live with 80 or whatever others prefer On Wed, 2015-06-10 at 00:02 +0200, Daniel Schürmann wrote: After skimming though the PR, I can see my objections confirmed regarding auto formated line breaks. On the other hand I see that most other issues are handled well. I think I will support such mass refactoring, if it does not introduce line breaks. For my feeling we have no readability issues with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: Example: https://github.com/mixxxdj/mixxx/pull/616 On Tue, Jun 9, 2015 at 4:52 PM, Max Linke max_li...@gmx.de wrote: On 06/09/2015 10:08 PM, RJ Ryan wrote: I'm for this -- we waste too much time arguing about code style and spend way too much time cleaning up code. We do differ from Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de wrote: On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote: Hi, I did recently, as asked by RJ, added some coding style commit in a PR, particularly on the following rule: _Plain-text comments should be separated from the comment symbol by a single space. Commented-out code should have no space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ...
Re: [Mixxx-devel] formating source Code with clang-format
After skimming though the PR, I can see my objections confirmed regarding auto formated line breaks. On the other hand I see that most other issues are handled well. I think I will support such mass refactoring, if it does not introduce line breaks. For my feeling we have no readability issues with long lines in current master, So there is no need to risk the clutter. Am 09.06.2015 um 22:54 schrieb RJ Ryan: Example: https://github.com/mixxxdj/mixxx/pull/616 On Tue, Jun 9, 2015 at 4:52 PM, Max Linke max_li...@gmx.de mailto:max_li...@gmx.de wrote: On 06/09/2015 10:08 PM, RJ Ryan wrote: I'm for this -- we waste too much time arguing about code style and spend way too much time cleaning up code. We do differ from Google C++ style in certain ways. I'm for eliminating most of the differences. +1 But I also attach the clang-format file I currently use. It is closest to the style we currently use. We should do a 1-step reformat-the-world and then distribute a commit hook to reformat. That will prevent a lot of unrelated noise in PRs. It looks like reformatting the world will change about 32k lines. That's a small price to pay for never having to worry about this again. On Mon, Jun 8, 2015 at 4:50 AM, Max Linke max_li...@gmx.de mailto:max_li...@gmx.de wrote: On 06/08/2015 09:51 AM, Sébastien BLAISOT wrote: Hi, I did recently, as asked by RJ, added some coding style commit in a PR, particularly on the following rule: _Plain-text comments should be separated from the comment symbol by a single space. Commented-out code should have no space between the comment symbol and the code_ I'm not sure that this kind of rule can be automatically enforced (detecting if comment is code or plain text is not easy). Yeah this is not possible. The best solution would be to delete the dead-code. We actually have some useful dead debug statements somewhere but most code gets deleted eventually anyway. And personally I'm not so set on the spacing rule for code vs text comments. Every commenting engine I used so far can't handle this case. +1 for automatic code review that can enforce coding style, security and sanity checks, ... -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net mailto:Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] can't edit wiki
My username being under three characters was the issue. The registration form was fooled because I put a period after two letters, but when I logged in it showed the user as be without the period at the end. I reproduced the issue with other usernames with two characters and a period. I registered a new user for myself (be.ing) and opened a bug report for DocuWiki: https://github.com/splitbrain/dokuwiki/issues/1190 On 06/05/2015 01:32 PM, S.Brandt wrote: The permissions for your user are fine, you should be able to edit. Did reset your user, and you should have received a new password. If you still can`t edit, try to edit your user settings to have a real name longer than two characters. Alternatively, register another user with a longer user name as a test. Might be a bug in the wiki software. On Jun 5, 2015, at 7:28 PM, Be b...@gmx.com wrote: This happens on every page. On 06/05/2015 12:04 PM, S.Brandt wrote: Please link to the page(s) you`re trying to edit, will check permissions. On Jun 5, 2015, at 6:57 PM, Be b...@gmx.com wrote: I'm still getting this error. There are a number of edits I've been waiting to make around the wiki. On 04/06/2015 09:43 AM, Owen Williams wrote: I'll see if I can figure out what's going on On Mon, 2015-04-06 at 09:27 -0500, Be wrote: Any idea what's going on with this? Pegasus said he has no trouble editing the wiki. Did something get messed up with registering new users when hard drive space was cleared recently? On 03/26/2015 06:56 PM, Be wrote: I recently registered an account (be) on the wiki. Whenever I try to edit a page, I get an unhelpful error: Sorry, there was an error processing your request. If this is an error contact us at info AT mydomain.com. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- ___ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
