jdittrich
commented
3 years ago suggestion: Rename to "Import/Export Penpot files from/to local files" so that is is clear this is not about e.g. im/exporting an SVG (related: #546)
Closed garrett closed 2 years ago
jdittrich
commented
3 years ago suggestion: Rename to "Import/Export Penpot files from/to local files" so that is is clear this is not about e.g. im/exporting an SVG (related: #546)
elhombretecla
commented
3 years ago Hi again and thank you for your words!!!
Import/export files and project is high prioritized in our project plan. We understand that this is key in the design process. We will work on it soon!
Chaphasilor
commented
3 years ago Just an idea:
The new File System Access API would in theory allow Penpot to interface with local files almost like any installed application:
The API isn't widely supported just yet, but I'm sure it'll get there.
Basic import/export is the way to go for now, but I feel like this API would allow for a much better UX and make working fully offline possible!
garrett
commented
3 years ago @Chaphasilor: I opened this issue for saving and loading Penpot-specific files. The intention is:
The goal isn't to read in a local directory or export a bunch of files to a local directory. It could, possibly, but I would consider that a different feature (one that might build on basic export/import functionality, but not this feature itself).
The File System Access API is a "working draft" and only partially implemented in Chrome exclusively. It's unlikely to ever be adopted by other browsers, unless the spec changes.
Google is notorious for making its one-off poorly-implemented non-standard-ish APIs and then either breaking or retracting the feature. There's a good thread about this kind of thing @ https://twitter.com/falessandrelli/status/1390284863534731273 (from a gaming on the Web point of view, where a lot of these kinds of APIs are used when possible) & https://twitter.com/chucker/status/1390348889266528259
It's one of the many experimental Chrome APIs that makes security and privacy on the Internet more difficult (similar to WebUSB and Web Bluetooth).
Firefox's statement @ https://mozilla.github.io/standards-positions/#native-file-system:
The ability to read and write from the filesystem is potentially very dangerous. We will need to carefully consider any solution in light of the security and privacy implications. We recognize that the spec authors take this issue seriously, but we are concerned that any solution will increase the risk of security incidents more than we are willing to tolerate. Right now, there isn't enough detail in the specification to make an assessment of these risks, so we will defer our decision until we have more information.
...and a longer, more detailed answer from a while back (2012) @ https://hacks.mozilla.org/2012/07/why-no-filesystem-api-in-firefox/
Apple gets right to the point @ https://lists.webkit.org/pipermail/webkit-dev/2020-August/031362.html (2020):
Apple's WebKit team does not support this feature due to the security / safety concerns.
There are good reasons why standards bodies exist and why we have multiple browser implementations to test these things. This particular API is not ready and should not be relied upon for production use, unless a developer is willing to accept the risks of it changing and also make a fallback solution as well.
Also: Be wary of web.dev; it's a Chrome-specific site (and Google doesn't really explicitly state that), unlike sites like MDN and CSS-Tricks which are for all browsers. There are a lot of things on web.dev that do work on all browsers, but there's a bunch of stuff that's proprietary to Chrome alone (and the site pretends Chrome is equivalent to all browsers, which it thankfully still isn't).
Chaphasilor
commented
3 years ago @garrett I know all that, and as I stated, it was just a idea for adding a neat feature, if available and needed/wanted.
I wasn't totally sure if you only wanted files from finished projects or also from WIPs, hence my suggestion.
There was no need for such a response, but of course it might be useful to someone else reading the thread \^\^
And I agree, what I proposed would likely warrant its own issue :)
garrett
commented
3 years ago There was no need for such a response
I wasn't being harsh. I was sharing information relevant to this PR and your comment. I provided details to back up my points.
It wasn't clear if you wanted to take this PR in another direction, but it seemed like it could go that direction if not addressed, so I addressed it.
As I use Firefox, changing the purpose of this PR to use some experimental, unfinished Chrome API would mean anyone using something that is not Chrome would not be able to use Penpot in their organization, as a interoperability (which is what this PR is about) is a requirement for me (and others) to be able to use Penpot. (That said, I have used Penpot a little already, but to really rely on it will require at least basic import/export features of Penpot files, not just its current SVG export that turns the text into paths and such.)
And, while it might be something you know about, many others aren't aware that web.dev is partially a propaganda site for Chrome. There are some really useful things on there, but they need to clearly state when something is experimental and for Chrome only, otherwise that will further cement Chrome as a de facto browser and ostracize everyone who wants to use a different browser.
it might be useful to someone else reading the thread
Exactly.
I don't know your background; I was replying to what you wrote for you (in case you didn't know these things already) and others too.
likely warrant its own issue
That's another point I was addressing in my comment.
What you suggest would be cool, certainly, but it's different from basic import/export. (What you suggest would probably build upon the work needed to save locally and import from local files. However, it would depend on a Chrome-only API that's only partially implemented and is probably in flux and could very well get pulled like so many other proprietary Chrome APIs.)
Chaphasilor
commented
3 years ago @garrett okay and that's why I included this part right here:
Basic import/export is the way to go for now, but I feel like this API would allow for a much better UX and make working fully offline possible!
I also didn't mean that your comment was harsh but that you wrote a whole blog post about this \^\^
Also, if we're already nitpicking:
The API is provided by Chromium, not Chrome. That means it's supported by not only Chrome but also Edge (which I use), and potentially also by Opera and Brave.
This is a good portion of the browser market, meaning it could warrant adding a feature as a progressive enhancement if available, and simply leaving things unchanged for anyone using a browser that's incompatible with the API :)
Just because some people can't make use of a feature, that doesn't mean no-one can.
I hope you understand this :D
niwinz
commented
3 years ago Hi @garrett and @Chaphasilor , first of all, thanks for this detailed feedback, suggestion.
Keep in mind that we use SVG as rendering format, so we use the browser facility to render SVG & HTML instead of using typical canvas. But this does not means we internally use svg/xml to store the data. In fact, the browser when interprets the SVG does not stores it internal as xml. Additionally, penpot is not a SVG edition application. It is a prototype/design tool, that stores a lot more not SVG related additional data.
Having this in the context, we still need to consider/discuss what format we go to use for saving/exporting the penpot files on the local computer, but single SVG file is a bit limiting and not very efficient way to store all the info needed by penpot file (because as I said previously, penpot is not svg editor, is a prototype/design tool and stores a lot of other svg unrelated info...)
A possible other option is store it as a zip file containing all the necessary info for the export/import (backup) round trip. Yes we know that having all saved into a single SVG file is very attractive, but we need to consider many options and choice one with a good balance between efficiency and usability. The main goals we have internally is allow users to be able save locally files for backup purposed and the users have no strict dependency on design.penpot.app. If we are able to address other features additionally, that would be great.
The FS API is very interesting, but we want to be multi-platform, and using experimental chromium-only API is not an option I think.
It all comes down to: we need to first thinking on which problem to solve and then find a good solution for it. Right now, export functionality is a very different concept and different use cases for each person:
And all this ideas are great but they are pretty different use cases for a simple "export/import" functionality, and each one can be addressed separately if it is feasible.
garrett
commented
3 years ago a whole blog post
Well, I often write in GitHub as a designer+developer and need to back things up. It's no different here.
I could've just disagreed with you, but wanted to state why, so that Penpot developers and anyone else reading this issue would know a bit of the important background information.
The API is provided by Chromium, not Chrome.
Google's promoting and driving the API for usage in Chrome. Having support in other browsers is incidental, and some browsers based on Chromium actually do turn off features they see as impacting privacy. So it's guaranteed in Chrome (for now), but could more easily disappear from non-Chrome browsers that are based on Chromium. Hence my focus on Chrome, as the devs at Google are pushing for this, not those at Opera and Brave.
But, specifically:
But, yeah, progressive enhancement is always a good idea for features. But Penpot would need to basic enhancement for all browsers first. :wink:
I hope you understand this
I've been working professionally in FOSS (Free and Open Source Software) since the late 90s and spent a large chunk of that off and on with web development. I currently work as a designer+developer in a project that's heavily web-based, with "cutting edge" web tech that uses progressive enhancement and tries to support all major browsers. I help evaluate which APIs we should use and look at the pros and cons when it comes up, as well as the support matrix of browsers. I even have friends who work in web browser engine development and we chat about things like this. I know. The thing is, does everyone reading this thread know about all this stuff like you or I do? Hence, I'm explaining it.
Even people in the web development community get these things wrong sometimes. Here's a blog post that talks about this in general and also specially about the File System Access API: https://ambientimpact.com/web/snippets/why-browser-diversity-matters-chrome-unilaterally-creates-de-facto-standards
garrett
commented
3 years ago @niwinz: Thanks for your response.
What I'm looking for is mainly to be able to migrate, share, and backup work done in Penpot, regardless of format.
SVG and PNG export and import exist in some fashion at the moment (exporting is limited to pieces of the artboard and it unfortunately converts the text to paths, so it's problematic at the moment, but that's a different story). I'm sure these will be improved over time. Thanks for already including these!
But, back to this issue at hand: exporting the internal format as a zip would be great. Perhaps we should rescope this issue to only these items. I'll update the top comment.
Edit: I did a strikethrough of the SVG point and added an explanation next to it.
lrq3000
commented
3 years ago But, back to this issue at hand: exporting the internal format as a zip would be great. Perhaps we should rescope this issue to only these items. I'll update the top comment.
I was going to suggest that. I wanted to use penpot for mockups, but the lack of a possibility to make local backups is a barrier IMHO. I checked the timeline feature but it doesn't work as a backup feature, I made several modifications and they did not register.
Just a zip export would be great. It wouldn't cover other cases but at least it would allow for backups.
PS: just for context, the goal of a backup would be to host it alongside other specs files in the git repo of the opensource project I'm working on. I think this is a pretty standard practice. Unfortunately for the moment, using penpot means that the only version that exists is on penpot, it doesn't fit well with such an opensource workflow, that's why I consider it a barrier, although penpot is certainly a very promising software.
garrett
commented
3 years ago @lrq3000 summarized it perfectly in the PS. It's really the dealbreaker for me to be able to use Penpot for work. Once this is solved, I should be able to happily use it.
Specific background: We put all of our mockups and related designs at https://github.com/cockpit-project/cockpit-design. Right now, that's the source files from Inkscape (mainly) and Excalidraw (just recently) as well as exports as PNG, so developers can always open the files and we can hotlink the mockups from elsewhere (such as GitHub issues).
niwinz
commented
3 years ago Hi @garrett and @lrq3000, we are already working on it and, the first version of export/import will probably be available on the next release.
lrq3000
commented
3 years ago Awesome @niwinz , thank you very much!
Finally I still used penpot for my mock-up because the workflow seemed to fit my workstyle better, and indeed it is amazing! The components and copy-paste approach with shared attributes is amazing, it saves so much time! That is a very impressive piece of software, it is crazy fast to design a mock-up with it (it took me 1 day to mock-up an app I was thinking about for over 1 year)!
Export/import would be a perfect addition to make this software perfect for open-source workflows! Also I wanted to add that with the export feature implemented, third-party developers will be able to more easily and independently work on parsers/converters to other file formats such as HTML or other softwares, so it can actually help to also reach the other features on the wishlist :-)
lrq3000
commented
3 years ago I just saw the last update, that's AWESOME! Thank you so much for implementing this feature (and others) so fast! :D
I guess this issue can be closed now?
I'd just like to ask two last questions:
elhombretecla
commented
3 years ago Hi @lrq3000 :)
"Export shared libraries" will export the file itself and all the shared libraries linked to this file. You will get into your dashboard 1 or more files once you will import it to Penpot (libraries separated)
"Include shared library assets in file libraries" will export the file itself with all the libraries merged into the file library. Only 1 file will be imported with all assets included.
Interactions are included.
Comments are not included in the export.
niwinz
commented
2 years ago I think we can close this issue, In any case, this issue contains very nice conversation about many related things. Right now the export import is implemented with compatibility with other svg tools in mind, but it generates a lot of inefficiencies. We are considering have a "second", custom format, that just stores the file data as blob and the related media in a zip file. It will make the importation more faster and will serve better for backup purposes.
Wow! Penpot looks awesome! Thanks for all your hard work on the project and the alpha release!
I've been waiting for this since early announcements and played around with design.penpot.app yesterday.
I'd like to be able to save projects and files locally, so I can:
Additionally, I would like to import these files (project & file level) so I can:
Apologies if these features are somewhere in the UI, but I cannot find them anywhere, so I'm assuming they're not there.