FiloSottile / age

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

Home Page:https://age-encryption.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

idea: GUI

JohnPi578 opened this issue · comments

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.

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.

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.

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.

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

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.

@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.

@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.