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.