I just noticed the new commit window in the latest release of TM2. My initial reaction is that I don't like it. Here's a couple of comments:
* The new look feels quite heavy. It uses a lot of textured/brushed (or what they're called) controls. I get the feeling that Apple is moving more towards controls that feel more lightweight
* The bottom bar doesn't look like the one in the main window
* It's not possible to change the height of the commit message text view
* The cancel button doesn't properly work. The other window that also opens still waits for a commit message (or something) after the commit window is closed
* One thing that's been bugging me or quite a while is that when doing an amend the check box for updating the commit message is enabled by default but there's no commit message. The commit message of the commit being amended should automatically be inserted in the text view and all text should be selected. This makes it easy to just change the commit message when amending. Or just add new changes without updating the commit message, all without needing to use the mouse
On Wed, Apr 9, 2014 at 1:52 PM, Jacob Carlborg doob@me.com wrote:
- The cancel button doesn't properly work. The other window that also
opens still waits for a commit message (or something) after the commit window is closed
Most of the functionality is actually controlled by the scm bundles. For the git bundle, it initially writes output to the html output window before opening the commit window. I have a pull request submitted to only show the html output window after closing the commit window (e.g., canceling or committing). Maybe we should also not send anything to the output window when canceling the commit too? So for this case (canceling) the other window would not be displayed at all.
- One thing that's been bugging me or quite a while is that when doing an
amend the check box for updating the commit message is enabled by default but there's no commit message. The commit message of the commit being amended should automatically be inserted in the text view and all text should be selected.
The commit window does accept a "--log" option that does just as you describe. Although I am not not aware of any bundle actually using this option (maybe the svn bundle??, I've only looked that the git and hg bundles). Also, the git bundle labels the "update commit message" as "M" which tells the commit window to enable it by default.
I do have a local change for the git bundle to include the last commit message automatically. As for the "enable by default", the status could be change to "?" or "X", I think, so that it is not enabled by default.
I am willing to submit pull requests to make the necessary changes to the git bundle to accommodate your comments, if that would be something of general interest.
Ron
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 10 Apr 2014, at 4:12, Ronald Wampler wrote:
[…] Maybe we should also not send anything to the output window when canceling the commit too? So for this case (canceling) the other window would not be displayed at all.
I think this makes sense since there is no useful info in the window (after cancel).
[…] the git bundle labels the "update commit message" as "M" which tells the commit window to enable it by default.
I’ve always found this behavior confusing and would gladly see it replaced with just showing the message in the commit window where the user can then either keep it or edit it.
I do have a local change for the git bundle to include the last commit message automatically.
You mean always show the last commit message, even when we are not doing an ammend? I wouldn’t personally like that, but I believe that the “Previous Commit Messages” feature was originally done because someone had a lot of boilerplate in their commits, so wanted to re-use a majority of the last commit message.
If your scenario is similiar then perhaps allowing to set a template would be better.
As for the "enable by default", the status could be change to "?" or "X", I think, so that it is not enabled by default.
What does it mean to not have previous commit message enabled? That we are required to either enter a new message or enable it? I think we should strive for eliminating the item to clear up this confusion.
I am willing to submit pull requests to make the necessary changes to the git bundle to accommodate your comments, if that would be something of general interest.
I would be happy to merge a pull request for showing last commit message for ammend (not in general), not opening HTML output window for cancel, and setting auto-save frame name for commit window.
I don’t know if you extracted any potential visual tweaks from Jacob’s feedback. Tbh I am not too happy about the look of the bottom bar, but I haven’t been able to come up with something better. Apple’s guidelines say to try and avoid bottom bars and place actions in the toolbar instead, but that doesn’t seem right for this window, and they have similiar bottom bar themselves e.g. in the iCloud Open dialog (try Preview → Open). Though Apple’s top bar is much lighter, but also a bit non-standard (no close/minimize buttons).
On Wed, Apr 9, 2014 at 9:41 PM, Allan Odgaard mailinglist@textmate.orgwrote:
On 10 Apr 2014, at 4:12, Ronald Wampler wrote:
I’ve always found this behavior confusing and would gladly see it replaced with just showing the message in the commit window where the user can then either keep it or edit it.
I do have a local change for the git bundle to include the last commit
message automatically.
You mean always show the last commit message, even when we are not doing an ammend?
No, that should have read "include the last commit message automatically when amending a commit" :(.
As for the "enable by default", the status could be
change to "?" or "X", I think, so that it is not enabled by default.
What does it mean to not have previous commit message enabled? That we are required to either enter a new message or enable it? I think we should strive for eliminating the item to clear up this confusion.
Looking at *Git → Amend...*, it appears if this is not enabled the commit message in the text view is not used (i.e., the last commit message is used). I agree with you that we could eliminate the item if we just auto fill the textview with the last commit message then the user can choose to edited it or not. This behavior would be consistent with the way amending a commit works when running "git commit --amend" from the command line.
Related to this I realize I forgot to implement the --log option. I will be submitting a patch soon to fix this regression.
I am willing to submit pull requests to make the necessary changes to the
git bundle to accommodate your comments, if that would be something of general interest.
I would be happy to merge a pull request for showing last commit message for ammend (not in general), not opening HTML output window for cancel, and setting auto-save frame name for commit window.
Thanks, I will submit patches soon.
Tbh I am not too happy about the look of the bottom bar, but I haven’t been able to come up with something better.
Agreed. Unfortunately, I can't think of anything neither.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 10/04/14 05:10, Ronald Wampler wrote:
Looking at /Git → Amend.../, it appears if this is not enabled the commit message in the text view is not used (i.e., the last commit message is used). I agree with you that we could eliminate the item if we just auto fill the textview with the last commit message then the user can choose to edited it or not. This behavior would be consistent with the way amending a commit works when running "git commit --amend" from the command line.
Exactly.
On 10/04/14 03:41, Allan Odgaard wrote:
I don’t know if you extracted any potential visual tweaks from Jacob’s feedback. Tbh I am not too happy about the look of the bottom bar, but I haven’t been able to come up with something better. Apple’s guidelines say to try and avoid bottom bars and place actions in the toolbar instead, but that doesn’t seem right for this window, and they have similiar bottom bar themselves e.g. in the iCloud Open dialog (try Preview → Open). Though Apple’s top bar is much lighter, but also a bit non-standard (no close/minimize buttons).
I would probably have used a standard window (not textured) and placed the buttons at the bottom, like a dialog.
I can give it some more thought and see if I can come up with something better?
BTW, what was the original reason to use a textured window, to better match the status bar of the text view?
On 10 Apr 2014, at 15:18, Jacob Carlborg wrote:
[ Commit Window ] I can give it some more thought and see if I can come up with something better?
That’d be appreciated. Also look a the find/clipboard history windows, as they have the same bottom bar. I also want to extend the bundle item chooser with buttons, so would be good to come up with a single style.
BTW, what was the original reason to use a textured window, to better match the status bar of the text view?
Yes, but come to think of it, I don’t think we need a status bar in the commit window.
The status bar is also a hindrance for using a split view, although I am not sure we really need that.
On 10/04/14 11:29, Allan Odgaard wrote:
That’d be appreciated.
I've come up with a couple of suggestions. Where would be a good place to put these images?
Also look a the find/clipboard history windows, as they have the same bottom bar.
I found the clipboard history window, is there some other windows as well?
I also want to extend the bundle item chooser with buttons, so would be good to come up with a single style.
Which view/window is this?
Yes, but come to think of it, I don’t think we need a status bar in the commit window.
Yeah, I don't really see the point of having it in the commit window.
The status bar is also a hindrance for using a split view, although I am not sure we really need that.
Is it?
On 10/04/14 11:29, Allan Odgaard wrote:
That’d be appreciated.
Here are a bunch of suggestions for the commit window:
* https://dl.dropboxusercontent.com/u/18386187/commit_mocks/commit_default.png
This one uses a regular window, a scope bar and a lighter color for the status bar. There should only be one button with a gear icon.
* https://dl.dropboxusercontent.com/u/18386187/commit_mocks/commit_light_conte...
The same as the above but uses the new style for controls, Light Content, available in 10.9.
* https://dl.dropboxusercontent.com/u/18386187/commit_mocks/commit_non_texture...
This one is like the first one but without the textured look for the status bar.
* https://dl.dropboxusercontent.com/u/18386187/commit_mocks/commit_no_status_n...
This one has no scope bar and no status bar. The "diff" button is supposed to be a regular button, not a drop down, but with the Round Rect style.
* https://dl.dropboxusercontent.com/u/18386187/commit_mocks/medium_bottom_bar....
As the previous one, but with a different style for the bottom bar.
* https://dl.dropboxusercontent.com/u/18386187/commit_mocks/mini_bottom_bar.pn...
As the previous one but with a minimal bottom bar. I tried to mimic the bottom bar that can be seen in Mail and Xcode, in the bottom left corner. But I guess this style works best for buttons that are only icons and no text. The buttons should have separators between them, this can be seen in Xcode.
* https://dl.dropboxusercontent.com/u/18386187/commit_mocks/mini_bottom_bar_bu...
A variation of the one above. This one has visible buttons for the commit and cancel buttons.
* https://dl.dropboxusercontent.com/u/18386187/commit_mocks/commit_calendar.pn...
For this one I tried to emulate the look of the info window used in Calendar for events. This one is a bit more rough looking since I created this one with a graphics program, for the others I used Xcode Interface Builder. This one is the one that looks most different and also will require most work.
On 10 Apr 2014, at 0:52, Jacob Carlborg wrote:
- The new look feels quite heavy. It uses a lot of textured/brushed
(or what they're called) controls. I get the feeling that Apple is moving more towards controls that feel more lightweight
The new window is closer to the rest of TextMate’s UI. Yes, it looks heavier because there are more controls than the previous commit window (the text view’s status bar) and it uses textured controls because it’s using a textured window.
I am not sure what to take from this. You want a visually lighter commit window that doesn’t use the textured window look? If so, the text view’s status bar would probably need to be updated to match such window.
Though this is one of the things where I suggest you use it for a few weeks before commenting on how it subjectively feels, although specific suggestions/mockups are received with gratitude.
- The bottom bar doesn't look like the one in the main window
Should it? The main window has a status bar with info to be read, the commit window has a bottom bar with actions represented via bordered controls.
- It's not possible to change the height of the commit message text
view
You can resize the window to make it taller (TODO set auto-save name for the window).
- The cancel button doesn't properly work. The other window that also
opens still waits for a commit message (or something) after the commit window is closed
By “doesn’t properly work” you mean that the HTML output window does not (also) go away? But instead writes that the commit was cancelled?
On 10/04/14 03:31, Allan Odgaard wrote:
The new window is closer to the rest of TextMate’s UI. Yes, it looks heavier because there are more controls than the previous commit window (the text view’s status bar) and it uses textured controls because it’s using a textured window.
I am not sure what to take from this. You want a visually lighter commit window that doesn’t use the textured window look?
Yeah, I would probably not have used a textured window. I have not seen this much at all in applications. If the bottom bar looked like that status bar and the gear button looked like the gear button in the status bar I think it would look lighter.
If so, the text view’s status bar would probably need to be updated to match such window.
Yes, even now it looks a bit out of place. Status bars looking like this are usually at the bottom of windows, not in the middle of a window.
Though this is one of the things where I suggest you use it for a few weeks before commenting on how it subjectively feels,
Yeah, probably.
although specific suggestions/mockups are received with gratitude.
I might have a look at that.
Should it? The main window has a status bar with info to be read, the commit window has a bottom bar with actions represented via bordered controls.
I think it looks a bit weird.
You can resize the window to make it taller (TODO set auto-save name for the window).
Well yes. But the previous implementation had a split view where I could change the height of the text control relative to the list of files.
By “doesn’t properly work” you mean that the HTML output window does not (also) go away? But instead writes that the commit was cancelled?
It doesn't write anything. It just waits. When I close the window I get a dialog asking if I want to stop the sub task (or similar).
On 10 Apr 2014, at 15:03, Jacob Carlborg wrote:
You can resize the window to make it taller (TODO set auto-save name for the window).
Well yes. But the previous implementation had a split view where I could change the height of the text control relative to the list of files.
Do you need this functionality?
By “doesn’t properly work” you mean that the HTML output window does not (also) go away? But instead writes that the commit was cancelled?
It doesn't write anything. It just waits. When I close the window I get a dialog asking if I want to stop the sub task (or similar).
Can you check if the process is still running? The simplest way is to install pstree and run: pstree $(pgrep TextMate)
Run this before/after cancelling the commit window.
Can you check if any exception is thrown from TextMate? This should be in console but to be sure you see everything https://github.com/textmate/textmate/wiki/Enable-Logging
On 11/04/14 05:41, Allan Odgaard wrote:
Do you need this functionality?
It would be nice to have. Sometimes the relative size of the text view and the table is not that good. I see no reason why this was removed. It's not super important, it's more annoying that it was there previously and worked fine and now it's removed, for now apparent reason.
Can you check if the process is still running? The simplest way is to install pstree and run: pstree $(pgrep TextMate)
Run this before/after cancelling the commit window.
Can you check if any exception is thrown from TextMate? This should be in console but to be sure you see everything https://github.com/textmate/textmate/wiki/Enable-Logging
Hmm, I can't reproduce this anymore. But this time I don't get the output window until I cancel the commit. Previously I got the output window simultaneously as the commit window appeared. I'll let you know if I see the problem again.
On 2014-04-11 08:13, Jacob Carlborg wrote:
Hmm, I can't reproduce this anymore. But this time I don't get the output window until I cancel the commit. Previously I got the output window simultaneously as the commit window appeared. I'll let you know if I see the problem again.
Hmm, I still have problem on one my computers. I don't know if it matters but I'm running OS X 10.9 on the computer where it works and 10.8.5 where it doesn't work.
On 12 Apr 2014, at 18:19, Jacob Carlborg wrote:
Hmm, I still have problem on one my computers. I don't know if it matters but I'm running OS X 10.9 on the computer where it works and 10.8.5 where it doesn't work.
Can you check for exception and see if commit process is running for the machine where it breaks?
On 14/04/14 04:39, Allan Odgaard wrote:
On 13 Apr 2014, at 16:49, Jacob Carlborg wrote:
[…] I can't see any exceptions but the commit process is running.
Does the problem occur both using the Cancel button and the commit window’s close button?
Yes, if I recall correctly.
On 09/04/14 19:52, Jacob Carlborg wrote:
I just noticed the new commit window in the latest release of TM2. My initial reaction is that I don't like it. Here's a couple of comments:
I found another problem, I can't use the Enter key to perform the commit anymore.
-
Allan Odgaard -
Jacob Carlborg -
Ronald Wampler