Announcement

Collapse
No announcement yet.

Wine 6.11 Released With Theming Support For All Built-In Programs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • dacha
    replied
    Originally posted by ix900 View Post
    What you're saying is basically that wine is so broken that it can't do its one thing correctly so it has to be splintered into multiple. That cannot be correct.
    Windows itself uses compatibility shims for older apps on newer Windows versions, so even Windows arguably had to be "splintered into multiple" for everything to work as well as it does.

    The LGPL licence also prevents Wine from being closed off, so these forks aren't necessarily that harmful.

    Leave a comment:


  • Cybmax
    replied
    Originally posted by ix900 View Post

    What you're saying is basically that wine is so broken that it can't do its one thing correctly so it has to be splintered into multiple. That cannot be correct.

    Point in fact I've seen code not added to wine in tkg's or ge's projects and it is stuff that should be added to Wine since its stubbed or unfinished. No one adds it.

    I do not see it your way ;-)
    Well, i do not disagree with you completely, because i aswell would like to and do not always understand why it does not work that way. What i do know is that it is somewhat of a rigid system to get stuff accepted upstream wine. Just look at all the code in staging that DO WORK, but does not seem to ever be accepted mainline.

    Some of it is understandable, as wine (i guess) strive for stability even tho it is not always the case, vs staging strive to "get things working" albeit code not deemed stable/correct enough. I do not know why staging <-> wine could never be "1 project" other than that staging is "experimental". A lot of code goes from staging -> upstream tho, so it is working even tho it is a very slow process.

    When it comes to proton, this is a "STEAM gaming branch", so it is a different project altogether (Different goals). TKG/GE is "enthusiast projects" and although contributing with code it is usually picking useful patches from proton/staging/other and putting it together. I also do that for my own wine version - picking proton patches, and other "performance patches" i find from various sources. Some of this is definitely not "production ready" code, as it is "hacks" to fix problems. (Eg. vulkan fullscreen hack patches, that really work great imo)
    WineHQ team i think try to avoid those "hacks" even tho it works. I have at some occasions spoken out on this... cos as you point out they SOMETIMES add stub's that are "unsafe", yet at other times is very rigid at adding (to me seemingly) working code.

    Think of it like this then: Why do not all distro kernels have the futex wait multiple (fsync), or futex2 pathes? Why do you have to use a 3rd party kernel for your distro? The distro kernels are CLEARLY not working optimally then? Or even winesync/fastsync kernel module + wine patches? It works fine, and could even be built as a standalone 3rd party kernel module with dkms. Don't see that in the Ubuntu repo....
    Oh.. cos it is still "experimental code" that is not yet upstream.

    It is what it is....

    Leave a comment:


  • ix900
    replied
    Originally posted by Cybmax View Post

    Yeah.
    Proton is mostly about steam/gaming, so the patches there are to get steam games to work. Staging is "wine experimental branch", and although good for gaming, is not mainly focused on that.

    So, lets take an example: Say you run app X on wine-staging. Then you decide you wanna try some game. That does not work very well with staging, so you try proton... and it works. However, running proton breaks app X.
    Lets say you combine the patches in staging + the patches in proton to get your game running? A "one-shoe-fits-all".. so that you can run App X and your game with the same "wine" version. That is mostly what TKG/GE is doing with their projects.

    It is not as simple as "jeez.. just combine all the projects upstream then!". Different ideas, different goals.. different people.

    EDIT: GE is more "release based" prebuilt version, where as TKG is fully customizable with no "release". You just enable/disable what fixes you want in the config files and you get a source based on that.
    What you're saying is basically that wine is so broken that it can't do its one thing correctly so it has to be splintered into multiple. That cannot be correct.

    Point in fact I've seen code not added to wine in tkg's or ge's projects and it is stuff that should be added to Wine since its stubbed or unfinished. No one adds it.

    I do not see it your way ;-)

    Leave a comment:


  • aufkrawall
    replied
    Originally posted by Linuxxx View Post
    Have You tried the recent Proton-GE build?

    Generally I have a better experience with it for running games than with WINE-Staging.
    I'll probably give it a try, given all the regressions with -staging when trying to stay up to date. My last attempt with regular Proton didn't work out well for this scenario, even though it has got much better for its intended purpose lately.

    Leave a comment:


  • Cybmax
    replied
    Originally posted by jbennett View Post

    That's not really what's going on. GE, for example, is taking the Proton changes and rebasing them on newer Wine versions. It's work that will eventually land in upstream Proton/Wine, but not code changes like you would think of normally. TKG looks like the same thing. It's like Wine has three branches: Vanilla, staging, and Proton. Staging and Proton both have experimental patches/fixes in place, and those do wind up in vanilla wine eventually. TKG and GE are just builds that pull in some of those patches from various places.
    Yeah.
    Proton is mostly about steam/gaming, so the patches there are to get steam games to work. Staging is "wine experimental branch", and although good for gaming, is not mainly focused on that.

    So, lets take an example: Say you run app X on wine-staging. Then you decide you wanna try some game. That does not work very well with staging, so you try proton... and it works. However, running proton breaks app X.
    Lets say you combine the patches in staging + the patches in proton to get your game running? A "one-shoe-fits-all".. so that you can run App X and your game with the same "wine" version. That is mostly what TKG/GE is doing with their projects.

    It is not as simple as "jeez.. just combine all the projects upstream then!". Different ideas, different goals.. different people.

    EDIT: GE is more "release based" prebuilt version, where as TKG is fully customizable with no "release". You just enable/disable what fixes you want in the config files and you get a source based on that.
    Last edited by Cybmax; 19 June 2021, 02:25 PM.

    Leave a comment:


  • jbennett
    replied
    Originally posted by ix900 View Post

    I do wonder if tkg's (ge's, etc) code is not up to snuff as to why they don't seem to donate all their fixes to wine project. I only use others if winehq's doesn't work well enough but the majority of the time (98%+) for me its fine. I find not putting the fixes into wine project is a really odd thing and isn't how I would go about it.
    That's not really what's going on. GE, for example, is taking the Proton changes and rebasing them on newer Wine versions. It's work that will eventually land in upstream Proton/Wine, but not code changes like you would think of normally. TKG looks like the same thing. It's like Wine has three branches: Vanilla, staging, and Proton. Staging and Proton both have experimental patches/fixes in place, and those do wind up in vanilla wine eventually. TKG and GE are just builds that pull in some of those patches from various places.

    Leave a comment:


  • ix900
    replied
    Originally posted by aufkrawall View Post
    -staging likely regresses even more (hard to imagine that this was even possible, but well). Still sticking with a (tkg) -staging 6.8 build, as I prefer my games being able to run and wineserver not eating a whole CPU thread for nothing...
    I do wonder if tkg's (ge's, etc) code is not up to snuff as to why they don't seem to donate all their fixes to wine project. I only use others if winehq's doesn't work well enough but the majority of the time (98%+) for me its fine. I find not putting the fixes into wine project is a really odd thing and isn't how I would go about it.
    Last edited by ix900; 19 June 2021, 12:51 PM.

    Leave a comment:


  • Linuxxx
    replied
    Originally posted by aufkrawall View Post
    -staging likely regresses even more (hard to imagine that this was even possible, but well). Still sticking with a (tkg) -staging 6.8 build, as I prefer my games being able to run and wineserver not eating a whole CPU thread for nothing...
    Have You tried the recent Proton-GE build?

    Generally I have a better experience with it for running games than with WINE-Staging.

    Leave a comment:


  • aufkrawall
    replied
    Originally posted by Turbine View Post
    It'd be nice if you could install any version of office from the past decade. I honestly find vanilla Wine useless for anything.
    -staging likely regresses even more (hard to imagine that this was even possible, but well). Still sticking with a (tkg) -staging 6.8 build, as I prefer my games being able to run and wineserver not eating a whole CPU thread for nothing...

    Leave a comment:


  • Turbine
    replied
    It'd be nice if you could install any version of office from the past decade. I honestly find vanilla Wine useless for anything.

    Leave a comment:

Working...
X