Thanks for the clarification on the subject/body best practice. I'll take a look at adding a 72 character line.
As an improvement, should there actually be separate Subject and Body text fields that, on commit, are combined as a single commit message with a blank line separating, and where the subject field is limited to 50 characters and the body field contents wrap at 72 characters? Yes, the two text fields would forcibly constrain the input to match the best practice, but two lines don't directly inform the user how they are to be used. (Originally I thought the line was a drawing bug, not a feature.) For VIM (or TextMate) the text coloring is the only available guideline, but a full GUI allows for a more direct "solution". Thoughts? Dave On Oct 31, 9:18 am, David James <[email protected]> wrote: > On my system, I just confirmed: > * in the commit view, gitx consumes roughly 7% CPU > * in the history view, gitx does not consume the CPU > > Here's the rationale for the 50 character line:http://www.tpope.net/node/106 > > I also wrote a post to this list requesting more nudges about well-formed > commit > messages:http://groups.google.com/group/gitx/browse_thread/thread/9740cf9d9e2c... > > " > I've noticed that gitx currently has a vertical bar to help us > > remember the *50 **character* mark. Could we also add something similar > for the 72 *character* mark? > > It might be worth considering using the approach using with VIM > integration:http://vim.runpaint.org/extending/integrating-vim-with-git/ > " > > > > On Fri, Oct 30, 2009 at 2:09 PM, David Anderson <[email protected]> wrote: > > For every project I'd have open in GitX another 10% of my CPU would get > > consumed. However, this would only occur when the commit view was visible, > > not when the History view was open. After a bit of time in Shark, I could > > see that the PBCommitMessageView drawRect: method was one of the two > > contributors to CPU usage. > > > I don't personally understand the reason for the feature, but the vertical > > line indicating a 50 column width in the PBCommitMessageView was causing the > > entire text view to be redrawn with each cursor blink (in and out) for the > > key window. Instead of keeping the subclassed NSTextView, I placed a > > subclassed NSView behind the NSTextView, and then I set the (commit) > > NSScrollView and NSTextView to not draw their background. Now when the > > cursor blinks, only the single line of the NSTextView is redrawn, and the > > dirty portion of the subclassed NSView (PBCommitMessageBackgroundView) is > > redrawn. The PBCommitMessageBackgroundView references the commit NSTextView > > for the typing attributes, background color, etc. > > > The other significant contributor to CPU usage was the Commit button fading > > in and out continuously. While it looks nice for panels and alerts, the > > NSButton with the Return key equivalent is not appropriate for the Commit > > window. The NSTextView (formerly PBCommitMessageView) is first responder > > and accepts the Return character, thereby masking the Commit button from > > receiving the key equivalent. Removing the key equivalent binding for the > > Commit button eliminated the remaining CPU usage. > > > With these two changes, and three projects open in GitX on the Commit view, > > the CPU usage for the active application has gone from ~33% to ~0.3%. When > > GitX is not the active application, CPU usage drops to 0.0%. > > > I'm not sure if/how you want to incorporate the .xib changes (as we appear > > to be using different versions of the dev tools), but please find the > > attached patches for my changes. > > > Dave
