J'ai créé une application avec Visual Studio, winforms et j'utilise openTK. Récemment, j'ai pensé à la rendre multiplateforme. Je vais utiliser Mono, parce que je ne connais rien d'autre de similaire. Et je n'ai aucune expérience avec GTK+. Dans mon application, il y a actuellement 4 Windows (bien sûr il y en aura plus dans le futur). J'ai lu que GTK+ est meilleur que WinForms, mais je ne sais pas encore lequel choisir. Alors, dois-je tout refaire pour GTK+ ou rester avec WinForms et pourquoi ? Existe-t-il un outil permettant de faire ce travail à ma place ?
Réponses
Trop de publicités?
Honnêtement, vous allez devoir nous en dire plus sur votre public /Le marché de l'interface graphique n'a pas l'intention de fournir une grande réponse, mais mon 0,02 $ d'expérience de développement est que le développement de l'interface graphique pour Mono sur le bureau est une affaire multi-cible si vous voulez le faire "correctement". Vous allez devoir développer le backend partagé de manière exceptionnellement modulaire, puis écrire l'interface graphique une fois par plateforme.
Fenêtres
Windows.Forms, tel qu'il est implémenté dans Mono, est une excellente béquille si votre application n'en est qu'à ses débuts, car il vous permet de cibler les applications Windows immédiatement et se déploient de manière quelque peu paralysée sur OS X et Linux. Notez cependant que l'on m'a dit sur IRC que le développement de Windows.Forms sur Mono est essentiellement mort. Les vieux bugs ne sont pas mis à jour, et, par exemple, j'ai rencontré SelectionBackColor qui ne fonctionnait pas dans RichTextBox sur OS X (c'est un problème dans une librairie que Mono utilise pour Windows.Forms sur OS X) après quelques minutes de test. C'est bien qu'il soit là, peut-être bon pour des utilitaires rapides où vous pouvez coder autour de ses limitations (voir la question aquí pour un exemple).
OS X
Pour cibler OS X, si vous avez une véritable application commerciale pour l'utilisateur final, vous devrez vous habituer à, euh, interagir avec Constructeur d'interface . Je dois préciser ici que l'utilisation de XCode et d'Interface Builder exige absolument que vous ayez accès à une machine fonctionnant sous OS X. Sinon, vous êtes coincé avec Windows.Forms ou, de préférence, je pense, Gtk#.
Xamarin a fait un excellent travail en faisant en sorte que son IDE bloque les connexions aux interfaces utilisateur natives construites dans XCode. C'est également la façon dont ils le font pour le développement iOS. Cela fonctionne assez bien, bien que la documentation soit faible. Il y a un excellente vidéo de 2011 de Michael Hutchingson décrivant ce processus Je pense qu'il commence à se faire 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 native qui est intégrée à votre code C#, ce qui est, tout bien considéré, un excellent compromis.
Linux
Je n'ai pas vraiment ciblé Linux. Il semble que Gtk# serait une solution naturelle, mais je ne suis pas d'une grande aide pratique dans ce domaine. Mon travail se construit en Windows.Forms, et il y a des bords rugueux, tout comme dans OS X. Si je devenais plus sérieux, je commencerais avec Gtk#, et c'est là que MonoDevelop a aussi son GUI RAD.
Exemple d'une application Gtk# sérieuse, mature et multiplateforme
Note rapide : Banshee utilise Gtk# pour cibler OS X, Windows (alpha) et Linux. Vous pouvez vous faire une idée de la difficulté d'utiliser Gtk# sur une grande application multiplateforme en consultant le site suivant sa liste de diffusion et d'autres ressources.
Désolé que les nouvelles ne soient pas plus faciles. Il n'y a pas de solution miracle ou de réponse unique.
201607 MISE À JOUR : Je pense que la solution consiste de plus en plus à utiliser Xamarin.Forms pour cibler le multiplateforme. Pour l'instant, vous êtes peut-être encore obligé d'écrire une interface Mac séparée, mais il y a des raisons de croire qu'elle sera prise en charge par Xamarin.Forms à un moment ou à un autre ; voir ci-dessous.
Malheureusement, si vous visez Linux, je pense que vous êtes toujours dans le même bateau qu'avant pour l'instant.
- Fenêtres : Vous pouvez désormais utiliser Xamarin.Forms et UWP .
- macOS : Vous êtes toujours au même endroit, mais un employé de Xamarin m'a dit le week-end dernier que Xamarin.Forms est officieusement en cours de développement pour OS X. Je pense que voici le repo sur GitHub . (Il existe même une branche pour tvOS.)
Karl-Johan Sjögren
Points
4207
Je vous suggère de réfléchir à votre public cible. Écrire l'interface utilisateur en utilisant un framework comme GTK# peut sembler une bonne idée, mais pour l'utilisateur moyen, votre application ne ressemblera pas aux autres applications Windows/OSX, ce qui peut facilement empêcher les gens de l'utiliser (à moins qu'elle ne soit vraiment exceptionnelle d'une autre manière).
La meilleure façon de procéder (qui peut ne pas être possible en raison de contraintes de temps ou de budget) est de placer la logique de l'application dans un assemblage séparé, puis d'écrire l'interface utilisateur pour chaque plateforme, en utilisant Winform (ou WPF) pour Windows, MonoMac /Cocoa pour OSX et GTK# pour Linux. Il ne vous limitera pas non plus à l'utilisation de fonctionnalités disponibles sur toutes les plateformes, ce qui dégraderait considérablement l'expérience de l'utilisateur.
Mathieson
Points
516
Je suis actuellement confronté à un problème similaire - mais ce que Karl-Johan a dit à propos de la séparation de la logique d'application rendra la tâche beaucoup plus facile. Envisagez un modèle ViewModel (MVVM), et vous aurez beaucoup moins de code à réécrire et à tester pour chaque plateforme, car la logique centrale devient agnostique vis-à-vis de l'interface utilisateur.
