Affinity Suite v2.0.4 on linux [ Wine ]

[Wanesty]

20 hours ago, Chillfox said:

0118:err:vulkan:get_vulkan_driver Wine was built without Vulkan support.

you're most likely missing some vulkan driver or/and maybe you didn't build wine while having vulkan dev dependencies https://wiki.winehq.org/Building_Wine#:~:text=systemd-,vulkan,-libvulkan-dev

also, does it work with OpenGL ?

[Wanesty]

@Chillfox any luck so far ?

[macdabby]

Any chance someone can dockerize this? I always have problems with wine for some reason. I know there are some good docker containers that have the latest wine etc.

[Grunt]

On 3/14/2023 at 3:54 PM, ElementalWarrior said:

This

wine-7.9-5442-gdb8b984c1f8

likely means you are using the wrong wine version. It should says wine-8.3.

It's just taken straight from Git and compiled into binary:

pkgver() {
    git -C wine describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^wine.//;s/^v//;s/\.rc/rc/'
}

And same result: 7.9.r5442.gdb8b984c1f8 and wine-git-7.9.r5442.gdb8b984c1f8-1-x86_64.pkg. But it's patched Wine 8.3. Simply change it in repository I guess.

So far tested Affinity Photo 2.0.4 and Affinity Designer 2.0.4 on ArchLinux/Manjaro and I agree. Works pretty fine.

No anti-aliasing, some weird graphical glitches but so far no crashes. Works surprisingly well. I have to make some time at weekend and prepare some testing session and test AF/AD properly. It's really just stubbed dxcore on Wine in custom branch?

[ElementalWarrior]

10 minutes ago, Grunt said:

It's just taken straight from Git and compiled into binary:

pkgver() {
    git -C wine describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^wine.//;s/^v//;s/\.rc/rc/'
}

And same result: 7.9.r5442.gdb8b984c1f8 and wine-git-7.9.r5442.gdb8b984c1f8-1-x86_64.pkg. But it's patched Wine 8.3. Simply change it in repository I guess.

So far tested Affinity Photo 2.0.4 and Affinity Designer 2.0.4 on ArchLinux/Manjaro and I agree. Works pretty fine.

No anti-aliasing, some weird graphical glitches but so far no crashes. Works surprisingly well. I have to make some time at weekend and prepare some testing session and test AF/AD properly. It's really just stubbed dxcore on Wine in custom branch?

For backwards compatibility, most applications try to implement stable API's of things (its the reason why wine is possible and so successful).

Dxcore is just a wrapper around directx functionality. I would guess that Affinity photo has some defensive programming, or uses old API's if dxcore doesn't give an appropriate response. When they were developing this in house, the had to transition to dxcore right? But they still wanted other devs not responsible for the windows store packaging to be able to make progress. So it makes sense in that regard.

In terms of getting this to work, it wasn't just dxcore. There was a bug in icon code (which someone else did, I just included the commit). And a number of uninmplemented functions that failed when not included in the dll's.

A good portion of wine is literally just functions that don't do anything. But they have to exist to be called in the first place.

You can thank Proton and devs actively working on Vulkan and Graphics API's for their continued efforts.

I just spent dozens of hours in the last year debugging, and implementing missing functions.

[ElementalWarrior]

Just now, ElementalWarrior said:

For backwards compatibility, most applications try to implement stable API's of things (its the reason why wine is possible and so successful).

Dxcore is just a wrapper around directx functionality. I would guess that Affinity photo has some defensive programming, or uses old API's if dxcore doesn't give an appropriate response. When they were developing this in house, the had to transition to dxcore right? But they still wanted other devs not responsible for the windows store packaging to be able to make progress. So it makes sense in that regard.

In terms of getting this to work, it wasn't just dxcore. There was a bug in icon code (which someone else did, I just included the commit). And a number of uninmplemented functions that failed when not included in the dll's.

A good portion of wine is literally just functions that don't do anything. But they have to exist to be called in the first place.

You can thank Proton and devs actively working on Vulkan and Graphics API's for their continued efforts.

I just spent dozens of hours in the last year debugging, and implementing missing functions.

I probably should have just started contributing to GIMP or Krita tbh 😂

[Wanesty]

53 minutes ago, Grunt said:

No anti-aliasing

only on the UI font, the viewport looks fine right ?

[Wanesty]

48 minutes ago, ElementalWarrior said:

I probably should have just started contributing to GIMP or Krita tbh 😂

honestly, neither of them have good vector rendering/workflow.. (like i believe both have vector curve but they get rasterized to the document's resolution)

edit : and inkscape is too web oriented for most graphic designer

[ElementalWarrior]

45 minutes ago, Wanesty said:

honestly, neither of them have good vector rendering/workflow.. (like i believe both have vector curve but they get rasterized to the document's resolution)

edit : and inkscape is too web oriented for most graphic designer

That is my primary reason for wanting Affinity Photo aha.

[Grunt]

23 hours ago, ElementalWarrior said:

Dxcore is just a wrapper around directx functionality. I would guess that Affinity photo has some defensive programming, or uses old API's if dxcore doesn't give an appropriate response. When they were developing this in house, the had to transition to dxcore right? But they still wanted other devs not responsible for the windows store packaging to be able to make progress. So it makes sense in that regard.

And it can possibly fail again in any future release. Do I get it right?

23 hours ago, ElementalWarrior said:

In terms of getting this to work, it wasn't just dxcore. There was a bug in icon code (which someone else did, I just included the commit). And a number of uninmplemented functions that failed when not included in the dll's.

A good portion of wine is literally just functions that don't do anything. But they have to exist to be called in the first place.

Is there somewhere complete dependency graph required by Affinity package? So far I know about .NET 4.8, WinRT, DXCore and DirectX for UI and canvas renderer.

23 hours ago, ElementalWarrior said:

You can thank Proton and devs actively working on Vulkan and Graphics API's for their continued efforts.

Right. I should. Just tested Photo on llvmpipe and works as well. Try it without Vulkan and wit parameters LIBGL_ALWAYS_SOFTWARE=1 wine Photo.exe (--no-hw-ui) --no-ocl.

23 hours ago, ElementalWarrior said:

I just spent dozens of hours in the last year debugging, and implementing missing functions.

Well, then we should probably pay you and not Affinity team for licensing:

As there are different glitches in software, license activation layer works without hitch. Pure mystery for me how this one aspect is always implemented flawlessly.

[Grunt]

23 hours ago, Wanesty said:

only on the UI font, the viewport looks fine right ?

Viewport is mix of anti-aliased font and something smudged, some parts are native bitmap-like font and native GTK-like UI. An interesting sight. But it works.

[ElementalWarrior]

17 minutes ago, Grunt said:

And it can possibly fail again in any future release. Do I get it right?

Is there somewhere complete dependency graph required by Affinity package?

Yes, could fail again.

Best bet is just to look at the DLLs imported. You could use dnspy to see further. Just don't use it to reverse engineer windows code.

[Wanesty]

15 hours ago, Grunt said:

Pure mystery for me how this one aspect is always implemented flawlessly.

i believe the login part is one of the most recent code in Serif apps so it make sense that it uses the same and few dependencies
(>one of the most recent code : i believe a lot of code for Affinity is from Serif's previous graphic suite (thus explaining a lot of weird legacy implementation))

[Wanesty]

On 3/22/2023 at 10:03 PM, Grunt said:

Viewport is mix of anti-aliased font and something smudged, some parts are native bitmap-like font and native GTK-like UI. An interesting sight. But it works.

most wine fonts are indeed bitmap but the font rendered by affinity directly are anti-aliased (because it doesn't rely on wine's renderer)

[Rafael Brucart]

Fantastic, this gives me hope. Thanks @ElementalWarrior

Has anyone had any success with Bottles (flatpak)? so placing the compiled wine into ~/.var/app/com.usebottles.bottles/data/bottles/runners
Then creating a Bottle for Affinity?

That said. Is there any chance @ElementalWarrior of putting out a compiled/binary release of this wine so others don't have to figure out why official wine dependency lists are missing packages, or miss naming them, and all the other strange things that happen when inexperienced peeps like myself end up flooding their OS with hundreds of dev packages and wasting hours or days until they finally give up.

I just switched to Windows at start of the year just for Affinity. Windows is the worst OS, and I miss Fedora dearly. I hope these patches make it to a precompiled Wine version. I know my limitations and have spent days trying to compile software in the past with no success, I must be dumb or cursed

Edited March 24, 2023 by Rafael Brucart

[niteswimming]

Hi folks,

first of all: thank you so much for your work and efforts! Had Affinity running in virtual machine till now. Running it in wine is much more comfortable.

I did everything step by step and managed to install the apps. But on startup I get this message:

"There was a problem starting the app.
The other Affintiy apps cannot be reached. Please make sure the app is up to date and your firewall is not blocking any LAN connections."

Original: "Beim Start der App trat ein Problem auf.
Die anderen Affintiy-Apps sind nicht erreichbar. Stellen Sie bitte sicher, dass die App auf dem neuesten Stand ist und Ihre Firewall keine Lan-Verbindungen blockiert."

No matter which starter I use (Publisher, Designer, Photo), it's all the same.

Any Ideas? (Unfortunately I'm not that deep into...)

 

EDIT: I did the installation with Affinity Photo 1 and it's working.... but want to use Photo 2

 

Edited March 25, 2023 by niteswimming

[SevenStart]

yeah i still couldn't compile this wine variant (I guess I'm not smart enough)

I got following error-msg:

 

Compile error: X11/extensions/Xrandr.h: No such file or directory
    33 | #include <X11/extensions/Xrandr.h>
       |     
compiling done

I guess i have to wait till this changes are merged to the main-branch of wine.🤷‍♂️

[Daegalus]

I just wanted to provide that I was successfully able to build and run everything. Everything works super well, have all 3 installed now and working.

Now to see if I can get this all working in Bottles. Lutris worked fine.

I will say it was quite annoying to install all the dependencies and getting them to work. Can't wait until this is upstreamed.

Based on how much free time I have, I might look into making a docker image to build this, so it is easier for others to build without polluting their systems. Or I might setup a mirror on Github and use Github Actions to build prebuilt versions. But I got a lot on my plate, so not sure if I will get to any of this. Thanks ElementalWarrior for getting this working.

[Wanesty]

On 3/25/2023 at 12:56 AM, Rafael Brucart said:

Has anyone had any success with Bottles (flatpak)? so placing the compiled wine into ~/.var/app/com.usebottles.bottles/data/bottles/runners
Then creating a Bottle for Affinity

you can !!  but you'd have to use winetricks to install dotnet48 since Bottle own "winetricks replacement" doesn't add the right registry keys.

[Wanesty]

4 hours ago, Daegalus said:

I might look into making a docker image to build this, so it is easier for others to build without polluting their systems

a docker image could be nice indeed but i never had docker in my workflow so yea i won't be the one doing it x)
also my install should be relatively clean since it only write :

• /bin/rum
• /opt/wines/
• /home/USER/Documents/wine
• /home/USER/Documents/rum
• the wine prefix you made

like, i get what you mean but at least you know where stuff are, and yes i might make a AUR package for rum and maybe an other one for ElementalWarrior's fork if some of you are on Arch (maybe react with a "Haha" if you are and interested)

[Wanesty]

On 3/25/2023 at 1:24 PM, niteswimming said:

Any Ideas? (Unfortunately I'm not that deep into...)

did you set your wineprefix version back to win10 / win11 ?

maybe your winmd files are outdated (weird but idk)

did you install it with the .exe or the .msix ?

if you installed it with bottle maybe you have a mshtml (or similar) disabled ?

^ this is winewfg btw

wine winecfg

rum ElementalWarrior-8.3 "/home/USER/.WineAffinity" wine winecfg

 

[Daegalus]

5 hours ago, Wanesty said:

you can !!  but you'd have to use winetricks to install dotnet48 since Bottle own "winetricks replacement" doesn't add the right registry keys.

Good tip, this fixed my bottle for me and now i have all my Affinity stuff in a bottle. Works great there now too. Now I can uninstall Lutris again.

[Daegalus]

5 hours ago, Wanesty said:

a docker image could be nice indeed but i never had docker in my workflow so yea i won't be the one doing it x)
also my install should be relatively clean since it only write :

• /bin/rum
• /opt/wines/
• /home/USER/Documents/wine
• /home/USER/Documents/rum
• the wine prefix you made

like, i get what you mean but at least you know where stuff are, and yes i might make a AUR package for rum and maybe an other one for ElementalWarrior's fork if some of you are on Arch (maybe react with a "Haha" if you are and interested)

While that does look clean, installing the 20+ 32bit libraries, and extra 64bit ones that I normally dont need wasn't pleasant. With a docker image, I can have all those dependencies pre-installed inside the docker image, and then just do `docker run wine-builder -v ~/path-to-wine-src:/path-to-wine-in-image` and it will just spit out a working, properly compiled setup, all self-contained.

I'm also a devops engineer, so containers is where i live most of my day, so they are comfortable for me, even though I rarely use them unless necessary on my personal devices. Also I never use RUM or manage my prefixes manually, its why i use flatpak Bottles, so everything lives in one place and a lot of stuff is handled for me. (minus apparently broken dependency installers, I might open a ticket for that with bottles.)

I am also on Fedora (moved from arch a few months ago), so different flow in general from Arch. I might maybe make  COPR repo for it (its like AUR for fedora) so it can be used easily on Fedora by others. I'll see what I have time for.

Edited March 27, 2023 by Daegalus

[SevenStart]

17 minutes ago, Daegalus said:

I am also on Fedora (moved from arch a few months ago), so different flow in general from Arch. I might maybe make  COPR repo for it (its like AUR for fedora) so it can be used easily on Fedora by others. I'll see what I have time for.

If you could, you would be my hero. To be honest I'm still having trouble installing all the dependencies to make the applications work.
I had to reinstall Fedora because there were some problems and I didn't know how to uninstall the "make install".

Yes, I know I'm a noob, but at least I'm trying.😅

[Grunt]

5 hours ago, Wanesty said:

and yes i might make a AUR package for rum and maybe an other one for ElementalWarrior's fork if some of you are on Arch (maybe react with a "Haha" if you are and interested)

Why do you use rum? I simply made my own Wine (affinity-patched) package and I intend use it only on designated MMC and only for testing purposes. No serious use at all (Affinity crashes a lot). When I'm done with it pacman -R wine-git and it's done (followed by formatting).

26 minutes ago, Daegalus said:

and then just do `docker run wine-builder -v ~/path-to-wine-src:/path-to-wine-in-image` and it will just spit out a working, properly compiled setup, all self-contained.

And you intend to distribute this docker image?