Contributing: Drawable, better text rendering and helping the Android platform

[allsorts46]

Creating an issue probably isn't the right way to do this, but as GitHub has no private messaging feature this seems like the only way to make contact.

I am the main developer of a commercial EPOS system, a fairly large project built around Windows Forms. We have been experimenting with ways to be able to run on other platforms without having to re-implement too much. We got the server-side components running under Mono on Linux pretty easily, but the client wasn't so easy - Mono's implementation of Windows Forms is quite poor and most of our interface ends up weird-looking or completely non-functional. Rewriting everything using something like GTK# isn't practical due to the huge quantity of existing Windows Forms interface code.

I've discovered Eto.Forms and it looks perfect for the task, due to the ability to embed Eto.Forms inside Windows.Forms, and vice versa; we can spend a little initial effort switching the main UI window over to Eto, then port the many plugins gradually, one at a time. Plugins for which we port the UI to Eto can be available under all platforms, and plugins we haven't got around to yet can stay as Windows.Forms and only be available under Windows using the embedding.

I've been playing with this idea for a few weeks, and had much success. Eto is a fantastic project and looks to be very healthy and active. However I encountered a few areas that don't quite work as we need, mainly because we use a lot of custom-drawn controls (directly inheriting from Control and using OnPaint to draw).

• The support for text rending (Graphics.MesaureString, DrawText) is very limited and doesn't support any kind of wrapping.

• It seems that only the Drawable control allows this kind of custom painting. This is fine for most of our custom controls, but a few of them are based on modifying existing controls like ToolStrip.

• The Android platform is very, very far behind the others, which is a great shame.

I cloned the repository locally and made an attempt at addressing some of these issues, and found it surprisingly easy, thanks to the good design of the library. I believe that if we commit to using Eto, I will be able to overcome any limitations I encounter.

Of course, I would love to contribute back to the project, if you feel my changes are beneficial. I've read the 'Contributing' page on the Wiki, but still have questions:

• Given the many platforms Eto targets, how 'complete' do changes have to be made to be accepted? For example, I have added additional overloads of MeasureString and DrawText which support wrapping within a bounding rectangle. I've implemented this for Windows Forms, WPF and (in progress) Android. However I do not have a Mac or an iPhone and have no experience working with GTK#. What should be done in this case? Leave the new methods simply missing so those platforms don't build? Leave the methods with an empty implementation (do nothing)? Throw NotImplementedException? Wait for another developer to implement the missing platforms before the code can be accepted?

• Is there a process for discussing design? I've implemented the above mentioned text rending methods in a way that is familiar to me from using Windows Forms, but perhaps it isn't the best 'cross platform' design. Should I open an 'issue' for every new change I am thinking of making, and wait for feedback? I need to balance this against my own need to get work done rapidly, though.

• I want to make a significant contributions to the Android platform, and bring it up to the standard where we can host a couple of our most critical interfaces (e.g. the till interface and kitchen prep screen) using the same code shared between Android/Windows. I've made an effort on this this evening and already have a working implementation of Drawable, but had to 'hack' a lot of things relating to graphics objects like fonts and brushes. Is there much interest in getting the Android platform up to standard? Is there anyone who'd want to work with me on this? I am happy finishing implementing the missing controls and completing the implementatin of Graphics, but I'm not very familiar (yet) with how Eto or Android do control layout. Also, no idea what the concept of a 'Form' means on mobile - and don't have an iPhone to try out the iOS platform to see what you've done there.

Thanks for any feedback. Very happy with this framework and will definitely be modifying it and using it for Vantage, but keen to give back whatever I can.

[cwensley]

Hey @allsorts46,

Thanks for taking the time to share your thoughts about contributing to Eto.Forms! Hopefully I can answer some of your questions.

I've discovered Eto.Forms and it looks perfect for the task, due to the ability to embed Eto.Forms inside Windows.Forms, and vice versa; we can spend a little initial effort switching the main UI window over to Eto, then port the many plugins gradually, one at a time

Yes, this ability to integrate with existing frameworks seems to have helped a LOT of projects. I would recommend looking into Eto's WPF port as it does get better support. You can still embed it into existing WinForms (using ElementHost) and embed winforms controls into it using Eto.Wpf.Forms.WindowsFormsHostHandler. Though I understand if you still use Eto's WinForms platform, just know that some features might be missing (e.g. drag 'n drop features in GridView and TreeGridView are lacking, etc).

how 'complete' do changes have to be made to be accepted? ... Leave the new methods simply missing so those platforms don't build? Leave the methods with an empty implementation (do nothing)? Throw NotImplementedException? Wait for another developer to implement the missing platforms before the code can be accepted?

I don't like to see incomplete implementations merged into Eto.Forms, because that just causes problems for developers trying to use it. The main platforms that require implementations are Wpf, Gtk, Mac64, and XamMac2. Everything must compile to pass the CI check (except iOS and Android), so stub implementations should be added. I will only accept pull requests with incomplete implementations if issues are created to get them implemented for the next release. It would be ideal to have someone willing to implement the missing platform implementations before the PR is accepted (feel free to ask, I don't mind doing Mac/Gtk stuff, and there are others that may be willing to do Gtk).

One huge gotcha with incomplete implementations without fully vetting all the platforms is that it might very so greatly that the API design in Eto may need to change. It is prudent to at least research the different platforms to ensure that the API can theoretically work first. I can usually help in this regard.

Is there a process for discussing design? I've implemented the above mentioned text rending methods in a way that is familiar to me from using Windows Forms, but perhaps it isn't the best 'cross platform' design. Should I open an 'issue' for every new change I am thinking of making, and wait for feedback? I need to balance this against my own need to get work done rapidly, though.

The process is to submit a PR with proposed changes and begin a discussion. The PR doesn't need to be fully complete, the PR would only be merged when you give the go-ahead.

I understand the balance of getting things done efficiently. You don't need to separate the issues completely, though it is very helpful to only have to review one set of changes at a time. For example, one PR for the Eto.Drawing changes, one PR for Android updates, etc would be acceptable. Having to review a huge pile of different changes in one PR is tedious and basically puts the extra time on the reviewer. This will typically cause a delay in a response and the review.

Is there much interest in getting the Android platform up to standard? Is there anyone who'd want to work with me on this?

I unfortunately have had very little feedback about getting Android updated (especially since Xamarin.Forms' arrival), though there may be devs willing to help. I do not have time personally to put towards this, so to keep the barrier to implementing it low I can merge Android-specific PR's quite willingly without much (any?) need for a review. I do much the same with the Gtk platform at the moment.

Very happy with this framework and will definitely be modifying it and using it for Vantage, but keen to give back whatever I can.

I'm really glad to hear that you are finding Eto.Forms useful! I (and everyone) are very appreciative of any contributions whether it be bug reports, wiki updates, or PR's.

[allsorts46]

Thanks very much for the detailed reply. We use git internally and have done for years, but I'm new to GitHub and haven't made a pull request before. I'll submit one or two small ones soon to get familiar with it before trying to submit something big like the Android changes.

I'm happy to implement all changes for Winforms, WPF, Android and (in theory - having some issues) GTK, but I'll definitely have to ask for help with Mac and iOS as I have no experience with it or access to a Mac or iOS device to work on.

Regarding GTK, I've been able to build and run with the older GTK2 project, but the newer 'plain' GTK project gives me an error when running on Linux about GTK 2 and 3 libraries being both loaded in the same process. I'll try a bit more to resolve this myself before opening a separate issue for it.

Just a final question about design discussions: I understand in general the process is just submit proposed changes and get them reviewed, but what about more abstract discussions before implementation? Is it possible to submit a PR without any actual code changes (i.e. just comments) and work from there?

[cwensley]

Hey @allsorts46,

I'll submit one or two small ones soon to get familiar

Sounds great!

but the newer 'plain' GTK project gives me an error when running on Linux

Hm, are you running Eto.Test.Gtk, or Eto.Test.Gtk3? It shouldn't be using GTK#2 or GTK#3 assemblies, but the specific ones included in the nuget packages. I know in some cases Eto.Test.Gtk3 on linux can't run with GTK#2 installed and vice versa.

but what about more abstract discussions before implementation? Is it possible to submit a PR without any actual code changes (i.e. just comments) and work from there?

Just open an issue in that case. It's the same as a PR, but with no code attached. (;

[cwensley]

Closing this as I believe the question was answered. Let me know if you have further questions regarding contributions to Eto.Forms. Thanks!