orbdrupal képe

Beküldte orbdrupal - 2006. október 23. 12.14

Most kicsit általánosságban beszélek, nem feltétlenül fogom a Drupal kifejezéseit használni:

Szóval azt szerettem volna, hogy legyen a következő 3 hierarchia:
Hírek, Cikkek, Letöltések.
A Letöltések és a Cikkek olyan hierarchiában legyenek hogy, ezekbe közvetlenül tartalmat is és al-kategóriát is bele tudjak rakni. A Hírek pedig olyan hierarchiában mutatkozzon meg, amibe nem akarok közvetlenül tartalmat belehelyezni, hanem csak a benne lévő alkategóriákba.

Az első amit rosszul értettem meg (remélem), hogy szótárba nem rakunk "egyenesen" tartalmat, hanem a szótáron belül készítünk Kifejezéseket és azokba "rakjuk bele" a tartalmat.
Továbbá a másik, hogy nem jól kezeltem, a taxonomy_menu és a "sima" menü-ket.

A megoldás, ami még mindig nem biztos, hogy a legoptimálisabb az, hogy készítettem egy Általános letöltések és Általános cikkek Szótárat. Ezeken belül készítettem egy-egy Letöltések és Cikkek kifejezést és a Letöltések, Cikkek tartalmakat, a nekik megfelelő kifejezésekbe helyeztem. A főmenübe pedig nem az Általános letöltések és Általános hírek szótárat raktam ki, mint menüpontot, hanem az ezekben lévő Letöltések, Cikkek kifejezéseket.

Ezzel elértem azt, hogy tudok tartalmat rakni a Letöltések-be és a Cikkek-be "közvetlenül" is és tudok alkategóriákat (kifejezéseket) is belerakni és ezekbe természetesen tartalmat is.


ha pedig taxonomy-t kell kiiratni, akkor először megjelenítem egy táblázatos formában a taxonomy-ban lévő termeket, majd a taxonomy-ban lévő tartalmakat (persze nem keruzívan!) ... na ez az, ami nem megy;(

Adott a következő példa hierarchia (kifejezések):

  1. Hírek
    1. 2006
      1. 2006 I. negyedév
      2. 2006 II. negyedév
      3. 2006 III. negyedév
        1. Fő hírek
        2. Al hírek
        3. Régi hírek
  2. 2006 IV. negyedék

A menünél nice_menu-t használok. Amikor rámegyek egy menüre, amiben van almenü, akkor az "kibomlik", de amikor kiválasztok egy menüpontot, akkor a menü ugye eltűnik. Ezt akartam úgy megoldani, hogy a "tartalmak" helyén is láthatóak legyen az al-kifejezések (almenük) listája is és a tartalmak is.

A fenti példában tartalom "bárhol lehet", így amikor kiválasztom, hogy pl. "2006", akkor a "2006"-ban lévő tartalmak jelenjenek meg, majd a 2006-ban lévő kifejezések is (alkategóriák).
Tehát a 2006 kiválasztásakor a tartalmak helyén ez jelenik meg:

(ezek linkek, amik a megfelelő kifejezésekre mutatnak: www.sajatoldal.hu/?q=taxonomy_menu/4/10/27)
- 2006 I. negyedév
- 2006 II. negyedév
- 2006 III. negyedév
- 2006 IV. negyedév
majd alatta a "közvetlenül" a 2006-ban lévő tartalmak jelennek meg.
Remélem kicsit azért érthető voltam;]

0
0
fox mulder képe

Beküldte fox mulder - 2009. február 22. 13.00

Ha te hoztad létre az új mezőket, akkor ezekhez nem lehet CSS szabály rendelve (ha más fejlesztette az oldalt).

Szóval (látom, zen sminket használ az oldal) marad az, hogy megnézed a sites/all/themes/zen/zen/node.tpl.php fájlt. Ebben van egy print $content; sor, elvileg ennek a $content-nek kéne tartalmaznia az összes CCK meződet. Lehet, hogy a fejlesztő nem a $content tartalmát küldi a kimenetre, hanem külön változókként a mezőket, például a <div class="ertekelesek"> rész belsejében ilyesmi: print $field_design, vagy print $field_sebesseg. Ez esetben majd valami ilyesmit kell írnod a node.tpl.php-ba:

<?php if(field_jogallas): ?>
<div class="jogallas">
<?php print $node->field_jogallas; ?>
</div>
<?php endif; ?>

Vagy ki lehetne iratni magát a $content változót, megnézni, hogy benne van-e a jogállás, a fejlesztő stb. (persze ezt a kiírást az is látni fogja, aki épp most böngészi az oldalt):

<pre>
<?php print_r($content); ?>
</pre>
0
0

Fox Mulder

aksza képe

Beküldte aksza - 2010. április 23. 17.17

Szia!
Nem fog bántani senki, ne izgulj, ha meg igen bántsd vissza:-)
A feliratkozásokkal alap helyzetben nem szokott gond lenni, megy az e-mail, ott van link arra kattintasz, és fel vagy iratkozva.
Ha használod a mimemail modult (azzal lehet küldeni formázott, képpel díszített html levelet) annak a képküldés részével vannak gondok.

De itt a megoldás:
mimemail.inc fájlt változtatni kell az alábbiak szerint:

 }
 
   $ret = $files;
-  $files = array();
+  $files = array();
+  $filenames = array();
   return $ret;
 }

Ha csak sima formázatlan levelet akarsz küldeni az megfelelő szerver beállítások mellett sima ügy szokott lenni.

Fontos a hírlevél küldésnél és ezért vélik sokan hibásnak, hogy az időzített feladatok futásával mennek ki a levelek, általában 30 / cron futás (ez állítható, de nem ajánlott több, idő túllépés miatt)
Az időzített feladatokat vagy szerver szinten kell beállítani (http://lapod.hu/cron.php-nak kell futni), ez vagy admin felületen, vagy a rendszergazdával megbeszélve lehetséges.
Ha ez valami miatt nem lehetséges akkor poormanscron modullal tudod áthidalni a problémát.

Első körben kézzel is futtathatod az időzített feladatokat, az admin / jelentések /állapot jelentés menüpontból, de mindenképpen ajánlott ezt valahogy rendezni, mert több szolgáltatás is használja (keresés, aggregált hírek, frissítés stb)

Megnéztem a contact űrlapodat azzal is ugyan ez a hiba üzenet, mielőtt bármit csinálsz egyeztess a szerver üzemeltetővel, írd le neki ezt a hibát.

0
0
y50cw képe

Beküldte y50cw - 2011. június 21. 19.42

Teljesen igazad van, először így csináltam én is. De aztán... Ez az ajaxos hiba nem csak itt jött elő.

Nagy méretű tartalmaknál kiakadt. node.module: drupal_set_time_limit(240);.

Nagy méretű tartalom indexelése kiakadt. Na mondjuk az nagyon.
search.admin.inc: $items = drupal_map_assoc(array(10, 20, 50, 100, 200, 500)); Sok.
Ha 10, egyenként 1-1.5Mbyte (A szöveg mérete) méretű tartalmat indexelt, hát igencsak szétesett. Bekerült egy kisebb érték plusszban, tökéletes.
Viszont emiatt system.admin.inc-be bekerült hogy 10 percenként is futhasson az időzitő.
Inkább sűrűbben, de kevesebb adatok kelljen legyűrnie.

Ha online frissítettem a nyelvi fájlt, azt ugye nem darabolhatom, kiakadt ott is, l10n_update.locale.inc: drupal_set_time_limit(240); kevés volt. Itt valószinű nem a méret volt a gond, hanem hirtelen sokmodult akart feldolgozni.

(Szerk.: És lehet, hogy itt épp a 16k-ra korlátozott mobilnettel csinálta a frissítést, és nem volt elég ideje, de basszus akkor is. Ne én legyek már a rendszerért, fusson amíg muszáj.)

Amit Te is írsz ott a locale.inc-ben van drupal_set_time_limit(240);
Ezen nem tom mit kell megoldaniuk a fejlesztőknek, nincs semmi baj vele, szerintem éles tárhelyen nem akad ki, localhoston igen, néhány embernek, de érthető, ahogy írtad is, nagy adatoknál nincs elég idő hagyva. Bár ahogy elnéztem telepítés közben az sql folyamatokat, nem csak ezt csinálja közben, sőt... Jó hogy nem bírja gyengébb gépeken.

A common.inc most meg nem mondom, miért akadt ki, de ott is a 240 volt a baj.
Azt hiszem a database.inc hivatkozott rá mikor elhalt... Sőt szinte biztos... Aztán lehet az indexelésen keresztül... Mindegy.

Szóval azért annyira nem egyszerű ez hogy daraboljak szöveget... Ha csak ott lenne gond, simán inkább angolul használnám. Így viszont...

Aztán persze gondolom, nem mindenki indexelget ekkora adathalmazt, ott nyilván lekorlátozódik a nyelvi fájlra... Ott jó lehet a darabolás, bár telepítéskor nem tudom...

Mindegy, én nem merek vitázni, én csak egyszerűen nem látok ebben a módosításban semmi kivetnivalót, bár tudom, ezzel most egyedül fogok maradni.

Szerintem zárjuk, nekem így ez jó, élesben én sem tenném. :)

Ui.: A fejlesztőknek meg elég lenne annyit tenni, hogy a drupal_set_time_limit egyszerűbben módosítható legyen. Miért ne? Nem rosszabb ez, mint a php.ini-ben túrkálni...
Minden problémát megoldana. Vagy ha nem, localhostos telepítéskor nagyobb értéket kapjon... Akár kiválaszthatóan... Tudom, nem az Ő hibájuk, hogy nincs mindenkinek sokmagos szörnye az asztalon =)

A lényeg, nálam azóta stabilabb mindentől, remek rendszer. Szeretem. Béke. :)

0
0
Sk8erPeter képe

Beküldte Sk8erPeter - 2012. március 30. 10.38

Arról nem is beszélve, hogy a target="_blank" nem is XHTML Strict-valid már ([link], "The target attribute is deleted from HTML 4.01 Strict and XHTML 1.0 Strict.").
Lehetséges opcióként - ha mindenképp ezt szeretné valaki alkalmazni - érdemes lehet jQuery-vel megcsinálni ugyanezt, és így a validitás is megmarad (a base href-es kerülő megoldást én NEM igazán erőltetném, sőt):

$("a.external").attr("target", "_blank");

Természetesen ez csak az external class-szal ellátott linkekre működik jól. Pl.: <a href="http://google.hu" class="external">Google</a>

Viszont annyit még hozzátennék, hogy az új fülön/ablakban megjelenő linkek elé esetleg érdemes lehet betenni egy erre utaló kis ikont, lásd pl. ingyenesen elérhető ikonok: [link], [link].
Ezzel legalább jelezhetjük a felhasználó felé (első klikknél mondjuk még nem biztos, hogy egyértelmű, aztán rájön az ikon jelentésére), hogy milyen viselkedést várhat el ezektől a linkektől. Pl. az external (vagy hasonló) class-hoz hozzáadnám a megfelelő tulajdonságokat, amik az ikon megjelenítésére szolgálnak.

Szerk.: elnézést, most látom, amit Petik linkelt, az External Links modul épp a fentebb leírt megoldásokat hivatott alkalmazni jQuery-vel, azzal kiegészítve, hogy ez "automatikusan elvégzi" (nem kell explicite hozzáadni plusz osztályt) annak felderítését, hogy az oldal belső vagy külső tartalomra mutat-e.

0
0
Sk8erPeter képe

Beküldte Sk8erPeter - 2013. augusztus 26. 15.39

A fújt arra írtam, hogy először összepakoltatod egy tömb tartalmát (még ha abban kevés tartalom is van, vagy konkrétan nincs), aztán egyszerűen kiszeded a kiíratását - ugyanúgy dolgozik vele a Drupal, csak tök feleslegesen (jó, igen, a Panels még sokkal jobban megdolgoztatja, úgyhogy erre a témára pont nem jó alternatíva, spórolásra a saját modulos útvonal-definiálás hook_menu-ben jó, amit csakiistvan ki is fejtett, annak beállítása az új frontpage-ként, majd egy kis CSS), ráadásul amikor később meggondolja magát, mégis akarja a szokásos frontpage-et, és elfelejti, hogy hoppá, itt mit is csinált, és mégis akar tartalmat belerakni, akkor majd szívhat vele, hogy ja basszus, de a render($content) sort kiszedte, így aztán várhatja a végtelenségig, hogy ott össze legyen állítva a tartalom... szóval sztem az ilyen hibalehetőségek elkerülhetők egy másik útvonal definiálásával (főleg, ha mondjuk a $contentben lenne érdemi tartalom is, csak ide nem kéne neki, akkor gány kitörölni a kiíratós sort sztem). Na de amúgy sem kell magadra venni, ha valaki vitatkozik az általad javasolt módszerrel, nem bántásként írtam, hanem csak szakmai vita kibontakoztatására. :) Nyilván nincs egyetlen igaz út, többféle megoldás is van, csak van, ami ésszerűbb lehet, mert mondjuk hosszú távon nem kínál akkora tévedési lehetőséget.
Mindenesetre bocs, ha sértőn vagy fölényesen hangzott, tényleg nem az volt a szándékom.

ha már így belemászunk, a drupal_is_front_page() hívásnak pedig semmi overheadje nem lesz a template_preprocess_page -ben, mert mire ideértünk, már többször is meghívtuk. igazából azt is mondhatjuk sosincs overheadje, mert például a system modul hook_initje is hív egyet :)

Igen, magának a függvénytörzsnek nyilvánvalóan nem lesz overheadje, mivel eddigre már "ötezerszer" meghívódott (mondjuk azt hittem, egyértelmű abból, amit írtam, hogy eddigre már nem lesz "költséges" a meghívása), de létezik olyan, hogy függvényhívás-overhead... ha találkoztál kismértékben is spórolós környezettel, akkor vágod... (amúgy assembly-kódolásnál sokszor előjöhet olyan feladat, hogy kerüljük el az ide-oda ugrálást, stack-mentéseket, felesleges plusz időket, beágyazott rendszernél pl. nem mindegy)
Nyilván itt nem beágyazott rendszerről beszélünk, de sokszor látom Drupal-modulok kódjában, hogy a fejlesztőjük szeret nagyon pazarolni, ezt már többször említettem - tipikus hiba például, hogy azonos függvényen belül többször meghívják ugyanazt a függvényt, ahelyett, hogy letárolnák az értékét egy változóba. És akkor ez csak egy a sok közül. Overhead jelentkezhet függvényhíváskor, és költségesebb lehet, mint egy változó értékének felhasználása. De igazából itt az overheadet inkább mellékes infóként jegyeztem meg.

1
0
ggondos képe

Beküldte ggondos - 2013. október 22. 10.29

Köszi a tippet, kipróbáltam, sajnos a Bartik alatt is fennáll a hiba.
Explorer, Firefox, Chrome alatt ugyanúgy.

Bemásolok ide adatokat, hátha:

Drupal 7.23
Adatbázis frissítések Aktuális
Adatbázisrendszer MySQL, MariaDB, or equivalent
Adatbázisrendszer verziója 5.5.19-1~dotdeb.1
CKEditor 4.1
CTools CSS Cache Exists
Colorbox plugin 1.4.14

Drupal alaprendszer frissítési állapota Aktuális

Feltöltés folyamata Nincs engedélyezve

A kiszolgáló alkalmas a fájlfeltöltési folyamat megjelenítésére APC-n keresztül, de ez a lehetőség tiltva van. Hozzá kell adni a apc.rfc1867 = 1 sort a PHP működését szabályzó php.ini fájlhoz. Javasolt a PECL uploadprogress használata, ami támogatja a több fájl párhuzamos feltöltését.

Frissítési értesítők Engedélyezett

Fájlrendszer Írható (nyilvános letöltési mód)

GD függvénytár PNG támogatással bundled (2.0.34 compatible)

GD képkezelő könyvtár használata a forgatás és a színtelítettség-csökkentés hatásokhoz bundled (2.0.34 compatible)

Időzített feladatok Legutóbbi futás ideje: 28 másodperc
Az időzítő böngészőből is futtatható.

Konfigurációs fájl Védett

Metatag Drupal core is compatible

Older versions of Drupal core were missing functionality necessary for taxonomy term pages to work correctly, but this version will work correctly.

Modul és smink frissítési állapot Aktuális

PHP 5.3.10-1~dotdeb.1 (további információk)

PHP memória korlátozás 512M

PHP register globals Tiltott

PHP-kiterjesztések Engedélyezett

Tartalom hozzáférési jogosultságok Tiltott

Ha a webhelyen teljesítményproblémák lépnek fel a tartalomak jogosultságai miatt, szükséges lehet a jogosultsági gyorsítótár újraépítése. Az újraépítés el fog távolítani minden jogot a tartalomról és az engedélyezett modulokon és beállításokon alapuló jogosultságokkal fogja kicserélni azokat. Az újraépítés sok időt vehet igénybe, ha sok a tartalom vagy bonyolultak a jogosultsági beállítások. Az újraépítés befejezése után a tartalom automatikusan az új jogosultságokat fogja használni. Jogosultságok újraépítése

Unicode könyvtár PHP mbstring kiterjesztés Webkiszolgáló Apache/2.2.16 (Debian)

jQuery Update jQuery 1.5.2 and jQuery UI 1.8.11

update.php elérése Védett

Engedélyezett modulok - mindent mindig frissítek egyből, amikor jön az értesítés, hogy elérhető:

Block, Color, comment, contact, content translation, contextual links, dashboard, database logging, field, field sql storage, field ui, file, filter, help, Image, List, Locale, Menu, Node, Number, OpenID, Options, Overlay, Path, PHP filter, Poll, RDF, Search, Shortcut, Statistic, Syslog, System, Taxonomy, Text, Toolbar, Trigger, Update manager, USer

Chaos tools,

CKEditor, Jquery Update, Wysiwyg

Block languages, Internationalization, Language icons, Menu translation, Multilangual content, Multilingual select, Path translation, String translation, Translation sets,

Colorbox, Easy social, Edit section, Facebook comment box, Insert, Libraries, Token

Metatag, Metatag: Open graph,

Custom sitemap

Variable

Views, Views UI

kösz
GG

0
0
Sweetchuck képe

Beküldte Sweetchuck - 2005. augusztus 11. 09.20

Sziasztok

Nekem tesztelés céljából volt/van arra szükségem, hogy több settings.php-t is használjak.
Ugyanazt az adatbázis struktúrát létrehoztam MySQL_4, MySQL_5 és PsotgreSQL_8-ban is.
Az Apache-nak a beállításain semmit nem változtattam,

Nálam Drupal nem a document_root-ban van, hanem egy ?drupal? nevű alkönyvtárban,
(c:\?.\.public_html\drupal).

Nem szükséges, de kényelmes dolog ha van egy regisztráció a no-ip.com -on és ott egy host kiválasztva, illetve a kliens progi futtatva.
Ha a regisztrált host így néz ki sajatgep.servehttp.com akkor a beállítások a következőek:
Csak Windows esetén tudom

Ezt a fájlt módosítani kell (nincs kiterjesztése)
c:\WINDOWS\system32\drivers\etc\hosts
Úgy emlékszem hogy alapesetben üres (a kommentezett leírás).

127.0.0.1	localhost
127.0.0.1	pg8.localhost
127.0.0.1	my5.localhost
127.0.0.1	my4.localhost
127.0.0.1	pg8.sajatgep.servehttp.com
127.0.0.1	my5.sajatgep.servehttp.com
127.0.0.1	my4.sajatgep.servehttp.com

Létre kell hozni az alábbi könyvtárakat, és bemásolni a setting.php-t
c:\?.\.public_html\drupal\sites\default\
c:\?.\.public_html\drupal\sites\my4.sajatgep.servehttp.com\
c:\?.\.public_html\drupal\sites\my5.sajatgep.servehttp.com\
c:\?.\.public_html\drupal\sites\pg8.sajatgep.servehttp.com\
és a megfelelő konfigurációs beállításokat elvégezni a fájlokban, mint a serverurl vagy az adatbázis kapcsolat, table_prefix stb....

A PostgerSQL-es drupal pedig ezen az URL-en található:
http://pg8.sajatgep.servehttp.com/drupal
vagy
http://pg8.localhost/drupal

Meglehet csinálni az Apache beállításaival is, de nekem nem sikerült, pedig nagyon sok manuált olvastam, fórumokon is nagyon gyakori kérdés, az ott elhangzott válaszok alapaján sem sikerült, az 1.3 és a 2.x verzióval sem.

0
0
ha5abe képe

Beküldte ha5abe - 2013. február 11. 08.42

Valóban jogosultsági gond.
Minden lépésnél, pl. modulok telepítésénél is az alábbi parancsokat kell lefuttatnom:

  1. find . -type d -print0 | xargs -0 chmod 755
  2. find . -type f -print0 | xargs -0 chmod 644
  3. chmod 757 sites/default/files

(Az első sor az összes könyvtárat, a második az összes filet, a harmadik pedig csak azt az egy könyvtárat állítja be. Gondolom, hogy nem teljes a lista.)

Utána megjelenik a kép, de a következő készítésénél megint nem, mert könyvtárat 700-al, filet 600-al hoz létre. Pl. cikkeknél file vagy kép feltöltésnél. Ha valamelyik file elérési útjához xxx/yyyy-t írok, akkor az első, tehát az xxx-nek 700-as jogot ad, úgy meg nem lát már bele. (Egyszeres mélységnél OK.)

Ha egy felhasználónak a saját dolgait saját könyvtárába szeretném pakoltatni, pl. egy tartalom típusnál, a mezőnél ez van beállítva:

  1. Fájl könyvtár: cikk-xxx/[current-user:name]

(A current-user:name lehet, hogy nem lesz jó, mert ha adminként belenyúlok, lehet, hogy átpakolja.)

Ez után ismét a fenti parancs sor kell, hogy következzen, mert, az első alkalommal 700-as joggal jön létre a könyvtára, a file belekerül, de nem látszik. Így aztán ismét a fenti parancsok. Utána, már megy, de csak annak a felhasználónak.

1
0
Illyés Edit képe

Beküldte Illyés Edit (nem ellenőrzött) - 2008. február 27. 00.43

Van a Drupal.hu-n egy belső feljegyzés erről, akkor most feloldom a titkosítását:

Nehézségek(pp)

Bármilyen rendszeren készítünk is videót tudnunk kell, hogy a legtöbb videó formátum filmek tömörítésére lett kitalálva. Egy képernyő videó tömörítésnél azonban teljesen más szempontok vannak mint egy sima filmnél. Ezért van az, hogy a legtöbb videó vagy nagy méretű lesz, vagy olyan ótvar a minősége, hogy használhatatlan. A megoldás az, hogy másodpercenként 1 képet készítünk csak. Ekkor a méret kicsi lesz a minősége pedig elfogadható.

Egy programot ismerek, ami a képernyő videóhoz optimalizált tömörítést használ ez a Camstasia nevű program. Ez ugyanis minden egyes kattintásnál készít egy képernyő képet és ezeket egy Flash animációba fűzi össze. Ezzel a program tökéletesen működik asztali alkalmazásoknál, de webes alkalmazásoknál nem, mivel a kattintás után olyan késleltetéssel jelenik meg az eredmény-kép, hogy mindig a kattintás előtti képet menti el a program.

Windows (Edit)

Szoftver: CamStudio. Az alapbeállítások nem megfelelőek (rossz képminőség, elcsúszó hang) – a helyes beállításokat lásd ezen az oldalon. A legjobb minőség a CamStudio saját codec-jével érhető el (Useful Links résznél, letöltés és kicsomagolás után telepítés a camcodec.inf fájlra kattintva.)

A pásztázás (nálam) csak függőlegesen működik, le kell venni a böngészőablak szélességét 800 pixelre.

SWF-be konvertáláskor (Tools -> SWF producer) kis fájlméret-csökkenést lehet elérni a színmélység és a Playback rate alacsony értékre állításával:

  • Color Mode: 16 bit
  • Sample/Playback Rate: 15 Frames/sec
  • Keyframe Rate: 15 Frames/sec

Linux(pp)

Linuxon az XVidCap nevű programot használom. Ez képes egyből flv-be kódolni, amit azután könnyedén lehet publikálni. Az általam használt beállítások:

  • General fül
    • Default Capture Mode: Multi-Frame
    • Capture Mouse Pointer: Yes, white
  • Multi-Frame fül
    • File Format: Macromedia Flash Video Stream(flv)
    • Frame per Second: 7,5 (ez a minimum)
    • Quality: 100 %

A Firefox-ot 800x600 felbontásra szoktam állítani, hisz így a "leggyakrabban használt" felbontásban 1024x768 még pont elfér az egész kép.

Ubuntu Gutsy Gibbon (Edit)
Azt írja a Gutsy dokumentációs oldala, hogy...

Desktop session recording

It is possible to record the whole desktop session along with mouse pointer and sound system. It is a very useful tool for video screenshot as ordinary still picture screenshots generated by pressing Print Screen cannot demonstrate everything. Two applications that can do this for you are Istanbul and Wink.

Istanbul

sudo apt-get install istanbul

Wink

sudo apt-get install wink

Egyéb tanácsok(pp)

A tanarurkerem.hu videóiban hallani egy brummogást. Ezt meg lehet szüntetni, ha a laptopból kihúzzuk a tápot és elemről működtetjük a felvételnél. (erre tök véletlenül jöttünk rá amikor egy ismerősömnél régi magyar rock lemezeket digitalizáltunk )