You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ok, I know this is a very large topic. So this should be a discussion on what GitX could look like in the future. Design is something very opinionated. So instead of opening random pull requests with changes most of the other contributors disagree with seems like a waste of time.
I did a very brief (and quality wise bad) mockup just that we have something to start with. It shows of a unified toolbar with all the buttons in one place. This design would get rid of both the scope bar and the bottom tool bar.
What do you think?
Reacted by AB, Yukai Huang, Alex Hesse, Tim Hutt and Zach
Looks like a good start! Some things that come to mind:
I'm not sure a unified toolbar is appropriate here because you lose the document proxy icon (which you can also use to see the path of the repository - I tend to use this a lot because I have the same repositories as submodules in many different places).
What would the toolbar look like in the commit view? A lot of those buttons are specific to the history view.
Losing the bottom toolbar makes sense to me. The loading progress indicator could be put somewhere temporarily (maybe in the toolbar or at the bottom-left in the source list).
The scope bar is useful for hiding commits not in the active branch. Getting rid of it makes sense, but wouldn't that need to be moved somewhere else rather than eliminated altogether?
Thanks for your thoughts!
I'll answer them one by one:
• I agree and have thought of this problem as well. Maybe we could implement another white view here in the center middle (similar to Xcode) which behaves the same way the document title does.
• I haven't looked into that one yet 🤔
• Yep! We could also move some of the buttons I've put into the toolbar back to the bottom into the source list. (Again like Xcode)
• That's what I've inserted the super crappy looking "Filter" button next to the search field. Clicking that could reveal a popover with all the filtering options GitX provides
Happy to provide any other feedback. In addition to the proxy icon, there'd need to be some sort of indication what repository is open. Your mockup doesn't show that at all right now. In cases like this it seems like just using the free behavior from NSDocument is simplest in terms of being maintenance free, but that's just my opinion :)
It'd probably be good to get opinions from other people that actually use some of those toolbar buttons. I tend to do any management like that through the command line, so if most of those buttons were to disappear I wouldn't notice (not that I'm suggesting they get removed).
Having the toolbar be a real NSToolbar with its full customize interface would be great! Merging the bottom bar buttons into the top sounds OK to me too. For switching between commit and history, perhaps either two toolbars could swap in place or irrelevant buttons could be disabled.
I would also miss the proxy icon if it went away. Moving it into the toolbar would save 17 pixels of height, but in exchange for a variable amount of horizontal space and being unusual relative to other apps. I'm not sure if that's the right trade-off. Looking at Xcode, I think it can have a unified toolbar because it has its own breadcrumb navigator internally.
Moving up the scope buttons and especially search makes sense, but I do use the scope bar not infrequently and would prefer not to add a click and a popover animation. Since there's only three scopes, perhaps a segmented control would be a better replacement if some appropriate icons can be designed.
I like the idea of simply switching the buttons in the toolbar, depending of which view is shown.
Well, that unified toolbar was just an idea (i really like the design), but seems to be not just right for document based apps. So we would probably go with a Finder style toolbar here?
I also really like the segmented control for displaying the scope buttons!
I am going to make another design with these improvements in mind
I did a basic first PR which has some functionality. I guess I will continue improving it, re-adding features like search, but if anything goes into the wrong direction, please tell me! :)
I'm definitely 👍 having a standard NSToolbar. I want to keep the scope buttons, and the search mode are really useful (I don't do git log very often, but when I do, it's through gitx). Incidentally, I have a branch around with a "raw" mode, because there's only so many things you can build a GUI to wrap the raw ⚡️ of git-log.
I would kill for some kind of back/forward support, because I found that I'm frequently switching between the commit and history view, and having a way to go back to the exact commit I was looking at in history would be awesome (right now you switch back to history view through a click on a branch, which will reselect its last commit loosing the thing you were looking at). (I just remembered they are keyboard shortcuts, but it turns out they also reselect the last branch, not the last commit).
Something that would be nice is to move the "Detailed view"/"Tree view" button to the bottom part of the history split view (since it only acts on that part) as a "commit" scope. The bottom pane would start with a scope-selection "toolbar" with Commit/Blame/History/Source, then the current "commit info" header (as the current commit "view" has), then a vertical split view containing (at the left) a fancy treeview displaying either the commits' changed file (for Commit) or the current complete treeview (for the others), and the right pane would be the HTML view of what's selected in the treeview (eg. the diff view or the current horrible HTML view).
The commit mode treeview would allow quick-access to every part of the diff (which would still be displayed in full in the right pane), which is something I wished I had (cough long commits cough).
I wonder if we should follow Apple's deprecation model re OSes. What's the oldest we can support while bringing this into the future? Old builds still exist, folks aren't out in the cold.
Please note we're in the midst of adding new CI to this as we're actively developing it again. So, it will be time well spent if you want to rejoin the thread :-)
I'm getting all the emails on this 🤪
I have some time constraints right now, but I'll see what I can do.
I wouldn't go so far and remove support for anything under Big Sur. The changes done are mostly in the UI, not the API. Adaptions for Big Sur can be additions to the code rather than replacements. I work on an app that runs perfectly fine on 10.13 with little to no effort.
Activity
ksuther commentedon Apr 28, 2017
Looks like a good start! Some things that come to mind:
mangerlahn commentedon Apr 28, 2017
Thanks for your thoughts!
I'll answer them one by one:
• I agree and have thought of this problem as well. Maybe we could implement another white view here in the center middle (similar to Xcode) which behaves the same way the document title does.
• I haven't looked into that one yet 🤔
• Yep! We could also move some of the buttons I've put into the toolbar back to the bottom into the source list. (Again like Xcode)
• That's what I've inserted the super crappy looking "Filter" button next to the search field. Clicking that could reveal a popover with all the filtering options GitX provides
ksuther commentedon Apr 28, 2017
Happy to provide any other feedback. In addition to the proxy icon, there'd need to be some sort of indication what repository is open. Your mockup doesn't show that at all right now. In cases like this it seems like just using the free behavior from NSDocument is simplest in terms of being maintenance free, but that's just my opinion :)
It'd probably be good to get opinions from other people that actually use some of those toolbar buttons. I tend to do any management like that through the command line, so if most of those buttons were to disappear I wouldn't notice (not that I'm suggesting they get removed).
mangerlahn commentedon May 3, 2017
You are probably right with that. Apple also said that in last years WWDC talk.
Nevertheless I hacked around and found that it is possible to show those controls in the unified toolbar. I even like the way that looks.
We would probably need to update that code as the UI changes and I am not sure if that would be desirable.
nanotech commentedon May 4, 2017
Having the toolbar be a real NSToolbar with its full customize interface would be great! Merging the bottom bar buttons into the top sounds OK to me too. For switching between commit and history, perhaps either two toolbars could swap in place or irrelevant buttons could be disabled.
I would also miss the proxy icon if it went away. Moving it into the toolbar would save 17 pixels of height, but in exchange for a variable amount of horizontal space and being unusual relative to other apps. I'm not sure if that's the right trade-off. Looking at Xcode, I think it can have a unified toolbar because it has its own breadcrumb navigator internally.
Moving up the scope buttons and especially search makes sense, but I do use the scope bar not infrequently and would prefer not to add a click and a popover animation. Since there's only three scopes, perhaps a segmented control would be a better replacement if some appropriate icons can be designed.
mangerlahn commentedon May 6, 2017
I like the idea of simply switching the buttons in the toolbar, depending of which view is shown.
Well, that unified toolbar was just an idea (i really like the design), but seems to be not just right for document based apps. So we would probably go with a Finder style toolbar here?
I also really like the segmented control for displaying the scope buttons!
I am going to make another design with these improvements in mind
mangerlahn commentedon May 6, 2017
Now with a more practical toolbar

ksuther commentedon May 11, 2017
Looking good! We'd probably have more opinions if we had a binary release that other people could use :)
mangerlahn commentedon Jul 19, 2017
I did a basic first PR which has some functionality. I guess I will continue improving it, re-adding features like search, but if anything goes into the wrong direction, please tell me! :)
tiennou commentedon Sep 2, 2018
I'm definitely 👍 having a standard NSToolbar. I want to keep the scope buttons, and the search mode are really useful (I don't do
git logvery often, but when I do, it's throughgitx). Incidentally, I have a branch around with a "raw" mode, because there's only so many things you can build a GUI to wrap the raw ⚡️ of git-log.I would kill for some kind of back/forward support, because I found that I'm frequently switching between the commit and history view, and having a way to go back to the exact commit I was looking at in history would be awesome (right now you switch back to history view through a click on a branch, which will reselect its last commit loosing the thing you were looking at). (I just remembered they are keyboard shortcuts, but it turns out they also reselect the last branch, not the last commit).
Something that would be nice is to move the "Detailed view"/"Tree view" button to the bottom part of the history split view (since it only acts on that part) as a "commit" scope. The bottom pane would start with a scope-selection "toolbar" with
Commit/Blame/History/Source, then the current "commit info" header (as the current commit "view" has), then a vertical split view containing (at the left) a fancy treeview displaying either the commits' changed file (forCommit) or the current complete treeview (for the others), and the right pane would be the HTML view of what's selected in the treeview (eg. the diff view or the currenthorribleHTML view).The commit mode treeview would allow quick-access to every part of the diff (which would still be displayed in full in the right pane), which is something I wished I had (cough long commits cough).
jspiro commentedon Jan 26, 2021
I like it – can we revive this? I like the unified bar, it's apt in 2021. Re the document proxy, Big Sur reveals the proxy on hover in Finder, e.g.:

mangerlahn commentedon Jan 26, 2021
Yes, we would need to keep the design in above screenshots for older OSes, but could adapt the unified toolbar for Big Sur
jspiro commentedon Jan 26, 2021
Cool, and hello! Welcome back to the project!
I wonder if we should follow Apple's deprecation model re OSes. What's the oldest we can support while bringing this into the future? Old builds still exist, folks aren't out in the cold.
jspiro commentedon Jan 26, 2021
Please note we're in the midst of adding new CI to this as we're actively developing it again. So, it will be time well spent if you want to rejoin the thread :-)
mangerlahn commentedon Jan 26, 2021
I'm getting all the emails on this 🤪
I have some time constraints right now, but I'll see what I can do.
I wouldn't go so far and remove support for anything under Big Sur. The changes done are mostly in the UI, not the API. Adaptions for Big Sur can be additions to the code rather than replacements. I work on an app that runs perfectly fine on 10.13 with little to no effort.