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

List:       kde-devel
Subject:    Re: KDE.NET
From:       Richard Dale <Richard_Dale () tipitina ! demon ! co ! uk>
Date:       2004-04-21 20:39:27
Message-ID: 200404212139.27605.Richard_Dale () tipitina ! demon ! co ! uk
[Download RAW message or body]

On Wednesday 21 April 2004 18:28, Martin Welch wrote:
> >>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 old version of C# uses a C library, but I'm working on one that uses the 
KDE SMOKE library. So it doesn't feature a one-to-one correspondence with 
unmanaged to managed methods anymore. It uses custom RealProxies, and there 
is only one unmanaged method call to RealProxy.Invoke() to implement the 
entire api. See the example code, and the calls to the proxy interceptors.

The example code doesn't have any Dllimport entry points like this:

[DllImport("/usr/local/bin/kde.net", EntryPoint="Control_SetName",
> 		CharSet=CharSet.Ansi, CallingConvention=CallingConvention.Cdecl)]



> 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:
OK, maybe you could build an SWF api on top of C# v2 bindings to the native Qt 
and KDE classes? I would say developing another C bindings library is not a 
good idea - I've recently scrapped the QtC and KDEC bindings, as it was the 
wrong way to go.

> ---------------------------------
> 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 (?). 
The entire api is autogenerated. Yes, there is a 1-1 correspondence between 
classes and members, but it doesn't work via a conventional C binding.

> 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?
I'm not sure how you subscribe - but it would be nice to discuss all 
approaches on the list. But I think you're trying to do something different 
to both Qt# v1 and Qt# v2/Kimono - I've personally never had a desire to 
implement SWF, or even thought about it. The only issue is whether or not 
it's a good idea to build SWF on top of the Qt/KDE C# api, rather than via 
its own custom C bindings.

-- 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]