http://bugs.winehq.org/show_bug.cgi?id=5115
Summary: Editing inline lines in BeyondCompare2 broken again
Product: Wine
Version: 0.9.12.
Platform: All
URL: http://scootersoftware.com/download.php
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-gui
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: wine-bugzilla(a)thequod.de
After updating to 0.9.12 (debian package from winehq), the inline editing in
the file view window (pressing F2/ENTER on a line) is broken again.
It has been fixed some versions ago.
AFAIK it's broken a bit different now: when pressing F2 or ENTER the focus
goes to the line to be edited and you are able to type into it, BUT: the text
that was already in that line disappears/gets blank.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4701
------- Additional Comments From lav(a)etersoft.ru 2006-22-04 11:12 -------
Really, WINE can use first in alphabetical order font from fonts dir instead
ttf MS Shell Dlg
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3857
------- Additional Comments From dank(a)kegel.com 2006-22-04 11:11 -------
It looks like progress has been made. The installer still
fails, but the errors are much fewer. Here they are:
fixme:msi:ACTION_HandleStandardAction unhandled standard action L"ValidateProductID"
fixme:msi:ACTION_HandleStandardAction unhandled standard action L"SetODBCFolders"
fixme:msi:ACTION_HandleStandardAction unhandled standard action
L"RemoveExistingProducts"
fixme:msi:ACTION_CustomAction msidbCustomActionTypeNoImpersonate not handled
fixme:msi:ACTION_CustomAction msidbCustomActionTypeNoImpersonate not handled
fixme:msi:ACTION_CustomAction msidbCustomActionTypeNoImpersonate not handled
err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603
err:msi:ITERATE_Actions Execution halted, action L"ExecuteAction" returned 1603
fixme:msi:msi_dialog_set_control_condition Unhandled action L"Default"
fixme:msi:msi_dialog_set_control_condition Unhandled action L"Default"
And it still seems to hang.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5104
------- Additional Comments From dank(a)kegel.com 2006-22-04 10:54 -------
Since the stack seemed to implicate wininet,
and the valgrind log seemed to implicate thread exit,
and http://www.winehq.org/pipermail/wine-cvs/2006-April/022380.html,
the only patch in the range April 16 to 20 involving wininet,
happened to also implicate thread exit, I tried reverting it.
This let me download a file normally.
I'm going to email the author of that patch and ask him
to check it...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5114
Summary: suggesting more descriptive desktop window titles
Product: Wine
Version: 0.9.12.
Platform: All
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: christian(a)authmann.de
With Wine 0.9.10 I've been using three different WINEPREFIX'es for three
different wine desktops, each holding its own application (just one each). The
Window title was set by wine to the path of the application, and allowed me to
automatically place those windows where I wanted by using KDE's window specific
settings.
I've upgraded to 0.9.12 now, and it's probably because of the desktop changes in
0.9.11 that the desktop windows are now named just "Wine desktop" (which makes
sense, as the desktop can contain multiple applications now). Unfortunately KWin
cannot distinguish the three desktops any more as they'll all have the same
class & title.
Proposed fix: add the desktop name to the window title, e.g. calling the window
"Wine desktop: $desktop_name".
This would allow me to run my apps with
WINEPREFIX=/my/path/to/prefix_A/ wine explorer /desktop=A myapp.exe
to get a unique window title "Wine desktop: A".
I wouldn't know how to fix this the proper way, so I'll leave the patching to
you. Setting to wine-misc, as I'm not sure if it needs to be fixed in explorer,
x11driver, both of them, or even somewhere else.
I'm using wine 0.9.12 from source, directly from gentoo portage, on x86_64, but
I don't think that matters in this case.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5112
------- Additional Comments From Speeddymon(a)gmail.com 2006-22-04 10:02 -------
What about if you don't change the window metrics? If you just:
1) Install wine from CVS.
2) $ wine explorer (Works. And creates fresh .wine folder too)
-skip several steps-
6) $ wine explorer..
does it fail on the 2nd run?
How about if you run wineprefixcreate before running wine explorer in step 2,
does it fail after all of the steps?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5113
Summary: Wine allows programs to change X resolution, doesn't
fix.
Product: Wine
Version: CVS
Platform: Other
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-loader
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: nospam(a)thenerdshow.com
Wine allows all Windows full-screen programs (games mostly) to change the X
screen resolution. Most do not correctly restore it. This is a problem with
Windows as well as wine. We can fix it in wine, however by running wine with a
wrapper to check screen resolution, like so:
============================ smartwine.sh ====
#/bin/sh
size=$(sudo xrandr | grep \* | cut -b2)
wine $@
#For testing. Purposefully set X to a different resolution.
#xrandr -s 1
newsize=$(sudo xrandr | grep \* | cut -b2)
if [ $size <> $newsize ]; then echo "Wine has changed X resolution. Fixing it..."
fi
xrandr -s $size
=================================
Shouldn't this functionality be built in to wine, however?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5104
------- Additional Comments From dank(a)kegel.com 2006-22-04 09:38 -------
Valgrind 3.1.1 didn't give anything especially illuminating.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5107
xerox_xerox2000(a)yahoo.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rob(a)codeweavers.com
------- Additional Comments From xerox_xerox2000(a)yahoo.co.uk 2006-22-04 09:38 -------
The above mentioned patch can cleanly be reverted in current cvs; after patch
-Rp1 -i patch.diff the text is back in the installer, however the installer
stillstill fails later on with an msi-error 1603. I think that is caused by
another patch, but that's difficult to figure out ... For now added author of
this patch to bug
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5104
dank(a)kegel.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |critical
Summary|Firefox 1.5 terminates after|Firefox 1.5 unstable
|"epoll_ctl: operation not |
|permitted" |
------- Additional Comments From dank(a)kegel.com 2006-22-04 09:02 -------
OK, Firefox has crashed four times this morning
with cvs as of last night. This problem was probably
introduced in the last four days.
It's so bad I had to switch back to Linux firefox.
Most of the time I don't get anything in the log,
but the most recent time I got a stack dump (short, so I'll paste it here):
Backtrace:
=>1 0x7d18a8c0 HTTP_HttpSendRequestW+0xeb7(lpwhr=0x7a5bd140, lpszHeaders=0x0,
dwHeaderLength=0x0, lpOptional=0x7a54e95a, dwOptionalLength=0x1,
dwContentLength=0x1, bEndRequest=0x1)
[/home/dank/wine/dlls/wininet/../../include/winbase.h:2070] in wininet (0x7d18a8c0)
2 0x7d18c014 HttpSendRequestW+0x1c4(hHttpRequest=0x6, lpszHeaders=0x0,
dwHeaderLength=0x0, lpOptional=0x7a54e95a, dwOptionalLength=0x1)
[/home/dank/wine/dlls/wininet/http.c:1897] in wininet (0x7d18c014)
3 0x7d18c108 HttpSendRequestA+0xca(hHttpRequest=0x6, lpszHeaders=0x0,
dwHeaderLength=0x0, lpOptional=0x7a54e95a, dwOptionalLength=0x1)
[/home/dank/wine/dlls/wininet/http.c:1929] in wininet (0x7d18c108)
4 0x300c6575 (0x300c6575)
5 0x300b22d5 (0x300b22d5)
6 0x300b26b6 (0x300b26b6)
7 0x300b27f6 (0x300b27f6)
8 0x00000000 (0x00000000)
0x7d18a8c0 HTTP_HttpSendRequestW+0xeb7
[/home/dank/wine/dlls/wininet/../../include/winbase.h:2070] in wininet: cmpw
$0,0x0(%ecx)
2070 while (*s) s++;
I guess I'll try valgrind now.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.