Sorry for crossposting initial message to both lists.
I think the topic may be interesting for both - users
and developers.
Any volunteers to help to translate the documentation
to languages other than English? This is very big job,
so there can be more than one person, working on the
same language.
Among responses to my call for volunteers I got
response from Pedro Restrepo suggesting his help in
Wine localization. See his message below.
Damian Wojslaw requested information on the same topic
on wine-users.
--- Pedro Restrepo <pedrores(a)tutopia.com> wrote:
> Hi Andiry,
>
> First, thank you and thanks to all people working on
> Wine. I am using
> Wine to run Lotus Notes Client on Linux. At the
> moment, we are testing
> it.
>
> I want to help on Wine project. I propose you one
> new work: Wine
> translation to spanish (documentation, installer,
> web site info, etc). I
> think in this work because I think this project is
> necessary for all
> people who need transition tools from Windows to
> Linux and there are
> many people in this situation in SouthAmerica (I am
> from Colombia and I
> am tired of the big payments for software in our
> poor nations).
Currently Wine does not have official documentation in
other languages. Some winelib applications are
localized to other languages.
Documents with highest priority for translation:
* README file
* Wine User Guide
* user-oriented pages on Winehq
Plus, we'll need to keep translations in sync with
original documentation.
Comments, ideas, suggestions?
Andriy
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
Dear wine developers,
I have one question on the development of wine. Long(one or
two years) ago I've heard that Microsoft got some hidden
APIs in their products of various windows, and they use
these APIs in their own applications. I wonder if this is
still a problem on their recent product like windows XP. If
it is, I guess wine will not be able to run such MS
applications which uses hidden APIs. Is this right?
And, is wine designed(or its goal is) to run all
applications(including MS product and non-MS product) that
runs on windows?
Please forgive me if this problem has appeared in the
past. I just joined this list a couple of days ago.
Thank you.
Regards,
--
Zhang Shu
wineinstall fails because wine can't find
regedit.exe.so.
Obviously, the wine source directory does not exist in
path of just created config file.
After the wineistall failure .wine directory with
config file are created. I get the same errors when I
try to run regedit manually, even with using full
path:
$ /prj/wine/programs/regedit/regedit
Could not stat /mnt/fd0 (No such file or directory),
ignoring drive A:
Could not stat /cdrom (No such file or directory),
ignoring drive D:
Warning: could not find wine config [Drive x] entry
for current working directory /mnt/buf/prj/wine;
starting in windows directory.
Warning: /prj/wine/programs/regedit/regedit.exe.so not
accessible from a configured DOS drive
Warning: /prj/wine/programs/regedit/regedit.exe.so not
accessible from a configured DOS drive
/prj/wine/miscemu/wine: cannot find
'/prj/wine/programs/regedit/regedit.exe.so'
$ file /prj/wine/programs/regedit/regedit.exe.so
/prj/wine/programs/regedit/regedit.exe.so: ELF 32-bit
LSB shared object, Intel 80386, version 1, not
stripped
$ ls -l programs/regedit/regedit
lrwxrwxrwx 1 apalamar apalamar 23 May 30
06:53 programs/regedit/regedit ->
../../tools/winewrapper
Andriy
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
On Wed, May 29, 2002 at 12:06:22PM -0700, Andriy Palamarchuk wrote:
> Changelog:
> Added bugzilla responsibilities page.
Hi,
hmm, I'm not 100% sure about this.
- why did you remove bug tracking link ?
- "Talking Back" probably isn't very descriptive. I'd add something like "...
(bugs etc.)"
- that's Albe*r*telli
- Application owners play *an* important role in the bugs handling process.
- why add a whole new talkback.inc ? isn't that a bit overkill ?
- why is <li>Bugs Hunting Guide</li> non-functional text ?
Wow, questions over questions :-)
Good job with bugz_resp.inc, BTW !!
Needless to say I'll add this immediately as soon as these questions
are covered :)
--
Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604 http://mohr.de.tt
--- Dustin Navea <speeddymon(a)yahoo.com> wrote:
> The changes on the lower numbered bugs are done by
> me,
> trying to get some of these old bugs out of he list
> of
> ones to be worked on, if they have been fixed.....
I noticed :-)
Dustin,
thank you for the great work you do. It was long
overdue to clean these old issues.
I have some comments - sometimes you mark as resolved
and ask to reopen if the bug still exists bugs with
very nice reports.
I think this is good approach when you can't check
whether the problem still exists or for some obscure
applications, but many of the bug reports you closed
are short, nice and consious.
I think better approaches with these sort of bug
reports is:
a) try to reproduce yourself - the best approach. Your
confirmation in the bug comments is very important for
developer who may try to fix the issue.
b) if research looks complex - a half a way to solving
a bug, you can add comment, smth like "Needs to be
confirmed".
In both cases bug can be assigned to the component
owner.
c) ask to confirm without resolving the bug
All these approaches insure that bug report won't be
forgotten and this can happen if the bugs are just
marked as "resolved".
Could you try to go through the old bugs you marked as
resolved?
I already started to do this.
I'll leave my comments in the bugs I reviewed.
Thanks,
Andriy
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
In case anyone is interested in a alternitive to winemaker.
Steven
"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson
-----Original Message-----
From: José Fonseca [mailto:[email protected]]
Sent: Friday, May 31, 2002 1:18 PM
To: Steven_Ed4153(a)yahoo.com
Cc: mingw-dvlpr(a)lists.sourceforge.net
Subject: Re: WINE with MFC and C++ DLLs (Was: Info on porting Wine dlls
and programs to Mingw)
On 2002.05.31 17:44 Steven Edwards wrote:
> MFC can and has been built with Wine although M$ licensing regarding
> MFC on non-windows platforms is confusing as it has been changes a few
> times. I think VS6 Before SP3 is OK.
>
This is nice to know. The MFC has been subject of long threads here.
It's
good to know that we can give some alternatives when people ask. (My
general idea is that people who minimally care with cross-compiler (not
to
mention cross-platform) compatibility would never choose to build an
application upon MFC - and that's probably the reason for why MFC has
been
loosing some ground and interest... )
> Also you guys might be insterested in the winemaker.pl script. It
> converts VS makefiles to UNIX makefiles and can configure your win32
> application to be built with winelib+MFC. I may look at adapting it to
> Mingw as part of the port
I once made a small sed script for that, but probably it's not as
complete
as winemaker.pl. But we do have a fairly complete MS Dev Studio
workspace
to Unix Makefiles converter. It's availabable on
http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/software/msds/ and it
will
soon be included on a "mingw-utils" package. Perhaps that might be
interesting for the WINE Lib project too?
Regards,
José Fonseca
Hi,
I'd like to improve debugging support for Wine, and have time to
undertake a larger project. Either I could work on winedbg to match
gdb's features, or I could try to make gdb understand Wine better.
Given the amount of useful frontends for gdb, it seems wiser to go for
the second option. I'd love to be corrected if you think working on
winedbg is a better choice.
Gdb seems to have trouble understanding the way windows processes run
in Wine. If anyone has thought about this, I'd like to know your
opinions on a good solution to this problem.
Furthermore, it seems useful to make gdb parse the .pdb format, or
other debugging information. Winedbg already has a working pdb
parser, which I could port to gdb.
Feel free to push me in the right direction.
--
Tijs van Bakel, ConnecTUX, <tijs(a)connectux.com>
Hi all,
I am using Debian SID with KDE. In KDE, I defined two keyboard layouts
(US and IL). I tried to add Israeli keyboard detection using the
attached patch (layout.diff). When trying to test that patch, however, I
perform the following task:
I type in the command as suggested in the docs (wine --debugmsg
+key,+keyboard >& key.log). Attached are two run attempts. key.log is
with the US keyboard selected, key2.log is with the Hebrew keyboard
selected.
Comparing the two outputs, several things become evident:
1. The Israeli keyboard is not detected. It fails to match even the
non-Hebrew characters (such as the '/' instead of lower case 'q').
It's as if WINE did not notice that a non-English keymap was
installed. On the other hand, there are some differences between
the two runs. What's going on?
2. The dvorak keyboard has 0 mismatches???? I noticed that the code
has some different virtual mapping of the keyboard. I am not aware
that dvorak keyboards generate a different scan code mapping. Am I
missing something here?
3. There does not appear to be any code that detects layout changes
in X11, and sends the apropriate WM_INPUTLANGCHANGE message. I
understood that implementing an event trigered by X layout change
is a difficult matter, but it is highly necessary for my BiDi
support (many programs, including Office, know the current
direction, and have visual representation when it changes. Not
implementing this message may prove to be problematic in that
respect).
I currently don't have the capacity to go after this particular
problem, but if it remains unsolved by the time it becomes crucial
to me, I will. If anyone has any leads on solving this problem,
please let me know. I have entered bug #735 on this issue.
Many thanks for your input,
Shachar
Index: dlls/x11drv/keyboard.c
===================================================================
RCS file: /home/wine/wine/dlls/x11drv/keyboard.c,v
retrieving revision 1.1
diff -u -r1.1 keyboard.c
--- dlls/x11drv/keyboard.c 30 Apr 2002 21:16:39 -0000 1.1
+++ dlls/x11drv/keyboard.c 28 May 2002 13:20:04 -0000
@@ -531,6 +531,15 @@
"zZ","xX","cC","vV","bB","nN","mM","öÖ","çÇ",".:"
};
+/*** Israeli keyboard layout */
+static const char main_key_IL[MAIN_LEN][4] =
+{
+ "`~","1!","2@","3#","4$","5%","6^","7&","8*","9(","0)","-_","=+",
+ "/Q","'W","÷E","øR","àT","èY","åU","ïI","íO","ôP","[{","]}",
+ "ùA","ãS","âD","ëF","òG","éH","çJ","ìK","êL","ó:",",\"","\\|",
+ "æZ","ñX","áC","äV","ðB","îN","öM","ú<","õ>",".?"
+};
+
/*** VNC keyboard layout */
static const WORD main_key_scan_vnc[MAIN_LEN] =
{
@@ -600,6 +609,7 @@
{"Latin American keyboard layout", 28591, &main_key_LA, &main_key_scan_qwerty, &main_key_vkey_qwerty},
{"Lithuanian (Baltic) keyboard layout", 28603, &main_key_LT_B, &main_key_scan_qwerty, &main_key_vkey_qwerty},
{"Turkish keyboard layout", 28599, &main_key_TK, &main_key_scan_qwerty, &main_key_vkey_qwerty},
+ {"Israeli keyboard layout", 28598, &main_key_IL, &main_key_scan_qwerty, &main_key_vkey_qwerty},
{"VNC keyboard layout", 28591, &main_key_vnc, &main_key_scan_vnc, &main_key_vkey_vnc},
{NULL, 0, NULL, NULL, NULL} /* sentinel */
I find tracing a wine problem with wine --debugmsg for large programs
unpractical. Usually you can know about exactly when a program hangs or
behaves badly, but there's no way to activate/deactivate tracing after
program start (afaik...)
Being also a windoze (sigh) programmer, I find very useful some utilities like
winspy that presents a window log in which you can start/stop tracing or
logging of wine messages, system calls and so on, and activate/deactivate
filters on the fly.
This would allow spotting the bug when it arises instead of having tenths or
hundreds of mbyte of logs.
I could implement it as a filter taking input from wine, but I guess it'll
slow downn much apps, having to parse wine output on the fly.
Much better would be an internal implementation....
Some comments about ?
Regards
Max