Comments (13)
Thanks for pointing to the right direction. I'll focus on Travis for now, will keep an eye on this :)
from bottles.
Thanks for pointing to the right direction. I'll focus on Travis for now, will keep an eye on this :)
Fixed GitHub CI with commit 176d9f8
Fixed Travis CI with commit 4f0ad02
You can find all the commands we used (separated by steps) in the github actions configuration file
But we are going to only use Travis for Bottles. Maybe GitHub Actions can be used for wine builds.
from bottles.
We have been releasing many versions in the last month but have reached a very stable beta point. I believe you can do it.
from bottles.
First of all, having to depend on a system (Flatpak) that not all distributions integrate as standard yet. This could lead to the user having to install and configure it manually, although setting it up takes only a few minutes.
Most distros and major DEs supports Flatpak out of the box. You have to just install your app from store or flathub.org if you prefer GUI or just enable Flathub (it's usually already done) and run flatpak install bottles
. If you don't have Flatpak in your system, you have to install it. After that, you'll get updatable application tested in its environment with icon in your application menu.
AppImage is also supported by most distros. It needs only FUSE support. It also might be not installed and user might has to install it. After all, AppImage don't create an icon for app menu so user has to set it up manually.
There are no centralized systems, the user will only have to download a single file and run it. That's all. Incredible.
It's not so cool as you think. First of all, downloaded file can't be just ran. It doesn't have execute permission, so user have to add it manually. Secondly, user looses an ability to update your application. They have to go to your GitHub sometimes to find out if there are any updates. Thirdly, as I already told, user don't have this app installed and has to manually find and open this file any time it's needed.
Here one of the fundamental aspects of Appimage takes over: compactness. It is a single file that is easy to download, run, update and remove.
First of all, it's compact by number of files but not by its weight. Flatpak uses runtimes shared by all applications so you don't have to ship GTK and other basic dependencies with your application. Secondly, AppImage is not easier to download (seek file in GitHub releases VS just press "Install" in application store such as GNOME Software or run flatpak install bottles
), run (press an icon in app menu VS find AppImage file in file manager and open it) and update (seek file in GitHub releases VS update with other Flatpak apps with application store or flatpak upgrade
).
Finally, while the Flathub repository is curated and well maintained, we don't want to official depend on repositories for distribution.
So you make it harder for user to find and install your application. Also depending on repositories in case of Flatpak is a price for cross-distributive distribution without shipping all your dependencies with you. Flatpak's runtimes allows you to don't depend on distros, software or software versions. For example, when I installed Bottles from Flatpak on my Fedora 34, all works good not depending on GNOME version or graphic system because of it. Now when I use your AppImage app fails to start because of using gsettings from older GNOME and becase I use Wayland. Flatpak solves it by using runtime and disable Wayland access in manifest.
So after all, do you really think that AppImage is better?
from bottles.
Updated Appimages can be found here: https://github.com/bottlesdevs/Bottles/releases
from bottles.
Any chance you can share how you did this? I can see travisci and github workflows just cant figure out its all tied together
from bottles.
Any chance you can share how you did this? I can see travisci and github workflows just cant figure out its all tied together
We are currently using Travis to create the appimage for each commit. We would like to migrate to GitHub actions but we haven't finished the work yet so we will still use Travis.
The process is quite simple, you find all the steps in the .travis.yml file.
from bottles.
Thanks for pointing to the right direction. I'll focus on Travis for now, will keep an eye on this :)
Fixed GitHub CI with commit 176d9f8
Fixed Travis CI with commit 4f0ad02
You can find all the commands we used (separated by steps) in the github actions configuration file
from bottles.
Is it okay if I submit to this AppImage kinda of list repo the release AppImage of Bottles ?
from bottles.
I've done that, but there seems to be an issue with the build test :
===========================================
============= TRYING TO RUN ===============
===========================================
/tmp/.mount_BeingT2Prewj/AppRun: Bourne-Again shell script, ASCII text executable
-rwxrwxr-x 1 root root 1.5K Dec 23 18:00 /tmp/.mount_BeingT2Prewj/AppRun
kernel.unprivileged_userns_clone = 1
Error: cannot configure loopback device
NUMBER_OF_WINDOWS: 0
ERROR: Could not find a single window on screen :-(
IceWM: using /home/travis/.icewm for private configuration files
convert: unable to read X window image `0x200011': Resource temporarily unavailable @ error/xwindow.c/XImportImage/5005.
convert: no images defined `database/Bottles/screenshot.png' @ error/convert.c/ConvertImageCommand/3210.
code/worker.sh: line 293: kill: (9219) - No such process
The command "if [ x"$FILES" != x ] ; then for FILE in $FILES ; do echo "$FILE" ; bash -e code/worker.sh $(readlink -f "$FILE") ; done ; fi" exited with 1.
There was this Warning
that I feel was just a quick notice about image file formats, but I didn't see anything else relevant :
WARNING: Icon is not in PNG format. It should be so that it can be used as a thumbnail
Does the problem relate to the fact that there is no X window ??
This file descirbes how the AppImage are generated ?
from bottles.
The correct file is .travis
.
They use Travis to test the AppImage but that I know of Travis hasn't an X server on it. I should investigate.
from bottles.
I think the flatpak would be the best methods for the reasons mentioned above too. appimage didn't work out of the box for me either, where as the flatpak version did.
from bottles.
First of all, having to depend on a system (Flatpak) that not all distributions integrate as standard yet. This could lead to the user having to install and configure it manually, although setting it up takes only a few minutes.
Most distros and major DEs supports Flatpak out of the box. You have to just install your app from store or flathub.org if you prefer GUI or just enable Flathub (it's usually already done) and run
flatpak install bottles
. If you don't have Flatpak in your system, you have to install it. After that, you'll get updatable application tested in its environment with icon in your application menu.AppImage is also supported by most distros. It needs only FUSE support. It also might be not installed and user might has to install it. After all, AppImage don't create an icon for app menu so user has to set it up manually.
There are no centralized systems, the user will only have to download a single file and run it. That's all. Incredible.
It's not so cool as you think. First of all, downloaded file can't be just ran. It doesn't have execute permission, so user have to add it manually. Secondly, user looses an ability to update your application. They have to go to your GitHub sometimes to find out if there are any updates. Thirdly, as I already told, user don't have this app installed and has to manually find and open this file any time it's needed.
Here one of the fundamental aspects of Appimage takes over: compactness. It is a single file that is easy to download, run, update and remove.
First of all, it's compact by number of files but not by its weight. Flatpak uses runtimes shared by all applications so you don't have to ship GTK and other basic dependencies with your application. Secondly, AppImage is not easier to download (seek file in GitHub releases VS just press "Install" in application store such as GNOME Software or run
flatpak install bottles
), run (press an icon in app menu VS find AppImage file in file manager and open it) and update (seek file in GitHub releases VS update with other Flatpak apps with application store orflatpak upgrade
).Finally, while the Flathub repository is curated and well maintained, we don't want to official depend on repositories for distribution.
So you make it harder for user to find and install your application. Also depending on repositories in case of Flatpak is a price for cross-distributive distribution without shipping all your dependencies with you. Flatpak's runtimes allows you to don't depend on distros, software or software versions. For example, when I installed Bottles from Flatpak on my Fedora 34, all works good not depending on GNOME version or graphic system because of it. Now when I use your AppImage app fails to start because of using gsettings from older GNOME and becase I use Wayland. Flatpak solves it by using runtime and disable Wayland access in manifest.
So after all, do you really think that AppImage is better?
Assuming that this issue is very very old and that over time we have added Flatpak, Snap and Deb to the official distribution methods, as well as AUR, Fedora, Void and Nix among those maintained by the community.
Flatpak is certainly the format that has been most adopted by distributions but it is not ready to use as you say. Wanting to give an example of distributions (important, widely used) in which there is no default Flatpak:
- Ubuntu
- many of the Ubuntu flavors (Kubuntu is an example if something hasn't changed)
- Debian
- Solus (moving towards snap packs as far as I know)
these too (which are aimed at advanced users so they know what they need to do, but it's not out of the box anyway):
- Arch Linux
- Void Linux
- NixOS
Many distributions have Flatpak by default but do not have Flathub, the repo we use to distribute Bottles. So the user will still have to take some steps to install our software (all clicks but it also depends on how the store behaves because very often or almost always, once Flathub has been added you have to restart the system or stop the GNOME Software process to make them find it).
Yours are certainly all very valid points but to the question: "So after all, do you really think that AppImage is better" I answer yes. Considering the facts, what a package has to do is be distributed and easily available everywhere and in fact Appimage is the best method in terms of portability and large-scale distribution.
The first step of a novice user (especially if he comes from Windows, therefore a part of Bottles users as the rest is mostly advanced and does not arise these problems) is to go to the product site and download it. If you are a new user and you install Ubuntu for example (due to the strong image it has it is often one of the first choices of new users) and you get to know our software, if you open the snap store you obviously do not find the flatpak but the snaps. So the user goes to the site and you think it is better to tell him to open the terminal, install a package, reboot, add the remote flathub, install bottles (always from the terminal because he should install gnome-software and replace the snap store, losing the only frontend it has to manage snaps)? Or do you think it's better to download a file, make it executable, and then run it?
I don't think the perfect package exists. As a user I have preferences, as a developer I have others, but we also have to think about the end user and how it is best to reach him. Assuming Flatpak is everywhere and Flathub is equally everywhere is wrong IMHO.
I understand what you say about updating, distribution and everything in between and that is why over time we have also adopted other official formats such as Flatpak, Snap, Deb and others maintained by the community such as AUR and Fedora.
from bottles.
Related Issues (20)
- [Bug]: An app installer will run when Bottles directory is default, but will not run if Bottles directory is custom.
- [Bug]: Permission denied error when trying to save a file in Translation Workspace XLIFF Editor
- [Request]: Roblox Support HOT 10
- err:xrandr:xrandr14_get_adapters Failed to get adapters HOT 2
- OpenSUSE MicroOS/Aeon/Kalpa wine/proton issues (noexec filesystem)
- [Bug]: Required Vulkan Extension VK_KHR_surface Not Supported HOT 1
- [Bug]: Crash on startup
- [Request]: Option to open prefix in file manager
- [Bug]: failed to install microsoft arial font HOT 12
- [Bug]: Ableton installer script fails at `tlsetupfx.exe` (ableton push driver installation) HOT 2
- my very detailed bug report was just closed because the github bot is a stupid idiot HOT 3
- [Bug]: Error when swiping or scrolling with 3 fingers on laptop
- [Bug]: "Failed to create a placeholder directory file" HOT 1
- [Bug]: Unable to set runner after importing with missing runner
- Bottles executables no longer shows local windows files. HOT 4
- [Request]: Library QOL
- [Bug]: Can't view any file after creating a bottle HOT 1
- ximput xbox360 not working
- When I was trying to open any domain of bottles they were not opening for me.
- [Bug]: Thick black borders around the Library tab HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bottles.