7 replies to this topic

[Brito]

As many may already know, KDE4 is now starting to be supported under Windows.

http://windows.kde.org/


I went onto their site to try out the latest release and report back my experiences and this way help a bit any other member interested in trying out their work.

The starting point is the KDE-Windows Installer: http://download.cegi...ndows/installer

About
=====

The KDEWIN Installer is aimed to be a installer tool to ease kde installation on windows.
See http://commit-digest...ues/2007-01-14/ for an article about the background of this installer.

State
=====
The gui installer is able to download, install and update packages from different internet ftp
or http location with or without using a proxy. The command line installer is only minimal working.

NOTES
=====
- see doc/readme.txt for more informations about the idea and backgrounds of the installer

- sources are located on http://websvn.kde.or...ewin-installer/

- the released version is build using a static qt release with specific configure
parameters, see section "static compile hints" for more informations

- to be able to use the update-mime-database package with kde please add the installation path to the
enviromment variable KDEDIRS

- runtime dependencies should be separated from the build requirement. perl for example is a build requirement of kdebase.
- some msi files are started without displaying a gui like perl. This should be fixed

This tool will download, install and compile all the apps you download.

------

• First you will need to create an empty folder on your disk (I recommend something short like c:\kde)
• Download the latest installer --> http://download.cegi...-gui-latest.exe
• Start the installer, type the folder path previously created (for some buggy reason it would give an abnormal error if I try to create a folder or select an already existent folder)
• Select the first web server (global) and don't modify any of the selected packages
• The program will download and install.

------

Once it is completed you find the programs read to execute inside the BIN folder.

You can now repeat the same steps but select all the packages you want to try out next.

--

This is all very preliminar as you will quickly find because the file explorer (konqueror.exe / dolphin.exe) are still very buggy but at the least all included games are working great.


Good luck with your tests!

[ispy]

Hi Nuno ,

Just a quick question am I given to believe that this KDE4 is a half way house or stepping/Bridging environment between Linux & Windows, sort of cross platform so 2 speak!

Or maybe a bit like "Wine" where windows programs will run on linux OP based systems.

I personally cannot wait for ReactOS to be generally available for the average "Joe" it seems to have a lot of promise but is a long time in the making?

Regards,

ispy

[Brito]

KDE4 is amazing because it brings the possibility of a rich desktop environment.

More detailed info here: http://en.wikipedia.org/wiki/KDE_4

The "secret" behind KDE4 is QT4 which allows to create programs that will work regardless of the OS running underneath (with some limitations of course): http://en.wikipedia....ki/Qt_(toolkit)

So you're not running anything emulated nor something like wine, these programs will run very smoothly but at the moment they've just began their jump into "our" windows based world and there are still a lot of rough edges to shave before we can consider it usuable.

For example, konqueror doesn't understand the concept of windows drives - under linux all drives and such are treated as subfolders placed inside a specific folder. So you have to manually type the drive letter to browse another partition.

--

Funny you mention reactOS because on that same day I also went to their site to download the latest unstable version and check for compatibility with KDE but the results weren't encouraging enough as the graphics simply took too long to be loaded or usuable.

This might also be an issue specific to qemu as I notice that under virtualBox the emulation is much smoother.

On real hardware ReactOS still didn't booted as expected and stopped on the part of "Installing drivers"

---------

My goal/dream would be a mix of both ReactOS with KDE4 and this way we would finally began having a free OS capable of running windows programs up to some extent with a good quality desktop.

ReactOS is still incredibly buggy, just wish they move along with their works as we see on the wine team.

MS is releasing new OS's that push incredible features but if we had a technologically "outdated" ReactOS it would surely become the starting point for a huge revolution as it was on unix world a few decades ago.

[Brito]

KDE4 is being built with portability in mind.

It would be great to carry it around on a pendisk and showcase to a few friends.

I've asked on the mailing list what would be needed to make KDE4 portable

> Do I need to install any Qt related service or add any registry keys
> to carry the kde base folder to somewhere else?

And a developer replied:

no, we are trying hard to avoid such dependencies. You should run
kbuildsycoca4 on the new machine.

Ralf

These are good news, anyone up to the task of trying this out?

[bobsobol]

Hey Nuno, thanks for the heads up and how to! I've been dying for this to break the ice since KDE2. Konquerer is a pretty fine alternative web browser as well as an FS browser, and I'd love to get to KOffice for the times when OOo just isn't cutting it.

Actually, KDE has always been QT based, and so is OOo, so if you use OOo (Open Office Org) on Doze, then you already know what QT looks like. OOo has an advantage in portability over KDE in that it is largely Java based... which is also holding it up from getting into x64 space right now, because Sun haven't gotten x64 builds of Java VM for Windoze or Linux.

KDE has been the most popular desktop environment on *nix OS for some time... Red Hat made it famous, though some of us still like a little Gnome in our PC.

Like Gnome, KDE isn't just a desktop however. But where Gnome provides the GTK (Gnome Toolkit) for RAD and system wide uniformal interface control and the Gnome Desktop Environment, KDE is all that, and GTK compatible too.

If you're wondering what this GTK thing is, that's how the Gimp has always been developed... so when you run the Gimp you are running GTK, and when you run OOo you are running QT.

KDE is only partly QT... the rest of it's RAD tools are KDE pure, but follow the same principals as QT... it's kinda like QT++. The effect is like moving from GDI to GDI Plus, and the QT structure compared to GTK is like moving from MFC to WPF in windows programming.

So most of what it gives is for developers, but because developers can use it to produce programs a lot quicker, with great results for the user interface, and without paying lots of money for a neat RAD development suite like Visual Studio, many of them do. Especially if they are not asking money for their software.

Once these building blocks are available to the windows world, most of that great software will become readily available to us here too. It's good news for all of us... even if you are a Linux or BSD fan, because with a wider audience to access software built for KDE, even more KDE based software will be written too. \o/

As for ReactOS, you may be one of the many people who have GFX card which is not supported by native ReactOS drivers yet... Support is very limited in this pre-beta stage, and sadly most of the manufacturer drivers installers (ATI and NVidia) don't recognize the ReactOS version of Windows and freak out. (well, refuse to install anyway) Sometimes a little hacking might get the driver from a working Windows install into ReactOS... but not if you can't get ReactOS to install at all.

Virtualised, ReactOS runs on VMWare, QEmu (not tried personally), VirtualBox and Virtual PC... I believe I got 2D hardware acceleration on VMWare, but only VBE (Vesa BIOS) to run on Virtual PC. It's a little while since I tried them all. VirtualBox has the advantage that it can run the x64 version IMS.

Regardless... KDE Desktop on ReactOS would be awesome as it's own Explorer.exe equivalent is still pretty lame. (No offense meant to the excellent efforts of the ReactOS team, I know it's not a priority, and serves it's purpose.)

[Brito]

Yes, no offense intended to the ROS team but the eye candy is an important key factor when considering a desktop OS.

I've basically stopped any attempts on KDE for windows for some time. I've moved full time to a linux box running Gnome and only use KDE4 occasionally (still learning the way of the gnome)

About ReactOS as an everyday OS - this just wouldn't work.

I've tried running the most usual apps for recovery purposes that we include on XP PE boot disks (that are quite smallish and self contained), few were the ones that actually worked and even fewer the ones that worked completely as expected or within a normal time of execution (programs would run way too slowly in some cases due to graphical bugs).

Let alone include KDE to hog it down even more, but I do keep the hope this can be possible one day.

-------------

It might be better to use a full KDE/Gnome under linux and then run all windows related programs under wine.

Lancelot recently published a script that adds .NET support for LiveXP and I *suspect* this might also work to install it on wine and add support for .NET under linux.

Then imagine a *nix machine running most common windows apps/games without any complications, would we still need ReactOS?

[bobsobol]

The Gnome is (IMHO) a nicer Desktop for Power Users... though KDE provides better RAD APIs to linux, so you kinda need it installed even if you don't use the desktop... just like you still need GTK even if you use Enlightenment or such for the desktop.

I still prefer BSD as Open Source Desktop OS... Linux is great for Server use, but BSD Portage rocks for making user installs easy, and keeping a desktop PC (which tend to install and uninstall more than Servers) neat and clean. It's just preference.

Would we still need ReactOS? I think M$ would say we never did! I would beg to differ. If you want to have a Windows based infrastructure, but need (and I mean NEED) the source, ROS is the way to go. There are many organizations which DO NEED the source of every key piece of software on their infrastructure for accountability.

Besides, I am still disapproving of X-Windows as a basis for Desktop WIMP (Windows Icons Menus and Pointer, more commonly called just GUI these days). If someone (someone fruity that is) released Cocoa, Crystal or Quartz for Linux I would be less scathing of it... but as most software is X-Windows based at some level, you either need to re-write the GUI, or at least KDE and GTK to work without X and on a more low level graphics system.

Additionally, once ROS can use all manufacturer drivers, and supports NTFS natively using standard Windows APIs, I think it will be a winner... even without any more eye candy than Win2K... and even without a decent explorer alternative. There are plenty of alternative desktops available.

I don't have GFX errors on my machine, and most stuff runs as expected, once you get past the setup program... very much like Wine. There are some issues with the Network stack... and that's not surprising, it took MS until Win2k to get a working stack, (that didn't need periodic reboots) and they are still fixing bugs in it now. Many things which are NT only expect security subsystems designed for NTFS and multi-user compatibility to be there... especially disaster recovery... so they don't work. Remember most of the API work was originally done to match Windows 95, and the 32-bit NT style kernel was bolted on afterwards.

Most enjoyable is that most of the software I write (in VB5, FreeBasic, Bloodshed or C++ Builder) works just fine. Again, you have more luck with other programs (Compiled with VC and such) if you copy over common libraries like VCRT, VBVM, DirectX, GDIPlus.dll etc from a working Windows install... the ROS team can't distribute those. You can also check dependencies and move over anything not yet in ROS, and that helps a lot.

Really, NTFS and TCP/IP stack is the biggest reason I don't use ROS more, but I keep checking in on them every now and then.

Interestingly, I have installed Windows on a Virtual Machine running on ReactOS... It performed admirably. But, I have also looked at ReactOS on laptops (where driver support will never fail to amuse) and the result was not pretty. So I know that running ReactOS on a live PC is, for the moment, more hit and miss than running a Hackintosh OS X install. This is the biggest reason ROS is no good for disaster recovery. But I remember the days when Linux biggest flaw was the lack of hardware support. (ahh, the heady days of trying to find somewhere that still sold a serial mouse, because Linux didn't support your PS/2 port, and an ISA 3COM 3c905 card and motherboard that still had ISA slots as that was the only card guaranteed to work.)

Indeed, compared to systems like SkyOS and even FreeBe (or whatever it is now marketed as, and which I personally think wonders of as I lament the loss of BeInc and it's x86/PPC OS greatly) I think ROS has a lot of traction, and watch it's development with great interest. I was impressed, even before it had a GUI, and could only run PEs designed for the command line. If nothing else comes of it, as developers, we will finally have a complete documentation of the Windows APIs as they work, not just as they are SUPPOSED to work.

When it reaches release maturity, I think there is also a lot of room for 3rd parties to "play" with improving the performance of a Windows system, and that could well feed back into MS installs. Initially as bolt on replacements for common Windows interfaces, but later as an integral part of every Windows install. Microsoft are not above learning (or, some would say stealing) from their peers. I don't think even a GPL license would stop them.

[was_jaclaz]

Since we are talking about possibly offending any of the GOOD ReactOS guys, I'll spend a few lines on them.

1) they are GOOD
2) they are GOOD programmers
3) they are missing a pragmatical objective

In my view, Linux users won't switch to ReactOS, ever.

Microsoft users may.

Thus, since Microsoft users already have (or should have) original Microsoft files and license, instead of a "binary" Black/White, 0/1, On/Off type of objective: you either run ReactOS or run MS Nt based systems, they could go for a "grey scale" one, or better "a suffusion of yellow" one.

We are missing a number of "no strings" attached files, just as an example:
minlogon.exe
ramdisk enabled SETUPLDR.BIN
not 512 Mb limited ramdisk.sys

Just as it happened for bootvid.dll, which "FULL" compatibility with MS one appears to be more a "collateral" effect than a "by design" one, or for the latest release of FREELDR that appears to be able to boot Server 2003, I think they should follow the "soft" path:
Today 99.99% MS files, 0.01% ReactOS ones
Tomorrow: 98.00% MS files, 2.00% ReactOS ones
Next week: 95.00% MS files, 5.00% ReactOS ones
Next month:90.00% MS files, 10.00% ReactOS ones
Next year: 50.00% MS files, 50.00% ReactOS ones
and so on, until you get to 100% ReactOS ones....



jaclaz