Create ImageMagick #456
Create ImageMagick #456
Conversation
[ci skip]
|
Getting
Does it not like to be run inside Firejail? |
|
I've been trying out ImageMagick's AppImage for a while (even before they published it on their github), and it's always worked well for me.
|
|
@simoniz0r does it also run correctly inside Firejail? |
|
I'm not paranoid enough to care lol. |
|
@KurtPfeifle if you have some time, maybe you can have a look? Thanks. |
|
I just submitted a PR to the ImageMagick folks regarding a different issue and am waiting for it to become merged. When I run my locally built AppImage with the new fixes in Firejail, I see this: Currently I've no clue what that means. Would have to dig deeper, once I've got the time for it. Or does this give YOU a hint, @probonopd ? |
|
I guess we need to ask at https://github.com/netblue30/firejail. |
|
Or just stop running all of your tests in a firejail because that's not how most users would be using an AppImage. You're trying to emulate a normal use case here; what you're doing is just adding more hoops for people who are submitting AppImages to jump though. |
|
I want to filter out applications that just take connectivity for granted. Because where I work I don't always have connectivity. |
|
That's really not logical to do. Those applications let you know that they need internet access before you download them. |
|
Therefore, you would know that the application needs internet and not attempt to use it without. Adding this test is just breaking things. Please remove it. |
|
Like with an application such as parsec, Discord, or any other application that has to connect to a server in order to function, you're just adding a test that breaks them for no reason. You, as the user, would be able to figure out if the AppImage works without an internet connection just fine; you're kinda assuming that users wouldn't be able to figure that out at all here. This test doesn't need to be happening; it's only breaking things and not helping anyone. |
|
If you do feel as if this test is necessary, at the very least, you should be running a test without firejail to see if the AppImage works well without it and one with firejail to see if the AppImage works well with it. You could even store that data on AppImageHub and let users know if AppImages work well with firejail or not. |
|
Just because I have internet at the moment when I download an application, does not mean that I have internet all the time. Also, I can get applications from the local network or from copying them from a USB thumb drive. So it is not necessary to have internet in order to get applications. |
|
That's not at all my point. My point is that the user can figure that out on their own. You don't need to be holding their hand here and breaking AppImage tests for no reason by putting them in this firejail. |
|
You could even be giving them useful info about whether or not it works in a firejail if you did tests with and without it... but you'd rather just say that any AppImage that requires the internet is broken. |
No one says that. But the application must give a clear message (in the GUI, if it is a GUI application) rather than just crashing with an unhandled exception. |
Now you're just making up things that you think application writers should have to do. An error in the console is perfectly acceptable here on Linux; that's how most applications send errors. |
|
Just get rid of the firejail tests or do them in a sane manner, please. |
|
If an error in the console is acceptable for an application to be in something like Debian's repos, why would it not be acceptable here? |
For GUI applications, that is not sufficient, because users are never gonna see it there. |
It is sufficient. Users know to run applications in their terminal when there is no error output. Also, you're basically saying that Debian's repos aren't maintained well enough for you here. You're being very silly. Please drop the personal agenda and test AppImages in a sane manner. |
|
Also, you running these tests with firejail is producing some really bad looking screenshots. For example, my twitch-wrapper AppImage is just blank screen because it couldn't load Twitch. |
No. I know users who don't know what a "Terminal" is.
I am not saying anything about Debian. I am just applying what I consider the basics of good user experience.
I am just accurately reflecting what the user sees. |
Then you should probably educate them on what it is because using a terminal is not only extremely helpful for using Linux, it's necessary at times.
No, you're not. A user would not be attempting to run an application that loads Twitch's website without an internet connection. You're giving the impression that my AppImage is broken by taking screenshots like that. I really don't appreciate it, honestly. You are being so silly here that it's hard to comprehend. |
|
I don't know if you realize that what you're asking for here is basically for application creators to rewrite their applications to work in AppImages. Sending an error in console when a GUI application cannot start is perfectly acceptable in any other package format, but not AppImage. You're basically telling any application creator that they have to rewrite that section of their application for it to be acceptable in an AppImage where said behavior is accepted in any other package format. |
|
First of all, AppImage is not a "package" format. It is more like an .app inside a .dmg on the Mac. Second, application authors can do whatever they want with their AppImages, and they will work exactly as the author intended. But in order for them to be listed on AppImageHub they need to pass certain quality standards. |
I do not understand why you don't take up the earlier proposal to test all AppImages in two ways:
and then report both results on AppImageHub? This would help all parties: end-users, application developers, AppImage creators and AppImageHub. |
|
Speaking of "certain quality standards": I voiced it earlier and I still am convinced that the quality standard of AppImageHub itself is not very high:
Update, almost a year later: All my points are still valid. Underneath the recent lipstick put on top of it, there is still the old "pig", even though it meanwhile weighs 665 apps.... |
While I don't disagree with this statement, I think it implies that we need to increase, not lessen, the extent and strictness of the tests.
Yes, we could do that. But then - what would we do with the results? We'd need two "product detail pages", one for users and one for developers (where all the failures etc. would be reported). While we are at it, we could even build in a check that would see whether the application "phones home" (i.e., starts generating any type of traffic without the user specifically triggering an action, hence making every application launch trackable) when launched. We could make a nice "phones home" badge ;-)
True, but that's not a fault of the application but a logical issue. Since we don't want (nor can) track every single versino/release of each application (it would kill us), we don't have direct download links unless upstream a) provides a permalink, or b) hosts the application on a "well known" (to AppImageHub) hosting service that allows us to parse the link to the latest version automatically (currently implemented for GitHub, could be done for Bintray, Mirrorbrain, OBS, etc, too if someone would go ahead). For me personally this is not very high on the agenda, since I download AppImages from the projects' download pages anyway (when I read about a new release in the blogs or on the project website). Getting in the link to the project website is much more important for me personally.
Where could we get this information from? Currently we are using desktop files and AppStream files as the sources of truth. Only restriction: This information should come from somewhere inside the AppImage, so that the application author can control it, and the local system can extract the same information for offline use cases (e.g., app centers showing the descriptions of the applications in the system even when offline).
We take a screenshot of whatever the application shows when launched initially. This is not always ideal, because
Agree that we should have more links to project websites. I think we are showing it if the project is hosted on GitHub (again, because we can easily parse it) or ships it in AppStream.
Since this is a community project, everyone is welcome to help improve it. But personally I don't believe in the "Yahoo" model (hand-build a catalog of manually maintained database entries), but in the "Google" model (automate everything and scrape information from existing sources, and give the original authors full control over the metadata). |
But the results of the tests where AppImages fail certain critera should not go into the current table. Entries which neither give a description of the app, nor a screenshot, nor a download link nor a homepage have no business whatsoever to appear there. They serve no use in order to promote AppImages in general. They only give a bad reputation to the whole project....
That you need two product detail pages isn't a necessary conclusion. You could report it in one table too. But even IF? So what? Then just create the two pages...
Rate it whomwever's fault you want... in any case it's a bad thing to "showcase" on AppImageHub and it reflects likewise on the whole project.
Easy: if upstream does not provide a permalink, then the app simply does not qualify for being listed on AppImageHub. (You can print a simple sentence underneath the table saying:
This sounds like you personally do not need AppImageHub at all. You seem to have created AppImageHub for other people to use. But at the same time you do not care at all for what other people coming across its web page would expect from it, and you neither care if this page shines a bad light on AppImages in general.
I don't care (any more), and you already refused to have it added by MANUALLY inserting it into to-be-created standard forms for submitting PRs)... So if this info isn't easy to be extracted from obvious locations, then JUST DO NOT LIST THE RESPECTIVE APPIMAGE on AppImageHub.
It is. But the project leaders in many cases do not seem to be able to tell in all cases beneficial from un-helpful proposals when outside help/suggestions/feature requests actually do appear. Actual help seems to be rejected and discouraged... I very much appreciate your decade-lasting stamina in following your idea and actually leading the creation of AppImage in its present form. This requires a lot of stubbornness, and in this respect your stubbornness was A GOOD THING. But more recently I observe lots of cases where this stubbornness now only acts as a break for further progress of your project and builds additional walls into its path to be overcome. This is something which already reduced my initial enthusiasm to help, down to less than 10% of its original level, and which made me decide that I'll only "finish" a few ideas I had and I started to work on, hand them over and then turn my back on them. |
|
Thanks for your thoughts @KurtPfeifle. If I read you correctly, you are basically saying it's OK to have less entries in AppImageHub, in other words, to make the criteria for being listed more strict (e.g., requiring permalinks, AppStream metadata, etc). So the contrary of what @simoniz0r is asking, namely to make the tests less strict. And I can definitely see where you are coming from, "class rather than mass". When making your judgment I ask you to consider that I am doing all of this in my spare time which unfortunately is very limited. So I am looking to build solutions that can scale with the minimal manual work needed. And when confronted with ideas for improvement that either create more work for me long-term, or tend to break when an external contributor loses interest, then I am a bit hesitate to enthusiastically embrace them. However, AppImage is architected in such a decentral way (at least that is the intention) that I should never become the bottleneck. If someone wants to build a better AppImageHub, that person can clone this repository and do just that - build a better version.
Perhaps I didn't explain it properly at the time when I rejected those PRs, but I rejected them for the simple reason that given how AppImageHub currently works, those changes would automatically have been overwritten the next time the automated test would have run. So I could just as well have merged them -- the manual edits would have been gone in no time again. You may ask, why did he set up the automated tests in a way that they overwrite files automatically. This has to do with empowering upstream authors. I think it's the right thing to do to enable upstream authors to determine how an application is presented, by embedding the metadata they like inside the AppImages themselves. So conceptually, the improved descriptions and such should go into AppStream metadata files that go to PRs to the upstream applciation projects. Happy to discuss if you think this is a bad idea. @KurtPfeifle I really greatly appreciate your continued support of the project and would be happy to do my part so as to increase your participation again to the 100% level. |
What I'm saying is: it's NOT OK to have any entries in AppImageHub which do not meet certain criteria. My personal criteria would be (all of) the following:
If these criteria cannot be met by automating everything what's no the page, don't automate it or don't publish it. Look for other means to get it onto the page: manual editing, that is: really crowd-sourcing its contents. Because even despite the claim that its content "crowd-sourced" -- from my observations that's not the case: its "auto-sourced", following the one-time submission of a single line of "source code" basically consisting of an URL by a crowd of a dozen or so contributors (where 80% of submissions was done by a single member of that crowd).
Of course I understood this explanation at the time, and I still understand it now. What I do not understand is...
I would understand if you do not have the time to implement it any time soon. But then, you should simply prepared to "sacrifice" all those automatically generated entries which produce bad results. This sacrifice will bring more benefits than it "costs". You could even move the "bad results" list into a separate table, explaining why they are currently there and asking readers to contact upstream with proposals how to improve this...
Of course it is the right thing to aim for.
I doubt that the current system did help with a single upstream AppImage to improve this situation. Even extremely AppImage-"friendly" projects like Krita, Kdenlive, KCalc, Kate, Kdevelop, LibreOfficeDev, LibreOfficePreRelease, LibreOfficeFresh or LibreOfficeStill do not care enough about how their apps look like on AppImageHub in order to bother with the quality of their AppStream metadata and/or screenshots. See also the long tiring discussion on #424 ...
Pah-lease!! Don't be silly! Nobody ever indicated that this is a bad idea. Finally, a #PSA, ICYMI: The good idea currently doesn't work well in real life. |
I think you totally should be tracking version numbers. Not only that, it would be extremely easy to do with either a script to check their github release page/website where the AppImage is linked for new AppImages once or twice a day or just by having the authors submit new versions here when they release them. Not tracking versions leads to so many issues. You end up with pages with no links to an AppImage or even a website, links to AppImages that don't exist, links to broken AppImages, etc. You say the competition can do it because they've got corporate backing, but I really don't see that as being true. All it would take is some time and willingness to cooperate. Almost all of the problems you've listed there would be solved by having some sort of process where you track versions of AppImages. The simplest way to do it would be to have authors submit the link to each new release here. You give them a form to fill out with the required information, that information gets passed along to a test that runs to make sure it's all valid and the AppImage they've provided is in working order, then that information gets uploaded in the same fashion it does now, but without you having to try and hunt it down. This would make the information provided by AppImageHub much more reliable and much more presentable. As is, the missing information on AppImageHub and/or text entries asking for the authors to provide more complete information doesn't make it look like the authors aren't doing their job. It makes it look like AppImage tools are hard to work with, and that the missing information is not easy to provide. I'm a huge fan of how AppImages work from the user end; they're by far the most user friendly universal package format. From a developer point of view, a lot of the things you're doing here don't make a lot of sense. One of the most common complaints I see when someone suggests a project create an AppImage is that the author is concerned that users would not be able to update it easily. Even after being made aware of AppImageUpdate and the like, the alternatives are still much more appealing because they work in a way that is familiar for Linux users. With snaps and flatpaks, you get a simple way to keep them updated with every officially released version. With AppImages, the author has to go out of their way to figure out how to make AppImageUpdate work well enough for them that it isn't annoying to their users. It should be pretty obvious that the tools you are currently providing for keeping AppImages up to date do not appeal to the majority of people who are creating AppImages. A very small percent of them choose to make use of the zsync info at all. I realize you're working on ways to improve AppImageUpdate and the like, but I really don't feel like that is a long term solution that will work out well. I honestly feel like changing AppImageHub to keep track of versions as the competition is doing would be a much better solution. I honestly think you'd find that the open source community would be pretty willing to jump in and help you out with handling submissions and such if you were a bit more willing to follow the standards that they're used to working with. |
|
Instead of printing...
...it would be better to change that to something like...
|
|
Thanks for your comments, will think about them. |
|
The icons part is now implemented. |
[ci skip]
|
Test still fails. I do not know why, but I am relatively confident that it's not an issue with ImageMagick
Possibly the custom Any help appreciated. |
|
I cannot reproduce this error anymore with the AppImage of ImageMagick 7.1.0-62 and The original error references line 25, which is |
No description provided.