Languages

Menu
Sites
Language
Announcing MonoTizen

On 19th May 2014, Bob Summerwill announced the availability of funding to add Tizen Support to Mono.

That announcement was the beginning of a broader project being run by Kitsilano Software to build a .NET development stack for Tizen.

MonoTizen is an independent project, which is not affiliated with either the Mono or the Tizen development teams. All trademarks are copyright of their respective owners.

Follow @monotizen on Twitter to keep up-to-date on our progress.

See About page for more details on MonoTizen.

ORIGINAL POSTING AT - http://monotizen.wordpress.com/2014/05/21/announcing-monotizen-project/

 

List

Responses

13 Replies
Bob Summerwill

In relation to ... http://mono.1490590.n4.nabble.com/Adding-Tizen-support-to-Mono-td4662858.html

I am still seeking a contractor or contractors who are willing TO BE PAID to get Mono working on Tizen.     This should not be a hard task, considering Tizen's Linux heritage.

If you interested in talking more about that, please do contact me via Twitter, LinkedIn or e-mail (as per the Mono forum posting link above).

 

Cheers, Bob Summerwill

Corstian Boerman

Oh wow, this is sweet! :)

Bob Summerwill
Thanks for that, Corstian! I will be at The Tizen Developer Conference in San Francisco if anybody wants to talk about this opportunity in more detail. I would really like to be paying somebody to do this fun work by the end of this week! Here is what I am looking for: http://monotizen.wordpress.com/2014/05/24/what-are-you-looking-for-in-a-contractor-for-monotizen/ Please do contact me (http://bobsummerwill.wordpress.com/contact-bob/) if you are interested. Also, if anybody has suggestions on other forums where qualified candidates might be hanging out, I would love to hear them! Linux developers forums, etc. I don't want to be an annoying spammer, but I do want to ensure that the right people are aware of the opportunity. Again, to clarify, I want to pay somebody to port the Mono Runtime to Tizen in the open on Github so we can get that support upstreamed into the Mono mainline. Cheers, Bob Summerwill Kitsilano Software
Nikita Kalyazin

Hi Bob,

 

Your idea and enthusiasm look very appealing.

Do I understand you correct, you're going to use Mono in Tizen mostly for UI applications?

If so, what graphic framework are you considering? C# wrappers for OSP, porting Gtk# for Tizen or something completely different (like Xamarin does)?

Bob Summerwill

 

Thank you!

MonoTizen will just wrap all the existing C++ APIs in C#, so that application developers can write "Native" applications in C#, rather than C++.

That probably means wrapping Qt and EFL and OSP, because different developers are using all of these UIs.

I asked a question about Gtk# only because that is the UI which MonoDevelop uses.     I think that it should be possible to run MonoDevelop IDE on a Tizen device, but that Linux -> Tizen port would require GTK+ to be ported to Tizen.     If you could run the IDE on device, that would mean, for example, that a teenage developer in a developing nation who had just bought a cheap Tizen device could actually use the device itself for the development of Tizen applications.    Just buying a Tizen device could be enough to open up the world of Tizen development to anybody around the world.

I want to help the next Mr Flappy Bird to have a good idea, and to be able to bring it to the world.

 

Cheers,

Bob

Nikita Kalyazin

Thanks!

A couple more questions.

What API are you going to wrap with C# OSP/Qt/EFL bindings (I mean what underlying API will be used)? Native OSP, EFL, Xorg/Wayland? If it is anything beside OSP, you will probably face same obstacles with Tizen Store as Tomasz does with Qt.

When you are talking of MonoDevelop IDE running on a Tizen device, do you suppose plugging monitor/keyboard/mouse to the device or you have an idea on making it convenient to develop apps on bare device (small screen, screen keyboard, etc)?

Bob Summerwill

Thanks for the questions and interest, Nikita!

The plan is to bind EVERY native API in every Tizen profile, and in Tizen:Common.    No need for me to try to "pick winners".    That will mean that you can build applications which will not be accepted in the Tizen Store today, but that's nothing specific to the C# bindings.    It is just reflecting the same unresolved issues which are present for C++ native developers.    I have hope that those issues will be resolved.    Even if they are never resolved in the Tizen Store, you could still build those applications for open Tizen platforms - like the NUC.    Perhaps somebody will do an open handset too?

For the MonoDevelop questions, I am imagining that having an external monitor will be the best approach.    Tablets might be just about workable directly.    Phones directly would probably be pretty nasty.    That just gets us going.    The next step would be to build some touch-specific UI for MonoDevelop, if that "IDE on device" model proves successful.

Cheers,

Bob Summerwill, Kitsilano Software

Bob Summerwill

I am delighted to announce that Crosstwine Labs (Damien Diederen) will be contracting for Kitsilano Software to bring the Tizen support in the Mono Runtime up to spec ...

http://monotizen.wordpress.com/2014/06/13/monotizen-contractor-found-crosstwine-labs-damien-diederen/

 

Bob Summerwill

PS.   I am still to determine the OPTIMAL ORDER in which to build all the native C++ bindings.

We'll do them all, but I'm not sure which to prioritize.

We'll start with NO bindings, which will just let you build console applications.   Then we'll need to go "bottom up" through the API stack.    Before too long, though, there will be choices to be made.   OSP first?   Qt first?   EFL first?     Focus on Tizen 2.x or Tizen 3.x?

Getting to a subset of bindings which will allow applications to be submitted to the Tizen Store is obviously important for early adoption.    Building a finished vertical stack for one of the UI toolsets is obviously of more value than having incomplete support for multiple of the alternative APIs.

If anybody has analyzed all of the native APIs, and their layering, and has a nice diagram which could help me determine a sensible ordering, please do let me know!

 

Cheers,

Bob Summerwill, Kitsilano Software

Bob Summerwill

 

Like this ... https://wiki.tizen.org/wiki/Common_Packages ... but including dependencies?    And including IVI and Mobile specific packages?

We also need to distinguish between applications/services and libraries with external native C++ APIs.

John Ixion

Hi Bob,

OSP (and the Store) is the best choice imo; Mono will be integrated in the Tizen SDK ?

Bob Summerwill

In the short term, yes, I think OSP is looking like the obvious starting point.

That is exactly where I started a year ago ... https://github.com/kitsilanosoftware/HelloTizen

As to whether Mono will be integrated into the Tizen SDK ... I'm mixed on whether that would be a good thing.    It would take strict versioning-control of Mono out of the hands of developers, and take us back into "DLL Hell".    Yes, you would save on app download size, but at what cost.     Unity3D applications always ship with the embedded Mono within the application.   I think that's a good choice for MonoTizen too.

Check out http://www.hanselman.com/blog/IntroducingASPNETVNext.aspx.   Microsoft just open-sourced the next version of ASP.NET.    With that version you can run ASP.NET websites on top of either MS.NET or Mono, and run them on Windows, Mac or Linux.    The website deploy includes all assemblies, down to and including the .NET Framework itself.    You essentially have a run.bat or .sh script in the root which lets you run the server-side application with NO external install requirements.

Watch http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DEV-B385.   Their best "trick" is building an ASP.NET website on a PC in Visual Studio, selecting Mono as the .NET Framework and deploying to a USB memory stick, transferring that USB stick to a Mac, running the shell script and then viewing the website inside Safari.

While they haven't said as much, it is obvious that this isn't just an approach for ".NET on the server", but something broader - trying to remove all installation requirements for .NET itself, so that side-by-side installations and entirely self-contained applications are possible.      Both Microsoft's .NET Native and Xamarin's AOT compiler technology also point in the same direction - generation of self-contained native EXEs which hide the fact that they are using .NET entirely,

Having centralized repositories of DLLs which are batch-updated for all applications "smell" to me like an old paradigm.    We obviously need to have SOME basis for the operating system, but having anything inside that "bucket" which is under active development does not strike me as a good pattern.    Perhaps, if there is very, very stable API and stable semantics already?    For anything else, you've just "DLL Hell"-ed yourself.    And for what?   To save disk-space?    To save a small amount of download size?    For any non-trivial application, the data which comes with an app will be the majority of the download.

You could argue "But deploying the Mono DLLs as part of the OS will mean you can ship bug-fixes to all applications without needing to modify the apps".   Well, that is true, but on the flip side it also means that you can introduce bugs or break applications which used to work.     Unless the MonoTizen team takes on the burden of testing EVERY APP which is built on top of MonoTizen as part of the acceptance tests for new releases, all you have done is taken control out of developer's hands.    You have decided FOR THEM that you are going to force-update the Mono runtime underlying their applications.   Well done.

If a new Mono release has some bug-fixes or improvements which the app developers want then they will update their own application.    That is their choice and right.    Why take that control away from them?

John Ixion

It would be interesting to have native Tizen (Store) apps in a completely different environment indeed.

The Tizen Association should sponsor this imo