search

flxzt / rnote

Sketch and take handwritten notes.
https://rnote.flxzt.net
GNU General Public License v3.0
7.89k stars 267 forks source link

deb/snap/appimage version #174

Open dnet890 opened 2 years ago

dnet890 commented 2 years ago

Hi to cover wider linux distros. Is it possible to get this app on deb/snap/appimage?

flxzt commented 2 years ago

with package formats I am personally committed to flatpak. Somebody else would need to volunteer and be willing to maintain another package format.

Additionally Rnote is already available natively for some distros, see https://repology.org/project/rnote/versions .

Imerion commented 2 years ago

A deb package would be great! This looks great and it would be nice to try out!

numbertumbers commented 2 years ago

Literally any other package format is unnessecary because Flatpak is already universal, it already covers literally every Linux distro AND BSDs, I don't understand any use for any other package format, sorry for the package management politics, but I feel rather strongly about this.

Imerion commented 2 years ago

While I see no need for snap, which just seems to do the same thing as flatpak, I have to disagree. There are still many reasons to want native packages like deb and rpm. There are still many issues with desktop integration that just doesn't work well with flatpak, which means many workflow-related troubles - not to mention accessability problems. There are also issues with performance and resource/storage use that is very real for many users. Anyway, I'm not saying either should be the only option but I would personally prefer a classic native package. It's good to know several distros already have them, but if someone have the knowledge to do a .deb package it would be appreciated as well. :)

werdahias commented 2 years ago

+1 for a native deb. The problem here are two main factors when it comes to that:

  1. Per debian policy all crates need to be available as debian package. This means first of all a lot of pre-packaging
  2. As rnote uses the GTK crates these need to be updated first as the ones in debian are really old

I am already working on the GTK update, but this will take time. It's mostly done. From what I can see most of the other crates are already in debian so that would be just a small piece of work. Also one issue is that @flxzt has his custom piet fork which complicates things as all crates packaged are directly taken from crates.io. I'd suggest that you upstream your changes or publish it as a separate crate.

In the meantime I'd recommend building it locally/using the flatpak. If anyone wants to help, join the #debian-rust IRC channel and ask :)

Cheers

werdahias commented 1 year ago

From taking a quick look:

I will start on nalgebra, fileformats and compose. It would be of great help to me if at least those two would be published to crates.io as the debian rust teams' workflow is based on that. I could work around that but it would be way easier to do it that way. Also ink-stroke-modeler is not on crates.io

flxzt commented 1 year ago

I can publish ink-stroke-modeler-rs at some point (after some polishing), but I want to keep the other crates internal. They are not really intended to be libraries, to be on crates-io and are subject to change at any point. Mostly are there to separate concerns. Couldn't you treat the entire repo as a single codebase?

werdahias commented 1 year ago

Thanks for considering a release of ink-stroke-modeler-rs. I have to check if I can package the other two crates some other way. It would be more convinient as the whole workflow is based on crates.io

philipwilk commented 1 year ago

Can i ask you elaborate on this? I don't mean to be rude, but I don't think any of your points are true. Flatpak apps create .desktop files just like any other ones, so they can be used from your DE like any other ones. There is no performance issue because flatpaks are just "cgroups, namespaces, bind mounts and seccomp". Not sure where your accessibility problems or resource/storage use claims are coming from. Flatpak only installs runtimes and libraries once, then reuses them for all flatpaks, as your native .deb runtimes and libraries do, meaning that apps aren't larger at all. Your flatpak apps still run in userspace like regular apps as well, and have the same cpu and gpu acceleration as any other app.

"There are still many issues with desktop integration that just doesn't work well with flatpak, which means many workflow-related troubles - not to mention accessability problems. There are also issues with performance and resource/storage use that is very real for many users"

Imerion commented 1 year ago

@wiryfuture No problem! Things might have changed since last time I tried this, but some of the issues I had included:

There were a few other things too, but the slower startup times might have been limited to snap apps - I cannot remember exactly for the moment as I tried them a bit back and forth, but I remember most of these issues being persistent across both formats.

werdahias commented 1 year ago

@flxzt After some discussion on the rust team: External stuff isn't really supported. The best way (packaging-wise) would really be to publish those on crates.io as the workflow is based on that. I get that this would create more work for you and wouldn't really make sense for internal crates. If you don't mind I could also publish them (just for packaging) which would save you the work.

philipwilk commented 1 year ago

@wiryfuture No problem! Things might have changed since last time I tried this, but some of the issues I had included:

* My selected QT theme (using the Kvantum theme engine) wasn't used for QT apps and my GTK "theme" and custom CSS settings (like using colored icons instead of monochrome ones) wasn't used/respected. Not being able to use a customized theme is the main complaint when it comes to accessability.

* Software did not remember the last folder I used when loading/saving, instead defaulting to a weird "latest files" construction which was very confusing and meant I had to navigate to the correct folder every time I had relaunched the software. I save and open a lot of files when working and this slowed down my workflow a lot. I also remember trouble accessing files from some parts of my file system.

* A huge folder (> 3 GB) was created in my home folder containing flatpack files. Since my SSD is only 128 GB with most of that used up that was an issue. Applications seemed to take up more space too, perhaps due to a greater variation in used libraries.

* Permission issues. I want software to have permission to my hardware by default so everything works out of the box. Trouble with video conference software getting access to my camera and microphone is an example.

There were a few other things too, but the slower startup times might have been limited to snap apps - I cannot remember exactly for the moment as I tried them a bit back and forth, but I remember most of these issues being persistent across both formats.

Themes do appear to be a bit annoying to have to set up manually, but it is possible (would call that customisation, not accessibility) .

If your file selector can remember the last opened folder, it will remember the last used folder, unless the flatpak app is somehow using the file selector incorrectly, rnote does it fine, and so does every other flatpak app I have used.

I might not have been clear enough earlier; flatpak apps are not larger than any other apps. The huge folder in your home folder is libraries, as you suggested, but it's not a a greater variation in libraries, it just seems like a lot because the runtimes are in one place, so it is easy to attribute them to "flatpak apps are big". Flatpak has to download the runtimes that are needed by apps, like your native package manager does for its packages. Similarly to what your package manager does for its apps, these runtimes are then shared between its apps. TLDR; flatpak has to download the runtimes apps need initially (which you often install on your operating system without realising), but the apps are still the same size as anywhere else.

Permission issues (unless exotic) are the fault of the flatpak author. When you create a flatpak app, the app requests the permissions it needs to have available by default, and everything will just work, like anywhere else. Therefore, if an app needs camera and microphone access, such as in your example, but the author doesn't make the app request those permissions, then flatpak won't give the app permission to use those, meaning it would be the author's fault, not flatpak's.

A point I don't think you raised, which I think is probably the most annoying, is that you have to manually give flatpaks access to folders outside your /home/(user) folder. This is very easy to resolve with flatseal, but I admit that it isn't great to have to do this.

Imerion commented 1 year ago

@wiryfuture Thanks for the info! I really appreciate learning more about this. I am not against this just because, but I just want to make sure things work as well as they always have. :)

Sounds like some of the issues might have been due to suboptimal packaging. I can also see what you mean by apps not being larger, but having two big sets of libraries instead of one means more disk space being used in totalt. That is a minor issue though. The last thing you mention about access to folders outside home is however very irritating - that's the part I mentioned as trouble accessing parts of my file system.

But themes are the big sticking point. It is good to hear it can be done - even though it seems to need quite a bit of extra work for each newly installed app. The thing is that I have a small business and one of the things I do is to set up custom made systems for people, and most of them are old or have disabilities like aphasia. For this group themes are very much an accessability issue. It can be everything from high-contrast themes, themes with larger text and larger buttons, non-flat high-color themes so it is more obvious what is what, etc. High color icons is also very important - for people who have trouble with their memory it really helps to know that "it is the red icon that looks like this, or a blue one next to it", etc. I have worked with these people for almost 10 years and correct themes make a world of a difference, and sadly most modern flat themes/icons don't have what these people need. And that is why I always put a lot of time into making sure everything looks correct and works automatically out of the box.

Perhaps these things can be made to work smoother in the future. For me the big worry now is mainly having to do a lot of extra work, like installing and setting up Kvantum twice if I understood the linked article correctly.

werdahias commented 1 year ago

fyi, I have GTK updated, so the next chunk of work for a deb would be nalgebra

soumyaDghosh commented 1 year ago

Anyone who would like to use a snap package. It exists, and I am maintaining it from v0.5.17

https://snapcraft.io/rnote