KDE for ReactOS

[Roland Leißa]

Hi,

I have read a bit of your homepage and a bit of the mailinglists.
Some people complained about the quite "ugly" GUI. Here my suggestion: Do not 
put your energy in improving the GUI for ReactOS. It would be nice when 
ReactOS will run on slow and older machines, too. But a ReactOS-Distro could 
include KDE (or GNOME) as default GUI. There will be a KDE- and a 
GNOME-version for Windows in a year or so. Hence it will also run on ReactOS 
(at least theoratically). So people who like to have a marvelous looking 
desktop enviroment can use KDE or GNOME. Besides there will be dozens of 
usefull application (just think of Kate, K3B, Kile, AmaroK, Konqueror, 
KOffice, KMail, Kontact, ...).
A ReactOS-Distro could, of couse, include all those packages and a 
linux-distro-like package manager. It would be great to see mingw-, qt-, 
gtk-, wx-, gnome- and kde-dlls. This would make a ReactOS-Distro very thin 
and lean because - for instance - every wx-application can link dynamically 
against the wx-library and so on.

-- 
Greetz,
Roland

[Mikko Tikkanen]

2005/10/17, Roland Leißa <ros_knue(a)web.de>de>:
>   Hi,
>
>  I have read a bit of your homepage and a bit of the mailinglists.
>  Some people complained about the quite "ugly" GUI. Here my suggestion: Do not
>  put your energy in improving the GUI for ReactOS. It would be nice when
>  ReactOS will run on slow and older machines, too. But a ReactOS-Distro could
>  include KDE (or GNOME) as default GUI. There will be a KDE- and a
>  GNOME-version for Windows in a year or so. Hence it will also run on ReactOS
>  (at least theoratically). So people who like to have a marvelous looking
>  desktop enviroment can use KDE or GNOME. Besides there will be dozens of
>  usefull application (just think of Kate, K3B, Kile, AmaroK, Konqueror,
>  KOffice, KMail, Kontact, ...).
>  A ReactOS-Distro could, of couse, include all those packages and a
>  linux-distro-like package manager. It would be great to see mingw-, qt-,
>  gtk-, wx-, gnome- and kde-dlls. This would make a ReactOS-Distro very thin
>  and lean because - for instance - every wx-application can link dynamically
>  against the wx-library and so on. 
Except that KDE or GNOME isn't really a Windows GUI nor can it run
Windows software (presuming on the applications you mentioned)...


-mikko

[Dmitrij D. Czarkoff]

On Monday 17 October 2005 02:01, Mikko Tikkanen wrote:
>   Except that KDE or GNOME isn't really a Windows
> GUI nor can it run
>  Windows software (presuming on the applications you mentioned)... 
Still this idea could be usefull after some rethinking.
ReactOS has its own implementation of win32 apps' GUI. On the other hand, we 
do have GTK+, Qt and some more crossplatform GUIs implemented on win32 
platform. So we can pass all the widgets stuff to one of them and drop the 
windows-native GUI (which is still slow and buggy). This would unify the GUI 
of the system and make the system more stable while easier configurable. This 
will let us use any popular X11 environment (or give a choise to user).
I think the preferable widget set would be GTK+ (because it's the most widely 
spread among alternative widget sets and its license is safe) and the 
preferable workspace would be GNOME (just because it's GTK+-based, popular 
and actively developed).
Technically this approache means makeing all the Windows GUI-related libraries 
the wrappers to the GTK libraries.
I think that such modification would be useful even without switching to some 
DE or WM from Linux world just because GTK is off and ready, while ReactOS's 
GUI is slow and buggy.

-- 
.0.
..0
000

[Richard Campbell]

I'm not arguing against new features in ReactOS, they just don't belong 
in the core project, as such, i will once again remind you that ReactOS 
is an attempt to create an operating system that is compatible with 
Windows Applications and Drivers.  If you change the UI, you'll break 
compatibiliy, not to mention you confuse the users, etc.  Also, it'd be 
quite difficult to make this work, we'd have to totally modify GTK+, 
which is pointless.

Dmitrij D. Czarkoff wrote:

>  On Monday 17 October 2005 02:01, Mikko Tikkanen wrote:
>   
>
> >  Except that KDE or GNOME isn't really a
> > Windows GUI nor can it run
> > Windows software (presuming on the applications you mentioned)...
> >     
> >  
> Still this idea could be usefull after some rethinking.
> ReactOS has its own implementation of win32 apps' GUI. On the other hand, we 
> do have GTK+, Qt and some more crossplatform GUIs implemented on win32 
> platform. So we can pass all the widgets stuff to one of them and drop the 
> windows-native GUI (which is still slow and buggy). This would unify the GUI 
> of the system and make the system more stable while easier configurable. This 
> will let us use any popular X11 environment (or give a choise to user).
> I think the preferable widget set would be GTK+ (because it's the most widely 
> spread among alternative widget sets and its license is safe) and the 
> preferable workspace would be GNOME (just because it's GTK+-based, popular 
> and actively developed).
> Technically this approache means makeing all the Windows GUI-related libraries 
> the wrappers to the GTK libraries.
> I think that such modification would be useful even without switching to some 
> DE or WM from Linux world just because GTK is off and ready, while ReactOS's 
> GUI is slow and buggy.
>
>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-general
>

[Robert Köpferl]

Sorry, but technically it seems you have no clue.
This gui stuff is difficult and not as easy as putting gt and k+ togehter.

Think of event handling not just painting. Or why is Ooo still without 
Cocoa UI?

Dmitrij D. Czarkoff wrote:
>   On Monday 17 October 2005 02:01, Mikko Tikkanen
> wrote:
>  
> >  Except that KDE or GNOME isn't really a
> > Windows GUI nor can it run
> > Windows software (presuming on the applications you mentioned)... 
>  
>  
>  Still this idea could be usefull after some rethinking.
>  ReactOS has its own implementation of win32 apps' GUI. On the other hand, we 
>  do have GTK+, Qt and some more crossplatform GUIs implemented on win32 
>  platform. So we can pass all the widgets stuff to one of them and drop the 
>  windows-native GUI (which is still slow and buggy). This would unify the GUI 
>  of the system and make the system more stable while easier configurable. This 
>  will let us use any popular X11 environment (or give a choise to user).
>  I think the preferable widget set would be GTK+ (because it's the most widely 
>  spread among alternative widget sets and its license is safe) and the 
>  preferable workspace would be GNOME (just because it's GTK+-based, popular 
>  and actively developed).
>  Technically this approache means makeing all the Windows GUI-related libraries 
>  the wrappers to the GTK libraries.
>  I think that such modification would be useful even without switching to some 
>  DE or WM from Linux world just because GTK is off and ready, while ReactOS's 
>  GUI is slow and buggy.
>  
>  
>  
>  ------------------------------------------------------------------------
>  
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-general

[Dmitrij D. Czarkoff]

On Monday 17 October 2005 04:11, Robert Köpferl wrote:
>   Sorry, but technically it seems you have no clue.
So true, but I never meant it to be easy any way.

>   Think of event handling not just painting. Or why is
> Ooo still without
>  Cocoa UI? 
You're talking about porting an app to another UI, but I say about
wrapping 
it. Say the program asks windows libs to draw a widget. Wrapper says: OK, and 
converts the request to GTK+. GTK+ asks GUI to draw a widget.
Yes, this is damn difficault, even more difficault than porting OOo to Cocoa.
But this way it would be much more tasty.

-- 
.0.
..0
000

[Aleksey Bragin]

The problem is that there is no 'native' API which we can use to bypass 
"buggy and slow reactos GUI".
GTK+ will still use the same "buggy and slow" GUI until it really gets 
"stable and fast" :-).

But if the KDE team will make KDE4 really a windows-shell replacement, then 
it is very interesting, and I'm for sure will be interested in getting KDE4 
to run under reactos.


WBR,
Aleksey Bragin.

----- Original Message ----- 
From: "Dmitrij D. Czarkoff" <czarkoff(a)yandex.ru>
To: "ReactOS General List" <ros-general(a)reactos.org>
Sent: Monday, October 17, 2005 11:48 AM
Subject: Re: [ros-general] KDE for ReactOS


On Monday 17 October 2005 04:11, Robert K?pferl wrote:
>   Sorry, but technically it seems you have no clue.
So true, but I never meant it to be easy any way.

>   Think of event handling not just painting. Or why is
> Ooo still without
>  Cocoa UI? 
You're talking about porting an app to another UI, but I say about
wrapping
it. Say the program asks windows libs to draw a widget. Wrapper says: OK, 
and
converts the request to GTK+. GTK+ asks GUI to draw a widget.
Yes, this is damn difficault, even more difficault than porting OOo to 
Cocoa.
But this way it would be much more tasty.

[Robert Köpferl]

> >  Think of event
> > handling not just painting. Or why is Ooo still without
> > Cocoa UI? 
>  
>  You're talking about porting an app to another UI, but I say about wrapping 
>  it. Say the program asks windows libs to draw a widget. Wrapper says: OK, and 
>  converts the request to GTK+. GTK+ asks GUI to draw a widget.
>  Yes, this is damn difficault, even more difficault than porting OOo to Cocoa.
>  But this way it would be much more tasty. 
That's exactly what the difficulties are.
It's not just wrap them. It is other philosophies, unknown, ohter 
different, callbacks, non-occouring events, painting orders.

That's the reason (from client site) for Ooo to have neither cocoa nor 
gtk UI. And why gtk for win lasts so long to come.

>   
>  
>  
>  ------------------------------------------------------------------------
>  
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-general