Hacker News new | comments | show | ask | jobs | submit login
Svgsus – Organize, clean and transform your SVGs (svgs.us)
52 points by stonebranch 219 days ago | hide | past | web | 37 comments | favorite



I wonder why some developers using Electron decide to release an non-cross-platform application. Isn't that the purpose of Electron? To create cross-platform applications using web technologies? Otherwise, why not build it with Obj-C or Swift and get advantage of the native libraries?


Probably because (AFAIK) Electron currently requires you to have each platform to build that platform's release. At least that's what I thought I saw last time I checked?

Also there are subtle differences in platforms which means you actually need to test. Simple examples are menu differences (no app menu on windows). Forking external command line program differences. Application data differences etc. (maybe someone will make the electron cross platform CI tester?)


In our case we are aiming towards making a cross platform application. Before doing so we want to make sure to have a version that we feel confident about and our users like.


Do the native libraries really provide that much? Is it really that hard to implement a scrolling list of images these days, or a toggle button?


Two unrelated questions. Native libraries would — at least — make the application faster, and considering this is an image-related program I don't want to imagine how slow it is being rendered via a hard webview instead of a light one powered by a native framework like Cocoa. On the other hand, if it is difficult to implement an scrolling list of images and a toggle button using either Objc or Swift, that is something I don't know because I have limited experience with those languages, but if you take the time to build a non-cross-platform application, why not use native libraries?

If they are planning to package this program for Windows, Linux, Others then good, nice release, but I would still criticize because they are using a technology that is supposed to be a tool to build cross-platform applications from the beginning, if they already have the HTML / JavaScript code for this, what is stopping them from packaging the Windows version for example? I don't see anything in the feature list that requires Mac specific hardware / tools.


That’s the idea, to bring this cross platform as soon as we have a tool people like. But we do need to use some special tricks, more than Electron provides, to manage the macOS clipboard. I’d expect that we need to do similar tricks when we port it to Windows and Linux. That said, macOS seemed like a good starting platform as it it what we use ourselves.


You have to make a choice if you really absolutely must have everything done "native". Do you really need that performance or can you get away with HTML? For mobile, it's still more important but its perfectly possible to create a fast desktop web app these days.

If you're doing something graphically intensive, there's also always WebGL. At the current rate the browsers are going, I expect the case to do native apps to be shrinking. Stuff is already running at 60 fps in the browser these days and most people can't tell the difference past 60 fps, and the benefit of getting access to the javascript/HTML web ecosystem outweighs any other points for most apps.


If all you want to do is clean your svg files, svgo is the tool to use: https://github.com/svg/svgo


I hate that meme "let's make X great again".


This is neat!

I wrote a similarish tool for converting SVG to code at Last Job™: https://github.com/biowink/SVGeez (though, it's questionable how well it works beyond the specific use case of the app it's for..though in theory it should work fine!)

(even the name is similar ;))

I bumped into issues when transforming complex paths into single paths. I suppose leveraging SVGO is a better plan for that. Kudos!


Seems like an icon library rather than a general tool for SVGs.


You may use it as a library, I know users who do. But you may select output needed, or drag 'n drop depending on if you work as an developer or a designer.

I suggest that you look on the videos on the site or read some tips and tricks at https://medium.com/@DepartmentStockholm/svgsus-tips-tricks-b...


Is this pronounced S-V-Jesus?


I'm from Sweden and I pronounce it S-V-Gsus. According to google it sure sounds funny ;) https://translate.google.com/#en/en/svgsus


I assumed it was ess-vee-gee-suhs ("S-V-Jesus"), too. But your pronunciation -- does it match google's (S-V-G-S-U-S)?

I think we need an .au file in the distribution with you saying "Hi this is Stonebranch and I pronounce SVGsus as 'SVGsus'".


So is it Mac only?


It's currently Mac only.


App Store only too. God I hate the way the Mac app store wants my password even for free apps. I've got to switch to my browser, enter my nice long lastpass and copy and paste it into the app.

I've never got the non-browser lastpass working.


Have you tried changing the free downloads password setting? See http://lifehacker.com/allow-free-downloads-from-the-mac-app-...


It's set and I just tried to download a free app - and it asked for my password.

It was only yesterday that I entered my password for another free app so it's not just a '30 day expiry' thing.


I despise the fact that you need a valid credit card number on file to download or even update free apps.


Not true, you can create an iTunes account without a credit card: https://support.apple.com/en-ca/HT204034


Nice, this will be helpful for these times when I need to import an svg from the material spec.

I am still waiting for the graphical tool that will allow me to animate an svg (creates 2 different but compatible paths) though.


Adobe Animate CC (previously Flash CS) plus: https://github.com/TomByrne/Flash2Svg will create SVG animations.


Thanks,

I will try that ! I had a look at pretty much all the svg tools I could find and was very surprised that the best option is to write the paths yourself in a text editor -_-


What do you mean by clean?


Svgs usually contain a lot of redundant and useless information. We clean the svgs using SVGO, https://github.com/svg/svgo (and a few of our own plugins) to get more beautiful svg files. The output often gets bloated by apps like Sketch, this way we end up with a better output.


This is beautiful electron work. Any plans to support eps import?


Great. How to clean up a whole set of SVGs?


There is currently no way handle multiple icons at the same time. I mean you could still make a copy of each icon by just dragging them to a new folder in finder. We have multi-selection handling in our roadmap. Follow us on @svgsus on twitter and I'll make sure to ping you once we implemented it.


I've cleaned thousands of SVGs with: https://github.com/svg/svgo

  npm install -g svgo
  svgo -f /path/to/svg/files


Could someone edit the title to match the title of the website? The submission sounds like this is an online service, the website title makes it clear that this is a GUI app for macOS only.

I'm on Linux and all the designers I work with use Windows. I know this isn't the norm for most people on HN but the title is still misleading and the submission guidelines would seem to agree.


Yup, looks like a moderator fixed that one a while ago. Submitted title was 'Svgsus – Let's make svgs great again'. Not sure if that implied an online service but it was too baity for an HN title.


Yeah except the fixed title doesn't resemble the website title which (at the time of this writing and when I commented) is:

"Svgsus - Easier SVG handling for Mac"

This clearly defines this as macOS software even if it doesn't elaborate on "handling" like the current submission title does.


Am I the only one who almost threw up in my mouth when he dropped that icon and got a wall of text? SVG, le sigh...


Yup, its just you. That XML is one of the key advantages of SVG over other formats such as PNG for certain applications.


I'm really curious why you say so.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: