Hirdetés
- Megújult a Glorious GMMK klaviatúracsaládja, és már van benne analóg modell is
- Végre a Logitech is bemutatott egy analóg klaviatúrát
- A GameMax háza egyedi csavarral lovagolja meg a mai trendeket
- iGPSport iGS800 kerékpáros óra: egyből a csúcsra tör
- Már nincs messze a világ első teljes UCIe IP megoldása
- Milyen TV-t vegyek?
- Bluetooth hangszórók
- Azonnali VGA-s kérdések órája
- Apple notebookok
- Ventilátorok - Ház, CPU (borda, radiátor), VGA
- Fejhallgató erősítő és DAC topik
- Mikrokontrollerek Arduino környezetben (programozás, építés, tippek)
- Milyen videókártyát?
- VR topik (Oculus Rift, stb.)
- Milyen billentyűzetet vegyek?
Hirdetés
-
No More Room In Hell 2 - Jövő hónapban indul a PC-s korai hozzáférés
gp A bejelentéssel együtt egy rövid előzetest is kaptunk a játékhoz.
-
Gondoskodik róla az EU, hogy az Apple felnyissa a rendszereit
it Az Apple-nek meg kell nyitnia a rendszereit a riválisok felé, ebből az EU nem enged.
-
Kiderült, mekkora aksi van az iPhone 16-okban
ma Mindegyik telep nőtt, legtöbbet az iPhone 16 Pro hízott.
-
PROHARDVER!
Új hozzászólás Aktív témák
-
Penge_4
veterán
válasz fatal` #14331 üzenetére
Nem. A Mozilla nyílt forráskódú.
Amúgy azért IE-ben volt először, mert a Microsoft úgy gondolta, hogy nem érdekli, mivel őket senki nem bünteti meg, aztán pert nyertek velük szemben, aztán az Opera végül úgy látta, hogy inkább nem feszegeti a határokat és beleteszi, mivel az ő kis norvég cégüket egy ilyen per össze is roppantaná gazdaságilag.Folytathatnánk tovább a filozófiai kérdéseket, hogy mi az, ami még baromság, mégis mindenki betartja/fizeti, rettegve a következményektől, de ez nem az a fórum.
"Először is leszögezném, hogy kézzel írtam be az inibe a szabályokat nem kiegészítő."
Az lényegtelen. Csinálj egy kiegészítőt és az filter.block.add(rules); eltávolítja az összes olyan szabályt, amit a rules változóban megadtál.
Fizikálisan az urlfilter.ini-ből végleg. Tehát nem csak egy ignore flag-et kap Local Storage-ban vagy ilyesmi.
(i)"pl. sg-n az a sárga szar felül elég gyakran"(/i)
Nálam ezek vannak blokkolva a Details szerint az SG-n és nincs sárga szar. Hátha ez segít. -
Penge_4
veterán
válasz fatal` #14337 üzenetére
Kiegészítő bug vagy nem tudom. Én ilyet még nem tapasztaltam.
(#14338) Wolfskin: A YouTube-ra nem tudok mit mondani, használd a gyári Flashblockert, az működik.
Az opera:cache csak akkor tárol, ha a lemez cache engedélyezve van.
A Textarea Backup helyett használhatod a Jegyzetek panelt.
Ctrl+F12->Haladó->Billentyűparancsoknál törölheted a Speed Dial-ra vonatkozó Ctrl+ parancsokat és akkor nem fog elnavigálni.
A Unite-tal kapcsolatos problémádból kiindulva ráférne már egy teljes profiltörlés az Operádra.
(#14339) daninet: 12.00-ban már javították, 11.50 véglegesben jelenleg annyit tudsz, hogy ilyenkor felfelé nyomod.
Címsorban csak akkor van Suggestion, ha eléírod a "g" kulcsszót.
(#14342) brd: A cookie alapú nem 1000 karakterig jó, hanem 4096-ig és sokkal instabilabb, mint a Local Storage alapú.
A Local Storage 10.5x-ben (a legbugosabb Opera széria) nem mentett crash után. Most már ment.
A probléma abból adódik, hogy csomó oldalon (ilyen például a blog.hu is) JavaScript alapú vagy AJAX-os hozzászólás doboz van. Ezeken a helyeken nem is fog működni semelyik, még a beépített megoldás sem.
De mivel a kiegészítő elég régen frissült, nem kizárt, hogy bugos. De az már nem az Opera hibája. Elvileg 11.50-től már részleges File API támogatás is van. De widgetek File I/O-ját is használhatná már, ahogy a Dither-féle NoAds módosulat is azt használja.
A JS-es szövegdobozok problémája azonban akkor sem oldódik meg.
-
Penge_4
veterán
válasz M_AND_Ms #15351 üzenetére
Nálam a Ghostery blokkolta, de bármilyen olyan kiegészítő blokkolhat oldalakat hasonló módon, ami az URL Filter API-t használja (és ilyenkor nem látszik a tartalomblokkolóban, mivel fizikálisan nincs az urlfilter.ini-ben a string, ami miatt nem töltődik be az oldal.
Oldalspecifikus fehérlista (még mindig) nincs, ezért lehet csak a teljes reklámblokkolást kikapcsolni oldalspecifikusan. Hogy az URL Filter API képes-e rá (és csak eddig nem csinálta meg senki), vagy nem, azt pontosan nem tudom, viszont a UserJS header @include, @exclude megoldással nem játszható ki. De van remény, mivel a Facebook blocker hasonló elven működik
-
Penge_4
veterán
válasz Dictator^ #15370 üzenetére
MLC-kben eleve össze vannak sűrítve a blokkok. A 20 giga alapból megvan a Windows háttérműveleteiből (bőven elég, ha nyitsz egy Process Monitor-t és látod, ahogy olvashatatlanul pörög, amikor szinte "üresjáratban" van a gép.
Rengeteg írás történik egy rendszerpartíción, ami írásonként 512 kilobájttal számolva elég durva.
-
Penge_4
veterán
válasz M_AND_Ms #15436 üzenetére
Vagy csak nem ismerted fel. A Lounge például nagyszerű arra, hogy összehozz egy konferenciabeszélgetést (igaz, csak írásban, de ez a HTML5-tel talán megváltozik).
A fájlküldés alatt is érzékeny adatokra kell gondolni, amit nem töltenél fel harmadik félnek.
A Webservernél is ha webfejlesztő vagy és a megrendelőnek akarod mutogatni, nem pedig otthoni szervernek.Inkább csak a marketingje volt rossz, aztán nem lett népszerű.
(#15437) Dluinet: Az Adblock kiegészítő az URL Filter API által az gyári tartalomblokkolót használja. Azoknak jó, akik túl lusták ahhoz, hogy saját maguk manuálisan állítsák össze. De olyan sosem lesz, mint egy manuális és/vagy túl terjedelmes lesz a lista, ami lassítja a böngészőt és/vagy túl agresszív szabályok által megjelenítési problémákat is okoz, ahogy te is írtad.
[ Szerkesztve ]
-
Penge_4
veterán
válasz w.miki #15450 üzenetére
Mivel már 2006-ban is legalább 30-40 kiegészítő beépített funkciókkal helyettesíthető volt Operában, azóta pedig csak bővült a kör, plusz az Operás kiegészítők a Chrome-os kiegészítők és a Firefox új, Jetpack (újraindítás nélkül alkalmazódó) kiegészítőinek felelnek meg (tehát nem tudsz például FTP klienst csinálni a böngészőből általuk), ezért nem is szükséges több, ami van is sok és rengeteg az átfedés is.
-
Penge_4
veterán
Miért, kire bízza? Ott a QA, akik ellenőrzik és a fejlesztők által is érthető formába öltik a semmitmondó "crash on the xy.com" megjegyzéseket. Ráadásul ők látják a forráskódot, konkrétan már úgy tudják továbbítani a fejlesztőknek, hogy a xy fájlban a 456. sor 34. karakterénél van egy végtelen ciklus.
A felhasználóknak van egy olyan tulajdonságuk, ami semmilyen fizetett bétateszternek nincs. Mégpedig általuk fut a szoftver milliónyi különböző konfigon és különböző szoftverkörnyezetben. Ha pedig terjeszteni akarják, akkor el kell dönteniük, hogy azt mondják "Hülyegyerek, ne buherálja a registry-t és akkor nem akad össze és nem ragad be a processz és nem produkál olyan hibákat, amiket másnál nem" és lemondanak ezekről a felhasználókról, vagy erőforrást fordítanak az elterjedtebb user error-ok orvoslására. Plusz itt már a konkurenciaharc is húzó erővel bír. Lásd: hulladék weboldalak, amik ha széthullanak Operában az lesz Mancika első érve, hogy "De hát a Firefoxban és az IE-ben miért nem hullik szét?"
-
Penge_4
veterán
válasz Namelesske #15698 üzenetére
Meg tegyük hozzá, hogy miközben a puritán Chrome már alulról nyaldossa a 30 megát (ne fogd a beépített pluginekre, a Chromiumban nincs semmi, mégis 26 mega körül van már az offline installer), a Firefoxból az egynyelvű is 15 mega, az IE-t nem tudom, a 60 megás Safariról ne is beszéljünk... Szóval mivel az Opera vezeti magasan a mezőnyt méret terén még ha a funkcionalitást (amiben szintén az Opera az első) nem is vesszük hozzá, így nincs túl nagy prioritása az agyonoptimalizált kódnak.
Mert kétféle optimalizáció van. Amikor ésszerű keretek között optimalizálnak és nem úgy állnak hozzá, mint az MS, hogy "Mit rinyálsz? Fillérekért (usákoknál warezadó nélkül) lehet terabájtos vinyót venni.", és amikor ezen a téren is átesnek a ló túlsó oldalára és e-penis-t méregetnek, a végén pedig már az átláthatóság rovására megy, ennek következtében pedig csak szaporodnak a bugok.
Az Operában (a telepítettben) így is 2,5 mega a gstreamer könyvtár és 14,7 a locate (nyelvi fájlok). Ezek nélkül a 36 megás telepített Opera csak 22 megás lesz. A következő legnagyobb pedig majdnem 1 megával a skin mappa.
-
Penge_4
veterán
válasz fatal` #16599 üzenetére
"Egy szakmai fórumon a böngészőt okolni azért, mert nem jelenik meg jól egy gányult megírt weboldal, minimum röhejes."
Főleg, hogy megint (jó szokásához híven) trollkodik. Mert ő is tudja nagyon jól, hogy aki annyira sötét (a trollokon kívül), hogy a böngészőt okolja ahelyett, hogy rájönne, hogy talán olyasmit blokkolt, amit nem kellett volna, az nem blokkol tartalmat. Sem manuálisan, UserJS-sel, sem Adblock-kal, sem Ghostery-vel, sem semmivel. Nem csinál semmit, használja a böngészőt úgy, ahogy az feltelepült. Innentől maximum a röfögő, zenélő bannerek idegesítik (amik minden más böngészőben is idegesítik), de minden ilyen szar fog menni benne. Ami Firefoxban és Chrome-ban is csak azért megy Adblock mellett, mert azokban van fehérlista támogatás. Ezentúl Operában is lesz ilyen.
[ Szerkesztve ]
-
Penge_4
veterán
válasz Sk8erPeter #16630 üzenetére
"(lásd Chrome forráskód-nézegetője, ami ugye frissítgethető is)."
Mármint ha az oldal tartalma változik. De te nem tudod kliensoldalon módosítani az oldal tartalmát azon keresztül, mint Operában, ahol szerkeszthető a forráskód és újratöltés után az oldal is változik, aminek a forráskódját szerkesztetted.
"Ha valaki hozzászokott a Chrome beépítettjéhez vagy a Firebughoz, akkor az tuti ezt nem fogja használni."
Ha meg valaki a Dragonfly-hoz szokott, az Chrome-on kap infarktust, hogy hiába kattint egy elemre az oldalon, a debugger nem fog odaugrani.
(#16635) brd: "ha fut ilyen, https-es oldalon, akkor sokszor bebugzik, és eltűnik a zöld/sárga lakat"
Az szerintem nem bug. Mondjuk lehetne egyértelműbb jelzés is, de onnantól, hogy egy külső script injektálódott a biztonságos oldal forráskódjába, az már nem mondható teljesen biztonságosnak. Maximum ha megbízol a script/kiegészítő fejlesztőjében.
"a https userjs warning, és az url szürkítés, a beépülőre való kötelező kattintás (ill. ez nem bug, de idegesítő)"
Utolsó már csak idő kérdése, hogy kivegyék, mivel az Eolass-nak annyi, a többire meg van patch.
"Mondjuk ezek az első kettő kivételével kipatchelhetőek szerencsére"
A Tab Stacking is. [link]
-
Penge_4
veterán
válasz Sk8erPeter #16710 üzenetére
"Gondolom inkább címzési korlát akart lenni."
Javítva.
"Példának okáért szerintem ha valaki gondolkozik, hogy vajon tényleg fog-e érezni a BÖNGÉSZÉS során előnyöket a 64 bites változattal, akkor rohadtul nem érdekli, hogy van-e szükség visszafelé kompatibilitásra, vagy nincs."
Szerintem meg igen. Elég ha megnézed mióta ismert hiba a Windows 2000 inkompatibilitás. Szóval ha ezeket a koloncokat végre ledobálnák magukról, akkor a végfelhasználó is érezné. Elsősorban
- Kevésbé bugos szoftver (kevesebb hibalehetőség).
- Gyorsabb fejlesztési tempó (nem kell foglalkozni a visszafelé kompatibilitással)Továbbá (bár ez gondolom még HDD esetében is csak szoftverekkel mérhető), nem mindegy, hogy milyen libeket hív be indításkor.
Az Operára vonatkoztatva viszont nem tudom, mert ez az elméleti fejtegetés arra vonatkozott, hogy amennyiben a szoftverfejlesztő minden előnyét kihasználja a 64 bitnek. De nyilván ahhoz is kell plusz programkód, hogy 32 bites plugineket tudjon futtatni plugin-wrapperen keresztül a 64 bites böngésző.
Ráadásul ha BIOS-ban nem kapcsoltad át a HPET mode-ot 64 bitre (bár ezt csak akkor teheted meg, ha kizárólag 64 bites OS-eid vannak), akkor a regiszterek 32-bites kompatibilitás módra vannak kényszerítve.
És te is nagyon jól tudod, hogy ahhoz, hogy a visszafelé kompatibilitási nehezékeket az összes szoftverfejlesztő (beleértve az Operát) ledobálhassa magáról és idővel megjelenjen egy olyan Windows, amiben már nincs 32 bites kompatibilitás, ahhoz nagyságrendekkel több embernek kell 64 bites verziót használni, hogy a 32 bitest lehessen végre kukázni.
Dunát pedig olyan cikkekkel lehet rekeszteni, ahol vérPistikék jól megaszondják, hogy "Ha nincs 4 gigától több RAM-od, akkor felesleges."
Ezt a ködöt próbáltam eloszlatni egy kicsit azzal, hogy van azért számos más terület is, ahol előnyösebb a 64 bit. Főleg ha már eleve adott egy 64 bites rendszer. Ott vétek 32 bites szoftvert futtatni, hogy a CPU jojózzon az utasításkészletek között.
(#16711) hunfatal: Mivel bugosabb?
-
Penge_4
veterán
válasz fatal` #16714 üzenetére
Az nem HWA specifikus? 32 bitesben nincs jelen?
Más: DirectX-es HWA-val más is tapasztalta, hogy 30-40%-ra terheli a dwm.exe a GPU-t, mikor az ITCafe-n írok a hozzászólásdobozba (mint például most is ezt a hsz-t). Ha háttérbe rakom ezt a tabot, akkor megszűnik a terhelés. Ha visszaváltok rá, akkor újra terhelődik.
-
Penge_4
veterán
-
Penge_4
veterán
válasz fatal` #16718 üzenetére
Jelentve: DSK-365452
-
Penge_4
veterán
Bekapcsolod a hardvergyorsítást, megbizonyosodsz róla,hogy DirectX-en van, nem pedig OpenGL-en, majd írsz egy hozzászólást (vagy választ) valakinek az IT Café felületén. Miközben a szövegdobozba gépelsz (és ha nem gépelsz akkor is, egészen addig, amíg a hozzászólásíró fül előtérben van) tapasztalhatod.
ps: Most, mikor először kezdtem neki a válasznak nem volt terhelés. Visszaléptem, majd újra válasz és azóta akárhányszor ismétlem van terhelés. Szóval érdekes.
-
Penge_4
veterán
-
Penge_4
veterán
Egy Refresh skin gombot azért ne felejts el mellé tenni, mert minden böngészőújraindítás után elfelejti a [Generic] szekcióban a gyáritól eltérően definiált dolgokat, így ezeket is (vagy például a line spacinget). Ez viszont megint egy ősrégi bug.
(#16743) Sk8erPeter: Hozzáférést csak Opera Software dolgozók kapnak. Bejelentkezni én se tudok, de ha a beküldött bug DSK sorszámát a https://bugs.opera.com/browse/ után írod, akkor az úgy sokkal trendibb. A Desktop Team-en is már egy csomóan így linkelik, akiknek szintén nincs hozzáférésük.
Mondjuk azt azért megoldhatnák, hogy az ember legalább a saját bugreportjait tudja követni.
-
Penge_4
veterán
válasz Sk8erPeter #16761 üzenetére
Chrome-ban nagyon jó a keresés minden szempontból.
1. Találat számláló
2. Nem ékezetérzékeny (bár itt lehetne azért opcionális kapcsoló, de azért néha nagyon hasznos tud lenni).
3. Nem fagy meg a böngésző nagy terjedelmű oldalon sem, például [link]Operában nem tudom letesztelni, mert nem listázza ki a fájlokat (ezáltal terhelés sincs), de a WhatWG oldalát kipróbáltam.
Chromiumban ennyi a betöltés (és mellette a többi tabot lehet használni. Érdekes módon régen, 8.x-ben multiprocessz nélkül is meg tudták oldani, hogy a háttérben történő betöltés ne fagyassza meg a böngészőt.
[link]
Operában itt untam meg (függetlenül attól, hogy csináltam-e valamit, vagy hozzá se nyúltam az ablakhoz ilyen CPU ciklusokat generált a végtelenségig. Ebből is elég jól látszik, hogy borzalmas. Egyébként szűz Opera USB-vel (12 RC2) teszteltem kiegészítők és mindenféle egyéb nélkül. Linkifierrel például meg is halt volna.
[link]
Ezen kívül a keresés. Chromiumban éppen egy picit akadozott (és még számolta is a találatokat), Operában minden billentyűleütés 5-10 másodpercet késett, 2-3 másodperces "Not Responding" szünetekkel.Visszasírom azokat az időket, mikor a 9.5-ben megjelent az új text parsing algoritmus és hatalmas terjedelmű szövegekben lehetett villámgyorsan keresni, navigálni.
"Előbb mi a tökömért volt jó, és most miért rossz megint, újraindítást követően? Mi történt? Valaki ezt érti?"
Ismert bug az idők kezdete óta. Erről beszéltem, hogy skin-ben definiálni és skin refresh minden újraindítás után.
-
Penge_4
veterán
válasz Sk8erPeter #16764 üzenetére
"Ezek szerint akkor az a narancssárga szín mégis a skin.ini-ben történt változtatás hatása volt?"
Nem. Az egyik a skin.ini-ben változtat, ez meg gondolom az operaprefs.ini-ben. De mindkettő ugyanazt okozza (és gondolom emiatt van, hogy ugyanaz a bug érinti mindkettőt egyformán).
"Mi a skin refresh módja?"
"Reload skin" - Csinálsz belőle billentyűparancsot, mozdulatparancsot, sajátgombot, amelyik a legjobban kézre áll.
Nem tudom miért nem sikerült. Elvileg Total Commanderrel belemész (ha gyári skin-t használsz, akkor az a Program Files-ban van, tehát adminjogosultság kell a szerkesztéshez) a zip-be, megnyitod a skin.ini-t és a már létező [Generic] szekció alá szerkeszted be a megadott 4 sort a választott színek hexa kódjával. Majd Ctrl+S, bezárás, a TC megkérdezi visszacsomagolja-e, leokézod és már kész is. Indítod az Operát, Reload skin és a következő újraindításig élvezed a hatását. Valószínűleg ezek szerint a Reload skin-t hagytad ki.
Azért nofocus, mert amíg nem nyomsz Esc-et, addig a keresődoboz van fókuszban, tehát a szöveg nincs. Ugyanis például link esetében a focus-ban lévő linket meg is tudod nyitni Enterrel.
[ Szerkesztve ]
-
Penge_4
veterán
válasz Sk8erPeter #16766 üzenetére
"Na most akkor a
Selected Text bgcolor nofocus = #FF9632
a skin.ini-ben minek kell egyáltalán?"Mert az egyik akkor jó, ha ritkán cseréled a skinedet és skinspecifikus (amikor éppen nem funkcionális haszna van, hanem a megváltoztatott kijelölésszín jobban illik az adott skin színvilágába), a másik pedig skinfüggetlenül ott lesz az operaprefs.ini-ben.
De lényegében mindkettő az egész böngészőben módosítja a kijelölés színét. Akár ha szimplán szöveget jelölsz ki az oldalon, akár az oldalsávon kijelölt elemek, az mind ugyanazzal a módosított kijelölésszínnel fog megjelenni.
"Ha most egy gyári alapján lemásolok egy standard_skin.zip-et, beállítom a megfelelő elérési útját, és annak a skin.ini-jében állítgatok, akkor az egyáltalán érvényre fog jutni?"
Igen.
"Vagy akkor melyik az "erősebb", az operaprefs.ini? Annak a beállításai élveznek prioritást, vagy a skin.ini-ben szereplők? Vagy rosszul teszem fel a kérdést, mert a skin.ini alapján építi újjá egy Reload skin esetén az operaprefs.ini-t?"
Szerintem a skin.ini-ben lévőnek magasabb a prioritása, mivel az böngészősessionon belül is változik. De ki kéne próbálni.
-
Penge_4
veterán
válasz Sk8erPeter #16770 üzenetére
Az operaprefs.ini-s változatot hagyd, az nem segít. Most próbáltam egy tiszta USB-ben, az oldalon akijelölés színét megváltoztatta, de a forrásban nem.
A skin.ini-ben is működik, hogy csak azokat a szekciókat adod meg, amiket módosítani akarsz a gyárihoz képest, annyi különbséggel, hogy ott oda kell figyelni a Clone-ra (mert mert ha valamit egy másik szekcióból klónoz, akkor arra nem tud hivatkozni a módosított skinen belül), valamint a .top, .right, .left és .bottom-ra, ha létezik mind a 4, akkor mind a négyet másolnod is kell, még ha csak az egyiknél is szeretnéd, hogy eltérjen a gyáritól.
Az alap skin.ini-nek ezeket kell tartalmaznia:
# This file describes the skin for the Opera browser
[Info]
Name = A név, amit akarsz
Name String Code = TOK_MINDEGY
Author = Amit akarsz
Version = 3
Preview Image = bg/preview.png
[Options]
Large Images = 0
Button Text Padding = 0
Fallback foreground = 0
Fallback background = 0
Inverted Pagebar Icons = 1
Transparency = 1
Full Transparency = 0
Dim Disabled Backgrounds = 0
Native Color Theme = Window Skin
Glow On Hover = 0
; How much the Aero client border is inset by, valid values are 0-4
Window Border Inset = 2
; The color if the outer window border when a "persona" theme is active
Window Border Color = #7CFFFFFF
; The inner color of the border between the window border and the UI
Window Inner Border Color = #47000000
; Include toolbar margins when positioning toolbars
Allow Toolbar Margins = 1
[Generic]
Line Padding = 2De csak az Options-ban vagyok biztos. Mindenesetre az összes módosított minimál skin ezeket tartalmazta valamilyen formában.
A Button Set-et hagyd. Csinálsz egy skin mappát a profilodban (ha még nincs), abba belerakod a kiherélt gyári skint, majd az Opera következő indításánál a Shift+F12-ben megjelenik. Az operaprefs.ini-ből meg szedd ki az egész [Colors] szekciót.
-
Penge_4
veterán
válasz Sk8erPeter #16772 üzenetére
opera:config#UserPrefs|OperaDirectory
Igen, és akkor már a Local-t is, mert a levelező, kiegészítők és az RSS abban van. És ügyelj rá, hogy ne hivatkozzon más máshova az operaprefs.ini-ben.
De miért, ha szabad kérdeznem? A C fizikailag különálló lemez? Csak mert újratelepítésnél úgyis mindent újra be kell lakni, akkor meg már mit számít, hogy a profilodat újra bemásolod. Akár még a felhasználónevedet is megváltoztathatod, mivel így dinamikusan a %appdata%-ra hivatkozik, tehát a userJS könyvtárat, (ahol a telepített változatnál valamiért nem működik a {SmallPreferences}, ellenben az USB-ben megadható profile\userjs formában) és az egyedi elérési útvonalakat leszámítva minden a régi marad.
Ha csak egy Windowsod van és attól félsz, hogy kidöglik alólad, akkor egyrészt Vista fölött már a régi fájlokat (ha van elég hely a rendszerpartíción, ha nincs, akkor nem tudom), ami a Program Files-t, a Users-t és a ProgramData-t foglalja magába belerakja egy Windows.old nevű mappába, ahol elérhető marad (amennyiben nem formázod le a telepítőlemezzel a partíciót). Továbbá egy Linux Live CD-ről is be tudsz tölteni egy hordozható fájlrendszert, ami már kezeli az NTFS-t, szóval elvileg tudsz másolni egyik partícióról a másikra (bár ezt még nem próbáltam).
Tehát ezért különrakni nem sok értelme van.
[ Szerkesztve ]
-
Penge_4
veterán
válasz Sk8erPeter #16776 üzenetére
Én is strukturáltan tartom és a Documents és társait át is helyeztem (főleg mivel minden szar mindig ezt ajánlotta fel defaultnak, aztán meguntam és átindexeltem).
Roamingban van 26 környváram Local-ban 20, Program Data-ban nem számoltam, de onnan úgyse kell semmit. Így ránézésre van vagy 7-8 cucc, amit feltétlenül backupolni kéne. A Program Files-t és a Program Files (x86)-ot így is-úgy is át kéne néznem (bár Vista óta könnyebb dolgom van a Local\VirtualStore miatt).
Az utolsó (saját) rendszertelepítésem (Win7) pedig 2009-ben volt, mikor megjelent az RTM, szóval nem vagyok az az újratelepítgetős típus. Pár évente egyszer kibírom, főleg, hogy ilyen időintervallumokban már hardverváltozások miatt többnyire újra kell rendszereznem a partícióimat.
-
Penge_4
veterán
válasz Sk8erPeter #16779 üzenetére
"akkor a hatmillió mélységű könyvtárakba navigálgatás miatt gyorsan elmegy a kedvem az egésztől, ha épp gyors eredményre vágynék inkább."
Ezért vannak kedvencek a Windows Explorerben és tabok a Total Commanderben.
"ezenfelül mondjuk szempont lehet az is, ha akár egy Dropbox/Google Drive/SkyDrive-fiókkal szinkronizáltatni szeretném a nem szenzitív adatokat tartalmazó beállításokat"
Az már a szinkronizáló szoftver hiányossága, ha nem lehet egyenként betallózni a szinkronizálandó könyvtárakat. Én ebből a szempontból különben is paranoiás vagyok, csak titkosítva, rarolva töltöm fel a fájlokat.
"No, de mondom, igazából ezt a problémát áthidalhatja egy directory junction."
Nekem ez kicsit magas: Létrehozok (vagy létrehoz egy program) egy fájlt a C partíció AppDatájában, ezáltal a fájl a C partíción lesz fizikailag.
1. Én megcsinálom a linkelést, hogy a D-n lévő link is a C partíción lévő fájlra hivatkozzon, ezáltal úgy tűnik, mintha tükrözném a könyvtárakat, pedig fizikailag valójában a C-n van.
2. Mikor létrehozom a hardlinket a fájl is párhuzamosan létrejön (amolyan RAID-szerűen) a másik partíción és mikor módosítva van az egyik, módosul a másik is. Ezáltal redundáns (ha nem száll el a vinyó), viszont dupla helyet foglal és dupla írási műveletet ró az amúgy is lassú HDD-re.Szóval melyik a kettő közül?
Illetőleg kompatibilitás terén milyen? A szoftverek széles tárháza (ami sokszor még egy felhasználónévben lévő ékezetre is érzékeny, vagy szimplán a nem ASCII karakteres fájlneveket nem nyitja meg (lásd: XnView nem nyit meg ő és ű betűket tartalmazó fájlneveket, pedig az is egy elég ismert cucc), akkor simán átsiklik ilyen újnak számító, "Vista and above only" megoldásokon?
Akkor már csinálok egy új Library-t Backup néven és oda hivatkozom az összes backupolandó fájlt.
-
Penge_4
veterán
válasz Predator2 #16813 üzenetére
(#16813) Predator2: [link]
(#16817) Namelesske: Azért most legalább valamit javítottak rajta. Nem úgy, mint korábban. Ráadásul igazi Apple-i (fogd másképp) kifinomultsággal és eleganciával állnak hozzá a support témához. [link]
(#16822) Sk8erPeter: A cikkben be van linkelve pár. Válogass (az első, Rijk oldala már jó, csak van egy kis tearing, ennyi volt a "csiszolás". A többi ugyanolyan).
(#16824) GoodSpeed: A címsávban kéne megjelennie egy legördülő nyílnak. Ha nem jelenik meg, indítsd újra.
-
Penge_4
veterán
Nem tudja valaki, hogy a Dragonfly képes-e a NoAds azon funkcióját helyettesíteni, hogy adott DIV-re mutatva annak teljes elérési útvonalát kimásolja nth-child-estől? Mert másra nem használom a NoAds-ot, akkor meg felesleges, úgyis UserCSS-vel blokkolok, mivel az gyorsabban alkalmazódik, mint a Local Storage és nincs villanás azonnali rendernél se, ráadásul emberi szemmel is olvashatóak az adatok.
A Layout fül->Parent Offsets-hez hasonlóra gondolok, csak pseudo class-okkal együtt.
-
Penge_4
veterán
válasz Sk8erPeter #16867 üzenetére
:nth-child()-ekre gondolok. És azért, mert enélkül olyat is blokkol, amit nem kéne.
-
Penge_4
veterán
A következő szöveget illesszétek a címsorba:
Lorem ipsum is simply dummy text of the printing and árvíztűrő tükörfúrógép industry. Lorem ipsum has been the industrys standard industrys standard dummy text. Ever since the 1500s, when an unknown ipsum printer, took type and 2-re........Kódfejtők előnyben. Vajon mi a baj a szövegben? Annyit megfejtettem, hogy 240 karakter körül kell lennie és szükséges tartalmaznia unicode karaktereket, valamint számot és kötőjelet és a végén pontokat. De a pontos mennyiséget és a miértet nem.
(#16869) Sk8erPeter: Köszi. Akkor inkább maradok a NoAds mellett.
-
Penge_4
veterán
válasz Sk8erPeter #16894 üzenetére
Igen, azt elfelejtettem írni. Én is véletlenül jöttem rá, mivel rossz szokásom, hogy néha arra használom a címsávot (mivel az van kéznél), hogy megnézzem, nincs-e valami fontos a vágólapon.
-
Penge_4
veterán
Pedig ezek szerint valamit használsz. Adblockot vagy hasonlót, mert anélkül nincs letiltott webcím, manuálisan pedig elmondásod szerint semmit nem raktál az urlfilter.ini-be.
A Ghostery pedig rendesen blokkol, tehát ha olyan oldalt akarsz elérni, ami például trackerről irányít át (vagy egy videót, ami a tracker-t tartalmazó URL-ről hívná be az FLV/MP4 fájlt), akkor bukta van. 12.10-ben talán megoldódni látszik végre a helyzet, mert kiegészül pár fehérlistás szabállyal. De jelenleg vagy blokkolod az adott trackert és akkor nem használod az oldalt/nézed a videót, vagy nem blokkolod és akkor nézheted az oldalt/videót. Amíg 1-1 ilyen eset van, addig nem vészes privacy szempontból, csak kényelmetlen, mert azt látja a tracker, hogy meglátogattad az oldalt (böngésző, felbontás, OS, IP, etc.), de mást már nem, mivel csak azon az oldalon engedélyezted ideiglenesen, amíg megnézted az oldalt/videót, utána ki is kapcsoltad, vagyis ott egy cookie a böngészőben, amit ha nem is törölsz ki se tud már a script visszaolvasni, mivel újra elvágtad az elérési utat.
-
Penge_4
veterán
Egyébként ha már Ghostery: Másnál is az van, hogy mikor elindítja a böngészőt a Ghostery késleltetve töltődik be, ezért a már megnyitott lapokon lefutnak azok a scriptek, amiket blokkolnia kéne?
(#16928) Laybee: A profilodban az operaprefs.ini fájlt megnyitod és ott ugyanezeket a beállításokat tudod módosítani.
-
Penge_4
veterán
válasz Namelesske #16939 üzenetére
A könyvjelző független tőle, ha sok könyvjelző van a gyökérkönyvtárban, akkor lassan töltődik be.
(#16941) dqdb: Szerintem meg valami script időzítés, vagy hasonló. Az ikonok késleltetve jelennek meg, de a kiegészítők scriptjei attól még oldalbetöltés előtt (az event listenernek megfelelően) lefutnak. Ha jól vettem ki az egyik Ghostery fejlesztő kommentjéből (ami 3 hónapja volt) ellenőrzi a tracker listát és gondolom addig betöltődnek az oldalak, amiken így nem fut le a scanner.js
A Facebook blocker (az URL Filter API-t használó változat) viszont azonnal lefut, meg még egy csomó más is, szóval nem Opera hiba szerintem. Az Adblock-ban ha jól emlékszem van egy olyan checkbox, hogy késleltesse-e a betöltést, ezáltal gyorsabbá téve az Opera indítási idejét.
-
Penge_4
veterán
válasz Sk8erPeter #17184 üzenetére
"Ja, bár biztos hihetetlen sok idődet elveszi az, hogy 5 perc alatt megkeresed az elérhetőségeket, és küldesz egy levelet egy screenshottal az általad kedvelt játékoldal fejlesztőinek, hogy javítsák ezt a részt, mert Opera nem kedveli, hogy k×rvára nem tartják be a HTTPS-"szabályokat"."
Ez már amolyan tipikus magyar szokás, de nem akarok nagyon offolni. A lényeg, hogy a Szégyenfalunkon lévő oldalak közül azokhoz, ahol regisztráció szükséges, kétlem hogy szintén sokan írtak volna az emberek a fejlesztőknek, hogy javítsák. És azért lássuk be, hanyagság ide vagy oda, nagyon nem mindegy, hogy egy oldalon, ahol sok éve talán hozzá sem nyúltak a kódhoz 2-3 ember panaszkodik, akik közül az egyik tagja/rendszeres látogatója is az oldalnak a többi pedig csak lelkes Opera user, vagy minimum 20-30 ember panaszkodik rendszeresen, akiknek legalább a 80%-a tagja is az oldalnak. Na ezért van Magyarországon egy statisztikai szakadék az Opera felhasználók számában még a Kárpát-medence többi országához képest is. Mert máshol írnak és főleg azok írnak, akik valóban tagjai/látogatói az oldalnak, (nem csak azt hazudják), nem pedig csak sírnak és panaszkodnak, hogy még mindig nem javították azok a csúnya, gonosz, gondolatolvasó webfejlesztők. Pedig állítólag valamikor pár hónapja írt már nekik a Józsi is.
(#17186) silver star: "Persze írok a fejlesztőnek a nyelvtanfolyamomat meg te fizeted"
Your site is a great, amazing, wonderful, magical, excellent site, but your site's code is a piece of shit. Please fix it ASAP!
Ehhez nem kell nyelvtanfolyam. Ha az oldalt látogatod (a menüpontokat tehát ismered, navigálni is tudsz), annyi tudásod van, hogy egy ilyen mondatot összehozz.
(#17187) hunfatal: "valamint nincs böngészőbe csomagolva."
Épp erről jut eszembe, valamelyik nap uninstalláltam ismerősnél a Chrome-ot és ott volt az uninstall utáni survey-ben egy olyan válasz a miért uninstalláltam résznél, hogy nem akartam telepíteni, csak valamelyik szoftverrel felmászott.
Egy ideig gondolkoztam, hogy bepipáljam-e, mert lehet, hogy csak azért tették bele, hogy lássák, mennyire hatékony ez a típusú marketing és ez alapján még agresszívebben folytassák, de végül azért csak bepipáltam.
[ Szerkesztve ]
-
Penge_4
veterán
És ha még tudnád, hogy mennyi bug van a 12.50-ben. Jelenleg eléggé használhatatlan. A billentyűk még egy dolog, azokat lehet remappolni AutoHotkey-jel, de a rendszeres random omlások ellen nem lehet mit tenni.
(#17243) Ndruu: Nem vettek ki belőle semmit. Beírod a keresendő szót, teljesen mindegy, mivel hívod elő a keresőt, a következő lapon (akár már meg van nyitva, akár még ez után nyitod) nyomsz egy F3-at és máris keres ugyanarra, amit előzőleg beírtál az előző lapon.
Soha nem volt másképp, egy Ultimate Search Highlighter nevű userJS van régóta, az tud ilyesmit, meg még egy csomó hasznos dolgot, (beleértve a találatok számlálását, amit a Chrome is tud, csak az Opera nem), de mivel userJS és RegExp-et használ nagyon lassú és nagyobb oldalon megfagyasztja a böngészőt.
De keresés terén nem igazán jeleskedik az Opera. Chrome-mal betöltök egy több, mint 100000 vagy 1000000(!) fájlt tartalmazó FTP könyvtárat, majd rákeresek bármire, még ha olyan általános dolog is az, mint egy dátum évszám (amit egyidőben a dokumentum egészén mindenhol kijelöl) simán és gyorsan történik. Operában a fájllistát sem tölti be, lásd itt például. De teszteléshez bőven elég az is, ha a WHATWG Current Work oldalán indítunk 1-1 keresést mindkettővel. Az Opera nagyon le van maradva, ahhoz képest, hogy a 9.5-nél még milyen büszkék voltak rá, hogy hatalmas szöveges dokumentumokban sokkal gyorsabban keres, mint a többi böngésző.
-
Penge_4
veterán
12.50 Summer Core Update - durva changelog.
De kiemelnék pár lényeget. Először is a megvalósult álom:
DSK-167121 Poor visibility of search results in source viewer and text fieldsFőbb változások:
Performance work, bug fixes, improved standard support...
Removed the UI language and crypto strength token from the UA string (more info)
CORE-46791 Drop prefixes for CSS Transitions, Animations and Transforms (more info)
CORE-40054 URL filter API improvements (more info)
CORE-34226 Add Screenshot API (more info)
CORE-34077 Add Resource Loader API (more info)
CORE-39021 Add Page Visibility API
CORE-46424 Add ProgressEvent constructor
CORE-46593 New prefs - "First Update Delay" and "First Styled Update Delay" - to control repaint of pages
CORE-46258 <track> subtitles/captions for <video> (without UI)
CORE-37103 Update WebSocket implementation to rfc6455 (more info)
CORE-41400 Update to Unicode 6.1.0 specification
CORE-44859 Allow sites to enable x-domain window.onerror information (implement <script crossorigin>)
CORE-45552 Remove support for recognizing versions in JavaScript MIME types
CORE-46830 FileList spec compliance
CORE-46870 Drop Voice XML, CSS Speech, etc. support
CORE-45319 Change our implementation of the resolution media query to use CSS units
CORE-46645 Introduce support for the dppx unit
CORE-45517 Implement TypedArray slice()
CORE-40915 Support HTML5's isProtocolHandlerRegistered(), isContentHandlerRegistered(), unregisterProtocolHandler() and unregisterContentHandler() methodsÉs a korábbi ismert hibák nagy részét kijavították, mint:
DSK-370118 Closed tabs don't go to closed tabs history
DSK-370089 Tabs set to "No images" when upgrading from previous build
CORE-47649 Numpad shortcut keys do not work
DSK-369709 Pressing Enter to select entry from dropdown field doesn't work
DSK-369608 Shortcuts for creating private tab or private window creates 2 tabs or 2 windows
Numerous crash fixes not detailed below
DSK-366433 Opera crashes on Google searchUtóbbit sajnos elég sűrűn tapasztaltam. És pár hasznos teljesítményjavítás:
CORE-45432 Leaving page with many frames takes a long time (temporary freeze)
CORE-46884 Slow performance with CSS3 transitioned images
CORE-37129 High CPU/NSL on some sites (window.constructor is Object object)
CORE-45142 Speed up area traversing with positioned elements
CORE-45284 Freeze when border-left-width or border-right-width is zero
CORE-45383 Slower to parse a function with many integers than it used to be
CORE-44725 Implement assembler optimized versions of pixel handling bottle necksÉs ha a specifikációs oldalt jól értelmezem, kell lennie már performance.now()-nak is, mivel a Presto verziószám elég nagyot ugrott. Presto/2.12.362
-
Penge_4
veterán
válasz DeathAdder #17362 üzenetére
Pedig nem lassabb. A Chrome egyértelműen gyorsabb, de 10+ kiegészítő után már egyre lomhább az is. És még akkor sincs sehol se az Operához képest. Bár akinek csak weblap megjelenítőnek kell a böngésző. Ugyanúgy szövegíráshoz is van, ami MS Word-öt használ és van, akinek a Notepad is megfelel. Gépelni mindkettőben lehet.
A Firefox pedig az Opera 10.50 óta nem gyorsabb, mint az Opera weboldal betöltésben sem. Maximum webalkalmazásokban (Docs, Gmail, stb.), de azt tudjuk, hogy miért van.
A szubjektív mérések nem számítanak. Egy Adblock mellett nyilván gyorsabb lesz a Firefox, mint egy friss telepítésű Opera, ami a háttérben betölt vagy 50 képet és lefuttat 30 felesleges scriptet ugyanazon az oldalon.
-
Penge_4
veterán
válasz Sk8erPeter #17370 üzenetére
Viszont AutoStack kiegészítő már van.
-
Penge_4
veterán
-
Penge_4
veterán
válasz Sk8erPeter #17535 üzenetére
Engem személy szerint viszont jobban idegesít, hogy ezen az oldalon pedig az Opera szenved elég durva hátrányt a többivel szemben, ráadásul ha nyomsz egy Ctrl+F-et betöltődés után, Opera alatt durva fáziskésések vannak, míg Chrome-ban szinte azonnal keres.
Mert többször futok bele baromi hosszú, nagy terjedelmű oldalakba (főleg például AutoPatchWork mellett), amit az Opera nehézkesebben kezel. Pláne mikor keresnék is rajta.
-
Penge_4
veterán
válasz Sk8erPeter #17553 üzenetére
"vagy letöltök valami óriási fájlt, és beakad a GUI ("Not responding"), az a halálom)"
Vírusirtót ellenőrizd. Szükség esetén cseréld le, vagy tedd kivétellistára az opera.exe-t.
-
Penge_4
veterán
Azért választották, mert egyrészt a 64 bit egy opció, nincs rá senki kötelezve, tehát mindenki eldöntheti, hogy nála van-e annyira problémás az OOPP, hogy ezért lemondjon a 64 bitről.
Másrészt 64 biten nincs más lehetőség arra, hogy 32 bites beépülőket futtassunk és vannak, akiknél nem áll meg az élet Flash-nél és Java-nál, hanem mondjuk használ DivX-et, DejaVU-t, vagy ne menjünk olyan messzire: Silverlight-ot.
-
Penge_4
veterán
Ilyen nálam is volt pár alkalommal, általában plugin-wrapper összeomlás vagy Nvidia driver összeomlás előzte meg (utóbbi után úgyis mindig restartolni kellett az Operát, ha a HWA be volt kapcsolva, mert megszűnt az ablak tartalmának renderelése), de az Opera újraindítás mindig megoldotta.
[ Szerkesztve ]
-
Penge_4
veterán
válasz Sk8erPeter #17659 üzenetére
"Egyszerűen képtelen vagyok megérteni, az Opera miért képtelen beépíteni már végre a sokak által elvárt autocomplete-funkciót az űrlapokhoz.
Van erre vonatkozóan bármi információ/haladás?"Konkrétan erre vonatkozóan nincs, de a semmihez képest pozitív hírekkel szolgálhatok. You sounded off, and your top 3 problems with Opera are...
Ez a rész különösen tetszik amúgy.
I think the main conclusion from my point of view is that the overall themes of the feedback are things we are already aware of, and actively working on. One might say that the feedback confirms many of the things we already know.
That is not to say that it was not a useful round of feedback. Feedback which supports existing conclusions is also useful because it shows that the current view of the situation is correct.
Haavard 4 president!
dqdb!
A korábban írt userJS-ed a PH-s bbcode-okhoz a legújabb 12.10-es snapshotban már nem működik, viszont a hibát továbbra sem javították, mert a userJS-t kiszedve is össze-vissza pakolja a BBCode-okat. Ránéznél, ha lesz időd?[ Szerkesztve ]
-
Penge_4
veterán
Use Opera's Forms Manager to Save Time
De azért van humorérzékük. Utána nem sokkal megjelenik egy olyan post, hogy Help Opera improve its products and services
A slusszpoén, hogy a kérdőív 3. oldalán 404-es hibát dob.
[ Szerkesztve ]
Új hozzászólás Aktív témák
Hirdetés
Kérdés előtt olvasd el az
összefoglalót!
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen