http://bugs.winehq.org/show_bug.cgi?id=9012
Anastasius Focht <focht(a)gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andrew(a)mleczko.net
--- Comment #27 from Anastasius Focht <focht(a)gmx.net> 2012-04-24 15:21:25 CDT ---
*** Bug 18284 has been marked as a duplicate of this bug. ***
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9127
--- Comment #43 from Austin English <austinenglish(a)gmail.com> 2012-04-24 13:53:46 CDT ---
(In reply to comment #42)
> (In reply to comment #41)
> You may try to get rid of gstreamer usage. It fixed problems with Steins;Gate
> for me.
> 1. Compile wine-1.4 from sources without gstreamer support (./configure
> --without-gstreamer) or install older wine-1.2 (gstreamer was not implemented
> here)
Or just disable winegstreamer.dll.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=9127
--- Comment #42 from gouriote <gouriote(a)trashmail.ws> 2012-04-24 13:07:00 CDT ---
(In reply to comment #41)
You may try to get rid of gstreamer usage. It fixed problems with Steins;Gate
for me.
1. Compile wine-1.4 from sources without gstreamer support (./configure
--without-gstreamer) or install older wine-1.2 (gstreamer was not implemented
here)
2. Use native quartz, devenum.
3. Install ffdshow (enable mpeg1, mpeg2 in video decoder options)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3548
--- Comment #44 from Thomas Spear <Speeddymon(a)gmail.com> 2012-04-24 05:10:03 CDT ---
Rather, I dislike that it defaults to being in .wine under my home directory.
I'd be OK with it being inside a hidden file, because it's a single file,
rather than a whole folder that some tools (grep -R, find, etc) would then
search through.
Also, if the filesystem is virtualized from inside of a single file, then the
user's desktop can be an actual folder and wine can track links to that between
it and the real ~/Desktop. In addition it solves a lot of issues with multiple
users in the linux system wanting to share a single prefix (could move the
prefix out of ~/.wine and into /home/.wine or /home/wine as well as allowing
one to have and manage multiple prefixes from within winecfg could become
easier)...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3548
--- Comment #43 from Thomas Spear <Speeddymon(a)gmail.com> 2012-04-24 04:55:25 CDT ---
(In reply to comment #42)
> I like the virtualized filesystem idea, but its probably not practical for wine
> itself to implement, moreso something for a separate project (winetricks?)
Thinking further about the virtualized filesystem idea, it should, in theory,
be possible to virtualize the filesystem without needing a fuse driver, if the
user were to setup a single file that were to hold the filesystem, sort of like
a VHD or an ISO. I like the ISO idea better, but perhaps something that's not
associated with a read-only media would be more appropriate.
That way it could be mounted with the loopback driver already in the kernel and
reads/writes would just take place to the mount point. It would make managing
things easier because the user could create an fstab-like file for wine to read
(or just do it in winecfg) to specify the mount point and path to the file
containing wine's filesystem -- That's the one thing I've always disliked about
wine was having the filesystem default to being under my home directory.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3548
--- Comment #42 from Thomas Spear <Speeddymon(a)gmail.com> 2012-04-24 04:46:43 CDT ---
(In reply to comment #29)
> (In reply to comment #28)
> > Perhaps we could move the .lnk's from the 'user' desktop to the 'public'
> > desktop, which would keep it off the 'real' desktop, but also allow keeping
> > track of it to remove the .desktop for later removal?
>
> The application tells shell32 to write the .lnk file to a specific
> C:\path\to\file.lnk location and remembers that location. Any attempt to move
> or rename the .lnk after that - even to the other desktop - loses that file and
> stops the application from deleting it on uninstall.
>
> The only thing I can think of that would fix this is to virtualize the
> filesystem - eg. use a FUSE module that merges
> ~/.wine/drive_c/users/user/Desktop with ~/Desktop when reading, but write .lnk
> files to ~/.wine/drive_c/users/user/Desktop and everything else to ~/Desktop.
I like the virtualized filesystem idea, but its probably not practical for wine
itself to implement, moreso something for a separate project (winetricks?)
As for the link tracking, the same thing happens in Windows when one moves the
.lnk file from their personal start menu folder or desktop to the public one.
IMHO, it should just be considered expected behaviour for the links to be
manually removed from the user's desktop when an app is uninstalled. That or do
a forced check of the user's desktop for a .desktop file in the wine
uninstaller tool, though I think the manual removal idea is better, personally.
As far as your comment on GNOME and KDE dropping support for XDG standards,
that's just sad. They used to be the pinnacle of openness, and the decreasing
support for those standards just shows the winds of change are not always good.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3548
--- Comment #41 from Damjan Jovanovic <damjan.jov(a)gmail.com> 2012-04-24 04:36:08 CDT ---
(In reply to comment #40)
> Still present in Notepad++ 6.1.1 using Fedora 16 x86_64 with wine 1.5.1.
> I'm not sure if any ideas on this have changed from Gnome3/Unity/OtherDE? with
> new method of not showing the files. Is this a large issue any more (for
> certain D.E.)? Has this move changed ideology for .lnk files being a viewable
> issue?
1. When the .lnk file is on the invisible desktop, we add a .desktop file on
the visible desktop.
2. When the .lnk file is on the visible desktop, we add a custom thumbnail to
that .lnk file.
Point 1 already works. Point 2 is difficult, since each desktop environment has
its own way of adding custom thumbnails to files.
I wonder if the Portland project could add a desktop-independent tool for
adding custom thumbnails to arbitrary files?
Oh and Gnome 3 / KDE 4 have dropped support for so many XDG standards that I
have even less hope for this working properly everywhere nowdays.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=3548
--- Comment #40 from gat <gatlinsullivan(a)yahoo.com> 2012-04-24 03:42:54 CDT ---
Still present in Notepad++ 6.1.1 using Fedora 16 x86_64 with wine 1.5.1.
I'm not sure if any ideas on this have changed from Gnome3/Unity/OtherDE? with
new method of not showing the files. Is this a large issue any more (for
certain D.E.)? Has this move changed ideology for .lnk files being a viewable
issue?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=2784
Maxim Velesyuk <loz.accs(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |loz.accs(a)gmail.com
--- Comment #38 from Maxim Velesyuk <loz.accs(a)gmail.com> 2012-04-24 01:45:00 CDT ---
I also have this bug on gentoo-x64 and wine-1.5.1, Red Alert 2 significantly
slows when mouse moves.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=2784
shawnlanika(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |shawnlanika(a)gmail.com
--- Comment #37 from shawnlanika(a)gmail.com 2012-04-23 22:21:03 CDT ---
Bug isn't fixed for me in 1.5.0. Game runs at full speed, but when I move the
mouse it slows down tremendously!
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.