A/ Imho nie ma wad, ale nie powinien wymagać do działania wskaźnika (mysz, joystick) a powinno się dać posługiwać aplikacjami przez domyślne skróty klawiaturowe (wzorem dla mnie jest TurboVision).

B/
1. Obiektowy i prosty w użyciu - podajesz strukturę, wywołujesz funkcję.
2. Nie powinien samodzielnie alokować pamięci jeśli już, to programista decyduje gdzie ma leżeć struktura.

Cześć,

W latach '90 gdy z SoTe musieliśmy napisać kilka programów użytkowych, od razu wiedzieliśmy że będę musiały mieć interface okienkowy, tyle że tryb graficzny odpadał. Interface miał być szybki i uniwersalny. Na początku wymyśliliśmy że stworzymy jakąś gotową do użycia bibliotekę, tak aby wykorzystać ją w innych programach. Życie jednak zweryfikowało nasze podejście to "tematu" i wyszło na to że każdy program który tworzyliśmy wymagał indywidualnego podejścia i kończyło się tak że robiliśmy jakiś w miarę uniwersal ny szkielet programu (np. zalążek biblioteki rysującej okienka i przechowującej treść pod "otwartym" okienkiem) a reszta funkcji w danym okienku była już indywidualnie obsługiwana przez niezależne procedury, czasami mieliśmy gotowe jakieś biblioteki I/O z poprzedniego programu, jednak nasza wiedza i doświadczenie rozwijało się "z programu na program", więc z czasem uznaliśmy że za każdym razem będziemy pisali wszystko od nowa, wykorzystując zdobyte doświadczenie i pisząc wszystko "nieco lepiej" niż poprzednio :)

Wydaje mi się że gdyby teraz dobrze przemyśleć całą sprawę to można by się pokusić o w miarę uniwersalną i dobrze zoptymalizowaną bibliotekę do obsługi okienek w trybie tekstowym.  Mam na swoim koncie jeszcze "prawie dokończony" program muzyczny (wewnętrzna rywalizacja z SoTe oraz chęć nauki robienia kolejnych rzeczy na Atari, lecz wtedy wygrał SoTe ze swoim MPT, a je nie zdążyłem i się zniechęciłem), program ten  cały był w trybie TXT (ANTIC mode 2), ale obsługiwał również myszkę od Atari ST/Amigi oraz rysował kursor (strzałkę, klepsydrę) co do pixela hi-res, oczywiście potrzebował 4 znaków wolnych w zestawie znaków aby to realizować, ale wyglądało to całkiem porządnie, być może w końcu uda mi się znaleźć dyskietkę z tym softem i będę mógł pokazać jak to wyglądało).

i na koniec,  pierwsze z brzegu przykłady naszych programów z interfejsami "okienkowymi" w trybie tekstowym:

rok 1992, napisane w MAC/65:

rok 1992, napisane w QA:

rok 1992, napisane w QA:

Ostatnio edytowany przez seban (2014-08-11 18:37:43)

W sumie to zalezy od upodoban uzyszkownika i od tego co program robi. Do niektorych uzytkow pasuje command line a do niektorych GUI. Ogolnie to ja bym optowal za GUI + command line tak jak to jest zazwyczaj w Linuxach.

No tak jak mowie, do niektorych uzytkow command line prasuje a do niektorych to bylo "cos na sile".
W sumie wazne zeby bylo wygodne :)

BMC usiłował się wzorować na "wygodnych" okienkowych systemach. Doprowadzał mnie do szału sterowaniem wskaźnikiem za pomocą joysticka (wiem - można było też myszką). Pomysł trafiania w jeden znak żeby zamknąć takie okno (zamiast po prostu wciśnięcie ESC) jest kretyński. Trauma została mi do dzisiaj. Podobnie zresztą było z kolejnym "wygodnym" Sound Trackerem z ASFu.
Od narzędzia wymaga się:
1. prostoty obsługi (kiedy jesteśmy zieloni)
2. szybkości obsługi (kiedy już przebrnęliśmy przez pierwsze kroki)
"Jedynka" to sterowanie myszką - jestem w stanie się zgodzić z Wieczorem, że to jest wygodne przy niektórych zastosowaniach, ale na dłuższą metę jeśli to jest jedyny sposób sterowania, to potrafi doprowadzić do pasji (vide Sound Tracker). Stąd też cechą dobrze zaprojektowanego interfejsu użytkownika jest sterowanie skrótami klawiaturowymi - i to załatwia "dwójkę". Wiadomo, że w niektórych rozbudowanych aplikacjach nie starczy kombinacji na klawiaturze, żeby wszystko podpiąć stąd też zazwyczaj podstawowe rzeczy są domyślnie predefiniowane, ale mamy osobny panel w ustawieniach, w którym do funkcji można samodzielnie przypisać kombinację klawiszy (choćby Eclipse IDE i Pakiet biurowy Microsoftu).
TurboVision też zresztą dawał obydwie opcje - każdą rzecz z oknami dało się zrobić odpowiednim skrótem. Nawet taki Windows 3.x dało się bez problemu obsługiwać samą klawiaturą, co było rzecz jasna szybsze niż szukanie wskaźnika myszy.
Jest też na Atari XL/XE coś takiego, jak Chaos(?) GEMS autorstwa Pelca (nie mam linka :/). To jest właśnie tekstowy interfejs ze wskaźnikiem przesuwanym co znak za pomocą kursorów klawiatury.

Edit: No i czytelny układ elementów aplikacji. Tragedia w Sound Tracker'ze (szczególnie definiowanie tracku), świetnie rozwiązane w NEO Tracker'ze czy TMC.

Ostatnio edytowany przez mono (2014-08-12 12:31:46)

Ależ ja wiem, że wiesz :) Wyraziłem jedynie swoją opinię na temat złych i niewygodnych interfejsów. Zdaje się, że nasze zdanie jest zbieżne :)

widzisz XXL, prób stworzenia takiego interfejsu było wiele, ale żaden nie wybił się, powinieneś raczej dorzucić swój kamyczek do tego ogródka

no z tym wybieraniem to jest tak że chyba właśnie nie ma z czego wybierać :) bo wszyscy za każdym razem od nowa projektowali interface dla swoich programów, nikt nigdy nie zrobił jednolitej uniwersalnej biblioteki z której można byłoby z prosty sposób skorzystać :)

W dawnych czasach (Code3) mieliśmy nawet taki prymitywny tool na którym rysowaliśmy sobie koncepcje interfejsu użytkownika dla naszych programów, nic skomplikowanego to nie było ale umożliwiało rysowanie ekranów w trybach tekstowych (+wczytanie dowolnego zestawu fontów). Można było mieć kilka ekranów, i przełączać się pomiędzy nimi, zmieniać zestaw znaków w każdej linii, etc.  Służyło nam to jako namiastka takiego edytora WYSIWYG, która pozwalała na zobrazowanie koncepcji interfejsu danego programu. ileż to było dyskusji i sprzeczek "o pierdoły" :) a potem i tak piszący kod "robił po swojemu".

Mój wynalazek, który Ci linkowałem nie ma bufora dla zawartości pod oknem, bo go nie potrzebuje (user też nie wskazuje takiego bufora). Aktualnie procedura rysowania jest wolna bo przy malowaniu każdego bajtu ekranu sprawdza z którego okna wziąć daną, ale można by to poprawić tak, żeby odrysowywało tylko potrzebne klipy. To był eksperyment wynikający z rozmów z JBW, który właśnie doszedł do wniosku, że można tak skonstruować system, że bufor jest niepotrzebny a tylko zajmuje pamięć. Nawet pokazywał mi w TA na pececie taki swój system okienkowy wyglądający na Borlandowy.

to ma byc biblioteka a nie jakas nakladka na atari os.

ja opuszczam program klawiszem reset. jak mam zapisac ustawienia podczas zimnego startu?

Kończę.

Niezły imho pomysł miał JBW w Panther'rze - chodzi o brak ramek w oknach. W trybie 40x24 one faktycznie zajmują tylko miejsce, a mogą być pokazane znacznie bardziej elegancko poprzez wyróżnienie obszaru ekranu, kursor itd. To samo widać w TMC/NEO. Może by tak pójść w takim kierunku? Podkolorowanie sprajtami, znaki tylko do wyświetlania treści (user miałby wtedy nawet generator znaków do własnej dyspozycji po to, żeby wyświetlać treść, a nie malować okna).