Hi all,
I've implemented SetClipList and GetClipList in the DirectDraw Clipper, and I'm
wondering how I should go about implementing clipping in DirectDraw's Blt() (if it
isn't already done somewhere).
M$'s documentation isn't too great, so I figured I should ask around. There's a game
one of
On April 2, 2004 4:01 pm, Francois Gouget wrote:
> These options are global, i.e. they are supposed to be effective in
> every makefile makefile generated by winemaker. For this reason they
> used to go in the Make.rules.in file. That way one could later modify
> them in one place instead of having
On Fri, 2 Apr 2004, Bill Medland wrote:
[...]
> What I used toi have was:
> #! /bin/bash
> # Run this script in order to pass the correct arguments to winemaker so that
> # it can set up the build environment
> winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget
> --nomfc -D
On Fri, 2 Apr 2004, Mike Hearn wrote:
> Interesting bug report. Not sure what might cause that, but it does beg
> the question - why aren't you using the native Linux version of StarOffice?
First, I think it's a good test case for wine, so it's good that he does it.
Second, in terms of practical
I haven't been following the winemaker stuff so I don't know whether it is
supposed to be able to handle this (and is broken) or not.
I am having to play with the "build a builtin dll to wrap a linux so" concept
again after a year or so since the last time, as discussed in the Winlib
manual, ch
> Yes but it would still be interesting to know why the statistics where
> wrong rather than just sweep the problem under the rug.
As I told you, you can run the command
./tools/winapi/winapi_extract --pseudo-stub-statistics --no-verbose
--no-progress > ../winapi_stats.txt
and check the file (i
I have a large amount of Windows Development CDsi am wondering if these
would be of any interest to the Development team of Wine
I think that these would become very usefull at developing for Wine as well as
alot of what Windows does is still most of the same. They are Windows NT 4
develop
On Fri, 02 Apr 2004 18:03:05 +0800, Ravi Kumar wrote:
> Hello Sir,
> I am working with wine for some time now. I faced with a problem,
> whenever i am saving a file from Windows version of Staroffice from wine
> it is saved without extension. I think it is a problem with wine, as
> staroffice in w
On Fri, 02 Apr 2004 14:54:30 +, [EMAIL PROTECTED] wrote:
> Well not to start a KDE vs Gnome debate, but Gnome is way behind KDE
> development...
hehe, hint, that's not a good way to "not start a KDE vs GNOME debate"
> it doesn't even support Superkaramba (last I checked).
SuperKaramba is
Hi,
As I'm pretty busy right now and won't have time to work on the various
misc projects I've been working on up until recently for the foreseeable
future, I'm checking them into my personal arch archive for people to
play with and maybe work on themselves.
My archive co-ordinates:
http://navi.
Dimitrie O. Paun wrote:
We'll, I've tried. But before objecting that strongly, hear me
out for a bit. The resulting file is not too big (~2000 lines),
which is on the order of a _small_ control. When I started working
on the listview, it was a 1 line file. Initially I thought
this was a disast
Hello Sir,
I am working with wine for some time now. I faced with a problem,
whenever i am saving a file from Windows version of Staroffice from wine
it is saved without extension. I think it is a problem with wine, as
staroffice in windows stores files with extensions. I am using
wine-20031118 ve
Mike Hearn wrote:
On Thu, 01 Apr 2004 17:39:14 -0500, Dimitrie O. Paun wrote:
Do you think Wine is the way to go for me, or am I
better off writing individual versions and keeping the Windows software
native and then producing QT or GTK versions for *NIX? I'm at a cross-roads
here, since I'll b
I object!
Being one of the people who sometimes works on EMFs, I don't like this
change. A flat namespace in my mind meants that we have one dll's code
in each subdirectory in wine/dlls, not that there's no other
subdirectories under those. It's a bad precedent to set that each dll
can have
> integration. Ideally, we will have a GTK theme and a QT theme
> that just calls the respective toolkit's theming code, so a
> Wine app will look native both in GNOME and in KDE. I 100% agree
> that native integration is paramount, and this is why we will
> have it.
This sounds very good. Maybe
On Fri, 02 Apr 2004 08:31:38 -0500, Dimitrie O. Paun wrote:
> Since you've mentioned the toolkits, a small comment on that.
> Of the two only QT is a serious option for cross-platform development.
> It's a good option, but it's not perfect because your application
> will not be native in GNOME, yo
On Sat, 3 Apr 2004, hatky wrote:
> On Thursday 01 April 2004 22:40, Francois Gouget wrote:
> > Did you find what caused the API count discrepency for winearts.drv and
> > others?
> You said remove them...
Yes but it would still be interesting to know why the statistics where
wrong
On April 2, 2004 5:03 am, Robert van Herk wrote:
> For me, as a user, I am
> always aware of the fact that it is running on a compatibily layer.
>
> If you want something that really looks Linux-like, I'd go with QT
> and/or GTK.
Indeed, currently Wine makes it painfully clear that it's not
native
On Fri, 2004-04-02 at 13:14, Jakob Eriksson wrote:
> Or better yet, lets you use a "native" toolkit like wxWindows. Think
> about it!
Yeah, I'm not a big fan of toolkit abstractions. Stuff like wxWindows
tends not to work well for the same reasons that implementing comctl32
on top of GTK would n
On Fri, 2 Apr 2004, Uwe Bonnes wrote:
[...]
> Mike> WineLib is a great way to do this. Pure WineLib apps will not feel
> Mike> native, because you're using a clone of the win32 widget set -
>
> Is Motif Look and Feel "native", is XAW "native"?
> Winelib is a Library like any other, also wit
> "Mike" == Mike Hearn <[EMAIL PROTECTED]> writes:
Mike> On Thu, 01 Apr 2004 17:39:14 -0500, Dimitrie O. Paun wrote:
>>> Do you think Wine is the way to go for me, or am I better off
>>> writing individual versions and keeping the Windows software native
>>> and then producing
On Thursday 01 April 2004 22:40, Francois Gouget wrote:
> Did you find what caused the API count discrepency for winearts.drv and
> others?
You said remove them...
>
> I checked a bigger dll: user32 and got slightly different results. I
> believe this is because your script worked
On Thu, 01 Apr 2004 17:39:14 -0500, Dimitrie O. Paun wrote:
>> Do you think Wine is the way to go for me, or am I
>> better off writing individual versions and keeping the Windows software
>> native and then producing QT or GTK versions for *NIX? I'm at a cross-roads
>> here, since I'll be dedicati
I am willing to re-write my best Windows software from scratch, but I
insist that the result is native or almost on Linux so there are not any
weird GUI glitches. Do you think Wine is the way to go for me, or am I
better off writing individual versions and keeping the Windows software
native and t
24 matches
Mail list logo
