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.
2005/10/17, Roland Leißa ros_knue@web.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
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.
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-general
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-general
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.
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@yandex.ru To: "ReactOS General List" ros-general@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.
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@reactos.org http://www.reactos.org/mailman/listinfo/ros-general
-
Aleksey Bragin -
Dmitrij D. Czarkoff -
Mikko Tikkanen -
Richard Campbell -
Robert Köpferl -
Roland Leißa