Announcement

Collapse
No announcement yet.

Wine 1.7.20 Finally Released, Brings X11 Drag & Drop Fixes

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

  • #16
    Originally posted by geearf View Post
    He's basically saying that you should look for the commit that broke that game for you.
    Basically you know the last date when it worked, and you know that now it doesn't.
    So you try with a wine build at half in between those dates.
    Depending on the result, you do the same of the right half or the left half and so on, till you find the bad commit.
    That might work... if the last "working Wine version" wasn't 1.3.x... >.<
    I haven't played in a few years

    Originally posted by Dukenukemx View Post
    I'd be happy if they supported the DX9 state tracker. I have tried CSMT on my laptop and it makes little difference. It's probably better with a really powerful CPU, which my laptops i3 is not. The move to support DX10/11 would probably bring even further degradation of performance. Something more dramatic needs to be done to go that route.
    They won't support the D3D9 state tracker for the same reason many people aren't supporting Mir upstream: It's a single-vendor solution. Hell, it's a half-vendor solution... Only AMD cards on Open Source drivers would be able to access the ability.
    Now, say the Open Source NVidia drivers switched to Gallium3D... then the Wine devs would give it serious thought.

    Originally posted by pinguinpc View Post
    Its strange on my case i have GOG version and works without problem

    But I use nvidia card with lastest propietary drivers with this command

    Sometimes also need rename movies folder for work

    I don't think the GOG version is the one on Steam... also, the GOG version is now up to version 2.0.0, and your game was on 1.69 (which was the last "official" update before GOG took control of it). Maybe a patch GOG did to support Windows 8 or something (bringing it up to version "2.0") broke the Wine support?

    Comment


    • #17
      Originally posted by Daktyl198 View Post
      [...] Now, say the Open Source NVidia drivers switched to Gallium3D [...]
      Nouveau is already based on Gallium3D, it's the official Intel driver that is pure Mesa (there is LunarG's ilo driver though, but it isn't as optimized or even well known).

      Comment


      • #18
        Originally posted by chinoto View Post
        Nouveau is already based on Gallium3D, it's the official Intel driver that is pure Mesa (there is LunarG's ilo driver though, but it isn't as optimized or even well known).
        Yeah, just learned that in another thread. I know next to nothing about Nouveau, so I'm sorry for that
        I could have sworn that "It would only work on AMD cards, so no" was Wine's reason... maybe they just ignore Nouveau because so few people use it? idk :/

        Is the D3D9 state tracker actually in Gallium3D mainline? Or is it still on a fork? If it's mainline, and we could convince Intel to add such a state tracker to it's driver... It would be interesting to see people developing D3D applications on Linux... And it would help the porting of Games, to be sure ^.^

        (wouldn't it be funny if the Linux drivers could provide better D3D performance than the Windows ones? >.<)

        Comment


        • #19
          Originally posted by Daktyl198 View Post
          That might work... if the last "working Wine version" wasn't 1.3.x... >.<
          I haven't played in a few years
          It's a binary search, so a few years would only add a couple extra checks.

          On the sad side, building Wine takes 15 minutes on a hexacore in RAM. It's an extremely bad project to bisect in that sense, which they acknowledge: they have that binary repo with snapshots (was it weekly?) which you can use to start the search, only having to build a couple times.

          Comment


          • #20
            Originally posted by curaga View Post
            On the sad side, building Wine takes 15 minutes on a hexacore in RAM. It's an extremely bad project to bisect in that sense, which they acknowledge: they have that binary repo with snapshots (was it weekly?) which you can use to start the search, only having to build a couple times.
            That is not entirely true. Once the amount of changes becomes low, the build system will detect that some files have not changed and skip rebuilding parts of the tree.

            Besides, 15 minutes is minor. Ever tried bisecting a kernel on ~10 yr old machine? (distcc for the win btw...)

            Comment


            • #21
              Originally posted by Daktyl198 View Post
              maybe they just ignore Nouveau because so few people use it? idk :/
              Or because at this point, it's basically useless. Once they get reclocking working, it might be faster than the closed-source driver
              Originally posted by Daktyl198 View Post
              we could convince Intel to add such a state tracker to it's driver...
              It might be possible, but then they'd have to play catch up with Gallium3D, what would be better is if they converted their codebase to Gallium3D or switched to the ilo driver and improved it.
              Originally posted by Daktyl198 View Post
              (wouldn't it be funny if the Linux drivers could provide better D3D performance than the Windows ones? >.<)
              Indeed, and probably would too.

              Comment


              • #22
                Another Wine update came out from the openSUSE repo, drag&drop still isn't working with Notepad++.

                Comment


                • #23
                  Originally posted by Rexilion View Post
                  That is not entirely true. Once the amount of changes becomes low, the build system will detect that some files have not changed and skip rebuilding parts of the tree.

                  Besides, 15 minutes is minor. Ever tried bisecting a kernel on ~10 yr old machine? (distcc for the win btw...)
                  The last time I did Wine bisecting, I had to run configure in each step (because they added/removed files/config options, and the auto-re-run was borked somehow), or the build would fail. Running configure prompted a full rebuild.

                  Sure I could have wasted time trying to build first, failing, running configure and a full build, but that would have been even more frustrating. The kernel is much more well behaved in that sense, it almost never forces a full rebuild.

                  Comment


                  • #24
                    POL

                    You could try binary WINE versions from Play on Linux...

                    Comment


                    • #25
                      Originally posted by chinoto View Post
                      I was excited when he mentioned the drag&drop functionality was finally fixed, so I updated Wine... it's still broken
                      I use Wine to run Notepad++ for development, but recently drag&drop stopped working, so I had to add entry to dolphin's "Open With" context menu, unfortunately that's dependent on the extension (which I could also add the option for), so for non-php files I press Shift+F4 to bring up a terminal and type "npp file" (I have an alias for it in ~/bin/).
                      Please describe that problem in detail, I want to try and fix it.

                      Comment


                      • #26
                        Originally posted by dacha View Post
                        Please describe that problem in detail, I want to try and fix it.
                        Well I used to be able to open Notepad++ and Dolphin (KDE's file manager), then drag a file from Dolphin and release onto Notepad++, and then the file would be opened in Notepad++. Sometimes it wouldn't work, but if I had it maximized, it would always work to drop a file in the upper left area of the program. But now when I do that, it is completely ignored. Not really sure what to say about it beyond that :/

                        Comment


                        • #27
                          Originally posted by chinoto View Post
                          Well I used to be able to open Notepad++ and Dolphin (KDE's file manager), then drag a file from Dolphin and release onto Notepad++, and then the file would be opened in Notepad++. Sometimes it wouldn't work, but if I had it maximized, it would always work to drop a file in the upper left area of the program. But now when I do that, it is completely ignored. Not really sure what to say about it beyond that :/
                          Thank you. I had a look. The problem is that Windows seems to always use window-relative coordinates for the point where the files were dropped, but Wine uses screen-relative coordinates, and Notepad++ doesn't check what coordinate type is in use. Patch submitted at http://source.winehq.org/patches/data/105219 and you can follow Wine bug 28557 for progress.

                          Comment


                          • #28
                            Originally posted by dacha View Post
                            Thank you. I had a look. The problem is that Windows seems to always use window-relative coordinates for the point where the files were dropped, but Wine uses screen-relative coordinates, and Notepad++ doesn't check what coordinate type is in use. Patch submitted at http://source.winehq.org/patches/data/105219 and you can follow Wine bug 28557 for progress.
                            Wow, thanks! OSS is great Hopefully a new version comes out with your patch soon

                            Comment


                            • #29
                              My version finally has it fixed! Thank you dacha!
                              http://download.opensuse.org/reposit...openSUSE_13.1/
                              wine 1.7.23-355.1

                              Comment

                              Working...
                              X