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

Podobne artykuły

Oprogramowanie

przez -
0 284
Oprogramowanie

przez -
0 318
  • stiff

    U mnie świetnie działa wersja pobrana z tej strony http://linuxappfinder.com/package/kshutdown/?v=3….
    Dokładnie experimental 3.0-1kde4.10
    Używam Kubuntu 12.04 z KDE 4.10.5

  • W artykule są tak samo zrzuty z wersji skompilowanej na Xubuntu 13.04 :D

  • Kaleson

    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

    • stiff

      zainstaluj gpoweroff jak msz gnome :)

    • mxl

      Nie pozostaje nic innego, jak czekać na gotowe KDE Frameworks 5…

    • Fisiu

      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 ;)

    • blind

      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. :)

    • ali

      Podziekuj za to paczkującym.

    • pijaczek

      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ę).

    • Kaleson

      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ść.

    • pijaczek

      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.

    • MikołajS

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

    • Kaleson

      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

    • pijaczek

      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).

    • MikołajS

      "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.

    • pijaczek

      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ę.

    • MikołajS

      "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? ;)

    • Fisiu

      Gdybyś zajrzał na stronę programu to być się nie pytał tutaj. http://kshutdown.sourceforge.net/README.html#kdev

    • MikołajS

      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.

    • herr

      Supported Functions/Platforms

      Tu jest.

  • Jacuś

    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.

  • Cóż za dziwny wynalazek. Ja to zawsze odpalałem konsolę Pythona, obliczałem ile sekund mają np. 2 godziny czyli 60*60*2 i w konsolę, su, sleep 7200 && shutdown -h now i tyle ;)

    • adams

      Dokładnie :)
      Albo
      sleep 1800 && killall clementine

    • 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

    • o_O

      ~/.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

    • pijaczek

      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.

    • Rudyf

      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.

    • pijaczek

      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).

    • Dzięki, nie wiedziałem, że można w ten sposób używać shutdown :)

    • Dede

      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

    • o_O

      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…

  • MamWindowsa

    to w Linux dopiero takie cos zrobili?:O W Windowsie to jest od 100 lat…

    • o_O

      MaszDowna.

  • o_O

    Screeny: KShutdown odpalony na gniocie… świętokradztwo ;)

    • O_o

      Screeny: Gniot odpalony na XFCE… świętokradztwo ;)