Rozdzielczość ekrani i wymiary okien formularzy w Mono

Zainstalowałem testowo Mono w formie maszyny wirtualnej VirtualPC. Tam od razu jest już Suse Linux ze srodowiskiem Gnome, pakiet Mono i kompilator MonoDevelop.

Zauważylem, że żeby odpalic aplikacje napisaną w Windows, to trzeba uruchomić konsole, przejść do katalogu i dać polecenie: mono NazwaPli.exe

Po chwili program się uruchamia i działa. Tylko jest mały problem.

W przypadku domyślnej instalacji Linux w maszynie, okna programów są większe niż być powinny.

Na poniższym ekranie jest uruchomiony prosty przykład napisany w Visual Studio 2005 i po lewej stronie widać okno uruchomione na Linuxie, a po prawej stronie, dla porównania wielkości, jest nałozone okno w systemie Windows.

Zauwazylem, że jak się wczyta projekt do MonoDevelop i skompiluje się w kompilatorze i uruchomi, to jest ten sam problem.

Zauważyłem, że przyczyną jest rozdzielczość ekranu. Metodą prób i błędów znalazłem, że prawidłowa rozdzielczość to 85dpi i wtedy wielkość okien jest prawidłowa:

Ponadto zauważyłem, że istnieją dwa interfejsy formularzy: Windows Forms i GTK#. programy w Windows Forms mają ten problem, ponadto, w MonoDevelop nie mogę znaleźć edytora formy. Natomiast przy formach GTK# ten problem nie istnieje, forma ma zawsze tą samą wielkość bez względu na ustawienia DPI i wielkość czcionki.

Gdzie i co ustawić w projekcie w Visual Studio, żeby formularz nie był "czuły" na ustawienie rozdzielczości dpi ekranu?

Czy można Mono tak skonfigurować, żeby Windows Forms zawsze wyświetlało okna bez skalowania?

Jak włączyć edycje formularzy dla Windows Forms w MonoDevelop?

Sęk w tym, że okno powinno być "czułe" na DPI. Twórz interfejs tak, by wszystkie elementy były równomiernie skalowalne według DPI (tj. nie polegaj na sztywnym podawaniu odległości i wielkości w pikselach). Później twojego programu używać będzie osoba z wadą wzroku i będzie miała problemy z interfejsem (taką sytuację mieliśmy ostatnio w firmie, bo komponent generowania barcodów był nieprzystosowany do większych DPI niż domyślnie i źle drukowały się faktury).
A tak w ogóle to radzę ci użyć GTK pod Linuksem, a Windows Forms pod Windowsem. Jest więcej roboty, potwierdzam, ale użycie odpowiednich wzorców, interfejsów da ci większe możliwości w przyszłości, gdy np. będziesz przenosił program pod Mac OS albo Windows Mobile.
Przykład tutaj: http://www.mono-project.com/Gui_Toolkits#Alternative_Implementation_Approaches

Niestety, standardowy Designer formatek w .Net nie wspiera pozycjonowania wzglednego i wymaga aby pos/size bylo podawane w pikselach.. Przez to, zmiana DPI wywala rozklad graficzny wiekszosci aplikacji, nie mowiac juz co sie dzieje jesli sie zmieni wielkosc czcionki systemowej.. Nie radza sobie z tym nawet uznane komercyjne pakiety kontrolek i layouterow jak np. DevExpress (mowie z doswiadczenia sprzed roku z v6..v8)
Wiec, jakkolwiek malo to pomocne -- ale nie daloby sie tak graficznie zaprojektowac okna, zeby ew. przesuniecia nie psuly ukladu? np. formularze w 100% poziome?

Własnie o to chodzi, że rozmiary formy i elementów okresla sie w pikselach, co sugeruje, że to muszą być wartosci bezwzględnie utrzymywane.

Gdyby te wartości określało sie w calach lub w centymetrach, to wtedy byloby wskazane, zeby wielkość na ekranie zależała od dpi, a dpi okreslone na podstawie ilości pikseli monitora na jeden cal przykładając miarkę do monitora.

Druga sprawa jest taka, że w Windows jest 96dpi (ustawienie domyślne), a w Linuxie trzeba ustawić 85dpi, żeby zachować wielkość formy. Skąd ta rozbieżność?

Próbowałem rówież zmieniać wielkości czcionek w Linuxie i zmiana formy nie zachodziła.

Ale z drugiej strony, forma w GTK# utrzymuje zadaną wielkość bez wzgledu na dpi ekranu.

Rozumiem, że do Linuxa lepiej Gtk#, a do Windows Windows Forms, ale który z tych dwóch jest lepszy, jak program ma działać w obu systemach bez rekompilacji.

Co do wielkosci czcionek, mialem na mysli natychmiastowe rozjazdy ale w innym stylu: sprobuj zmienic kontrolce jej .Font na jakis wiekszy, np. 18pt zamiast 8 czy 12, kontrolka ochoczo natychmiast urosnie, ok, ale z braku nawet podstawowych mechanizmow layoutu na formularzu, zapewne zacznie natymiast gryzc sie z kontorlkami obok.
Oczywiscie, wystarczy uzyc layoutu albo samemu przeliczyc pozycje..

GTK widać jest lepiej napisane, bo mniej zakłada a wiecej wylicza.. ciche założenia to ciągła sól rzucana w oczy przez M$..

A co do DPI, szczerze, nie wiem, ale wiem ze zmiana DPI na windowsie tez rozwala wiekszosc okien roznych aplikacji

Rozumiem, że do Linuxa lepiej Gtk#, a do Windows Windows Forms, ale który z tych dwóch jest lepszy, jak program ma działać w obu systemach bez rekompilacji.

Normalnie, w tym sęk ;).
Powiedzmy, że pracujesz nad oknem logowania. Tworzysz interfejs ILogonWindow, który posiada takie pola jak username, password, event od naciśnięcia przycisku ok albo anuluj. Później dla każdego z interfejsów tworzysz klasy implementujące interfejs. czyli np. WinForms.LogonWindow i Gtk.LogonWindow. I w programie będziesz tworzył sobie automatycznie instancje dowolnej z tych klas na podstawie systemu, w którym został uruchomiony. W praktyce będzie to wyglądać na przykład tak:

ILogonWindow logonWindow = InterfaceManager.GetWindow<ILogonWindow>();
logonWindow.ShowModal();
logonWindow.OKPressed += ...
string login = logonWindow.Username;