Amiga forum / MUI i Reaction / MUI
Czytasz wątek: MUI
-
ministerq
Nieaktywny użytkownik starego forum
-
MUI wysłany: 2008-01-06 16:21
[url]http://exec.pl/comments.jsp?nid=3492 W tym newsie, redakcja ucina sobie bardzo fajną dyskusję na temat MUI. Pada tam bardzo wiele ciekawych kwestii, które w sam raz nadają się pod dział "amiga dementi".
MUI nie jest nieskoordynowanym pakietem, wbrew temu co się pisze w powyższym komentarzu. Nad MUI sprawuje kontrolę Stefan Stuntz, który rozwija ten pakiet do dziś - cały czas powstają nowe, robocze wersje tego pakietu pod system MorphOS, które każdy zainteresowany może sprawdzić u siebie w działaniu.
Niechęć do MUI na execu zapewne wynika bezpośrednio właśnie z faktu, że jest ono rozwijane przede wszystkim na potrzeby systemu MorphOS, a nowe wersje pod AmigaOS nie pojawiają się na bieżąco z wersjami dla systemu MorphOS. A przecież wszystko co nie powstaje równolegle na "wyznaczający standardy AmigaOS4" nie jest warte uwagi, i powinno być z tego względu wyśmiane, bądź sprowadzone albo do nieistotnej ciekawostki, bądź "zła koniecznego"...
Trzeba jednak obiektywnie zaznaczyć że publiczne, stabilne wersje MUI, zarówno pod systemy AmigaOS jak i MorphOS, w zakresie wbudowanych klas jest bezproblemowe, i pomimo "rozwoju i koordynacji Reaction przez systemowych developerów" ciągle posiada znacznie większe możliwości niż Reaction.
Na potrzeby tego komentarza można się jednak uciec do pewnego uogólnienia, iż w zakresie podstawowej funkcjonalności, MUI jest z grubsza odpowiednikiem "systemowego" Reaction.
W skład MUI wchodzi kilkanaście klas, "wbudowanych", koordynowanych i rozwijanych przez Stuntza - [url]http://www.sasg.com/mui/autodocs/ -tu jest ich pełna lista. Tylko to podstawowe drzewo jest wyznacznikiem tego czym jest MUI, i co się w nim zawiera.
Podstawowa funkcjonalność MUI, którą Stuntz wprowadza wraz z nowymi wersjami, nie zmienia się na tyle drastycznie, by nie dało się np. pisać programów korzystających z tego pakietu, i jednocześnie działających na wszystkich platformach kompatybilnych z API AmigaOS (OS3, 4, MOS, AROS).
Elastyczność API, bardzo dobra dokumentacja, możliwość pisania aplikacji które na poziomie źródeł są kompatybilne z różnymi wersjami AmigaOS sprawia, że jest to bardzo popularny pakiet wśród programistów, co przekłada się bezpośrednio na ilość oprogramowania, które z niego korzysta. Przekłada się to również na ilość ZEWNĘTRZNYCH klas, które są wynikiem "radosnej twórczości" amigowych programistów, i z którymi autor MUI, jako koordynator projektu nie ma nic wspólnego.
W komentarzach pada stwierdzenie o tym, że gdy autor danej klasy, co należy podkreślić: ZEWNĘTRZNEJ klasy, nie związanej z bazowym pakietem MUI "wyjedzie, zachoruje lub gdzies zniknie to mozna sobie tylko poplakac". Oczywiście. Tyle że to zdanie nie ma wyłączności na określenie sytuacji zewnętrznych klas MUI - ono dotyczy również zwykłych programów, i wszystkich składników tego oprogramowania (które nie jest publikowane na zasadach OpenSource). To zdanie dotyczy również ewentualnych zewnętrznych klas Reaction, które ktoś, kiedyś być może stworzy, i umieści w pakiecie ze swoim programem...
Z podstawowej zalety MUI, jak i poniekąd Reaction - możliwości pisania własnych klas, i ubierania ich w publiczne interfejsy, robi się w tym momencie WADĘ, zapominając jednocześnie, że dotyczy ona OBU pakietów. I nie tylko tych dwóch.
W przytoczonym komentarzu pisze się o tym, że brakuje tzw. "koordynacji rozwoju MUI", jednocześnie wrzucając do jednego worka pod nazwą MUI WSZYSTKO co się z MUI wiąże - również klasy, które ktoś tam sobie dłubie w zaciszu domowym.
W takim razie, ja chciałbym zapytać - czy jeśli jakiś szczęśliwy programista, świeżo upieczony, pod AmigaOS4 oczywiście, zacznie tworzyć sobie program, i część jego funkcjonalności obuduje w klasę, dajmy na to HTMLView.gadget, i następnie okaże się że w tej klasie jest błąd, który to powoduje iż Reaction wraz z systemem leci w kosmos w jakiejś niezidentyfikowanej sytuacji, to czy oznacza to że błąd leży po stronie Hyperionu i Reaction, który nie skoordynował prac nad klasą HTMLView.gadget? To jakaś pokrętna logika, którą można wysnuć czytając komentarze na temat MUI, które pojawiają się na tej stronie.
To po pierwsze.
Po drugie: nie da się "skoordynować prac nad zewnętrznymi klasami" do jakiegokolwiek GUI - tak jak sun nie koordynuje zewnętrznych klas w javie które to tworzą jacyś świeżo upieczeni adepci swinga czy innego awt, podobnie jak M$ nie koordynuje klas które jakiś świeżo upieczony adept MFC czy innego c# rzeźbi w zaciszu domowym, i puszcza w świat, itp, itd
Dlatego właśnie winienie MUI za błędy, które popełniają ludzie w publicznych klasach które tworzą jest głębokim nieporozumieniem, i z czasem, jeśli Reaction zacznie doganiać MUI pod względem dostępności klas, bardzo podobny problem zacznie dotykać również owe "systemowe rozwiązanie". I na nic się tutaj nie zda owa rzekoma większa "systemowość" Reaction - błąd w programie, który jest klasą, jest błędem, niezależnie od tego czy został ubrany w *.mcc czy w *.gadget, czy w cokolwiek innego.
Jeśli zaś autorzy komentarzy pod newsem sądzą, że sytuacja w jakiej znajduje się MUI nie dotyczy Reaction, "koordynowanego i rozwijanego przez systemowych developerów", to śpieszę z pocieszeniem, iż twórcy systemowych klas nie są w stanie napisać klas do wszystkiego, i na tyle uniwersalnych, by nigdy nie zaszła konieczność ich subklasowania, czy tworzenia nowych, wyspecjalizowanych klas do konkretnych zastosowań.
No, chyba że Reaction stanie się pakietem "zamkniętym", bez publicznego interfejsu, i bez możliwości subklasowania. Wtedy oczywiście wszyscy życzymy mu powodzenia.
-
Gordon Shumway
Nieaktywny użytkownik starego forum
-
MUI wysłany: 2008-01-06 16:40
@ministerq
1. Nikt nie neguje faktu ze nad MUI sprawuje kontrole Stefan Stuntz.
2. Tak jak zauwazyles problem dotyczy ZEWNETRZNYCH klas.
3. Przy czym obecnie sytuacja wyglada tak, ze te zewnetrzne klasy sa tak samo wazne jak te podstawowe.
4. Rozwiazaniem problemu bylo by wejscie tych bardzo waznych zewnetrznych klas pod kontrole i rozwoj glownego pakietu MUI, ew. napisanie przez Stuntza nowych klas spelniajacych te bardzo wazne funkcje, ktorych brakuje w podstawowym MUI. Tak, aby zwykli userzy nie musieli biegac po sieci w poszukiwaniu zewnetrznych, ale tak naprawde PODSTAWOWYCH klas.
-
ministerq
Nieaktywny użytkownik starego forum
-
MUI wysłany: 2008-01-06 16:49
@
I jaka w tym wina samego MUI?
To nie wina MUI, że pod ten pakiet powstały zewnętrzne klasy o bardzo dużych możliwościach.
A powiedz mi, jakimi to kryteriami miano by się kierować, oceniając które to zewnętrzne klasy są na tyle "ważne" by je włączyć w drzewo MUI?
Jak zmusić autorów oprogramowania by udostępniali kody źródłowe swoich klas?
To o czym piszesz jest nielogiczne i bezsensowne.
Ja bym to nazwał tak: trudno winić autora MUI za popularność wśród programistów pakietu, który stworzył, ale obecnie chęć napisania stabilnego programu zmusza programistę do posiadania praktycznej wiedzy, które klasy się wieszają, a które nie, w jakich wersjach i w jakich sytuacjach. Rozróżnienie na klasy wewnętrzne i zewnętrzne może być tu tylko punktem wyjścia do przeprowadzenia odpowiedniej analizy, a nie rozwiązaniem problemu.
Nie powiesz chyba, że jest to sytuacja komfortowa z punktu widzenia twórcy oprogramowania chcącego skorzystać z pewnego i stabilnego pakietu bibliotek tworzących GUI.
-
Gordon Shumway
Nieaktywny użytkownik starego forum
-
MUI wysłany: 2008-01-06 16:54
@ministerq
Oczywiscie ze autor nie jest w stanie napisac klas do wszystkiego, obecna systuacja z MUI wyglada jednak tak, ze zasadnicze klasy sa poza glownym drzewem i dlatego uwazam obecny rozwoj MUI za nieskoordynowany.
Autor MUI powinien rozwiazac ten problem, byc moze dopuszczajac autorow tych klas do rozwoju calego MUI, ala jak znamy Stuntza to wydaje sie to raczej nierealne.
Swoja droga ciekawe co sie z stanie z MUI, gdy kiedys Stuntz obrazi sie na srodowisko (tak jak ostatnio jeden gosc od pewnego stosu USB) i sobie pojdzie do innej piaskownicy?
-
ministerq
Nieaktywny użytkownik starego forum
-
MUI wysłany: 2008-01-06 17:03
@Gordon Shumway
@ministerq
Oczywiscie ze autor nie jest w stanie napisac klas do wszystkiego, obecna systuacja z MUI wyglada jednak tak, ze zasadnicze klasy sa poza glownym drzewem i dlatego uwazam obecny rozwoj MUI za nieskoordynowany.
Autor MUI powinien rozwiazac ten problem, byc moze dopuszczajac autorow tych klas do rozwoju rozwoju calego MUI, ala jak znamy Stuntza to wydaje sie to raczej nierealne.
Na jakiej podstawie łączysz rozwój MUI z rozwojem zewnętrznych klas które nie mają nic wspólnego z MUI i jego autorem?
Czy jeśli w przypadku Reaction kiedyś powstaną zewnętrzne klasy do tego pakietu, na tyle "ważne", jak te o których mowa w przypadku MUI, to czy Hyperion dopuści autorów tych klas do rozwoju Reaction jeśli ci autorzy nie będą chcieli udostępnić do nich źródeł? I czy będzie się tak działo za każdym razem?
Tak w ogóle to po co Stuntz miałby dopuszczać autorów jakichkolwiek klas do swoich źródeł? Przecież z rozwojem MUI radzi sobie doskonale. Co go obchodzą jakieś klasy pociotki tworzone przez jakichś amatorów?
Sądzisz że Hyperion w takim przypadku zaweźmie się, i napisze tzw. "systemowy odpowiednik" każdej klasy która z jakiegoś powodu stanie się na tyle ważna by brać ją pod uwagę w kontekście do którego zmierzasz?
Czy jeśli jakiś program się wiesza pod AmigaOS 4, to Hyperion pisze własny, systemowy odpowiednik który się nie wiesza?
@
Swoja droga ciekawe co sie z stanie z MUI, gdy kiedys Stuntz obrazi sie na srodowisko (tak jak ostatnio jeden gosc od pewnego stosu USB) i sobie pojdzie do innej piaskownicy?
Dokładnie to samo, co się stanie w podobnej sytuacji z dowolnym składnikiem systemowym AmigaOS4, bądź samym AmigaOS, jeśli jego autorom się "odwidzi", i gdy pójdą do innej piaskownicy.
Poza tym jest jeszcze Zune, które jest opensource, i zawiera w sobie 99% funkcjonalności MUI - więc problem "odejścia" Stuntza jest jakby troszkę marginalny.
- Menu
- Baza wiedzy
- AmigaOS.pl