-
Fototrend
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz gipszw #18300 üzenetére
Ha ezt kipróbálod, akkor mi a helyzet?
http://prohardver.hu/tema/opera_bongeszo_2/hsz_17856-17856.html
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz poirot #18321 üzenetére
Szerintem még mindig él dqdb hsz.-e ezek szerint:
http://prohardver.hu/tema/opera_bongeszo_2/hsz_17856-17856.htmlSk8erPeter
-
Sk8erPeter
nagyúr
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz daninet #18382 üzenetére
Milyen oldalakra gondolsz konkrétan? Miért nézel ilyen oldalakat, ahol 2000 kép jelenik meg egy oldalon?
Egyébként az ilyen lazyload kialakítása az oldal fejlesztőinek felelőssége, ha nem oldották meg, legfeljebb valami ügyes extensionnel/userJS-sel tudod megoldani a dolgot. Hogy van-e ilyen, fogalmam sincs.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz daninet #18389 üzenetére
Na, most megnéztem az aláírásodban lévő tumblr-oldalt, hát elég tetszetősek a képek (de nyilván nem a tájképekre csorgattam a nyálamat ). Opera 12.02, x86, HWA kikapcsolva (opera:config#UserPrefs|EnableHardwareAcceleration), WebGL 1-esre kapcsolva (opera:config#UserPrefs|EnableWebGL ; autodetect), nem volt vele semmi para, szépen töltődtek be a képek a görgetéskor, és AJAX-os betöltés van, ahogy elnéztem.
Szóval érdemes lenne kipróbálnod ugyanezt egy USB-s Opera-változattal is, hogy nem a jelenleg telepített Operáddal van-e a para.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Joe109 #18439 üzenetére
Teljes oldalról nem lehet screenshotot készíteni, csak az épp látható részekről, igazából az is csak debuggolás céljára van. Ha nyomsz egy Ctrl+Shift+I-t, akkor van egy "Utilities" fül, ott tudsz screenshotot készíteni az épp látható területről, de sajnos nem a teljes oldalról, így lehet például az oldalon lévő színeket vizsgálgatni.
Sk8erPeter
-
Sk8erPeter
nagyúr
Áhh, most látom, oda van írva feketén-fehéren:
"It works on Opera 12.10 and newer. If your Opera is older, the extension will not be installed."Nálam Opera 12.02 (x86) van még, a sok "remek" bugokkal kapcsolatos hír miatt (amik itt a topicban is felröppentek) még nem vágytam valahogy a frissítésre.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz didyman #18450 üzenetére
Hát ja, sajnos volt itt panasz a memóriaszivárgásról is az újabb verziók kapcsán.
Az azután írt dolgok, a Gmaillel és Facebookkal kapcsolatos hibák inkább ezeknek az oldalaknak az egyedi megoldásaik miatt fordulnak elő, meg amiatt, hogy ezeknek a fejlesztői magasról leszarják az Operát, mint marginális böngészőt. Ezért szokott az Opera "utánaigazítani", és kiadni a megjelenítés javítására szolgáló egyedi utánatákolásokat. Ettől függetlenül egyetértek vele, hogy az Opera nem sokat javít a helyzetén mostanában a bugtengerrel, amiben úszhat a kedves júzer, amikor az újabb verziókra frissít, bár erre nem pont a Gmail és Facebook csupán a jó példa, hanem az általános használat közben jelentkező degenerált viselkedés, amiről itt a topicban elég sokat olvasni mostanság sajnos.
Én őszintén szólva mostanában az Operát arra használom, hogy gyűjtsek benne olyan füleket későbbi megnézés céljára, amiket épp nem volt időm megnézni, de később attól még érdekelne, de nem akarom a megnyitva tartásával rontani az átláthatóságot a Chrome-ban.
Biztos aztán megint lesz olyan időszak, amikor visszatérek az Operára, de az akkor lesz, amikor az Opera nem lesz tele bugokkal, és mondjuk lehet használni akár fejlesztőeszközként is (például a botrányosan egy példányban nyitható Dragonfly-on javítanak).Sk8erPeter
-
Sk8erPeter
nagyúr
válasz didyman #18456 üzenetére
"Igen, de régen még magasabbról tettek az Operára"
Mármint kik? Miért, "azóta" (a nem tudom, mióta ) nőtt az érdeklődés az Opera iránt a fejlesztők részéről? Én ilyen tendenciát sajnos nem vettem észre.A Gmailes problémákkal teljesen egyetértek, Opera alatt katasztrófa használni. A chatben ezer éve fordulnak elő bugok, az oldal tempójával is bajok vannak, meg egyedi hibák fordulnak elő, amikor az oldal egy része nem látható, nem kezelhető részre kerül egyszer csak, és egyetlen megoldás a lap frissítése. A teljesítménye akkor is fos, amikor jó konfigurációról van szó, a rendszer pedig SSD-n futkorászik.
"megnyitottam egy IE9-et és lehet, hogy szép lassan átköltözik oda a többi weboldal is"
Azért a másik végletig ne menjünk el
Ha már normális, de jóval kevésbé konfigurálható böngésző, akkor már Chrome. Azért az IE-től a mai napig tépem a hajam, ha használni kell, annyira okádék a felülete, még az IE9 is kiábrándító, IE10 jottányit sem fejlődött UI tekintetében. Screenshotokat nézegettem, az alapján ítélkezem. Nézd meg ezt: [link]. Az mennyire értelmetlen, hogy a fülek egy sorba kerülnek a címsorral? Akkor csakis széles képernyőn lehet egyáltalán látni mondjuk a fül címét? Akkor már az is jobb, ami az IE8-nál van, hogy órási helyet foglal el a fölső rész a címsorral és fülsorral, meg esetleg még egy-két toolbarral, de legalább látszik a fül normálisan, akkor is, ha meg van nyitva egyszerre 7-8."Dragonfly az valami eszméletlen jó ötlet tőlük amúgy, imádom. Csakhát..."
http://en.wikipedia.org/wiki/Firebug_(web_development)
http://www.opera.com/docs/history/
A Firebug 2006-os cucc, a Dragonfly alphája csak 2008 júniusában jelent meg, úgyhogy az ötlet nem az Operáé. Az IE-nek is van fejlesztőeszköze, de azt inkább hagyjuk. A Chrome viszont eleve csak 2008 szeptemberében jelent meg, az element inspectora viszont mára használhatóság, kényelmesség tekintetében az én tapasztalataim szerint bőven túlszárnyalta már az Opera Dragonfly-t, ami a mai napig csak egyetlen példányban nyitható meg. Hát ez mi? Mi az, hogy egyszerre nem tudsz két weboldalt vizsgálgatni, egymástól teljesen független panelen? Ami a durva ebben, hogy ezt még az Internet Explorer beépítettje is tudja már egész régóta... legalábbis most próbáltam, és még az IE8-ban lévő fejlesztőeszköz is több példányban működik... vicc az egész. Amíg az Opera ezen nem fejleszt valamit, hogy épp a célcsoport, tehát a webfejlesztők is normálisan tudják használni ezt a sz@rt fejlesztésre, addig nincs is miről beszélni a Dragonfly kapcsán. Addig felőlem rakhatnak bele akármennyi szolgáltatást, ha egy ilyen elementáris igényt képtelen kiszolgálni, akkor addig egy fostalicska.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fatal` #18458 üzenetére
"Szerintem Opera alatt a legegyszerűbb a gmail használata, lévén ott van benne a levelező kliens. Nem is értem miért szenved mindenki a webes szarral"
Például mert én a beépített levelezőt tartom "szarnak", számomra kényelmetlennek, csúnyának De nem, igazából nem szar, csak nekem nem fekszik, hanem jobban tetszik a Gmail saját webes "szara", megengeded nekem? Én sem akarlak meggyőzni arról, hogy szerintem a "webes szar" jobb. És nem "szenvedek" a webes "szarral", hibátlanul használom Chrome alatt.Szélsőségek irányába nem tudom, miért kell elmenni.
Nem arról volt szó, hogy győzzük meg egymást, kinek melyik megoldás tetszik jobban, hanem arról, hogy a "webes szar" felülete Opera alatt (!) lassú. Chrome alatt nem az, ennyi."A legtöbb user 2-3 fület tart nyitva"
Engem egyáltalán nem érdekel a "legtöbb user". Az érdekel, hogy egy böngésző számomra legyen kényelmes és jól kezelhető, átlátható, ne a "legtöbb user" számára. De ha van lehetőség az átszabására, akkor tök jó, ettől függetlenül nem fogok használni IE-t.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fatal` #18464 üzenetére
"De az IE-t ugye nem neked fejlesztik, hanem sokmillió usernek. Átállítod és kész, az Opera alapbeállításai is szarok, mégsem szidja emiatt senki."
Szerintem nem szarok az Opera alapbeállításai. Honnan tudod, hogy nem szidja emiatt senki?
Az IE-nek ez a beállítása viszont eltér az összes népszerű mai modern böngészőtől, biztos a többi böngésző gyártója a hülye.Egyébként igazából nem nagyon értem, miért nyilvánítasz úgy messzemenő véleményt a Gmailről, amikor előbb mondtad, hogy egyáltalán nem használod a "webes szar" felületét, csak gondolom most a kedvünkért, hogy bebizonyítsd, neked van igazad, kipróbáltad pár kattintás erejéig. Én hosszú távú használatról beszéltem, amikor kijönnek az idegesítő dolgok, és a böngészők közti különbségek. Például az, hogy a Chrome-ban gördülékeny a Gmail használata, Operában viszont sok esetben nagyon nem az. Nem azt mondtam, hogy kattintasz párat, és már az is borzalmasan lassú.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Dehát erre a kisbetűs parára asszem 6 hsz.-szel előtted írt vmit Ndruu
http://prohardver.hu/tema/opera_bongeszo_2/hsz_18463-18463.html
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz didyman #18467 üzenetére
A Chrome a Microsoft ClickOnce miatt települ oda, ahogy az alábbi linken más emberkék leírták, csak hogy ne nekem kelljen körülírni
Az ütemezett feladatos megoldást meg gondolom azért találták ki, mert az egyszerű júzer megijed tőle, amikor felpattan egy ablak, hogy frissíteni kéne, és akkor most úristen, mi lesz, hogy lesz, ehelyett ez megtörténik automatikusan, időnként ránézve, van-e új verzió; ráadásul (ez elég fontos lehet sok esetben) ahhoz admin-jogosultságot is kér az alkalmazás amikor a Program Files-ba/Program Files (x86)-ba megy; utóbbi a telepítés helyét is megmagyarázza. Végül is ők megkerülték ezt.
Valaki szereti, valaki nem, valakit meg nem különösebben zavar, én az utóbbi kategóriába tartozom, nem foglalkozom vele.
Amúgy mi az oka, hogy ennyire zavar? Mármint milyen hátrányát látod a saját esetedben? Nem lesz az ütemezett feladatos megoldás erőforrás-igényesebb, mint amikor az alkalmazás időnként ránéz a saját szerverükre, hogy van-e újabb verzió... plusz akkor lövöd ki az ütemezett feladatokat, amikor akarod.Amúgy én abszolúte nem vagyok Chrome-fan, mindig azt használom, ami épp a leginkább kézenfekvő számomra. Két böngésző között szoktam vergődni, az az Opera és a Chrome. Jelenleg az Operával inkább bajaim vannak, mint amennyire élvezném a használatát, még ha gyorsabbnak is találom általánosságban (a Gmail-para ellenére), mint a Chrome-ot, így jelenleg a Chrome-nál maradtam. A Firefox és IE nekem sosem jött be saját felhasználásra. Az IE leginkább azért nem, mert nagyon nem konfigurálható, nem testreszabható, plusz számomra vánszorgós, igaz, most már SSD-vel más a helyzet, de a Chrome mégis kézenfekvő, főleg fejlesztés céljára, eléggé el van találva a developer toolbarjuk. Ezért is lep meg, hogy számodra ha számít valamennyit a beállíthatóság, akkor miért fekszik jobban az IE, de én persze elfogadom, hogy valamiért neked az jobban bejön, aztán ennyi.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz didyman #18476 üzenetére
"Én pontosan tudom ezeket az érveket, okokat az appdata mellett"
Írhattad volna előbb is, akkor nem vakerászok ennyit róla"Az Opera/róka is tud a program filesba települni, és hovatovább, minden egyéb folyamat nélkül keres és telepít frissítést, nem kell ijedeznie a felhasználónak, néha egy folyamatjelző végigfut indulásakor és ennyi a frissítés."
De az Opera admin-jogokat kér:Ez sok felhasználó beszaratásához már eleve elég. Admin-jog nélkül mondjuk nem is fog menni. Egyébként abban én igazat adok neked, hogy ez nem is biztos, hogy baj... igaz, meg lehet közelíteni a kérdést másik oldalról is: ha meg nincs frissítve, akkor meg az is lehet baj, ha például valami biztonsági rést sikerült bennehagyni egy korábbi verzióban.
"Amikor fut 3 példányban a gupdate, akkor az ilyen 6-30MB között akármi is lehet állandó jelleggel"
Ez viszont most hirtelen nem világos, hogyhogy fut 3 példányban állandóan az update?A Chrome könyvtára ilyen mértékű hízásának problémájával egyetértek, hogy az gáz.
Összegezve számtalan dolgot kéne még bővíteni a Chrome-on ahhoz, hogy elégedett lehessek vele, meg én továbbra sem érzem olyan gyorsnak, mint az Operát, de ez más kérdés, viszont van benne számtalan olyan dolog, ami Chrome-ban sokkal jobb, mint az Operában, például az, hogy erre optimalizálnak fejlesztők, meg az, hogy például ennek a developer toolbarja nagyon jól használható.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz ottoyes #18483 üzenetére
"de ha trendi akarok lenni akkor Chrome.Hiába,nagy úr a Google. "
Jaj ne, ne menjünk el a kicsit vicces "rohadt szemét nagyvállalat"-utálat irányába, mert az általában jó messzire visz mindenféle szakmaiságtól. Az Opera is tele van olyan nevetséges hibákkal, amiket a Chrome viszont eleve jól alakított ki, vagy idővel csiszolt rajta, annak érdekében, hogy adott feature használható legyen, tehát azért nem árt az általunk szeretett böngészőt is némi kritikával kezelni. Én ezer éve használom az Operát, de tele van számtalan olyan idegesítő dologgal, ami például a Chrome használata felé lökdös (ahogy említettem, most épp azt az időszakomat élem, amikor Chrome-felhasználó vagyok). Most hirtelen eszembe jutott az Opera beépített keresőfunkciója vs. a Chrome-é, amiről itt Penge_4-gyel már sokat beszélgettünk, hogy ez speciel Chrome-ban ezerszer jobban lett kialakítva (mutatja a találatokat, és óriásterjedelmű oldalnál (lásd w3.org egyes aloldalai) is nagyon jól használható, akadások nélkül); valamint a source nézetben való keresés: Chrome-ban láthatók a találatok emberi szemmel is, Operában nem, és az erre való javítás Operában állítólag csak valami alfa-béta-gamma verzió valamelyikében elérhető; plusz ami szerintem sokkal kezelhetőbb, az a Chrome beépített fejlesztői eszköztára, amiről nemrég kifejtettem a véleményem, hogy a Dragonfly ezzel szemben viszont még mindig jócskán elmarad - sajnos. Aztán biztos van még egy csomó minden, de ez a három dolog, ami hirtelen beugrott, és ami számomra jelentős, de még biztos gondolkodhatnék jópár dolgon, csak nem akarok itt böngészőháborút elindítani, mert egyáltalán nem vitatom el viszont az Opera sok-sok előnyét a Chrome-mal szemben - lásd például épp azokat a dolgokat, amiket hunfatal említett az előbb, és amelyekkel mind egyetértek, hogy botrány, hogy a Chrome-ból még kihagyták.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18481 üzenetére
"Én már rövidtávú használatkor is látom a különbséget. Operával szar, Chrome-mal (mivel arra tervezték) jó. De még Firefox-szal és IE-vel is jobb, mint Operával."
Igazad van, csak hunfatal az imént annyira ragaszkodott hozzá, hogy pár klikk után neki a Dzsímél akkor is legalább ugyanolyan jó, mint Chrome-ban, hogy nem volt kedvem erről tovább vitázni akkor. Pedig de, Opera alatt szimplán szar a Gmail, és kész. És igen, Chrome-ra biztos jól optimalizálják, de a többi említésre méltó részesedéssel rendelkező böngészőnél is jobban működik, Opera alatt pocsék érzés használni. És én nem tartom alternatívának a beépített levelezőt, mert számomra az meg fapad.Az RSS readerrel kapcsolatos elképzeléseid szerintem jók, de nem tudom, hogyan működik a Google Readernél a felfelé irányú kapcsolat, van-e bármi API-juk a lista frissítésére, anélkül, hogy konkrétan a readernek kellene olvasnia azt a bizonyos feed-fájlt (pl. XML).
Az Appdata-s dolgot sztem félreértetted, én nem mondtam, hogy a Chrome logikájával értek egyet, hogy miért is jó, hogy oda írogat, csak elmondtam, hogy ők milyen elképzelések mentén alakíthatták ki így. Én is látok benne potenciális biztonsági problémákat, legalábbis az aktuális bejelentkezett júzer adatait tekintve.
Hízó cache, fél internet becache-elése: én nagy általánosságban nem tartom gyorsabbnak a Chrome-ot, mint az Operát, persze bizonyos oldalaknál észrevehető a különbség a Chrome javára, de ez szerintem sok esetben az Operánál inkább valami szar/átgondolatlan implementáció eredménye. Például nem értem, hogy sokszor dicsérik (vagy csak dicsérték régen?) az Operát a JavaScript-motorja miatt, pedig szerintem nem gyorsabb, mint a Chrome-é, például a Gmail tele van JavaScriptes dolgokkal, és ott nagyon előjön a különbség - miért, mert a Google-nél jól ellenőrzik, hogy Chrome-ról van-e szó, és akkor adott beépített funkcióknak valami sokkal hatékonyabb változatát használják? Hát nem valószínű.
Amúgy az általad többször linkelt w3.org-os óriásoldalaknál is előjön a különbség (itt nem tudom, miért ez az alap, mármint a w3.org-on, miért nem bontják szét alapból, és linkelik be az egész változatot is, no mindegy), amiktől legalább a Chrome nem hal meg (fagyasztja szét a GUI-t). (Szerk.: itt az utóbbinál már nem a JavaScript-motorról beszélek.)[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fatal` #18486 üzenetére
Gondolom ez náluk is olyan, mint itt a Prohardver fícsörökért kuncsorgós topicjában, hogy "nem prioritás, úgyhogy leszarjuk a fejedet".
De olyan nagyon azért nem kell messzire menni, hogy ilyen mentalitással találkozz, miért, az Operánál mi van (az olyan fejlesztésekkel kapcsolatban, amit elvileg egy (hosszú) délután alatt lehetne megcsinálni)? Miért nem vezetik be évek óta például az űrlapmezőknél a history-szerűséget (az autocomplete nem teljesen egzakt)? Miért nem teszik többpéldányossá a Dragonfly-t? Miért van a position:fixed bug? (jó, ez nem egy délutános feladat) Miért ilyen degeneráltan csinálták meg a formelemeknél való találat-megmutatást, mint a source nézetben a textarea-nál, hogy minden szürke, és a találatok a szürkének valami más árnyalatai? Miért csak bugosodnak a verziók, miért nincs valós fejlődés?
A Chrome-nál viszont egyre több opció elérhető, a 3 db beállítás már szerencsére nem igaz (most már legalább 5 darab van ), a beállítás felületével kapcsolatos változásokkal kapcsolatos lázongást pedig aztán végképp nem értem a fanok részéről, mert szerintem ez speciel pont, hogy jó irányba haladt, minden beállítási aloldal belinkelhető (csak egy példa a sok közül: chrome://settings/contentExceptions#javascript), ezt az ötletet valószínűleg az Operától nyúlták, de jól tették, a chrome://net-internals/ -nál lehet jókat bambulni, és úgy csinálni, mintha értenéd, mi van ott , aztán a chrome://gpu/ -nál ugyanez, meg ott van az összes többi elérhető cuccos a chrome://about/ -nál; plusz chrome://flags ; szóval bővül, és nem csak azt látom, hogy csúszik egyre lejjebb, bugosodik, mint az Opera.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz ottoyes #18489 üzenetére
Dehogy vagyok én szakértő... Csupán a téma iránt érdeklődő. De itt a topicban vannak páran, akik nálam sokkal jobban vágják a témát, én mezei felhasználóként és weboldal-fejlesztőként tekintek a böngészőkre. Meg próbálkoztam extension-fejlesztéssel Opera alatt, gyorsan elment tőle a kedvem. Chrome-ban speciel ez is jobban meg van oldva (ettől függetlenül nem foglalkoztam sokkal többet az ottani bővítményfejlesztéssel, de azt már tudom, hogy ezerszer jobban van megvalósítva a Chrome extension API, mint az Operáé). Ettől még én is szeretem az Operát.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fatal` #18491 üzenetére
"a userjs-ekből tákolták össze és gondolom a végeredmény is olyan lett, amilyen"
Jaja, ez így igaz. A "tákolmány" szó tökéletesen illik az Opera Extension API-ra.
Chrome-bővítményt még nem akartam használni belső lapon, úgyhogy ahhoz nem tudok hozzászólni, de én is hallottam valami ilyen jellegű paráról, de egyáltalán nem követtem mostanság, hogy mi újság ezzel, javították-e. Ja, a HTTPS-ről is csak ilyen félinfó maradt meg, hogy asszem az már megoldott kérdés.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fatal` #18493 üzenetére
"Szerintem nem bug, hogy a belső lapokon nem működik, hanem feature, hogy ne gányoljanak bele az kiegészítők a felületbe (ami azt hiszem HTML meg JS)."
Nem is mondtam, hogy bug, csak hogy hallottam, hogy volt ilyen para, hogy volt, akiknek szüksége lett volna rá, de nem működött. Egyébként azért ezt másféleképpen is meg lehetne oldani, hogy bizonyos dolgok ne működjenek belső lapokon, egyszerűen korlátozva a lehetőségeket."Az Opera Extension témához: Egy gány, de Opera alatt nem is kell sok, a legtöbb cucc beépített."
Hát azért sztem ez nem ilyen egyszerű, ha már egy böngészőgyártó lehetőséget ad arra, hogy a felhasználói extensionöket is fejlesszenek hozzá, akkor már tegye azt úgy, hogy ne legyen a fejlesztés gány, nyakatekert, hanem lehessen konzekvens, szép kódot írni; ha valaki ahhoz szeretne extensiont írni, hogy akármikor egy linkre kattint, pirosra változzon a háttér, akkor hadd tegye meg saját kárára, de akkor már nem mindegy, hogyan írja meg ezt; ilyen meg nincs beépítve."ha kedvencet nyitok a kedvencek sávról görgővel, akkor ne fókuszáljon rá"
Ezt most kipróbáltam Chrome-ban, Ctrl+Shift+B-vel megjelenítettem a könyvjelzősávot, aztán Ctrl+klikkel rákattintottam egy könyvjelzőre, és a háttérben nyílt meg, nem fókuszált rá, szóval ennek kapcsán sztem nyitott kapukat döngetsz.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18504 üzenetére
"Linuxon például a fájltársítások, a protokollok és a fontok módosításakor nem szemeteli tele az operaprefs.ini-t"
Ezt a szemetelést hogy érted? Akkor mit szemetel, ha nem az operaprefs.ini-t? Mert valahol tárolnia kell a módosításokat.Amúgy az OS X is UNIX-alapú.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18510 üzenetére
Hát elég gázosak ezek a szemetelések, amiket írtál, a Silverlight aktuális verzióját és az ennek megfelelő könyvtárat meg lekérdezni pedig egy nyomorék registry-kulcs vizsgálgatásával nem túl nehéz:
http://stackoverflow.com/questions/4814486/finding-silverlight-version-installation-folder-programmatically/4814739#4814739
Igazából nem világos, a Windows-os változatot miért szemetelős szarra készítik el."Ami tetszik, hogy a címsorba belekattintva elsőre nem jelöli ki az egészet, ezért könnyebben ki tudom másolni egy URL részletét"
Amikor Linuxot használok, nekem erre mindig nehéz átszoknom. Általában ha van rá lehetőség, át is állítom inkább a Windows-os módszerre, mert zavar, miután úgy szoktam meg, hogy a teljes címsort kijelöli ilyenkor. Igaz, néha jó, de általában ha szükségem van a címre, akkor a teljes címre van szükségem (pl. elküldök valakinek egy linket), amikor részletre, az a sokkal ritkább eset, és akkor úgy szoktam, hogy Ctrl+L, jobbra nyíl, aztán Ctrl+Shift+balra nyíllal visszajelölöm a szavakat egész addig, amíg kell.Egyébként hogyhogy most Linuxozol? Vagy csak virtuális gépen tolod?
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18512 üzenetére
D"Az Nvidia például az önkicsomagolás után otthagyja az összes eddigi driver kicsomagolt, több száz megás telepítőjét, pedig arra aztán tényleg semmi szükség"
Jaja, ez így van, de sajnos ez elég sok önkicsomagolós telepítőre jellemző, pedig szimpla igénytelenség ezt így megcsinálni, lehetne úgy is elkészíteni egy telepítőt, hogy egyből a célhelyre bontja ki magát.
Vagy ha már így készítették el, akkor könyörgöm, törölje már magától a kibontott szutykot (legalább kérdezze meg, hogy akkor törölheti-e, amire úgyse lesz többé szükség, vagy kérdés nélkül törölje)."Mikor az egész címre szükségem van, már rutinból nyomom az Alt+D-t."
Ja, ez is jó, én valahogy megszokásból a Ctrl+L-t nyomom egyből. Annak ellenére, hogy elvileg az Alt+D a közelebbi betűk miatt jobban kézre kéne, hogy álljon, bár tulajdonképpen annyi a különbség, hogy a Ctrl+L-nél két kézre is szükség van, de ha úgyis az "alapállásban" tartod a kezeidet, akkor kábé ugyanaz.Linux-időszak nálam épp egy ideje eltűnt, mert alapvetően elégedett vagyok a Windows 7-tel (8-asra nem váltanék, mert számomra okádék az új, ízlés kérdése). De mostanában virtuális gépen én is használni fogom, egyetem miatt úgyis megint szükség lesz rá (na meg a 12 GB RAM már elég a virtualizációhoz).
A KDE-t még nem használtam, mert mindig arról szólt a fáma, hogy erőforrás-igényesebb, mint a Gnome, így szarabb konfigon lassabb.
A csomagkezelő Linuxban bejövős, de azért az tetszik, hogy a Microsoft is egyre több helyen alkalmaz hasonlót, például az egységsugarú júzer által is kezelhető Web Platform Installernél ráklattyolok, hogy telepíteni akarom a Drupalt, és automatikusan behúzza a függőségeit: MySQL (vagy preferenciától függően MS SQL is lehet akár), FastCGI PHP, webszerverhez telepíthető cache-elési mechanizmusok, IIS-beállítások; tényleg pár klattyintással fel lehet állítani egy normálisan működő IIS-szervert. Ráadásul az IIS-hez van normális grafikus alapú admin-felület, az Apache-hoz sajnos nincs (csak ilyen, de ez azért nem ekvivalens); persze félre ne értsd, ez nem azt jelenti, hogy az IIS jobb, mint az Apache (főleg, hogy utóbbi ingyenes), de konfigolhatóság tekintetében egyszerűbb (igaz, vannak kész csomagok, mint a WAMP meg EasyPHP, XAMPP és társai).AIDA64-alternatívaként ez is nagyon jó: HWiNFO64.
A Windows sok-sok felesleges lapozása meg sajnos jogos probléma-felvetés, de már nagyon régóta fennálló probléma...
A Skype megnövekedett erőforrás-igénye meg tényleg kiakasztó, mert nem került bele olyan sok újítás, hogy indokolt lenne; a sok rohadt social-integrációtól meg amúgy is kimegyek a fazonomból (NEM, nem akarom összekötni a Facebook-fiókommal még véletlenül sem jó, persze én biztos ezzel a kisebbségbe tartozom).
A LibreOffice viszont egyébként szerintem szintén elég rossz vicc, hogy a "másik oldalt" is fikázzuk egy kicsit. Erőforrás-igényes, akadozós lassú szar. Na speciel Office-csomagra (mármint konkrétan én csak a Wordöt, Excelt, Powerpointot használom, és ennyi) még rendes, számomra igazán tetszetős Linuxos alternatívát nem ismerek.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18572 üzenetére
Hmm, meglepő, én a Te cikkedből tudtam meg azt is, hogy a Firefox is hasonló váltást tervez.
Az tény, hogy elősegíti a kompatibilitást, mert sajnos sok webfejlesztő szimplán a webkites prefixekkel elérhető CSS-tulajdonságokat használja, és magasról nem érdekli, hogy a többi böngészőben hogy néz ki a cucca. Persze biztos nagy általánosságban is magasabb szintű kompatibilitás is lesz jellemző, most csak a CSS-részre koncentráltam.Azt az instrukciót viszont nem minden esetben tartom jogosnak, hogy ne használjunk feature detectiont - bizonyos esetekben szükséges lehet. Amúgy miért olyan nagy probléma, ha 3rd party libre, pl. Modernizr-re van szükség?
Látom a megjegyzésben, hogy a Dragonfly megszűnik. Tök jó, hogy annyi munkát öltek bele, a több példányban futást mégsem sikerült megoldaniuk, viszont most meg kiderül, hogy kuka a dolog. Mi lesz helyette? Vagy nincs terv? Mert akkor webfejlesztésre az átmeneti időszakban nyilván senki nem fogja használni, legfeljebb a végeredmény csekkolására.
(#18573) hunfatal :
milyen szempontból sajnálod? Mármint konkrétan milyen hátrányát érezheted?Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18592 üzenetére
""Mi lesz helyette? Vagy nincs terv?" - Gondolom a Chromium-os Developer Tools"
Ezt most nem egészen értem. Nem tanulmányoztam a kódját a Chromiumos Developer Tools kódját, de hogyan ültetnének át egy teljesen más programra alapozott eszköztárat egy az egyben Operára?A mozdulatparancsoknak és a hotkey-knek miért kellene már ettől megszűnni vagy megváltozni? A cikkedben elvileg csak a böngészőmotor (!!) lecseréléséről volt szó, vagyis a megjelenítésért, renderelésért felelős motor cseréjéről, ettől még tudtommal a böngésző ilyetén jellegű feature-jeinek nem kell megszűnniük, ugyanis nem a komplett böngésző kidobásáról szól a fáma... ezért nem értem brd hozzászólását sem (és akkor már hunfatalét sem ). Ettől még miért változna az Opera Chrome-má?
De Te egészen biztos, hogy sokkal többet olvastál utána a témának, úgyhogy kíváncsi lennék, hogy van-e oka a drámának (mintha már kvázi teljes böngészőcseréről beszélnénk...).Pont ehhez kapcsolódóan emelnék ki jópárat a felvetéseiddel kapcsolatban, nem is mindet hozom fel, csak ami nagyon szembetűnt:
"szövegkijelölés"
Itt mire gondoltál?"spatial navigation, Fast Forward"
Nekem megint nem világos, ez a renderelő motor cseréje miatt miért kell, hogy megszűnjön?"anonymous függvény"
Itt mire gondoltál?"a .htaccess értelmezése a kényszerített letöltéseknél (hogy meg lehessen nyitni böngészőben is előzetes lementés nélkül)"
Hogy nyitod meg a .htaccess-fájlt letöltés nélkül? Kényszerített letöltésről írsz, de lementés nélkül, ez nekem képzavar."hogy a letöltés elindul-e a dialógusablak felugrásakor"
Ez nem csak Chrome-implementáció?"illetve ezzel összefüggően az Operában megnyitott fájlokat az Opera cache-ből menti le a végleges helyre, miközben a többi böngésző ilyenkor az eredeti URL-ről akarja letölteni."
Először itt nem vágtam, mire gondolsz, aztán rájöttem, hogy valszeg arra, hogy ha mondjuk megnyitsz egy óriási JS-fájlt (csak egy példa, bár nem annyira életszerű, mivel kevéssé valószínű, hogy lehet egyáltalán olyan óriási, hogy kijöjjön annak az előnye, amit mondasz, ha jól értelmezem azt), és nyomsz egy Ctrl+S-t, hogy lementsd, akkor ezek szerint az Opera a már cache-elt változatot akarja másolni valahova, nem pedig újból letölteni. Így értetted?
Ha igen, akkor annak megint csak mi köze a renderelő motor cseréjéhez, milyen módon áll ez összefüggésben?[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #18593 üzenetére
Vagy arra gondolsz, hogy Operánál ezek a funkciók ilyen szinten össze lettek drótozva a Presto motorral, hogy ezek működését is alapvetően fogja befolyásolni? Csak mert normális renderelő motor megtervezését úgy képzelném el manapság egy böngészőnél, mint egy külön komponenst, ami tök jól kommunikál a böngésző többi komponensével, mondjuk különböző API-kon keresztül, de ezek a komponensek egymástól lényegében függetlenek.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18598 üzenetére
"Újabban például megtudtam, hogy a non-modal dialogs is Presto sajátosság. Lásd, legutolsó bekezdés."
idézem az utolsó bekezdést:
"Koch said Opera’s decision is therefore “our own fault”, and he too wondered how this would impact on Mozilla, legacy Opera support, Presto-specific benefits (such as JavaScript not blocking the UI thread), and Opera’s political power in the web standards community."
Kiemeltem a Presto-specifikus dolgot, hol látsz itt non-modal dialogs-ról szóló részt?
Itt csak arról beszél, hogy egy hosszú ideig futó JavaScript-kód nem blokkolja a felhasználói felületet... ami egyébként elég nagy előny. De non-modal dialogs-ról nem is láttam említést a cikkben. (Pedig a kedvedért tényleg elolvastam az egészet. )Szövegkijelölés: na ez például engem Chrome-ban kifejezetten idegesít, hogy a duplaklikk egy szót+az azt követő szóközt is kijelöli... minek a plusz szóköz?!
"Anonymous függvény alatt a function()-t értem, ami arra szolgál, hogy a weboldal ne lássa milyen kiegészítőket/userJS-eket használsz, illetve mivel manipulálod/manipulálod-e kliensoldalon az oldalt, csak ha lekérdezi a global scope-ot."
Ennek mégis mi köze a böngészőmotorhoz? Ez JavaScript-specifikus dolog, abszolúte semmi köze az Operához.
Ha bővebben is érdekel:
How Good C# Habits can Encourage Bad JavaScript Habits - Part 1
http://enterprisejquery.com/2010/10/how-good-c-habits-can-encourage-bad-javascript-habits-part-1/
itt keress rá az anonymous functionről szóló részre. Érdemes elolvasni, nagyon hasznos írás.
(továbbiak: [link])"Például megnyitok egy .txt-t, egy .js-t, egy .css-t, egy .srt-t vagy képformátumokat."
Ennek szerintem semmi köze nincs a renderelő motorhoz.""Ez nem csak Chrome-implementáció?"
Ez ősi Opera feature, nem is tudtam, hogy Chrome-ban ilyen van. De szerintem nincs is, mivel még temporary_downloads sincs benne."
Mostanában tapasztaltam, amikor mondjuk nagyobb fájlokat akartam lementeni, és azt tapasztaltam, hogy a Chrome-nál elindul a letöltési sáv, még mielőtt megmondanád, pontosan hova is szeretnéd letölteni... [link] - gondolom ennyi, hogy elkezdi a %userprofile%\Local Settings\Application Data\…\Cache könyvtárba menteni."Az automatikus letöltést (amire te gondolsz) Operában is be lehet állítani, csak ott mime type specifikusan is. Sőt, MIME type specifikusan beállíthatsz még egy csomó mindent."
Én most ilyesmi összehasonlításról nem beszéltem, úgyhogy szerintem félreértetted, hogy én mire gondoltam. Mondjuk most hirtelen nem tudom, melyik részét, gondolom amiről az előbb írtam."De jó lenne ha leírnád, hogy te is csak tippelgetsz, vagy tudod is, hogy minek van köze a motorhoz és minek nem."
Honnan tudjam, pontosan az Opera milyen fícsöröket "drótozott be" a Presto-ba? Van egy-két dolog, ami tök logikus, hogy nem a renderelő (!!!) motorhoz KELLENE ELVILEG, hogy kötve legyen - eleve ha értelmezed a szó jelentését, hogy mire vonatkozik a RENDERELÉS szó, akkor nem kellene, hogy például a letöltéskezelés módja a motorváltástól megváltozzon a böngészőben... Ettől még ha valami nagyon degenerált megoldást alkalmaztak, akkor még akár simán összefüggésben is lehetne... erről beszéltem, hogy normál esetben egy csomó ehhez hasonló dolog úgy kellene, hogy megtervezve legyen, hogy egymástól független komponensekből álljon össze a böngésző, például a letöltéskezelés ugyan ne függjön már bármilyen módon is a konkrét renderelő motortól... legfeljebb annyiban, hogy tudja hívogatni a dolgait valami API-n keresztül. Tehát nyilvánvaló, hogy a legtöbb dolog belső működésével nem lehetek tisztában, ahogy feltételezem, dqdb kolléga sem böngészgette a Presto kódját..."Ezzel szemben a Presto-t (mivel zárt) senki nem tudhatja, hogy mennyire van összedrótozva a böngészővel."
Na, hát ez jó, ezek szerint az ezutáni mondókádban lényegében ugyanazt írtad le, mint én az előző bekezdésemben. Akkor mi a kérdésed?[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18632 üzenetére
Szerintem azért nem a non-modal dialogs-ról van szó, mert azt írja, hogy "JavaScript not blocking the UI thread", tehát itt ebből úgy tűnik, hogy csak arról beszél, hogy másik szálon fut a UI kezelése, tehát egy szarul megírt JavaScript-kód adott esetben nem blokkolhatja a teljes UI-t. Már csak azért is ez a valószínűbb, mert a non-modal dialogs régóta nem csak Operában van, a Firefox is lemásolta (szóval innentől nem Presto-specifikus), például egy alert()-nél simán lehet tabot váltani, plusz a szöveget is le lehet másolni a párbeszédablakból már jóideje (hogy konkrétan hányas verzió óta, azt nem tudom). Próbáld ki ezt FF-ban: http://jsfiddle.net/CSAXj/1/
Na mindegy, az idézett rész eléggé hiányos tartalmú ebben a formában ettől még.
"Az egyetlen logikus indok az lehet, hogy ha valaki azért jelöli ki a szót, hogy Backspace-szel kitörölje. Ilyenkor nem kell utána egy + Del-t nyomni (vagy Del esetén duplázni)."
Igen, de ez CSAK szövegbeviteli mezőkben (text típusú input, textarea) jön jól, egyébként meg SEHOL. Mert alapból az ember ugye nem tud törölni egy normál szövegből.
Úgy szoktam "megoldani", hogy kettőt klikkelek a szóra, és egy kicsit visszahúzom az egérkurzort, de elég zavaró, hogy ilyen hülye kerülő megoldásokhoz kell folyamodni. Egyébként SAJNOS a Firefox (Gecko) is átvette ezt az idiótaságot... (nem mintha használnám amúgy a FF-ot, csak nem vágom az okát, minek vették ezt át)"Egyébként meg nem csak a renderelésért felel, hanem a hálózatkezelésért is. (DNS caching, SPDY és társai) Vagy nem? Mert ha igen, akkor ennek igencsak része a .htaccess fájl feldolgozásának módja."
Hát a renderelő motornak nem kéne, hogy túl sok köze legyen a hálózatkezeléshez, a kettő tök más feladat.
A letöltött .htaccess tartalmának böngészőben történő megjelenítése pedig nem értem, hogy kapcsolódna a hálózatkezeléshez. A kettőnek nem sok köze van egymáshoz szintén.(#18634) Penge_4 :
ezt nem értettem, hogy érti, hogy nem támogatja a scope-ot, nem sok magyarázatot fűzött hozzá...[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18671 üzenetére
"Egyébként azt még én se tudom, hogy mi alapján dönti el, hogy melyik meghajtó lesz sda, sdb, sdc és így tovább. Mert IDE-nél még volt primary meg secondary master/slave, de SATA-nál már nincs. Meg USB-nél sem. Az meg aranyos, hogy a kötetcímke alapján adja az útvonalat, de Windows alatt a kötetcímkét szabadon módosígathattad, itt meg csúnya vége lehet neki."
Ha Windows-ban nyitsz Win+R segítségével egy diskmgmt.msc-t (Disk Management), akkor ott is láthatod, hogy van Disk 0, Disk 1, stb. Vagy ha nyitsz egy cmd-t, majd diskpart, aztán list disk, itt is hasonló számozásokkal vannak ellátva a háttértárak. Aztán select disk 0, list partition, itt is meghatározott számok vannak rendelve a partíciókhoz. Na jó, nem megyek tovább , de Windows-ban is lehet egyedileg azonosítani a lemezeket, partíciókat.
UNIX/Linux-ban az eszközök listázása, nyilvántartása ilyen szempontból egész más, mint Windows-nál; Linuxban az eszközök (device) a /dev alá mountolódnak (pl. /dev/sda1), itt nincs C:, D:, meg a többi, de ezeket az eszközöket olyan "felhasználóbarát" nevek alá mountolod pl. a /media elérési út "alá", amilyenre csak akarod, érdemes is így használni, nem pedig a /sda és a többit buzerálni, az csak olyan esetben kell, amikor particionálsz és hasonlók, amúgy teljesen jó az "alias". Ezt viszont a /etc/fstab-ban kell az eszköz UUID-je alapján megcsinálni, és fontos is, hogy UUID alapján rendelj hozzá "aliast", mert akkor nincs olyan gond, hogy máshova csatlakoztatod az eszközt, és máris hülyeség jön ki az egészből. Ja, és akár több ilyen elérési út alá is mountolhatod az eszközt, halál egyszerűen. Aztán ezeket úgy módosítgatod, ahogy akarod.
Valahogy így csináld:
http://linux.byexamples.com/archives/321/fstab-with-uuid/
Szerk.: kicsit kapkodósan írtam, úgyhogy nem mentem bele precízen a részletekbe, de a lényeg benne van. Meg a linkelt cikkben is le van írva.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Penge_4 #18679 üzenetére
"Ráadásul a Flash-t is beállíthatod On Demand-ra (hogy csak kattintásra töltődik be és csak az, amire kattintasz (például a bannerek nem, csak a videó)."
Ez Chrome-ban is beállítható.(#18673) Penge_4 :
https://help.ubuntu.com/8.04/installation-guide/i386/device-names.html
"SCSI ID address-wise""The first SCSI disk (SCSI ID address-wise) is named /dev/sda.
The second SCSI disk (address-wise) is named /dev/sdb, and so on.""The partitions on each disk are represented by appending a decimal number to the disk name: sda1 and sda2 represent the first and second partitions of the first SCSI disk drive in your system.
Here is a real-life example. Let's assume you have a system with 2 SCSI disks, one at SCSI address 2 and the other at SCSI address 4. The first disk (at address 2) is then named sda, and the second sdb. If the sda drive has 3 partitions on it, these will be named sda1, sda2, and sda3. The same applies to the sdb disk and its partitions.
Note that if you have two SCSI host bus adapters (i.e., controllers), the order of the drives can get confusing. The best solution in this case is to watch the boot messages, assuming you know the drive models and/or capacities.
Linux represents the primary partitions as the drive name, plus the numbers 1 through 4. For example, the first primary partition on the first IDE drive is /dev/hda1. The logical partitions are numbered starting at 5, so the first logical partition on that same drive is /dev/hda5. Remember that the extended partition, that is, the primary partition holding the logical partitions, is not usable by itself. This applies to SCSI disks as well as IDE disks."
"Modern Linux rebuilds /dev directory on bootup, and it scans scsi-hosts in the order they appear on the pci bus."
======
Lényeg esetedben: én azt tartanám elképzelhetőnek, hogy mivel bootoláskor alakul ki a sorrend, a pendrive eleve rá volt dugva a gépedre, és így inicializálási sorrendben a pendrive-od került előrébb.
Tesztelned kellene utólagos rádugással is.Sk8erPeter
-
Sk8erPeter
nagyúr
Meg gondolom láttad Penge fordítását is, amiben írja, hogy a WebKitnél konkrétan a Chromiumra alapoznak.
Mindenesetre ettől még a beállíthatóság tekintetében csak nem kúrják már el az Opera egyik legnagyobb erényét. Azért előre nem kell teljesen beparázni, elég lesz majd akkor idegeskedni, amikor esetleg bekövetkezik az, amitől tartottál, hogy elkrómosodik. (Remélhetőleg nem nagyon.)Amúgy kíváncsi vagyok, az általános böngészési tempót hogyan fogja érinteni a motorváltás.
====
Penge_4 :
megnézted a sorrenddel kapcsolatos cuccot Linuxon? Amúgy konkrétan milyen disztribúciót használsz?[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Ezzel a hozzászólással teljesen egyetértek, nekem sem lenne probléma, ha az INI-ket lecserélnék JSON-re, ahogy írtad, normális formában, nem minimalizáltan tök jól olvasható. És igen, létezik pl. http://jsbeautifier.org/, ha mégsem lenne az elsőre.
Nekem az is szimpatikus, hogy a Google Chrome extensionöknél JSON-formátumban kell megadni az alapadatokat (manifest.json), semmi baj nincs vele, teljesen jól olvasható, és így egymásba ágyazott formátum is megadható, ami ilyen esetben jóval olvashatóbb az INI-fájloknál.
Az XML csúnyább egy fokkal számomra, de attól még az is jól olvasható, az ellen sem tiltakoznék.
Csak ahogy írtad is, legyen egységes, és akkor ez a formátumprobléma megoldott kérdés.
Sőt, kívánom minden Opera usernek, hogy az új verzióknál az legyen a legnagyobb problémájuk, hogy az ő preferenciájuknak esetleg nem felel meg az XML- vagy JSON-formátum, az lenne a szép világ, egy jó böngészővel.Sk8erPeter
Új hozzászólás Aktív témák
Kérdés előtt olvasd el az
összefoglalót!
- Windows, Office licencek a legolcsóbban, egyenesen a Microsoft-tól - 2990 Ft-tól!
- Steames kulcsok jó áron eladóak!
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- PC JÁTÉKOK (OLCSÓ STEAM, EA , UPLAY KULCSOK ÉS SOKMINDEN MÁS IS 100% GARANCIA )
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen