GUI w skryptach?

zasadniczo jestem przeciwny takiemu pomysłowi. celem skryptów jest automatyzacja, a ich największą zaletą jest przetwarzanie potokowe – wyjście jednego skryptu staje się wejściem dla innego. dodanie GUI łamie te zasady – przede wszystkim zakłada interakcję, podczas gdy punktem wyjścia dla skryptu jest podanie parametrów 'up front’ dające automatyzację danego zadania. 

GUI jest oczywiście niezbędny dla 1szej/2giej linii, ale również pojedyncze zadania łatwiej przeważnie wyklikać. można też wyobrazić sobie rozwiązanie 'hybrydowe’ [takie modne słowo w dzisiejszych czasach… od paznokci poprzez samochody aż po architekturę IT] – skrypt przyjmuje parametr [np. nazwę pliq wejściowego], a kiedy go nie ma, pokazuje jakiś file-picker czy coś… nie jest to koszerne, ale koniec-końców decyduje zamawiający.

w ostatnim czasie musiałem wrócić do poważnego skryptowania [yyyeeeeey! (= ] właśnie z myślą o narzędziach dla 1szej linii. w zwizq z tym musiałem zmierzyć się z pisaniem pełnego GUI w PowerShell. w związq z tym kilka wniosków i spostrzeżeń.

GUI w PS – możliwości

w oprogramowaniu GUI jestem n00bem. ostatnie aplikacje okienkowe pisałem w Javie na studiach. do tego jeszcze moja ogólna niechęć do takiego pisania… a więc wpis cenny dla tych, którzy są na tej samej drodze. 

są trzy podstawowe metody uzyskania interfejsu dla skryptów:

• natywne metody PS – jest ich oczywiście niezmiernie mało i są bardzo ograniczone. tak na prawdę ogranicza się do albo sczytywania z linii poleceń [nie bardzo GUI, ale jest interakcja) albo out-GridView – który jest genialną metodą do zrobienia szybkiego 'pickera’ wartości. dodałbym też tutaj funkcję

  [System.Windows.MessageBox]::Show(MessageBody,Title,ButtonType,Image)

  która natywna dla PS nie jest, ale dobrze uzupełnia możliwości.
  
• wykorzystanie obiektu DCOM wscript.shell  który daje możliwość wyświetlenia prostego okienka podobnie do .NET. osobiście mierzi mnie łączenie tak odległych technik jak PS i WScript – IMHO to błąd i zamieszczam wyłącznie żeby napisać: „nie korzystać! to jest legacy crap„
• no i oczywiście pełnoprawne GUI – albo poprzez biblioteki Forms lub WPF. 

dokładniejszy opis w przyszłości, co kiedy jak i z jakim efektem, a póki co

narzędzie dla skryptów na poważnie

zwykłe ISE przestaje wystarczać – nie tyle z powodu samego GUI, co ogólnie tego, że ostatnio piszę więcej. zacisnąłem zęby i po raz kolejny przesiedziałem nad odpaleniem VSCode. VSC niestety jest makabrycznym narzędziem, jednak jego potencjał i choćby możliwości integracyjne są na tyle ważne, że cóż.. płaczę, ale walczę. kiedy to było tylko hobby, odpuszczałem zniechęcony, ale kiedy trzeba bardziej na poważnie, musiałem się złamać

• VSC jest uniwersalnym narzędziem developerskim. dwa kluczowe słowa: uniwersalne i developerskie – w zasadzie wskazują jego wady. uniwersalne – wszystkiego jest za dużo, 8o% opcji jest zbędne przy pisaniu w PS. po instalacji dostajemy coś, czego do pisania w PS nie da się używać – a więc czeka nas czytanie serii artykułów i wpisów na forum, które pluginy zainstalować, jak skonfigurować, które z tysięcy opcji jak ustawić żeby uzyskać jakiś sensowny efekt.
  to co kiedyś było potęgą produktów MS – integralność i trzymanie się pojedynczych standardów – załamało się wraz z „powszechną linuxyzacją”. dziś wszystko trzeba wybrać z pośród dziesiątek lub setek różnych dodatków i zaczynają się problemy że 'ten dodatek jest szybszy a tamten ma taką opcję, a inny gryzie się z tamtym ale ma tą funkcję..’ .. i tak zaczyna się żmudna żonglerka dobrania sobie zestawu pluginów tak, aby mieć maksymalnie dużo wymaganych funkcji, równocześnie nie przeciążyć środowiska zbytecznymi śmieciami …
• …które doprowadzą do niestabilności. podstawowe zastrzeżenie jakie mam do VSC to niestabilność, a zwłaszcza inteliSens, który regularnie przestaje działać w trakcie pisania. skrót „alt-ctrl-p, reload” już mi wszedł w krew /: [muszę poszukać pluginu, który mi doda tą operację pod jednym guzikiem q:]. o ile ISE zawieszało się w bardzo szczególnych przypadkach [np. korzystając z commadletów Exchange] o tyle VSC wywala się jak archetypiczny open source. poprawki wydawane typowo agile – czyli update za updatem i trzymanie kciuków, czy dziś będzie się wywalać się bardziej….  welcome to open source .. and agile.    

czemu warto pocierpieć? przy pewnej wielkości czy skomplikowaniu skryptu, nie mówiąc o projekcie w którym tych skryptów jest wiele, ale nawet kiedy po porostu trzeba przy nich popracować więcej – ISE to za mało. lepsze wyświetlanie składni, czy masy skrótów klawiszowych, znacznie przyspieszają pracę. integracja z repo, projekty… jest wiele dodatków, bez których byłoby więcej ręcznej pracy – czyli to co jest wadą, przy zainwestowaniu czasu, staje się podstawową przewagą.

jeśli więc czeka cię przesiadka – zarezerwuj sobie przynajmniej tydzień nieskończonej cierpliwości. będzie za to nagroda w postaci dużych możliwości i jeszcze większego potencjału. jeśli jednak nie korzystasz z repo, piszesz hobbystycznie lub okazjonalnie – ISE to wszystko co potrzebne i szkoda czasu i stresu. 

pisanie GUI

niestety VSC nie pomaga zbytnio w pisaniu GUI. może są dodatki, których jeszcze nie znalazłem, ale ogólnie – oprogramowanie GUI w edytorze nie-wizualnym to porażka. kilka elementów i robią się setki linii kodu ciężkie do ogarnięcia. ustawianie guzików zmieniając ich położenie wartościami X/Y na czuja – makabra. interfejs najlepiej się rysuje w interfejsie, dla tego najsensowniej jest mieć coś wizualnego. chciałoby się powiedzieć Visual Studio… huh, ale VS do pisania skryptów PS, to jak instalacja Exchange on prem w pełnej redundancji do wysyłania kilq emali. 

w skrócie – cały czas jestem w trakcie poszukiwania jakiegoś lekkiego designera interfejsu. te, które testowałem online były … jak to aplikacje online – siermiężne i ograniczone. 

forms vs UWP vs WPF

już sam wybór tego w czym ten interfejs ma być napisany nie jest łatwy. formsy wygrywają ilością dostępnych przykładów, UWP [chyba] umiera, WPF niby jest trendem, nowsze, nowocześniejsze i bardziej uniwersalne… ale czy przyszłościowe? no właśnie – nawet po przeczytaniu kilq artów, jeśli nie siedzi się w temacie, sam dobór biblioteki nie jest trywialny. jeśli się uczyć, chciałoby się nauczyć czegoś, co choć przez kilka lat się przyda. a to w obecnym tempie zmian niełatwe zadanie. 

osobiście póki co zdecydowałem się na formsy – stare, dobre, oklepane, dużo przykładów, a póki Microsoft nie zrezygnuje z Windows na rzecz jakiejś hybrydowej dystrybucji [chciałoby się powiedzieć Lindows, ale to już było] , zgromadzona wiedza powinna żyć przez jakiś czas.

zmiana logiki

ciekawym aspektem jest zmiana paradygmatu całej logiki działania. skrypty, poniekąd z samej definicji skryptu – przetwarzane są sekwencyjnie linia po linii. tak też logika pisania jest 'liniowa’. GUI to z kolei 'rozproszona logika’ pozaczepiania pod elementy interfejsu. całość nie jest już jak opowiadanie:

begin { początkiem }
process { rozwinięciem }
end { i końcem }

w zamian staje się fragmentarycznym kodem, sterowanym akcjami z kliknięć czy innych list. dla skrypciarza z krwi i kości to jest inny świat. dziwny i nie do końca logiczny. 

GUI + skrypt

na tym etapie nie mam jeszcze wyrobionych 'best practice’ więc poszuqję. jednym z pomysłów było zadziałanie tak, jak to przez pewien czas projektował Microsoft [i co mi się bardzo podobało] – interfejs służył do zebrania informacji, wizualizacji elementów, ale ostateczna akcja to był po prostu skrypt uruchomiony z parametrami, których wartości były zebrane z interfejsu.

takie podejście jest świetne jednak w momencie kiedy pisze się duże, rozbudowane narzędzie, aplikację pozwalającą na wykonanie wielu zadań. jednak drobny tool, którego celem jest właśnie ograniczenie wyborów i dostosowanie do konkretnego zadania w konkretnym środowisq powoduje, że rozdzielenie na dwa niezależne skrypty [jeden to GUI do zebrania parametrów, drugi do wykonania akcji] tworzy dużą nadmiarowość. ponadto takie podejście choć 'ładne’ i logiczne, utrudnia uruchomienie osobom, które tych skryptów się już i tak boją. to te niuanse – łatwiej komuś nieqmatemu przesłać jeden plik do uruchomienia, niż kilka, z opisem jak zrobić bibliotekę, czy jak przygotować środowisko. w regularnej aplikacji załatwia to instalator, przy skrypcie to już nie takie proste. 

z kolei zaletami oddzielenia GUI od logiki jest łatwiejsze panowanie nad samym wykonaniem, no i dla osób, które GUI nie potrzebują – od razu jest narzędzie. większa uniwersalność. mam nadzieję pokazać przykłady za jakiś czas.

praktyka pokaże który sposób wygra, choć widzę coraz więcej zalet rozbicia tego monolitycznego podejścia na rzecz bardziej uniwersalnej metody…

kompromis

skoro skrypty nie są do pisania GUI, przesiadka jest trudna, to czemu po prostu nie zacząć pisać np. w C#? 

proste: mimo-wszystko łatwiej nauczyć się oprogramowania samych Formsów, niż całego języka. na drugi dzień byłem w stanie narysować prosty interfejs, podpiąć logikę i zbudować jakiś działający skrypt. a to dla tego, że cała faktyczna logika, aktywna część działania była tym, co znam, w postaci commandletów. nauczenie się napisania tego w C# i poznanie całej specyfiki samego języka, zajęła by znacznie więcej czasu. choć podobny do PS – jest czyś zupełnie innym. no i podstawowa rzecz – nie zamierzam być developerem [może kiedyś, hobbystycznie] a tego rodzaju zadania są 'szybkim wsparciem’, a nie moim codziennym zajęciem. póki co nauka C# byłaby stratą czasu. 

jak mawiają: 'życie składa się z kompromisów’. kompromisem jest tutaj wyważenie efektu i czasu. pozostają zalety skryptu: kod nie jest kompilowany, łatwo go przeczytać a w razie potrzeby zmodyfikować 'gdziekolwiek’, bo bez konieczności rekompilacji, commandlety dają obszerne biblioteki o olbrzymich możliwościach, a równocześnie można dopiąć kawałek GUI – i to wszystko w bardzo krótkim czasie.

może Frankenstein, ale żywy i myślący. 

eN.