For a “Pain free experience, use a Mac.” Yeah, right. I do use a Mac and some things on there that aren’t part of the core OS are painful. Lets see, some apps (like Chirp for programming radios, and some commercial apps) just aren’t accessible using VoiceOver (the screen reader). Also, unless you are a command line junky, you are going to find that literally any X desktop based app is inaccessible and there is no ORCA port for macports. If you want to use macports, better learn the command line because that is about the only way you are going to have access to apps that might not be directly developed for OS X. Then again, much the same thing can be said about Linux and Windows as well. We, the blind, are unique (even in the computing world) because we have to use other senses to perceive our environment and most people, especially those in program development or IT, can’t (or won’t) understand us and our particular needs. It’s just a fact of life. About the only way to overcome this is to become an expert in the field and get hired for that kind of work. Also, working as a developer on many open source projects will look good on the resume and get most HR people to see past the blindness (mostly). Like it or not, 85% of humanity is still sighted, so we still have to make our own tools that allow us to adapt to the world around us. That or become a united political force (much like the deaf) and force the issue. Btw, I do use macports here and I often use command line utilities to accomplish what a GUI app might not do because of visibility issues within the app interface to VoiceOver. Lately, however, I have run into breakage problems with some of the development apps (like boost). Some libraries don’t get installed by default, and as a result, this breaks the compiles of packages that might depend on boost (for instance). For example: transcode depends on MKVToolnix which depends on the double precision library in boost (which is missing). Other programs (like DVDRip, and some others) depend on transcode. So, a big chunk of the multimedia index for macports is effectively broken and the developers of boost are trying to make the claim that something is off in my install of macports and misconfiguration of the development environment. Yet, I did the default install using the instructions available on the macports site. Basically, that means installing Xcode, then Command line tools for Xcode, then the macports development tree via package. After which, running the port command to self update, upgrade outdated, etc. Then installation of the specific items needed (like boost, boost—jam, Boost-build, PHP, Python, Perl, Ruby, and TCL. So, yeah, “Pain free experience”? Uhh huh! Apple used to be very good at this with their “just works” scheme. However, since Steve Jobs passed on, their quality control has fallen off quite a bit. Now, it’s “Just works, sometimes”. Now, as for the flat pack issue in SLINT, you might need to make sure that all dependencies are completely installed and configured. Also, any secondary dependencies not listed (and I have found quite a few over the years because dev teams often forget these little details). In fact, I have found that the only way to cover all eventualities is to simply install everything in the development environment. Basically, grab all the devel packages and then start building them. This way, you end up with a build environment that is as complete as you can get it and is also optimized for your machine. I did this quite a lot over the years starting with building a new kernel, compiling in the modules for that hardware (this method would bloat the kernel a bit, but would remove the issue of installing or loading new modules with changes in hardware, which doesn’t happen in laptops). Building external modules that can be loaded slims down the kernel a bit and would work best in a desktop tower where hardware can be changed. One nice thing about building apps like this is that you can compile in the libraries. Sure, that bloats the app a bit, but then, you could build and then once you have built all you need, you can remove the libraries and other files in the dev tree and still have fully running apps. That will slim down the system a lot when you don’t need too keep the build environment around. It really all depends on what you want to do. -Eric Leader of the Technomage Guild. > On Jul 24, 2021, at 10:40 AM, Linux for blind general discussion <blinux-list@xxxxxxxxxx> wrote: > > Yep, reading all the documentation was actually a good idea. > > > I got cawbird to work on Slint. Yeah, it's a pain, but what the heck. > > > For a pain-free computing experience, use a Mac. > > > Warm regards, > > Brandt Steenkamp > > Sent using Thunderbird from Slint > > On 7/24/21 4:53 PM, Linux for blind general discussion wrote: >> Hi Brandt, >> >> I never used flatpak or twitter, however... >> >> maybe a post installation configuration is needed, as indicated in: >> https://slackbuilds.org/slackbuilds/14.2/desktop/flatpak/README >> >> If this doesn't help, please post the exact steps you took to install flatpak >> then cawbird and start cawbird. >> >> Then I'll try to reproduces later today. >> >> Cheers, >> >> Didier >> -- >> Didier Spaier >> >> >> Le 24/07/2021 à 16:27, Linux for blind general discussion a écrit : >>> Hi all, >>> >>> >>> I installed flatpak on my Slint installation, for the simple reason, there are no up to date Twitter clients that I can find. >>> >>> >>> I looked at the Slackbuilds, but nothing. Cawbird, my favorite Linux client, for now, is available as a flatpak, but when I try and run it, I get a broken Pipe error. Can anyone help with this issue? >>> >> >> >> _______________________________________________ >> Blinux-list mailing list >> Blinux-list@xxxxxxxxxx >> https://listman.redhat.com/mailman/listinfo/blinux-list > > _______________________________________________ > Blinux-list mailing list > Blinux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/blinux-list _______________________________________________ Blinux-list mailing list Blinux-list@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/blinux-list