Skip to content
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

feat: Mount manager #1977

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

feat: Mount manager #1977

wants to merge 2 commits into from

Conversation

SL-RU
Copy link

@SL-RU SL-RU commented Nov 30, 2024

Hi, I think mount points management is important part of file manager and because of that I want to implement that feature. This pull request is the starting point. It was mentioned here #1272 #927 . I think it cannot be fully done using plugin system and must be part of this project.

Currently there is only data from /proc/mounts in the menu, but later it must contain data same as lsblk (including not mounted yet volumes) and from fstab (not mounted yet volumes).

Functionality now is limited: only change direcory to mountpoint. In plans: mount, unmount, poweroff and show info about partition.

Keymap:

In file manager key M opens mount manager.

In mount manager up and down scrolls; l or <Enters> changes directory to selected. Mountpoint list is updated only when opens or arrow keys pressed, later maybe makes sense to update on timer.

Only UNIX systems are supported now for demonstration purposes. But later is not a problem to add mac and win.

Please give some feedback, can it be merged in the future? Do you think it is required feature in your project?

image

@SL-RU SL-RU marked this pull request as draft November 30, 2024 23:25
@sxyazi
Copy link
Owner

sxyazi commented Dec 1, 2024

Thank you so much for your PR!

This is a feature I've always wanted to support but just didn't have the time to complete, so I'm really happy to see someone take it up, especially since you're the original author of ranger_udisk_menu, which was my original inspiration. I really appreciate your outstanding contributions to the entire file manager community with such a great plugin!

I think it's best to offer this as a plugin rather than a built-in feature, and expose the API for getting mount information to Lua. This way, it can also benefit other plugins.

If many users need it, we can offer it as a built-in plugin, but initially, it's better to maintain it as a separate repository. So that we can get quick issue fixes independent of Yazi's release cycle, just like with the git.yazi plugin.

I'm more than happy to explore any blockers in implementing this via the plugin system, and if necessary, I can provide any missing plugin APIs — just let me know!

@SL-RU
Copy link
Author

SL-RU commented Dec 1, 2024

Thank you for such an answer! I get your point and agreed that this functionality is possible to implement with extended API!

I'll create list of required API and we'll decide how to implement it better.

@SL-RU
Copy link
Author

SL-RU commented Dec 4, 2024

I understand your perspective and agree that leveraging an extended API is a viable approach. However, I believe that integrating a mount manager directly into the Rust codebase is essential for achieving a robust and seamless user experience, especially given the limitations of the current Lua API in delivering a sophisticated user interface. I couldn't imagine situation when mount manager is not required for user.

My suggestion is to implement the core mount manager functionality in Rust, ensuring multi-platform support for essential features such as viewing mount points and unmounted drives, navigating to mount points, and performing mount and unmount operations. This would provide a solid foundation for users across different systems.

Subsequently, we can develop a Lua API to allow for further customization and extension through functional plugins. This hybrid approach would combine the stability and performance of Rust with the flexibility of Lua, catering to both basic and advanced user needs.

I look forward to collaborating and contributing on this and exploring how we can best implement these features to enhance the project.

@sxyazi sxyazi force-pushed the main branch 2 times, most recently from 1394fb4 to 62ac224 Compare December 9, 2024 02:28
@SL-RU
Copy link
Author

SL-RU commented Dec 16, 2024

@sxyazi hi, I've made plugin 😄

It is in early stage, I'll debug it a little bit and make it public. It is LUA plugin with Rust application. Rust app based on linux sysfs, and udisk2 via dbus.

https://github.com/SL-RU/mount.yazi
https://github.com/SL-RU/mmt

screencast:
render1734392169072

@SL-RU
Copy link
Author

SL-RU commented Dec 20, 2024

@sxyazi can you give some feedback please?

@sxyazi
Copy link
Owner

sxyazi commented Dec 23, 2024

Sorry for the delay. I did some research on supporting this across 3 platforms (Linux, macOS, Windows). Since I'm not familiar with Linux and Windows — those aren't my work systems, it took me some time.

I took a look at the mount.yazi plugin, and it's really cool! I really appreciate your effort. Is it possible to move some of the mmt code into Yazi as a Lua API? We could start by just listing devices.

If you're not familiar with the Lua part, that's totally fine! You can just create a simple function for me, and I'll port it to Lua.

In the meantime, I'll try to implement the device listing for macOS, as it's my work system and should be lot easier for me. Once we have that API, we can start working on the UI in the plugin. If you're not familiar with Yazi's UI plugin API, no worries — just leave it to me, and I'll provide any help needed to implement it.

As for Windows, it looks like it will require calling some Windows-specific APIs. If you're familiar with those, please try to implement a function for getting the device list there as well. If not, that's fine too — we can leave it for now and wait until someone familiar with Windows platforms is available to handle it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants