MonoDevelop dla Mac OS

8 lutego 2008

Wydana została wersja Mono 1.2.6 zawierająca natywne GTK+ dla OS X oraz platformę programistyczną MonoDevelop w wersji dla Maca.

Wersja dla Maca ma według Miguela de Icazy taką samą funkcjonalność, co wersja linuksowa. Miguel ma nadzieję, że dzięki temu wydaniu twórcy aplikacji dla Mac OS X przekonają się do platformy Mono.

Poinformowano również o planach wydania MonoDevelop dla Windows. Nie będzie on jednak konkurentem świetnego SharpDeveloper, a głównym zadaniem ma być udostępnienie dla Windows programu Stetic (tworzenie interfejsu dla Gtk#) w celu ułatwienia budowania przenośnych aplikacji.

PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo

Technologie

21 odpowiedzi na „MonoDevelop dla Mac OS”

mario

8 lutego 2008

Developerów makowych tym nie przekona – menu nie może być w oknie aplikacji w OS X, wtedy aplikacja nie jest obsługiwana jak inne makowe aplikacje.

Odpowiedz
mk

8 lutego 2008

Właśnie. Menu nie w tym miejscu, widgety nie natywne – nikt nikogo tym nie przekona. Może jeszcze z X11 korzysta?
Właściwe podejście to CocoaSharp, a nie Gtk#.

Odpowiedz
1. mario
  
  8 lutego 2008
  
  X11 nie używa, widać to po nazwie aplikacji w menu obok jabłuszka.
  :
  CocoaSharp nie jest do końca dobry podejściem, bo chodzi o GUI przenaszalne – aplikacje masz napisać raz, a uruchomić wszędzie, jak to jest w przypadku Javy. W Javie osiągnięto to na 2 sposoby:
  :
  1. SWING, czyli GUI, które na każdej platformie samo się maluje po swojemu, albo używa natywnych kontrolek jeśli załadowano odpowiedni Look&Feel. Wymaga to trochę kodu do napisania ręcznie, ale jest to zaledwie kilka linijek. Swing używa na Maku domyślnie COCOA.
  :
  2. SWT, czyli GUI wrapper, na inne GUI, który pod Windowsem używa WinAPI, pod Linuksem GTK, a pod Makiem … niestety Carbon, a nie Cocoa (ale wygląda i tak o niebo lepiej niż to GTK pod OSXem)
  
  Odpowiedz
  1. dPeS
    
    8 lutego 2008
    
    imo swing nie uzywa natywnych kontrolek, natomiast swt uzywa ich gdzie tylko moze a jesli nie moze to maluje swoje
    
    Odpowiedz
    1. mario
      
      8 lutego 2008
      
      Używa jak użyjesz odpowiedniego Look&Feel. Metoda <code>UIManager.getSystemLookAndFeelClassName()</code> stara się zwrócić Look&Feel natywny dla OSu na którym uruchomiono program. Wtedy program Javy ma taki sam wygląd jaki skonfigurowałeś sobie w ustawieniach systemowych, bo używa natywnych kontrolek.
      
      W Mac OS X warto dodatkowo wywołać:
      <code>System.setProperty("apple.laf.useScreenMenuBar", "true");</code>
      aby menu było w górnej belce, a nie w oknie aplikacji.
      
      Odpowiedz
    2. citan
      
      9 lutego 2008
      
      Swing zawsze "rysuje" kontrolki w odpowiedni sposób, nie używa natywnych – nawet jeżeli wybierzeż L&F systmowy. AWT było powiązane z kontrolkami natywnymi.
      
      Odpowiedz
    3. mario
      
      10 lutego 2008
      
      Ok to odpal WindowsLookAndFeel w Linuksie albo OSX – nie da się. Swing w większości przypadków rysuje kontrolki, ale równie dobrze może używać natywnych. LookAndFeel to nie jest prosta skórka, tylko biblioteka, której zadaniem jest wyświetlanie komponentów, nie zmusza ona do rysowania komponentów. Kiedyś Swing zawsze rysował okienko i wszystkie jego elementy, teraz potrafi wyświetlić je natywnie , łącznie z dialogami, oknami wyboru pliku itp.
      :
      Głównym celem Javy jest "napisz raz uruchom wszędzie", dlatego Swing początkowo miał rysowane GUI.
      
      Odpowiedz
2. krzychoocpp
  
  8 lutego 2008
  
  Albo po prostu… użyć Qt. I byłoby po problemie 😛
  
  Odpowiedz
  1. mario
    
    8 lutego 2008
    
    Qt nie pozwoli programistom zamknąć aplikacji.
    
    Odpowiedz
    1. mk
      
      8 lutego 2008
      
      Pozwoli, jeżeli go normalnie kupią, a nie wezmą darmochę.
      
      Odpowiedz
    2. mario
      
      8 lutego 2008
      
      Twórca freeware'a nie kupi, bo nie zarabia na programie. Generalnie powstają dodatkowe problemy, dlatego też większość aplikacji powstaje na GTK a nie lepszym Qt.
      
      Odpowiedz
    3. palcuś
      
      9 lutego 2008
      
      QT lepsze?! Nie wiem w czym.. fakt obecne QT4 jest nieco szybsze, jednak GTK dopiero czeka lifting, niemniej nie wypada mimo to tak kiepsko. Pomijając już absolutnie fakt, że w GTK jest prościej kodować. Jedynie dobre wyjście dla GTK to SWT w windows/OSX.
      
      Odpowiedz
    4. krzychoocpp
      
      9 lutego 2008
      
      Prościej się pisze w GTK ? Oj, chyba nie pisałeś nigdy czegoś większegon iż Hello World w jednym i w drugim, skoro takie rzeczy wypisujesz 😛
      
      Co do argumentu o zamykaniu kodu, to przecież Mono Develop chyba otwarte jest, więc nie ma problemu ?
      
      Odpowiedz
    5. palcuś
      
      9 lutego 2008
      
      Na pewno prościej niż w QT3
      
      Odpowiedz
    6. mario
      
      9 lutego 2008
      
      Qt jest lepsze od GTK, zwłaszcza Qt3, pod względem prędkości. Wystarczy popatrzeć na responsywność aplikacji Qt i GTK oraz na zajętość pamięci. GNOME zajmuje w pamięci RAM o jakieś 20 – 30MB więcej od KDE. Testowałem na moim byłym laptopie KDE i GNOME, okazało się, że KDE działa zdecydowanie szybciej, a na P3 900 256MB RAM to naprawdę czuć. Oczywiście najszybszy jest fluxbox, ale wygoda KDE jest naprawdę rewelacyjna :-).
      Warto dodać, że taki stan rzeczy jest chyba od KDE 3.5 (od tego, które zastosowano w openSuSE 10.1) chyba wcześniej GNOME dział nieco szybciej, ale potem KDE zrobiło ogromny skok wydajnościowy zostawiając GNOME daleko w tyle pod tym względem.
      
      Odpowiedz
    7. drm
      
      9 lutego 2008
      
      To chyba dawno testowałeś obecne gnome 2.20 zajmuje mniej RAM niż KDE 3.5, nawet kubuntu ma większe wymagania niż zwykłe z gnome..
      
      Odpowiedz
    8. Maciek
      
      9 lutego 2008
      
      po co to RAM-owe aptekarstwo? O czym świadczy to, że na Twojej instalacji jedno zajmuje 290 MB, a drugie 320? Większe już są różnice w funkcjonalności 😛
      
      Odpowiedz
    9. mario
      
      9 lutego 2008
      
      Mówię o zajętości w RAM, np. openSuSE z KDE zajmuje w pamięci w standardzie ok 80 MB z GNOME ponad 100MB. To ile zajmuje środowisko, świadczy o tym ile zostaje dla aplikacji – nie włączasz komputera chyba po to aby oglądać pulpit i ikony, tylko po to aby uruchamiać w nim programy, zgadza się? Ważne aby dobrze wyważyć pomiędzy zużyciem zasobów i wygodą pracy.
      :
      @drm: sprawdzę najnowsze wersje, w każdym razie mój tata odziedziczył po mnie laptopa i po tym jak zainstalował sobie Ubuntu z GNOME, szybko wrócił do openSuSE z KDE, bo po prostu słabo to chodzi na sprzęcie, który ma 256MB RAM. Chciał Ubuntu, bo się mu bardziej podobało wizualnie. Siostra za to została przy Ubuntu, bo ma lepszy sprzęt z 1GB RAMu i nie ma dla niej większego znaczenia ile środowisko zajmuje.
      
      Odpowiedz
    10. drm
      
      10 lutego 2008
      
      top z freebsd 6.3 z kde;
      Mem: 96M Active, 19M Inact, 111M Wired, 8472K Cache, 34M Buf, 2332K Free
      :
      top z freebsd 6.3 z gnome;
      Mem: 73M Active, 8252K Inact, 27M Wired, 7012K Cache, 22M Buf, 480K Free
      :
      Dalej sie upierasz ze ma mniejsze wymagania KDE?
      
      Odpowiedz
Jakub

9 lutego 2008

Palcuś, ale może udowodnij. Moje doświadczenia są zgoła inne. QT3 to bardzo dobrze, świetnie udokumentowana i dobrze przemyślana biblioteka. Może jakieś konkrety? Bo jak na razie to są insynuacje.

Odpowiedz
1. Jakub
  
  9 lutego 2008
  
  Oj, klik nie tam, naturalnie komentarz do odpowiedzi palcusia w wątku powyżej. 🙂
  
  Odpowiedz