Porting the editor to the desktop?

[blinovartem]

The editor works as a program on desktop systems Windows, Mac and Linux. Is this possible? Will it be in the future?
And if possible work offline.

[niwinz]

Very interesting question. Porting to desktop probably is posible using electron or similar technologies. We will evaluate it in a future.

Working offline is an other story; right now is not contemplated, but 90% of requests are made through an abstraction layer, so should not be completly imposible.

[Manueljlin]

Would be amazing to see! Especially to avoid triggering the browser menu on Vivaldi and Firefox with Alt when measuring stuff

[garrett]

On Firefox, you can go to about:config and change ui.key.menuAccessKeyFocuses to false to prevent the menu from showing up when tapping alt.

However:

• Hitting F9 will still show the menu (if you want to do that)
• The menu shortcuts like alt+f (to show the file menu), alt+e (edit menu), alt+v (view menu), etc. all still show their respective menus

[vir-gomez]

Hi, thank you for developing this awesome tool.

So, I am interested too in using penpot on the desktop, same as https://github.com/excalidraw/excalidraw it would be WONDERFUL because I work with a tablet graphic tablet.

I understand this is a website and not a webapp, isn't it? I am just a graphic designer and SEO, sorry for my ignorance.

Luck!

[KiranWells]

It does not seem like much thought has been put into porting to desktop, but I think it would be a great idea, even if it is just for the performance. In that same vein, using another library, such as Tauri, may end up giving a much higher performance boost.

The main difficulty would likely be converting the network request layer to work with the desktop framework, but with the right configuration, that may not be necessary.

[hansnolte]

In the FAQ under "How Can I Make Penpot Work Offline?" stands
... "Please wait for our electron-based app Bundle Later This Year."
https://help.pepot.app/faqs/

Any news on that?

The only thing that keeps me from using Penpot is that it is web based.
And I'm pretty sure that a Desptop Application will significantly expand the potential user base.

[jre10]

Hi,
Thank you for sharing your valuable suggestions on Penpot.

I am not sure that Penpot with desktop applications would be a priority or a great achievement.

In my humble opinion, the priority is to continue to develop some functionalities like these ones we find in Figma :).
For instance: Polygon, Inspect, Communication. :) Mirror for iOS and Android :).
And a space like FigJam would be great :) for the teams :).

And an integration in Thunkable (open source app for creating mobile and web app :) ) would be tremendous :)

At the same time, Figma as desktop applications for Windows and MacOS :)
But not for GNU/Linux! An opportunity for Penpot? :).

Note too:
I am interested in a way to create easily tables (just the design) :). This does not exist in Figma :).

This is my humble opinion from a newbie iwith Penpot :).
@PenpotTeam. Thank you for your work with the last version 1.9 :).

In any case, be sure I will stay interested in Penpot with Desktop application :).

[ktryndchrs]

The main reason for me to use a desktop version of an app such as Penpot if for keyboard shortcuts feature so that they don't interfere with the browser ones. If there is a way to manage it.

In that regard, my personnal best solution at the moment is a tool such as Natifier
https://github.com/nativefier/nativefier

[vintprox]

Ah yes, the shortcuts in browser... Once upon a time, I went away for mere minutes, and was welcomed by broken shortcuts in Penpot: like, browser could not delegate Ctrl+D to the page (for object duplication), and I was stuck fighting with "Bookmark" shortcut. It's always annoying to have your primary input method do stuff you don't want at all.

Another problem is no support for renaming by F2 and similar shortcuts I'm used to on desktop apps.

[lublak]

Is there an eta for this?

Later 2021 is already over. Therefore, I assume that it will only 2022 what :P.
Is it still on the screen or was the idea discarded?

[garrett]

Note: You can use Podman instead of Docker and it works fully as your own user, without needing admin rights (that is: as rootless containers).

Use podman-compose (with podman-compose up -d) and select docker.io when it asks for the remotes. When everything is up and running, visit http://localhost:9001/ in your browser.

It might be a bit trickier to get it working on Windows or macOS, but it's possible. Podman needs to run a lightweight vm on those OSes (with podman machine init) and would first need to be installed in WSL2 on Windows or with brew install podman podman-compose on macOS. But otherwise, it should work similarly.

It's not the same as just launching an app, of course.

---

You can even use docker-compose with podman with a rootless container, but you'd have to point it at your user ID (usually 1000 by default):

docker-compose -H unix:/run/user/1000/podman/podman.sock up -d

---

For the time being, if you don't mind using the hosted solution @ <penpot.app>, you can use a Chromium based browser (such as "Chromium" or "Chrome") to create an "app" that you can launch from the desktop (to access the online hosted solution). It also works with GNOME Web, but it's currently much slower (especially for panning around).

Unfortunately, Firefox dropped "app" installation on desktops a while ago... but Penpot works in in a Firefox tab.

[lublak]

that is of course possible. The desire for easy installation and use is still of course given :P
In theory, you can make an application based on electron that starts penpod as a server in the background.
But I don't know of any portable alternative to docker or podman at the moment.
Better would be without docker container of course.

[niwinz]

Heheh, the priority changes but yeah, we are still evaluating this. From our point of view, there are unclear list of benefits having desktop app.

• Many people think and expect that desktop app will bring better performance, but this is untrue, since we will use the same web technology, rewriting the app in native language, will cost the same as doing penpot from scratch in other language, that is totally crazy and the benefits unclear.
• Others think it bring offline mode, but this is very different feature, offline and desktop app can come together but each one does not imply the other. We still don't know what is real supposition behind the "desktop app" request, if they want just an app outside the browser tab or they want offline.

The unique reasonable and valuable request is that shortcuts does not clash with the default browser one... and yes this is a great benefit but we are still developing more important features than this.

However, returning to speak about the "offline" feature: it is not mandatory to have a desktop app for offline, in any case, an offline mode with 100% features of penpot is pretty infeasible, because we will need to re-implement many backend code in frontend, such that running headless browser (no we cant reuse the same browser because we don't have access to same api inside the browser context), image and/or font conversion, assets storage, and many other stuff that are running right now in backend. The offline mode I image is some kind of limited features for prototyping, with later synchronization when you becomes online, but you will not be able to upload images, fonts, etc... And speaking about fonts and assets, they are all loaded from remote storage, so they will be need to be explicitly cached before go offline. I try to say that offline has very good bunch of challenges for make it trully usable and right now is not our priority. If you want really go offiline, you can run all the componentes with docker-compose on your laptop (it is not ideal but will make it work).

Just have desktop app for have one, does not make any sense form my point of view and we need to research and know the real reason behind the constant desktop app request.

[vintprox]

I'm into this with two hands! Awesome experience like Penpot should be available for the distributed collectives. My concern isn't even about Internet speeds randomly interrupting the flow, but having a functioning app without administrator knowledge and without dependency on hosting.

[KaKi87]

offline and desktop app can come together but each one does not imply the other

I bet there are tons of UX drawbacks for implementing offline mode in browser for such an app.

The first one which comes to my mind is file access : a PWA can't read nor write a file without opening a dialog every single time.

[N-Upchurch]

I know this is an old thread, but on the native app debate: We know that native apps consume less resources in general; as a rule, I don't use web-based apps where there is a native equivalent that is even 70% as good because it's just plain wasteful and bad for the environment. For me, it's an ethical thing; especially when you have hundreds, thousands, or millions of users, using efficient native code is just the right thing to do for the world. QT & C++ apps can be compiled for many platforms, KDE has some fantastic libraries for working with QT quickly, there's Proton Native and NodeGUI for those who must use Typescript / Javascript. Requiring an entire browser engine for an app just seems silly these days.

On a more subjective note, browser-based apps don't feel like serious, professional tools to me. I've been doing design work for 15 years now, and any time I've tried out a browser based app and experienced its weird quirks (scrolling weirdness, browser menus appearing on right click, worse performance, online-only usage, et cetera) I've just felt like I was using a toy - something cool to play with, but too irritating to use as an every day tool.

[KaKi87]

as a rule, I don't use web-based apps where there is a native equivalent

With all due respect, you should then refrain from participating to this discussion and go find or create a native alternative app.

As one of the maintainers said :

rewriting the app in native language, will cost the same as doing penpot from scratch in other language

---

there's Proton Native and NodeGUI

Which do not provide the same developer experience.

---

browser-based apps don't feel like serious, professional tools to me

For everyone's sake, I'll refrain from commenting that.

---

any time I've tried out a browser based app and experienced its weird quirks

Native apps can have bad UX as well as web apps can, when poorly developed, while web apps can have good UX as well as native apps can, when properly developed.

---

Regarding resources consumption of desktop web apps, please look into Tauri.

[N-Upchurch]

@KaKi87 I'm sorry that I seem to have offended you, but my comment was respectful, and I have every right to share my opinion and add my perspective. I read the comments above, and I am aware of the maintainer's point. The maintainer made an economic argument, and I made an ethical one I hadn't seen represented in the thread. I have also heard of Tauri, but thank you for sharing.

[hansnolte]

Hi niwinz,
please look at Lunacy.
It's a Desktop Application with an Offline Mode.
https://icons8.com/lunacy
You can design your complete layout offline and only if you need additional things like Google Fonts, Icons, Assets etc. you go online.

[garrett]

Lunacy isn't Open Source.

Prior to last week, it wasn't even available on Linux aside from Ubuntu and Debian based distributions. (I took the initiative, with the app developer's blessing, to flatpak the deb and make Lunacy available on Flathub for all distributions. It's always nice to have another app available to use.)

While it's a "competitor" to Penpot in some ways... as it's not Open Source / Free Software, it's not really a competitor as a result.

However, Lunacy can open and save Sketch files whereas Penpot cannot (yet). And you can open a Sketch file in Lunacy and copy (as SVG) and paste it to Penpot and Inkscape. Text will be converted to paths in the process (I think this is on Lunacy's end), but everything else works (at least on Linux, specifically: Fedora 35 Silverblue with the GNOME desktop).

Plus, unless you go into Flatseal and disable networking for Lunacy, Lunacy does ping home. But disabling networking will also disable some functionality too (which is why I didn't), including "Photos" and "Illustrations".

[hansnolte]

Hi garrett,

it was just about the on/offline mode and how other programs do it.
It wasn't meant to be a comparison between the two programs.

[vintprox]

@garrett I don't get why we came to comparing two very different beasts? The matter that author brought is about having online modules of Penpot as an option, and not as requirement for app working.

"Like Lunacy did", as I would say - and Penpot's offline implementation doesn't have to be better than Lunacy/Adobe XD/Figma/whatever, since you already point out Penpot's open source factor as the leading advantage. Google Fonts and Assets don't have to be there for UI design, although certainly interesting. Making these as option for user that has connection to server, while maintaining JavaScript frontend application as independent unit - well, it seems only imperative.

[garrett]

it was just about the on/offline mode and how other programs do it.
It wasn't meant to be a comparison between the two programs.

@hansnolte: Oh, it looked like you were recommending using Lunacy instead. As a result I pointed out the licensing and also how it can actually work with Penpot with copy/paste (to be able to extract elements from Sketch files).

I don't get why we came to comparing two very different beasts?

@vintprox: It was @hansnolte who brought up Lunacy.

It's similar (vector-based tool to make llustrations and UI designs), but different (app vs web app, licensing, etc.).

I'm all for having more options available to others (which is why I flatpak'd Lunacy — since I do actually need to open Sketch files on Linux), and personally prefer FOSS whenever possible (which is why I prefer Penpot over other similar tools like Lunacy and Figma).

[fire]

To be honest, I wasn't able to wait for the official release. So, I used the suggestion earlier to use nativefier.

# Install scoop
scoop install GraphicsMagick nodejs
# Restart powershell
npm install -g nativefier
nativefier https://design.penpot.app
# Run penpot native app

[niwinz]

making the application run in an embedded browser engine instead of running it in a browser app does not make the app native. It just detaches the tab and removes browser decoration.

I think this is only the tip of the iceberg when it comes to talking about all the implications of a native application. The hard part isn't running penpot inside a webview... it's probably the most irrelevant part of the process from my point of view.

[fire]

As an outsider, I don't think the Penpot organization has the technical will or man-months to create a robust system for example in c++ using 3D native render, including the live collaboration features and still be able to maintain the web version which is their primary application. Especially if their technical design is a Java language (clojure) transpiled to Javascript? WASM?

As part of the Godot community, I've consider this collaboration problem for 3d scene editing.

Examples: https://github.com/mbrlabs/Lorien, https://github.com/alfredbaudisch/Godello

[KaKi87]

use nativefier

and

create a robust system for example in c++ using 3D native render

are two extreme options.

The intermediate option discussed here is porting to Electron/Tauri (not just for the webview, but for actual framework-enabled benefits).

[fire]

I have no idea. Carry on debating.

[fire]

I'm curious is Electron/Tauri written in clojure? Wanted learn more about how penpot is developed.

[LauraWebdev]

I've been taking a shot at this yesterday.

penpot-desktop

[KaKi87]

This is not offline nor secure though.

<webview>, contextIsolation: false...

[LauraWebdev]

You can spin up your own penpot on localhost, making it fully offline. And concerning security, considering that you can't properly escape the penpot instance url, all security issues would concern penpot as a whole.

[KaKi87]

With all due respect, a webview on one side and a local server on the other side, is not a proper solution.

[niwinz]

Penpot is born as and developed with the client server architecture, as Web Application. Rewriting it all, as standalone, native application is not an option, because doing that it is whole new project. I mean this will require rewrite all the parts of the application. So all ideas about writing full 100% desktop application is not going to happen.

However, thinking in a desktop variant using webview with high integration with system, and in future make it work on a limited way (I mean without collaborative edition and many other advantages of multi-user approach) can be easily approached step by step. Just take in context that we are not so big team, and we can't do everything... so we need to priorice tasks. There are a lot of needed features that are more important for us that having a fully featured desktop app (better components, auto-layout, for example). And I'm glad that the community starts working on its own solution such like the Penpot-Desktop project.

[philippedcote]

I think the Desktop App (Web App) is more important in short term than an Offline App. As an example, many people prefer using the Figma Desktop App, which is self-contained, and doesn’t interfere with the browser tabs. Also, the Desktop App has another advantage: for example, on macOS, you can remap the keyboard shortcuts at will, which is a real productivity gain.

[KaKi87]

So, I'm looking into the possibility of doing this as well, just in case I would be up to it.

My initial idea consists in creating an Electron app that :

• imports the front-end as a git submodule ;
• loads the imported front-end using loadFile (i.e. as any other app does) ;
• intercepts HTTP requests using interceptBufferProtocol (of course, natively binding the front-end to Electron/Node APIs¹ would be the best implementation, but only someone who knows the project by heart can do that).

Toward that end, @niwinz, could you tell me how to turn those cljs files into HTML ?
I thought I could use a bundler to transpile whatever I'd find in this frontend/src directory (e.g. Vite/Parcel/etc. handle pretty much anything) but I was not expecting this, this one is all Chinese to me 😅

Thanks

(1): Or even better — Tauri APIs.

[niwinz]

you can generate the full bundle execute the ./scripts/build command of the frontend directory
It will require some dependencies; they are all solved by the devenv docker image; in this case the command is: ./manage.sh build-frontend-bundle. This obviously will require docker installed.

[KaKi87]

So, even bundling is impossible without Docker ? :/

[niwinz]

yes, it is possible, just you need jvm, clojure, yarn, node installed in order to run this, the docker just has all this already packaged, so you can execute it without needing to install all the stuff in your main system. But there are nothing docker dependent as-is.

[medmedin2014]

For solo and home creators, having fast and responsive desktop version is good choice, because we don't need any collaboration, and we need the app to run natively and fast on our machines, currently the web or self-hosted version is really slow and laggy like any browser based app.

[SimplyPhy]

I just want to add something that seems to be critically missed in this discussion:

Many users will simply not consider using Penpot until they can download it.

You really needn't even get into the discussion regarding offline mode, native performance, etc. If you don't make it downloadable, people won't download it. And that means they won't use it. I really can't stress this enough.

I'm not negating the importance of what users are requesting here, I'm just saying those details are less foundational than simply increasing peoples' willingness to give it a shot.

P.s. this is also true of Tiaga.