-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
systemd: Open path in terminal #21162
Conversation
Currently in a workable state! Here's what it looks like, both errors are alerts: @martinpitt If you have any feedback before I polish it and do some URL stuff and write tests, let me know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool @ashley-cui ! I did a first review round. I can try to help you a bit with the styling, but that's my weak point as well. But until @garrett has time to look at this, we can sort out the code, functionality, and tests.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as outdated.
This comment was marked as outdated.
I don't really have time right now to properly test this, but I was looking through my mentions, and it looks pretty good from the screenshots, provided the alerts aren't covering up the terminal content. The continue action should probably look like a secondary small button. |
5e2aaf5
to
c114eb0
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ashley-cui! Nice work with fixing the issues and adding tests, they look fairly happy. I have a lot of really small stuff, should be quite fast to fix. But let me know if anything is unclear, happy to help!
There's also some outstanding threads from my previous review.
f9fff28
to
5e84f7b
Compare
Updated, now looks like this! Thanks for the thourough reviews @martinpitt 😺 |
I tested this interactively, and in general it works great! I noticed two visual issues, though: there should be some separation between the alert and the neighbors. For the "missing directory" one it's still okay-ish: But the danger one has a missing background color, so it's all white (note I use a white terminal theme): Inline danger alert should have a red-ish tint, like in the docs. I'm not sure where exactly this goes wrong, as this PR changes no CSS. What could help is to move the alerts above the existing thin separator line, which you can see without an alert: It may in fact be better to move the alerts above the header bar even? |
With moving the alert group right after the opening of which I find a better, WDYT? @garrett ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, almost there!
pathError: null, | ||
changePathBusy: false, | ||
}); | ||
cockpit.location.replace(""); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks a little odd. The effect is that when I cancel a change dir request due to "busy", it doesn't go back to the previous location, but clears the path entirely. It's mostly cosmetic, as the actual terminal session stays intact.
So mostly thinking aloud, ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reasoning behind this: If we don't clear the path but the user clears the error, and then tries to open the path again, there isn't a change because there's no navigation event, so onNavigate() doesn't run.
Design wise, I still prefer the alert after the title/toolbar. I feel like this is more of a terminal warning over a page warning, ie it doesn't affect the toolbar, so the alert should be placed below the toolbar, before what's going to be affected, but curious to hear what @garrett thinks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thanks @ashley-cui ! Good enough then, I don't have a strong opinion about the alert placement. I'd just really like to understand that grid row CSS change..
I dropped the no-test label, so your next push will run the full gamut (so far I only triggered fedora-40). I don't expect any fallout somewhere else, but 🤷♂️ 😁
@garrett can you please do the final sign-off? @ashley-cui can you please post updated screenshots (with the isInline
change)?
@ashley-cui dang! On CoreOS this is slightly different, the home dir is indeed under /var/ there. Check e.g. this case:
|
Allow opening of a path from a URL option, path=path. If the terminal is busy, then warn the user and prompt them to continue.
payload: "stream", | ||
spawn: [user.shell || "/bin/bash"], | ||
environ: [ | ||
"TERM=xterm-256color", | ||
], | ||
directory: user.home || "/", | ||
directory: dir || user.home || "/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This added line is not executed by any test.
if (cockpit.location.options.path) { | ||
const validPath = await this.readyPath(); | ||
if (validPath) { | ||
dir = cockpit.location.options.path; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 4 added lines are not executed by any test.
componentWillUnmount() { | ||
cockpit.removeEventListener("locationchanged", this.onNavigate); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 2 added lines are not executed by any test.
return true; | ||
} | ||
} | ||
return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This added line is not executed by any test.
actionClose={<AlertActionCloseButton onClose={() => | ||
this.setState({ changePathBusy: false })} />} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 2 added lines are not executed by any test.
Hey! Thanks for working on this feature and congrats on getting it merged! I noticed a few issue from the screenshots that should be handled in a follow-up:
Normally, design related changes should be handled before the PR is merged. I was busy with Anaconda lately, but this still should've been held back until it got a few moments for design review. It's somewhat OK with this feature right now, as people aren't going to see it yet (as it needs to be implemented in Cockpit Files too), but the danger is that these changes that I listed might be accidentally ignored or delayed, and additionally strings will get translated for the current state and then the translations will be thrown away when they have to be re-translated. (We don't want to give translators extra busy work if we can help it.) We generally don't have deadlines for most features in Cockpit, so it's usually fine for something to "slip" to the next release if something doesn't make in time for an immediate release. My quick feedback in a comment above was that the general approach (alert instead of modals, as modals would cover up the actual content that would need to be interacted with, especially dealing running processes) looked fine. It wasn't meant as a sign-off though. I'll open up a new issue based on this comment. (Note: We've all merged things a little too early before. It's OK; the implementation looks great; it just needs a little bit more polish in this case.) |
Allow opening of a path from a URL option, path=path. If the terminal is busy, then warn the user and prompt them to continue.
WIP: changing to a path that does not exist should result in an alert, but there's some css magic that's preventing the alert from showing, and I can't figure out what it is. Also needs tests, but thought I would draft it for feedback so far 😌
Prerequisites: