Instalacja

KShutDown w najnowszej wersji dostępny jest dla Ubuntu 12.10 i wyżej w postaci paczek deb, ale także dla Arch Linuksa, Debiana Wheezy i wyżej, Fedory 18 i wyżej, Mageii 2 i wyżej, openSUSE 12.2 i wyżej, Slackware 13.37 i wyżej oraz ROSA Desktop i Enterprise.

KShutdown 3.0 - autor

Możemy także własnoręcznie skompilować dostępne źródła lub pobrać uniwersalną paczkę dla wielu systemów Linux. Jest też dostępna przenośna wersja dla Windowsa.

Użytkowanie

KShutDown jest narzędziem niezwykle prostym. Po jego uruchomieniu mamy domyślnie ustawione testowanie wszystkich zdarzeń, jakie się w nim znajdują. Dzięki temu przypadkowe kliknięcie w przycisk zatwierdzenia, nie uruchomi nam od razu wybranej akcji.

Dostępne są następujące akcje:

Aplikacja posiada możliwość definiowania akcji w oparciu o wykryte zdarzenia, np. zakończenie działania programu lub nieaktywność użytkownika. Prócz tego istnieje moduł do tworzenia własnych zdarzeń pod pozycją Extra.

Ciekawostką jest pasek postępu, jaki pojawia się na samej górze ekranu.

KShutDown - pasek postępu

36 Komentarze

  1. KDE to bloat, żeby zainstalować taki mały programik w czystym GNOME muszę pobrać 383,90 MiB zależności.

    To chyba przesada żeby instalować phonona, ebook-tools, nepomuka, qt-webkit i akondai

    • Jaka dystrybucja?
      To nie są bezpośrednie zależności kshutdown. Jeśli kshutdown został zbudowany z bibliotekami KDE to nie ma się co dziwić :D W takiej konfiguracji kshutdown wymaga kdebase4-runtime, kdebase4-workspace i klika innych. Stąd tyle się tego nazbierało… Tak się składa, że w drugą stronę zależności wyglądają tak samo :) Są tacy co mają tylko KDE/Qt bez niczego "na gtk". Dla nich instalacja programu wymagającego gnome będzie taką samą męką…
      Jeśli używasz Gnome, skompiluj kshutdown bez bibliotek KDE, tylko z Qt ;)

    • W Debianie 7.1 z zainstalowanym środowiskiem GNOME instalacja kshutdown bez pakietów polecanych wiąże się ze ściągnięciem 100 pakietów o wadzę 90 MB (260 po rozpakowaniu) w tym np. phonon czy vlc-nox. :)

    • W Archu instalacja gshutdown wymaga jeszcze więcej. Gshutdown wymaga libglade, który wymaga gtk2, który wymaga poza masą bibliotek używanych tylko w programach GTK i Gnome, tony śmieci jak biblioteki do obsługi JPEG2000 czy libcups do drukowania. GShutdown czy KShutdown praktycznie nic z tego co jest zależnością w dystrybucjach nie potrzebują i jeśli zbudować im biblioteki tylko z tym co potrzebują wielkość zależności byłaby niewielka… problem w tym, że w Linuksie programy nie są dostarczane z bibliotekami, a polegają na tym co jest w systemie, dlatego wszystko jest budowane z maksymalnymi możliwościami i drzewko zależności rozrasta się do gigantycznych rozmiarów – jeśli używasz KDE te zależności się dublują i nie obchodzi Cię ich rozmiar, bo to zależności dla większości oprogramowania… wtedy denerwuje Cię instalacja programu z Gnome wymagającego tonę śmieci które użyjesz tylko z tym programem, a on ich nawet nie obsługuje (jednak te zależności są zbudowane tak, żeby działać z masą softu… tylko tobie niepotrzebnego bo używasz innych). Jeśli używasz Gnome i programów GTK to masz tak samo (masę bibliotek masz zainstalowanych ale one się dublują w prawie każdym programie więc na ich wielkość nie zwracasz uwagi, jednak instalując mini programik jak kshutdown zabija Cię informacja o ilości danych do ściągnięcia , bo dystrybucje te zależności kompilują z maksymalną siecią zależności i nie wiedzą, że będziesz chciał używać tylko tak prostej aplikacji i nie przytną Ci tego na miarę).

    • To co piszesz o zależnościach to święta prawda, ale cały czas aplikacje KDE są dużo większym wrzodem na dupie dla użytkowników jakiegokolwiek DE opartego na GTK, niż w drugą stronę.

      Z ciekawości uruchomiłem sobie obraz instalacyjny archa i porównałem kshutdown (+ 1056.55 MiB po rozpakowaniu) z gshutdown (+ 172.13 MiB po rozpakowaniu). To sześciokrotnie więcej zależności!

      To tylko mały przykład. Bardzo miło ze strony twórców kshutdown że można ich kod skompilować w oparciu o czyste QT, wtedy zależności są naprawde znośne, problem w tym że to nie jest częsta praktyka w repozytoriach i nie wszystkie programy dają taką możliwość.

    • To nie takie proste – po prostu w Archu jest o tyle dziwnie z pakietami, że te 172MB pakietów powiązanych z gshutdown nie wymaga… instalacji Xów, które i tak musisz zainstalować, żeby z bibliotek skorzystać w wypadku po prostu pakietów KDE podpięta jest zależność od Xów i innych pakietów, które i tak musisz mieć zainstalowanych w systemie (a przy instalacji w Archu z gnome musisz instalować ręcznie oddzielnie). Dla przykładu całe KDE (razem z programami nieobowiązkowymi jak Amarok itp.) w pakietach Archa ma 250 MB, a reszta z tego GB to pakiety jak Xy (ponad 200 MB) i inne. W wypadku Gnome to są podobne ilości danych tylko akurat w Archu inne osoby zajmują się paczkami i nie dodają zależności rzeczy niezbędnych, ale logicznie zainstalowanych już w systemie.

    • Ale to oznacza, że program nie potrzebuje tylu zależności więc zależności są nieprawidłowo ustalone.

    • Pewnie tak, to już inna sprawa. W archu, jest jeden worek o nazwie kdebase-workspace na którym bazuje sporo pakietów, więc zależności są potwornie monolityczne. Ale od czego mamy pacman -Rdd

    • Nie – zupełnie nie to oznacza. Program A wymaga biblioteki X, podobnie jak program B, ale zupełnie innej części, z innymi możliwościami itd. i osoba pakująca ma problem dopasuje bibliotekę X do potrzeb programu A, aby były minimalne zależności biblioteki od innych bibliotek/programów to program B nie zadziała. Mając wiele programów korzystających z jednej biblioteki (a nie jak w Windows/MacOS/Android/… każda aplikacja ma własną kopię każdej biblioteki), możesz ją tylko uzależnić od wszystkiego co tylko jakiś program może potrzebować, aby była to wersja biblioteki uniwersalna. Ogólnie jest wyjście – albo olbrzymie zależności i współdzielenie bibliotek, albo minimalne zależności bibliotek i każdy program ma swoje własne wersję biblioteki (nie ma mowy o współdzieleniu).

    • "możesz ją tylko uzależnić od wszystkiego co tylko jakiś program może potrzebować, aby była to wersja biblioteki uniwersalna. "

      Chodzi Ci o to, że biblioteka X musi być uzależniona od wszystkiego do czego się gdziekolwiek w kodzie odwołuje? Fakt, że mając inne rozwiązania otwarte do wykorzystania, większość będzie wolała użyć ich zamiast wymyślać koło od nowa i pewnie stąd te rozrastające się zależności.
      Mimo wszystko rozwiązanie typu Click jakie wymyśla Canonical nie jest moim zdaniem lepsze. Będzie ono fajne i użyteczne, szczególnie do dostarczania komercyjnego oprogramowania, ale mam nadzieję, że ani trochę nie naruszy dotychczasowego sytemu dostarczania pakietów programów otwarto-źródłowych.

    • W praktyce – tak musi. Po pierwsze w Linuksowych systemach masz zasadę: nie dubluj kodu i jeśli ktoś już napisał bibliotekę do czegoś to ją do tego wykorzystaj, a nie pisz nowy kod do tego samego, a jeśli korzystasz z kodu innych bibliotek to musisz* do tych bibliotek linkować. Jeśli linkujesz już to jesteś uzależniony.

      * no dobra możesz też dynamicznie ładować biblioteki jak pluginy przez dlopen() i pobierać ręcznie wskaźniki na wszystkie funkcje jakich używasz, ale zważywszy na dużą ilość bezsensownie napisanego dodatkowego kodu (pomijam już problem z brakiem dlopen i innymi nazwami bibliotek dynamicznych w windowsie), który jest podatny na błędy w czasie runtime przez literówkę (kompilator nie będzie ostrzegał), to na dodatek mocno utrudnia debuggowanie aplikacji. Nie możesz tego uznać za sensowną alternatywę.

    • "kompiluj kshutdown bez bibliotek KDE, tylko z Qt ;)"

      To po co te wszystkie zależności, skoro program ich nie używa? Może tylko dlatego, aby w main.cpp napisać KApplication zamiast QApplication? ;)

    • Akurat na podanej stronie nie opisano różnicy w działania obu wersji. Ale domyślam się, że cała zależność od kdelibs potrzebna jest do integracji programu ze środowiskiem KDE.

  2. Gdy komuś w GNOME przeszkadzają te olbrzymie zależności to nic innego nie pozostaje jak konsola :p albo gnomowy GShutdown lub ewentualnie taki malutki programik wykorzystujący okienka Zenity http://tiny.pl/hzj4x Ten ostatni nie wymaga nawet instalacji.

    • Odnośnie odtwarzacza to grając cover piosenki, która startuje od razu nie dając szans na równe rozpoczęcie grania napisałem sobie skrypt…

      #!/bin/bash
      mpc -h 192.168.1.102 stop
      echo "3"
      sleep 1
      echo "2"
      sleep 1
      echo "1"
      sleep 1
      mpc -h 192.168.1.102 play 66

    • ~/.bash_rc:
      alias mpccountdown='mpc -h 192.168.1.102 stop && for k in 3 2 1; do echo $k; sleep 1; done && mpc -h 192.168.1.102 play $1'

      $ mpccountdown 66

    • Możesz mi powiedzieć po co ten sleep? Samo "shutdown -h +120" (lub zamiast +120 minut napisać po prostu godzinę o której ma to zrobić jak czyli przykładowo shutdown -h 23:05) wydaje się lepszym pomysłem.

    • Dlaczego lepszym? Wygląd nie czyni skryptu lepszym (przynajmniej na takim poziomie, kiedy nie trzeba go 'utrzymywać'), jeżeli wszystko działa tak jak chciał, to nie ma lepszego rozwiądania.

    • Jest bardziej czytelny, nie wymaga pipeowania, nie zapomni o zadaniu po wyłączeniu przypadkiem konsoli (w przypadku podanego przykładu tak będzie i trzeba by to wpisać w skrypt i uruchomić go w tle (dopisać "&" po skrypcie)). Samo shoutdown jest po prostu lepszym sposobem – nie, że korzystanie z uruchomienia warunkowego jak "&&" nie spełniało swojego zadania, bo spełnia, ale jest wyjściem gorszym (zarówno w zapisie, jak i w działaniu, bo trzeba pamiętać o wysyłaniu tego polecenia w tło, aby zamknięcie terminala konsoli nie odwoływało zaplanowanego zamknięcia).

    • Strasznie komplikujesz sobie życie z tym 60*60*2=7200 i widać, że nigdy nie widziałeś man sleep. Gdybyś widział, to wiedziałbyś, że można prościej czyli:
      sleep 2h

    • Szkoda, że nie ma jednostki milisekund. Oraz że tylko niektóre implementacje obsługują ułamki dziesiętne jako milisekundy, i tak mając problemy z lokalizacją i robiąc problemy przy przecinku i kropce. Napisałby ktoś wreszcie to polecenie porządnie…

Odpowiedz