-
Fototrend
Új hozzászólás Aktív témák
-
#41133696
törölt tag
válasz
HZoli87
#16798
üzenetére
Köszi
Azért kérdeztem, mert itt nem írja, vagy én nem látom
, hogy az IE-től eltérő verzió, ami beépül Firefox, Safari és Opera alá az 64-bites is lenne.NIS azt mondja a Flash-re átlagos használat mellett egyszer egy héten megborul és instabil

Ami az Opera 12.00-t illeti túl sokan még nem használjuk a Norton táborból
Ja tudom, hogy a 64-bites nem támogatja, de azért felteszem szerintem

-
-
dqdb
nagyúr
válasz
Sk8erPeter
#16785
üzenetére
Én eddig konzolról szarakodtam mklink-kel.
Szerintem a Sysinternals (most már Microsoft) féle junction.exe az igazi
Én úgy oldottam meg, hogy egy mappába összegyűjtöttem egy rakás batch fájlt, ami létrehozza a junctionöket a megfelelő programokhoz. Már évekkel ezelőtt meguntam, hogy egyes programokat lehetetlen az alapértelmezett helyükön kívül máshová telepíteni (nem lehet állítani, hiába állítom át, nem működik máshol, teleszemetel más mappákat a C: meghajtón, ...), ezért pár kinevezett darabot helyből átirányítok.Apropó, nem az XP-ben, hanem már a Windows 2000-ben bevezették ezt a feature-t, akkor került pár igen hasznos módosítás az NTFS-be (sparse files, tömörített fájlok).
Dropbox, Google Drive, SkyDrive is tudtommal kernelszinten beépülnek
Nem kell kernel szintre lemenni, sőt FSD filter (file system filter, a vírusirtók itt is beépülnek az összes fájlművelet monitorozására) sem kell, vagy szimplán végignézik a lokális fájlokat, vagy a Windows által tálcán kínált megoldásra építenek. Bár minden ilyen véleményemhez disclaimer gyanánt hozzáteszem, hogy én legalábbis így csinálnám meg
-
Sk8erPeter
nagyúr
válasz
Penge_4
#16780
üzenetére
"Ezért vannak kedvencek a Windows Explorerben és tabok a Total Commanderben."
Most itt nem tudom, milyen kedvencekre gondolsz, én Library-ket szoktam használni, ami alá akár több könyvtár is rendelhető, és az ebben található könyvtárak fizikai helye ugyanott marad."Az már a szinkronizáló szoftver hiányossága, ha nem lehet egyenként betallózni a szinkronizálandó könyvtárakat."
Nyilván megvan az oka. A Dropbox, Google Drive, SkyDrive is tudtommal kernelszinten beépülnek (egyfajta "modulként", hogy pongyolán fogalmazzak), de pontosan nem ismerem a működésüket, hülyeségeket nem akarok beszélni, de nyilván nem annyira egyszerű, hogy viszonylag erőforrás-takarékosan, idle-ben lehessen szinkronizálni a könyvtárakat, és minden szirszart be lehessen dobálni.
De ha tudsz jobb megoldást, ne tartsd magadban.
Azért nyilván egyik sem egy szar...A titkosítós parádról itt egy topic, ami érdekelhet: http://hup.hu/node/115335, hátha hasznos.
Egyébként én csak amiatt paráznék, ha szenzitív adatot töltenék fel, nyilván egy Opera-beállítás esetén kb. leszarom, ki szerzi meg, ha annyira akarja.
De azért ezek nem kispistike által törhető rendszerek...Most látom, brd már elmondta a directory junction lényegét.
A "kompatibilitás" szempont alatt meg számomra nem egészen világos, mire gondolsz, az OS megoldja a symbolic link/hardlink problémát, nekem nem kell foglalkoznom vele, ahogy egyik alkalmazás írójának sem, itt csak fájlrendszerbeli szervezési dolgokról van szó, amit az operációs rendszer megold helyetted.
========
(#16784) brd:
"Egyébként ehhez a linkelgetősdihez szerintem ez egy nélkülözhetetlen cucc"
Jaja, pont a héten kezdtem el csak használni, erre pont témába vág a dolog.
Elég durván részletes dokumentációt írtak hozzá.
Én eddig konzolról szarakodtam mklink-kel. -
brd
nagyúr
válasz
Penge_4
#16780
üzenetére
Directory junction: Nem Vista+ only, már XP-ben is volt. Úgy működik, hogy létrehoz a cél oldalon egy virtuális könyvtárat (=linket, tehát nem másol semmit sehová), ami a forrásra mutat, és ez az összes program számára teljesen transzparens (még pl. akár a windowsos userprofile-t is megcsinálhatod így), mert a filerendszer szintjén működik, és azt hiszik, hogy nem virtuális könyvtárba írnak. Pl. a D:\teszt könyvtárat átlinkeled a C:\ alá, ekkor lesz a C:\-n is egy teszt könyvtár, és minden számára úgy fog látszódni, hogy a C:\-n van ilyen (valós) könyvtár, de a műveletek a D:\teszt-en hajtódnak végre. Ami XP-ben (useroldalon) nincs, az a symlink, de ha kellene, az is megoldható, az alább linkelt oldalról letölthető driverrel.
Egyébként ehhez a linkelgetősdihez szerintem ez egy nélkülözhetetlen cucc'. -
slashing
senior tag
annél speciel nekem sincs gondom...
időközben elkezdtem kikapcsolni egyesével a kiegészítőket (13 van) és a ghostery a ludas de nem tiszta hogy miért és miért csak a blog.hu-s oldalaknál, aminél most tapasztaltam annál a ghostery 6 dolgot blokkol ami önmagában még nem kéne hogy processzor terhelést eredményezzen...
-
AtHoS
nagyúr
válasz
slashing
#16781
üzenetére
Nálam a magyaropera.blog.hu szépen működik, procihasználat további 40..60 megnyitott füllel is 1..4% környékén mozog.
i52500k - 11.64b1403 + Win7 HP x64
-
slashing
senior tag
Nálatok a ****.blog.hu oldalak többsége nem zabálja jobban a procit operában mint más böngészőben? Nagyon régóta használok operát és volt gépváltás és op.rendszer váltás ami után ugyan úgy fenn áll nálam ez a probléma. Ha csak simán böngészek néhány 1-3% szokott lenni a proci a legtöbb blog.hu-s oldalán meg hozzádob 25%-ot minimum, még az sem számít hogy hány komment van... mitől van ez vajon? Mondom több gépen más más oprendszerrel is tapasztaltam és tapasztalom nap mint nap.
-
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.
-
Sk8erPeter
nagyúr
válasz
Penge_4
#16778
üzenetére
"főleg mivel minden szar mindig ezt ajánlotta fel defaultnak, aztán meguntam és átindexeltem"
Jaja, igazából én is emiatt jöttem rá idővel, hogy mennyivel egyszerűbb lenne, ha engedném is, hogy a default Documents könyvtárba mentsen, de akkor már a Documents legyen jó helyen.Én sem vagyok egy újratelepítgetős, inkább próbálom karbantartani a rendszeremet, de ez nem változtat rajta, hogy a user-specifikus dolgaimat jobb' szeretem normális helyen tartani, már csak azért is, mert ha valamit be akarok állítgatni, változtatni szeretnék mondjuk valami ini-fájl tartalmán (lásd Operás cuccok), 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.

Meg nemcsak az az előnye, hogy nem kell hatmillió alkönyvtárba belelépni, hogy elérjek a célomig, hanem számomra logikusabb elnevezésű könyvtárakba tudom pakolni a beállításokat; 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 (később is meglegyen, ne kelljen feltétlenül lementeni, vagy épp legyen róla biztonsági tartalék jó helyen [értsd: nem valószínű, hogy ezek a fiókjaim csak úgy elszállnak; persze jó esetben biztonsági tartalék még egy másik háttértáron is van]), ergo a Dropbox/Google Drive/SkyDrive könyvtárához vagyok kötve.No, de mondom, igazából ezt a problémát áthidalhatja egy directory junction.
-
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.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#16776
üzenetére
Hehh, ez jó, most látom, Tamil ugyanazzal az ötlettel állt elő erre a problémára, mint amit én is említettem az utolsó bekezdésben: [link].
-
Sk8erPeter
nagyúr
válasz
Penge_4
#16775
üzenetére
Igazából már a kérdést sem értem, hogy miért lenne ez nekem jó.
Nem találkoztál még azzal az esettel, hogy újra akarod telepíteni az operációs rendszeredet, és minden lószart backupolni kell, de lehetőleg csak azt akarod backupolni, amit nagyon kell (nyilván nem akarod a teljes Roaming könyvtárat és a többit is kimásolgatni, mert mi a szarnak), és esetleg valamilyen könyvtárról megfeledkeztél, ami a hatmilliomodik alkönyvtárban van a rendszerpartíción (lásd "c:\Users\Peter\AppData\Roaming\Opera\Opera\"), vagy csak utáltad, hogy mennyire macerás, ahelyett, hogy szépen struktrurálva, saját igényeid szerint legyenek a megfelelő helyen, vagyis egy másik, adatok számára fenntartott partíción ezek a könyvtárak?"amennyiben nem formázod le a telepítőlemezzel a partíciót"
Az ilyen inkrementális jellegű mellé/föléírogatásokat nem szeretem, miért is ne formázhatnám egy újratelepítéskor. Így megvan az az érzés, hogy tiszta lappal indulok. A háttértár számára is szabaddá válnak a logikai címek a háttértáron. Innentől ízlése szerint felülírogathat bármit az adott partíción.
Biztonság kedvéért van, hogy fontosabb könyvtárakat egyszerűen átmásolok másik partícióra, ha sokáig tart, otthagyom, hadd menjen, aztán mehet a reinstall egy formázással megspékelve.Ugyanígy első dolgom pl. átmozgatni az adatpartíciómra (nevezzük D:-nek) a Windows beépített Documents, Music, stb. könyvtárát (aztán esetleg tetszés szerint átnevezni) és az összes többit is (ezt már XP-től kezdve így csinálom), így eleve oda lesznek mentegetve a fájlok, ergo nem kell foglalkoznom vele újratelepítésnél, hogy ezeket mentsem, mivel az adatpartícióm érintetlenül marad.
Az újratelepítést követően meg legfeljebb csak az elérési utakat kell átállítgatnom, de nem kell attól tartanom, hogy hoppá, valamit elfelejtettem, na, kerítsünk elő egy adatvisszaszerző progit, és nézzük meg, van-e még esély rá, hogy vissza lehet állítani az adatot.Röviden összefoglalva: a felhasználó-specifikus, számomra fontos adataimat igyekszem normálisan strukturáltan, normális útvonalon elérhető helyen, másik partíción, a rendszertől szeparáltan tartani.
Ezzel most újdonságot mondtam?
Viszont közben eszembe jutott egy lehetséges kerülő megoldás, ami lehet, hogy nem a legszebb, de működőképes lehet, és nem kell figyelnem arra, hogy minden egyes helyen átállítgassam az elérési utakat: symbolic link vagy directory junction az említett, rendszerpartíción lévő könyvtár(ak)ra.
-
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.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#16772
üzenetére
opera:config#UserPrefs|OperaDirectory
Ezt állítsam át a nekem tetsző helyre, azt' jóva'?
Ma úgy látszik, láma napom van.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#16772
üzenetére
Látszik, nem vagyok még Power User az Operában, még csak most kezdett el igazán érdekelni, hogy is tudok minden szirszart felülbírálni.

-
Sk8erPeter
nagyúr
válasz
Penge_4
#16771
üzenetére
Igazad lehet, most kipróbáltam egy nagyon minimális skin.ini-vel, és okoz egy olyan minimális megjelenítésbeli "problémát" is, hogy a felső címsor úgymond külön sávot kap, nincs "egybetolva":
http://i.imgur.com/MP5XD.png
- nem úgy, mint a korábbi változatnál,
amikor ennyit rakok bele:# This file describes the skin for the Opera browser
[Info]
Name=Pete - Some small modifications
Author=Pete
Version=3
Preview Image=
[Colors]
Highlighted Text=#ff7f27
Highlighted Text Unfocused=#99d9ea
Skin=#f0f0f0
Edit Background=#b97a57
Selected Text=#ffaec9
Selected Background Unfocused=#ed1c24
Selected Text Unfocused=#81e0a7Viszont más parát most hirtelen nem veszek észre.
Ez a felső címsoros para vajon konkrétan melyik sor hiányától lehet azok közül, amiket említettél?
Ez azért lehet csak érdekes, mert akkor lehet, hogy tényleg még jobban lehetne minimalizálni a skin.ini-t.
Próbáltam a
Window Border Inset = 2
beállítást, újratöltésnél ez sem oldja meg.
Na mindegy, akkor marad az, hogy bemásolom, amiket írtál.Ja, amúgy a Name String Code pl. úgy látom, nem kötelező, legalábbis nincs benne minden skinben, ez mire kell?
Viszont akkor úgy néz ki, nem jövünk rá, vajon mi a francért sikerülhetett korábban megváltoztatni a kijelölés színét a forráskódban.
Örök rejtély borítja ezt majd homályba?
Kár, hogy egy kissé ezen a területen kiszámíthatatlan az Opera.======
Szerk.:"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."
Úgy látszik, kezdek fáradni, már képzavarban vagyok.
c:\Users\Peter\AppData\Roaming\Opera\Opera\
Van egy ilyen könyvtáram, defaultból.
Na most akkor én nyilván nem ide akarok írni, mert okádék az elérési út, plusz ezt bukom egy Win-újrahúzásnál.
Akkor most hogy is mozgatom tetszőleges helyre úgy, ahogy van?
Gondolom nem egyenként kell beállítgatni a skin könyvtárat, stb... Mert elvileg opera:configban arra is lenne mód. -
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.
-
Sk8erPeter
nagyúr
válasz
Penge_4
#16769
üzenetére
Kösz, majd végigpróbálgatom, melyik jut érvényre, ha lesz időm.
De már kezdem kicsit hülyén érezni magam, mert nálam hiába nyomok reload skint, hiába van az operaprefs.ini-ben már libafostól kezdve mindenféle szín, akkor sem hajlandó újból beállítódni az a nyomorék szín a keresésnél a textarea-ban. Fingom sincs, hogy amikor jól csináltam kétszer is, akkor mit csináltam másként. Tudtommal akkor is csak megpróbáltam azt, hogy beállítottam újból, elmentettem, nyomattam egy reload skint, aztán ha nem ment, újraindítottam, újrapróbálkoztam. Na most minden kombinációt végigjátszottam, és b@szik rá.
Pedig már teljesen skint is váltottam, meg a Button Set is tök más elérési útra van már állítva, és megnéztem az újban lévő skin.ini nem bírálja felül az operaprefs.ini fájlnak az ezekre a színekre vonatkozó beállításait..Most ez szerepel nálam az operaprefs.ini-ben:
[Colors]
Highlighted Text=#ff7f27
Highlighted Text Unfocused=#99d9ea
Skin=#f0f0f0
Edit Background=#b97a57
Selected Text=#ffaec9
Selected Background Unfocused=#ed1c24
Selected Text Unfocused=#81e0a7Ha esetleg van időd, akkor majd próbáld már ki légyszi, neked sikerül-e normálisan beállítani, kíváncsi lennék, mit b@szok el.
Egyébként olyat még csak ne is merészeljek elképzelni, hogy esetleg a 12-es bétában már történt valami javulás a skinek terén, tehát hogy nincs szükség ilyen reload baromságokra?
Ja, még egy kérdés: a button setnek létrehozhatok akár egy tök csupasz, egyetlen skin.ini fájlt tartalmazó tömörített állományt is (zip), aminek megadom a path-ját a button setre vonatkozó beállításban, és a skin.ini-ben csakis azokat a beállításokat bírálom felül, amiket változtatni szeretnék?
Tehát itt a skin.ini-nél is érvényes az az ökölszabály, mint a standard_menu.zip-nél, hogy csak azt a bejegyzést kell beletenni az ini-fájlba, amit felül szeretnék bírálni? Az lenne a logikus, ha így lenne, de gondoltam előtte megkérdezem.Amúgy kösz, hogy türelemmel végigolvasod a szenvedéseimet!

-
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.
-
Sk8erPeter
nagyúr
válasz
fatal`
#16767
üzenetére
Mondjuk az elég ratyi megoldás, ha valóban úgy van, ahelyett, hogy így "cache-elve" lenne. De egyébként nyilván egy egyszerű tömb nem lenne elég, mert tárolni kellene a találatok pozícióit is, de asszem ez nem kéne, hogy gondot okozzon egy normális programozónak. Az lenne az első, ami eszembe jutna, hogy ameddig a keresőmező egyáltalán nyitva van, és a karaktereken nem változtattunk, addig tárolom a találatokat a memóriában. Aztán ha újabb keresést indít a felhasználó, akkor persze az újabb találatokat kell tárolni (az előző kukázható).
-
fatal`
titán
válasz
Sk8erPeter
#16764
üzenetére
Feltéve, hogy tömbben tárolják a találatokat. Szerintem éppen attól ilyen lassú az egész egy hosszú oldalon, mert nincs letárolva, hanem ha beírsz egy szöveget akkor végignézi a kurzorpozíciótól az egész szöveget.
-
Sk8erPeter
nagyúr
válasz
Penge_4
#16765
üzenetére
Azért ez már szinte sértésszámba megy, hogy elmagyarázod, hogyan update-eljem egy csomagolt állományban lévő fájl tartalmát.

Beállítottam, mégis lefosta, újraindítottam, aztán megnéztem, és láttam, hogy az operaprefs.ini-be érthetetlen módon más skin elérési útja került be, pedig korábban itt jót állítottam be:
opera:config#UserPrefs|ButtonSetNa mindegy, legyen, beállítottam még egyszer, újraindításkor végre hajlandó volt módosítani a jó elérési útra, meg is nyomtam a Ctrl+Shift+Alt+B (ne kérdezd, miért ezt állítottam be - gondoltam ez tuti nem foglalt, és véletlenül nem fogom megnyomni) kombót, ekkor végre kaptam már az arcomba egy üzit:
http://i.imgur.com/bAs9T.png
"Unable to continue. Please select a skin made for your version of Opera."Na végre, ebből már legalább ki tudok indulni. Úgy látszik, már kissé régóta görgetem magam előtt ezt a skin-verziót, és a sok update után már inkompatibilis.
VISZONT most megint működik jól a narancssárga kijelölés, most ezt már tényleg nem vágom.
Akkor most ez azért van, mert nyomtam egy "Reload skin"-t, és ettől érvényre jutottak az operaprefs.ini beállításai?Most akkor beállítok egy gyári skint, annak lemásolom a standard_skin.zip-jét, és akkor nem fog sírni inkompatibilitásra.
De ezt írtad:
"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)."
Most akkó' mi va'?Na jó, megnéztem operaprefs.ini-ben végre, ott ezt látom:
[Colors]
Highlighted Text=#ff7f27
Highlighted Text Unfocused=#99d9ea
Skin=#f0f0f0
Edit Background=#b97a57
Selected Text=#ffaec9
Selected Background Unfocused=#ed1c24Na most akkor a
Selected Text bgcolor nofocus = #FF9632
a skin.ini-ben minek kell egyáltalán?
Meg amúgy ez a bgcolor nofocus "toldás" ez biztos, hogy "valid" így?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?
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?Bocs, de én már teljesen belezavarodtam.

-
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.
-
Sk8erPeter
nagyúr
válasz
Penge_4
#16763
üzenetére
Jaja, az ékezetérzékenység is tényleg nagyon jól jön sok esetben (és tényleg lehetne opcionális, pl. csak a keresőmező melletti checkbox-szal).
Tényleg, most, hogy mondod, még találatszámláló sincs Operában... pedig ennek az implementálása aztán rendkívül nehéz, lekérik a tömb hosszát, és kész... (újabb érthetetlen hiánya a megvalósításnak, ami nagyjából minimális dizájnváltoztatást és plusz pár sort igényelne)Ez a "Not Responding" üzenet meg már megint csak megfelelő szálkezelési probléma lenne...
"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."
Azt a qrva
Azért ez kemény.
Ezek szerint akkor az a narancssárga szín mégis a skin.ini-ben történt változtatás hatása volt?
Tehát a
Selected Text bgcolor nofocus = #FF9632
miatt?
Itt egyébként a nofocus "paramétert" nem vágom. Miért épp a nofocus a jó?
Viszont most már azt sem vágom, akkor hogy sikerült legutóbb.
Mi a skin refresh módja? -
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.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#16761
üzenetére
Komolyan mondom, megőrülök ettől.
Újraindítottam az Operát, és megint nem jó, pedig megnéztem, a beállításaim ugyanazok (a Selected Textnél még ilyen buzirózsaszínt is beállítottam korábban kínomban, hogy kipróbáljam, az hol is látszik, az érdekesebb Highlighted Text meg még mindig narancssárga):
http://i.imgur.com/FG1TY.pngDe már megint pontosan ugyanolyan a textarea-knál a keresés:
http://i.imgur.com/2apJf.pngElő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?
-
Sk8erPeter
nagyúr
válasz
cousin333
#16757
üzenetére
Kösz, ez nekem új volt, eddig erre nem kerestem, de az a gáz, hogy hiába változtatgatok itt akármit, a <textarea>-kon belül egyszerűen nem hajlandó más színnel keresgélni.
A változtatások egy újraindítás után érvényre jutnak a normál szövegben való keresésnél, de formelemben, tehát szövegmezőben szarik rá. Ja, amúgy nem is kéne újraindítani? Hogy van ez a reload skin?
Nagyon tudnám ütni azt, aki ezt kitalálta. Abszolút semmi logika nincs benne. Ez Chrome-ban teljesen értelmesen van megoldva.Csak úgy kontrasztként, Chrome-ban a korábbi keresés, Prohardver forráskódjában a "javascript" szóra:
http://i.imgur.com/xFPCn.png
Aki itt nem szúrja ki a szót, az vaksi.
Chrome-ban mondjuk a forráskód-nézet nem textarea. De érdekes módon Chrome-ban a textarea-ban történő keresést is meg tudták oldani értelmesen - PH!, új hozzászólás:
http://i.imgur.com/oKpwf.png
Jól látható az aktuálisan kijelölt elem, meg a többi találat is.
Ehhez annyira nagy ész kell, hogy valaki ilyen szín-összeválogatásban oldja meg?SZERK:
Bocs, az összes korábbi pampogásomat visszavonom, mégis látszik! Úgy látszik, előbb még nem jutott érvényre.
Az általad mutatott beállítások között egész pontosan a "Highlighted Text" beállítás volt a nyerő:
opera:config#Colors|HighlightedText
Átállítottam narancssárgára:
Így már látható:
VÉGRE!!!

Ettől függetlenül hülyeség, hogy a fehér az alapbeállítás

Meg az sem lenne rossz, ha a Chrome-hoz hasonlóan a többi találat is egyből látszana, így nem kéne a találatokat végignyomkodni, ha nem szúrja ki rögtön az ember.Köszi, cousin333!

-
Sk8erPeter
nagyúr
válasz
cousin333
#16756
üzenetére
Na basszus, nem voltam egyértelmű, igazából a lényeget felejtettem el mondani.
A legfőbb probléma akkor van, ha egy szövegmezőben keresek (<textarea>).
Mivel maga a Source nézet is egy szövegmező, épp azért, mert módosítani is lehet a forráskódot, ezért ott is jelentkezik ez a gond.Legdurvább példa:
csak kísérletként írjátok be például egy szövegmezőbe a tipikus lorem ipsum szöveget:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque aliquam pharetra nisi, ac euismod eros malesuada at. In elementum commodo ligula et congue. Donec tincidunt purus a diam vehicula sit amet sollicitudin dolor elementum. Morbi sed erat id massa venenatis euismod vel id tortor. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Nunc eget eleifend libero. Etiam id tortor elit, eu facilisis tortor. Vivamus in adipiscing diam. Ut hendrerit, leo luctus convallis tempus, dolor odio porttitor mi, in vestibulum diam urna quis eros. Cras enim sapien, dapibus viverra vulputate sed, malesuada vitae mauris. Nulla felis nunc, sollicitudin non scelerisque a, eleifend eu tellus.Keressetek rá mondjuk az "ipsum" szóra:
Prohardver, új hozzászólás írása
Látja itt egyáltalán bárki, hogy az "ipsum" elvileg ki van jelölve?Egy fokkal jobb a helyzet mondjuk a Drupal Answers szövegmezőjében:
Drupal Answers, új hozzászólás írása
Itt már legalább látszik, hogy a szövegmezőben is ki van jelölve... De egy forráskódnál ezt kiszúrni mérhetetlen idegesítő.
Nem tudom, ki lehetett az a degenerált elmebeteg, aki ezt a színkombinációt kitalálta.
Ez az Operában alapskin.De vegyük akkor már a forráskódot, pl. Prohardver forráskódjában rákeresek a "javascript" szóra:
Prohardver, Source nézet
Ezen kiszúrni nem kis erőfeszítést igényel.Na, ezen szeretnék változtatni, hogy a szövegmezőben való kijelölés színe valami nagyon feltűnő legyen.
-
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.
-
cousin333
addikt
válasz
Sk8erPeter
#16755
üzenetére
Na, közben csak megtaláltam:
opera:config#Highlighted
Ha ezt írod be, akkor keresni fog, tehát négy beállítási találatot is kapsz. Itt beállíthatod a hátteret és a betűszínt is, külön az aktív és a többi találatra.
Nagyon jó ez a linkelhető opera:config (sajnos itt a PH-n már nem megy), csak néha kicsit nehéz eltalálni a megfelelő keresőszót.
-
cousin333
addikt
válasz
Sk8erPeter
#16753
üzenetére
Ez régen mintha benne lett volna a beállítások között, de most nem találtam. Mindenesetre nálam elsötétíti, a találatokat sárgával, az aktuálisat zölddel jelzi. A színeket nem tudom, hol kell állítani, de a sötétítésen lehet tekerni, méghozzá itt:
opera:config#UserPrefs|DimSearchOpacity
Azt hittem, százalékos, de úgy tűnik, nem az. Én feltoltam 200-ra (minél nagyobb, annál sötétebb), és így ezt kaptam:
Szerintem elég feltűnő lett...

mod: Forráskódban viszont nem működik

-
Sk8erPeter
nagyúr
Hmm, megörültem, de nekem sajnos nem jött be.

Pedig azt a skin.ini-t módosítottam, ami az
opera:config#UserPrefs|ButtonSet
elérési út alatt található.
A [Generic] részbe beraktam ezt:Selected Text bgcolor nofocus = #FF9632
Próbáltam a Source-ban való keresgélést is, ugyanaz a szitu.
(Természetesen a becsomagolt változatban lévő skin.ini-t felülírtam.)
Nálatok? -
válasz
Sk8erPeter
#16753
üzenetére
Ezt találtam. Még nem próbáltam, de ki fogom, mert a textboxban (pl. hozzászólás írásnál) és a forráskódban alig látszik a keresési találat.
-
Sk8erPeter
nagyúr
Még ilyenekkel sosem szórakoztam, azt hol lehet megváltoztatni, hogy amikor mondjuk adott oldalon keresgélek Ctrl+F-fel, akkor a megtalált szó kijelölése milyen színű legyen? Amikor elkezdek keresni, akkor megjelenik egy fekete átlátszó vászonszerűség, de a megtalált szó kijelölésének színe annyira nem tér el, hogy alig tudom kibogarászni, hogy hol is van a megtalált szó. Chrome-ban pl. ez a kijelölés pl. narancssárga, na az elég feltűnő.
Köszi! -
Sk8erPeter
nagyúr
A HDD vs. SSD téma kapcsán mondjuk - az igaz, hogy nem tettem hozzá - én elsősorban természetesen a háttértáron való kotorászásban tapasztalható különbségekre gondoltam, amihez a CPU-intenzív feladatoknak és memóriában történő adat-előkotrásnak tényleg nem sok köze van. Így utólag elolvasva emiatt tényleg sántít a hozzászólásom, f@szság volt ezt így összekeverni.

Kicsit normálisabban megfogalmazva: a tipikus előnyök - feltételezem - pl. program-betöltés során és gyorsítótárból való előkaparás során tapasztalhatóak, ami mondjuk - ha az SSD-n van a gyorsítótár, amit mondjuk sokszor az elhasználódás miatti túlparázás (nyilván rendkívül sokaknál fordult elő, hogy egy mostanság vett SSD a rajta lévő gyorsítótár, temp. és egyebek miatt egyszer csak bemondta az unalmast) miatt áthelyeznek inkább HDD-re - gondolom nem minden esetben elhanyagolható.
Ja, de most olvastam el még egyszer a hsz.-edet, lényegében te is ezt mondtad.
(ez egy ilyen nap)Egyébként szerintem a 64 bites változat lehetséges előnyeiről való elmélkedés során egyikünk sem azt hangsúlyozta, hogy ez milyen rohadtul fontos lenne, ha már elkészülne, csak arról vakerásztunk, vajon miért is lehet az nekünk jó, ha 64 bites a böngészőnk. Hogy egyáltalán a gyakorlatban hol jönne elő a böngészés során a 64 bites előnye. Ez még azóta is nyitott kérdés, mert egyértelmű válaszunk még nincs, ezért beszélünk róla.
Engem speciel érdekel, hogy egy böngészőben mitől lenne jó.
Nyilván ezernyi más hiba/javítandó feature/megjelenítésbeli probléma/esetleges új funkció/bármi egyéb van, amit előbb jó lenne megoldani az Operában, ahelyett, hogy arra recskáznánk, hogy nekünk márpedig 64 bites brózerünk van, ebben tökéletesen egyetértünk.
Én pl. első körben tényleg örülnék, ha azt a nyomorék szar webfejlesztő panelt (Dragonfly) kicsit csiszolgatnák, engednék abból több példány megnyitását, valamint még a kiegészítőkhöz tartozó API-t egy kicsit normálisabban használhatóvá tennék. Az extension API tekintetében pl. a Chrome tényleg fasza, próbálgattam már a képességeit, és aki kicsit vágja a JavaScriptet, könnyen tud írni benne egész tűrhető kiegészítőket. Az Opera esetén meg csak ilyen "jajj-ne-már"-érzésem van sokszor, ezt ntomkával is beszéltük már, aki készítette a Prohardver! Eszközök extensiont Chrome-ra, már kifejtette, hogy nem véletlen, hogy még nem készült el az Opera-változat, pedig már belekezdett.
====
(#16751) draco31: OK.

Majd én is kipróbálom! -
draco31
veterán
válasz
Sk8erPeter
#16745
üzenetére
VideoCacheView-2.21 nevű programmal sikerült megoldani.
-
brd
nagyúr
válasz
Sk8erPeter
#16749
üzenetére
Igazából nem konkrétan neked szólt a kérdés, bocs', ha így jött le. Csak pl. Penge is úgy írja, hogy milyen k*va fontos lenne, pedig l*szt, ezer más dolog van, ami ráadásul érdemben javítana rajta.
Az SSD-nek ehhez semmi, de semmi köze, a CPU-n (és a ma divatos, egy kicsit innen-egy kicsit onnan másolok, ill. a programnyelvbe beépített objektumokat használom-féle, erőforrászabáló programozáson) nem gyorsít. Opera esetén gyorsítani az olvasott/írt cache darabokon tud, máson nem nagyon, mert az mást nem nagyon (minimálisat) forgalmaz a háttértár felé, ha már egyszer elindult. Egyébként Opera esetén baromira észrevehetetlen, hogy HDD, vagy SSD van alatta (bekapcsolt cache mellett is), néha, amikor tabot váltottam, akkor HDD esetén volt egy fél-1 másodperces darálás (ez mondjuk a pagefile idióta használata miatt is lehetett), de ennyi. -
Sk8erPeter
nagyúr
Hát ez tény, hogy nem ez lenne a legfontosabb probléma az Opera esetén...
Félreértesz, én nem "rugózom" a kérdésen, egyszerűen az ELMÉLETI lehetőségeket próbálgatjuk vázolni Pengével, hogy milyen lehetőségek merülhetnének fel a gyorsulásra, tehát ha a lehetőségek adottak, akkor a 64 bitesből milyen pluszt lehetne kihozni a 32 biteshez képest.
De könyörgöm, Te magad állítottad, hogy SSD-t használsz, így nyilván rohadtul nem érdekel, hogy vajon a 64 bitestől várhatsz-e minimális mértékű gyorsulást... Léteznek azért még olyan emberek is, akik nem kapcsolták ki a cache-t teljes mértékben (mondván, hogy felesleges), plusz akinek egy mezei HDD-je van. Nálad SSD birtokában valószínűleg nagyjából minden gyorsabb. Persze erről Te jobban be tudnál számolni. -
brd
nagyúr
válasz
Sk8erPeter
#16742
üzenetére
Azzal is egyetértek, hogy sokan már-már divatból mondják azt, hogy "ugyan már, semmi haszna a 64 bites változatnak, hacsak nincs több mint 4 GB RAM-od", pedig ez nem igaz, így valószínű, hogy nem tudják, miről beszélnek, vagy képzavarban vannak. Persze az igaz, hogy elképzelhető, hogy a gyakorlatban nem érzékelik a különbséget.
Én sem látom, hogy egy amúgy is gyors (talán a leggyorsabb jelenleg) böngészőnél jelenleg mi előnye van (lenne), valaki lécci' mondja már el, mert nem értem, minek ezen rugózni. Annyi "más", javítandó bug/feature-nek hívott hiányosság van benne...

-
fatal`
titán
válasz
Sk8erPeter
#16746
üzenetére
Az RC előtti build, verziószámot most hírtelen nem tudok (1441, 1445 közül valamelyik). A korábbiakkal még jó volt (és a tegnapi RCvel is).
Szerk.: Nextről volt szó.
(#16748) brd: Én is így látom. Maximum benchmarkkal mérhető sebességnövekedés lesz. De a különböző hackek (32 bites pluginok stb.) miatt végeredményben akár még lassab is lehet.
A 64 bites IE remek példa, lassabb a JS, mint a 32 bitesben.
-
Sk8erPeter
nagyúr
válasz
draco31
#16732
üzenetére
Sok videó letöltéséhez itt találhatsz online video-letöltő szolgáltatást:
http://deturl.com/Ami nekem bevált olyan oldalaknál, ahol amiről nehezebb volt leszedni a streamelt tartalmakat:
http://www.streamtransport.com/ -
fatal`
titán
válasz
Sk8erPeter
#16743
üzenetére
Nem feltétlen, a kedvencek melletti piros ikonkára is. De az RC-ben javítva lett ez a hiba szerintem. Nem minden oldalon jelentkezett a hiba, blog.hu-n pl. jó volt. De nem egyedi hiba volt, Pengénél sem volt jó.
Szerk.: Igen, már javítva van.
-
Sk8erPeter
nagyúr
válasz
fatal`
#16716
üzenetére
"hogyha kinyitok egy topicot itt a ph-n az új hsz-ek számára kattintva, akkor nem látszik a végén a #hszszám a címsorban"
Na várj, itt most az "Itt szóltam hozzá" résznél lévő ugrabugrára gondolsz?
Csak mert az nálam rendesen működik.(#16719) Penge_4 : milyen f@sza, hogy ezt nem lehet publikusan megnézni.

Ehhez hogy lehet accountot kapni? -
Sk8erPeter
nagyúr
válasz
Penge_4
#16713
üzenetére
Ja, mondjuk a visszafelé kompatibilitás igényének elhagyása tényleg jó lehet abból a szempontból, hogy kevesebb visszafelé teszteléssel, hibalehetőséggel járhat, és így gyorsabb a fejlesztés, ez jó szempont.
Azzal is egyetértek, hogy sokan már-már divatból mondják azt, hogy "ugyan már, semmi haszna a 64 bites változatnak, hacsak nincs több mint 4 GB RAM-od", pedig ez nem igaz, így valószínű, hogy nem tudják, miről beszélnek, vagy képzavarban vannak. Persze az igaz, hogy elképzelhető, hogy a gyakorlatban nem érzékelik a különbséget.
Ha rendelkezésre áll a 64 bites változat, és 64 bites OS-t használ valaki, akkor én is úgy gondolom, hogy érdemes mindenképp azt választani, de ettől nem érdemes viszont azt várni, hogy ezentúl olyan gyors lesz a program, mintha az OS-t egy SSD-re költöztetnéd.
Egyébként én arra lennék kíváncsi, vajon a 64 bites változatban az oldalak renderelése, SVG-renderelés mennyivel lehet gyorsabb, JavaScript-motorok teljesítményén javít-e érdemben, WebGL-nél mennyit számíthat, meg csomó ilyen általános használat során érzékelhető különbségre lennék kíváncsi. Nem tudom, van-e már ilyen teszt, vagy fog-e készülni hiteles felmérés a témakörben.
===
(#16711) hunfatal :
"Annyi előnye van, hogy natívan fut, más nem igazán."
Én ezt azért kétlem, a fentebb és korábban említett szempontok miatt is.
Legalábbis remélem, hogy azért érzékelhető is valami különbség.
-
draco31
veterán
-
Penge_4
veterán
-
cousin333
addikt
válasz
darvak
#16734
üzenetére
"Először is amiket leblokkolok jobb gombbal, azok a content/blocked content szabály-gyűjteménybe kerülnek??"
Igen. A teljes listát a Ctrl+F12, Haladó, Tartalom, Letiltott tartalmak részen találod.
"NA meg netről töltötem url.ini-t, jó sok szabállyal. Ezért a weboldalba beilleszett media-player videot alapból be sem töltötte."
Ezért kell óvatosan bánni ezekkel a "full extrás" szabályfájlokkal. Személy szerint azt javaslom, hogy a nulláról indítsd a listát, mindig hozzáadva azt, ami éppen zavar az adott oldalon. Ez kicsit lassabb és nehézkesebb módszer ugyan, de pontosabb és testreszabottabb, ráadásul az Opera Linkkel szinkronizálhatod a listát két gép között, vagy egy új friss telepítés esetén.
"Mit kéne kitörölnöm hozzá, hogy újra menjen a blocked contentek közül?"
Több megoldás is van. A gyorsabb, inkább teszt jellegű, hogy globálisan, vagy csak az adott oldalon letiltod a tartalomszűrést. Ez utóbbit az F12, Webhely beállításainak szerkesztése, Tartalom fülön teheted meg.
Vagy, jobb klikk az oldalon, Tartalom letiltása, majd a felső sávban a Részletek gomb, és ki is listázza az aktuálisan tiltott elemeket.
-
cousin333
addikt
válasz
draco31
#16732
üzenetére
Ezt írd a címsorba:
opera:about
Megmutatja a profilod helyét (amit keresel). Vagy:
opera:cache
Ez meg a gyorsítótár tartalmát, amiben lehet keresgélni is. De lehet, hogy egy Flash letöltős kiegészítővel járnál legjobban, bár ez az oldaltól is függ.
-
darvak
senior tag
Hello!
Blocked content-ről kérdeznék párat.
Először is amiket leblokkolok jobb gombbal, azok a content/blocked content szabály-gyűjteménybe kerülnek??
NA meg netről töltötem url.ini-t, jó sok szabállyal. Ezért a weboldalba beilleszett media-player videot alapból be sem töltötte. Gondolom a filter miatt lehetett, mivel a plugin-ok között be van kapcsolva a media-player.
Mit kéne kitörölnöm hozzá, hogy újra menjen a blocked contentek közül?
ahoj
-
dqdb
nagyúr
-
draco31
veterán
Hello!
Az Operát csak másodlagos böngészőként használom, és minden kilépésnél törlöm az adatokat.
Egy flash videot szeretnék vele elmenteni, úgy tudom, hogy innen lehetne kimásolni:
C:\Documents and Settings\<felhasználónév>\Application Data\Opera\Opera\profile
de nekem nincs profil mappa. Hol találom meg az adott videót? -
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.
-
pethYeti
addikt
Directx-es hwa-val miért ilyenek a fontok vajon? Tiszta linux feeling

-
dqdb
nagyúr
válasz
fatal`
#16726
üzenetére
Nem csak bizonyos oldalakon és időszakosan jelentkezik, hanem állandóan és az opera.exe CPU felhasználása száll el. Teszek majd egy próbát üres profillal a hordozható változatban, bár a mostani profilom maximum 2 hónapos lehet csak.
Penge_4: ha megmondod, hogy mivel nézzem (laptop HD3450-tel), akkor megnézem neked szívesen.
-
dqdb
nagyúr
válasz
fatal`
#16724
üzenetére
Nem tudom, azt nem néztem meg, majd talán holnap. Azon a gépen korábban volt az OpenGL gyorsítással problémám (akkor még a DX-es változat nem létezett), így ki volt kapcsolva sokáig. Aztán nemrég tettem egy újabb próbát, ennek hatására DX módban indult el az Opera, és én úgy hagytam.
Közben megnéztem, másik gépen 32 bites Opera alatt szoftveres és DX rendering esetén sem jelentkezik az összecsúszó szöveg.
Az utóbbi pár snapshotnál új probléma jelent meg nálam (a mai is érintett), mindössze pár percnyi futás után megeszik egy magot az Opera

-
dqdb
nagyúr
válasz
fatal`
#16722
üzenetére
Kipróbáltam, és úgy tűnik, hogy kizárólag a 64 bit és a DX gyorsítás együtt okozza a problémát, mert 64 biten kikapcsolt hardveres gyorsítással sem jelentkezik (amúgy ránézésre azokon a helyeken csúszik össze a szöveg, ahol a karakterek az ISO-8859-1 kódlapon nem találhatóak meg, mint ő és ű).
-
dqdb
nagyúr
válasz
fatal`
#16716
üzenetére
Nem tudom milyen hwacc van, csak onra kapcsoltam, máshoz nem nyúltam, nem tudom melyik az alapértelmezett.
DirectX-nél jelentkezik a hiba 64 bites Operával, ez biztos. A másik gépemen 32 bites Opera van hardveres gyorsítás nélkül, ott nem, szóval nem tudom megmondani, hogy a 64 bit vagy a DX mód az okozója. -
Penge_4
veterán
válasz
fatal`
#16718
üzenetére
Jelentve: DSK-365452
-
Penge_4
veterán
-
fatal`
titán
válasz
Penge_4
#16715
üzenetére
32bitesben még egyszer sem találkoztam. De HWA specifikus, írtam is, hogy bekapcsolt hwaccal. Nem tudom milyen hwacc van, csak onra kapcsoltam, máshoz nem nyúltam, nem tudom melyik az alapértelmezett.
Másik hiba, hogyha kinyitok egy topicot itt a ph-n az új hsz-ek számára kattintva, akkor nem látszik a végén a #hszszám a címsorban (itt szoktam nézni, hogy honnan kell olvasni, ha kevés hsz van, vagy, ha valamiért nem görget le), csak, ha belekattintok. Ezt esetleg lehet valahol állítani? Mert egyébként a teljes webcím be van kapcsolva.
-
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
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?
-
fatal`
titán
válasz
Sk8erPeter
#16708
üzenetére
Annyi előnye van, hogy natívan fut, más nem igazán. Egyelőre bugosabb is, mint a 32bites, így én inkább a 32-est használom a bétából is.
(#16704) Orlin: IE-n kívül egyikből sincs stabil, natív x64. Illetve a Safarit nem tudom.
-
Sk8erPeter
nagyúr
válasz
Dluinet
#16709
üzenetére
Jé, ezt nem is láttam még.
"címkézési korlát"
Gondolom inkább címzési korlát akart lenni.
Ezzel a cikkel az a gond, hogy azonkívül, hogy bemutatta, hogy a titkosítást használó oldalaknál lehet esetleges előnye, lényegében nagyrészt csak elméleti fejtegetés volt, és egyáltalán nem koncentrált a böngészőkben konkrétan felmerülő és a gyakorlatban is érezhető előnyökre/hátrányokra a 64 bites változat esetén. 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.
Tulajdonképpen én úgy érzem, ez a cikk csak a célját nem teljesítette, hogy bemutassa a 64 bites Operával tapasztalható érdemi különbségeket. A 32 bit vs. 64 bit témával kapcsolatos általános elméleti cikkekkel pedig így is Dunát lehet rekeszteni. -
A 64-bitről bővebben magyarul
-
Sk8erPeter
nagyúr
Ha már említésre került, felmerült bennem, milyen szempontokat lehet felhozni a natív 64 bites változat mellett/ellen egy böngésző esetén, a Firefox 64 bites unofficial változatának kivesézésénél pont ezeket fejtegetik (most itt tök mindegy, FF-ről vagy Operáról van szó, az előnyök/hátrányok nyilván hasonlók): [link].
-
Orlin
addikt
válasz
Sk8erPeter
#16705
üzenetére
Új rendszert alkottam
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Orlin
addikt
Van akinek fent van és mennyire megbízható?
Köszi! -
Orlin
addikt

Nem vagyok nagy Opera használó csak szerettem voln a rendszere még egy stabil böngszőt...
Azrt érdekes,h nincs stabíl 64 bites
Új hozzászólás Aktív témák
Kérdés előtt olvasd el az
összefoglalót!
- Battlefield 6
- iPhone topik
- Xiaomi 17 Ultra - jó az optikája
- Hivatalos a OnePlus 13 startdátuma
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- GL.iNet Flint 2 (GL-MT6000) router
- ASUS blog: 2K-tól a 4K-ig és tovább a Radeon RX 9000-es szériával
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Motorola Edge 50 Neo - az egyensúly gyengesége
- További aktív témák...
- PC Játékok
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Game Pass Ultimate előfizetések 1 - 36 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN! AKCIÓ!
- Játékkulcsok ! : PC Steam, EA App, Ubisoft, Windows és egyéb játékok
- BESZÁMÍTÁS! Részletfizetés 0% THM ÚJ Sony PlayStation 5 Slim digital / lemezes / Pro konzol 27% áfa
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- LG 45GS95QX - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- ÚJ Apple Airpods Pro 3 - www.stylebolt.hu - 1 Év Apple garancia - 27 százalékos Áfá-s száma !!!!
- Xiaomi Watch S4,Újszerű,Dobozaval,12 hónap garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Azért kérdeztem, mert itt nem írja, vagy én nem látom
, hogy az IE-től eltérő verzió, ami beépül Firefox, Safari és Opera alá az 64-bites is lenne.
![;]](http://cdn.rios.hu/dl/s/v1.gif)









