This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
RE: cygwin as a replacement for explorer.exe
- From: "Ralf Habacker" <Ralf dot Habacker at freenet dot de>
- To: <cygwin at cygwin dot com>
- Cc: "Sal" <vinnie_vidivici at yahoo dot com>
- Date: Sun, 10 Aug 2003 22:28:20 +0200
- Subject: RE: cygwin as a replacement for explorer.exe
> > > If you want a graphical file manager, take a look at the KDE for Cygwin
> > > suite of tools.
> >
> > For KDE see http://lists.kde.org/?l=kde-cygwin&m=103072530327420&w=2.
> >
> > General Informations about KDE/cygwin could be found on
http://cygwin.kde.org
Thanks for the pointer.
> > You can get more information on that by asking on the cygwin-xfree list.
>
> > If you're asking whether you can replace the Explorer desktop, taskbar,
> > and window manager with Cygwin tools/programs, I'm not sure if it's
> > possible
>
> This is one of the goals of the KDE/cygwin project.
>I highly doubt it. If you read on further in my message than the part you
>quoted, you'd see that I mentioned controlling and switching to/from
>Windows programs. If that is the goal of KDE/Cygwin, then I completely
>misunderstood what it's about. As I understand it, it's a desktop
>environment for interfacing with X programs only (i.e., Cygwin or remote
>ones), but not local Windows programs.
> Does the project *really* plan to support, for example, a system-tray
replacement showing the mouse driver
>icon? If so, *why*? ("Just to show we can" is as good a reason as any,
The KDE/cygwin efforts are based on the fact, that for many people switching to
linux from windows on the deskop isn't possible yet because of acceptance and
training costs for the new applications.
Our roadmap is to introduce KDE applications (along with the cygwin based
command line) application on windows (at first xfree based, at last without
xfree) so that the windows user could get familiar with KDE (and linux), which
increases the user and developer base for such applications. The more such
applications are running under windows, the easier is to introduce for example
the KDE desktop as explorer replacement or other main KDE applications like
Koffice, Kdevelop and so on. If KDE is widly used and accepted by windows users,
the way replacing explorer with the KDE desktop isn't very far. So if the whole
desktop is KDE based on windows, the additional task replacing the kernel by
linux seems much nearer.
If KDE/cygwin is a mostly complete desktop replacement for explorer and friends,
than it should integrate native windows applications (1) into kde's startmenu
(for example the control panel items) and (2) integrate running native
applications into the KDE taskbar and task switcher.
For (1), I have done a study and already working alpha release of the windows
control panel items integration which creates related kde startmenu entries
(desktop files).
For (2): There are plans to extend kicker (kde's taskbar application) to
recognize running native windows applications and to
display it into the taskbar. This seems not to be a very hard job. So why should
adding system tray icons not be possible ?
Let me tell you some histories of this project, so you can imagine what going
on:
I have started in 2001 Mai with kde1/cygwin/xfree, one year later released
qt2/cygwin/xfree and kde2/cygwin/xfree and this year qt3/cygwin/xfree and
kde3/cygwin/xfree. November 2002 a native port of qt2 has been started and now
the native qt3 gpl port is about 85% ready, which I have never believed before.
On the linuxtag dvd this year a complete cygwin and KDE/cygwin release along a
recent knoppix release was distributed. Klaus Knopper, who has build this dvd
said, that they had burned 5000 dvd's and they would need 1000 more to still all
the needs.
In August 22-24, on the KDE developer conference in Nove Havre one session is
about the KDE/cygwin state and how to prepare the KDE libs to support a native
windows based KDE port, which I have never believed before too.
So when I see this things happens, I could believe that we have a native kde 3
cygwin release based on in the beginning of the next year and implementing(1)
and (2) would only a question of time.
And last, Yes, there are some already known performance issues with cygwin like
fork, unix domain sockets and file io, but I'm sure, this will be captured by
the time.
Ralf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/