Gtk# Port?

Feb 22, 2009 at 2:52 AM
Hi-

I really like ScintillaNET but it would be nice to be able to use it with Gtk# as well as Winforms and WPF. Can someone who is involved with the development tell me what sort of effort would be involved in adapting the library to also work with Gtk#.

Thanks.
Coordinator
Feb 22, 2009 at 3:34 AM
Honestly I haven't the foggiest idea about GTK or GTK#. I know that in more than a couple places in ScintillaNET a Windows/Windows Forms implementation is assumed. Pretty much all of the GTK specific details of Scintilla aren't implemented in ScintillaNET. I guess my advice would be not to start with this implementation . Start off with a from-scratch proof of concept that follows the basic guidelines of how to get a standard native GTK component into GTK#. Once you do that your choices are to try and change this implementation to accomidate GTK# or to keep adding to the new implementation.If you choose the latter option Scintilla and ScintillaNET's license permits you to use code from this project (see the license tab for details).
Coordinator
Feb 22, 2009 at 3:43 AM
HHHmmm.... It looks is though I may have made some assumptions in my post. Are you aware that ScintillaNET is a Windows Forms wrapper around the Native Scintilla Component? The native Scintilla component itself uses the GTK library so other GTK enabled applications can use it as well as Windows treats it as a native regular old Window Class. ScintillaNET's implementation is much like any other Windows Forms control's implementations that wrap and manage native Window Classes. If you can use the GTK# library's way of wrapping native GTK widgets the same way that Windows Forms does it, in theory it should work. This is what I was trying to suggest above.

You probably do know all of this, but if you didn't my previous post may not make a whole lot of sense :)
Feb 22, 2009 at 5:27 AM
Right. I get all of that. I guess the question would better be worded like:

Is ScintillaNET set up in a way where the interaction with the GUI layer (WinForms) is separate from the interaction with the native Scintilla?

That is, if I were to write the wrapper portion just for the interaction with Gtk# (mouse interaction, keyboard interaction, etc), could I use the rest of the ScintillaNET code that wraps Scintilla? I want to have the same interface with the native Scintilla library, but certainly wouldn't want to add Gtk as a necessary dependency to ScintillaNET.

You see, I'm interested in using Scintilla in an application that has both a Gtk# and WPF UI layer, with a common backend. If I can safely push all editor code to the backend, and only have the GUI layers create an instance of their respective control wrappers, that would be ideal. Otherwise, if I went with something like the GtkSourceView wrapper for Linux, I would have to maintain separate editor code to deal with things like language lexing and code completion on each platform. Plus, Scintilla is a much more mature editing component.

Anyway, thanks for the quick and helpful response.


On Sat, Feb 21, 2009 at 9:43 PM, chrisrickard <notifications@codeplex.com> wrote:

From: chrisrickard

HHHmmm.... It looks is though I may have made some assumptions in my post. Are you aware that ScintillaNET is a Windows Forms wrapper around the Native Scintilla Component? The native Scintilla component itself uses the GTK library so other GTK enabled applications can use it as well as Windows treats it as a native regular old Window Class. ScintillaNET's implementation is much like any other Windows Forms control's implementations that wrap and manage native Window Classes. If you can use the GTK# library's way of wrapping native GTK widgets the same way that Windows Forms does it, in theory it should work. This is what I was trying to suggest above.

You probably do know all of this, but if you didn't my previous post may not make a whole lot of sense :)

Read the full discussion online.

To add a post to this discussion, reply to this email (ScintillaNET@discussions.codeplex.com)

To start a new discussion for this project, email ScintillaNET@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Coordinator
Feb 22, 2009 at 7:18 AM
I'm sorry but you'll have to forgive my ignorance on GTK and GTK# because I really have no experience with either of them. That will probably make discussing it a bit difficult and frustrating :(

So a lot of ScintillaNET's higher level designs like abstracting Scintilla's flat API architecture into hierarchies and collections are just regular .NET classes. That code should be pretty universal. Same goes for the configuration system as that's mostly just interpreting XML files. As far as everything else goes it's all very "iffy" if you take it outside the vanilla Windows Forms on Windows OS context. At one time I created a proof of concept WPF app that uses ScintillaNET but I remember I had quite a lot of issues and I would never use it in a production app. I really have no clue how anything would work with GTK#. I assume you tried it out of the box, what was your experience with it. If you're here it means it didn't meet all your expectations ;) but did it even load at all? Paint, accept keyboard input? These are all things we had to figure out how to make work when creating a Windows Forms wrapper around Scintilla. The same process would have to be applied to any technology that in turn wraps ScintillaNET.

So the fundamental problem we have is all these abstraction layers around a really complex component:
Scintilla Uses GTK. GTK abstracts the OS Functions of handling IO like keyboard and mouse, painting, receiving commands from the containing application, sending notifications to the containing application, etc. That's what allows it to run on Windows, Unix and variants, and whatever other OSes that has a GTK library implementation.

ScintillaNET is heavily invested on Windows Forms and assumes Scintilla will be used in a Windows context. That means that it assumes Scintilla will
  • Be created via Win32 CreateWindowEx
  • receive and interpret Windows messages for mouse and keyboard
  • Use GDI to get/render fonts and such and ultimately Paint
  • Send WM_NOTIFY messages to the parent window for notifications (events)
ScintillaNET further complicates things by
  • We came across some weird MDI issues that would end up causing the Scintilla Window to be destroyed and recreated. Sctinilla doesn't like that very much and starts acting really funny. We reparent the Scitnilla Window to try and workaround it. We still haven't 100% solved all the issues around this. What this means for you is that we do funny non-standard things to make other things work in a highly Windows Forms Specific context that would probably cause problems with other wrappers.
  • We intercept all keyboard input and decide if we should pass it on to Scintilla or not. This is done for a couple reasons, one is for some added features, but primarily because Scintilla does keyboard handling in a manner that isn't consistent with most Windows text input controls, especially things like control keys. We handle these in ScintillaNET so that users get the behavior they expect and programmers get the right events fired. So again anytime we start tampering with basic IO handling and really start putting Windows Forms specific behavior and logic in it really messes with other implementations.
  • ScintillaNET has a lot of logic in place that intercepts WM_NOTIFY messages and in response fires .NET events in a manner that tries to be consistent with other Windows Forms Controls. We aren't 100% there but we're pretty close. This again binds it closely to Windows and things need to be just right in order for everything to work. When platform wrapping and emulation gets involved things tend to get fired in a different order or something else really small ends up causing huge problems.
  • ScintillaNET does a little bit of its own painting on top of Scintilla. This means GDI+ is involved on top of regular GDI. Off the top of my head I can only think of Markers, which are used for Drop Markers and Snippets. These are kind of "fluff" features though, not a wrapper of core Scintilla behavior.
  • ScintillaNET communicates with Scintilla by crafting Windows Messages and sending it to a subclass of Scintilla's DefWndProc. This actually shouldn't be a problem on any platform that can act as a Windows Forms Host. However if it is problematic you can invoke Scintilla's DirectFunction API, previous versions of ScintillaNET did this.
So what I guess I'm getting at is since we have so much code that is tightly coupled to Windows Forms (on Windows) I doubt you can inject some new code in a few key places to get it to work in a stable manner across WPF and GTK#. Unfortunately that's the nature of the beast, the majority of ScintillaNET's code is abstracting the behavior of Scintilla to make it more Windows Forms-ish, which wasn't easy as Scintilla is very complex.

I honestly think your best bet is to look elsewhere. Have you seen SyntaxBox? The feature set matches ScintillaNET's pretty closely and the part that I think will work for you is that it has no dependencies on native components like Scintilla. Now it does use a fair amount of Win32 calls using PInvoke but I'm pretty sure the chances of it playing nicely with WPF and GTK# are wwwaaayyyy better than ScintillaNET's. And yes, a co-author of ScintillaNET is endorsing a competing product. Let the religious wars begin! :D
Feb 22, 2009 at 5:21 PM
Chris-

Thanks for taking the time for this detailed reply. I think you've convinced me that it's not the best way to go for getting an editing component in Gtk#. I'm not sure SyntaxBox is much better if it relies on Win32/PInvoke calls since those will not work on Linux. I'll probably look into the new all-managed editor for MonoDevelop.

Thanks again for you help.

-Andy

On Sun, Feb 22, 2009 at 1:18 AM, chrisrickard <notifications@codeplex.com> wrote:

From: chrisrickard

I'm sorry but you'll have to forgive my ignorance on GTK and GTK# because I really have no experience with either of them. That will probably make discussing it a bit difficult and frustrating :(

So a lot of ScintillaNET's higher level designs like abstracting Scintilla's flat API architecture into hierarchies and collections are just regular .NET classes. That code should be pretty universal. Same goes for the configuration system as that's mostly just interpreting XML files. As far as everything else goes it's all very "iffy" if you take it outside the vanilla Windows Forms on Windows OS context. At one time I created a proof of concept WPF app that uses ScintillaNET but I remember I had quite a lot of issues and I would never use it in a production app. I really have no clue how anything would work with GTK#. I assume you tried it out of the box, what was your experience with it. If you're here it means it didn't meet all your expectations ;) but did it even load at all? Paint, accept keyboard input? These are all things we had to figure out how to make work when creating a Windows Forms wrapper around Scintilla. The same process would have to be applied to any technology that in turn wraps ScintillaNET.

So the fundamental problem we have is all these abstraction layers around a really complex component:
Scintilla Uses GTK. GTK abstracts the OS Functions of handling IO like keyboard and mouse, painting, receiving commands from the containing application, sending notifications to the containing application, etc. That's what allows it to run on Windows, Unix and variants, and whatever other OSes that has a GTK library implementation.

ScintillaNET is heavily invested on Windows Forms and assumes Scintilla will be used in a Windows context. That means that it assumes Scintilla will
  • Be created via Win32 CreateWindowEx
  • receive and interpret Windows messages for mouse and keyboard
  • Use GDI to get/render fonts and such and ultimately Paint
  • Send WM_NOTIFY messages to the parent window for notifications (events)
ScintillaNET further complicates things by
  • We came across some weird MDI issues that would end up causing the Scintilla Window to be destroyed and recreated. Sctinilla doesn't like that very much and starts acting really funny. We reparent the Scitnilla Window to try and workaround it. We still haven't 100% solved all the issues around this. What this means for you is that we do funny non-standard things to make other things work in a highly Windows Forms Specific context that would probably cause problems with other wrappers.
  • We intercept all keyboard input and decide if we should pass it on to Scintilla or not. This is done for a couple reasons, one is for some added features, but primarily because Scintilla does keyboard handling in a manner that isn't consistent with most Windows text input controls, especially things like control keys. We handle these in ScintillaNET so that users get the behavior they expect and programmers get the right events fired. So again anytime we start tampering with basic IO handling and really start putting Windows Forms specific behavior and logic in it really messes with other implementations.
  • ScintillaNET has a lot of logic in place that intercepts WM_NOTIFY messages and in response fires .NET events in a manner that tries to be consistent with other Windows Forms Controls. We aren't 100% there but we're pretty close. This again binds it closely to Windows and things need to be just right in order for everything to work. When platform wrapping and emulation gets involved things tend to get fired in a different order or something else really small ends up causing huge problems.
  • ScintillaNET does a little bit of its own painting on top of Scintilla. This means GDI+ is involved on top of regular GDI. Off the top of my head I can only think of Markers, which are used for Drop Markers and Snippets. These are kind of "fluff" features though, not a wrapper of core Scintilla behavior.
  • ScintillaNET communicates with Scintilla by crafting Windows Messages and sending it to a subclass of Scintilla's DefWndProc. This actually shouldn't be a problem on any platform that can act as a Windows Forms Host. However if it is problematic you can invoke Scintilla's DirectFunction API, previous versions of ScintillaNET did this.
So what I guess I'm getting at is since we have so much code that is tightly coupled to Windows Forms (on Windows) I doubt you can inject some new code in a few key places to get it to work in a stable manner across WPF and GTK#. Unfortunately that's the nature of the beast, the majority of ScintillaNET's code is abstracting the behavior of Scintilla to make it more Windows Forms-ish, which wasn't easy as Scintilla is very complex.

I honestly think your best bet is to look elsewhere. Have you seen SyntaxBox? The feature set matches ScintillaNET's pretty closely and the part that I think will work for you is that it has no dependencies on native components like Scintilla. Now it does use a fair amount of Win32 calls using PInvoke but I'm pretty sure the chances of it playing nicely with WPF and GTK# are wwwaaayyyy better than ScintillaNET's. And yes, a co-author of ScintillaNET is endorsing a competing product. Let the religious wars begin! :D

Read the full discussion online.

To add a post to this discussion, reply to this email (ScintillaNET@discussions.codeplex.com)

To start a new discussion for this project, email ScintillaNET@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com