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

[Arno Rehn]

On Saturday 26 July 2008 19:41:17 Richard Dale wrote:
> 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.
Yes, internally it uses qt_metacast(). It first tries to do a simple cast in 
C# itself. If that fails, it calls a C method I added which then does the 
qt_metacast. If it's successful, a new instance of the target class is 
returned.

> > > 	* 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?
Yes, we could. But you can't execute desktop files from a shell like you can 
with real executables. So of course we should provide a .desktop alongside the 
application and the shell script. But the desktop file should just contain an 
"Exec=" entry pointing to the shell script.

> > > 	* 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.
Why is it excluded then? KUrl::List itself isn't a template class, so the 
calls declared in KUrl::List could be put in the smoke lib, couldn't they?

> 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
Yes, it'd be really cool if we'd get something like KWrite in C# working. It 
might be just a simple and small app, but it demonstrates that you can really 
do something with the C# bindings :).

-- 
Arno Rehn
arno at arnorehn.de