Well I'm really hoping for the packaging format, because I'm looking to port a MUD client to windows (where it'll be a pretty good competition to the existing similar windows programs).<br><br><div class="gmail_quote">
On Dec 18, 2007 6:24 PM, Shane King <<a href="mailto:kde@dontletsstart.com">kde@dontletsstart.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Just had a few thoughts about how KDE is going to work on Windows as a<br>finished product somewhere along the line. For background, my blog post<br>about Amarok Windows releases:<br><br><<a href="http://amarok.kde.org/blog/archives/550-Windows-binaries-and-packaging.html" target="_blank">
http://amarok.kde.org/blog/archives/550-Windows-binaries-and-packaging.html</a>><br><br>As I see it, sometime in the not too distant future, Amarok 2 is going<br>to go alpha on Linux, and we'd like to go alpha on Windows too. The
<br>difficulty is that you can really only have one KDE 4 installation per<br>user (or at least only be running from one installation at a time), so<br>to play nice with others, Amarok can't really package its own KDE
<br>libraries, there needs to be an "official" distribution.<br><br><br>For this to happen, I think we'd need to do the following:<br><br>* We need to pick a compiler. Keeping things compiling under multiple
<br>compilers is a good thing so we can change with circumstances, but for<br>releases to work we need an official compiler.<br><br>Lets be honest: MSVC compiles faster, produces smaller binaries, (IMO<br>seems to) produces faster code, has a better debugging environment, is
<br>the standard for windows development, just works with the PSDK without<br>having to write your own headers and hasn't had the lead developer quit.<br>On the other hand, the politics of choosing it over mingw are difficult.
<br>Not sure how you decide that one, glad it's not my call. ;)<br><br>* We'd need to have sort of nominal release schedule so that we can<br>point people to it and say "yes, bug X is fixed and in the next release,
<br>we hope to have it out in 2 weeks". Of course we have very limited<br>resources so we can't commit to anything concrete, but having a vague<br>idea of when the next release is coming and what will be in it would be
<br>nice.<br><br>* Maybe not straight away, but we probably also need a real packaging<br>format (with thing like pre-inst/post-inst scripts etc) so third parties<br>can make packages against the base system. Ideally I should be able to
<br>do something like make my own Amarok package and send it out to test a<br>bug fix and others can just install it so long as they have the<br>dependencies installed via the installer.<br><br>Is porting something like dpkg or rpm even remotely possible/sensible?
<br>Or is it easier to just to a simpler custom implementation?<br><br><br><br>Now perhaps it's too soon to start thinking about this, but just like<br>KDE on Unix going to release in part because they hope it will attract
<br>interest, perhaps there's merit in doing the same thing on Windows?<br><br>Thoughts? Has this been discussed before in the past and I've missed it?<br>I did a quick google search but it didn't turn up anything quite along
<br>these lines.<br><br>As I said on my blog post, yay for Linux and someone else having to deal<br>with turning source into binaries. :p<br><br>Shane.<br>_______________________________________________<br>Kde-windows mailing list
<br><a href="mailto:Kde-windows@kde.org">Kde-windows@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/kde-windows" target="_blank">https://mail.kde.org/mailman/listinfo/kde-windows</a><br></blockquote></div><br>