Hirdetés
-
Spyra: nagynyomású, akkus, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
-
Perelnek a vallásos kripto-piramisjáték miatt
it Két kriptocéget perel New York államügyésze, mert több mint 1 milliárd dollárral károsították meg az áldozatokat.
-
Ingyen osztogatja a Samsung a Galaxy Watch FE-t
ma Pedig még nem is létezik. Közben befutott a szuperfényes Watch Ultra specifikációja.
-
PROHARDVER!
Új hozzászólás Aktív témák
-
Penge_4
veterán
válasz
grabber
#13424
üzenetére
Kiegészítők/userJS-ek?
ps: Amúgy ha másodpercenként (/s) nőne annyival az tényleg durva lenne.
(#13423) sekli: Ha már be van konfigurálva (Adblock.exe, CSS, mime type, saját menü, stb.) akkor hagyhatod, gyorsabb, mint a NoAds.
A NoAds annyiból jobb, hogy ahhoz nem kell exe és egyéb trükközés, csak egy kattintásos kiegészítő, de technikailag ez sok esetben erősebb és mivel fájlban tárolja a szabályokat, nem adatbázisban, ezért kevésbé sérülékeny.
A blokkolható tartalmakat, mint banner viszont ajánlott a beépített tartalomblokkolóval blokkolni, mert az tényleg blokkol, nem csak elrejt (mivel 11.10 óta az Opera is rálépett a többi böngésző által kitaposott útra és a display:none szabállyal elrejtett elemek tényleg is betöltődnek a háttérben. Kompatibilitás szempontjából jó, "nem hivatalos" reklámblokkolás szempontjából viszont kevésbé.
[ Szerkesztve ]
-
Penge_4
veterán
válasz
grabber
#13427
üzenetére
Ezt olvasd át és járj el eszerint.
Ha nincs rá időd/nem érdekel, akkor a legegyszerűbb első lépésben az operaprefs.ini törlés, második lépésben a teljes uninstall (profiltörléssel), majd friss install.
A Gmail-en ilyennek normál esetben sem a végleges 11.10-ben, sem a 11.50 alfában nem lenne szabad jelen lennie.
-
Penge_4
veterán
válasz
scorpy02
#13441
üzenetére
Gatter van neki, felnyomták a szerverüket, mint a Sony-t, semmi köze az Operához.
(#13440) grabber: Akkor nem tudom. Telepítsd újra a Windowst.
(#13439) arnyekxxx: Csak ha a Flash nincs letiltva. Akkor is teljesen random. Van, mikor 3 napig megmarad olyan 2-300-as átlagon, van, mikor azt veszem észre, de többnyire előbb lesz random crash áldozata, minthogy elérjen magasabb memóriahasználatot.
De mióta le van tiltva a Flash, illetve Flashblockkal böngészek, azóta nincs ilyen jellegű problémám. De ez csak nálam van így, valamiért a gépen (soha semelyik) nincs jóban a Flashssel, böngészőfüggetlenül produkál érdekes dolgokat. Teljesen friss Windows esetén is (tehát nem barmolom szét).
-
Penge_4
veterán
válasz
scorpy02
#13443
üzenetére
Legalábbis a fontosabbakat, mint például banki jelszavak, ha tároltál benne olyat, vagy olyan torrent oldalak, ahova "szinte lehetetlen" bejutni és ilyesmi.
Egy PH account kétlem, hogy érdekelné őket, bár sose lehet tudni. Gmail, Hotmail, Yahoo, stb. már jobban, elvégre több ezer fiókból egész jó kis spamhálózatot lehet csinálni.
És tanulni az esetből, hogy online soha semmilyen értékes dolgot nem tárolunk, mert feltörhetetlen rendszer nincs és egy jelszavakra szakosodott cég fokozottan kiemelt célpont. Vagyis előbb-utóbb mindet fel fogják törni.
(#13444) kovaax: A saját géped azért ennél ezerszer biztonságosabb. Ha leszámítjuk az utolsó bekezdésemet (avagy a 7 milliárd emberből egy nem célpont), akkor is, többnyire van tűzfal, víruskereső, bekapcsolt UAC és frissen van tartva az OS. Ha pedig ezek megvannak, akkor már eleve kevesebb az esélye, hogy bárki megtámad.
Ha emellé még a user sem hülye (tehát nem kattint mindenféle baromságra), az tovább növeli a biztonságot.
[ Szerkesztve ]
-
#13482
Penge_4
veterán
Sk8erPeter
#13481
Penge_4
veterán
válasz
Sk8erPeter
#13481
üzenetére
"Erre mutass már példát légyszi, mert már tényleg érdekel."
Először szedd le ezt (végleges 11.01) és csinálj belőle egy tiszta USB-s telepítést.
Hirtelen most ezen kívül nem ugrik be más oldal. Nézd meg. 11.01-ben a képek először lerenderelődnek, amíg végig nem érnek, majd utána jelennek csak meg áttűnéssel, 11.10-ben pedig már az elején letöltődik az összes és az első alkalommal is áttűnéssel jelennek meg.
"Most ennek mi köze a display:none-hoz?"
Az, hogy sokan ezzel oldották meg még a hover menüt is.
Egyébként itt van két ellenpélda: LastPass oldala (itt vidd rá az egeret a view more gombra) Jobb, ha privát módban nyitod meg az oldalt, mert akkor bezárás után újra kipróbálhatod és nem kell törölni a cache-t, ha elsőre nem lenne egyértelmű), a másik pedig a hotfile.com-on a nyelvválasztó legördülő.
"Te ezt figyelgetted, onnan tudod, vagy mi?"
Először csak tapasztaltam, hogy ha kicsapom a banner DIV-jét, akkor nem villan fel oldalbetöltéskor a progess bar (nálam ez alul van, részletes), aztán egy Baldric (aki akkor éppen userJS-t fejlesztett Operához) megerősített benne, hogy az Opera ezt egyedi módon dolgozza fel. De igen, konkrétan ezt nem figyeltem, de mintha úgy emlékeznék, hogy a hálózat fülön új kérés történt, mikor egy display:none mögött lévő kép láthatóvá vált.
"De ezt már csak azért is nehéz elképzelni, mert akkor ezek szerint a forráskódban sem kellene, hogy látsszon a display:none tulajdonsággal ellátott elemek belső tartalma, ami elég nagy f@szság lenne - márpedig csak így elképzelhető az, amit mondtál."
Miért is? A DOM fát betölti, majd mindent letölt, kivéve azokat a képeket, amik display:none szabállyal vannak megjelölve. A scriptek ugyanúgy lefutnak, sőt még az iframekben lévő dokumentumok is betöltődtek, egyedül a képek nem. Tehát nem volt 100%-os megoldás, de rengeteget segített, mert sok ilyen rohadt GIF, PNG és JPG banner van, amiben a fájlkiterjesztésen túl nincs egyetlen állandó sem, mert például egy adbox nevű dobozban generálódik le és a src minden újratöltésnél cserélődik az imageshack-től a tinypic-ig mindenféle képmegosztóra feltöltött klfjsiuiojfklsd.jpg és kldjfsdlfjsd.gif nevű fájlokig.
Na ezeket blokkold.
"Mégis mi a büdös francnak kéne még máshogy jelezni az id-n/class-on kívül, hogy az micsoda?"
Éppen erről van szó. Az URL Filterrel csak azokat lehet blokkolni, aminek fix elérési útvonala van, mint adverticum és társai. Vagy example.com/banners/
De ez a módszer már az example.com/kepek/ esetén is csődöt mond.
Ergo: Ilyenkor jött a végső mentsvár a CSS alapú blokkolás, amivel a szabvány banner méreteket is blokkolhattad és ID/Class alapján is.Sokszor még ID/Class sem volt, de köszönhetően a selectoroknak az is megoldható volt.
Sokszor JavaScript cserélte össze-vissza a DIV-eket, hogy a selector alapú blokkolást is kijátszák, ilyenkor a domain alapú IMG[src*=".gif"] működött és JPG-vel is néha, mivel többnyire PNG-ket használnak az oldalak elemeinek. De ez olyan agresszív, hogy csak domainspecifikusan működött. Az meg szintén csak a selector alapú cuccal volt megoldható. Meg URL Filterrel, de ahhoz még nincs kiforrott kiegészítő, az meg, annyira meg nem vágom a JS-t, hogy a location.href alapján URL Filter API-val manuálisan blokkoljam a reklámokat.Azon kívül: Ha a Firefox-féle Adblock Plus + Element Hiding Helper teljes funkciókészletét implementálnák, akkor ugyan pozitívum, hogy lenne fehérlista, viszont negatívum, hogy a 90%-ban teljesen felesleges RegExp miatt rengeteget lassítana.
A jelenlegi wildcard megoldást elég lenne kibővíteni egyetlen karakterrel, ami a magasabb prioritást élvező fehérlistás URL-t szimbolizálná.
"mondjuk legtöbbször a sima prohardver.hu-t használom, de majd figyelgetem."
Akkor válts portált. Egy héten belül (ha napi szinten látogatod) biztos találkozni fogsz vele. Persze RSS-ből ugorva (vagy bárhonnan közvetlenül a topic linkjére) gyakoribb. És többnyire mikor már régóta nem látogattam az oldalt, vagy újraindítás után (tehát cache-sel kapcsolatos lehet).
[ Szerkesztve ]
-
#13490
Penge_4
veterán
Sk8erPeter
#13488
Penge_4
veterán
válasz
Sk8erPeter
#13488
üzenetére
"De én úgy emlékszem, ez IE-nél is így van/volt, nem?"
A kettő nem ugyanaz. Az általam linkelt JavaScriptes hover menük minden böngészőnél villognak és Opera 11.01-ben és 11.10-ben is villognak.
A display:none-t, pedig csak az Opera kezelte máshogy, az IE nem és semmilyen másik böngésző sem. Emiatt is vált szükségessé ennek a de facto szabványnak a támogatása, mert sokan ezzel oldották meg.
"Ha első betöltést követően villódzás tapasztalhatő, és ezt az adott honlapnál nem oldják meg, akkor az annak a site-nak az igénytelenségét minősíti."
Jó, hogy egyetértünk. Éppen erről van szó. Főleg 2011-ben. Mert a fejlesztő is csak régi cikkeket linkelt 2005-ig bezárólag, amiben azt taglalják, hogy mennyivel jobb a CSS, mert mi van, ha a user letiltja a JavaScriptet. 2011-ben már nem tiltja le, illetve ha igen, akkor nem az lesz a legnagyobb problémája, hogy nem lesz hover a kép/menü fölött.
Tehát a régi display:none esetében semmilyen hátrányunk nem származott belőle, hogy nem töltötte be a képeket a villódzáson kívül. Ha scriptekkel töltötték elő akkor a scriptet lehetett tiltani és meg volt oldva, de reklámbannereket különben sem töltögettek elő.
"de azért az sem elvárható a webfejlesztőktől, hogy az oldal megírásakor legalább annyira legyenek tekintettel a reklámblokkolókra, mint az oldal általános megjelenésére, működésére, az elsősorban célzott közönségre..."
De nyilván nem reklámblokkolási céllal hozták létre a régi működést, hanem elsősorban adatforgalom szempontjából, ami most ismét aktuális a mobilnet terjedésével.
Erre viszont lehetnek tekintettel.
Meg amúgy másra is. Például az önkritika gyakorlására. Egy PH sebességű (már mikor nem lassú) szerveren nem zavar, hogy a PH oldala mennyivel nagyobb, mint mondjuk az ITCafé, de ahol a 20-30kB/s sebességet is kínszenvedés elérni (lásd: blog.hu) ott igazán bekaphatnák, amikor több, mint 1 megás oldalt kell betölteni, gondolok itt az admin felületre.
Meg jó dolog az AJAX, pláne ha ért is hozzá az, aki írja. Ott sajnos ezzel sem ez a helyzet. 10-ből 5 alkalommal "Sikertelen mentés" után nem javul meg. Ki kell másolni az egész postot, majd újratölteni (mivel ilyenkor az URL hasztalan, visszanavigálni az eredeti helyre, bemásolni, majd reménykedni.
"Nem attól lesz szar egy honlap, hogy nem felel meg a reklámblokkolási elvárásaidnak."
Akkor még egyszer: Ha elő lenne töltve JS-sel (értsd: minden másik böngésző is ugyanúgy kezelné a display:none-t, vagy a szabványban deklarálva lenne), akkor nem lett volna rá szükség.
Nem attól lesz szar, hogy nem felel meg a reklámblokkolási szokásaimnak, hanem attól lesz szar, hogy még egy menüt/slideshow-t sem tudnak normálisan megírni.
"Amúgy lehet tiltani meghatározott domainekről betöltendő tartalmat akár a hosts fájlon keresztül is"
Igen, itt a meghatározott domainekkel van a baj. Ugyanis ha elolvastad volna amit írtam: Itt nincs meghatározott domain. Itt van 8 imageshack, 4 képfeltöltés, 7 tinypic és 12 kephost-os cím, amiről jön a banner. Az egyetlen állandó a kép mérete: 468x60
Itt vagyok meglőve...
-
Penge_4
veterán
-
Penge_4
veterán
Aki érdekelt a következők valamelyikében:
- UserJS működés HTTPS kapcsolatokon anélkül, hogy minden alkalommal jóvá kéne hagyni egy megerősítő dialógust újraindítás után.
- URL "nem fontos" részének kiszürkítése.
és ezek valamelyikét (esetleg mindegyikét) ki szeretné iktatni, van számára egy jó hírem.
Hamarosan lesz rá megoldás. Illetve már van is perl script formájában, de még nagyon alfa és teszteletlen, tehát a készítő nem szeretné még publikálni, ezért nem is írok róla külön postot egyelőre.
De aki mindenféle instrukció nélkül képes lecserélni a XaNoCTA patchben lévő .pl kiterjesztésű fájlt erre, majd végrehajtani a batch fájllal, annak itt van: http://pastebin.com/LkV60SMK
Ismert bug: A UserJS-t HTTPS-en nem lehet külön kikapcsolni a hozzá tartozó opera:config beállítással, tehát magát a működést patcheli meg, nem csak a confirm dialógust.
-
Penge_4
veterán
válasz
erdoke
#13504
üzenetére
Ezt a kérdést most jól feltetted. Gondolom kiegészítőre gondolsz, mivel a widgetek saját processzben futnak, de nem tudom. Talán ha felsorolnád őket (legalább azokat, amik hozzáférnek a hálózathoz (tehát a Privacy beállításoknál van pipa-lehetőség a Private Tabs és a HTTPS mellett is).
-
#13565
Penge_4
veterán
Sk8erPeter
#13511
Penge_4
veterán
válasz
Sk8erPeter
#13511
üzenetére
"Tehát amiről beszéltünk, hogy nem oldották meg a JavaScriptes előtöltést. Pedig rohadt nehéz ám, akár egy sorban is meg lehet oldani."
Azt kéne még. Így legalább JavaScriptes trükközéssel pótolható a display:none, de ha azt is "megjavítják", az már nálam válóok.
"mintha egy sima mezei felhasználó lenne, aki minden lószar zavaró dolgot észrevesz"
Nem tudom, én minden átlagembert (nem, nem átlagusert, ez sajnos az élet minden területén így van) kiakasztok, azt mondják túl kritikusan szemlélem a dolgokat (és ez még a legszebb megfogalmazás).
"Aszinkron módon nagyjából mindent, aminek a betöltésére a felhasználónak előbb-utóbb úgyis várnia kellene"
Attól függ. Egy tabos felületen minek töltsön előre 5 oldalt képekkel, mindennel együtt, amikor lehet, hogy az első látogató végigböngészi a felületet, de egy régóta regisztrált felhasználó már csak az első oldalra kíváncsi az esetek 90%-ában. Amíg szélessávon küldi, addig nem téma, de mobilnettel már eléggé.
Ezt (ha már az Opera ennyire advanced böngésző) böngészőből kéne kontrollálni, vagy minimum kiegészítővel a butább böngészőkben. Nem?
"Hát akkor Operában ezek szerint ez nem igazán volt működőképes."
A "nem működőképes" az én szótáramban kicsit erősebb mint egy esztétikai villódzás, az is az első alkalommal csak.
Mutass egy olyan oldalt, ahol konkrétan rontotta az élményt. Még a Wikipédiás Multi Column Layout bug (amikor megjelenik a vízszintes görgetősáv túl sok forrásnál) is zavaróbb ennél, mert autoscrollnál gyakran félremegy és az a 20 pixel vertikálisan is zavaró tud lenni.
"Nem olyan nagy dolog azt sem megoldani, hogy mindkét módszerrel működjön a küldés."
A PH-n éppen működik, csak az átlagusernek nem biztos, hogy leesik, hogy miért marad ott "örökre" a "Hozzászólás elküldése sikeres". Főleg úgy, hogy átirányítás már HTML alapon is létezik JS nélkül.
"Gratula amúgy a képfeltöltés.hu üzemeltetőinek ezért... Érdekes, imageshack.us-re ezelőtt 3 évvel felrakott képeim továbbra is megvannak..."
Az a baj, hogy az összes szar. Régen volt a media.proxnet.hu aztán megdöglött és elveszett egy rakás kép, pedig favorit volt torrentes körökben.
Az ImageShack nálam újabban "domain blocked" békás képre dob, csak ha közvetlenül másolom a címet a címsorba és entert nyomok tölti be.
Ez olyasmi, mint a fájlmegosztók, csak itt gyorsabb az elavulási idő. Jön egy új, az elején nagyon jó, aztán lassul, telerakják reklámmal, tovább lassul, aztán egyre több a downtime, aztán tovább lassul, aztán jön egy újabb és kezdődik az egész elölről.
A legjobb, ha a fontos képeidet saját tárhelyre töltöd fel, az egyszeri screenshotokat, amiknek meg x hónapon belül már úgysem lesz aktualitása pedig valami gyors, direktlinkelhető oldalra, mert én például azt is utálom, mikor megnyitok x oldalt, majd 1-1 avatar, vagy fórumba beszúrt kép miatt fogja 1 percig az oldalt.
Mondjuk ha az Opera teljes oldalbetöltés előtt az anchorra ugrana, akkor kevésbé lenne idegesítő.
"Mostanában mondjuk memóriaspórolás céljából használom a Tab Vault-ot, így onnan is megnyithatom később, de legalább nem zabál erőforrásokat."
Ott vannak helyette a könyvjelzők.
[ Szerkesztve ]
-
Penge_4
veterán
válasz
Dluinet
#13541
üzenetére
"A jelszavas probléma akkor csúcsosodik ki, ha például a pároddal együtt használjátok a gépet."
Külön felhasználói fiók mindennek a titka. Főleg ha a párod technikai analfabéta.
"Az Operáé egyszerűbbnek tűnik, pedig nem."
Nem egyszerűbb, komplexebb. Például a checkboxokat is megjegyzi.
-
#13571
Penge_4
veterán
Sk8erPeter
#13570
Penge_4
veterán
válasz
Sk8erPeter
#13570
üzenetére
"így legalább címsorba begépelve valamit egyből megkapom a címeket, de most átmenetileg megnézendő oldalakat nem fogok külön könyvjelzőkként elmenteni."
Hát mire való a Kuka?
-
#13591
Penge_4
veterán
Sk8erPeter
#13590
Penge_4
veterán
válasz
Sk8erPeter
#13590
üzenetére
-
Penge_4
veterán
"Nem hiszem hogy valaki fullhd-ban nem hasznalna zoomot."
Pedig sokan vannak. Például én (igaz, nem fullHD) is inkább bekapcsolom az oldalsávot állandóra a másik oldalra meg a fülsávot (ami azért is jó, mivel sok fület tartok nyitva egyszerre), minthogy zoomoljam az oldalt. Mivel SVG-t szinte sehol nem használnak, a zoomolásnál minden apró kép pixelesedik, ami ocsmány.
Amellett a scrollozással is néhány oldalon probléma van zoom mellett.
De ez inkább az inkompetens webfejlesztők sara, mint a böngészőfejlesztőké, mivel szabványok nélkül nem lehet globális, 100%-os megoldást találni arra, hogy sehol ne rontsa el az oldalt a zoom, semmilyen böngészőben. A leggyakrabban előforduló probléma a horizontális görgetősáv indokolatlan megjelenése.
Amúgy meg a nagy felbontás nem azért van, hogy ugyanazt nézd nagyobb méretben, hanem azért, hogy többet láss a képből és a gyakran használt elemeket is látható helyre pakold.
Ezt jelenleg egyedül az Opera nyújtja és a Firefox kiegészítőkkel. A többi böngésző tényleg csak zoomolással, vagy nem teljes méretű ablakkal alkalmas widescreen monitoron történő böngészésre. Ennek ellenére pedig ők büszkélkednek a legjobban a helyspórolással. Ja, megspórolnak defaultban 30-40 pixelt vertikálisan (ha valakinek annyira hiányzik, akkor ott a pivot mód), ami a többivel szintén elérhető volt már ezer éve, csak nem defaultban, a horizontális látóteret meg még lehetőséged sincs semmivel kitölteni.
A weboldalak pedig nem igazán a dinamikus elrendezés felé haladnak. Pedig most már lenne rá lehetőségük, ott van például a Multi Column Layout, amivel orvosolható a korábbi "akadály", avagy hogy a userek nem szeretnek széles szövegeket olvasni.
De például itt a PH!-n sem értem miből tartana JS-sel lekérdezni a felbontást és szükség esetén a "legfrissebb anyagok" doboz mellé pakolni még egy sávot (nem pedig alá), illetve a másik oldalon a "kedvenceim" mellett lenne az "itt szóltam hozzá", nem pedig alatta.
-
#13630
Penge_4
veterán
Sk8erPeter
#13626
Penge_4
veterán
válasz
Sk8erPeter
#13626
üzenetére
"Azért nem olyan nagyon egyszerű megoldani azt, hogy minden felbontáson, mindenféle zoomolási opció esetén jól mutasson az adott weboldal."
Azért remélem érzed a különbséget a "csak 1024-ben normális" és a "szabványos felbontásokon normális" között. Mert jelenleg csak az első teljesül. Én meg úgy gondoltam, hogy
1024 kap saját változatot.
1366-tól 1680-ig kap egy újabb változatot (hogy a dobozokban ne csússzon el semmi).
1680-tól felfelé pedig egy újabb skála.Nem, valóban nem tudom, éppen ezért magyarázd el, hogy mivel több, mint a következő:
1. Feature check (Multi Column megléte)
1/a Ha létezik, akkor JavaScript 1 lép működésbe.
1/b Ha nem létezik, akkor JavaScript 2 lép működésbe.2. Ha felbontás kisebb, mint 1024, akkor CSS 1.
- Ha felbontás nagyobb, mint 1366, de 1680-tól kisebb, akkor CSS 2.
- Ha felbontás nagyobb, mint 1680, akkor CSS 3.Ami meg nem támogatja a Multi Column Layout-ot az kapja a szabványos 1024-re optimalizált változatot (mint most kapja az összes).
Mi ebben a nehéz? Ezért van a HTML5 meg a CSS3, hogy használjuk, előbb-utóbb úgyis át kell majd állni.
"ha egy buzinagy TV-re kipakolod a képet, akkor ha egy fotelben ülsz, elfogadható távolságban a TV-től, hogy ne verje ki a szemedet közvetlen közelről"
Most akkor fullHD monitorról, vagy fullHD tévéről van szó? Mert a kettő nem ugyanaz. Egyébként meg épp az ilyesmire találták ki a Readablity-t és társait. Én erre személy szerint UserCSS-t használok, megadom, hogy
body {
background-color: #aaa;
}
p {
font-size: 28px;
font-family: "Helvetica World";
}
a {
font-size: 28px;
font-family: "Helvetica World";
}
h1 {
font-size: 36px;
font-family: "Helvetica World";
}Ez általában egységes, a többit meg oldalspecifikusan. Van egy IncludeCSS nevű kiegészítő is, ami Local Storage alapon működik. Ahhoz nem kell frissítgetni a stíluslapokat módosításonként.
"Legyenek nagyobbak az egyes dobozok, vagy rendezgethesd át tetszésed szerint, vagy mire gondolsz?"
Minden egyéni preferenciának megfelelni nem egyszerű. De egyébként erre találták ki (vagyis nem, de erre is jó) az "Akadálymentes változat" néven futó alternatívát, ami hatalmas betűket csinál és kontrasztos megjelenést. Erre volt userCSS próbálkozás is Operánál, de mint mondtam, a globális megoldások nem éppen a legjobb hatásfokkal működnek.
"Hát őszintén gratulálok, hogy rájöttek, hogy valami újulást a felhasználók meg a jó pénzeket fizető támogatók, hirdetők is szeretnének látni."
Mondjuk ha a konkurenciát nézzük a PH még mindig kiemelkedő. A HWSW nem rossz, de az alapja vBulletin fórum, a RIOS legalább saját fejlesztés. Ott van az SG, arról inkább ne is beszéljünk. A többi meg (techline, etc.) említésre sem méltó. A Geeks.hu is statikus, csak ott a cikkek kevésbé bulvárosak.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Szóval ez van, a példa azt mutatja, hogy az átlagolvasó rétegnek megfelel, pár törzsfórumozóért meg nem fognak ekkorákat fejleszteni, elvégre ők tudják megérné-e a plusz munka.
"A Facebookos AJAX-os hozzászólás-küldés megírása sem olyan nagy ördöngösség... ahogy a többi sem, csak ráfordított idő kérdése."
Azért Parcinak kevesebb nulla van a bankszámláján, mint a Zuckerberg gyereknek.
Gondolom a motiváció is kisebb."ezek közül néhányat ingyen is megcsinálnék, csak hogy haladjon már valamerre ez a nyomorult fórum."
Sokan vagyunk így, ez az egyetlen mozgatórugója (a céges támogatásokon túl) a nyílt forráskódú projekteknek is. De fizetést nem az egész világtól fogsz kapni "x összeg egy helyesírási hibáért", "y összeg egy fórumos fejlesztésért" és "z összeg egy AJAX implementációért" alapon, hanem egy adott cégtől, ahol az idő vasfoga megöli a kreativitást.
"Hát azért jobban afelé haladnak, mint pár évvel ezelőtt."
Legutóbb a PORT.hu-ból lett dinamikus helyett fix 1024-es változat. Meg volt még pár, aminél a designváltás dinamikusról fixre váltást is eredményezett. Ha jól tudom eredetileg az IWIW is dinamikusnak indult.
-
#13682
Penge_4
veterán
karldergroße
#13680
Penge_4
veterán
válasz
karldergroße
#13680
üzenetére
HyperTranslate összeakad a WYSIWYG szerkesztőkkel, mivel úgy működik, hogy minden meglátogatott oldalon legalul behívja a Google Translate fordítóját egy rejtett iframeben (Shift+G paranccsal meg is nézheted).
De már a beállításaiban megadhatsz kivételeket, szóval nem kell a content scriptet szerkeszteni manuálisan.
-
#13684
Penge_4
veterán
karldergroße
#13683
Penge_4
veterán
válasz
karldergroße
#13683
üzenetére
Csavarkulcs ikon a kiegészítők lapon (Ctrl+Shift+E) -> Preferences -> alul Blacklist mellé beszerkeszted az oldalt.
-
Penge_4
veterán
"Mondjuk nekem nem is a prgfiles könyvtárba van telepítve a böngésző, sőt még csak nem is az OS partíciójára, tehát OS újrarakása esetén még csak mentegetnem sem kell, csak egyszerűen ugyanide telepíteni"
Akkor meg már miért nem USB módban indítod a telepítőt, hogy a registrybe se írjon a szükségesen kívül (társítások) mást?
-
Penge_4
veterán
A speed dial clear csak a gyorshívót módosítja. Az Opera INI struktúrája pedig úgy van kialakítva, hogy elég csak a módosított szekciókat letárolni a profilodban lévő INI fájlokban, beleértve a skineket is, a többit ilyenkor a gyáriból veszi.
Tehát például egy Omelion-hoz hasonló skinnél értelemszerű, hogy az egész skin.ini módosítva lesz, mivel a színvilága és az ikonjai nem összeegyeztethetők a gyári skinnel, de ez nem mindegyiknél van így. Sőt, leginkább a többségnél csak megcsinálja a készítője úgy, hogy a saját eszköztár elrendezésénél jól mutasson a többi résszel pedig nem foglalkozik, vagy csak érintőlegesen.
A Program Files-ból emeld át a módosított szekciót a Speed Dial Clear skin.ini-jébe, mert a Program Files-ban lévő gyári skin minden frissítésnél felül fog íródni.
ps: Figyelj rá, hogy lehet, hogy kelleni fog a sima [Addressbar Skin] is, illetve ha vannak olyanok, mint [Addressbar Transparent Skin.bottom], akkor az fog vonatkozni arra, ha esetleg valamikor a jövőben alulra pozícionálod a címsávot. Ha ez nem fog megtörténni, akkor nem kell átemelned, csak tudj róla.
ps: Figyelj még oda a szekciók alatti "Clone =" kezdetű sorokra, ugyanis ha például a [Toolbar Transparent Skin]-t klónozza és az üres vagy más értékekkel rendelkezik abban a skinben, amelyik inijébe átemeled az adott szekciót, akkor csúnya lesz.
-
Penge_4
veterán
válasz
fatal`
#13770
üzenetére
"Tudtommal a Chrome sem fut sandboxban."
De állítólag igen, viszont itt az az alapvető tévedés áll fenn, hogy az emberek ezt úgy képzelik el, mint egyfajta atombunkert, pedig köze sincs hozzá.
Biztonsági szempontból nézve az Opera már a kezdetektől fogva rendelkezett azokkal a tulajdonságokkal, amiket a Chrome sandbox csak akkor nyújt, amikor éppen nem bugos, illetve nem törik fel.
Tehát például az Opera:
1. Az egyetlen olyan böngésző, ahol weboldal nem láthatja a vágólapod tartalmát.
2. A weboldal teljesen el van zárva a vinyód fájljaitól (ez a HTML5 Drag and Droppal majd megváltozik, de mivel ez egy konkrét W3C specifikáció lesz, feltehetőleg biztonságosabb)
3. A böngésző program része védett könyvtárban van (amennyiben például az UAC nincs kikapcsolva), tehát user módban futó folyamat nem képes manipulálni sem az opera.exe-t, sem az opera.dll-t.A beépített harmadik féltől származó futtathatók pedig mindig nagy biztonsági kockázatot jelentettek.
-
Penge_4
veterán
"külső addblock-on gondodolkozom még, csak nem tudom mennyivel gyorsabb és jobb a user.js javascriptes megoldás, mint a minialkalmazásként használatos Opera addblock."
Ezt nem tudom értelmezni. Minialkalmazás (widget) formában még nem találkoztam ilyesmivel.
A teljesen megbízható megoldás a beépített tartalomblokkoló, a hosts fájl, vagy bármilyen globális megoldás. Ez utóbbit neked kell eldöntened, hogy kell-e. Én nem szeretem több okból:
- Ilyen egyszerű feladatra ne kelljen már külön bináris.
- Nincs is normális. Az AdMuncher fizetős (és teleszemeteli az egész OS-t, meg egymagában 60 megát zabál). A Proxomitron fejlesztője meghalt 2004-ben azóta a program kicsit elavult.
- A külső megoldások soha nem integrálódnak annyira a böngészőbe, mint a belső megoldások, vagy a saját beépített megoldások (urlfilter).Végezetül: Ha egy OperaUSB-t indítok azt szeretném tiszta profillal tenni, ha pedig globálisan blokkolom a reklámokat, akkor azt is minden alkalommal tiltanom majd újra engedélyeznem kell ilyenkor.
Viszont ez az egy a pozitívuma is egyben, mármint ha valaki sok különböző böngészőt használ és nincs is nagy elvárása egyikkel szemben sem annak hasznos lehet, mert elég egy központi helyen blokkolni (főleg mivel böngészőn belül normálisan még mindig csak Operában és FF-ben lehet).
"Flashblock-ból szintén nem tudom mi lenne a legjobb."
11.50-től a beépített "On Demand Plugin" funkció, mivel oldalspecifikus lett. És biztonságosabb is, mint a UserJS változatok, mert nem lehet egy sima Shift+G-vel kiütni őket, nem kell patchelgetned a böngészőt vagy állandóan dialógusokat jóváhagynod, ha HTTPS-en is szeretnéd használni.
Ez utóbbi ellen a kiegészítő segítséget jelentene, de nem lenne értelme, mivel az On Demand még így is sokkal jobb, elég csak arra gondolni, hogy az RSS feedekben is működik, valamint együttműködik az urlfilterrel, ami abban nyilvánul meg, hogy egy blokkolt útvonalon lévő .swf kiterjesztésű banner fölött nem jelenik meg feleslegesen az esetenként sokszáz pixeles placeholder, a userJS/kiegészítő pedig ilyenkor csak a forrást/DOM fát tudja ellenőrizni és ha ott benne van (node-ot csak adott célra írt userJS-sel lehetne kiütni automatikusan), akkor kirakja a placeholdert.
Végezetül pedig ez az oldal bebizonyítja, hogy mennyire egyszerű módon működnek és, hogy mime type-ot nem ellenőriznek.
-
Penge_4
veterán
Az Opera Adblock csak előre elkészített listákat importál az URL Filter API-val a gyári urlfilter.ini-be.
Nem rég lett oldalspecifikus, 11.50-től (a funkció egyébként 10.50-től van benne), ami még nem is végleges, meg az ilyen általuk "peripherial"-nak tartott funkciókat sajnos nem szokták különösebben nagy dobra verni. Ez az oka többek között, hogy mikor a többi böngészőfejlesztő
lenyúljalemásolja az Operában már esetenként sok éve létező funkciót, akkor mindenki a másolat készítőjének tulajdonítja az innovációt.Egyébként jobbklikk->Webhely tulajdonságai->Tartalom fül.
Globálisan pedig a Ctrl+F12->Haladó->Tartalom-nál tudod engedélyezni/tiltani attól függően, hogy fehér vagy feketelista alapon akarod működtetni. -
Penge_4
veterán
válasz
grabber
#13893
üzenetére
"Egyes oldalak amiket látogaok,suli miatt,nem támogatja az operát és talán kicsit gány,de csak az opera alatt nem jelenik meg rendesen."
PH bug. Mióta kivették a kompatibilis belépés checkboxot, azóta van így és csak akkor, ha a cookie beállítások "Accept cookies only from the site I visit"
Régebben gondolom volt egy location.href cserélgetős script, amivel beléptetett gyorsan az összes portálra, legalábbis az állapotsávon mindenhonnan felvillant pár tizedmásodpercre a request.
-
Penge_4
veterán
válasz
fatal`
#13896
üzenetére
De épp erről beszélek, hogy ha a beállítást módosítod, mert nem akarsz naponta x ezer sütit törölni és azt sem akarod, hogy xy kétes oldal beléptethessen bárhova egy iframe-en keresztül (nem, nem érdekel mihez fér hozzá, egy biztonsági rés is elég és szopacs), akkor megváltoztatod, hogy csak onnan fogadjon el sütit, amelyik oldalt meglátogatod.
A Google még így is beléptet mindenhova, mivel a loginnál a google.com-ra átirányít, de legalább ezzel kiszűröd az iframeben betöltődő reklámok által elhelyezett sütiket.
[ Szerkesztve ]
-
Penge_4
veterán
válasz
Dluinet
#13932
üzenetére
Viszont oldalspecifikus szövegnagyítós kiegészítő már van. Szvsz jobb is, legalább az ikonokat nem homályosítja el. A semmitől mindenképp jobb.
1%-os lépték addig volt, amíg be nem vezették az új zoom csúszkát (nem ezt, az ettől eggyel régebbit). A mai napig vissza lehet tenni a sima legördülőmenüs zoomot, ami 20-1000%-ig van skálázva, sőt bele is lehet kattintani és manuálisan is lehet bele értéket írni, de Entert nyomva már nem zoomol sem köztes állapotokra (pl: 25%) sem szélső állapotokra, mint 10% vagy 5000%
-
#14036
Penge_4
veterán
Sk8erPeter
#14025
Penge_4
veterán
válasz
Sk8erPeter
#14025
üzenetére
"Hát ilyen alapon userJS-ekkel is csodálatosakat lehet gányolni."
Jaja, csak aki képes megtalálni az AppDatában (ami egy rejtett mappa) az Operás profilt, ott új könyvtárat létrehozni és bemásolni egy userJS-t, illetve kitallózni, majd oda menteni az már minimum 2.0-s user. Ha ezen felül még a headert (include, exclude, stb.) is tudja szerkeszteni, akkor 3.0 és így tovább...
Egy kiegészítőt pedig bárki képes használni. Még olyan is, akinek kiguglizni is nehezére esik, hol talál segítséget.
(#14035) GoodSpeed:
opera:config#UserPrefs|CacheDirectory4opera:config#UserPrefs|OperatorCacheDirectory4
opera:config#UserPrefs|TemporaryDownloadDirectory
-
Penge_4
veterán
válasz
S. Szabi
#14037
üzenetére
Ha ilyesmit tapasztalsz, mint itt, akkor az egy elég régóta létező bug, amit eddig még nem javítottak.
Két esetben jön elő, fix pozíciós (CSS) háttér és fix pozíciós látható elem esetén.
Ha értesz a CSS-hez, akkor ezeket a DIV-eket vagy hátteret elrejtheted.
A kérdés, hogy számodra mi fontosabb, a görgetési teljesítmény, vagy, hogy mondjuk egy csilivili háttér fölött gördülön a tartalom, esetleg, hogy legyen egy folyamatosan látható eleme az oldalnak.
Utóbbit 99%-ban beúszó reklámdobozoknál vagy mindenféle hülye toolbarnál (Facebook, Twitter) használják, tehát az esetek többségében lehet élni nélküle.
Engem is nagyon zavar ez a bug és remélem minél hamarabb javítják.
-
#14041
Penge_4
veterán
Sk8erPeter
#14040
Penge_4
veterán
válasz
Sk8erPeter
#14040
üzenetére
"már amennyiben nincs ideje valakinek arra, hogy egyenként letiltogassa mindet"
Nem kell annyit vesződni vele, 30-40 mega szabad helye mindenkinek van, ahol elfér egy kicsomagolt aktuális Opera USB, amiben ha működik, akkor 3 dolog maradt
- Kiegészítők
- Egyéni beállítások (operaprefs.ini)
- Egyéb profil fragmentáció (Local, többi ini, stb.)
- UserCSS -
Penge_4
veterán
válasz
RootRulez
#14055
üzenetére
Minden esetben mergel UUID alapján. Tehát ha te PC-n elmented a prohardver.hu-t könyvjelzőnek, majd elmented ugyanez Miniben is, akkor lesz két prohardver.hu, mert a cím egyezik, de az UUID egyedi. De ha megvárod, amíg a másik eszközön is leszinkronizálja a könyvjelzőket, akkor egy lesz csak belőle. Mivel más-más könyvjelzőket használsz mobilon és PC-n, így jelenleg a legjobb megoldás, ha nyitsz egy külön könyvjelzőmappát a mobilos tartalomnak, a gyorshívót meg nem szinkronizálod mobilon, amíg nem lesznek külön szinkronizációs profilok.
-
Penge_4
veterán
válasz
cousin333
#14112
üzenetére
(#14112) cousin333: "Ha új a gép, és vélhetőleg elég sok a memória, akkor akár ki is kapcsolhatod a lemez-gyorsítótárat"
A lemez cache és a memória cache nem váltja ki 100%-ban egymást, felhasználási szokásoktól függ. Ha valaki gyakran indítja újra a böngészőt, vagy ritkán, de sok lappal indítja újra, akkor célszerű a memóriacache. Ha pedig olyan oldalakat is látogat, ahol 1-1 ikonméretű képre is hosszú másodperceket kell várni, akkor ajánlott 16 giga RAM mellé is. Viszont akkor már érdemesebb megfontolni, hogy áthelyezi pendrivera.
"Másfelől nem azért költöttem annyit SSD-re, hogy aztán egy lassabb HDD-re pakoljam a gyorsítótárat, aminél a leglátványosabban kijönnének az SSD előnyei."
Ez jogos, de így vettél egy SSD-t, amit 1-2 évig teljes funkcionalitásában tudsz használni, akkor meg kitolod az élettartamát pár évvel.
(#14113) Dluinet: "Szerintem semmi értelme ezeknek a dolgoknak, így nem hosszabbítod meg az SSD életét."
Dehogynem. A szomorú tény, hogy az elején ilyen 17 éves élettartamokról indult, aztán a könnyebb (és kifizetődőbb) utat választva nem elég, hogy átálltak mindenhol (mármint a végfelhasználóknak szánt megfizethető szegmensben) MLC-re, de még a TRIM, a wear leveling és a garbage collection is úgy van tervezve, hogy ha eltérsz a "szokásos" használattól, többet árt, mint használ.zz
Mert az evidens, hogy ha valami folyamatosan átpakolja a cuccokat az egyenletes terhelés miatt, akkor minimum 2x annyi írást kell elviselnie + egy TRIM-et, amikor az előző helyről törli azt.
Az a baj egyébként, hogy az élettartam kalkulációkat a lemez teljes területére vetítve végzik. De neked mondjuk egy olcsóbb 64 gigás SSD-n van egy 20-25 gigás OS, az "ősi hagyományt" megőrizve a 64 gigából is csak 59-et látsz, mert a többi biztonságilag elkülönített cella, így marad 34 gigád, amin van 25 giga statikus adat, amit időnként teljes egészében "körbe-körbe" mozgat, ahogy a szabad területre extrém terhelést ró a többi apró írási folyamat.
-
Penge_4
veterán
válasz
Dluinet
#14117
üzenetére
"Ha nem megy tönkre addig, akkor is elértéktelenedik vagy extrém kisméretűnek fog számítani, mint most egy 8GB-os SSD."
Azért annyira ne szaladjunk előre. Egyrészt akkorát nem ugranak a méretek. A Win98 idejében egy átlagos vinyó 1-3 gigás volt, az XP idejében 100-200 gigás a Win7 idejében pedig 500 gigás - 1 terás.
Egy jobb minőségű zenei album mp3-ban most is 100-300 mega, egy jobb minőségű DivX/XviD most is hossztól függően 700 mega/1,4 giga, egy jobb minőségű BDRip pedig szintén mérettől függően 1,4 vagy 2,2 giga.
Tehát 4-5 év múlva bőven jó lenne még egy 30-40 gigás SSD is, ha másra nem, a hordozhatóság miatt még akár pendrive helyett is.
(#14120) GypsFulvus2: A Superfetch-t letilthatod, az SSD már elég gyorsan olvas. Egyébként bizonyos felhasználási szokások mellett HDD-nél is érdemes, mert csak feleslegesen kerregteti a vinyót, mivel az algoritmus nem éppen áll a helyzet magaslatán.
Már az előrelépés lenne, ha be lehetne állítani prioritás alapján, hogy miket töltsön mindig előre, illetve miket csak néha az alapján, hogy éppen mennyi RAM van szabadon.
A töredezettségmentesítés Win7-től automatikusan kikapcsolódik, az indexelést pedig kapcsold ki.
(#14124) klayton#1: Linkek panel
(#14139) Ayg0: Miért baj az, egyből tudsz kattintani bármelyik menüpontra és ha nem fér ki akkor elvileg van görgetősáv, nem?
A hiba az, hogy framesetet használ és valami nagyon hülyén van megírva az oldalsó menü. Nem tudom, rég találkoztam már ilyen ótvar routerrel.
Amúgy a Disconnect gomb miért inaktív?
(#14144) Sk8erPeter: Nem amiatt van, SSD-nél már 1024-gyel számolnak. Azért látsz annyit, mert az emberekbe már beleégett az 1000-es váltószám, ezért kapóra jött a gyártóknak, hogy ezzel az amúgy is rövid életű SSD élettartamát kitolják pár gigányi csere NAND segítségével. Persze tesznek bele enélkül is, de így mégiscsak olcsóbb, ha a normál méretből is csípnek le.
A Sandforce a sebesség miatti kísérleti eljárás miatt még a szabvány 64, 128, stb. méretekből is lecsípett és elkülönítette a maradékot csere-NAND-ként.
(#14190) hunfatal: Igen, az URL Filter API-t használva rendesen blokkol. Viszont, hogy mekkora a fáziskésés az már a scripttől is függ és az Operától is. Például ha kiegészítővel (NoAds) blokkolsz DIV-et, akkor bizonyos oldalakon felvillan egy pillanatra az akár üres DIV, majd eltűnik, ez a "késés" sima userCSS-nél nincs. Bár lehet, hogy erre szolgál a BeforeCSS event, hogy ezt elkerüljük, nem tudom, mivel a NoAds DOMContentLoaded-et használ.
[ Szerkesztve ]
-
Penge_4
veterán
válasz
fatal`
#14193
üzenetére
Lehet, hogy bug. Én már rég nem blokkoltam így. A lényeg már tiltva van. Bannert ritkán látok, maximum olyan oldalakon, amik Google találatként jönnek ki, azokkal pedig nem növelem a listát, nem valószínű, hogy visszatérek ugyanoda.
A többire meg hatástalan ez a módszer, de az Infó panelen látom a scripteket, CSS-ket és iframeket. Azt pedig már egyenesen rakhatom is a szűrőbe.
Ha nem mindenhol, akkor azt nézd meg, hogy nem-e valami random generált sorszámot tartalmaz a banner elérési útvonala? Például http://www.example.com/content/f4d3e6a1/banner.gif
Vagy ilyesmi. Esetleg még lehet olyan is, hogy http://www1.example.com/
-
Penge_4
veterán
válasz
cousin333
#14202
üzenetére
"Link?"
3. bekezdés vége.
"Tényleg roppant szomorú, hogy az átlagfelhasználóknak is megfizethetővé tették ezt a technológiát..."
A megfizethetőség relatív. Ebbe a kérdéskörbe inkább ne menjünk bele, mert én azt mondom a már meglévő robotnak teljesen mindegy, hány nanométeres bizbaszokat pakolgat, de mi csak azért sem tudunk leszokni róla, hogy tiszavirág életű elektronikai cikkekkel növeljük a hulladékmennyiséget, az újrafelhasználásra vagy magasról teszünk, vagy PR-ként felhasználva többszörös árat gombolunk le általa a környezettudatos vásárlókról. Ezen felül pedig a modularitás, kompatibilitás és szabvány vagy szitokszó vagy szintén háttérbe van szorítva.
"Itt arról van szó, hogy az amúgy is szükséges másolásoknál figyel arra, hogy ha lehet, akkor ne egy már agyonhasznált cellába írjon, hanem egy frissebbe."
A dinamikus wear levelingnél igen, a statikusnál azonban minimum 10% a write amplification. És ma már az összes forgalomban lévő statikus.
"A TRIM lényege meg éppen a kevesebb írási művelet."
Nem. A TRIM lényege a sebesség, mivel íráskor, ha már egy töröltnek jelölt cellába akar írni, akkor nem kell kiolvasni, törölni, majd beolvasni újra.
Tehát az írás ugyanannyi, csak időben eltolódik. A TRIM egyetlen hátránya, hogy a GetDataBack-hez hasonló megoldásokat kiiktat a wipe miatt.
"Emellett például a Sandforce vezérlő tömöríti is az adatokat, így kevesebbet kell írni"
Igen, de a tömörítéssel időveszteség is jelentkezik. Plusz valahogy ódzkodom tőle. Mi van, a ha valami firmware bug miatt bizonyos körülmények között nem csomagol ki és úgy jársz, mintha lekódoltad volna BitLockerrel a meghajtót?
Előnye pedig a tömörítési eljárástól függ. Videofájlokat és veszteséges zenéket nem lehet már igazán hova tömöríteni, ahogy veszteséges képformátumokat sem. Tehát OS-ként van mit tömöríteni, statikus adatoknál nincs.
"valamint több biztonsági tárhelyet tartalmaz (64GB-os lemez pl. 50GB szabad helyet ad)."
Ha két 64 gigásat vennék ahol nincs biztonsági tárhely és 64 gigát használhatok belőle, az még biztonságosabb lenne.
[ Szerkesztve ]
-
Penge_4
veterán
"Rendszeresen idönként előjönö a blog.hu hozzászólások betöltése után folyamatosan 100%-on pörget egy magot operával dolog"
Facebook valamelyik domainjét nem blokkolod véletlenül urlfilter.ini-ben?
(#14244) hunfatal: Nem az IE "vezette be", hanem egy Eolas nevű patenttroll szervezet gondolt egyet és úgy döntött, hogy mostantól a Flash beépülők szabadalom alá tartoznak.
Értsd: vagy csengetsz (komoly milliókat, hasonlóan, mint az MPEG-LA-nak), vagy belerakod ezt a szart a kódba.
Egyetlen kibúvó lehetne az Operának ezen a téren. Mégpedig ha külön USA Edition-t adnának ki és IP sniffinggel az USA-ból érkezők csak az USA Edition-t tudnának letölteni, amiben benne van ez a szar, mivel Európába nincs hatásköre az Eolas-nak.
(#14273) Laybee: Aha. Aztán az alap tisztításod miatt x hónap múlva nem tudod uninstallálni valamelyik szoftvert, mert a CCleaner előzékenyen törölte a Temp-ből az uninstallhoz szükséges fájlokat.
A Windows túl gány volt évekig, a fejlesztők elhülyültek, idő kell, amíg mindenki normálisan megtanul programozni. Még ma is vannak szoftverek, amik például hadilábon állnak az UAC-lal, csak éppen a Windows beépített védelmi megoldása miatt (VirtualStore) ez az átlagfelhasználónak nem tűnik fel.
Szóval azt mondom, amit nem muszáj azt ne törölgessük. Nem fog senkinek fájni az a pár mega a Temp könyvtárban. Ha meg telepítgetünk állandóan azt tegyük virtuális gépen.
Akkor egy Windows-zal ki lehet húzni 3-4 évig is.
(#14303) hunfatal: Az urlfilter nem felejt. Ha szarul van lekódolva a kínai kiegészítő, amit használsz arról nem az Opera tehet.
Mivel az tud hozzáadni és törölni is.
Ha meg a filterlistában átfedés van (pl blokkolva van már a *adserver* akkor a jobbklikkes blokkolásnál hatástalan lesz akár engedélyezed a http://www.adserver.com/banners/* cím alatti bannert, akár kettőt kattintasz rá és újra tiltod. Igen, ilyenkor úgy tűnhet, mintha eltünedeznének, ezért érdemes odafigyelni, hogy amiket blokkolsz ott ne legyen átfedés.
Ez Firefoxban van egyedül használható módon megcsinálva, saját statisztikával és oldalspecifikus buborékkal. Chrome-ban meg max külső adblockot használsz, mert ott még mindig csak CSS alapon tud blokkolni.
(#14307) hunfatal: Kapaszkodj meg, Chrome-ban is. http://people.opera.com/rijk/opera/
Válts át a piros stílusra és szemléld meg, mennyivel kevésbé dinamikus még a darabos scroll is. A smooth scroll bugnak valójában annyi köze van a smooth scrollhoz, hogy mivel az lassabb és átmenetibb, így jobban feltűnik, hogy akadozik. De ennyi. Mind az Operában, mind a Chrome-ban smooth scroll nélkül is jelen van fix pozíciós elem és háttér esetén.
Egyébként mi bajod a Chrome letöltéskezelőjével? Mármint azon kívül, hogy
1. Nincs temporary downloads.
2. Nincs mime type alapú beállítási lehetőség
3. Kikapcsolhatatlan a hülye sáv alul.
4. Nincs "törlés a lemezről" opció.
5. Nincs a fájltípusnak megfelelő környezeti menü.A könyvjelzőkezelőnek hívott valami is ironikus módon még a Google Bookmarks-tól is butább. Sem tagek, sem description, sem azonosító, sem semmi. Csak cím és URL + fa szerkezet. Ezzel az erővel egy HTML fájlban is hordozhatom a könyvjelzőimet. Ja, nem. Az okosabb, ott van alt, title, abbr és longdesc is.
(#14310) hunfatal:
*, *::before, *::after {
position: static !important;
}De ez egyikben sem lesz jó megoldás, mert az ilyen hulladék oldalakon sokszor körbe van pakolva 1-1 elem képekkel és ilyenkor az széthullik.
Egyik ilyen a Gmail.
(#14329) kispx: Elő, hogy rohadna meg, kb mióta létezik ez a funkció. Már írtam is nekik, hogy ez egy hatalmas nagy biztonsági rés, de azzal sem foglalkoznak.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
dqdbKérdés előtt olvasd el az
összefoglalót!
- Politika
- Milyen alaplapot vegyek?
- Bluetooth hangszórók
- sziku69: Szólánc.
- Kerékpárosok, bringások ide!
- Otthoni hálózat és internet megosztás
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Vezetékes FEJhallgatók
- sziku69: Fűzzük össze a szavakat :)
- További aktív témák...
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Windows 10/11 Home/Pro , Office OEM/Retail kulcsok
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- PC JÁTÉKOK (OLCSÓ STEAM, EA , UPLAY KULCSOK ÉS SOKMINDEN MÁS IS 100% GARANCIA )
- Eladó Steam kulcsok kedvező áron!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen