Mikael Kalms

The scroll handle in PlasticX is narrower than in regular Plastic. I find it difficult to hit with the mouse. As for the old Plastic client, I have no problems with hitting that handle: Also. When using the client in fullscreen mode, I realize that what I usually do in a situation like this is, I slam the mouse cursor into the right-hand side of the screen, and then I move it a few pixels to the left to get it onto the handle. The new client's handle, however, has a ratio of (width of handle) / (distance between handle and edge of window) that requires me to use more precision (and move more slowly) when I align the mouse horizontally. It's the same kind of problem that I'd face if I was using the client in a non-maximized window. The old client's handle width + height is such that it's not a precision problem for me -- but the new client's handle width makes it noticeable to me. I also think that the new handle can become shorter (vertically that is) than Windows' standard scroll handles do. I think that compounds the issue for me. It's enough many pixels that I can't just put the mouse into the right-hand screen border and then"adjust a

Hi, The bottom half of the Pending Changes / Checkin Changes view in Plastic, Gluon and PlasticX is dedicated to the diff view. When our artists use these tools, they are sometimes not interested in seeing the diffs at all. However, it seems there is no way to disable the diff view. All they can do is drag down the horizontal divider almost all the way to the bottom - but this is not ideal either, and also, if they close/open Plastic/Gluon/PlasticX then the divider position will be reset. Please consider adding a show/hide button that controls visibility of the diff view for PlasticX/GluonX. (Related thread for the classic Gluon client below)

The "Checkin Changes" pane will display a diff view in the bottom section. Some of our artists are not interested in this view. However, it seems there is no way to disable it. All they can do is drag down the horizontal divider almost all the way to the bottom - but this is not ideal either, and also, if they close/open Gluon then the divider position will be reset. Is there a way to permanently hide that diff view section?

If I diff a couple of changesets, and then click on different files, to see the line-by-line diffs, then the PlasticX client sometimes gets stuck in an infinite loop - it uses 100% of a core and becomes unresponsive. I have had this happen after jumping between 2 files, between 3 files, and between ~15 files during my tests. I do not experience this using my regular Plastic client. It is not 100% reproducible, so it's not specific files triggering bad behaviour. I am using dynamic workspaces. See issue #30614 for logs and videos.

The "Try our new GUI (alpha)" button is easy to find. However, after I switched to the new GUI, it was really hard for me to find the button to switch back to the old GUI. It took me well over a minute of searching to find it. I felt frustrated, like this was an intentional design choice. As a user, I expect the "switch to the other GUI" button to be in the same place in both applications.

I am used to hitting F5 for refreshing views in Plastic. I use this particularly much in Pending Changes and in Branch Explorer views. This hotkey does not seem to do anything in PlasticX. Any chance we can some hotkey (F5 or Ctrl-R or something) for this in PlasticX as well?

If I switch to the Changesets view, I get a list of changesets with the following header: When I double-click any of those vertical bars, I expect the column to auto-resize so that its contents is fully visible. This functionality is present in Plastic but not in PlasticX.

The same thing (react to mouse-up rather than mouse-down) also applies to these checkboxes. Again, it makes the UI feel more sluggish than the classic Plastic UI.

I'm testing with PlasticX on Windows, v10.0.16.6538. Here is a snapshot from the Workspace Explorer view: When I click on one of these right-arrow symbols, the UI will respond to the mouse-up event, not the mouse-down event. This makes the UI feel more sluggish than necessary. The old Plastic client reacts to the mouse-down event. ------------------------- In addition, I notice that it is not 100% reliable. Lots of clicking on the same folder's right-arrow will sometimes make a folder higher up expand. I think that is related to folders sometimes not opening instantly, and the UI not handling non-instant opens entirely correctly. I made this (an arrow disappeared) happen just by clicking a couple of times on that arrow -- see that 'Meshes' is missing an arrow in the screenshot below:

In recent times, the "owl" is being used to not only give tips on features, but also notify about new Plastic version releases. This increases the frequency at which people see these owl popups. I still think it is a mistake to put these tips in people's faces. There are gentler solutions. See what Unreal Engine does (in screenshots above). Here is a snippet of conversation from our internal Slack workspace. They were starting Plastic, going to do some work, and wham there's 30% of the plastic UI surface area covered by something they didn't ask for and unrelated to what they're currently thinking about. They need to go hunt for that tiny dismiss button before they can continue working effectively. I don't think they dislike the owl and the information in itself; it's rather that it shows up un-prompted, with information that is only relevant to some of the users. Small notifications in the corner of the UI are less intrusive and allow people to take action when they think "interesting, tell me more".

When I double-click at the red-marked vertical divider, the width of the "Repository" column gets adjusted so that all strings in that column are fully visible. That is as expected. It will also trigger an action on the currently-selected item in the view: - if I have a folder selected, it will expand/contract that folder within the view - if I have a file selected, it will open that file in an external editor That is not as expected

Side note; I find the new font easier to read with the Dark theme, compared to new font + Light theme.

Hi, I have only used PlasticX for a few minutes. Would like to point out that the fonts used - and perhaps the alignment strategy for these - makes text smudged. Left side is text from Plastic. Right side is text from PlasticX. I have screenshotted both applications and zoomed results to 400% using nearest neighbor interpolation. I perceive text in views where each letter is important - for example, filename column in the Workspace Explorer - as more difficult to read with the new font.

Today, I deleted a dynamic workspace via the Plastic SCM client. I noticed that the disk space was not reclaimed immediatedly. I thought "huh, that is odd". Then I closed the Plastic SCM client. This triggered a BSOD - PAGE_FAULT_IN_NONPAGED_AREA. This is the first BSOD that I have with this workstation in a long time - I think, the first in 12+ months. After restarting my machine, I notice that the the Dynamic Workspaces feature doesn't seem to remove plasticfs workspace storage content for me. When I delete a dynamic workspace, the folder remains with all its contents within the "plasticfs-workspace-storage" folder. An entry is added to the "dynamic-wk-to-delete.conf" file, with folder name + a date. I have verified this once by creating & removing a dynamic workspace since after the bluescreen. I have now deleted the unused storage folders + the config file manually, so to get the diskspace back. I notice no other weird results. Normal interactions with a preexisting Dynamic Workspace seems to be have as expected. I can't say for sure if deleting Dynamic Workspaces always behaved like this, or if this is a new phenomenon... but I think it has always behaved like this for me.

Today, we lack linkage between source art versions and imported art versions. We have strong linkage (files in same repo) between imported art versions and code. If we didn't have the latter linkage, we would be in a world of pain