Anything wrong with this patch Alexandre?
On Fri, 2003-04-04 at 21:00, Mike Hearn wrote:
Hi,
pkgconfig as you may know is a replacement for the various foo-config programs that are usually used to retrieve compiler flags etc for packages. Here's a patch to add a .pc file to wine, this will hopefully help the Mono guys (they said it'd be nice to have)
ChangeLog: Add a pkgconfig file
thanks -mike
Mike Hearn mike@theoretic.com writes:
Anything wrong with this patch Alexandre?
Not really, but I'm not convinced it's that useful. You can't use wine by simply adding -lwine anyway; I think a better approach is to flesh out the autoconf macros we already install to make it easier to integrate Wine in a configure script. I don't think pkgconfig is going to be enough for that.
On April 12, 2003 03:51 pm, Alexandre Julliard wrote:
[...] You can't use wine by simply adding -lwine anyway;
BTW, will we ever be able to do so? Any hint on what it would take? As Wine matures, it seems more and more people are trying to do that, just to find out they have to turn their Unix app into a Winelib app. Not catastrophic, but it would be so much nicer if they didn't have to.
"Dimitrie O. Paun" dpaun@rogers.com writes:
BTW, will we ever be able to do so? Any hint on what it would take? As Wine matures, it seems more and more people are trying to do that, just to find out they have to turn their Unix app into a Winelib app. Not catastrophic, but it would be so much nicer if they didn't have to.
That depends a bit on what you are trying to achieve. But in any case simply linking against libwine can't work since libwine doesn't export the Windows APIs; so you have to link against the Wine dlls one way or another. To build a regular Unix app this would mean making the Wine dlls normal ELF libraries, which would break a number of things; so you would probably need a separate set of "crippled" Wine dlls where features that can't be done in ELF are disabled or hacked around.
On 13 Apr 2003, Alexandre Julliard wrote:
That depends a bit on what you are trying to achieve. But in any case simply linking against libwine can't work since libwine doesn't export the Windows APIs; so you have to link against the Wine dlls one way or another. To build a regular Unix app this would mean making the Wine dlls normal ELF libraries, which would break a number of things; so you would probably need a separate set of "crippled" Wine dlls where features that can't be done in ELF are disabled or hacked around.
Many people need to link against very simple DLLs that are simple shared libs, no fancy PE features. What we probably need is a tool of sorts that export some sort of ELF import libs. That is, given a regular PE DLL or a Wine ELF DLL, it exports as much as it can into a ELF so library that the program can link to. Of course, the program will also have to link with -lwine for it to work.
Does this sound reasonable/workable? BTW, I'm not very familiar with the various formats (ELF/PE), what would we be missing if we are to export to ELF? Resources come to mind, but I think we can export some sort of symbol to ELF that our Wine code would understand, so they may not be a problem.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Many people need to link against very simple DLLs that are simple shared libs, no fancy PE features. What we probably need is a tool of sorts that export some sort of ELF import libs. That is, given a regular PE DLL or a Wine ELF DLL, it exports as much as it can into a ELF so library that the program can link to. Of course, the program will also have to link with -lwine for it to work.
Does this sound reasonable/workable?
It will be fairly complex, and will probably add a lot of different constraints, I'm not sure it would really be an improvement over winebuild. If you want a really transparent solution then it should most likely be done directly at the linker/ld.so level.
BTW, I'm not very familiar with the various formats (ELF/PE), what would we be missing if we are to export to ELF? Resources come to mind, but I think we can export some sort of symbol to ELF that our Wine code would understand, so they may not be a problem.
They will still be a problem, you'll need to redo the resource functions to deal with that. Other problems include at least ordinal exports, separate dll namespaces, and initialization order. Then of course you have all the binary compatibility problems with module handles that don't point to the right structures etc.
If you really want to provide a seamless Unix source environment, you pretty much need to give up on full binary compatibility, and do something more like what TWIN was doing. But I don't think that's where we want to go.
On 13 Apr 2003, Alexandre Julliard wrote:
It will be fairly complex, and will probably add a lot of different constraints, I'm not sure it would really be an improvement over winebuild. If you want a really transparent solution then it should most likely be done directly at the linker/ld.so level.
Yes, it sounds about right. Of course, the ultimate goal would be to be able to use Wine by doing -lwine. Now, an intermediate step toward this goal would be to allow the program to remain a Unix app (rather than a Winelib app), and require a more complex linking process. Which is fairly close to what winebuild is doing currently.
But we are not there. The idea with this additional step would be to factor all this ugliness into one spot (that is, linking), so we can drop it altogether when the required support appears in the linker.
Thinking more about it, the current winebuild setup is very close to this. So what's bothering me? I guess asking people to transform their apps to a Winelib app if they want to use Winelib.
For CUI apps, there is no difference between the current winebuild process, and what I'm proposing (a Unix app with a non-standard link). I think (please correct me if I'm wrong).
However, for GUI apps, people need to provide the WinMain entry point instead of main. Maybe we can export some sort of init function, so that they can keep their main(), and simply call a wine_init(). Doing so, we maintain the appearance of a Unix app. Of course, the limitation would be that no Wine-related funtionality can be called before the wine_init() call. So no more static C++ initializers, etc. Would this be doable?
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Thinking more about it, the current winebuild setup is very close to this. So what's bothering me? I guess asking people to transform their apps to a Winelib app if they want to use Winelib.
The only real problem is that Winelib apps are shared libraries and not executables; but this could probably be fixed with a good amount of linker magic. The rest is just a matter of wrapping the winebuild incantations into an easier to use front end, which is basically what you started doing with winewrap.
On 14 Apr 2003, Alexandre Julliard wrote:
The only real problem is that Winelib apps are shared libraries and not executables; but this could probably be fixed with a good amount of linker magic. The rest is just a matter of wrapping the winebuild incantations into an easier to use front end, which is basically what you started doing with winewrap.
Right :) This is where I'm driving at. Unfortunately, I know very little about the linking inner workings for me to attempt to solve this. I'm just trying to understand better the thinking on this issue, and what future plans we have for it. Maybe if we can break it down to smaller tasks, we can start implementing bits and pieces.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Right :) This is where I'm driving at. Unfortunately, I know very little about the linking inner workings for me to attempt to solve this. I'm just trying to understand better the thinking on this issue, and what future plans we have for it. Maybe if we can break it down to smaller tasks, we can start implementing bits and pieces.
I think this should wait for dll separation. It will be a lot easier to play with the linking process once all dlls get linked the same way.
On 14 Apr 2003, Alexandre Julliard wrote:
I think this should wait for dll separation. It will be a lot easier to play with the linking process once all dlls get linked the same way.
Of course, I'm not advocating we should do it now. Speaking of DLL separation, it's listed as item E2 in the TODO: http://www.dssd.ca/wine/Wine-0.9-TODO.html
Last I've heard from you, it was on hold, but I've noticed Eric is working on it. Any change in status?
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Of course, I'm not advocating we should do it now. Speaking of DLL separation, it's listed as item E2 in the TODO: http://www.dssd.ca/wine/Wine-0.9-TODO.html
Last I've heard from you, it was on hold, but I've noticed Eric is working on it. Any change in status?
Yes, Eric and I have been working on it, so I guess you could change the status to "being worked on".
On Mon, 2003-04-14 at 04:45, Alexandre Julliard wrote:
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Many people need to link against very simple DLLs that are simple shared libs, no fancy PE features.
In fact, for a lot of uses I believe simply exporting LoadLibrary and GetProcAddress would be enough - it's often for things like codecs with few entry points. Doesn't need to be a part of the traditional build process.
It will be fairly complex, and will probably add a lot of different constraints, I'm not sure it would really be an improvement over winebuild. If you want a really transparent solution then it should most likely be done directly at the linker/ld.so level.
This could be doable.
BTW, I'm not very familiar with the various formats (ELF/PE), what would we be missing if we are to export to ELF? Resources come to mind, but I think we can export some sort of symbol to ELF that our Wine code would understand, so they may not be a problem.
ELF is actually very flexible, resources could be done in the same way they are in Windows just by adding a new section then reading it from itself using libbfd.
They will still be a problem, you'll need to redo the resource functions to deal with that. Other problems include at least ordinal exports
Offsets in the export table? Symbol mangling?
, separate dll namespaces,
Windows style symbol scoping will have to be added to glibc at some point anyway, we've looked into this quite extensively for autopackage. Solaris style grouping semantics are the mostly likely candidate, and I think it's reasonably close to DLL namespacing. If not, then again symbol mangling perhaps or an abuse of symbol versioning.
and initialization order. Then of course you have all the binary compatibility problems with module handles that don't point to the right structures etc.
If you really want to provide a seamless Unix source environment, you pretty much need to give up on full binary compatibility, and do something more like what TWIN was doing. But I don't think that's where we want to go.
TWIN?
Full binary compatability is far more useful agreed, but source compatability isn't that important for a lot of projects, in fact they usually dynamically load the DLLs anyway for codecs or .NET P/Invoke.
You don't need to be able to do -lgdi32, just -lwine then being able to load DLLs in the usual wine fashion and get entry points by name would be good enough for now, it'd certainly be enough for say mplayer and possibly mono as well.
Mike Hearn m.hearn@signal.qinetiq.com writes:
In fact, for a lot of uses I believe simply exporting LoadLibrary and GetProcAddress would be enough - it's often for things like codecs with few entry points. Doesn't need to be a part of the traditional build process.
For that, using Wine is a bit overkill; all you need is a PE loader and some glue code depending on what dll you are trying to load. You are much better off copying a few bits of Wine source into your app than trying to make use of the unmodified Wine dlls. That's basically the mplayer approach.
On 14 Apr 2003, Alexandre Julliard wrote:
For that, using Wine is a bit overkill; all you need is a PE loader and some glue code depending on what dll you are trying to load. You are much better off copying a few bits of Wine source into your app than trying to make use of the unmodified Wine dlls. That's basically the mplayer approach.
But you see, the interface to the DLL may be small enough that LoadLibrary would do just fine, but most of the time the DLL itself will need registry support, and so on, and so forth.
If done right, -lwine should not be too bad, in that you should pay for what you use. Sort of like lazy paging of libraries. Our big problem is the server, which is rather heavy if you don't make use of any of its features. But than again, I'd think the vast majority of useage patterns will require (sooner, rather than later) more features than a PE loader can provide. Not to mention the convenience to simply link to wine, rather than rip code out.
To begin I don't have much experience with all this wine linking stuff and the internal stuff.
I think it is quite important that some way of linking with wine dlls gets possible without making a winelib binary. Today I heard something more that would make it more needed than before. Someone from the mono project is now working on turning wine into "normal" unix libraries to make it possible to directly link wine to mono. This would eliminate monostub, mono's wine launcher. The mono project would support this library.
To sum it up find a way to easily link with wine to prevent another wine fork...
Roderick Colenbrander
On Monday 14 April 2003 22:43, Dimitrie O. Paun wrote:
On 14 Apr 2003, Alexandre Julliard wrote:
For that, using Wine is a bit overkill; all you need is a PE loader and some glue code depending on what dll you are trying to load. You are much better off copying a few bits of Wine source into your app than trying to make use of the unmodified Wine dlls. That's basically the mplayer approach.
But you see, the interface to the DLL may be small enough that LoadLibrary would do just fine, but most of the time the DLL itself will need registry support, and so on, and so forth.
If done right, -lwine should not be too bad, in that you should pay for what you use. Sort of like lazy paging of libraries. Our big problem is the server, which is rather heavy if you don't make use of any of its features. But than again, I'd think the vast majority of useage patterns will require (sooner, rather than later) more features than a PE loader can provide. Not to mention the convenience to simply link to wine, rather than rip code out.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
But you see, the interface to the DLL may be small enough that LoadLibrary would do just fine, but most of the time the DLL itself will need registry support, and so on, and so forth.
Of course that depends on what the dll does. But for the common case of things like codecs, you don't want to drag Wine into it. Even if the dll is calling a bunch of API functions, you want to stub these to do whatever makes sense for your app; you don't want to have to provide a config file, DOS drives, registry files, the wineserver, the X11 driver, etc. etc.
If the dll does require a lot of Windows features then yes you should use Wine, but then I think it's reasonable to build a Winelib app. Even if we somehow change the linking process so that you can simply add -lwine, you will still end up with a Winelib app, and have to deal with everything this implies. And frankly at that point the exact command line you have to use to link is a minor detail.
The problem with saying that one should be able to use Wine simply by adding -lwine is that "use Wine" means something different for each case. And what people really want is that -lwine should allow them to use the APIs their specific case needs, and not bother them with any other part of Wine; so there's simply no way to offer a general solution for that.
On April 14, 2003 05:27 pm, Alexandre Julliard wrote:
Of course that depends on what the dll does. But for the common case of things like codecs, you don't want to drag Wine into it. Even if the dll is calling a bunch of API functions, you want to stub these to do whatever makes sense for your app; you don't want to have to provide a config file, DOS drives, registry files, the wineserver, the X11 driver, etc. etc.
Stubbing stuff out, and copy&pasting bits of Wine code may be a bit extreme. Yes, it will give the best performance, but it's very inconvenient, and it's very hard to do. I would hope that we can make Wine good enough that linking with it will not require most users to go to that extent.
Moreover, the problem is that in Windows even codecs or SANE driver, or what have you end up needing GUI support, registry, etc. You may think you don't need any of that stuff, and start copying code, and slowly but surely you go down a very dangerous path, and before you know it you end up copying most of Wine.
My hope is that we can lazily initialize enough things such that it's feasible to build a Winelib app even for the simplest things. But that requires that (1) building Winelib apps is easy, and (2) if you don't use expensive features, you don't pay for them.
So let's see what we can do for the examples you give above: - provide a config file: should be merged into the registry soon - DOS drives, registry files: we should have good enough defaults to be able to startup and operate without a registry - X11 driver: lazy load, if apps don't access graphical stuff, there's no need to even initialize this bugger - wineserver: that's the tricky one. I'm not sure lazy initialization would do anything here, but in the future we may provide a dummy version of sorts where the Winelib user knows there is only one process to worry about. Maybe even start it automatically only if there are more than one process to worry about :)
Hey, I don't know how feasible this ideas are, but it's probably worth it to try to make Winelib more easily useable as a library rather than encourage people to hack some bits out of it. I think many of the changes are beneficial to Wine in any event. That's why I think tasking out a long time goal may be a good thing as some of the tasks may bubble out anyway (like the configuration work around winecfg).
- wineserver: that's the tricky one. I'm not sure lazy initialization would do anything here, but in the future we may provide a dummy version of sorts where the Winelib user knows there is only one process to worry about. Maybe even start it automatically only if there are more than one process to worry about :)
Hey, I don't know how feasible this ideas are, but it's probably worth it to try to make Winelib more easily useable as a library rather than encourage people to hack some bits out of it. I think many of the changes are beneficial to Wine in any event. That's why I think tasking out a long time goal may be a good thing as some of the tasks may bubble out anyway (like the configuration work around winecfg).
I know some Linux distros (RHAT) set wineserver to allways run a a background process via xinetd or other rc.d scripts so doesnt this method take care of part of the problem of wineserver initialization? I mean if the system is going to need wine for software the user is going to run most or all the time then shouldnt wineserver always run?
Thanks Steveen
Le lun 14/04/2003 à 21:40, Steven Edwards a écrit :
I know some Linux distros (RHAT) set wineserver to allways run a a background process via xinetd or other rc.d scripts so doesnt this method take care of part of the problem of wineserver initialization?
Actually, the only thing RH does with Wine and rc.d scripts is to enable the execution of Windows excutables through the binfmt_misc module, ie you can then execute a Windows executable the same ways as a normal ELF or script executable (or Java or whatever else you configured binfmt_misc to handle).
The wineserver starts the same way as on other distros/OS, ie probably by wine itself if it is not already running (or can't be connected to).
Vincent
"Dimitrie O. Paun" dpaun@rogers.com writes:
Moreover, the problem is that in Windows even codecs or SANE driver, or what have you end up needing GUI support, registry, etc. You may think you don't need any of that stuff, and start copying code, and slowly but surely you go down a very dangerous path, and before you know it you end up copying most of Wine.
Even if you need some GUI support, or some registry calls, you most likely don't want to use the Wine variant of them. You want to add stubs to make the calls integrate with your apps; you want controls drawn by the dll to look like your other controls, you want settings to be stored in your app config file not in some mysterious system.reg file, you don't want paths to contain drive letters, etc.
Even if you may end up implementing a whole bunch of Windows functionality, IMO you will implement it in a completely different way.
My hope is that we can lazily initialize enough things such that it's feasible to build a Winelib app even for the simplest things. But that requires that (1) building Winelib apps is easy, and (2) if you don't use expensive features, you don't pay for them.
I don't think that's feasible, at least not without a major change in our development philosophy, which IMO would impact binary compatibility. If you want a lightweight environment, and good Unix integration, what you want is to write a wrapper as thin as possible, that calls to Unix immediately. For instance an open file dialog should resolve to a Qt or Gtk dialog. In Wine we want just the opposite: we want high level features to use the low level features, and call to Unix as late as possible. So the open file dialog calls comctl32, which calls user32, which calls x11drv, which calls the registry, which calls the server; and you end up pulling in most of Wine for what seems to be a trivial function.
The fact is that Wine is a large, mostly self-contained environment, and this is not going to change even if you disguise it as a normal Unix library. And the problem if you do that is that people will expect it to behave like any other library, and it simply won't.
Sure, it would be nice to have a set of small independent modules that you can mix and match with your app to get just the amount of Windows functionality that you require. But IMO that's a different project.
On 14 Apr 2003, Alexandre Julliard wrote:
Even if you need some GUI support, or some registry calls, you most likely don't want to use the Wine variant of them. You want to add stubs to make the calls integrate with your apps; you want controls drawn by the dll to look like your other controls, you want settings to be stored in your app config file not in some mysterious system.reg file, you don't want paths to contain drive letters, etc.
Yes, you are describing an ideal world, but it looks very unlikely to happen. In fact, it's similar to the QT vs. GTK debate. Fact of the matter is, there's no unifying the two, there are here to stay as separate thing, even if people try to build one on top of the other. And the scenario you present is also very unlikely to happen -- a thing that should take days will take weeks or month to implement for little gain. Yeah, you'll get a dialog box that looks a bit different, so what? Availability always beats perfection. People would love for example to have Photoshop plugins work in Gimp now with slightly differnt dialogs, than to wait month/years for someone to create a perfectly looking GTK dialog on top on some Windows code.
In a way, Wine is just another toolkit (from a user point of view). The integration work will be through things like freestandards.org, RedHat BlueCurve, etc: http://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00001.html
In fact, once we do Wine 1.0, people may decide to build a desktop environment around it. I think this is very exciting possibility, and I think we can even beat KDE and GNOME despite their big lead. I don't even think it's that much work (we need a panel, a file browser, and a control panel), we will have a lot more apps than they do, and we'll have far better binary compatibility.
At that point you'll have GNOME, KDE, WIND (WINe Desktop :)). Do you think app writers will abstract their stuff so they have perfect integration with each and every one of them? They don't do it now for GNOME and KDE (when there is an incentive to do so, in the future thinks like BlueCurve will remove big part of that incentive).
I don't think that's feasible, at least not without a major change in our development philosophy, which IMO would impact binary compatibility. If you want a lightweight environment, and good Unix integration, what you want is to write a wrapper as thin as possible, that calls to Unix immediately. For instance an open file dialog should resolve to a Qt or Gtk dialog. In Wine we want just the opposite: we want high level features to use the low level features, and call to Unix as late as possible. So the open file dialog calls comctl32, which calls user32, which calls x11drv, which calls the registry, which calls the server; and you end up pulling in most of Wine for what seems to be a trivial function.
Well, but his can happen within the Wine framework. If anyone wants to put in the effort to do such a thing (which I doubt, but hey!), they can create another implementation of the comctl32 (which will work even better when we move the standard controls in there, like XP). Then you can use one or the other.
But I'm afraid this approach is hard, and it will never work reliably due to very complicated Windows controls (custom draw, owner draw, etc).
The more workable solution would be to make our controls theamable (like XP), and have styles that try to render them in the currently selected style (say BlueCurve). The users shouldn't care what toolkit the app uses, just as it should not care or see what language the app has been written into.
Availability always beats perfection. People would love for example to have Photoshop plugins work in Gimp now with slightly differnt dialogs, than to wait month/years for someone to create a perfectly looking GTK dialog on top on some Windows code.
Indeed - at the moment the only way to do such a thing would be to use IPC. For apps that wanted to redirect API calls, could they not use the windows hooks mechanism?
In a way, Wine is just another toolkit (from a user point of view). The integration work will be through things like freestandards.org, RedHat BlueCurve, etc: http://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00001.html
Already happening with EWMH, menu specs and at some point notification area icons.
In fact, once we do Wine 1.0, people may decide to build a desktop environment around it. I think this is very exciting possibility, and I think we can even beat KDE and GNOME despite their big lead. I don't even think it's that much work (we need a panel, a file browser, and a control panel), we will have a lot more apps than they do, and we'll have far better binary compatibility.
Eurgh. My god. Please tell me you're kidding or have been drinking. We put so much work into Wine to run the applications, not because we think Windows is perfect and should be copied to the last detail. Anyway, there is already XPde which is copying XP to the last pixel.
At that point you'll have GNOME, KDE, WIND (WINe Desktop :)).
Well we already have GNOME, KDE, ROX, Enlightenment, as well as a seemingly infinite number of "lite" window managers.
I don't think that's feasible, at least not without a major change in our development philosophy, which IMO would impact binary compatibility. If you want a lightweight environment, and good Unix integration, what you want is to write a wrapper as thin as possible, that calls to Unix immediately.
Well, good Unix integration is somewhat relative - having a Photoshop plugin work in the GIMP, using my WM and being able to read my Linux drives *at all* would be great integration from my perspective, using drive letters and win32 style open dialog boxes is an extremely trivial annoyance really. And as we're much further along with the complete-environment windows integration, it makes sense to use that, even if the results would be sub-optimal.
And of course we're ignoring that despite its lack of elegance at times, people already are integrating with Wine, but they're using IPC hacks, or ripping parts of the loader, or writing stub winelib apps, which is even less clean.
Well anyway, this is an interesting discussion to have, but I'm not able to write any code for even allowing GetProcAddress-level integration at this time, so take my views with a large pinch of salt :)
On 15 Apr 2003, Mike Hearn wrote:
In fact, once we do Wine 1.0, people may decide to build a desktop environment around it. I think this is very exciting possibility, and I think we can even beat KDE and GNOME despite their big lead. I don't even think it's that much work (we need a panel, a file browser, and a control panel), we will have a lot more apps than they do, and we'll have far better binary compatibility.
Eurgh. My god. Please tell me you're kidding or have been drinking. We put so much work into Wine to run the applications, not because we think Windows is perfect and should be copied to the last detail. Anyway, there is already XPde which is copying XP to the last pixel.
No, I'm not kidding nor drinking. WIND has nothing to do with copying the XP UI. As I was explaining in my message, we can have our UI look like BlueCurve or what have you. WIND is all about the API. And yeah, the Windows API is not perfect, but there's no perfect API. And thing is, 99% of programmers out there know Win32, not GKT+. And I think the Win32 API is not that bad that it should be dropped, given the investment level that the human race has put into it. Quite frankly, I think the Win32 API si not that bad for UI tasks, it certainly proved to work OK for so many years. And if you want to talk about ugly, you should start with GTK, not Wine :) Not to mention the fact that I think our widgets are better, more polished, and I think more featureful.
But the big thing is that we'll have better binary compatibility than glibc had, a programming API known to *many* people, and a large set of apps aldready written. Look at SF, you'll see that the top downloads are by a huge margin apps that run on Windows.
No, I'm not kidding nor drinking. WIND has nothing to do with copying the XP UI. As I was explaining in my message, we can have our UI look like BlueCurve or what have you.
I'm not really sure what it is then, a desktop based on Wine? Why would that be better than a desktop based on Qt or GTK?
WIND is all about the API. And yeah, the Windows API is not perfect, but there's no perfect API. And thing is, 99% of programmers out there know Win32, not GKT+.
Not sure about that. I did many years of Windows programming before using Linux, but it was with Delphi. I'd guess most programmers know MFC, Visual Basic, Delphi/VCL and now .NET rather than the raw Win32 APIs.
And I think the Win32 API is not that bad that it should be dropped, given the investment level that the human race has put into it.
Hmm, that's an interesting idea. More a matter of philosophy though.
Well, part of the problem is that it's really Microsoft, not the human race, that has invested in it, everybody else was essentially forced to use it. I doubt we'll see the last line of Win32 for a long, long time, which is why Wine is so necessary. I'm not sure that's a valid reason to continue using it though. If the human race has invested in anything, it'd be the open source toolkits and APIs built mostly by volunteers.
Quite frankly, I think the Win32 API is not that bad for UI tasks, it certainly proved to work OK for so many years.
Well I'd guess a lot of, if not most apps use wrapper libraries because Win32 is so painful on its own.
And if you want to talk about ugly, you should start with GTK, not Wine :) Not to mention the fact that I think our widgets are better, more polished, and I think more featureful.
I personally found GTK2 to be a much saner API than Win32 - the mess over dialog vs window procedures just made me laugh out loud when Alexandre explained it. It has fewer features at the moment yes, but then it's much younger. It'll get them in time. Plus of course some design decisions in GTK are much better - signals, GObject API, containment based layout etc. Plus of course it has standardised bindings to many languages, unlike the Win32 API which can appear in many different forms depending on what IDE you use.
But the big thing is that we'll have better binary compatibility than glibc had, a programming API known to *many* people, and a large set of apps aldready written. Look at SF, you'll see that the top downloads are by a huge margin apps that run on Windows.
Sure, but Wine the binary emulation service works no matter what desktop it's in, I don't understand what the benefits of having a desktop built on top of it would be.
a Lindows -like ? :)
I'm not really sure what it is then, a desktop based on Wine?
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War !
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On 15 Apr 2003, Mike Hearn wrote:
I'm not really sure what it is then, a desktop based on Wine? Why would that be better than a desktop based on Qt or GTK?
Maybe. We do have a few big advantage. Unfortunately Qt is GPL and for taht reason I don't think it's viable to become the standard for Linux desktop. I'm not the only one thinking this way, that's why RedHat it's pushing GTK. But regardless, this is another discussion.
Let's look at what we bring to the table: 1. Stable API *and* ABI 2. Well known programming environment 3. A working, tested and accepted object embedding standard 4. A lot of standardized interfaces lacking currently in Linux 5. A LGPL, neat implementation
Let's see how the other compare: 1. KDE: broke API compatibility on every major release, as well as ABI compatibility. They claim they'll keep API compatibility, but ABI compatibility is likely to be broken in the (no so distant) future. This is a big no-no for ISV, it certainly doesn't sit well with me (mind you, I am a KDE user) GNOME: broke API compatibility from 1.x -> 2.x. It is true, it looks like they're gonna stick to the new one, and they are a lot more likely to maintain binary compatibitity in the future. But porting stuff to the 2.x API is going slowly, and the project seems to have lost steam.
2. KDE: it's C++, and a lot of people don't like that. Yes, they do have bindings to other langauges, but they often lag behind, it's simply not a viable alternative. GNOME: they justs switched to the new 2.x API, it's new, people by and large don't know it. It takes a lot of time traning 100 of thousand of programmers. However, it seems to be a decent API, so it is a promissing alternative.
3. KDE: KParts. Very non-standard, many people don't like it, it is only KDE that can use it. I really doubt it that it will ever become a commonly accepted standard, no matter how nice it may be. GNOME: Bonobo. Copied fairly closely from the Windows world why is it any better? In fact, the entire CORBA thing sucks badly, we'd be a lot better of with binary compati- bility with OLE. How cool would it be to have Word embedded in gnumeric? :)
4. We just have more APIs for stuff. Yeah, some of them are ugly, some not needed, but most are accepted and used by people, which is what matters in the end.
5. KDE does not qualify unfortunately. GNOME is OK on this point.
I think we should change a bit our point of view. We are comparing Win32 with GTK and QT. Not fair. We should compare it with Xlib, and then it becomes clear that it gives us a lot more.
The scenario that like to happen (and is preferable from almost any conceivable point of view) is to have Wine _below_ GTK, not the other way around:
| Applications .... ----------------------------- | GTK | QT | MFC | Mono | ... --------------------------------- | Wine ------------------------------------- | Xlib | (other unix libs ...) ----------------------------------------- | glibc | (other low level libs ...) --------------------------------------------- | Linux kernel =============================================
This one will allow for a lot of interoperability, it's technically feasible, it has all sorts of advantages. Having Wine use QT/GTK/etc. is just bound to fail.
Maybe. We do have a few big advantage. Unfortunately Qt is GPL and for taht reason I don't think it's viable to become the standard for Linux desktop. I'm not the only one thinking this way, that's why RedHat it's pushing GTK. But regardless, this is another discussion.
Well, at this point I seriously doubt any widget toolkit or platform will end up the standard, not that it matters much these days anyway, once we have unified theming as far as the end user is concerned Qt and GTK apps will look practically the same anyway (minus HIG differences).
Let's look at what we bring to the table:
- Stable API *and* ABI
Only while Microsoft are around. Wine is effectively slaved to what Redmond do - where they go, we must follow. Losing control of our own APIs is a bad idea. Also Microsoft are moving away from Win32 to .NET anyway.
- Well known programming environment
I don't know that many people with a lot of experience with Win32, they are all VB/Delphi/MFC coders. I'd guess most of them have used it a bit, but as I've been discovering, knowing how to call the API occasionally is very different from writing entire apps with it.
- A working, tested and accepted object embedding standard
Yes, that is true. Linux needs a component model badly. COM/OLE would never be accepted by the community though, not even a derivative - it's not even certain for Mono/.NET which gets binary compatability at the bytecode level as well in a much cleaner and better documented fashion.
- A lot of standardized interfaces lacking currently in Linux
Hmmm. Like? Ignoring OLE we have equivalents for most that are widely accepted:
comctl: Qt or GTK WinSock: UNIX sockets DirectX: SDL (ignoring directmusic which nobody uses) Direct3D: OpenGL Windowing/Graphics: X11 (abstracted by the toolkits anyway) VFS layers: well, there is no standard yet but I don't think making one would be too hard, and I'd note that the VFS situation in Windows is poor also, writing shell plugins is a vision of hell.
Yes, there are still some parts missing, and for some things there are several possible implementations (HTML renderer), but really I doubt there are that many critical interfaces lacking.
Also you have to remember the issue of control.
- A LGPL, neat implementation
That isn't finished ;)
Let's see how the other compare:
- KDE: broke API compatibility on every major release, as well as ABI compatibility. They claim they'll keep API compatibility, but ABI compatibility is likely to be broken in the (no so distant) future. This is a big no-no for ISV, it certainly doesn't sit well with me (mind you, I am a KDE user)
ABI compatability is less of an issue on Linux thanks to proper soname versioning/symvers etc. Windows has broken it too of course, winsock1, winsock2, D3D versions and so on. MSXML1,2,3
GNOME: broke API compatibility from 1.x -> 2.x. It is true, it looks like they're gonna stick to the new one, and they are a lot more likely to maintain binary compatibitity in the future. But porting stuff to the 2.x API is going slowly, and the project seems to have lost steam.
AFAIK it's almost all done, the big one we're waiting for now is Evolution for which the port is nearly finished (but they want to make it HIGified I think). There are still a lot of GTK1.2 apps out there, but much development/cvs software has moved to GTK2. Again, it doesn't matter that much, you've got similar issues on windows with comctl32 versions.
I'd expect more ABI churn while the linux desktop is developing, if you look at other areas it's far more stable.
- KDE: it's C++, and a lot of people don't like that.
Yes, they do have bindings to other langauges, but they often lag behind, it's simply not a viable alternative. GNOME: they justs switched to the new 2.x API, it's new, people by and large don't know it. It takes a lot of time traning 100 of thousand of programmers. However, it seems to be a decent API, so it is a promissing alternative.
It's alright. Documentation is rather poor. MSDN beats, well, pretty much anything, regardless of how much we like to bitch about undocumented stuff. Open source is much worse :(
The GNOME/GTK bindings for popular languages are pretty good though. Again, zero documentation, but they work well and are tested/mature.
- KDE: KParts. Very non-standard, many people don't like it,
it is only KDE that can use it. I really doubt it that it will ever become a commonly accepted standard, no matter how nice it may be. GNOME: Bonobo. Copied fairly closely from the Windows world why is it any better? In fact, the entire CORBA thing sucks badly, we'd be a lot better of with binary compati- bility with OLE. How cool would it be to have Word embedded in gnumeric? :)
Yeah, I've long believed COM/OLE beats the pants off any open source solution. KParts and Bonobo both have their strong points of course. On the other hand, Microsoft are leaving COM behind for .NET anyway, and who can blame them? COM is old and crufty.
- We just have more APIs for stuff. Yeah, some of them are ugly, some not needed, but most are accepted and used by people, which is what matters in the end.
Accepted and used *by Windows coders* because they have no choice. It's been possible to use Wine to write apps that work on both Windows and Linux for a long time, I'd guess it wouldn't be hard to avoid or fix the occasional bug or missing piece of Wine. Yet, no Linux coders do it. They use wxWindows instead if they really want portability, or GTK/Win32.
- KDE does not qualify unfortunately. GNOME is OK on this point.
I think we should change a bit our point of view. We are comparing Win32 with GTK and QT. Not fair. We should compare it with Xlib, and then it becomes clear that it gives us a lot more.
The scenario that like to happen (and is preferable from almost any conceivable point of view) is to have Wine _below_ GTK, not the other way around:
You mean so that GTK/Qt both map to the Windows APIs? I guess you could introduce another layer, but I don't see what this buys us that using freedesktop style standards does not.
------------------------------------------------------------ | GTK | Qt | GNOME | KDE | Wine | OpenOffice | Mozilla/XUL | ------------------------------------------------------------ | Xlib DBUS .desktop files (etc) | ------------------------------------------------------------
Really the parts of Win32 that Linux lacks are rapidly being filled in with the exception of a component model, and usually end up being nicer than the old Windows equivalents as well because we can learn from what worked and what didn't in Win32.
In terms of platforms, our current problem is that we have too many due to politics, because our major web browser/office suite was written to be cross platform originally and the need for compatability with Windows.
The answer would seem to be to suck the platform out of all these products and into a standardised, specified layer. Which is what is happening. It might be more work than just adopting Win32 wholesale but it's politically acceptable and will give nicer results.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
No, I'm not kidding nor drinking. WIND has nothing to do with copying the XP UI. As I was explaining in my message, we can have our UI look like BlueCurve or what have you. WIND is all about the API. And yeah, the Windows API is not perfect, but there's no perfect API. And thing is, 99% of programmers out there know Win32, not GKT+. And I think the Win32 API is not that bad that it should be dropped, given the investment level that the human race has put into it. Quite frankly, I think the Win32 API si not that bad for UI tasks, it certainly proved to work OK for so many years. And if you want to talk about ugly, you should start with GTK, not Wine :) Not to mention the fact that I think our widgets are better, more polished, and I think more featureful.
I strongly disagree. The Win32 API may not be so bad in the abstract (though I'd dispute that too), but it's a very poor choice for a Unix toolkit. It exposes way too many low-level details that don't have an equivalent on Unix. If you want a cross platform toolkit you should use a higher level one that abstracts a lot more of the platform details; and if you don't care about other platforms then you should use a Unix native toolkit. I don't think we would be doing anybody a favor by encouraging the use of Wine for new Linux developments.
On 15 Apr 2003, Alexandre Julliard wrote:
I strongly disagree. The Win32 API may not be so bad in the abstract (though I'd dispute that too), but it's a very poor choice for a Unix toolkit. It exposes way too many low-level details that don't have an equivalent on Unix. If you want a cross platform toolkit you should use a higher level one that abstracts a lot more of the platform details; and if you don't care about other platforms then you should use a Unix native toolkit. I don't think we would be doing anybody a favor by encouraging the use of Wine for new Linux developments.
Absolutely -- nobody these days write apps directly in the Win32 API. People do use a higher level toolkit such as MFC, QT, GTK, etc. Yeah, I agree, the Win32 API exposes stuff that's hard to implement on Unix. But stop for a second and think at the following ideal scenario: - all QT versions were free (and LGPL) - GTK had a proper Win32 port, where they would not reimplement the widgets, but use the native ones like QT does - we had a stable Wine 1.0 :)
Now, Linux apps use either QT/KDE, GTK/GNOME, or wxWindows as a toolkit. If things are done right, we would have binary compatibility for the toolkit backends, so that one can choose either the GTK/Wine or GTK/X11 backend at runtime.
These cross platform toolkits are hiding all these low level things that are hard to implement, so we don't have that problem. But we would have a unified platform that would be quite cool.
I don't think we're that far off. QT has a Win32 backend, it's doable, the only problem is that it's not free. GTK should be portable to Win32, and wxWindows already has a working Wine backend. Bonobo should easily mix with OLE given it's development history.
What you get: -- Linux apps using their toolkit of choice. None of the silliness we have now where you have to choose one or the other almost like they are different platforms (there is hope with BlueCurve) -- Iteroperability across the board, including _native_ Windows apps! -- a LOT of good apps, free and comercial. Look at SF which are the most popular apps. Windows apps! -- a lot less duplication of efforts, etc, etc.
Yes, there are problems, it will not be 100% pretty, but what is? In fact, all things too pretty tend to fail (I think Python is a lot prettier than Perl, but Perl is doing so much better).
And I think a better name would be WIDE for: -- WIne Desktop Environment -- WIDEly Integrated Desktop Environment -- Wide Is a Desktop Environment -- WIld Desktop Environment :)))
Absolutely -- nobody these days write apps directly in the Win32 API.
For good reasons....
People do use a higher level toolkit such as MFC, QT, GTK, etc. Yeah, I agree, the Win32 API exposes stuff that's hard to implement on Unix. But stop for a second and think at the following ideal scenario:
- all QT versions were free (and LGPL)
- GTK had a proper Win32 port, where they would not reimplement the widgets, but use the native ones like QT does
AFAIK Qt does not use native widgets on Windows, it does what GTK does and renders them itself. Or did last time I checked anyway. It does do a very good job of imitating the Win32 controls though. Also, check this out:
http://gtk-wimp.sourceforge.net/screenshots/
Who needs native widgets :)
- we had a stable Wine 1.0 :)
Now, Linux apps use either QT/KDE, GTK/GNOME, or wxWindows as a toolkit. If things are done right, we would have binary compatibility for the toolkit backends, so that one can choose either the GTK/Wine or GTK/X11 backend at runtime.
These cross platform toolkits are hiding all these low level things that are hard to implement, so we don't have that problem. But we would have a unified platform that would be quite cool.
There are *much* easier ways to get a unified platform imho..
On 15 Apr 2003, Mike Hearn wrote:
http://gtk-wimp.sourceforge.net/screenshots/
Who needs native widgets :)
Nice! Which is close to what we want :)
These cross platform toolkits are hiding all these low level things that are hard to implement, so we don't have that problem. But we would have a unified platform that would be quite cool.
There are *much* easier ways to get a unified platform imho..
Very informative :) If you're unified platform supports a few apps, yes I agree. Check out OpenOffice.org. But if you look at the bigger picture, what would you suggest? It's not clear we can unify the Unix apps (GNOME,] KDE, Mozilla, OpenOffice, Wine, etc.), let alone integration of Windows apps.
"Dimitrie O. Paun" dimi@intelliware.ca writes:
What you get: -- Linux apps using their toolkit of choice. None of the silliness we have now where you have to choose one or the other almost like they are different platforms (there is hope with BlueCurve) -- Iteroperability across the board, including _native_ Windows apps! -- a LOT of good apps, free and comercial. Look at SF which are the most popular apps. Windows apps! -- a lot less duplication of efforts, etc, etc.
Yes, there are problems, it will not be 100% pretty, but what is? In fact, all things too pretty tend to fail (I think Python is a lot prettier than Perl, but Perl is doing so much better).
Apart from the obvious technical problems with that, and the overall ugliness of the result, the major drawback is that you are essentially putting Microsoft in control of the direction of the Unix desktop.
The Windows API is not something we have freedom to change, and that is a very problematic restriction. Even if most desktop environments today are quite similar to Windows, I hope we can move beyond that someday, and leave Microsoft in the dust. This can't happen if we let them define the core APIs.
On 15 Apr 2003, Alexandre Julliard wrote:
Apart from the obvious technical problems with that, and the overall ugliness of the result, the major drawback is that you are essentially putting Microsoft in control of the direction of the Unix desktop.
The tehnical problems are workable, and seem easier to deal with than the current ugly mess. The ugliness, like beauty, is in the eye of the beholder :) In my vision, only toolkits need to mess with Win32, so I'm not worried too much about his aspect.
However, the last point moves us into the political arena. There are interesting questions: should we not develop something even if it made technical sense because it may help Microsoft? Are we on war with Microsoft, or are we just developing the most useful stuff we can, so we can live in freedom?
Fortunately, I think we can avoid these issues for now. I don't think Microsoft is in any control. All they can do is _extend_ the API. If they move it from under us, *we* will keep backwards compatibility, they die, and we are happy. So again, all they can do is extend it. Which makes the current API a free interface. We can choose to extend it too, when we feel we can add useful stuff to it. But that's a different matter.
What we have currently is an API that's accepted by most software industry, tested, and refined through many years. Is it pretty? No. But the same goes for many things in Unix. We now have a free implementation of this API. Why is this dangerous? Why shouldn't people use it? If they care not to be controlled by MS, all they have to do is to not use useless extensions comming out of Redmond. All they have to do is to WANT to be free. Once we have a good enough coverage of the API, we don't care what MS does. From this perspective, I can't see how MS can control the Unix desktop.
I think Wine is quite underestimated. At a global level, people invested unthinkable sums of money to train people into knowing it (and yeah, I've heard the arguments with MFC/Mono/etc, but all these are related to Win32 one way or another, so they fall into the same basket). If we are to kill MS and move people to Linux, the benefit that Wine brings to the global economy is huge. But we have to know to leverage it. I think a WIDE project make sense, not sure if it's politically viable. Only starting work on it will tell. Maybe post 1.0 :)
"Dimitrie O. Paun" dimi@intelliware.ca writes:
I think Wine is quite underestimated. At a global level, people invested unthinkable sums of money to train people into knowing it (and yeah, I've heard the arguments with MFC/Mono/etc, but all these are related to Win32 one way or another, so they fall into the same basket). If we are to kill MS and move people to Linux, the benefit that Wine brings to the global economy is huge. But we have to know to leverage it. I think a WIDE project make sense, not sure if it's politically viable. Only starting work on it will tell. Maybe post 1.0 :)
I think that project has already started, it is named ReactOS... Of course it's not based on Linux, but with your approach there's no real reason to use Linux anyway since everything goes through the Win32 API, you might as well use a Win32 kernel too.
On 15 Apr 2003, Alexandre Julliard wrote:
I think that project has already started, it is named ReactOS...
:) Point taken :)
Of course it's not based on Linux, but with your approach there's no real reason to use Linux anyway since everything goes through the Win32 API, you might as well use a Win32 kernel too.
Of course there is a reason, there is a lot more to an OS then the GUI. I do a lot more than edit files in Word or Excel. What about the command line and all the utilities? The non-braindead filesystem? And so on, and so forth. The Win32 API is almost synonymous with GUI programming. For that, it works just fine. There's no reason for deamons, utilities, etc. to be written to the Win32 API. The Unix one is perfect there. It's exactly what it was designed to do. In fact, not even apps need to use the Win32 app directly -- as I said, only the toolkits will need to be written to them. wxWindows is already done, it's not such a drastic proposition, is it?
Really Alexandre, who cares what toolkit an app uses? If we do, we repeat the mistakes done in Java with Swing. That killed Java on the desktop, because it exposed an implementation detail. People care about apps integrating in their current setting, they don't give a rat's ass in which language, toolkit, IDE, etc. the app was written. Take Audacity for example, it's written on top of wxWindows, do you think anyone would care if wxWindows would use Wine to render instead of GTK? (Assuming the rendering matches the current theme, like BlueCurve)?
"Dimitrie O. Paun" dimi@intelliware.ca writes:
Really Alexandre, who cares what toolkit an app uses? If we do, we repeat the mistakes done in Java with Swing. That killed Java on the desktop, because it exposed an implementation detail. People care about apps integrating in their current setting, they don't give a rat's ass in which language, toolkit, IDE, etc. the app was written. Take Audacity for example, it's written on top of wxWindows, do you think anyone would care if wxWindows would use Wine to render instead of GTK? (Assuming the rendering matches the current theme, like BlueCurve)?
Well I see absolutely no point to the whole exercise, but I'm clearly not going to convince you. Feel free to try to persuade the Unix world to insert a bloated Win32 layer under all their toolkits; I don't think you will get very far with that idea...
On April 15, 2003 07:16 pm, Alexandre Julliard wrote:
Well I see absolutely no point to the whole exercise, but I'm clearly not going to convince you. Feel free to try to persuade the Unix world to insert a bloated Win32 layer under all their toolkits; I don't think you will get very far with that idea...
Hey, "absolutely no point" is a bit strong :) But don't get upset, I was more brainstorming than anything else. I don't have time to sleep now, let alone start such a project. ;)
But we've lost track were we started from. I was advocating to make Wine easier to use as a library, and not encourage people to copy & paste code. There are a few cases where that may work: mplayer, *maybe* Gimp. But even in those cases it seems the plugins pull way to much of the API with them to have a snowball chance in hell to get something decent. Linking with Wine should give a decent result. Right now that's not the case, but it seems some simple improvements we plan to do anyway (the configuration work, lazy initialization, etc.) will greatly help in that regard.
So my end goal for this debate is to understand better what steps we need to take toward a EzWinelib (TM). And none of the problems listed seem all that hard, let alone insurmountable.
The one that cannot compile the toolkit on their system or have a non compatible version of the toolkit....
Really Alexandre, who cares what toolkit an app uses? If we do, we repeat the mistakes done in Java with Swing. That killed Java on the
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War !
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Dimitrie O. Paun wrote:
On 15 Apr 2003, Alexandre Julliard wrote:
I think that project has already started, it is named ReactOS...
:) Point taken :)
I have been watching this thread for a while but was going to keep my mouth shut untill someone else said it. =)
Dimi I agree in part with what you are saying. This is why I wanted to see a Win32 based IDE working on WINE/Linux. I would love to help you but I think it wont be for about 5+ years when my programming skills are able to start submitting real code to your project. In the meantime the ReactOS team is working on some stuff to try and help your vision along. Expect to see our explorer clone in the next few months.
Thanks Steven
On Tue, 15 Apr 2003, Dimitrie O. Paun wrote: [...]
But the big thing is that we'll have better binary compatibility than glibc had, a programming API known to *many* people, and a large set of apps aldready written.
I don't understand. In another email you are arguing that only toolkits (Gtk, Qt, Gnome, KDE, wxWindows) should be using Win32 and that Unix applications should use these toolkits. So applications would still be subject to the whims of these toolkits, to that breaking source level or binary level compatibility. And familiarity with Win32 buys you nothing if you are going to code to these toolkits anyway. So Win32 buys applications and application developpers nothing in that scenario.
For applications to benefit from the stability of the Win32 API, they would have to use it directly, or maybe use it via a stable toolkit like the MFC (urgh). IOW, people should write Windows applications and that strikes me as a not so good solution for Unix applications!
There is another issue to consider which has not been raised until now: compatibility with non-x86 platforms. Unix applications *must* work on non-x86 platforms (in my view if they don't they're no good). Winelib is portable... in theory. But in practice the Win32 API has all sorts of portability issues (endianness of resources, endianness of DIBs, often passes pointers via ints, etc.). IMO Win32 is not a mature cross-platform API and that is enough to disqualify it as an API to be used for building Unix applications.
So I would rather put efforts into making sure Gtk, Gnome, KDE and QT are suitable solutions. (or more precisely, have other people put efforts into that ;-)
Look at SF, you'll see that the top downloads are by a huge margin apps that run on Windows.
No problem. Let's run them in Wine on a Gnome/KDE desktop (or fvwm if you're like me). I see nothing that would prevent them from nicely integrating with the desktop environment (be that menus or systray for instance). And any problems there currently are (e.g. z-order of unmanaged windows) should be solved in that environment. Yes they will not have the exact same look as other applications, but it is no worse than Mozilla not having the same look as Emacs, Konqueror or OpenOffice or gkrellm.
I see no need for WIND/WIDE to take advantage of these Windows applications.
(oups, stirring trouble, sorry, just had to add my grain of salt)
On April 19, 2003 05:44 pm, Francois Gouget wrote:
So I would rather put efforts into making sure Gtk, Gnome, KDE and QT are suitable solutions.
Really? Do people think that KDE & QT would be a more suitable solution? Do *anyone* here think that KDE & QT are a better alternative then WIDE for Linux as a _platform_?!? Newsflash: QT is GLPed. KDE depends on QT. If you want to develop non-GPL apps on Unix using KDE/QT, you have to pay thousands of dollars to Troll Tech for each developer. Is this the _free_ platform we want to build? You can develop apps for free on Windows (see MinGW, Borland, OpenWatcom), or for a small price buy MSVC, yet you'll have to pay through the nose on our free OS! Isn't that fantastic? And the best part is that we give the Trolls complete monopoly, whereas they can do what they want to the price in the future. We trade the (very little) control that MS has over Win32, with the big one that Trolls have over QT. Splendid!
So, can someone please tell me a *single* advantage of having KDE & QT as the GUI platform for Linux vs. having WIDE?
I have waited with this message a week to calm down, but I didn't :) so I have to say what I have to say.
You guys rave about the big, bad, bloated, ugly Win32 messing up the nice Unix GUI API. WTH are you guys talking about? There's no traditional Unix GUI API! You want bad, bloated, and ugly? Fine: -- ugly: Xaw, what can I say? -- bloated: Motif, it's good it's dead. -- bad: QT, can you spell non-free?
So the _only_ viable Unix GUI API is GTK/GNOME. But version 2 of that API came out only a year ago, and Evolution is not even ported to it! Do you consider that traditional? It's so new it's not even funny. And maybe that's fine, but the problem is that they lost steam: at the moment it seems that most development is done by RedHat, Ximian, and Sun. And it's going slow. The two platforms (GNOME and KDE) seem to diverge more and more, and if you look asymptotically, do you see a bright, integrated future?
I don't think that WIDE is the greatest idea since slice bread. It's just something I thought of as a possibility during the discussion, and I threw it in there as a way to show there are other ways of looking at Wine. But I also don't think it's such a bad idea either. And I really don't understand the irrational fear (oh, it comes from MS, it *must* be evil), and the overly emotional and unsupportable defense of 'Unix API'.
Really? Do people think that KDE & QT would be a more suitable solution?
No, but they are not the only platform available, as you have noted.
platform we want to build? You can develop apps for free on Windows (see MinGW, Borland, OpenWatcom), or for a small price buy MSVC, yet
How many people actually program Windows without using an IDE? Most programmers I know use either MS Visual C++/Basic or Delphi (and now .NET).
So the _only_ viable Unix GUI API is GTK/GNOME.
I would say, rather, "So the _only_ viable Unix GUI API for non-GPLd software is GTK/GNOME"
For GPLd software, Qt is fine (though aesthetically i prefer gtk). This would only be a problem if in future you were required to use it in order to get integration, as you are required to use the Win32 API implementations to get integration on Windows. Luckily that isn't the case, and is becoming less so every day.
I don't see any fundamental reason why you can't have the same app written using Qt and GTK next to each other, with identical L&F and perfect integration. Sure, that's not the case today, but it's possible.
But version 2 of that API came out only a year ago, and Evolution is not even ported to it!
Well, it almost is. Apparently the 1.3.x series is quite stable now.
Do you consider that traditional? It's so new it's not even funny. And maybe that's fine, but the problem is that they lost steam: at the moment it seems that most development is done by RedHat, Ximian, and Sun.
Not sure where you got that idea, Ximian haven't been contributing much code of late at all, they mainly maintain current stuff. Redhat and Sun do quite a bit, but the bulk of the work, as ever, is done by volunteers. The release coordinator is a volunteer, GStreamer is developed by volunteers, a lot of the work on GTK is done by volunteers, ditto for gnome-panel, libgnome and so on.
And it's going slow. The two platforms (GNOME and KDE) seem to diverge more and more, and if you look asymptotically, do you see a bright, integrated future?
Actually.... yes? :) They aren't really diverging in my eyes, this broken system tray I have sitting here taunting me is a visible reminder that we need to keep Wine up to date with the latest standards.
I don't think that WIDE is the greatest idea since slice bread. It's just something I thought of as a possibility during the discussion, and I threw it in there as a way to show there are other ways of looking at Wine. But I also don't think it's such a bad idea either. And I really don't understand the irrational fear (oh, it comes from MS, it *must* be evil), and the overly emotional and unsupportable defense of 'Unix API'.
I'm still not sure why you think we need one implementation to get integration, as opposed to one set of interfaces with several possible implementations. Experiments like the system tray seem to indicate that we can get a unified platform between several large toolkit implementations regardless of their license, or who designed them.
On 25 Apr 2003, Mike Hearn wrote:
Actually.... yes? :) They aren't really diverging in my eyes, this broken system tray I have sitting here taunting me is a visible reminder that we need to keep Wine up to date with the latest standards.
Yes, they become better integrated, but we're at the beginning of the road, and we still don't even get the easy stuff perfect: L&F, system tray, etc. I can see unifying most settings so we don't have to configure things twice, but we're far away, there seems to be little political will (especially on the KDE side). But what about OLE? KDE will never accept CORBA (for good reasons), while GNOME will not drop it. That's the big one: how do you integrate the apps more than making them just look the same?
I'm still not sure why you think we need one implementation to get integration, as opposed to one set of interfaces with several possible implementations.
It's mainly a misunderstanding, mea culpa. I am not suggesting the "one implementation" is the way to go, but it's a possiblity. I actually think a set of interfaces with different implementations is better in the long run, so I'm happy we have things like the freestandards.org, and Havoc seems to be doing a great job.
For WIDE, I would not reinvent everything around Win32, as the GNOME/KDE/OpenStep/Enlightment people did around their toolkits. I would get the best of breed apps from all environments, and try to integrate them: -- For L&F, having Wine adapt the L&F of the native environment is better, if that would be available, I'd use it. If not, I might compile GTK-Wimp agains Wine, until we get theaming in Wine. -- There are a bunch of free Win32 apps on SF which are very popular. I can choose some of those, like eMule, Mozilla/Win32, etc. I may use the ReactOS Explorer replacement instead of Nautilus, if they do a good job with it. -- I would compile wxWindows against it's Wine backend, simply because I think out widgets are better than the ones in GTK. -- I will try to have a Bonobo backend for Win32, so that GNOME apps could seemlessly link and embed Win32 apps. -- All libs in WIDE will be LGPL, so the platform is free for everybody.
I was not suggesting to replace read with ReadFile, or Unix pipes with Win32 pipes. Yes, about the same thing one can achieve on top of GNOME, by just tweaking Wine to integrate better with it. But the big problem with GNOME is political, people are too religious about these issues.
All I want is a higly integrated environment where I get by default 'best of breed' free apps from across GNOME/Windows/etc. As a user I don't care what langauge/api/toolkit an app uses, I want an unified seemless environment. I'm sick and tired of all the political debates, give me a cool user experience, not political diatribes on why I should belive religiously that Windows sucks and $YOUR_DESKTOP_ENVIRONMENT is the best thing since slice bread.
Dimitrie O. Paun wrote:
Yes, they become better integrated, but we're at the beginning of the road, and we still don't even get the easy stuff perfect: L&F, system tray, etc. I can see unifying most settings so we don't have to configure things twice, but we're far away, there seems to be little political will (especially on the KDE side). But what about OLE? KDE will never accept CORBA (for good reasons), while GNOME will not drop it. That's the big one: how do you integrate the apps more than making them just look the same?
This is kind of off topic but I have been pondering this for a while. Is someone working on Xdnd in WINE? I emailed Jean-Claude Batista about his work for Corel using OLE with Xdnd but I dont think anyone is working on this in WINE atm. I would be nice if we could get some sort of OLE <-> Xdnd bridge going that is portable. That way the KDE on Cygwin and GNOME on cygwin people could use it also on X for Mingw/Cygwin.
-- There are a bunch of free Win32 apps on SF which are very popular. I can choose some of those, like eMule, Mozilla/Win32, etc. I may use the ReactOS Explorer replacement instead of Nautilus, if they do a good job with it.
Lets us hope we do a better job then microsoft or no one will use ReactOS or your WIDE <g>
I apologize if I'm misinterpreting what you said. It came across that way to me. Maybe it's just I misunderstood you or that your words were not true to your thoughts.
On Fri, 25 Apr 2003, Dimitrie O. Paun wrote: [...]
So, can someone please tell me a *single* advantage of having KDE & QT as the GUI platform for Linux vs. having WIDE?
I mentioned many but you seem to be conveniently ignoring them.
At the same time you dismiss out of hand solutions that are being worked on, exist and are usable now, just because they are not perfect. At the same time you push a solution which does not exist, claim it will solve all problems when it seems to me it will just run into exactly the same issues you complain about for the other while adding new issues of its own.
For instance, if we just take the Look and Feel issue. You diss Gnome an KDE for not having a common configuration for their look and feel.
* As far as I can tell WIDE would not have a configurable look and feel at all because Wine does not have that support. Sure that support can be added but that's replacing something that works (themes in Gnome and KDE) even if not perfect (not integrated) with something that does not exist (themes in Wine). * you propose to use GTK-Wimp to integrate the Gnome look and feel with the Wide themes. That's a good idea. But you don't propose anything to integrate the KDE look and feel with the Wide look and feel. So either KDE applications will still have a different look and feel from Wide applications, or more development will be necessary. At this point I have to wonder whether this is less work than integrating the Gnome and KDE theme configuration, or use a trick ala Blue Curve, and whether the method you propose is going to be really superior. * you want all applications to have the same look and feel and I definitely agree with that goal. You claim Wide makes it possible but you don't address the case of applications that are not based on Gnome or KDE: gkrellm, emacs, Xaw-based applications, etc. Now to be fair I think there is nothing we can do for these applications except find replacements for them (or live with them as they are).
In my view, one thing that has plagged the Unix desktop is the proliferation of GUI toolkits and desktop environments/window managers. Fortunately in the past few years most development appears to have coalesced on two environments, Gnome and KDE. But you are essentially proposing to add yet another toolkit/desktop environment and IMO this requires having very strong arguments showing the existing stuff *cannot* be fixed and that the new stuff will not suffer the same issues and will be significantly superior.
(yes I feel the same way whenever someone says we need yet another window manager, text editor, email client, web browser, file manager, replacement for X, Linux distribution, etc.)
[...]
-- bad: QT, can you spell non-free?
According to my Debian files, QT is dual licensed under the QPL and GPL:
Qt 2.2 and later is dual licensed under the QPL and the GPL Please refer to /usr/share/common-licenses/GPL for complete GPL license.
So this does not seem to be a problem. Or did it change back with 3.0?
And I really don't understand the irrational fear (oh, it comes from MS, it *must* be evil), and the overly emotional and unsupportable defense of 'Unix API'.
I hope you do not ascribe that argument to me.
On April 25, 2003 04:53 pm, Francois Gouget wrote:
So, can someone please tell me a *single* advantage of having KDE & QT as the GUI platform for Linux vs. having WIDE?
I mentioned many but you seem to be conveniently ignoring them.
No, I'm not ignoring anything. You referred to KDE/QT/GNOME/GTK, I argued precisely against KDE/QT. Once again, I think it is unacceptable to have our _platform_ (not apps) covered by the GPL. It sets an uneven playing field. I'll ask again: is this the kind of free OS we want to build? Yes, QT is licensed under QPL as well -- go rea
On April 27, 2003 12:47 am, Francois Gouget wrote:
Only as far as commercial companies are concerned. Under the GPL license, anyone can fork QT.
And you think this is any way acceptable? I am sorry, but an OS that puts commercial development at such a tremendous disadvantage (that is, subject to the monopolistic whims of one company) is not a platform. So all the portability issues you listed don't even start to apply.
So you're saying Linux developpers should abandon Gnome/Gtk and KDE/QT and instead develop using Win32+OLE+COM?
No! Unfortunately, KDE/QT is in a difficult situation due to the licensing problem. It is the desktop of choice for most people, I use it, but I can't see what we can do about it.
I'm not criticizing, I'm trying to clarify because in one of your previous email I had the impression that you advocated development against a Win32-based Gtk API.
Gtk is already ported to Win32. App wouldn't even know what Gdk backend is used, they would be just the same.
What about graphical applications? In the Windows world most applications don't use Win32 directly for the GUI. Should we provide an LGPL implementation of MFC? Implement a replacement for Visual Basic? A binary compatible one?
I am mainly referring to graphical apps. And no, commercial apps provide their own framework just like they do now. It'd be nice to have efforts toward a free MFC implementation, but it's besides the point. It's an orthogonal issue.
What API would open-source developpers use for WIDE applications?
They have a choice: Gtk/Gnome, wxWindows, Win32. There are a lot of free apps (see the top SF downloads for examples) that use the Win32 API, so it's not something new I'm suggesting? Do you think it's more moral/ethical to treat these apps as second class citizens in Linux?
Yes it would be very cool. I am far from being an expert on OLE/DCOM but I have been told that it may be feasible. Probably a heck of a lot of work though.
I'm not saying it would be easy. But given that Bonobo was so deeply inspired by OLE, I'm hoping it can map easily onto an OLE backend, and maybe that leads to an easier path to integration.
But AFAICS what's needed is much smaller in scope from what you propose with WIDE.
Hm, it seems I have problems communicating. In fact, it seems to me we have most of the pieces for Wide already.
Other questions so I better understand:
- are you proposing source-level compatibility or binary level
compatibility?
Both. We get both with Wine, we should be able to keep that.
- if it is source level, does it mean modifying gcc to support the
Visual C++ COM extensions?
It would be nice to have gcc support for those, but this is independent of the Wide effort. Just like we have support for other stuff that was added through the MinGW project.
- how do you propose to handle the issue of drive letters?
What we do in Wine is just fine. I'm only concerned with GUI apps, and there I see drive letters as just shorthands to a bunch of dirs. If you like that, go nuts. I see it as mainly a UI thing, other than that we'd try to pass Unix paths around as much as possible.
On Sun, 27 Apr 2003, Dimitrie O. Paun wrote:
On April 27, 2003 12:47 am, Francois Gouget wrote:
Only as far as commercial companies are concerned. Under the GPL license, anyone can fork QT.
And you think this is any way acceptable?
Bah, I don't really care. Maybe because I use neither Gnome nor KDE. I see your point but I can't help but think that it's a bit of a stretch to say Trolltech could become another monopoly when there is a GPL implementation available, which is why I said the above.
I am sorry, but an OS that puts commercial development at such a tremendous disadvantage (that is, subject to the monopolistic whims of one company) is not a platform. So all the portability issues you listed don't even start to apply.
Because KDE's license is bad it does not matter whether WIDE is portable or not? That does not make sense. Your telling people to ignore a fatal flaw in WIDE just because _one_ of the other frameworks has what you say is another fatal flaw. That's jumping out of the fire and into the pan.
Now if you think WIDE is portable, tell us how.
So you're saying Linux developpers should abandon Gnome/Gtk and KDE/QT and instead develop using Win32+OLE+COM?
No! Unfortunately, KDE/QT is in a difficult situation due to the licensing problem. It is the desktop of choice for most people, I use it, but I can't see what we can do about it.
So the situation will remain the same: we will haev KDE applications and WIDE applications and they will not be interoperable. I.e. it won't be possible to insert an Excel spreadsheet in a KWord document.
I'm not criticizing, I'm trying to clarify because in one of your previous email I had the impression that you advocated development against a Win32-based Gtk API.
Gtk is already ported to Win32. App wouldn't even know what Gdk backend is used, they would be just the same.
Does that include interoperability with OLE/COM/DCOM or just the look and feel integration?
They have a choice: Gtk/Gnome, wxWindows, Win32. There are a lot of free apps (see the top SF downloads for examples) that use the Win32 API, so it's not something new I'm suggesting? Do you think it's more moral/ethical to treat these apps as second class citizens in Linux?
I don't see the problem. Do you think it's more moral/ethical to treat open-source MacOS/X applications as second class citizens in Linux? What about DOS applications? OS/2 applications? Amiga applications?
Yes it would be very cool. I am far from being an expert on OLE/DCOM but I have been told that it may be feasible. Probably a heck of a lot of work though.
I'm not saying it would be easy. But given that Bonobo was so deeply inspired by OLE, I'm hoping it can map easily onto an OLE backend, and maybe that leads to an easier path to integration.
I think we agree on most of the goals: we both want to integrate the Wine, Gnome and KDE environments. By 'integrate' I mean, integrate the menus and associations, automatically use the same look and feel, and make it possible to use object components of one in the other and reciprocally.
I believe where we differ is on the method: * I think we should work on Wine to make that possible (though there may be some work to do in Gnome and KDE). * You think that it is mostly Gnome that must be modified to use the Wine APIs and you are ready to drop/ignore KDE. I believe you also proposed to replace Nautilus/Konqueror with Explorer, and to develop a new window manager.
Other questions so I better understand:
- are you proposing source-level compatibility or binary level
compatibility?
Both. We get both with Wine, we should be able to keep that.
Of course binary compatibility will only work on the x86 platform. Porting applications to another platform will require recompiling them. This will put commercial applications based on a commercial framework such as MFC and Visual Basic at a big disadvantage. Is it fair to tell people that this is the way to go when it will restrict them to the x86 platform?
I think not. Then you would push Gnome/Gtk as the framework of choice for WIDE. But for these developpers, what's the advantage of WIDE compared to the regular Gnome? It seems to me that it only risks to tempt them into using non-portable APIs.
- how do you propose to handle the issue of drive letters?
What we do in Wine is just fine. I'm only concerned with GUI apps, and there I see drive letters as just shorthands to a bunch of dirs. If you like that, go nuts. I see it as mainly a UI thing, other than that we'd try to pass Unix paths around as much as possible.
You seem very concerned about look and feel. But drive letters are just as big an issue. You won't have a unified desktop unless this is handled uniformly. Or do you propose that Gnome applications too use drive letters?
On April 27, 2003 05:32 pm, Francois Gouget wrote:
Bah, I don't really care. Maybe because I use neither Gnome nor KDE. I see your point but I can't help but think that it's a bit of a stretch to say Trolltech could become another monopoly when there is a GPL implementation available, which is why I said the above.
I really don't understand you. It seems to me obviously clear that a GPLed platform is as useful as a GPLed Wine. This is not something minor, and it's no stretch -- the Trolls would have the monopoly over all commercial apps, which is where the money is. You may not use either, but that's no solution. People will have to choose one or the other, they can't go back to Xaw or Motif.
Now if you think WIDE is portable, tell us how.
Well, we do have Winelib working on non-i386 platforms, don't we? But bottom line, people worried about portability should program to the Gnome/Gtk API, I haven't suggested for a moment we drop Gtk and code everything to the Win32 API. For people like the emule guys that like to code to the Win32 API, they can continue to do so if they so wish.
So the situation will remain the same: we will haev KDE applications and WIDE applications and they will not be interoperable. I.e. it won't be possible to insert an Excel spreadsheet in a KWord document.
No, it will be better: you will be able to have deep integration between Win32 apps and Gnome apps, no small feat.
Does that include interoperability with OLE/COM/DCOM or just the look and feel integration?
Well, the OLE/COM/DCOM bit is the interesting one, the look and feel is simple and has other solutions, as we discussed.
I believe where we differ is on the method:
- I think we should work on Wine to make that possible (though there may be some work to do in Gnome and KDE).
For sure. But this will work for things like L&F. The difficult things aren't even considered by anyone at this point. So no, we are quite in violent agreement here.
- You think that it is mostly Gnome that must be modified to use the Wine APIs and you are ready to drop/ignore KDE. I believe you also proposed to replace Nautilus/Konqueror with Explorer, and to develop a new window manager.
No, I'm not dropping/ignoring KDE. It's just that right now we're talking about some deep integration issues that no one even considered before. Right now, integration is used to describe L&F. It's fairly clear we need to be able to integrate with things like BlueCurve so Wine integrates as much as possible in both Gnome and KDE.
Wide doesn't change that. In fact, being based on Wine, it will implicitly benefit from all the integration work we do on the Wine side. But at that point, people will ask: what is the difference between Wide, and just Wine running in Gnome? And it's a good question. Part of the answer is that Wide may choose to use Wine's OLE implementation to integrate Bonobo/Win32/OpenOffice apps. But that's really wishfull thinking, I'm not even sure that's at all possible.
The real answer is that Wide is just like Gnome, but with a different set of mentalities. Instead of picking the default apps only based on religious things like 'is it using Gtk?', I propose we choose the default apps from the set of all Gnome and free Win32 apps (and any other platform that integrates nicely). I am sorry I can't include KDE here as well, but it's because their platform is not free enough, not because I don't like the Qt framework. If tomorrow we have a LGPL Qt implementation, they would be added to the pool of possible apps.
This should answer your Nautilus/Konqueror/Explorer. I have to religious affiliation to Nautilus or Konqueror. If the ReactOS people build a better (and free) browser, it goes in as the default browser. Apps should compete on features and user experience, not on irrelevant implementation details.
Dimitrie O. Paun wrote:
This should answer your Nautilus/Konqueror/Explorer. I have to religious affiliation to Nautilus or Konqueror. If the ReactOS people build a better (and free) browser, it goes in as the default browser. Apps should compete on features and user experience, not on irrelevant implementation details.
I think you are forgetting the one beast/API/toolkit to bind them all. Mozilla. It is my hope that ReactOS will be able to use either khtml as it is LGPL or use the Gecko. If you are talking about getting WINE/WIDE and GTK to play nice together then your and our time will be better spent on mozilla with explorer.
Thanks Steven
On April 28, 2003 12:29 pm, Steven Edwards wrote:
I think you are forgetting the one beast/API/toolkit to bind them all. Mozilla. It is my hope that ReactOS will be able to use either khtml as it is LGPL or use the Gecko.
There's some confusion. I thought you guys are working on doing an Explorer-the-file-browser clone, not an IE clone. Yes, we already have khtml and gecko, it would be crazy/silly to start yet another one.
Dimitrie O. Paun wrote:
There's some confusion. I thought you guys are working on doing an Explorer-the-file-browser clone, not an IE clone. Yes, we already have khtml and gecko, it would be crazy/silly to start yet another one.
We are doing work on a explorer clone. I thought you had jumped to discussing the WebBrowser interface. The guy that wrote our bootloader and task-manager is supposed to be working on our explorer clone. At some point the explorer clone is going to have to interface with a web-browser. In any case I want to see this OLE to GTK or bonobo integration support you are talking about. The more these applications can get along the better chance we have of moving people off of Windows on to Linux, ReactOS or anything else that comes along and does GNU. There are a 2 things I think WINE needs now before we will see a good WIDE.
1. Implement Xdnd to OLE support. Corel did some work on this but it never made it in to the main winehq tree. This would really help anyone porting a Windows application to Linux seeing as how everything on Windows uses OLE and KDE and GNOME both support Xdnd now. I thinking if it is done right then you could even have it both ways and build it as a dll under Mingw and use it with either kde-cygwin/gnome-cygwin or libw11 ported applications. (If anyone has a snapshot of the corel-wine CVS I would like to look at this)
2. Cleanup Ole*. Everything depends on OLE and it either doesn’t implement everything or calls way to many non-standard APIs. Now that codeweavers has started to fix the need for M$ dlls in crossover maybe it will get fixed. We cannot make much use of most of the WINE code until we can build working ole32 support. There are way to many win16isms, and 9xisms.
On Monday 28 April 2003 01:07 am, Dimitrie O. Paun wrote:
On April 27, 2003 05:32 pm, Francois Gouget wrote:
So the situation will remain the same: we will haev KDE applications and WIDE applications and they will not be interoperable. I.e. it won't be possible to insert an Excel spreadsheet in a KWord document.
No, it will be better: you will be able to have deep integration between Win32 apps and Gnome apps, no small feat.
Does that include interoperability with OLE/COM/DCOM or just the look and feel integration?
Well, the OLE/COM/DCOM bit is the interesting one, the look and feel is simple and has other solutions, as we discussed.
I believe where we differ is on the method:
- I think we should work on Wine to make that possible (though there may be some work to do in Gnome and KDE).
a few issues are being conflated here perhaps: 1) what browser? 2) how can we get wine apps to have a consistient look-and-feel on gnome and kde (and other) desktops? 3) (the original thread I believe?) what are the prospects of using wine as a window manager?
The third may be beyond my ability to answer, but 1) and 2) seem easy to me...
As for the browser issue, it's been discussed on the list ad infinitum and the consensus was that we should lean towards konq integration.
OTOH, if someone had a well-done, LGPL, working base of completely original code, or magical code to get mozilla or opera or lynx or what-have-you to do everything wine needs -- I would be surprised if it wouldn't find its way into wine (or at least into my tree at home !!! ;)) So he who codes first wins the debate, as usual ;)
There is no reason, I think, that we theoretically couldn't accomidate different browsers via run-time configs -- some people really, really need/want their favorite browser -- the debate is therefore unwinnable, we need them all :P
As for the look-and-feel thing, I have stronger opinions, so I will try to say less -- I imagine that I will fail ;) First, I should note that there do exist some efforts to do this already in wine, like "icon tray" support, cut-and-paste, etc... so it's not like there's no precedent for what you propose, Dimi... (except maybe the WM thing I guess).
If you ask me, we should look to implement the (undocumented?) XP skinning API's -- with a deliberite sprinkling of internal extensions to clean up some of the messy parts if they are too slow for "built in" wine skins.
It's probably not /that/ difficult to figure out, especially if one is armed with something like WindowBlinds to hack on. After all, they figured it out at StarDock, (although they might have the "top secret" special sauce from MS for all I know...) and some of it is probably out there on the net.
Once you have a skinning API, you just implement a 'gnome compat' and 'kde compat' skin (or even just an automagical one that does both) the thing would "just work", right? Why, it shouldn't take more than a couple of hours ;) (WARNING: that last part was a joke, if you set your watch by this you very well may miss work for several years).
Might be harder than some other approach to this problem, but IMO it would be a waste to expend labor building "skins" into wine using some other architecture which might be non-orthagonal to that used by MS operating systems.
On Tuesday 29 April 2003 01:46 am, Gregory M. Turner wrote:
architecture which might be non-orthagonal to that used by MS operating
hrmph, s/non-//r. I will shut up and try to do some real wine work soon, I promise ;)
If you ask me, we should look to implement the (undocumented?) XP skinning API's -- with a deliberite sprinkling of internal extensions to clean up some of the messy parts if they are too slow for "built in" wine skins.
I think they are fairly well documented from looking at them a few months ago.
It's probably not /that/ difficult to figure out, especially if one is armed with something like WindowBlinds to hack on. After all, they figured it out at StarDock, (although they might have the "top secret" special sauce from MS for all I know...) and some of it is probably out there on the net.
WindowBlinds uses extensive hooking from what I recall - it made Windows (98) rather unstable. XP theming is different, it's actually built into the common controls library.
Once you have a skinning API, you just implement a 'gnome compat' and 'kde compat' skin (or even just an automagical one that does both) the thing would "just work", right? Why, it shouldn't take more than a couple of hours ;) (WARNING: that last part was a joke, if you set your watch by this you very well may miss work for several years).
I don't think we could do KDE skins, as (surprise) they depend on Qt which is GPLd. Most projects out there (mozilla, openoffice) use GTK theming engines.
Might be harder than some other approach to this problem, but IMO it would be a waste to expend labor building "skins" into wine using some other architecture which might be non-orthagonal to that used by MS operating systems.
On April 29, 2003 02:46 am, Gregory M. Turner wrote:
- (the original thread I believe?) what are the prospects of using wine as
a window manager?
Man, am I misunderstood or what? :) No, I've never suggested we use wine as a window manager. In fact, I explicitly said I don't what to needlessly duplicate code. Using the gnome panel & window manager, and what have you is good enough for me.
As for the browser issue, it's been discussed on the list ad infinitum and the consensus was that we should lean towards konq integration.
Is this in the context of the IWebBrowser interface? That is, how we go about providing an implementation for that interface? Well if so, I think it would be nice if we could have both khtml and gecko as backends for it. In fact, I think it'd be easier to have mozilla as a backend as they already implement the IWebBrowser interface. But that's just me talking, I should give this a try -- but after the 0.9 release! :)
If you ask me, we should look to implement the (undocumented?) XP skinning API's -- with a deliberite sprinkling of internal extensions to clean up some of the messy parts if they are too slow for "built in" wine skins.
Yes, I agree on this one -- I've said multiple times that implementing the theming API is the way forward. In fact, separating the drawing code will cleanup the controls I think, as we'll have a better separation between the presentation and logic layers. Moreover, it will allow us to have a cleaner solution for the win311, win95, win98, winxp looks.
But again, this looks like a post 1.0 project. We need to fix a lot of things in the controls for the 1.0 release anyway. I think it's more important to the a working set of controls, rather than a themable set of broken controls :).
Is this in the context of the IWebBrowser interface? That is, how we go about providing an implementation for that interface? Well if so, I think it would be nice if we could have both khtml and gecko as backends for it. In fact, I think it'd be easier to have mozilla as a backend as they already implement the IWebBrowser interface. But that's just me talking, I should give this a try -- but after the 0.9 release! :)
A gecko backend would be handy for apps that use MSHTML just as a convenience for browsing the web yeah, for apps that actually use the various quirks of IE and such we'd need to be able to control our own fork. Not sure how we'd detect which one to use.
Yes, I agree on this one -- I've said multiple times that implementing the theming API is the way forward. In fact, separating the drawing code will cleanup the controls I think, as we'll have a better separation between the presentation and logic layers. Moreover, it will allow us to have a cleaner solution for the win311, win95, win98, winxp looks.
But again, this looks like a post 1.0 project. We need to fix a lot of things in the controls for the 1.0 release anyway. I think it's more important to the a working set of controls, rather than a themable set of broken controls :).
Agreed. Theming and WebBrowser implementation is cool, but there's still way too much work to do just to let people install things reliably etc first.
For that, using Wine is a bit overkill; all you need is a PE loader and some glue code depending on what dll you are trying to load. You are much better off copying a few bits of Wine source into your app than trying to make use of the unmodified Wine dlls. That's basically the mplayer approach.
Perhaps, but for instance the quicktime codecs try and load comctl32 regardless so mplayer stubs that out and just tries to avoid triggering crashes - the whole thing is basically extremely fragile.
Plus there are things for which copy'n'paste isn't appropriate - the guy who was playing with Cubase VST plugins in Wine a few months ago for instance, VST plugins often require GUI support, registry, directsound etc etc.
Mike Hearn mike@theoretic.com writes:
Perhaps, but for instance the quicktime codecs try and load comctl32 regardless so mplayer stubs that out and just tries to avoid triggering crashes - the whole thing is basically extremely fragile.
Plus there are things for which copy'n'paste isn't appropriate - the guy who was playing with Cubase VST plugins in Wine a few months ago for instance, VST plugins often require GUI support, registry, directsound etc etc.
Just like I said, that's the case where it needs to be a Winelib app. Whether you build it with winebuild or winewrap or by adding -lwine is really a cosmetic issue. The only real problem is that currently it has to be a shared library, which isn't very nice and will eventually be fixed. But it makes no difference at all, neither at link time or at run time, whether the app calls only LoadLibrary and GetProcAddress, or calls 1000 different Windows APIs; you still need the full infrastructure one way or another.
For that, using Wine is a bit overkill; all you need is a PE loader and some glue code depending on what dll you are trying to load. You are much better off copying a few bits of Wine source into your app than trying to make use of the unmodified Wine dlls. That's basically the mplayer approach.
[OT] They arent merging/fixing their wine loader for months :)
===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War !
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth.
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
-
Alexandre Julliard -
Dimitrie O. Paun -
Dimitrie O. Paun -
Francois Gouget -
Gregory M. Turner -
Mike Hearn -
Mike Hearn -
Roderick Colenbrander -
Steven Edwards -
Sylvain Petreolle -
Vincent Béron