[Kde-bindings] RE: KDE.NET

[Martin Welch]

>>I suppose the tradeoff is that if you wrote the logic in C#,
>>you be more likely to get other people to help out than if
>>they needed to write it in C++.

We'll need lots of both :)

>>The only thing is a name clash, if I start calling the SMOKE
>>Qt ones Qt.NET. What about Qt.SWF instead, does that seem
>>a good one?

Do you mean the project name or the namespaces? If it's the project name I'd
prefer to call mine KDE.NET rather than Qt.SWF since KDE.NET more accurately
reflects my goal. But the project name is the least of my worries!

Cheers!

Martin

-----Original Message-----
From: Richard Dale [mailto:Richard_Dale at tipitina.demon.co.uk]
Sent: 22 April 2004 19:46
To: KDE bindings for other programming languages
Subject: Re: [Kde-bindings] RE: KDE.NET


On Thursday 22 April 2004 18:58, Martin Welch wrote:
> >>Maybe a better starting point would be a cut down version of
> >>Qt# v1/QtC with all the unwanted classes removed.
>
> I know it goes against the grain to reinvent the wheel but I'm not
> convinced that using existing bindings is the right answer for two
reasons:
>
> First, the bindings won't deal with callbacks->delegates (?) so I've had
to
> override KMainWindow to do this. All the necessary bindings I've written
> use CMainWindow, not KMainWindow.
The SMOKE library has all the virtual method callbacks, so you can override
C++ methods in the target language. But then Kimono isn't working yet.

		protected virtual bool QueryClose() {
			return ProxyKMainWindow().QueryClose();
		}

> Second, consider the following:
>
> 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 one function, with one binding, I believe, if far better than the
> sequence of binding API's I'd need to call using the C bindings. There's
> less bindings and the performance would be better.
I suppose the tradeoff is that if you wrote the logic in C#, you be more
likely to get other people to help out than if they needed to write it in
C++.

> >>On the other hand if you
> >>don't use any KDE classes it won't really be a KDE project.
>
> Right. I want to create KDE.NET, not Qt.NET. I know I'm getting ahead of
> myself but perhaps one day I could create a KPart in C# - or VB!
>
> >>I wonder
> >>if there's any code that could be borrowed from the Gtk version.
>
> That's quite possible.
>
> >>one which uses Wine for maximum compatibilty
> >>with existing native code widgets
>
> I might be wrong here but I think most people use P/Invoke to handle the
> fact that SWF is actually quite limited and primitive. I know that's all
> I've used it for.
>
> >> I probably know stuff about polish()
>
> My lack of KDE knowledge is certainly slowing me down but then one of the
> reasons for starting this in the first place was to learn KDE programming.
> Any help is welcome :)
Well in C# expertise is very welcome. The only thing is a name clash, if I
start calling the SMOKE Qt ones Qt.NET. What about Qt.SWF instead, does that
seem a good one?

-- Richard
_______________________________________________
Kde-bindings mailing list
Kde-bindings at kde.org
https://mail.kde.org/mailman/listinfo/kde-bindings