Problems switching keyboards
Hi,
I have a problem when working with a one keyboard option for language
switching, and would like your help.
I am using the default X11 IL keyboard. This keyboard has two layouts -
US English one and an alternate IL Hebrew one. I have instructed X to
switch between the keyboards when pressing both shifts (the full command
was "setxkbmap -option grp:shift_toggle,grp:switch,grp_led:scroll il",
and it should work on your machine assuming you have the he_IL locale
compiled).
The problem is this. When I run "notepad" with the proper LANG settings
(LANG=he_IL wine --debugmsg +keyboard notepad), I can type English ok. I
can also type Hebrew ok if I don't perform a permanent switch (i.e. -
pressing the right Alt and typing produces Hebrew ok). If I do perform
the permenant switch (pressing both shifts), I get all-caps. After
switching back, I still get allcaps unless I press the caps lock. The
only way to get out of this deadlock is by togelling to Hebrew, pressing
the caps lock, and toggeling back. I get the following messages on toggle:
trace:keyboard:X11DRV_ToUnicode Found keycode 50 (0x32)
trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym
0xfe0a
err:keyboard:X11DRV_ToUnicode Please report: no char for keysym FE0A
(ISO_Prev_Group) :
err:keyboard:X11DRV_ToUnicode (virtKey=10,scanCode=2A,keycode=32,state=2001)
trace:keyboard:X11DRV_KeyEvent Ignoring ISO_Next_Group keyboard event
trace:keyboard:X11DRV_KeyEvent Ignoring ISO_Next_Group keyboard event
trace:keyboard:X11DRV_KeyEvent Ignoring ISO_Prev_Group keyboard event
I am out of my depth here on X. I will also note that I am not using the
currently compiled Israeli keymap, but I have applied the attached patch
(which I cannot seem to debug)
Any help will be apretiated.
Shachar
Index: dlls/x11drv/keyboard.c
===
RCS file: /home/sun/sources/cvs/wine/dlls/x11drv/keyboard.c,v
retrieving revision 1.17
diff -u -r1.17 keyboard.c
--- dlls/x11drv/keyboard.c 7 Jan 2003 20:36:22 - 1.17
+++ dlls/x11drv/keyboard.c 17 Jan 2003 07:10:59 -
@@ -631,10 +631,10 @@
/*** Israeli keyboard layout */
static const char main_key_IL[MAIN_LEN][4] =
{
- "`~;","1!1","2@2","3#3","4$4","5%5","6^6","7&7","8*8","9(9","0)0","-_-","=+=",
- "qQ/","wW'","eE÷","rRø","tTà","yYè","uUå","iIï","oOí","pPô","[{[","]}]",
- "aAù","sSã","dDâ","fFë","gGò","hHé","jJç","kKì","lLê",";:ó","\'\",","\\|\\",
- "zZæ","xXñ","cCá","vVä","bBð","nNî","mMö",",<ú",".>õ","/?."
+
+"`~;~","1!1!","2@2@","3#3#","4$4$","5%5%","6^6^","7&7&","8*8*","9(9(","0)0)","-_-_","=+=+",
+ "qQ/Q","wW'W","eE÷E","rRøR","tTàT","yYèY","uUåU","iIïI","oOíO","pPôP","[{[{","]}]}",
+
+"aAùA","sSãS","dDâD","fFëF","gGòG","hHéH","jJçJ","kKìK","lLêL",";:ó:","\'\",\"","\\|\\|",
+ "zZæZ","xXñX","cCáC","vVäV","bBðB","nNîN","mMöM",",<ú<",".>õ>","/?.?"
};
/*** Greek keyboard layout (contributed by Kriton Kyrimis <[EMAIL PROTECTED]>)
Re: GPL winelib apps ok in tree? (was: Re: Implementation of "start"command)
Dan Kegel wrote: /me gets clue I read the source for cygstart. It's at http://www.neuro.gatech.edu/users/cwilson/cygutils-package/cygutils-1.1.3.tar.bz2 It's also a thin wrapper around ShellExecute, just like my program, but they did put noticable work into that wrapper. The license for Cygstart is GPL, and I'm afraid that may be a problem for merging. Would the leadership care to comment on whether individual directories in wine/programs can be under the GPL? - Dan IANALBICCW1 (I am not a lawyer, but I can consult with one) As far as I can see it, winelib apps that do not export any functionality don't have to be LGPL stricly, without affecting the usability of Wine elsewhere. Personally, I don't see why the DLLs themselves have to be LGPL, as we don't seem to dynamically link with them anywhere, but that is besides the point. Shachar
GPL winelib apps ok in tree? (was: Re: Implementation of "start"command)
Dan Kegel wrote: Sylvain Petreolle wrote: Dan, It was already discussed when Dustin was trying to handle the autorun.inf files. If you want to do this, use cygstart. Could be funny if we merge it. http://www.winehq.com/hypermail/wine-devel/2002/12/0279.html Cygwin is GPL, but the registry-sensing changes have to go directly into ShellExecute, which is LGPL. Emulating them in start is not really an option. /me gets clue I read the source for cygstart. It's at http://www.neuro.gatech.edu/users/cwilson/cygutils-package/cygutils-1.1.3.tar.bz2 It's also a thin wrapper around ShellExecute, just like my program, but they did put noticable work into that wrapper. The license for Cygstart is GPL, and I'm afraid that may be a problem for merging. Would the leadership care to comment on whether individual directories in wine/programs can be under the GPL? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Away for 9 days
Hi folks, I'll be away for 9 days starting tomorrow, skiing. Just in case you wonder whether I've fallen off the net. :) -- Dimi.
Re: Implementation of "start" command
On Thu, 16 Jan 2003, Dan Kegel wrote: > Well, of course Wine should be able to do that, I realized > when I woke up this morning, and I vowed to make it happen > before I went to work today. So here's a quickie implementation > of the start command. Seems to work... comments welcome. Shouldn't this be an internal wcmd command instead? -- Dimi.
Installing IE5.5
I managed to install IE5.5 using the following procedure: 1. Download the IE5.5 base install from MS 2. Set .wine/config as suggested a few days ago (ver=nt40, setupapi=builtin, *=native,builtin) 3. Using the latest Wine (20030115), run the setup tool 4. I, personally, made two sessions. One downloading everything, and the other for installing. 5. Install just the basic IE. No Connection wizard or anything else. 6. When setup finshes (and you get an error in processing the reboot) - wait for all wine instances to exit 7. run wineboot. 8. One of the programs initiated by wineboot fails to run (starts winedbg), just shut it down. 9. That's it - IE works, sortof. I'm hoping this proves useful to everyone. Shachar
Re: Implementation of "start" command
On Thu, 16 Jan 2003, Dan Kegel wrote: > You might think so, but on WindowsMe at least, it's a > separate executable, C:\windows\command\start.exe Indeed, but I'm a bit worried of poluting the Unix command line namespace with such a Windows specific feature... With your command, what's the difference between start prog and prog & ? If I'm using bash, I expect Unix-like behaviour. I only expect Windows behaviour if I use wcmd. So maybe we can keep it as a separate program, but install it in a different path that's searched by default only in wcmd? Say $prefix/wine/bin? Or $prefix/bin/wine? What does FHS say, if anything? -- Dimi.
Problem compiling current CVS on Redhat 8
wine/dlls/comcat/:
comcat_private.h:45: conflicting types for `ClassFactoryImpl'
comcat.h:49: previous declaration of `ClassFactoryImpl'
[more of same error for ther types]
The two struct definitions actually are the same
typedef struct
{
/* IUnknown fields */
ICOM_VFIELD(IClassFactory);
DWORD ref;
} ClassFactoryImpl;
However, the
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
on Redhat 8 rejects the redefinition of the extern class which
follows:
extern ClassFactoryImpl COMCAT_ClassFactory;
Is it neccessary to declare these types two times and/or include both
*.h files?
I also get this:
gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall
-mpreferred-stack-boundary=2 -gstabs+ -fPIC -D__WINESRC__
-D_REENTRANT -o comcat_main.o comcat_main.c
In file included from comcat.h:28,
from comcat_private.h:29,
from comcat_main.c:21:
../../include/wine/obj_base.h:26:2: #error DO NOT INCLUDE DIRECTLY
Martin
RunOnceEx - is it necessary?
RunOnceEx is a key that is not available "by default" in Windows 95 and in Windows NT. Its processing is installed as part of the "IE integration" (shell integration?). When installing IE 5.5 on systype "nt40", these entries are processed by a rundll entry that was added to "runonce", even with wineboot as it is today. The question that needs to be answered is how important it is to add explicit support for it in wineboot? Shachar
(no subject)
timegettime - WinMM.dll funciton
I was trying to debug a DirectX8 simple sample, and found a bug in timegettime. Once this call has been made, my program never exits, probably because of the launched thread? Can anyone take a look at this? I'll happily test it :-) For now I have commented out that call and the pgm exits fine. It is also worth noting that the values I get back dont seem anything like on windows (I know the magnitude is based off when the timer thread gets kicked off, but I am talking about the deltas between two successive calls). Jason
Re: Implementation of "start" command
Sylvain Petreolle wrote: Dan, It was already discussed when Dustin was trying to handle the autorun.inf files. If you want to do this, use cygstart. Could be funny if we merge it. http://www.winehq.com/hypermail/wine-devel/2002/12/0279.html Cygwin is GPL, but the registry-sensing changes have to go directly into ShellExecute, which is LGPL. Emulating them in start is not really an option. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Implementation of "start" command
Dan, It was already discussed when Dustin was trying to handle the autorun.inf files. If you want to do this, use cygstart. Could be funny if we merge it. http://www.winehq.com/hypermail/wine-devel/2002/12/0279.html > BTW, with this implementation, > start notepad > works, and > start wordpad > will probably work if you have the right registry entry (attached), > but > start foo.txt > probably won't... I'll try it out, and maybe improve ShellExecute if > needed. > > Also, start takes a number of switches; I'll try to implement them > soon. > - Dan > > -- > Dan Kegel > http://www.kegel.com > http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 > > REGEDIT4 > > [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App > Paths\WORDPAD.EXE] > @="C:\\Progra~1\\Access~1\\WORDPAD2.EXE" > > = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Implementation of "start" command
It conflicts with vim's view, /bin/view. --- Alexandre Julliard <[EMAIL PROTECTED]> a écrit : > Dan Kegel > 'view' is not installed in /usr/bin, and 'start' shouldn't be > installed there either, it's very likely to conflict with something > else. Since we install the .exe.so in /usr/lib/wine it will be > available from wcmd anyway, and you can run it directly from the Unix > cmdline with 'wine start', which is acceptable IMO. = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
shlwapi/path test compilation error
This test does not compile on Windows. There is a header include problem but changing them to the following solves the problem: #include "windef.h" #include "wtypes.h" #include "shlwapi.h" #include "wininet.h" #include "wine/test.h" #include "wine/unicode.h" However we then have problems with missing declarations on Windows: path.c(58) : warning C4013: 'UrlHashA' undefined; assuming extern returning int path.c(59) : warning C4013: 'UrlHashW' undefined; assuming extern returning int path.c(83) : warning C4013: 'UrlGetPartA' undefined; assuming extern returning int path.c(85) : warning C4013: 'UrlGetPartW' undefined; assuming extern returning int path.c(99) : error C2065: 'URL_PART_HOSTNAME' : undeclared identifier path.c(100) : error C2065: 'URL_PART_PORT' : undeclared identifier path.c(101) : error C2065: 'URL_PART_USERNAME' : undeclared identifier path.c(102) : error C2065: 'URL_PART_PASSWORD' : undeclared identifier path.c(103) : error C2065: 'URL_PART_SCHEME' : undeclared identifier path.c(104) : error C2065: 'URL_PART_QUERY' : undeclared identifier -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
Re: Implementation of "start" command
Dan Kegel <[EMAIL PROTECTED]> writes: > I'd be ok with a wine bin, but I don't think FHS or LSB > define a program called "start", so there's not much chance of clash > if we install 'start'. And 'start' is *very* handy. > > (And we already have a clash ... should we rename programs/view > to not clash with vi's view alias, or is 'view' specified by windows?) 'view' is not installed in /usr/bin, and 'start' shouldn't be installed there either, it's very likely to conflict with something else. Since we install the .exe.so in /usr/lib/wine it will be available from wcmd anyway, and you can run it directly from the Unix cmdline with 'wine start', which is acceptable IMO. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Implementation of "start" command
Dimitrie O. Paun wrote: You might think so, but on WindowsMe at least, it's a separate executable, C:\windows\command\start.exe Indeed, but I'm a bit worried of poluting the Unix command line namespace with such a Windows specific feature... With your command, what's the difference between start prog and prog & Easy: "prog &" doesn't look for the program in App Paths like start does. Also, once I make sure "start datafile" works, that will let you open the file with the appropriate windows app much easier than remembering the path to the program. If I'm using bash, I expect Unix-like behaviour. I only expect Windows behaviour if I use wcmd. So maybe we can keep it as a separate program, but install it in a different path that's searched by default only in wcmd? Say $prefix/wine/bin? Or $prefix/bin/wine? What does FHS say, if anything? I'd be ok with a wine bin, but I don't think FHS or LSB define a program called "start", so there's not much chance of clash if we install 'start'. And 'start' is *very* handy. (And we already have a clash ... should we rename programs/view to not clash with vi's view alias, or is 'view' specified by windows?) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Add check to SetMenuItemInfo
On Thursday 16 January 2003 11:44 am, Mike Hearn wrote: > I think you're right in that a full test case is needed, but I can't > do that (at least, not in C, if Object Pascal is acceptable I might > be able to do so). Why can't it be done in C, out of curiosity? Please forgive me if paying attention to the rest of this thread would have answered this question :( Also: I spent the past 5 years programming Object Pascal. It would be great (for me, at least) if we could make tests in Object Pascal, but it's hard for me to imagine how that could ever be a wine-compatible approach? Is there even an OSS compiler for Object Pascal? Even if there is such a thing, I don't think it would be of much utility without the wine headers being also ported to Object Pascal, a huge task in itself. Just wondering, no flame intended :) -- gmt "If everyone is thinking alike then somebody isn't thinking." --George S. Patton
Re: Add check to SetMenuItemInfo
Unfortunately it seems I was wrong about it stopping the QuickTime menu
corruption... it merely reduces it and changes where it appears. The
changes you gave below don't seem to change that, as far as I can see,
so somehow we're missing a check that Windows does somewhere.
In particular the rather confusing nature of the calls Quicktime makes
doesn't help:
SetMenuItemInfoA( 0x0006025F 0 TRUE [0x0013FD04] -> 44 , MIIM_CHECKMARKS
| MIIM_BITMAP | MIIM_FTYPE , MFT_BITMAP | MFT_MENUBARBREAK |
MFT_OWNERDRAW | MFT_SEPARATOR , 0x0020 , 1310100 , 0x3C0052C4 ,
0x0311 , 0x0202 , 0x , "x H" , 4 , 0x0013FD94 ) -> FALSE
fMask -> MIIM_CHECKMARKS | MIIM_BITMAP | MIIM_FTYPE
fType -> MFT_BITMAP | MFT_MENUBARBREAK | MFT_OWNERDRAW | MFT_SEPARATOR
Which other than being API violations don't make sense anyway, why would
any menu in quicktime need to have a vertical break?
I think you're right in that a full test case is needed, but I can't do
that (at least, not in C, if Object Pascal is acceptable I might be able
to do so).
On Thu, 2003-01-16 at 01:30, Dmitry Timoshkov wrote:
> "Alistair Leslie" <[EMAIL PROTECTED]> wrote:
>
> > Reading about the MENUITEMINFO structure.
> > Take from MSDN
> > The MFT_BITMAP, MFT_SEPARATOR, and MFT_STRING values cannot be combined with
> > one another.
>
> In that case the code which verifies MENUITEMINFO fields could be generalized.
> All existing checks in SetMenuItemInfoA should be removed and something like
> this should be added to SetMenuItemInfo_common:
>
> if (lpmii->fMask & MIIM_TYPE )
> {
> if (lpmii->fType & MFT_BITMAP)
> {
> if (lpmii->fType & (MFT_SEPARATOR | MFT_STRING))
> return FALSE;
> }
> else if (lpmii->fType & MFT_SEPARATOR)
> {
> if (lpmii->fType & (MFT_BITMAP | MFT_STRING))
> return FALSE;
> }
> else if (lpmii->fType & MFT_STRING)
> {
> if (lpmii->fType & (MFT_BITMAP | MFT_SEPARATOR))
> return FALSE;
> }
> }
>
> Mike, could you please try this approach and report whether it helps?
--
Mike Hearn <[EMAIL PROTECTED]>
QinetiQ - Malvern Technology Center
Re: Implementation of "start" command
Dan Kegel wrote: I saw somebody at work type the following commandline in Windows: start notepad blah.c He said "It's the easiest way to bring up a random file in Notepad." Well, of course Wine should be able to do that, I realized when I woke up this morning, and I vowed to make it happen before I went to work today. So here's a quickie implementation of the start command. Seems to work... comments welcome. BTW, with this implementation, start notepad works, and start wordpad will probably work if you have the right registry entry (attached), but start foo.txt probably won't... I'll try it out, and maybe improve ShellExecute if needed. Also, start takes a number of switches; I'll try to implement them soon. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WORDPAD.EXE] @="C:\\Progra~1\\Access~1\\WORDPAD2.EXE"
Re: Implementation of "start" command
Dimitrie O. Paun wrote: On Thu, 16 Jan 2003, Dan Kegel wrote: Well, of course Wine should be able to do that, I realized when I woke up this morning, and I vowed to make it happen before I went to work today. So here's a quickie implementation of the start command. Seems to work... comments welcome. Shouldn't this be an internal wcmd command instead? You might think so, but on WindowsMe at least, it's a separate executable, C:\windows\command\start.exe -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Implementation of "start" command
I saw somebody at work type the following commandline in Windows:
start notepad blah.c
He said "It's the easiest way to bring up a random file in Notepad."
Well, of course Wine should be able to do that, I realized
when I woke up this morning, and I vowed to make it happen
before I went to work today. So here's a quickie implementation
of the start command. Seems to work... comments welcome.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Index: configure.ac
===
RCS file: /home/wine/wine/configure.ac,v
retrieving revision 1.116
diff -d -u -r1.116 configure.ac
--- configure.ac4 Jan 2003 02:52:05 - 1.116
+++ configure.ac16 Jan 2003 16:28:55 -
@@ -1497,6 +1497,7 @@
programs/regtest/Makefile
programs/rpcss/Makefile
programs/rundll32/Makefile
+programs/start/Makefile
programs/uninstaller/Makefile
programs/view/Makefile
programs/wcmd/Makefile
Index: programs/Makefile.in
===
RCS file: /home/wine/wine/programs/Makefile.in,v
retrieving revision 1.33
diff -d -u -r1.33 Makefile.in
--- programs/Makefile.in4 Jan 2003 02:52:05 - 1.33
+++ programs/Makefile.in16 Jan 2003 16:28:55 -
@@ -19,6 +19,7 @@
regtest \
rpcss \
rundll32 \
+ start \
uninstaller \
view \
wcmd \
@@ -43,6 +44,7 @@
regsvr32 \
rpcss \
rundll32 \
+ start \
uninstaller \
wcmd \
wineboot \
@@ -61,6 +63,7 @@
progman \
regedit \
regsvr32 \
+ start \
uninstaller \
wcmd \
wineboot \
@@ -73,6 +76,7 @@
# Symlinks to apps that we want to run from inside the source tree
SYMLINKS = \
+ start.exe \
rpcss.exe \
wcmd.exe \
wineconsole.exe \
--- /dev/null 2002-08-30 16:31:37.0 -0700
+++ programs/start/Makefile.in 2003-01-16 08:20:35.0 -0800
@@ -0,0 +1,13 @@
+TOPSRCDIR = @top_srcdir@
+TOPOBJDIR = ../..
+SRCDIR= @srcdir@
+VPATH = @srcdir@
+MODULE= start.exe
+APPMODE = cui
+IMPORTS = shell32
+
+C_SRCS = start.c
+
+@MAKE_PROG_RULES@
+
+### Dependencies:
--- /dev/null 2002-08-30 16:31:37.0 -0700
+++ programs/start/start.c 2003-01-16 08:23:33.0 -0800
@@ -0,0 +1,59 @@
+/*
+ * Start a program using ShellExecute
+ *
+ * Copyright 2003 Dan Kegel
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include "config.h"
+#include "wine/debug.h"
+
+#include
+#include
+#include
+
+WINE_DEFAULT_DEBUG_CHANNEL(start);
+
+/* Placeholder implementation for now. */
+
+int main(int argc, char *argv[])
+{
+ char *program;
+ char *arguments;
+ HINSTANCE hres;
+
+ if (argc == 1) {
+ printf("Usage: start file-or-program ...\n");
+ exit(0);
+ }
+ if (argc > 3) {
+ WINE_FIXME("More than one argument not implemented");
+ exit(1);
+ }
+
+ program = argv[1];
+ arguments = NULL;
+ if (argc == 3)
+ arguments = argv[2];
+
+ hres = ShellExecute(NULL, "open", program, arguments, NULL, SW_SHOWNORMAL);
+ if (((int)hres) <= 32) {
+ printf("Cannot execute %s %s, error %d\n", program,
+arguments?arguments:"", (int)hres);
+ exit(1);
+ }
+
+exit(0);
+}
Re: WINE in CD-ROM
Dan Kegel wrote: Uwe Bonnes wrote: "Jelcyn" == Jelcyn <[EMAIL PROTECTED]> writes: Jelcyn> Hi, I write a book about editing binary files (Hex Workshop, Jelcyn> Resource Hacker etc.) to polish Helion publishing Jelcyn> (www.helion.pl) Can I add in CD-ROM in my book wine ?? You can redistribute winehq Wine accxording to the GNU License. Here's the text of the license in Polish, in case that helps: http://gnu.org.pl/text/licencja-gnu.html D'oh! Wrong license! And unfortunately, there's no translation of the LGPL into Polish. http://opensource.org/docs/osd-polish.php has a short description of some properties common to both licenses, but it's not really much help. Sorry! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: FHS vs LSB
Vincent Béron wrote: Le mer 15/01/2003 à 22:20, Tom Wickline a écrit : In updating the Packagers Guide I plan to replace FHS with LSB any objections ? FHS = http://www.pathname.com/fhs/ LSB = http://www.linuxbase.org/ Linux is not the only system on which Wine can be built (FreeBSD and Solaris/SunOS comes to mind). The FHS covers various Unices, the LSB covers only Linux. I agree the FHS is the right standard to reference. However, the LSB does not cover only Linux. It's quite likely Solaris could conform to the LSB. The LSB authors are eager to avoid actually requiring a Linux kernel. And if Wine is distributed as a Windows application sometime in the future... :) Heh. Well, it'll be a cold day in Hell before Windows conforms to the FHS :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: WINE in CD-ROM
Uwe Bonnes wrote: "Jelcyn" == Jelcyn <[EMAIL PROTECTED]> writes: Jelcyn> Hi, I write a book about editing binary files (Hex Workshop, Jelcyn> Resource Hacker etc.) to polish Helion publishing Jelcyn> (www.helion.pl) Can I add in CD-ROM in my book wine ?? You can redistribute winehq Wine accxording to the GNU License. Here's the text of the license in Polish, in case that helps: http://gnu.org.pl/text/licencja-gnu.html - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Time
On Thu, 16 Jan 2003 13:33:53 +, you wrote: > > Thanks for being gentle. > > '15:32 +' == '16:32 CET' > > How's that? A clock in Central European Time zone is one hour beyond a clock that displays UTC. > > > > >Whether to post in UTC (as you do) or local time (what you expect) is > >somewhere configurable in agent.ini. It does not affect the time as you > >see in the messages pane, that should be the local time. > > I went looking for this in the help file, and couldn't find it. I > don't want to post in UTC. But before I go jumping to the forte > newsgroup, i just wanted to make sure that the tune call to the wine > system was cool. agent.ini -> message -> GMTDate Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: Time
On Thu, Jan 16, 2003 at 01:33:53PM +, Oliver Sampson wrote: > > Thanks for being gentle. > > '15:32 +' == '16:32 CET' > > How's that? "+0" is UTC, CET is "UTC+1" bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg16556/pgp0.pgp Description: PGP signature
Re: Help wanted: Implementing Wine dlls that need access to X11 commands.
Enrico Horn farmboy1-at-subdimension.com |Wine Mailing Lists| wrote: Hi, On Wednesday 15 January 2003 19:09, Robert North wrote: Robert North 7ownq0k402-at-sneakemail.com |Wine Mailing Lists| wrote: Now, as it turns out, the methods to interrogate a wintab message queue are extremely similar to those to interrogate an X11 message queue. So that's +1 to giving wintab it's own X11 message queue. (Or possibly even one X11 msg queue per tablet context!). A simple X11<->wintab mapping can be implemented, and no additional queue data structs are needed in the wintab implementation. I'm not convinced you can avoid managing an event queue for wintab events; from a quick look at the spec I doubt you can simply map the wintab functions to X11 queue functions. I'm about to have a final look at this, see if there is a clear mapping from X11 functions to wintab. More on this once I've completed my investigations. One mismatch is that wintab uses a fixed size message queue which can be defined as, as opposed to Wine or X11. (I'm assuming wine or X11 are either extremely large queues, or dynamically sized.). I've re-checked the X11 code, and you're right, the only sane way to map X11 events to a wintab queue is by coding an event queue for wintab. Thanks -Rob. Sorry if this seems like a stupid question. Don't think it is, It's the question I've ended up trying to answer when looking at how best to implement wintab. Could you please elaborate what the problems between X11, DirectDraw, OpenGL and accessing X11 functionality are. I am not an expert in either area but like to understand the problem. I'm not the person to answer this, but answering it will help me clarify my own thoughts, and allow people to correct me :-) Well, it seems that wintab now has the concept of drivers, at least for graphics (&sound??) As I currently see it the problem is a question of policy: What should be in the x11drv dll (a private? dll) and what should be in the application facing dlls. Currently, the x11drv dll does not appear export any X11 data stuctures, or handles. Therefore my assumption is that code that interfaces with the X11 system should go in x11drv. This means that x11drv could become horribly bloated with support for specialist dlls like x11drv. Also, as I've mentioned before, x11drv is so important to the functioning of wine, unnecessary tinkering here gould cause nasty regressions. As Alexandre points out, wintab code need not interact much with current x11drv code, and therefore if well designed, will cause minimal regression risk. And yet, DirectDraw, OpenGL dlls do access the X11 system directly. How? By some clever hacks to get X11 display objects from gdi and X11 window handles from Wine window handles. And is this good policy? No. Lionel has pointed out that these dlls are bad examples of how to do it. So, what is the policy? I dunno. Maybe it's use your head? Hope this helps -Rob. Thanks Enrico
Re: Time
On Thu, 16 Jan 2003 12:59:30 +0100, Rein Klazes <[EMAIL PROTECTED]> wrote: >On Wed, 15 Jan 2003 15:33:03 +, you wrote: > >> Howdy, >> Forgive me if this is already known, but I checked the bug list and >> didn't see it. >> >> It would seem that when Agent makes a call to get the Wine system >> time, it's returned the BIOS time, but not the adjusted time zone. >> For example I have set in my KDE environment as the time and as CET >> (which is where I am.) You see that the time that this email was sent >> is actually around 15:32 instead of the real 16:32. > >You are wrong. Thanks for being gentle. '15:32 +' == '16:32 CET' How's that? > >Whether to post in UTC (as you do) or local time (what you expect) is >somewhere configurable in agent.ini. It does not affect the time as you >see in the messages pane, that should be the local time. I went looking for this in the help file, and couldn't find it. I don't want to post in UTC. But before I go jumping to the forte newsgroup, i just wanted to make sure that the tune call to the wine system was cool. Thanks, Oliver Sampson [EMAIL PROTECTED] http://www.oliversampson.com
Re: FHS vs LSB
Vincent Béron wrote: Linux is not the only system on which Wine can be built (FreeBSD and Solaris/SunOS comes to mind). The FHS covers various Unices, the LSB covers only Linux. And if Wine is distributed as a Windows application sometime in the future... :) Vincent Okay, Ill leave it as is FHS just upade to show version 2.2 as the docs now show version 2.1 thanks for the info. Tom
Re: Time
On Wed, 15 Jan 2003 15:33:03 +, you wrote: > Howdy, > Forgive me if this is already known, but I checked the bug list and > didn't see it. > > It would seem that when Agent makes a call to get the Wine system > time, it's returned the BIOS time, but not the adjusted time zone. > For example I have set in my KDE environment as the time and as CET > (which is where I am.) You see that the time that this email was sent > is actually around 15:32 instead of the real 16:32. You are wrong. '15:32 +' == '16:32 CET' Whether to post in UTC (as you do) or local time (what you expect) is somewhere configurable in agent.ini. It does not affect the time as you see in the messages pane, that should be the local time. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: WINE in CD-ROM
Le jeu 16/01/2003 à 03:50, Uwe Bonnes a écrit : > > "Jelcyn" == Jelcyn <[EMAIL PROTECTED]> writes: > > Jelcyn> Hi, I write a book about editing binary files (Hex Workshop, > Jelcyn> Resource Hacker etc.) to polish Helion publishing > Jelcyn> (www.helion.pl) Can I add in CD-ROM in my book wine ?? > > You can redistribute winehq Wine accxording to the GNU License. Take note that it's the LGPL, the Library General Public License, not the GPL. It is included in the Wine archive as COPYING.LIB. Vincent
Re: FHS vs LSB
Le mer 15/01/2003 à 22:20, Tom Wickline a écrit : > In updating the Packagers Guide I plan to replace FHS with LSB > any objections ? > > FHS = http://www.pathname.com/fhs/ > > LSB = http://www.linuxbase.org/ > > Tom > > Linux is not the only system on which Wine can be built (FreeBSD and Solaris/SunOS comes to mind). The FHS covers various Unices, the LSB covers only Linux. And if Wine is distributed as a Windows application sometime in the future... :) Vincent
Re: WINE in CD-ROM
> "Jelcyn" == Jelcyn <[EMAIL PROTECTED]> writes: Jelcyn> Hi, I write a book about editing binary files (Hex Workshop, Jelcyn> Resource Hacker etc.) to polish Helion publishing Jelcyn> (www.helion.pl) Can I add in CD-ROM in my book wine ?? You can redistribute winehq Wine accxording to the GNU License. -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
