[Kde-bindings] KDE/kdebindings/csharp/ktexteditor

[Richard Dale]

On Saturday 26 July 2008 18:26:51 Arno Rehn wrote:
> On Friday 25 July 2008 19:24:44 Richard Dale wrote:
> > SVN commit 837777 by rdale:
> >
> > * Add a port of the KWrite shell to C#
>
> Heh, cool :)
>
> > * There are some problems to be solved:
> > 	* Accessing some functionality requires qobject_cast<>'s
>
> I added a C# one which looks and behaves the same way:
> T qobject_cast<T>(QObject obj)
OK good, and using qt_metacast()? - that's what I was thinking we needed.

> > 	* How should mono KDE apps be installed? Should they be installed into
> > 	  the bin dir, or they should they be started from a C++ shell like Ruby
> > 	  KDE apps?
>
> I think we should have a shell script together with each application which
> will simply call "mono <path/to/main.exe> $@". This will need to be
> configured by cmake to point to the correct path. the mono exe itself
> should be put together with all the libraries of the application in a
> seperate directory in lib/.
> So we have e.g. /usr/bin/foo, /usr/lib/foo/foo.exe and /usr/lib/foo/bar.dll
> As far as I know this is how all mono/.NET applications are installed.
Are they? We couldn't just exec 'kwritemain.monoexe' from the .desktop file?

> > 	* Couldn't see how to convert this call:
> > 		QTextStream input(stdin, QIODevice::ReadOnly);
>
> Either we have to map FILE* to IntPtr in kalyptus and create calls for
> stdin, stdout and stderr in smoke and C# or we create wrapper classes
> around QIODevice and System.IO.Stream so you can use an System.IO.Stream
> instead of a QIODevice and vice-versa. I'd prefer the latter one - it
> improves
> interopability between Qyoto and C# and keeps the file handle stuff out of
> the managed world (which isn't used anywhere in the .NET framework, afaik,
> aside from some convenience/compatibility methods)
OK, I'm not sure which is best, but we can't really have 'FILE *'s in any 
bindings. Perhaps we could special case stdin, stdout and stderr though in 
this sort of case.

> > 	* The KUrl.List class needs more work to be usuable with drag and drop
>
> Yes, there seem to be some bugs in kalyptus regarding which methods should
> be converted and which not.
I've had a look, and it really needs to be a List<KUrl> in general in the api. 
But we need to have a KUrl.List too which has the extra methods added to 
QList<KUrl> - I think we will need to do this manually as KUrl::List is 
excluded from the smoke lib.

See my recent commit for more issues with the KWrite text editor. I think it 
is a really good example to get working as there are quite a few general 
Kimono issues it brings up which need fixing. I got as far as loading a file 
today, but I needed to hack CreateInstance() in SmokeMarshallers.cs to work 
with Kimono.KEncodingFileDialog.Result

-- Richard