Using 2 spaces for indentation is actually quite common, you know... ;)
With the release of 8.0, one of the buzz-words is "heavily focusing on usability". That said, please don't scrap the Bookmark feature as I've gotten hints that you may be considering!
If people are not using it, it could be because it's not persitent between sessions - which is a fundamental flaw of course, but one that should be easy to fix...
Currently, all applied bookmarks are gone when restarting the Plastic GUI.
This was fixed in 18.104.22.16826. Excellent, thank you very much. (Took 3 years to un-disable a menu item, though...)
Also, I manually edit our ignore.conf to keep it tidy, but the suggested "remove from ignored list" command would remove all my formatting (comments, empty lines etc) that I have added to make the file easier to maintain.
You seem to miss my point. Suppose I ignore all *.dll files by default, but there's one DLL that I want to actually put under source control. Sure I could exclude that specific file from my ignore file, but why should I have to? It would be simpler to use the Add command that is already there but disabled.
It's a bit rude to tell customers to stop making mistakes, and in this case there was no mistake involved - only an exception to a rule which could be accomplished in one step (Add) instead of two (Remove from ignored + Add) if only you bothered.
You do support adding ignored files to source control and then they will no longer be ignored, right? So why not stop disabling the Add command for ignored files?
Sure this is just a small detail and a corner case, but if you ignore tiny suggestions like this you will never get the polish that you otherwise could. I don't think this change would make other customers less happy and you would surely get less whining from those who care...
But that is not at all what I want! I want to keep my general ignore rule and simply add this single file to source control. It's simply disturbing to have the wanted action available but greyed-out...
Sigh. For years now I've complained about the lack of consistency in functionality between the different views in Plastic Client. It's getting better but we're not there yet. And please don't remove useful functionality instead of making it more consistent - the cluttering could be solved by making some "advanced" functions optional.
Well, fine, I guess I'll have to accept that there will be no bookmarks outside the Branch Explorer, but could you then pretty PLEASE at least fix the persistency of those?! :
Branches that are on the same hierarchical level would still need to be sorted by additional heuristics just like today, based on overlap in time etc, but the branch hierarchy should be the main ordering criteria.
The earlier linked screenshots have now been moved here:
suggested "sorted" layout: https://drive.google.com/open?id=1laNq1DuVRwif4bLOCefEHJvXzc9bI2zq
This uservoice is slightly related (but different) : https://plasticscm.uservoice.com/forums/15467-general/suggestions/18561949-add-a-branch-weight-for-layouting-in-branch-explor
The most basic improvement to the Branch Explorer layout would be to simply replicate the same "vertical ordering" that you get in the Branches view when you enable "Tree view" (instead of "List view") !
I added one more screenshot "crossing_lines.png" to the dropbox URL mentioned earlier.
The new screenshot shows a smaller and simpler case where you can see a couple of grand-child-branches that are not sorted according to their hierarchical parent-child relationship. Instead the lines indicating ancestry (the "cross-branch changeset links") are allowed to cross other (cousin or unrelated) branches.
What I'd like to see is a more strictly hierarchical default layout.
The screenshots are here:
Here you can view two screenshots, one is the default Branch Explorer layout and in the other one I have manually done "relayout" to match the "branch namespace" hierarchy. I think the "sorted" one is much easier to grasp, since there is much less line-crossing and (grand-)child branches follow logically beneath their parents.
This hierarchical sorting is something that could easily be done automatically (by default).
The use-case is that you need to trace a certain block of code back in time (from the current changeset, let's say 32000) to see why and how it was changed. This must be done on a per-line basis, so the previous changeset (let's say 31000) of the whole file is pretty useless. In Annotate you can view a line/block and see at what changeset (let's say 30000) it was changed to the current reading. Then you very often want to know how that line/block read just before that latest change. That's why we need to be able to annotate the previous changeset for a specific line (let's say 29000). Your new feature takes us from cs:32000 to 31000, but we really need a way to go from cs:32000 to 29000 (line-specific)...
The majority of suggestions here were addressed in 22.214.171.1241, thanks! However, the most important missing feature, "annotate previous changeset", was _not_ implemented the way it's suggested here and the way it works in TortoiseBlame!
The implemented feature simply opens Annotate on the previous changeset where ANY LINE in the file was changed. But that is not what was requested. What we need, and what TortoiseBlame does, is to open Annotate on the previous changeset where the SELECTED LINE was changed.
* When there are local changes, it's not very useful to see these in the Annotate view. Instead we should see the latest Checked-in changes (at least optionally)...
Also, the line that was selected (when requesting the Annotate) should be pre-selected (and scrolled into view) when the Annotate view appears. This is related to the following uservoice:
This uservoice is related to this one: https://plasticscm.uservoice.com/forums/15467-general/suggestions/13890972-track-the-evolution-of-a-section-of-code-back-thro
Yes, "Annotate previous changeset" is the most important of my suggestions here. It's a must-have feature for any Annotate/Blame implementation... Without it, you can only see the latest revision of a line or block of code, with no quick way to trace it further back into history.
OK, didn't see the info bar at the bottom... :P However, the bottom area works fine, except that it should be updated when I move the cursor to a line that comes from another changeset (at least when the cursor is in the left area)! That is, when clicking a changeset line in the left area it becomes selected, but it should also be possible to move the selection with cursor up/down and PgUp/PgDn keys.
For reference, the "multi-screen diff" feature was "documented" in the following release notes:
"Release 126.96.36.1990 Mar 22 2017
Windows GUI: dynamic diff window to help diffing code in multi-screen setups.
You can show the diffs from a branch or changeset, move the window to a second screen, and the diffs will be updated when you select a different changeset or branch. This is super useful to review changes.
The diff window will be updated if you select a different branch in Branch Explorer or the branches view, and same for changesets. It works for shelves too.
You can skip this behavior launching the diff window using Shift + DoubleClick. When there are more than one "dynamic" diff, the diffs won't be updated."
That's right, this new "multi-monitor" setup in the 6.0 Beta is a nice improvement!
This is very much related to this uservoice: https://plasticscm.uservoice.com/forums/15467-general/suggestions/8278431-preview-changes-for-changesets
Also, here is the mentioned suggestion of listing changed items in the Properties sidebar: https://plasticscm.uservoice.com/forums/15467-general/suggestions/5722236-list-changed-files-in-branch-explorer-properties
I second this! Add a "Show/Hide Changes" toggle in the Changesets and Branch Explorer views. (Very similar to the "Show/Hide Diffs" in the Pending Changes and 2D History (Version tree, for a single file) views, but here you need also the list of changed items.
Actually we started doing this on the new Mac and Linux GUIs :-) The new GameUI also supports this mechanism. Soon we’ll have it on the regular Windows GUI.
The most confusing part is that the per-machine tabs are not "sticky", so they dis-/appear when switching the active workspace...
A first step towards this was (perhaps) taken in Beta 188.8.131.523:
"Windows GUI: We improved the way to switch workspaces. Now instead of tabs there is a button with the last N recently used workspaces (7 by default). You can change this value by editing the "RecentWorkspacesCount" property in the guiclient.conf file, placed on ~/AppData/Local/plastic4 directory."
So now the workspaces are gathered in a dropdown. Most of the buttons in the left sidebar will open a tab that is specific to the active workspace, but the following will not since they are instead of a per-machine or per-user nature (re-ordered) :
- Sync repositories
- Blog news
This one was started over a year ago?
The quickest fix for this ticket is to simply activate (in Pending Changes) the same Ctrl++ and Ctrl+- shortcut keys that are currently working (since 184.108.40.2067 or .806) in the other Diff Changeset views but NOT in Pending Changes!
WAIT!!! This is not fully fixed in .806! It still won't work in Pending Changes, only in Diff Changeset etc. PLEASE fix Pending Changes as well, since that is one of the most important places to have this!
Fixes for this were included in 220.127.116.116. Thanks!
My request is that I'd like to see at-a-glance:
(1) which changeset I'm currently at.
(2) which branch I'm currently switched to.
The GUI always shows (2) but not as readily (1), while the "cm status" CLI command always shows (1) and only shows (2) if requested via a special option.
Thus, you are not consistent in showing this info between your GUI and CLI... IMHO, both (1) and (2) should be shown by default in both GUI and CLI.
Additional note: It would also be very useful to see here the latest changeset number on the switched branch, if it differs from the one loaded!
BTW, to show this updated info we might have to press the Reload icon in the "selector bar". (Strangely enough, that icon is located at the far right while in all other views the Reload icon is located immediately to the left...)
Here is a related uservoice, which would solve this on on-the-fly: https://plasticscm.uservoice.com/forums/15467-general/suggestions/18890365-make-all-branch-explorer-colors-customizable
Some of the colors are already customizable via text files, so a minimal implementation would be to simply expose the rest of those colors to the user.
Branches can already be custom-colored via "Conditional format", based on attributes.
Since attributes can also be applied to labels, all that's needed (for consistency) is to extend the "conditional format" coloring feature to Labels as well!
In short: When zooming out, stop shrinking the font before it becomes unreadable.
This is slightly related to this other uservoice: https://plasticscm.uservoice.com/forums/15467-general/suggestions/9655032-improve-vertical-ordering-in-branch-explorer-make
I find the default visual layout to be rather random. Being able to use a branch-weight attribute for auto-layout would definitely help in improving this.
(However, as requested in the above uservoice, I would also want the option to order branches vertically by namespace/parentage.)
To keep these uservoices separated: This one is only about colors, while the other one is about adding additional visual indicators for selections.