[Kde-bindings] RE: KDE.NET

[Martin Welch]

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

I've discovered that (so far) 90% of the effort is in figuring out how to
implement SWF in Qt rather than the bindings. I spent far longer, for
example, finding out that a call to polish() is the best place for a
callback for Form.Load than implementing Form.Load. Implementing SWF using
Qt# will still need that 90% effort.

My other reservation would be that SWF->qt#->smoke may get a little too
top-heavy from a performance point of view ?

>>But I think you're trying to do something different
>>to both Qt# v1 and Qt# v2/Kimono

I'm inclined to agree with you here.

>>I've personally never had a desire to implement SWF,
>>or even thought about it.

I'm convinced that an implementation of SWF is critical since 100% of .NET
windows forms developers are already familiar with it. Very, very few .NET
developers are familiar with Qt.

I've just subscribed to kde-bindings - shall we continue this on
kde-bindings instead?

Cheers!

Martin

-----Original Message-----
From: Richard Dale [mailto:Richard_Dale at tipitina.demon.co.uk]
Sent: 21 April 2004 21:39
To: kde-devel at kde.org
Subject: Re: KDE.NET


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