Devrais-je réécrire l’interface graphique avec GTK + au lieu de WinForms pour Mono?

Je faisais une application avec Visual Studio, Winforms et j’utilise openTK. Récemment, j’ai pensé à le rendre multi-plateforme. Je vais utiliser Mono, parce que je ne connais rien de semblable. Et je n’ai aucune expérience avec GTK +. Dans mon application, il y a actuellement 4 fenêtres (bien sûr, il y en aura plus à l’avenir). Je veux créer rapidement des applications sous Windows, Linux et OS X. J’ai lu que GTK + était meilleur que WinForms, mais je ne savais toujours pas lequel choisir. Donc, devrais-je tout refaire pour GTK + ou restr avec WinForms et pourquoi ? Aussi, y a-t-il un outil qui ferait ce travail pour moi?

Honnêtement, vous allez avoir besoin de nous en dire plus sur votre public cible / marché cible pour fournir une excellente réponse, mais mes 0,02 $ d’expérience en développement dans ce domaine sont que le développement d’une interface graphique pour Mono sur le bureau est une affaire à cibles multiples si vous voulez. pour le faire “droit”. Vous allez devoir développer le back-end partagé de manière modulaire, puis écrire l’interface utilisateur une fois par plate-forme.

les fenêtres

Windows.Forms tels qu’ils sont mis en œuvre sur Mono constituent un excellent support si votre application en est à ses balbutiements, vous permettant de cibler Windows immédiatement et de le déployer de manière quelque peu handicapée sous OS X et Linux. Notez cependant que l’on me dit sur IRC que le développement Windows.Forms sur Mono est pratiquement mort. Les anciens bogues ne sont pas mis à jour et, par exemple, j’ai rencontré SelectionBackColor qui ne fonctionnait pas dans RichTextBox sous OS X (c’est un problème dans une bibliothèque que Mono utilise pour Windows.Forms sous OS X) quelques minutes après le test. Neat que c’est là, peut-être bon pour les utilitaires rapides où vous pouvez coder autour de ses limitations (voir question ici pour un exemple).

OS X

Pour cibler OS X, si vous avez une application réelle, commerciale et utilisateur final, vous devrez vous habituer à, euh, une interface avec Interface Builder . Je devrais préciser ici que l’utilisation de XCode et d’Interface Builder nécessite absolument d’avoir access à une boîte de dialog exécutant OS X. Sinon, vous êtes coincé avec Windows.Forms ou, de préférence, je pense, Gtk #.

Xamarin a fait un excellent travail en établissant des connexions de bouts IDE avec des interfaces utilisateur natives construites en XCode. C’est comme cela qu’ils le font pour le développement iOS également. Cela fonctionne assez bien, même si la documentation est faible. Michael Hutchingson a publié une superbe vidéo de 2011 décrivant ce processus , même si je suppose que cela prend du temps (c.-à-d. “Vieux”). ( Lien direct vers la vidéo )

Je suppose qu’Interface Builder est également votre seul véritable choix si vous souhaitez cibler le Mac App Store. Mais regardez, c’est une interface utilisateur native qui a été réduite à votre code C #, ce qui est, à tous égards, un excellent compromis.

Linux

Je n’ai pas vraiment ciblé Linux. On dirait que Gtk # serait un choix naturel, mais je ne vous aide pas beaucoup sur le terrain. Mon matériel est construit dans Windows.Forms, et il y a des aspérités, tout comme dans OS X. Si je devenais plus sérieux, je commencerais par Gtk #, et c’est là que MonoDevelop possède également son interface graphique RAD.

Exemple d’application Gtk # multi-plateforme sérieuse et mature

Remarque rapide: Banshee utilise Gtk # pour cibler OS X, Windows (alpha) et Linux. Vous pouvez avoir un bon aperçu de la difficulté d’utiliser Gtk # sur une grande application multiplate-forme en consultant sa liste de diffusion et d’autres ressources.

Désolé, les nouvelles ne sont pas plus faciles. Il n’y a pas de solution miracle / simple bonne réponse.

MISE À JOUR 201607: Je pense que la solution consiste à utiliser lentement Xamarin.Forms pour cibler plusieurs plates-formes. Vous êtes peut-être encore bloqué pour le moment en train d’écrire une interface Mac distincte, mais il y a des raisons de penser que le support de Xamarin.Forms sera également pris en charge à un moment donné; voir ci-dessous.

Malheureusement, si vous ciblez Linux, je pense que vous êtes toujours dans la même situation qu’auparavant.

Windows: Vous pouvez maintenant utiliser Xamarin.Forms et UWP .
macOS: Vous êtes toujours à peu près au même endroit, mais un employé de Xamarin m’a dit le week-end dernier que Xamarin.Forms était en développement non officiel pour OS X. Je crois que c’est le rapport sur GitHub . (Il y a même une twig pour tvOS.)

Je suggérerais que vous considériez quel est votre public cible. Écrire une interface utilisateur à l’aide d’un framework tel que GTK # peut sembler une bonne idée, mais pour l’utilisateur moyen, votre application ne ressemblera pas à leurs autres applications Windows / OSX, ce qui peut facilement empêcher les utilisateurs de l’utiliser (à moins que ce ne soit vraiment exceptionnel d’une autre manière).

La meilleure façon de procéder (ce qui pourrait ne pas être possible en raison de contraintes de temps / budget) consiste à placer la logique de votre application dans un assemblage séparé, puis à écrire l’interface utilisateur de chaque plate-forme, à l’aide de Winform (ou WPF) pour Windows, MonoMac / Cocoa pour Windows. OSX et GTK # pour Linux. Cela ne vous limitera pas non plus à utiliser des fonctionnalités disponibles sur toutes les plates-formes, qui nuiraient beaucoup à l’expérience utilisateur.

Je suis confronté à un problème similaire maintenant, mais ce que Karl-Johan a dit à propos de la séparation de la logique d’application facilitera la tâche. Examinez un modèle ViewModel (MVVM) et vous aurez beaucoup moins de code à réécrire et à tester pour chaque plate-forme, car la logique centrale devient indépendante de l’interface utilisateur.