Why is the GUI builds not released anymore?

[lrq3000]

I saw that before there was a GUI build, which was very useful for non-technical users. Indeed, although the command-line interface does not change much for the receiver (it's still just about running the app and typing the passphrase), for the sender it's a lot more complicated.

Is the GUI planned to return at some point?

[schollz]

Yeah I'm looking at doing a Gui again...

[makew0rld]

That would be great to see! It would make things a lot easier for users, and I'd be able to easily direct this application to friends as a way to transfer files.

[camjac251]

I was thinking of something that would be nice to have inside of croc. Although this would primarily be for windows users.

I was thinking if there was a right click context menu option for sending and receiving to/from the folder or multiple selected files. So if you need to send FileA File39 and File#21, then it would be as simple as selecting just those files, right click, send with croc, then it could maybe copy the code to clipboard automatically too. Then on the target computer just right click an empty space and select Receive with Croc, then it would grab the clipboard and possibly also autoaccept the files.

Having it be as simple as copy and pasting using context menus would be very easy for people who don't use CLI at all.

[camjac251]

I thought I'd try the idea myself. There might be a bug here or two with it but I'll definitely be using it over using cmd. This would add two context menu items croc > send and croc > receive. What I like about this is you can select any files or folders in File Explorer, right click and send them all really easily.

For this I wasn't able to do it natively just yet in Windows so you'd need another program to begin with. I used https://github.com/stax76/OpenWithPlusPlus which registers a DLL and allows a gui to add new context menu items.

My croc receive context menu item opens powershell and runs the clipboard contents, but will strip croc and adds it again in case the user only copies the code. The full output would be this powershell.exe -command "$receive = @(Get-Clipboard);$receive = $receive -replace 'croc ','';croc --yes $receive" in case someone wanted to implement it without the above tool. Sending is much easier since it uses the built in %paths% powershell.exe -command "croc send %paths%;pause". I think pause is in there because sometimes it would fail.

This is my settings.xml, but renamed to .txt for GitHub to accept it. Rename it to settings.xml and drag it into %appdata%\Open with++\ or your config folder (in settings) Update: Fixed a problem with spaces in path causing powershell to error, added single quotes around %paths% and it's fixed Settings.txt

It would be even cooler if I could figure out how to copy the last line of the output of croc send to clipboard which would make this process in my opinion easier than a gui.

It would be really cool if croc had a built in option like croc install context which could then add registry info that would add context menus that emulate this.

[lunemec]

There was already Windows GUI present: https://github.com/schollz/croc/commit/d42a4f82a1ba03fe75796b4f9c303154cab80218 but it is not in the repository anymore.

[piegamesde]

A GUI is great, but it really should be in a separate repository.

[ansballard]

Just stumbled across this, but it seems like this doesn't necessarily need a full gui in a separate window, I was wondering more about a tray icon with send/receive/text box , since that should cover all the base functionality without needing less tech-savvy users to open a command line, and without the extra weight of a full GUI.

I think the context menus are a nice option but I tend to avoid them myself, since they tend to add up pretty quickly

[quite]

Maybe a cross-platform gui would be the thing. Covering linux dists, windows, macos, ios, android. What are the options for such gui? :)

[piegamesde]

How about re-using existing Wormhole-GUIs? The functionality and CLI syntax is nearly identical, it could be rather easy to take one of these and make croc a second backend.

What are the options for such gui?

With regards to your requirements—web. There is no true one size fits all solution for cross platform GUIs.

[ansballard]

@quite first one that comes to mind is electron, which is way to heavy for this app in my mind. Tauri might be a good alternative, but it's in early dev and I haven't used it personally.

Looks like wormhole uses qt, which is a pretty popular cross platform ui, I'm sure someone that's used it before could throw together a solid UI pretty quickly.

[quite]

@ansballard wow, Tauri looks like something that could replace electron, which indeed is heavy and mad...

[Jacalz]

I might be looking at creating a gui for croc sometime in the future. I already have a gui called wormhole-gui for magic-wormhole that uses fyne so that it is fully cross-platform. It shouldn't be all too hard to reuse some of that code to fit better with croc. It can currently run on Linux, MacOS and Windows, but fyne has support for iOS and Android too, so it should be possible to perhaps get that wired in sometime in the future as well.

[rpush-01]

I might try my hand at this, using Go or Rust. The easiest way is to make it essentially just executing the croc cli commands, which isn't too hard with the use of a couple libraries, and use goqt or goui for the GUI, which both are cross platform. I am intrigued by the possibility of a mobile app, but I'm not sure how writing to the open file system, and also how default network firewalls would work with the app.

[Jacalz]

I don’t think executing cli commands is the best solution to do this. It firstly kills off the portability of the application by needing you to have the cli installed at the same time (fyne apps are for example entirely statically build without runtime dependencies). It can also, theoretically, insert security issues where an attacker uses admin rights or modifies the command executions to overwrite necessary files or harm the system in any other way. Lastly, it will be slow to rely on a shell to run the commands. My opinion is that it would need to use the library instead if it ought to be really good.

[piegamesde]

It can also, theoretically, insert security issues where an attacker uses admin rights

If an attacker has got admin rights, you lost. Game over.

Lastly, it will be slow to rely on a shell to run the commands.

Calling a CLI tool does not require having a shell. You can still call the executable with command line arguments as a subprocess.

[lunemec]

The best option is to replicate what the CLI does in gui: https://github.com/schollz/croc/blob/master/src/cli/cli.go

[quite]

I dont think executing binaries is sa problem performance wise for this use-case. But, bundling/executing binaries might be an issue in the future on Android, because goog (playstore). At least I heard something like that.

[rpush-01]

@Jacalz you raise some good points, but as piegamesde said, if they have admin rights its game over, so that shouldn't be a major issue, although with testing we will know. I will build a barebones versions of application and we can test speed. I am most likely switching to Swift for the macOS application, as using nsopenpanel for a Finder window to select files is far easier than engineering something similar in Go.

[daegalus]

I mean the simplest solution could be just running an API server in Croc, and serving an HTML page that hooks into http APIs in croc. You can use your preferred Go HTTP library, be it the default built in, Gin, or whatever.

There is stuff like Lorca but that requires Chrome/Chromium to be installed on the target system. Many apps nowadays have just a built in HTTP server with a WebUI that gets launched in your default browser. Rclone does this for example.

or you can go the GoQt or something route and just hook everything up internally and use that for the GUI.

I think its less about what to use for the UI, but what you want it to do, and what it will accomplish for you visually. What features you want exposed, or how minimal you it should be.

And I saw a mention earlier that it will mostly be used by Windows, but I am fairly sure most people using OSX and Linux wouldn't mind having the option. I am on linux, and I still prefer GUI apps a lot of the times. I know OSX users might like some GUI options, especially if they want to use it with less tech savvy family or friends.

[realkotob]

I tried making a GUI for the croc CLI, but since the send command does not return immediately (it waits for the transfer to start), I was unable to capture the output and show it in the GUI.

Can we somehow have the send command return the url and run the transfer service in a separate background process?

[makew0rld]

I think that running the CLI as a subprocess is an inefficient way to do this, and will led to issues like the one above. The best way to solve this would be to create a library for croc, and have both the CLI and GUI use that.

[CicadaCinema]

@schollz Why was the GUI originally removed?

[schollz]

@ColonisationCaptain Too much upkeep for something I wasn't using

[quite]

There is a Croc app for Android on F-Droid now, it's https://github.com/howeyc/crocgui -- based on Fyne, so it can be run on desktop as well?

[smaragdus]

@schollz

Yeah I'm looking at doing a Gui again...

Any news?

[sten0]

I'm not sure how suitable it would be for Windows/MacOS, but there's a magic-wormhole GUI written in Vala and using GTK3: https://github.com/bleakgrey/Transporter Meson build system.

[Jacalz]

I'm not sure how suitable it would be for Windows/MacOS, but there's a magic-wormhole GUI written in Vala and using GTK3: https://github.com/bleakgrey/Transporter Meson build system.

If you are looking for an interface for wormhole, you'd be better off with https://github.com/Jacalz/wormhole-gui. However, I'm not sure how relevant this is given that this is about croc 🐊

[Jacalz]

For a Croc GUI on Android, I think https://github.com/howeyc/crocgui might be what you want to have a look at.

[sten0]

@Jacalz, I shared the link to that because it's a desktop application that could potentially be adapted for croc.

I think we'll both agree that the question of converged mobile+desktop API solutions vs desktop native solutions is subjective, and that it depends on what degree of desktop integration is desired/expected. I confess bias against mobile-first design conventions ;-)

Anyways, I'm excited for croc because ipv6 support is important to my friends and colleagues, and magic-wormhole doesn't yet support it.

[Marksdo]

I made a simple iOS croc app iCroc.

https://iCroc.marksdo.com or search iCroc in the app store.

[github-actions[bot]]

Stale issue message