Udzielone Odpowiedzi
- AutorPosty
- 2 lipca 2018 o 15:27 W odpowiedzi do: [SOLVED] Program do dodawania kolorowych tekstów, kresek itp. #7858pavbaranovForumowicz
O ile się nie mylę, to deepin-draw ma własne narzędzie zbliżone do qt5ct (nb. unikasz aplikacji KDE, a używasz Deepin). Spróbuj może uruchomić ten program z pominięciem qt5ct – może da to jakiś efekt.
Spróbuj może jeszcze taki programik jak dibuja – z opisu wygląda na prosty.
2 lipca 2018 o 11:37 W odpowiedzi do: [SOLVED] Program do dodawania kolorowych tekstów, kresek itp. #7856pavbaranovForumowiczCoś tu znajdziesz ;)
Proste? MyPaint, XPaint, mtPaint… Są jeszcze na javie np. Pixelitor, Helios… Od groma. Te pierwsze na Gtk zatem nawet nie pociągną Ci wielu zależności i w mniejszym stopniu będą obciążać komputer przy pracy.Jeśli chodzi o deepin-draw – nie mam u siebie opisywanego przez Ciebie problemu. Pomijając raczej dość mierne możliwości tego programu i mylące tłumaczenia (kolor linii dla rysowania kształtów nazywa się tu „wypełnij”, a samo „wypełnianie” ich tak jak to ma miejsce w innych programach raczej działać nie chce, to obawiam się, że nawet zdiagnozowanie problemu poprzez uruchomienie programu z konsoli niewiele Ci da, ale możesz to uczynić.
Pomijam też, że program dociąga bezsensowne dla Ciebie zależności jak np. deepin-notyfications – programik, który ma sens tylko i wyłącznie w środowisku Deepin i w żadnym innym.pavbaranovForumowiczJest od groma serwisów on-line, których jedynym zadaniem jest zrobienie gifa z plików jpeg/png itd. Są też małe programiki do robienia gifów. Polecam stronę alternativeto.net.
pavbaranovForumowiczNa 99% masz winnego. Takie montowanie/odmontowywanie się urządzenia podczas korzystania z jego pamięci jest najbardziej prawdopodobnym powodem tego, co Cię spotkało. Całe szczęście, pamięć się fizycznie nie uszkodziła. Jeśli coś takiego występuje, to najlepiej jest znaleźć jakiś program narzędziowy, który „poukłada” taką pamięć ponownie. Ostatecznie właśnie „formatowanie pamięci”.
Jeśli chodzi o „formatowanie pamięci” – no to ono właśnie tak działa na Androidzie. Przywraca „stan domyślny”, ale plików konfiguracyjnych najczęściej nie rusza (a tak zwykle jest historia).
pavbaranovForumowiczPrey – w przypadku linuksa z systemd – jest uruchamiany przez jego usługę. Jeśli ktoś uruchomi Twój komputer, na Twoim systemie, to w istocie wpierw podniesie się prey, a potem, gdy podłączy się do sieci (swojej, zatem Twoje ustawienia nie mają tu żadnego znaczenia) – w istocie być może zlokalizujesz swój komputer. W żadnym innym przypadku nie masz możliwości jego lokalizacji.
Sądzę, że czyjś komputer można ukraść z dwu powodów: albo ze względu na samą rzecz albo ze względu na zawarte na nim dane. W drugim przypadku możesz się jako tako ustrzec przed próbą dobrania się do danych poprzez zaszyfrowanie danych bądź dysku.
W pierwszym przypadku, prey zadziała wyłącznie wówczas, jeśli złodziej jest idiotą do kwadratu (czyli nie dość, że odpali ten komputer, to jeszcze widząc konto gościa z niego usłużnie skorzysta, a następnie podłączy się do jakiejś sieci wifi) możesz liczyć na szczęście. Innymi słowy – całe zabezpieczenie, jakie obecnie kombinujesz jest na być może początkującego złodzieja, w dodatku bez żadnego wsparcia kolegów „z branży”.
Jedyna sensowna aplikacja, która pozwalałaby na lokalizowanie komputera musiałaby być podnoszona jeszcze zanim w ogóle system wystartuje i to niezależnie od niego.Tak, czy inaczej – odpowiedź na pytanie, które zadałeś – masz udzieloną wraz z przykładami.
pavbaranovForumowiczZobacz. Ja to zwykle robię z wykorzystaniem nmtui.
Pamiętaj jednak o jednej rzeczy. Nawet, gdy połączenie jest skonfigurowane w taki sposób, że nawiązuje się dopiero po podniesieniu się DE, to i tak sama usługa działa dużo wcześniej (przy bootowaniu) i „czeka” na konfigurację. W przypadku podniesienia przy bootowaniu:
– jeśli złodziej połączy się przez kabel – w istocie być może zlokalizujesz swój laptop (nie wiem jak ten prey działa);
– jeśli połączy się do dowolnej sieci niekablowej (wifi, mobilna), to w takim przypadku, połączenie z wifi „przy starcie” systemu nic Ci nie daje, gdyż wówczas – abyś mógł znaleźć złodzieja, to musiałby połączyć się z… Twoją (prekonfigurowaną) siecią. Jeśli będzie chciał się połączyć z inną, to musi ją skonfigurować sam, niezależnie.
Wydaje się, że samo skonfigurowanie prey wystarcza – jak się złodziej w dowolny sposób sam połączy z siecią na Twoim systemie i bez ingerencji w niego – to zlokalizujesz komputer. Innymi słowy – prey ochroni Cię jedynie przed złodziejem idiotą.pavbaranovForumowicz@enszur – Wykonaj tę listę (masz komentarze jak uznałem za potrzebne). Aha, zakładam, że Twoje środowisko to Deepin w Manjaro Deepin (zobacz, czy się nie mylę). Teraz już lista:
1. Gdy pojawi Ci się SDDM:ctrl+alt+F2
podajesz swój login, enter, hasło (nie będzie widoczne podczas wpisywania), enter.
2.sudo systemctl stop sddm
3.sudo pacman -Rns gdm
4.sudo pacman -Syu deepin deepin-extra networkmanager
5.sudo nano /etc/lightdm/lightdm.conf
w sekcji [Seat:*] dopisz:
greeter-session=lightdm-deepin-greeter
zamknij edytor zapisując zmiany.
6.sudo ln -s /usr/share/backgrounds/deepin/desktop.jpg /usr/share/backgrounds/default_background.jpg
7.sudo ln -s /usr/share/backgrounds/deepin/desktop.jpg /usr/share/backgrounds/background_desktop.jpg
8.sudo systemctl disable sddm
9.sudo systemctl enable lightdm
10.sync && reboot
W ten sposób powinieneś wyrzucić z systemu GDM wraz ze wszystkim co przyniósł (3); dokonać aktualizacji oraz ponownej instalacji całego Deepin DE (4), instalacji, konfiguracji i uruchomienia lightdm, deaktywacji sddm oraz zrestartowania systemu. Sprawdź, czy to działa. Na razie jeszcze nie usuwaj SDDM (może się przydać).
Jeśli będą jakieś błędy – napisz jakie.
Jeśli dalej będzie toPointer to TMDS table invalid
, to ten błąd jest związany ze sterownikiem nouveau i w istocie może objawiać się zawieszeniem się systemu na DM. Dobrzy ludzie w necie twierdzą, że zmiana sterownika nouveau na nvidia pomaga w takim przypadku.pavbaranovForumowiczCo zakomentowałeś? W SDDM nie istnieje taki wpis jak w LightDM. Całe /etc/sddm.conf w moim przypadku (komentarze po #):
cat /etc/sddm.conf [Autologin] # generalnie ma znaczenie wyłącznie jeśli się używa automatycznego logowania do systemu Relogin=false # tu: "nie" - nie będzie w razie błędu próbował ponownie logować mnie do domyślnej sesji Session=plasma.desktop # to owa domyślna sesja dla autologowania User=pb # domyślny użytkownik [General] HaltCommand= RebootCommand= [Theme] # nie ma większego znaczenia - ustawienia wyglądu Current=breeze CursorTheme=breeze_cursors [Users] # znaczenie ma, ale nie jest istotne teraz o tym rozmawiać MaximumUid=65000 MinimumUid=1000
Jeśli chodzi o błąd, który masz – na 99% to nie kwestia związana z DM. Teoretycznie po zabiciu SDDM powinieneś mieć możliwość uruchomienia Deepin przez bodaj startdde. Coś się u Ciebie posypało również z innymi rzeczami, jak tylko LightDM. W sumie, to temat na inny wątek. Proponuję przywrócić Manjaro Deepin do w miarę oryginalnego poziomu, czyli zrobić to co w moim poprzednim wpisie (oczywiście też uruchomić LightDM). Jeśli będzie występował błąd z urządzeniami wejściowymi, to załóż nowy, a ten pozostawmy na lepsze czasy, gdy już owe urządzenia wejściowe działać będą.
pavbaranovForumowiczPamiętajmy jednak, że w przypadku LightDM (i nie tylko jego) – niemal wszystkie wiersze zakomentowane są jednocześnie domyślnie przetwarzane. Stąd w wielu przypadkach nie ma znaczenia, czy mamy '#cośtam = coś’czy mamy
cośtam = coś
, bo to na to samo wychodzi. dopiero dokonanie zmiany nacośtam = inne_coś
daje spodziewany efekt. Choć nie zawsze tak to działa i często jest jak mówi @azja (szczególnie w oprogramowaniu z dawnych, dobrych czasów). Zresztą wszystko zależy od tego, czy oprócz jakichś *.conf np. w /etc/ nie ma jakichś szkieletów, do których program dobiera się, gdy już żadnych plików konfiguracyjnych nie ma. W przypadku dystrybucji, które każą wszystko/wiele robić samemu (Gentoo, Arch) – takich szkieletów prawie nie ma, ale w przypadku dystrybucji „user-friendly” takich sporo. I mam tu wieczne pytanie – dlaczego to q… nie jest porządnie opisane, że w porównaniu do rozwiązania upstreamowego wprowadziliśmy X do plików konfiguracyjnych, które zamieściliśmy w Y. Kurcze ani filozofii skończyć nie trzeba, ani też tych kilka słów nie zbawi.Podsumowując wątek @enszur:
1. Zrobić porządek w pliku *.conf
2. Zrobić to co pod zgłoszeniem błędu w Archu.
3. Ew. wyedytować linię, na którą wskazuje @azja (ale w Sink) i dopisać sesję deepin.
LightDM musi zadziałać.pavbaranovForumowicz@azja – To i jak ja na początku. Niestety trudno na użytkownikach dowolnego forum wymóc, by przedstawiali problem dokładnie tak jak wygląda i dokładnie na czym polega. Potem pretensje do wszystkich, ale nie do siebie samego.
pavbaranovForumowicz@azja – Z całym szacunkiem, ale lekko pomieszałeś (dla laika; nie Tobie to tłumaczę).
Masz absolutną rację, że odkomentowanie owego:
# greeter-session = Session to load for greeter
w miejscu i w sposób, w jaki to zostało dokonane nie ma żadnego sensu, a LightDM (greeter) nie będzie w stanie przetworzyć „Session to load for greeter”.
Masz też rację – sterowanie obecnego LightDM odbywa się w sekcji [Seat:*] i to tu dokonujemy zmian. Niemniej jednak takie coś:[Seat:*] #greeter-session=example-gtk-gnome
niczego nie wnosi, albowiem jest zakomentowane. Tzn. niezależnie czy będzie zakomentowane, czy nie – i tak podniesie Gnome (będzie chciało podnieść gnome). Aby dokonać zmian należy:
1. odkomentować wpis
2. w miejscuexample-gtk-gnome
umieścić to co potrzebne (tu coś z Deepin, ale nie wiem jak się to akurat w tym przypadku nazywa, a nie chce mi się szukać).
Dopiero wówczas sesja deepin zostanie podniesiona prawidłowo.pavbaranovForumowiczpavbaranovForumowicz@azja – To jednak zdaje się, że nie linux, a android. Dość wczesny nawet (kernel 2.6.x). Nikt nie jest w stanie odpowiedzieć na tak zadane pytanie i zdiagnozować problemu, chyba, że doskonale się zna na Androidzie. Po prostu ten typ tak miał (wersje do 2.x). Lubił tego typu sytuacje i dlatego niemal w każdym Androidzie masz owe „przywrócenie ustawień domyślnych”, czy „formatuj pamięć”. Innymi słowy – rozwiązanie jest, ale problemem jest jak zapobiec sytuacji, która go wymaga. W tym przypadku to praktycznie problem nierozwiązywalny. Rączki do boga, a w zasadzie do Google’a.
25 czerwca 2018 o 12:26 W odpowiedzi do: [SOLVED] Wersje KDE i XFCE i różne reakcje na modem Huawei E173 #7810pavbaranovForumowiczTemat w zasadzie rozwiązany, ale jeśli się chcesz pobawić w jego wyjaśnienie i ewentualne zgłoszenie błędu w KDE (o ile jest), to daj znać. Może się uda i może dzięki temu będzie coś lepiej.
pavbaranovForumowiczNiestartujący moduł odpowiada za bluetooth – jeśli nie używasz – możesz zignorować. Drugi to jakiś vfs_monitor (i pewnie służy monitorowaniu vfs :)). O drugim z problemów sporo w necie – instalacja plików nagłówkowych kernela oraz aktualizacja deepin-anything do wersji 0.0.1-2 winny pomóc.
Zdiagnozować możesz tak, jak Ci napisało:systemctl status systemd-modules-load.service
Generalnie – z uwagi na to, że system nie potrafi znaleźć jakichś modułów, to należałoby zacząć od nagłówków. Po prostu brakuje Ci czegoś (ich?) w systmie. - AutorPosty