AppImage

[baimafeima]

Could you add an AppImage to the releases here on GitHub? This would allow users to offer feedback to your application who are unable to compile from source.

[kynikos]

Thank you for the suggestion, I like the idea, although it looks like it needs quite a bit of studying :) Until I get there, wiki/Development-environment is meant to guide setting up a testing environment: I can help in case of problems, as long as the output errors are pasted in a bug report, along with some info on the system (mainly distro and version).

[probonopd]

Can you provide a script that would make a self-contained venv on Ubuntu 14.04? From there it would be easy to generate an AppImage. Happy to help.

[kynikos]

Thanks @probonopd, why 14.04? I've downloaded the latest Ubuntu image (17.10) and tested a script there, although perhaps it works also on older releases, but a 2014 one could be too old...
Anyway, the script is at https://github.com/kynikos/outspline/blob/AppImage/dev/mkvenv.sh, I'm looking forward to knowing if it works for you and what you can do with it :)

[probonopd]

Applications can be expected to run on newer, but not on older distributions than the build system. Hence we recommend to build for the oldest still-supported LTS release, which currently is Ubuntu 14.04. So you say I can use that script on Ubuntu 14.04 and it will give me a working venv with outspline?

[kynikos]

Wow you're quick! Hmm... the main problem is wxPython: 14.04 has python-wxgtk2.8, while this application is built on 3.0, which apparently appears only since 16.04. If I remember correctly I had to make some changes when wxPython 3.0 was released, therefore I don't think that this application still runs on 2.8. If you have a 14.04 system ready for testing it's only a matter of launching the script and see where it goes, otherwise I'll download a 14.04 image and try it myself in the next days.

[probonopd]

I'll download a 14.04 image and try it myself in the next days

That would be appreciated. Please ping me when you have it working on 14.04, thanks.

[kynikos]

Hey @probonopd, I've tested the script on 14.04 but as I expected the application doesn't work there, and I can't go back to support wxGTK 2.8, it's too old and would require rewriting too much code, at that point I'd rather spend the time to rewrite the interface with more modern techniques...

On Ubuntu 16.04 the application runs normally, except 1) notifications appear in regular floating windows (with decorations) instead of the standard non-decorated self-destroying windows, and 2) the tray icon doesn't work (perhaps because installing in a virtualenv prevents e.g. from installing icons under /usr/share/icons, but I should investigate).

On 17.10 the application runs fine including the notifications, but the tray icon doesn't appear there either at least when run from the virtualenv.

If you're still interested I can try to fix the notifications on Ubuntu 16.04 and better test the tray icon, but if you need the application working also on 14.04, then I can't support AppImage...

P.S. I've renamed the virtualenv script to https://github.com/kynikos/outspline/blob/AppImage/dev/mkvenv_ubuntu.sh

[probonopd]

If you're still interested I can try to fix the notifications on Ubuntu 16.04 and better test the tray icon, but if you need the application working also on 14.04, then I can't support AppImage...

Of course you can decide which target systems you want to support.
Since an AppImage is just a self-mounting filesystem, you can put inside what you like,

But Ubuntu 14.04 is still a supported (by Canonical) version, so I wonder why any developer would develop against anything newer than the oldest still-supported LTS version if they are interested in maximizing usage of their application...

For being added to the AppImageHub central directory of available AppImages, though, it must pass a test on the oldest still-supported LTS release, which at this time is 14.04.

[kynikos]

Of course you can decide which target systems you want to support.

I see, thanks, then I'll look into those problems, I might be able to target 16.04 after all.

I wonder why any developer would develop against anything newer the oldest still-supported LTS version if they are interested in maximizing usage of their application...

This isn't designed to be a commercial application, I originally made it for myself, and I'm using Arch Linux which is rolling-release, i.e. it always has the latest libraries, so I've kept adapting the application to new versions of wxPython as they were released. I'd be happy to share this app with other people if they find it useful, but I don't have the resources to support too many different environments.

[baimafeima]

Thanks for working on an AppImage @kynikos
I use Solus which is also a rolling release and I don't think Ubuntu will be the benchmark any longer, especially as it is not a specifically desktop-focused operating system anyway. I understand that @probonopd needs a common denominator for listing AppImages on a directory though. I find it a better criteria to test that AppImages build on at least three major independent operating systems such as Debian, Solus and Arch and would avoid Ubuntu alltogether :D

[probonopd]

I find it a better criteria to test that AppImages build on at least three major independent operating systems such as Debian, Solus and Arch and would avoid Ubuntu alltogether :D

While you can do as you please for your application, I strongly disagree with that attitude. It leads to "Linux" being perceived as constantly broken, because in order to use the latest applications you constantly need to update the system.

Many users (especially companies, universities etc.) want stable systems that are not changed frequenty. Ideally a base operating system runs for years (Windows XP ran for almost a decade), yet still the latest applications can run on top of it.

This works only if application developers develop for the oldest still-supported system rather than for the newest ones. Applications developed on older systems will run on newer noes, but not the other way around. It's purely a question of mindset.

Debian, Solus and Arch and would avoid Ubuntu alltogether

I avoid Solus and Arch because they are practically unsupportable due to their constant-changing "moving target" nature. If I test on them today, things might be broken already tomorrow. If I test on LTS releases, then at least for a couple of years things should continue to be working. For me, the only systems worthwhile investing time into are those that can be expected to stay around for a couple of years, such as CentOS/Red Hat Enterprise Linux, openSUSE Leap/SUSE Linux Enterprise, and Ubuntu Long Term Stable.

[baimafeima]

I avoid Solus and Arch because they are practically unsupportable due to their constant-changing "moving target" nature.

Except that Solus is more stable than Ubuntu.

It leads to "Linux" being perceived as constantly broken, because in order to use the latest applications you constantly need to update the system. (...) It's purely a question of mindset.

It is indeed a question of mindset. What I consider most when it comes to installing applications is their security. And the security of a system can only be guaranteed when you are actually willing to regularly update. Running Windows XP for a decade is surely prone to be a security nightmare, just as any Linux-based operating system which is not taken care of by a user. A user who doesn't update simply doesn't take security seriously. The idea with Solus is that the operating system actually gets out of your way, you merely have to update with a simple click and are guaranteed stability and safety.

[probonopd]

Except that Solus is more stable than Ubuntu.

Depends on the definition of "stable". With "stable" I do not mean "does not crash" but "can be depended on in that it does not change".

Don't get me wrong - I like Solus. It's great for a certain target group of, say, operating system enthusiasts. But I don't think it's suitable for all scenarios, say, large enterprises or universities, that depend on mission-critical applications to run on a daily basis without (even temporary) interruption. What you need there is an operating system that does not change (besides security fixes) over long periods of time. Still, users may want to use the latest applications on those systems.

And I would never recommend a rolling release system to grandma. For issues like described here. Rolling release systems may work if all you use is the software that is provided within those systems. But as soon as you want to run software from the outside on them, good luck.

[kynikos]

Guys, are we really fighting the distro war even in this remote corner of the web? :)

I'll comment on @probonopd's ideal development strategy instead (to target "the oldest still-supported system rather than for the newest ones"). First, it's not true that "Applications developed on older systems will run on newer noes, but not the other way around", and this very application is a proof: if I didn't update it for wxPython 3.0 it would have stopped working e.g. on Ubuntu 16.04. Yes, I could have implemented some sort of a system to map the old classes and methods to the new library and keep supporting both, or perhaps the wxWidgets guys could have preserved backward compatibility in the first place, but if we always do that where's the incentive for progress? Should have I really waited 4-5-6 years before using the new features that the new library made available? I'm of the idea that if an application stops working because some library gets updated and nobody is there to update the app itself, that app is dead not because it's merely broken, but because it's been abandoned by its developers, and it's very welcome that people stop using it and move on to something more modern.

My ideal development strategy is instead to always develop for the latest stable releases of libraries (and operating systems), and once there's a breaking change a new major version should be released, so that users stuck on obsolete systems can still use the older version of the application. The fact that a new major version is released doesn't necessarily mean that the older version isn't supported anymore; in fact, I do think that until there's a reasonable userbase it should still get security and major bug fixes, but all the efforts on developing new features should only go in the latest major version, based on the latest available technologies. I'm sure that if I tried to use an old enough release of this very application, it would run on Ubuntu 14.04, and in fact if it had been it its repositories, it wouldn't have been upgraded to the no-longer-supported version.

[probonopd]

I'm sure that if I tried to use an old enough release of this very application, it would run on Ubuntu 14.04

Certainly, but this is about running the most recent version of this application.

Not trying to "fight a war", just trying to raise awareness for why it may be a good idea to target the oldest still-supported versions of distributions. But since this topic would lend itself more to an evening-filling discussion (starting from some basic beliefs and principles) rather than a bug report, let's best leave it at this here.