P3D3::"Save as...?" shouldn't be there.

Create issue
Issue #48 resolved
Tommaso Lanza created an issue

The following is a "detail" for the current state of things, but something that should be considered for a change in the longer run.

Keeping in mind the premature awesomeness of MacHg: remove the Save menu!

MacHG adds only one evident feature on top of those already provided by the underlying Hg: a one-click access list of repositories I am working on, showing their remote parents, and possibly(?) -in the case of cloned heavy branches- allowing cross-repository interaction.

This list is the only thing I want the application to remember and keep track of the next time I open it (not counting the app's preferences).

Still, MacHg asks me to save any changes I make to that list in a .mchg document which doesn't seem to serve any other purpose than, ditto, save that list. I think this operation shouldn't be exposed. It is the app's own business to save its state and remember it the next time I open it. Imagine an app that asked you to "Save as..." every time you changed something in the preferences. Wouldn't that feel weird?

When I open MacHG, I shouldn't think that I am using MacHG, rather that I am using one or more of my repositories. I am not working on my files, rather on a meta-description of my documents' current and past state. I am not there to edit the list of the repositories containing my actual documents.

If anyone wants to save different .mchg documents so to group repositories, that seems like a low priority feature to me, and it could be accomplished more elegantly by grouping in the list itself.

MacHg should handle saves the way the Yojimbo and other do: there is no explicit save.

What do you think?

Comments (11)

  1. Former user Account Deleted

    Well, to save an mchg file offers to have separate files for separate repo constellations. I don't see why one should not have the possibility to organize repos (belonging together) in dedicated mchg files.

    Greets, Marko

  2. Franck Zoccolo

    For me, the only thing that make me still using Murky instead of MacHg is its document based architecture...

    In my mind, as the OP said, MacHg would be more useable without this feature.

  3. Tommaso Lanza reporter

    I don't see why one should not have the possibility to organize repos (belonging together) in dedicated mchg files.

    As I mentioned in my last paragraph, I agree that is good, albeit low priority in my view, to have the ability to organise repositories in groups/sets/constellations. But sure enough, saving a different .mchg file seems like the least elegant approach. It is a GUI application, and a Mac one. It is supposed to make Hg easier to use (and don't get me wrong it does a heck of a job at that), not by adding complexity to an already *very* complex tool as Hg.

    Grouping could be achieved in the list via a number of well-known techniques (think folders and disclosure triangles).

    Asking the user to explicitly save every change to that list is an interaction hiccup, whose supposed advantage –as you describe it– is minor compared to the elegance tradeoff in terms of interaction.

    Think of iTunes (not the best example, I admit), you *can* have different libraries, but the functionality isn's exposed (opt-launching the app) as it is something affecting a minority of advanced users. The application is perfectly usable without ever being aware of that possibility.

  4. Marko Käning

    Don't get me wrong either, I still would vote for the document approach, because I have quite a few groups of repository sets which I would never want to open together. This is why I like this feature.

    Also I guess there is less overhead if you have this feature, since it frees the application of trying to figure out whether some repos are compatible or not and so on and so forth...

    I'd miss this feature badly.

    (Also it gives me the chance to reduce the number of repos in a file to a degree that I can give it to Jason for debugging purposes, as it had happened in the past. Indeed a very useful feature.)

    So, perhaps one can make MacHg configurable in such a way that it hides the .mchg file open/save functionality for those who don't need it.

  5. Tommaso Lanza reporter

    mkae So, perhaps one can make MacHg configurable in such a way that it hides the .mchg file open/save functionality for those who don't need it.

    Yes. Sorry for not being clear about it in my previous posts. Obviously if the "Save as.." disappears, MacHg will still need a place to store the data.

    It could behave like:

    1. First launch, ask where to save the .mchg file, then handle all saves automatically, using Event Notifications on any modification to the repo list.

    2. Never, ever ask for where to store the .mchg file, just create a default one under /Library/Application Support/.. and keep writing to it.

    3. As above, leaving the "Save as..." and "Open" menus in place so that those who want to create multiple .mchg files can do so at their will, but if not instructed to do so, the app will default to 1 or 2.

    Going for 3 is probably a good gray shade. All it counts is that save operations should be transparent to the user. Then if they are going to be atomic saves, Hg-based saves (a repo of repos :)), an SQLite file, timer-based or whatever I don't really care. Those are implementation details.

  6. Jason Harris repo owner
    • changed status to open
    • marked as bug

    Thanks for the commentary guys! Its nice to see your remarks to get a feel for your opinions etc. Thanks!

    Right in answer to the question, I have had a couple requests for having documents (Personally I also use documents as well, one constellation of repos for work, another for MacHg projects, and another for various sandboxing...) And I have had a couple of requests to only have a single document. As Tommaso and others have pointed out itunes, ical, and some other applications just have one unified document and you don't save it or anything. Its just automatically saved.

    Thus the compromise I was planning to do was automatically save the default untitled document as MacHgRepositories in the users documents folder if that doesn't already exist. Once the document is saved and has a file name, then any later MacHg operation automatically saves the document (This should already be happening for named documents). So its just this initial change where I will auto save the untitled document as /Documents/MacHgRepositories.mchg . I will add this (probably tomorrow and you guys can play with it and see if it is a compromise everyone can likely live with :) )

  7. Tommaso Lanza reporter

    Hey, thanks for the reply, that's great. One more thing then: please not in the Documents folder :) Can we do Application Support as a default? I bet you got pissed off at least once when some random Adobe app or even Apple's Soundtrack Pro drop docs and folders in the user's Documents folder. It may be too late anyway as that folder has already been rendered useless by too many apps defaulting to it, but...

    Sure the file can be moved to another location, but since we are talking about a default, first launch behaviour, the first impression is at stake.

    Or am I just being too anal retentive?

  8. Marko Käning

    Tommaso, what concerns the saving the default (untitled) document under Application Support I think you are perfectly right. That's Apple's recommended behavior. I'd also vote for that.

  9. Log in to comment