[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    RE: KDE.NET
From:       "Martin Welch" <martin () welch ! eclipse ! co ! uk>
Date:       2004-04-21 17:28:08
Message-ID: GIEKKMAAMELBNKEJJKHGAEAJCNAA.martin () welch ! eclipse ! co ! uk
[Download RAW message or body]

>>I'm interested in hearing what you've done.

No problem.

>>The problem is that C# doesn't interface easily with C++,
>>and you usually need to do C bindings first.

'easily' is an understatement! Figuring out mangled names for multiple
compilers is not my idea of fun. Yes, I've had to write C bindings, but the
approach I've taken should minimise this.

The approach I've taken is different from Qt# in that:

* I want to develop KDE (not QT) applications that ideally are portable. The
potential to develop in-house line-of-business apps that can run on linux is
what appeals to me. My development skills are largely windows based, just
like most dotNet developers. My biggest concern with the Qt# approach is
that dotNet developers will be faced with another class hierarchy, rather
than the one they're familiar with - SWF. The work I've done so far allows
the following code to run as a native KDE app:

---------------------------------
using System;
using System.ComponentModel;

using System.Windows.Forms;

namespace Test
{
	class MainFrame : System.Windows.Forms.Form
	{
		public MainFrame()
		{
			this.Load += new System.EventHandler(this.OnLoad);

			this.IsMdiContainer = true;

			this.Text = "Hello World";
		}

		[STAThread]
		static void Main(string[] args)
		{
			Application.Run(new MainFrame());
		}

		private void OnLoad(object sender, EventArgs e)
		{
			Console.WriteLine("MainFrame.OnLoad");

			MDIChild child = new MDIChild();
			child.MdiParent = this;
			child.Show();
		}
	}
}
---------------------------------
using System;
using System.ComponentModel;

using System.Windows.Forms;

namespace Test
{
	class MDIChild : System.Windows.Forms.Form
	{
		public MDIChild()
		{
			this.Load += new System.EventHandler(this.OnLoad);

			this.Text = "MDI Child";
		}

		private void OnLoad(object sender, EventArgs e)
		{
			Console.WriteLine("MDIChild.OnLoad");
		}
	}
}
---------------------------------
BIN =/usr/local/bin

CLASSES= \
      MainFrame.cs \
      MDIChild.cs

MDITest.exe: $(CLASSES) $(BIN)/kde.net.so $(BIN)/KDE.Windows.Forms.DLL
	cp $(BIN)/KDE.Windows.Forms.DLL .
	mcs $(CLASSES) -r KDE.Windows.Forms.DLL /out:MDITest.exe
---------------------------------

* The Qt# approach favours a 1-1 relationship between C# and it's
corresponding C++\Qt class. This'll need a binding for every member of every
Qt class (?). I'm looking at a library that supports SWF (initially) where
the bindings are as thin as possible. For example:

void CMainWindow::SetIsMdiContainer(bool value)
{
	if ( value == true )
	{
		if ( m_pWorkspace == 0 )
		{
			QVBox* vb = new QVBox( this );
			vb->setFrameStyle( QFrame::StyledPanel | QFrame::Sunken );
			m_pWorkspace = new QWorkspace( vb );
			m_pWorkspace->setScrollBarsEnabled( TRUE );
			setCentralWidget( vb );
		}
	}
}

This single managed->unmanaged call, I think, would be more efficent than
several/many 1-1 calls. The bindings could be reduced further if state is
maintained on the managed side, e.g:

namespace System.Windows.Forms
{
	public class Control : System.ComponentModel.Component
		/* , ISynchronizeInvoke, IWin32Window */
	{
		public IntPtr Handle
		{
			get {return m_Handle;}
		}
		protected IntPtr m_Handle = IntPtr.Zero;

		[DllImport("/usr/local/bin/kde.net", EntryPoint="Control_SetName",
		CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl)]
		private static extern void Control_SetName(IntPtr widget,
[MarshalAs(UnmanagedType.LPStr)]string name);

		public string Name
		{
			get {return m_Name;}
			set
			{
				m_Name = value;
				Control_SetName(m_Handle, value);
			}
		}
		private string m_Name = "";

		.
		.
		.
	}
}

Now you're probably wondering why I don't just wait for (or help out with)
Mono's SWF implementation. Well, a) I just wanted to see if/how it could be
done and b) I think  Mono's SWF will always favour GNOME and I just prefer
KDE.

Incidentally, kde-bindings@kde.org doesn't get a mention on the www.kde.org
page. I assume I just send 'subscribe' to this address?

Cheers!

Martin

-----Original Message-----
From: Richard Dale [mailto:Richard_Dale@tipitina.demon.co.uk]
Sent: 20 April 2004 08:31
To: kde-devel@kde.org
Subject: Re: KDE.NET


On Monday 19 April 2004 23:17, Richard Moore wrote:
> Talk to Richard Dale, he's developing the C# bindings. They're
> actually making a lot of progress.

>
> On Mon, Apr 19, 2004 at 11:08:04PM +0100, Martin Welch wrote:
> > Are there any initiatives to bring KDE and .NET together?
> >
> > I've searched the archives and can only find references to a theme, an
> > april fool and Qt#.
> >
> > I get the impression from the Mono archives that Qt#'s progress is slow
> > and that the KDE developer community is somewhat against the idea.
> >
> > This is slightly more than an idle curiosity as I've spent a few
evenings
> > developing the beginnings of such a beast.
> >
> > I'd appreciate your thoughts.
I'm interested in hearing what you've done. The problem is that C# doesn't
interface easily with C++, and you usually need to do C bindings first. Qt#
v2/Kimono will use the SMOKE library via custom RealProxies, and SMOKE does
a
lot more than the obsolete QtC C bindings.

You could join the kde-bindings@kde.org list to discuss your approach and/or
help out with Kimono.

I've attached an example of how the Qt# v2/Kimono api looks -
KMainWindow.cs.

To generate the entire api to review it, you can edit
kdebindings/smoke/kde/generate.pl.in and change '-fsmoke' to '-fkimono'.
Then
configure kdebindings with a '--with-smoke=kde' option, and the sources will
be generated in the smoke/kde directory.

-- Richard



 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]