Skip to content

Modern UI #91

Open
Open

Description

@mangerlahn

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.

gitx

What do you think?

Activity

  1. ksuther commented on Apr 28, 2017

    @ksuther
    Contributor

    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?
  2. mangerlahn commented on Apr 28, 2017

    @mangerlahn
    ContributorAuthor

    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

  3. ksuther commented on Apr 28, 2017

    @ksuther
    Contributor

    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).

  4. mangerlahn commented on May 3, 2017

    @mangerlahn
    ContributorAuthor

    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.

    bildschirmfoto 2017-05-03 um 21 57 47

    We would probably need to update that code as the UI changes and I am not sure if that would be desirable.

  5. nanotech commented on May 4, 2017

    @nanotech
    Contributor

    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.

  6. mangerlahn commented on May 6, 2017

    @mangerlahn
    ContributorAuthor

    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

  7. mangerlahn commented on May 6, 2017

    @mangerlahn
    ContributorAuthor

    Now with a more practical toolbar
    bildschirmfoto 2017-05-06 um 21 51 39

  8. ksuther commented on May 11, 2017

    @ksuther
    Contributor

    Looking good! We'd probably have more opinions if we had a binary release that other people could use :)

  9. mangerlahn commented on Jul 19, 2017

    @mangerlahn
    ContributorAuthor

    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! :)

  10. tiennou commented on Sep 2, 2018

    @tiennou
    Contributor

    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).

  11. jspiro commented on Jan 26, 2021

    @jspiro
    Member

    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.:
    Screenshot 2021-01-25 at 11 58 00 PM

  12. mangerlahn commented on Jan 26, 2021

    @mangerlahn
    ContributorAuthor

    Yes, we would need to keep the design in above screenshots for older OSes, but could adapt the unified toolbar for Big Sur

  13. jspiro commented on Jan 26, 2021

    @jspiro
    Member

    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.

  14. jspiro commented on Jan 26, 2021

    @jspiro
    Member

    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 :-)

  15. mangerlahn commented on Jan 26, 2021

    @mangerlahn
    ContributorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions