search

FiloSottile / age

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.
https://age-encryption.org
BSD 3-Clause "New" or "Revised" License
17.26k stars 506 forks source link

idea: GUI #153

Closed JohnPi578 closed 3 years ago

JohnPi578 commented 3 years ago

Not sure whether this is better suited for the Mailing List or here. Sorry, if I got it wrong.

Are there any plans for a GUI or is one in development? I just think that this would make the usage of Age much easier for people that don't feel comfortable using a terminal.

alerque commented 3 years ago

Since the Go code now acts as a library, it wouldn't be hard to come up with GUIs for various environments. I don't think the core project should start including any GUI code though, there are too many different platforms, environments, toolkits, themes, and other things involved in creating a GUI and it's impossible for one project to do them all well and still do a good job of managing the core library.

ghost commented 3 years ago

I'm against including the GUI in the core. I agree if you want to create a GUI front end that depends on the CLI version of the program.

JohnPi578 commented 3 years ago

I agree if you want to create a GUI front end that depends on the CLI version of the program.

yeah, that was what I had in mind. But since my proposition is probably not going anywhere, perhaps I will do it myself. I just thought that a GUI would make it easier for my non-techie friends to use it.

Yukaru-san commented 3 years ago

Interesting to find this idea in the issues. I've actually made a simple GUI version a month ago if you are still interested.

ghost commented 3 years ago

Hello, lol it was created by a software engineer and not a software designer, prob not going to happen unless there is a huge push for this.

This is more likely possible if golang itself had a native GUI.

alerque commented 3 years ago

@Prajwal-Koirala This isn't an issue of engineers vs. designers really. Your comment pits them against each-other as if engineers were against good UI/UX. Sometimes it's appropriate for a project's scope to be a library or a CLI and not a GUI. Even good GUI designers can understand the need for properly scoped interests. You don't have to "push" because it was made by an engineer, that's just the puzzle piece that has to come first for good crypto.

Also GUIs are never really native to languages, so this isn't golang's fault (as much as I dislike the Go ecosystem!). GUI's are "native" to platforms, not programming languages and GUI toolkits or frameworks are often libraries targeting one or more platforms and have bindings for use in one or more languages.

ghost commented 3 years ago

@Prajwal-Koirala This isn't an issue of engineers vs. designers really. Your comment pits them against each-other as if engineers were against good UI/UX. Sometimes it's appropriate for a project's scope to be a library or a CLI and not a GUI. Even good GUI designers can understand the need for properly scoped interests. You don't have to "push" because it was made by an engineer, that's just the puzzle piece that has to come first for good crypto.

Also GUIs are never really native to languages, so this isn't golang's fault (as much as I dislike the Go ecosystem!). GUI's are "native" to platforms, not programming languages and GUI toolkits or frameworks are often libraries targeting one or more platforms and have bindings for use in one or more languages.

Just a standard package for GUI would be nice.