profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/scx/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

issue commentBeep6581/RawTherapee

Flatpack version won't allow use of secondary drives

@Thanatomanic

As I said before, I have always tried to give the highest possible permissions to satisfy all users (and since the flatpak sandbox is mostly a lie, I see no reason to apply strong restrictions). Unfortunately, on Flathub it is impossible, not because of some real guidelines, but because they discriminate one software and favor another, as I just proved above. I would like to grant the --filesystem=host permissions to RawTherapee on Flathub, but as you can see, it's not that easy. Darktable is allowed to use such permissions, and RawTherapee it not, just because Flathub/GNOME members said so. I don't know if anything can be done about it. I could describe this topic in more detail (there were even more examples of discrimination), and try to get the media interested in it (e.g. Phoronix), but to be honest, I don't know if it will change anything. And it already took me a few days to write all of it (I started on July 29...). I could suggest providing a snap package, but RT is one of those apps that will be useless without classic confinement, and there are some restrictions about using it. Anyway, manual approval is required. I'm not sure if I have enough patience to dead with it, but at least in theory, it looks like it's worth the time.

chgruver

comment created time in 4 days

issue commentBeep6581/RawTherapee

Flatpack version won't allow use of secondary drives

TL;DR

According to Flathub members, everything is fine. It's not a bug, it's a feature. You should even limit the filesystem access (to --filesystem=xdg-pictures) instead of increasing it (to --filesystem=host). If you do the second one, you may be banned on Flathub. As a solution, you should use flatpak override instead, because it is "easy for users". I don't agree with this, but there is nothing I can do about it. This are the Flathub rules.

chgruver

comment created time in 4 days

issue commentBeep6581/RawTherapee

Flatpack version won't allow use of secondary drives

@Benitoite

paperdigits has some RT flatpak experience to bear.

I don't want to be rude, but last time he wasn't even able to build gtkmm, so he asked for help here. You should know that when my app submission to Flathub was accepted, I didn't get repo access right away, allegedly by an "oversight" (previously my submission was blocked for many months without any reason). Anyway, there was a need to apply my patches, so he tried to do this, but he failed, so I had to fix it by myself later. Then he removed the dconf access, which resulted in the lack of support for HiDPI in many distributions (at that time: at least RHEL 7, RHEL 8, CentOS 7, CentOS 8, openSUSE Leap 15.1, Mageia 6.1, Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Mint 18, Mint 19, elementary OS 5 - and even now EL7 is still affected, although it is still officially supported by flatpak). I told him not to do it several times, but he ignored it. Since then, he hasn't had any interest in this flatpak package at all. In the end, in my opinion he has very limited knowledge of flatpak and RawTherapee itself. I am not saying that you shouldn't use his help, but you should keep a careful eye on him and very carefully watch what he is trying to do.

chgruver

comment created time in 4 days

issue commentBeep6581/RawTherapee

Flatpack version won't allow use of secondary drives

@Benitoite

Filesystem Access should be set to host to access /mnt

According to Flathub members, it should be limited even more (to --filesystem=xdg-pictures). Technically, I could add the --filesystem=host permissions, but I won't do it, because it would be revoked very soon. You can try it on your own responsibility, but I don't know if you will experience any repercussions for this (according to Flathub maintainers, you can lost "push access to your repositories" on Flathub). If you're lucky, no one will notice. This was the case with RedNotebook. I was forbidden to give the removable devices access on Flathub, and then two years later, the author gave them by himself. BTW, there should be no need to ask me about this. According to the Flathub members, it is the software vendors that should deliver their applications to the Flathub store: "Flathub is primarily intended as a service that is used by app developers to distribute their apps". You should have full access to the RawTherapee repository on Flathub. Why don't you have? Because you've criticized flatpak and promoted a technology that competes against GNOME's flatpak in the past. This is how Flathub works. Not everyone is welcomed.

As an user, you can manually override package permissions with the flatpak override command. When it comes to the GUI, there is a problem. While snap can provide Snap Store, flatpak can't provide GNOME Software. GNOME Software was supposed to be just a front-end for PackageKit. However, they screwed up. PackageKit is dead, officially. Still, they blame Canonical for that Snap Store can only handle snaps. Since it uses strict confinement, it can't support anything else (even native package, like RPMs or DEBs, so it's not like it discriminates only flatpaks), because there is no such API in the Linux world. If you want to blame someone for this, you should blame Richard Hughes, who is a Flathub/GNOME member, sponsored by Red Hat. He was responsible for PackageKit. Anyway, if you're lucky enough, GNOME Software will let you manage some flatpak permissions, at least in a limited way. On my systems (RHEL 7, CentOS 7), it just crashed (Segmentation fault (core dumped)) and GNOME Control Center is completely broken under MATE. If I good remember, in the past it was possible to grant and remove Home Access, which by the way actually could break some applications, because not every software uses XDG user directories, and flatpak cannot really blacklist the ~/.* files and directories. BTW, contrary to what Flathub members say, XDG_CONFIG_HOME is not "the new Linux standard". For example, snap uses SNAP_USER_DATA instead. Just because GNOME devs have integrated support for XDG user directories into GLib, doesn't make this "the new Linux standard".

chgruver

comment created time in 4 days

issue commentBeep6581/RawTherapee

Flatpack version won't allow use of secondary drives

@chgruver @Benitoite @Beep6581

Flatpack version won't allow use of secondary drives

Well, according to the Flathub members, it's not a bug, it's a feature. I always try to give the --filesystem=host permissions, because users expect it. Unfortunately, Flathub members have a different opinion on this matter. They always want to limit application permissions as much as possible, at least officially. Anyway, I got at least several dozen requests (both on GitHub and IRC channel) to remove the --filesystem=host permissions from my packages. This was also the case with RawTherapee. As you can see, my standalone package has full permissions, but I was forbidden to give the same permissions on Flathub. I know that at least some of you are familiar with the flatkill website. It is true that most popular software on Flathub have the highest possible access to the filesystem. I tried to confront Flathub members why new applications cannot have such permissions. The answer was as follows: "rules are fluid and just because something has been accepted before doesn't mean it would be now". Moreover, for already existing packages, "patches are welcomed". It was in 2018. Even today, GIMP, LibreOffice, VLC, etc. still have the highest permissions. Moreover, new submissions are still accepted with highest privileges. For example, Gimpsle was accepted with the --filesystem=host access, although yet in 2018 they said that even GIMP should have lower permissions. I will tell you one thing: these rules are bullshit. They are not there to provide exemplary quality, but to discriminate one software against another. It doesn't matter if the software is full-value or half-working (generally speaking, almost every IDE on Flathub is broken, including Visual Studio Code, Code::Blocks, JetBrains IDEs, etc.), polished or bugged, stable or unstable, safe or with security holes (we already have packages that have literally over 100 known security vulnerabilities (already marked with CVE) and no one has done anything about it for years). The only thing that matters is who creates the application and who is the maintainer of the package. If you are a GNOME member, you can do anything, break all the rules. If you have ever criticized GNOME or Flatpak in public, you will be discriminated. This is software fascism. The hierarchy goes something like this:

  • GNOME developers
  • software companies (as vendors, because companies are not interested in maintaining packages on Flathub - they often chose Snapcraft instead)
  • KDE developers
  • independent developers
  • RH/GNOME/Flathub-skeptics

I will give you a few examples:

Permissions

As of Jan 1, 2020, at least these applications have the --filesystem=host access:

  • adriconf (Advanced DRI Configurator)
  • Almond
  • Android Studio
  • appstream-glib - Freedesktop
  • Atom
  • Audacity
  • Avidemux
  • AVI MetaEdit
  • Beaker
  • Betaflight Configurator
  • Bijiben - GNOME
  • Blender
  • BlueJ
  • Brackets
  • Builder - GNOME
  • Bustle - Freedesktop
  • BWF MetaEdit
  • Byte
  • calibre
  • ClamTk
  • CloudCompare
  • Corebird
  • Cozy
  • CRUSH
  • Darktable
  • Déjà Dup Backups - GNOME
  • Detwinner
  • Drawpile
  • DV Analyzer
  • Eclipse
  • Emacs
  • Engauge Digitizer
  • Eye of GNOME - GNOME
  • Evince - GNOME
  • Fedora Media Writer
  • FFaudioConverter
  • FileZilla
  • Flowblade
  • FontForge
  • fre:ac
  • FreeCAD
  • FreeFileSync
  • Geany
  • gedit - GNOME
  • Handbrake
  • GHex (GNOME Hex Editor) - GNOME
  • GIMP - GNOME
  • gitg - GNOME
  • GitKraken
  • Glade - GNOME
  • Glimpse
  • Gnomit
  • Godot
  • gScope
  • GSequencer
  • GStreamer Debug Viewer - Freedesktop
  • Howl
  • Hydrogen
  • Indicator-KDEConnect
  • Inkscape - GNOME
  • IntelliJ IDEA Community
  • IntelliJ IDEA Ultimate
  • Karapulse
  • Kdenlive
  • KeePassXC
  • KolourPaint
  • Krita
  • LibreOffice
  • Lifeograph
  • Liri Text
  • Lollypop - GNOME
  • Manga Reader
  • Mark Text
  • MediaConch
  • Meld - GNOME
  • Melody
  • mGBA
  • MKVToolNix
  • Movie Monad
  • MOV MetaEdit
  • MusE
  • MuseScore
  • Natron
  • Neovim
  • *NetBeans
  • Nextcloud Desktop
  • Notepadqq
  • nsm (nifty site manager)
  • OBS Studio
  • Octave
  • Okular
  • Olive
  • OpenMW
  • OpenShot
  • OpenToonz
  • OSM Scout Server
  • PDF Slicer
  • Pencil2D
  • PhotoQt Image Viewer
  • Pitivi - GNOME
  • Purr Data
  • PyCharm Community
  • PyCharm Professional
  • Pyzo
  • qBittorrent
  • QCTools
  • QGIS Desktop
  • QuickAccess
  • Quod Libet
  • RDPlot
  • RetroArch
  • Roger Router
  • Scan Tailor
  • ScanTailor Advanced
  • Scribus
  • Setzer
  • Shotcut
  • Skrooge
  • SmartGit
  • SmartSynchronize
  • Splash
  • Sublime Merge
  • Sublime Text
  • Syncthing GTK
  • Synfig Studio
  • TeXstudio
  • Textosaurus
  • TeXworks
  • Tiled
  • Timetable
  • Toggl Track
  • Transmission
  • TrenchBroom
  • TuxGuitar
  • UberWriter
  • Unity Hub
  • VidCutter
  • Vim
  • Visual Studio Code
  • VLC
  • Vorta
  • WebStorm
  • Xournal
  • YUView

We have similar amount of applications with the --filesystem=home access.

From a security perspective, there is not much difference between the --filesystem=host and --filesystem=home. They both allow you to escape from the sandbox. So, for example, if you have an application without direct access to any devices and without network access, but with at least --filesystem=home, you can still use a camera, take a picture of the user and send it over the Internet. By the way, Snap doesn't have this problem at all (see: snap's home, as well as personal-files, removable-media, etc.), but you can't say something was better done by Canonical, because that would be "hate". Oh, and we have the same security problem with the --talk-name=org.freedesktop.Flatpak permission. In Snap, this problem was partially resolved by the slots. However, it is not suitable for every application. This is why Canonical provided the classic confinement. Unfortunately, the snapd packages for Fedora are intentionally broken to prevent such applications from running. It is easy fixable in classic Fedora (all you have to do is create a symlink... with root permissions), but not in Silverblue.

Anyway, the flatpak sandbox is mostly a lie. Let's say you want to provide the fully sandboxed game. You give it standard permissions, but without filesystem access, apart from its own directory. Then you provide access to the Internet and joystick. You think it is pretty safe, but it is not, because it can actually access your secret data and sent it over the Internet. It is because the whole permission system is broken. If you want to add access to the joystick, you must also give access to the camera... as well as the whole /dev/. If you want to add access to the scanners, you have to provide access to the Internet! Makes sense? In the end, in typical scenario, flatpak doesn't protect you from anything. There is no such problem in Android, but on the desktop, a lot of portals are missing. Let's talk about scanning.

  • To access raw devices, there should be portal for USB, as well as for COM, LPT and possibly other interfaces. It would be good for apps like VueScan (but not necessarily for VueScan itself - just for similar apps).
  • There also should be a portal for raw SANE access, for applications such as XSane, Skanlite or Simple Scan.
  • Because SANE is some kind of low level API, there should be also some kind of a higher level API, to make application development easier. For example, if you want to force a color scan, you need to know all the names of the color modes, e.g. Color, Color24, Color48, etc. It's not documented anywhere, and each driver (sane backend) can make their own modes.
  • Sometimes you don't want to implement the entire GUI for scanning. You just want some API that will return a scanned image or series of images to you. It would handle all technical aspects (batch scanning, rotating/cropping images, brightness/contrast manipulation, etc.) by itself. Actually, I proposed something like this between 2019 and 2020. This would be useful for OpenOffice, LibreOffice, GIMP, Glimpse, KolourPaint, etc. Currently, most of these applications use XSane. However, it doesn't work at all under flatpak.

Currently, to access the scanner under flatpak you need to build libusb, then sane, then its backends. Each of them requires a lot of patches, which makes it almost unmaintainable. And you still have to add various permissions, including some DBus access (e.g. --system-talk-name=org.freedesktop.Avahi) and Internet access (yes, there is no way to limit network access to the local network). And it still won't work in all cases, because there is no way to provide udev rules. Even if it were possible, each distro has its own udev rules, e.g. because they use different groups. For example, lp (because of All-in-One devices), saned, scanner, etc. We have similar problems with the joysticks/gamepads, recent files, etc. Flatpak doesn't provide half of the APIs needed for full-fledged applications, but Flathub members still blame developers for half-working software. For example, according to the Flathub members, to access files, you should use the file chooser portal (BTW: it is only available for Gtk+3 and Qt5 apps, but according to the Flathub members, it is just an API, so you could implement it e.g. in Gtk+2, and then provide and push updates for Ubuntu, Fedora, Endless OS, Chrome OS, Red Hat Enterprise Linux, Linux Mint, openSUSE, Arch, Debian, CentOS, Gentoo, Kubuntu, Solus, Alpine, Megeia, Pop! OS, elementary OS, Raspberry Pi OS, Clear Linux, Void Linux, NixOS, PureOS, SulinOS, Ataraxia Linux, Zorin OS, Deepin, Pardus and Pisi GNU/Linux - it is so simple!). However, it just gives you access to a single file. This works in very few cases. Most of the time it will be useless:

  • Every software that uses concept of projects, solutions or workspaces (e.g. IDE, non-linear video editor, etc.) needs normal file access.
  • The same applies to the HTML viewers, Markdown editors, Spreadsheets, etc.
  • Music players often uses playlists, so they also need normal file access.
  • Movie players often want to load subtitles.
  • Every file manager or media browser need normal file access.
  • The same applies to the download managers.
  • Even simple file converter usually needs normal file access. But according to the Flathub members, software developers are just "lazy", because they don't want to use Portals...

Anyway, as of Jan 2020, GIMP can have the highest filesystem access, and Pinta must be limited to the standard folders (Documents, Pictures, etc). Lollypop and VCL may have the --filesystem=host permission, independent music player can't. Darktable is allowed to use such permissions, RawTherapee it not. Why? Because Flathub/GNOME members say so. To be honest, it is even more ridiculous than you can imagine. For example, GPick is supposed to read and save the color pallets. According to the GNOME/Flathub developers, such files are just like JPEG images, so they should be saved in the Pictures folder: "I'd prefer to see it limited to xdg-pictures. It's easy for users to change it themselves." (so the app wouldn't even have access to the Documents!). Personally, I don't know any graphic designer who does that. The --filesystem=host permission on Flathub is officially banned at least since 2018, but Glimpse was accepted with the highest filesystem permission year later without any problem! However, we can access GIMP from Rawtherapee, but it doesn't work for Glimpse (try to use a custom editor in RawTherapee: flatpak-spawn --host flatpak run "org.glimpse_editor.Glimpse" - technically, it would be possible - it is a permission problem). Why? Because GIMP is GNOME software, and Glimpse is not - it is just a fork.

What are the advantages of using a --filesystem=host over --filesystem=home?

  • You can access removable media (e.g. CD-ROMs, pendrives, disks, etc.).
  • You can access shared directories under /srv (e.g. files shared over network - often used in corporations).
  • You can read-only access shared directories under /usr/share via /var/run/host/usr/share (e.g. Stock Photos, Backgrounds, Brushes, Clip Arts, Samples, Document templates, etc. - often used in graphics studios).
  • You can read-only access configuration files under /etc via /var/run/host/etc (e.g. /etc/*-release - often used by system tools).
  • You can access custom directories, like /data.

If you only care about removable media, the --filesystem=/run/media permissions may be enough.

Additional, users often expect access to GVfs (--filesystem=xdg-run/gvfs:ro, --talk-name=org.gtk.vfs, --talk-name=org.gtk.vfs.*), e.g. for Android files (MTP).

In a normal store, the developer/maintainer decides about the default permissions. But as you can see, Flathub is not a normal store. It never was.

AppData

For a long time (since Dec 2018), every application on Flathub has to provide an OARS rating. While it might make sense for games and gambling apps, it doesn't make sense elsewhere. For example, every package manager/software store client must report all application features that are available there. So, according to the AppData, the Steam client is mostly about "prostitution" and "slavery". Did I say that every Store app must follow these rules? Well, there is one exception - GNOME Software. It doesn't have to report anything like that! However, since the flatpak package of Steam client is maintained by the Freedesktop runtime (basically, Flathub runtime) member, it can lie about telemetry. So, again, according to the AppData, there is no telemetry at all! No update checking! No Steam Hardware & Software Survey! No crash dumps. Nothing at all! However, if you are an independent developer, you must report the mild level of telemetry only if you have optional update checker, and moderate level if your app may collect statistical data, even if it is disabled by default. Still not enough? Ok, listen this. The flatpak package of GIMP claims that it provides the gimp binary. The AppData specification makes it clear - it must be "installed into a location in PATH". However, flatpak doesn't export any binaries to the host. Snap has this capability, and what's more, it can export multiple binaries from a single package. This feature is often used by developers/maintainers. Yet another advantage of snap over flatpak. But lack of this feature in flatpak is one thing (they are "working" on it since 2018), and lying in the AppDate file is another thing. I proposed to automatically remove such entries from AppData files by flatpak-builder. We already have a similar fix for TryExec in desktop files. However, my request was ignored as "unnecessary". Last but not least: GIMP claims that it uses a modern toolkit. What is modern toolkit? According to GNOME (kudos is a GNOME thing - AppData extension used by GNOME Software to promote modern software, and it acts as a kind of "awesomeness score"), ModernToolkit is "like Gtk-3 or QT-5". But we already know that GIMP 2.x uses Gtk+2. Is it modern? Unfortunately, not. It doesn't support Portal APIs (e.g. native file chooser dialog), Wayland, HiDPI, transparency, etc. It doesn't even have currently supported web control. There was WebKitGTK, but it was banned in Fedora several years ago (in Fedora 27, released in 2017), because of "roughly 150 unfixed security vulnerabilities". However, this absolutely doesn't prevent anyone from using this component on Flathub. Actually, GIMP still uses it in 2021. Should I mention that webkitgtk 2.4.11 was released in 2016, and has not received any security patches since then? Anyway, what is the penalty for lying in kudos? According to GNOME, "any application that is found cheating, i.e. adding kudos artificially will have all the kudos manually removed with a blocklist rule in the AppStream builder". But when it comes to GIMP, of course it won't happen, because it's still GNOME Software, even if it sticks to Gtk+2 and doesn't meet the GNOME3 HIG criteria at all.

README

Providing the README is banned on Flathub at least since 2018. Of course, many apps still do this. As of Jan 2020, it is over 100 packages, including Adobe Flash Player, some GNOME software (e.g. Contacts, Déjà Dup Backups, D-Feet. Font Viewer), HandBrake, JetBrains IDEs, Lutris, NetBeans, OBS Studio, Remmina, RetroArch, Skype, Slack, Steam, Thunderbird, VueScan, WPS Office. Some of these files are completely pointless. However, even if they are desirable, they should be removed: "No user is going to find this README to read your FAQ. If you consider any of this critical, put it in appdata." So, why not put this in your AppData file? Because it is too limited to handle complex FAQ. The appstream-glib puts various restrictions on line length, header length, number of paragraphs, number of characters, etc. These rules change even several times a year. Nobody has time to edit it all the time. If the AppData file fails validation, the entire build is rejected. Theoretically, you can validate it before submitting commit (however, don't assume that Flathub has provides the latest version like it should, because it isn't always the case), but we often use some preprocessor to generate full AppData file, so it isn't available at pre-build time. Is isn't also upstreamable, because we are talking about flatpak-specific issues. Besides, it would require manually generating patches with each update, which make it almost unmaintainable. And as I said, the AppData summary has a length limit. So, why not put a link in the AppData file? Because you can't. Not only it won't be formatted as link, but the entire file will also fail validation. All links, even provided as plain text, are explicitly prohibited.

Manifest layout

According to the Flathub members, you should put your manifest in the single file, and all additional files (e.g. patches) should be placed in the main directory. In my opinion, it is the maintainer who should decide what is more convenient for him, not the reviewer who will never add a single commit after the review is done. This is obvious on Snapcraft, but not on Flathub. However, even here we have a lot of examples of breaking this rule:

According to the Flathub maintainers, splitting manifest over files is type of "code obfuscation". BTW, since Freedesktop 18.08, they put each module in separate file. The same is true for GNOME 3.30 and later. Anyway, why do this at all? Because it is easier to maintain such code. For example, if you have a lot of pure Python modules (without native deps), you can relatively easily (well, it is not always that easy) generate manifest for each of them (e.g. by flatpak-pip-generator, flatpak-pip-generator + flatpak-json2yaml, or similar tool). In the end, you can automate it with a simple script. However, if you absolutely want to use just single file, you will have to manually copy-paste everything each time. It is really waste of time, and often leads to mistakes. Actually, I've created tools to update components (general-type, not only for python modules), beautify the code, add the necessary tags and validation (e.g. suggest to replace buildsystem: cmake with buildsystem: cmake-ninja, add builddir: true and config-opts: [DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo] to both of them, update config.{sub,guess} and perform autoreconf for buildsystem: autotools, add --disable-static, --enable-maintainer-mode and maybe even --disable-manpages to config-opts: when possible, replace "http:" with "https:" in url: when possible, etc.), etc. They actually work pretty well, but only for single-module manifests (it means that each module must be placed in a separate file). Moreover, when you have single-module manifest, you can easily compare them between various projects. So, for example, wxWidgets/wxGTK is typically built with project specific options (some applications work better with wxWidgets 3.0, others with 3.1, some programs work better with Gtk+2, others with Gtk+3, some need web control, others don't, each wxWidgets variant may require different patches, etc.) , but it's still nice to be able to compare manifests side by side. What's more, in this way it's easier to manage dependencies, because you can see what belongs to what, which is important when updating the program, runtime or shared-modules, and there is a need to remove unnecessary components.

Helper scripts

Most people will agree that it is easier to run ./build.sh than e.g. git submodule init; git submodule update; flatpak-builder "build" "io.github.wxmaxima_developers.wxMaxima.yaml" --force-clean --install-deps-from="flathub" or similar command. This is especially important when you are working with the vendor who is not very familiar with flatpak. Of course, this is not limited to the build script. For example, it's much easier to update python modules with a simple script than doing it manually. It is obvious to everyone, except to Flathub members. Such helper scripts are explicitly forbidden. And because it is strictly forbidden practice at least since 2018, a lot of projects can still use it, e.g.:

Upstream needs to be involved

According to Flathub members, "upstream needs to be involved". We can safety assume that every package that use extra-data is maintained beyond the knowledge and consent of the upstream vendor. As of Jan 1, 2020, it includes Android Studio, Dropbox Client, GitKraken, JetBrain IDEs, Minecraft, Skype, Slacks, Spotify, Sublime Merge, Sublime Text, Teams, TeamSpeak, UnityHub, Viber, Visual Studio Code, VueScan, WPS Office, Zoom and dozens of other packages. All of them should be removed from Flathub immediately.

On the other hand, Flathub members like to make false claims that the vendor is not involved when he (or she) really is. It was the case with Qalculate. My application submission was blocked for no reason. Outside Flathub, I have already worked with Hanna Knutsson (the upstream vendor) on the flatpak package. She forked my repo, has provided some pull requests, and even started to ship self-contained packages with her GitHub releases. It was Jan 20, 2020. I asked Flathub members one more time about my applications submissions, showing them that TUV is really involved and waiting for merging this repo. Flathub members reserve the right to decline any package as they wish, as you can always host your own flatpack repo. However, they get furious every time when a popular app does this. This was the case with Qalculate. Just 4 days later, they finally put a review... with fake issues. They stated that vendor is not involved or the app is no longer developed (remember, just 4 days earlier the new release has been shipped with a standalone flatpak package, and they knew about it). They also claim that there are pointless README, license files, shell scripts and too wide permissions (e.g. --filesystem=home). It was a lie. There was no shell script, README, license files, and the filesystem access was actually limited to --filesystem=xdg-documents, --filesystem=xdg-desktop and --filesystem=xdg-public-share. What is more, at the same day, they put the same review with fake issues in almost my every app submission, for example:

So, for example, the author of Imagine is waiting for accepting his application at least since 2019. Flathub maintainers know about it (I reminded them about it several times on the official IRC channel), but still claim that there is "no upstream participation". We have exactly the same case with mtPaint. Yet in 2018, the author stated that he is "quite interested", but according to the Flathub maintainers, he is not. Another example: gImageReader. When it comes to NaSC, I even provided quite a lot of pull requests to gain some so-called "bonus points": changing the Application ID, using XDG user directories, improving the AppData file, porting to Meson, etc. My patches were mostly accepted, but Flathub maintainers still claims that there is "no upstream participation". I could give you even more examples, but this is not the place for that. At first, I wanted to reply, but then I asked myself: how should I respond to fake issues? They weren't made by a mistake. It was clearly intentional. When they stared removing my comments, I just gave up. It was the case with XSane. As I stated before, to gain scanner access in flatpak, you have to build libusb, then sane, then additional sane-backends, e.g. hpaio (a scanner portal has been already proposed, but there has been no progress since 2017). When it comes to hpaio, it is really buggy and requires a lot of patches just for flatpak. What is worse, there is no way to make them upstream (vendor does not accept PRs/MRs). Anyway, since version 3.19.1 (released in Jan 2019), at least dozens of drivers are broken. HP knows about it, but they just didn't care about old device models. Several distributions decided to prepare their own patches to restore support for these devices. I took the patch from Fedora and extended it to all affected models, then limited it to only those devices that actually can scan. I did all of this for OCRFeeder, after several people reported problems on GitHub, GitLab, and a few others via emails. But of course, these issues are not related to OCRFeeder itself, but to HPAIO. So when I was submitting XSane for Flathub (to improve scanning support in Flatpak packages), I just linked these issues, to make it clear, why such patches are needed. What did the members of Flathub do? They removed comments ("flathub deleted a comment from scx on Jan 26, 2020") with these links (please note that there is still an evidence about it: "mentioned this pull request on Jan 26"), and then in the review they stated: "I doubt these patches are relevant to flatpaked xsane" and: "Please say upfront if you're going to address issues in your submission so we don't waste time arguing". Of course, all these patches were already approved in OCRFeeder, and no one said a bad word about them. But OCRFeeder is GNOME software, and XSane is not. Anyway, it was another level of trolling that I couldn't handle anymore. I gave them an ultimatum: Either they stop their software fascist practices or I won't longer provide even a single commit for any Flathub package, including these ones that have already been accepted. There was no reply for this. Since then, some of my packages have been already broken, intentionally or not. It is clear to me that I am not welcome there, and that whatever I do, it won't be accepted. This is revenge for that I publicly criticized Flatpak and Flathub in 2018-2020.


Flathub maintainers claim that they "want to be seen as source of good practices", but in the end, most packages don't meet Flathub's rules. And if you also take runtimes into account, then there is no even one application that would meet these rules. Even besides these so-called "issues", a lot of packages are half-working software, often buggy and unstable, and what is worse, with tons of security holes. Each Freedesktop runtime version brings more bugs and issues than Debian, Ubuntu or even Fedora. For example, in Freedesktop 1.6 there was a critical bug in glibc (we hit this bug in PyQt apps, e.g. ReText) and SDL2 (we ran into this in Widelands). In GNOME 3.30 the help system was broken (Gtk+ apps were affected, including OCRFeeder). In KDE 5.11, Qt was completely broken on EL7. In Freedesktop 19.08, Mesa was broken on some configurations (Widelands on EL7 was affected by it). In the same runtime, pciutils was broken. While this was fixed relatively quickly in the Freedesktop runtime, we had to wait a few months to backport this fix to the GNOME runtime.

There are a lot of flatpak-specific issues when it comes to:

  • development tools (almost every IDE is broken, dev tools don't work as they should)
  • administrative tools (similar to above)
  • compatibility (package doesn't work on specific distribution or range of distributions, because they are too old, too new or just too hipster)
  • nested sandoxing (it doesn't work, at least on EL7)
  • single instance (you have to implement it via DBus, otherwise it won't work)
  • themes (only Gtk+3 and Qt5 apps have proper theme support, and yet dynamic theme changing doesn't work under KDE, at least on EL7)
  • fonts (they are broken if the host uses symlinks to targets outside of standard locations, e.g. /usr/share/fonts/wine-tahoma-fonts/tahoma.ttf -> ../../wine/fonts/tahoma.ttf)
  • locales (similar to above - spell checking components couldn't handle broken links)
  • CJK (it is broken)
  • PackageKit (apps are unable to install extensions by themselves)
  • printing (basically, the printing support was broken until 2020, and it is still issue on EL7, at least when it comes to non-Gtk+ apps; printing preview still doesn't work in 2021)
  • scanning (most of apps doesn't support scanning, because there is no scanning portal)
  • GPGPU (CUDA and OpenCL are often broken, because Flathub runtimes use the bleeding-edge components, including latest GCC (instead of following NVIDIA's guidelines), and because they try to provide the same graphics driver for each distribution, from oldstable LTSes to rolling release distros)
  • 3D (3D accelerations are often broken, some drivers aren't supported at all (e.g. zhaoxin-linux-graphics-driver-dri - they pretend it doesn't exist), others have some issues from time to time)
  • video decoding (flatpaks are unable to load necessary kernel modules by themselves, which often results in the lack of support for e.g. NVENC)
  • audio (JACK wasn't supported at all until 2020, and it is still not supported on EL7)
  • services (flatpak packages can't provide or even manage services)
  • udev (flatpak packages are unable to deliver dbus rules, e.g. for Steam Controller or scanners)
  • kernel modules (unlike native packages, flatpaks can't provide kernel modules, e.g. xpad for game controller, vbox* for VirtualBox, or ashmem and binder for Android emulation)
  • host integration (flatpaks are unable to export binaries, manuals, bash completions, etc. on the host)
  • desktop integration (trash support, applets support, file manager extensions, shell integration, etc.)
  • portals (they are often buggy/broken (sometimes by design) and incomplete, or too old for Flathub apps)
  • runtime quality (updates may completely broke some apps on selected distributions, because Flathub members don't really care about proper validation and testing; what's is worse, there is no way to provide different version of application for e.g. LTS distros that can't handle some new features/components)
  • updates (flatpak update will fail if there is at least one non-compatible package (e.g. that requires newer version of flatpak) on top of the update queue, and updating the flatpak itself often leads to strange issues with OSTree)

What is worse, Red Hat/GNOME/Flathub members keep suggesting you to solve problems in the most ridiculous ways:

  • Flatpak cannot handle the "Open with..." menu? Just remove it.
  • Flatpak cannot handle fonts that are symlinks to targets outside of standard locations? You can just install all officially supported distributions, check which fonts are affected, and then report an issue on each distro's bugzilla.
  • It happens that common runtimes like KDE suddenly make all Qt5 apps no longer works on enterprise distros. What should the application maintainer do? Manually check if the Qt provided by the runtime is compatible with the host, and if not, display the appropriate message using Gtk+3 ("It's really the job of app to verify what is available and exit gracefully if required component is missing." - in this case, these required components were kernel symbols; "doing checks in the sandbox and failing cleanly with a UI is the best approach").
  • It happens that Mesa is broken on LTS distros. What should the gamedev do? Manually check if the driver provided by the runtime is compatible with the host (kernel, DRI, DDX, X.Org Server, etc.), and if not, display the appropriate message using Gtk+3 ("Flatpak uses X server from host so eventual bug in xorg isn't flatpak issue to resolve." - but isn't it the flatpak issue that it provides a GPU driver incompatible with the host?).

The desktop environment is super complex. Is is not a server with a docker, where all you need is access to files, network and a few other things. No, it's much more. Flathub/GNOME members would like to develop it at a low cost, but it doesn't work that way. Unfortunately, it seems they just couldn't handle this properly. Flatpak was supposed to solve Linux problem. However, it isn't a magic cure for Linux itches. In the end, it is introducing more problems than it is solving.

Maintaining flatpak applications is really pain in the ass, not only because of above issues, but also because you need to build tons of components (and their dependencies) from scratch. This includes: Avahi, Boost, codecs, doxygen, fonts (in bundled fonts we have colored emoticons, but not math symbols or CJK chars), freeglut, Haskell modules, hpaio, ghostscript, GNU Plot, GraphicsMagick, graphviz, Gtkmm, gtk-sharp, GtkSharp, ImageMagick, libusb, Lisp (e.g. CLISP, ECL, GCL, SBCL), netpbm, net-snmp, nodejs, OpenAL, OpenCL, Perl modules, Python modules, Ruby modules, sane, wxWidgets/wxGTK and literally hundreds of other components. A lot of them require extensive patching, which is usually the responsibility of the distribution maintainers (unfortunately, for many Linux components the upstream is already dead, so they are maintained by Canonical/Debian/Red Hat/SUSE employees/maintainers). Here, you have to keep maintaining everything that isn't included in the minimalist runtime (which is not minimal when it comes to size, but just focused on GNOME stuff) by yourself. This is why packages are often extremely outdated and insecure (especially when it comes to FFmpeg, Ghostscript, OpenJPEG, Python modules, WebKit, etc.). BTW, in Snap, you can just re-use existing DEB packages. This approach has another advantage - the developer can be informed about component updates, especially in the case of security patches. Moreover, Flathub SDKs (Freedesktop, GNOME, KDE) lack of standard build tools, such us ImageMagick/GraphicsMagick (to resize icons - there is only rsvg-convert, but for obvious reasons, it cannot handle raster icons), dos2unix (to convert line endings in plain text files), XMLStarlet (to modify XML files, e.g. the AppData file), jq (to handle JSON files), etc. You have to build all of them by yourself! In Freedesktop 19.09, even intltool was removed, although it was recommend tool to handle translations of e.g. AppData files!

There is still no clear information on which runtimes are fully supported and by when. It is especially confusing with GNOME. Maintenance is abandoned almost immediately after a new version is released. Occasionally there are some patches, but it isn't known whether they are intended to fix all security bugs or just selected ones. Anyway, the first one wasn't always the case. Finally, after a maximum of two years (when the base runtime becomes EOL, which is Freedesktop), they are marked with EOL as well, but in fact the status is unknown for about 0.5-1.5 years. Freedesktop runtimes should be supported for 2 years, but that's not entirely true. First of all, even fully supported runtimes may provide insecure components for months. It was the case with GNOME 3.36 - for long time, it had FFmpeg 4.2.1 with no security patches backported (CVE-2020-12284). But there is much bigger problem. You see, if your application uses some libraries available in flatpak shared modules, you must use those modules. Otherwise you would break Flathub rules (which is extremely stupid: for example, Qt4 is provided without SVG support - why? is there any security hole in it? no, it's just because Qt4-based apps don't deserve to open SVG files!). And since there are GLU, GLEW, Gtk+2, libappindicator, libsecret, libusb, Lua Python2, Qt4, etc., shared modules are used very often. Unfortunately, these modules are often only compatible with the latest runtime. So, for example, GIMP had to revert shared-modules to older version, because Gtk+2 was broken in GNOME 3.32. And because of this, for several months they couldn't apply security patches for Python2 (sorry, you couldn't use multiple versions of shared-modules in single project, because your manifest must be "clean"). You can say it was an incident. Unfortunately, this is more a rule than an exception: "This change will intentinally break manifests of apps that used udev from shared-modules. The assumption is that app using freedesktop 18.08 runtime won't need updating shared-modules and if they do then it's always recommended to switch to 19.08". Unfortunately, often you can't just switch to a new runtime, due to incompatibility with new GCC toolchain, some libraries (e.g. ICU), GNOME stacks, etc. Of course, it may be doable, but usually takes some time. There is one more reason - new runtime runs are often heavily bugged, and corrections can take long months, sometimes even over half a year (e.g. pciutils in GNOME 3.34, if I good remember) - if they are introduced at all, which does not always happen (e.g. glibc bug in Freedesktop 1.6). There is one more thing about shared modules worth to mention - Flathub members treat this like their own working directory. As I said before, intltool is a kind of Linux standard, and it was removed in Freedesktop 19.08. Of course, this move had negative consequences. Since a lot of Linux components actually require intltool and flatpak-builder at the time did not allow the same module to be built multiple times (this was changed later at my request), many shared modules had problems with building. They kept [adding(https://archive.is/G0JQs)] and removing references to intltool from manifests, thereby repairing the packages they needed at the moment and breaking others. Of course, the other package maintainers on Flathub didn't have such privileges, so they had to wait weeks or maybe even months for the module they needed to be fixed. During that time, they couldn't apply security patches. Anyway, these are some of the reasons why Flathub applications often use unpatched and insecure versions of components like Gtk+2, OpenJPEG, Python2, udev, etc. Do you know what is the Flathub members response to these allegations? I will tell you: "Sorry, but no". They prefer to pull the wool over people's eyes (BTW: do you remember 10% market-share by 2010 and 20% market-share by 2020?), and at the same time discredit the Snap/Snapcraft that objectively provides a better level of security. And believe me, they really hate Snap. Canonical has had problems with GNOME from the very beginning, when they started submitting patches to GNOME 2. Many of them were rejected for biased reasons. GNOME members have always ignored the needs of users, maintainers, and developers. This is why Canonical decided to develop Unity and later Mir (and others forked GNOME2/GNOME3, or patched Gtk+3). However, development costs money, they had a budget at least 10 times smaller than Red Hat, and it is hard to make big cash on the Linux desktop. Therefore, they had to revise their plans and focus on the cloud and IoT. Personally, I think the Snap/Snapcraft is doing pretty well for the resources that Canonical could have been spent on it, but unfortunately it is still far from being perfect.

Flathub/GNOME members are always externally rude:

  • running a snap is no more secure than "wget -O - URL | bash", again much unlike Flatpak
  • there is little point for us to continue to promote a technology that competes against GNOME's flatpak
  • I'm a big fan of deleting code. The Snap plugin is about 1500 lines, so I'm pretty sure we can remove the other 2500 by removing the purchase and auth support

They treat any form of criticism as "passive-aggressive behavior", but on the other hand, they see nothing wrong with calling the flatkill website owner an idiot.

What is even worse, they started spreading some ridiculous rumors. For example, when Visual Studio Code team launched their snap package and stated that they are not going to provide or even support flatpak, some GNOME and flatpak evangelists tried to discredit Snap and VSC, by saying that Canonical is sleeping with Microsoft. The reasons for choosing snap were purely technical - such package is a full-fledged IDE, while flatpak package is just broken by design. However, Flathub members state that the VSC is broken, not the flatpak. We had the same situation with the Atom:

<Persi> A big chunk of the issues that we get on io.atom.Atom follow the formula "In installed $PLUGIN and it doesn't work, but it works on snap/deb/rpm"
<Persi> We keep telling them to use flatpak-spawn --host, but that isn't going to be a big help to users on more rigid systems like silverblue or endless
<TingPing> Persi, gnome-builder did everything right, so copy that

They know it can't work that way, because plugins can't really provide native dependencies or use existing deps from the host, but they will still claim that all IDEs on the world are broken, except GNOME Builder of course, which is supposed to handle building flatpaks and only flatpaks. Another example: Flathub took JetBrains IDE just to gain a cheap popularity. JetBrains distanced themselves from supporting flatpak from the very beginning. Yet, they are blamed why it doesn't work properly under flatpak. It's been suggested that JetBrains IDEs are bugged and maybe even unmaintained by upstream. Yep, Flathub members always blame "lazy" developers for all issues, doing virtually nothing to fix the problem on their side. They also started a campaign against Snap on Reddit. Unfortunately, accounts with their posts have already been deleted, but you can still find some references. Anyway, they stated that Canonical wants to take control of the Linux software, the whole Snapcraft is corporate-driven and it is against the Linux community. Is that so? Well, not really. When it comes to Snapcraft, anyone can put their package there, while it's not that simple on Flathub. On Snapcraft, you have much more freedom. For example, you can provide some Windows software wrapped in WINE, when it is explicitly forbidden on Flatbub (BTW, on January 1, 2019 they stated that they are open to share their build infrastructure with others, and just less than two weeks later they started yelling that using it for non-Flathub packages is "abusing the build infrastructure"). On Snapcraft, you can even submit your own variant of the program if you think it's better than the official one (see: qalculate and qalculate-jz). On Flathub, there is a problem with submitting the Qt-based application if the Gtk-based variant is already there. When it comes to permissions, you can generally do more on Snapcraft, where permissions are granted according to strict rules, not discretionary as it is on Flathub. The Flathub runtime, for some reasons named Freedesktop (they claims it is "distributions agnostic, desktop environment agnostic, and package format agnostic", but it isn't really true - it may be adopted to other package formats, but right now it isn't truly agnostic), has been approved on Snapcraft as a community runtime, although in reality no one except GNOME is interested in it, and GNOME members generally don't publish their applications to Snapcraft. Canonical also gave the green light for Fedora runtime. On the other hand, Flathub has rejected Fedora runtime. Why? Because it "stinks"... What else? Flathub members stated that Snap is strongly tied to Ubuntu and there is no way it could properly support other distros anytime soon. How is it actually? Snap officially supports over 20 distributions. It is pre-installed on Manjaro, Ubuntu, Solus and Zorin OS. It supports Arch, Debian, openSUSE and others very well. Only in the Red Hat world (EL and Fedora) it have some serious issues, partially because snapd packages are intentionally broken there (but it isn't the only reason). Flathub also claims that it supports over 20 distros. However, support for LTS distros is often broken. From time to time, even normal distributions ( e.g. openSUSE Leap, Mageia, Mint, elementary OS, Endless OS, etc.) are affected by some issues. It happens that problems affect everything that isn't bleeding-edge, including openSUSE Tumbleweed and Fedora Rawhide. What's worse, Flathub constantly pushes developers to make changes that will break packages on older (but still officially supported by Flathub!) distributions, e.g. by removing direct dconf access.

When I am maintaining packages, I always try to not only build the software and its deps correctly, but as far as possible I try to fix the annoying bugs and improve its quality. For example, I've provided some patches and other fixes for Aegisub, gImageReader, NaSC, RawTherapee, wxMaxima, Widelands, XnRetro and dozens of other programs. I put even more efforts in polishing Notepadqq and OCRFeeder. Vendors usually appreciate my work, like it was e.g. in the case of Widelands ("Thanks to the work of scx we can now provide development builds for all distributions.") or OCRFeeder ("I gotta give my special thanks to the community member scx who not only fixed a few important issues and added a couple of quick improvements, but also was patient enough to wait for my delayed reviews last year, and even created the flatpak for OCRFeeder."). Back in time, I provided the Steam package for EL6, which gained some popularity. Then I provided some stuff to EPEL, ELRepo and Nux Dextop. My packages have also been somehow reused in other repos, such as RPM Sphere. I was also spotted at COPR, where I provided literally hundreds of packages. I often got nice e-mails from people who thanked me for maintaining packages. For all these years, only the members of Flathub sabotaged my work and tried to discredit my person: "To keep it short, submitter repeatedly ignores reviews, changes request and instead of acknowledging their poor behavior and doing something about it, keep saying it's a personal thing. While as admins we are not affecting day-to-day maintenance too much, it's important that everyone is cooperative instead of turning Flathub into some kind of playground." & "And here we go again, playing victim…" Eventually, they admitted that they were doing it for non-technical reasons: "In the end his manifests are often acceptable but they are a difficult person to work with and that is not ideal for the community." And I am "a difficult person to work with" just because I can't handle constant trolling and software fascism, i.e. discriminating one software and privileging another.

It's up to you if you want to care about the flatpak package, but I'm done here.

chgruver

comment created time in 4 days

issue commentRamonUnch/AltDrag

New name for the project

@RamonUnch

I am planing to rename the project, to avoid conflict with the original AltDrag.

I think it is fine to keep the old name if development of the orginal version has been stalled or original author just give up. Actually, we have a lot of such projects in FLOSS, including MyPaint or RawTherapee. You could also rename it to AltDrag2, just like it was with Notepad2Notepad3. If you want to pick different name, you should take a look at similar projects first:

It should be noted that these software are not only about dragging windows, but also snapping windows to the edges. I think this is a feature that is worth to be mentioned. Unfortunatelly, snapdragon and snapdragger are trademarks, and snapdrag is already taken. However, AltSnap should be free for now. The same thing applies to AltWM.

RamonUnch

comment created time in a month

pull request commentRamonUnch/AltDrag

Force check hotkeys state

@RamonUnch

Thank you for your cooperation!

scx

comment created time in a month

issue commentRamonUnch/AltDrag

Wrong state of hotkeys after returning from screen lock

In case someone was affected by this bug and didn't want to wait for AltDrag 1.45, here are the test builds:

They are based on ec078869d67764a029a5309d028adc8c20870f5c from Jun 24, 2021.

scx

comment created time in a month

pull request commentRamonUnch/AltDrag

Force check hotkeys state

@RamonUnch

the IsHotKeyDown() function already exists, please avoid so much extra code

I can see that you used IsHotKeyDown(&conf.Hotkeys) in your code. How does it work? Or rather: what does table conf.Hotkeys contain? All the hotkeys enabled in the Hotkeys panel (Left and Right Alt by default)? If so, how does it deal with the Combined Keys feature? It doesn't, right?

So I would have to extend the IsHotKeyDown() function to handle this case (let's say, by adding a boolean value as an argument, e.g. check_combined), right? That's what you mean?

scx

comment created time in a month

issue commentRamonUnch/AltDrag

Wrong state of hotkeys after returning from screen lock

Could you make a PR?

Done.

Test builds:

scx

comment created time in a month

PR opened RamonUnch/AltDrag

Force check hotkeys state

Force check hotkeys state when performing mouse wheel actions.

Fixes RamonUnch/AltDrag#74

+29 -2

0 comment

1 changed file

pr created time in a month

issue commentRamonUnch/AltDrag

Wrong state of hotkeys after returning from screen lock

Similar issue: https://github.com/RamonUnch/AltDrag/issues/46

See also: https://github.com/RamonUnch/AltDrag/issues/71

scx

comment created time in a month

create barnchscx/AltDrag

branch : altstate

created branch time in a month

issue openedRamonUnch/AltDrag

Wrong state of hotkeys after returning from screen lock

Some actions are performed even when the hotkeys are not pressed.

Steps to reproduce

  1. Install AltDrag 1.0-1.44.

  2. Run AltDrag.

  3. Setup AltDrag

    3.1. Set scroll whell action to Transparency.

    3.2. Set Left Alt and Right Alt as the hotkeys.

    3.3. Make sure that the Combo Keys option is disabled.

  4. Open one or more Explorer windows (e.g. Documents, Pictures, etc.).

  5. Test changing window transparency by pressing Alt-Scroll Up/Down.

  6. Lock screen by pressing Alt-Ctrl-Del, then Lock.

  7. Press Ctrl-Alt when screen is locked. Repeat two times to be sure.

  8. Enter your password, then press Enter to return to your desktop.

  9. Don't press any key. Just hold the mouse cursor over a window, then scroll up/down using scroll wheel.

Expected results

Nothing special should happen from the AltDrag. You may scroll window content or perform any other default scroll action.

Current results

Although hotkeys are not pressed, the selected window changes transparency level.

Notes

You can get similar results with any other scroll wheel actions, e.g. Alt-Tab, Volume, Lower Window, Maximize Window, etc.

This bug doesn't appear for middle mouse button actions.

It also doesn't affect left and right mouse button actions.

Explanation

AltDrag tries to check key state when possible. Unfortunately, it is unable to record release of the mentioned keys when lock screen is enabled.

Solution

AltDrag should check the state of the keys more carefully.

Temporary patch

AltDrag-1.44-AltState.diff (git diff): AltDrag-1.44-AltState.diff.txt https://pastebin.com/raw/L1vtAW0K

diff --git a/hooks.c b/hooks.c
index 3b73432..221fb0e 100644
--- a/hooks.c
+++ b/hooks.c
@@ -1570,6 +1570,30 @@ static void SetForegroundWindowL(HWND hwnd)
         PostMessage(state.mdiclient, WM_MDIACTIVATE, (WPARAM)hwnd, 0);
     }
 }
+// Return true if required amount of hotkeys are holded.
+// Defaults hotkeys are left and right Alt.
+// If KeyCombo is disabled, user needs to hold only one hotkey.
+// Otherwise, user needs to hold at least two hotkeys.
+static int AltState()
+{
+    // required keys, default 1
+    UCHAR rkeys = 1;
+    // if KeyCombo is enabled, one more key is required to be holded
+    if (conf.KeyCombo) rkeys++;
+    // current keys
+    UCHAR ckeys = 0;
+    // loop over all hotkeys
+    struct hotkeys_s *hk = &conf.Hotkeys;
+    UCHAR *pos=&hk->keys[0];
+    while (*pos && ckeys < rkeys) {
+        // check if key is held down
+        if (GetAsyncKeyState(*pos)&0x8000)
+            ckeys++;
+        pos++;
+    }
+    // return true if required amount of hotkeys are holded 
+    return ckeys >= rkeys;
+}
 // Returns true if AltDrag must be disabled based on scroll lock
 // If conf.ScrollLockState&2 then Altdrag is disabled by Scroll Lock
 // otherwise it is enabled by Scroll lock.
@@ -2698,8 +2722,11 @@ LRESULT CALLBACK LowLevelMouseProc(int nCode, WPARAM wParam, LPARAM lParam)
             return CallNextHookEx(NULL, nCode, wParam, lParam);
         }
     } else if (wParam == WM_MOUSEWHEEL || wParam == WM_MOUSEHWHEEL) {
-        int ret = WheelActions(pt, msg, wParam);
-        if (ret == 1) return 1;
+        // Force check of hotkeys state
+        if (AltState()) {
+            int ret = WheelActions(pt, msg, wParam);
+            if (ret == 1) return 1;
+        }
         return CallNextHookEx(NULL, nCode, wParam, lParam);
     }
 

AltDrag-1.44-AltState.patch (diffutils patch): AltDrag-1.44-AltState.patch.txt https://pastebin.com/raw/JL2gw1vT

diff -au AltDrag.orig/hooks.c AltDrag/hooks.c
--- AltDrag.orig/hooks.c	2021-06-24 11:44:43.919604500 +0200
+++ AltDrag/hooks.c	2021-06-24 12:29:54.988818800 +0200
@@ -1570,6 +1570,30 @@
         PostMessage(state.mdiclient, WM_MDIACTIVATE, (WPARAM)hwnd, 0);
     }
 }
+// Return true if required amount of hotkeys are holded.
+// Defaults hotkeys are left and right Alt.
+// If KeyCombo is disabled, user needs to hold only one hotkey.
+// Otherwise, user needs to hold at least two hotkeys.
+static int AltState()
+{
+    // required keys, default 1
+    UCHAR rkeys = 1;
+    // if KeyCombo is enabled, one more key is required to be holded
+    if (conf.KeyCombo) rkeys++;
+    // current keys
+    UCHAR ckeys = 0;
+    // loop over all hotkeys
+    struct hotkeys_s *hk = &conf.Hotkeys;
+    UCHAR *pos=&hk->keys[0];
+    while (*pos && ckeys < rkeys) {
+        // check if key is held down
+        if (GetAsyncKeyState(*pos)&0x8000)
+            ckeys++;
+        pos++;
+    }
+    // return true if required amount of hotkeys are holded 
+    return ckeys >= rkeys;
+}
 // Returns true if AltDrag must be disabled based on scroll lock
 // If conf.ScrollLockState&2 then Altdrag is disabled by Scroll Lock
 // otherwise it is enabled by Scroll lock.
@@ -2698,8 +2722,11 @@
             return CallNextHookEx(NULL, nCode, wParam, lParam);
         }
     } else if (wParam == WM_MOUSEWHEEL || wParam == WM_MOUSEHWHEEL) {
-        int ret = WheelActions(pt, msg, wParam);
-        if (ret == 1) return 1;
+        // Force check of hotkeys state
+        if (AltState()) {
+            int ret = WheelActions(pt, msg, wParam);
+            if (ret == 1) return 1;
+        }
         return CallNextHookEx(NULL, nCode, wParam, lParam);
     }
 

Please note that it check the state of the hotkeys only when performing scroll wheel actions, so it shouldn't affect performance too much.

PR is on the way.

created time in a month

fork scx/AltDrag

Maintained continuation of Stefan Sundin's AltDrag

fork in a month