Le 22/06/2021 à 19:10, Steve Litt a écrit : > Didier Kryn said on Tue, 22 Jun 2021 18:00:17 +0200 > >> Le 22/06/2021 à 14:20, Steve Litt a écrit : >>> How bout making a CLI Hopman with an API somebody can interact with >>> in gtk, or CLI, or PHP, or Tcl/Tk, or Python/Tk, or pretty much >>> anything else? >> I have thought of this initially before doing it with Gtk2. But it >> means a dual-process application (Hopman + a GUI written in Tk, PHP >> ...). In a mode of operation like inotifywait, a formatted message >> would be emitted by Hopman to standard outputeverytime the status >> changes. I probably rejected this solution because it implied to >> develop the two programs, which at least is twice more work. >> >> If there are volonteers to develop the GUIs, I can think of this >> CLI version. > I'll volunteer to make a Python3/Tk version. I'll need specifications > from you, either written or formulated via a set of emails between us, > offlist.
Let's continue on list for generalities since it might trigger reactions. This is my suggestion: Hopman-cli would write to the pipe 3 sorts of messages, with all the necessary details: - a device special file associated to a removable partition has been detected in /dev - a symlink has been detected in /dev/disk/by-label, pointing to a removable partition - a device special file associated to a removable partition has been removed At startup Hopman-cli looks for removable partitions already present; then it relies on inotify; but the messages would be the same for initial discovery and for online creation. Then it's up to the GUI application to - parse these messages, maintain and display a list of removable partitions and their labels, - on click, spawn helpers to mount/umount/open partitions and potentially eject disks, check completion and report errors, - periodically read /proc/self/mounts and report mountpoints of removable partitions on the display. Both Hopman-cli and the GUI must read hopmanrc at startup (it seems simpler to have a single file to configure both). Possibly the name of the GUI application might be specified in hopmanrc and Hopman-cli would launch it. Both applications must die immediately when the pipe is broken. I don't think the GUI is a piece of cake, but you seem to have some experience (~: Note that this a reactive program: it must react on input data available, mouse-click, and child-termination, while periodically reading /proc/self/mounts. I think the most difficult is to check the result of helpers and forward their messages to the user. If this seems too difficult, Hopman-cli could take care of mount helpers, but this would require a bidirectional communication, making it impossible to launch both applications from the command-line (Hopman-cli should be in charge of launching the GUI). Maybe this is similar to what Aitor does with his dual-threaded version. Cheers. -- Didier _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
