visszajelzés: ezt mar en is megkerdeztem, csak feedback-kel

szoval nekem azert ment vissza mindig, mert a test pilot kiegeszito bekapcsolva volt.
remelhetoleg nalad is ez az ok.

aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D

Sziasztok!

Firefox 3.0.8-at hasznalok es valami nem stimmel vele. A picasa albumoknal a kis kepeket behozza, de mikor raklikkelek, bejon az oldal, minden ok, csak a nagy kep nincs ott. Semmilyen frissitest es kiterjesztest nem telepitettem mostanaban es IE8-al jonnek rendesen a nagy kepek is. Mi lehet a problema nem tudjatok veletlen?

első hsz -> diagnosztika

megszenvedve bar, de a vegere jutottam a with-es peldanak, amibe utolag beleraktam az XMLHttpRequest-et is.
es ahogy dqdb irja, jatszhatsz regexp-pel, substring-gel, de akar dom-mal is az informacio kinyerese erdekeben!

de kozben megy level is, kieg-et csatolva

[ Szerkesztve ]

aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D

Olvastam, de abbol melyiket csinaljam?

3.0.8? Miért nem frissíted?

Mondjuk az már ne mis támogatott, szóval a kérdés jogos.

Nincs vele semmi problemam, ez is most jott elo, nem tudom mi a baja. A 3.6-ost mar probaltam egyszer, de nagyitva van nalam a kep egy kicsit es az emotikonokat is nagyitotta, mosottak lettek, ez a 3.0.8 pedig nem csinalja.

Pedig az a valódi nagyítás. Egyébként emiatt én nem kockáztatnám, h. talán kritikus sebezhetőségű browsert használok.

Ok, de ugy csunyak, egyebkent erdekes, hogy ez a verzio meg beken hagyja oket. Nem tudod mi lehet ezzel a picasaval?

Mondom, első hsz -> diagnosztika. De az is lehet, h. a régi verzió miatt szar, sőt...

dqdb: Tudtommal nincsen ilyen opció Firefoxban.

[ Szerkesztve ]

Nemreg meg jo volt, szoval nem hiszem hogy emiatt van. Rohadt hosszu az a lista, nem tudom melyiket kell.

[link]

[ Szerkesztve ]

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Én hülye csak a beállításokban néztem. De ez így marhára nem jó, mert csak a szöveget nagyítja, így nem férnek el a divben, és máris gáz lesz.

(#15263) Lauda : azt a listát végig kell csinálni, ha nem tudod.

[ Szerkesztve ]

Akkor hagyom a fenebe, annyit nem szenvedek vele. Ha veletlen rajovok mi volt, akkor jelezni fogom.

szerk: oksi, megprobalom megint, hatha sikerul valamit alkotni a nagyitassal, de majd csak holnap.

[ Szerkesztve ]

Rendben, mindensetre nagyon erősen javaslom, h. térj át a legfrissebb verzióra.

Újabb félig-hülye kérdés: Van valami kieg, amivel a tabok egymásra dobálásával lehetne groupokat létrehozni, mint a legújabb béta Operánál?

Tab Candy - addonként nem, csak Fx4-ben érhető el.

Kozben frissitettem a 3.6.12-re. Az ugy jo, hogy a c-rol nem szedtem ki semmit, csak magat a programot uninstall, majd fel az ujat? Igy mindenem megmaradt. Erdekes modon az emotikonok se mosottak, lehet javitottak mar ezt? Ja es a picasa is megjavult.

Van több változatban Firefox -om Adobe Flash -el és a nélkűl, ha az utóbbit használom ugye megjelenik egy sáv ha olyan oldalra megyek amihez kell pl ez a Plug-in kell. Hogyan lehet ezt a felesleges sávot eltüntetni?

Manapság egy előnye van ha nem vagy szegény, színvonalasabb ellenségeid lehetnek

Tök jó.

zoltanz: about:config -ban hozz létre egy plugin.default_plugin_disabled logikai változót, és állítsd false-ra. Indítsd újra a Fx-et.

[ Szerkesztve ]

Köszi szépen. Lőn világosság.

Amúgy eleve false /Hamis/ értéknek hozza létre az FF.

Manapság egy előnye van ha nem vagy szegény, színvonalasabb ellenségeid lehetnek

Koszi! Egyebkent PH! alol nezve a forumot most is erdekesek az emotikonok, van amelyiknek negyzetes az oldala/alja, de nem szamit, gamepod alol szoktam nyomulni, ott meg tokeletes.

Ez oké, de ez nekem lassú, ezért kérdeztem, hogy úgy mint operában, hogy fogom a fülsávon egymásra dobom a tabokat és kész, lenyiló listában csinál belőlük egy csoportot. De ha nem, akkor marad ez

Igen, mert aki ezt hozzáadja, az false-nak akarja valszeg.

Lauda: Csinálj már egy screenshotot léci.

hunfatal: Nekem is tetszik az Opera megoldása, a Tab Candy sajnos sztem nem kiforott (meg lassú is), elég sokan gondolunk így a tesztelők között. A tabstripen jobb gombbal kattintva tudsz áthelyezni füleket a kontext menüvel, talán az a leggyorsabb. (áthelyezés új csoportba)

Sajna a drag and reorder se megy még, nem hogy az egymásra pakolászós csoportosítás.

[ Szerkesztve ]

Nekem is tetszik az Opera megoldása, a Tab Candy sajnos sztem nem kiforott (meg lassú is), elég sokan gondolunk így a tesztelők között.
A tab candy látványos, hasznos is lenne, de a megvalósítás valahogyan nem az igazi. Az Opera megoldása kevésbé látványos, de hatékonyabb. A kettő együtt alkotna egy tényleg tökéletes megoldást: tab stacking a megnyitott, olvasásra váró fülek összegyűjtésére, tab candy pedig a multidesktophoz hasonló független fülcsoportok létrehozására.

Operában a mai snapshotban szúrták el az én szememben a tab stackinget: automatikusan létrehoz egy csoportba az adott fülről nyitott összes fülnek. Remélem ez a módosítás csak opcionális lesz, mert most a downgrade-en agyalok.

Lauda: szerencsétlenül jön ki néha nem megfelelő felbontású képnél az átméretezés, Operában is néha megjelenik alul vagy jobb oldalt egy 1 pixel széles fekete vonal nagyítást használva.

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Teljesen egyetértek! A Tab Candyben még az zavar, h. teljesen olyan lenne, mintha nem is az Fx-hez tartozik, egy átlaguser számára rohadtul nem triviális, h. mit csinál, h. működik.

Lauda: itt nem is nagyítottál rá.

[ Szerkesztve ]

Most hogy nezem, igazad van es azert jo a gamepod alol, mert ott alapon van, a ph alatti meg kicsit nagyitva. Ha abbol is visszaveszek akkor jo, marad igy akkor.

dqdb jah, erdekes amugy, mert ha tovabb nagyitom, akkor a kockasodas eltunik, viszont egyre mosottabb lesz.

[ Szerkesztve ]

Egyszer játszadoztam vele, az eredeti kép méretétől és a nagyítás mértékétől függött, hogy megjelenik-e a keskeny fekete vonal (például 160%-nál és 180%-nál volt, de 170%-nál nem, és hasonlók). Én emiatt (és a rosszabb minőségű képnagyítás miatt) bináris használom a zoomot: vagy 100%, vagy 200%.

Most próbálkoztam kicsit Operában az eset reprodukálásával, de nem sikerült összehozni. Elképzelhető, hogy már javították.

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

Jo otlet, koszi szepen! Engem kicsit zavar, ha mosottak az avatarokes az emotikonok, szerintem hagyom igy alapon.

WonderCSabo Szia!

[ Szerkesztve ]

Sziasztok!

Van olyan Youtube userJS, amivel a chaneleken is automatikusan max felbontásra állítja a videót?

Yays!
Van amikor nem állítja át 1-2 chanelen, meg sima videóknál sem, de az esetek többségében működik. Ráférne egy frissítés.

Köszönöm, Te nagyon otthon vagy ebben a Youtube userJS témában. Ez műxik a sima Youtube oldalakon is? - a válasz igen, ott van az oldalon, LOL már én is write-only leszek.

Más:

egy nagyon fontos bug landolt most - az in-content UI!!!

[ Szerkesztve ]

Igen.

Bassus, nem megy Fx4-el. dqdb, esetleg ha van időd, ránézel?

in-content UIt akarok minden panelre (beállítások, letöltések, könyvjelző kezelő, stb) most! Sajna ez cask Fx.next-ben lesz benne...

[ Szerkesztve ]

Köszi, végülis egyelőre párhuzamosan használom a legújabb Opera buildel, meglátjuk majd, de az Opera villámgyors GUIja miatt még mindig inkább arra húzok. Mindkét böngészőnek megvannak az előnyei.

Ez a legújabb hourly-ban van benne, a holnap nightly buildben lesz benne.

Köszi.

hunfatal: Sajnos az Fx GUIja nem a leggyorsabb, ennek 2 oka van:

- XUL, XBL, CSS, SVG, JS-ben van megírva
- egy processzben fut a contenttel

Elhibázott lépésnek tartom, h. ez ellen az Fx4-ben nem tesznek semmit.

Beta8 kint van már?

Thanos was right.

Nincs. Blockers. Most vmi JPAKE tartja vissza, akármi is legyen az.

ha kijön, az ITCafé is megírja.

A JPAKE egy bizonyos jelszavas titkosítás, ami a Synchez kell, nem akarok belemenni, mert nem is értem pontosan.

Ez a legújabb hourly-ban van benne, a holnap nightly buildben lesz benne.
Köszi, akkor holnap mindenképpen ránézek, mert kíváncsi vagyok.

Sajnos az Fx GUIja nem a leggyorsabb, ennek 2 oka van:

- XUL, XBL, CSS, SVG, JS-ben van megírva
- egy processzben fut a contenttel

Elhibázott lépésnek tartom, h. ez ellen az Fx4-ben nem tesznek semmit.
A Jaegermonkey ezen is sokat segít, hiszen nem mindegy, hogy a keretrendszer milyen sebességgel fut. A könnyű bővíthetőséget a XUL teszi lehetővé, mert script alapú, de a XUL az oka annak is, hogy lassú a GUI, mert script alapú. A Jetpack alapú bővítmények minél gyorsabb elterjedése azért lenne jó, mert eléggé nagy tehermentesítést jelentene, ha eddigi script alapú közvetítő rétegek helyett az addonok közvetlenül natív kóddal kommunikálnának.

Az Fx4-ben érezhetően gyorsult az alkalmazás általános sebességérzete (nem szintetikus tesztekre gondolok, hanem - szépen szólva - a használat közben felhasználói élményfaktorra), egy gyárilag beépített smooth scrollal és egy rakás kényelmet szolgáló bővítménnyel tudná hozni azt az UX-et, ami miatt az Operát szeretem.

Azon csodálkozom, hogy eddig nem írtak XUL → natív kód közötti fordítót (vagy csak nem tudok róla).

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

csak a jetpack-os reszre:
szerintem jetpack meg keves ahhoz, hogy komolyabb kiegeszitoket lehessen benne/vele irni.

remelem tevedek.

aláírás1: csocsó-vesztes vagyok, főleg a Bog és Bocha páros ellen, aláírás2: van mobilarénáskulcstartóm! :D

A Jaegermonkey ezen semmit se segít. Egyrészt mert ki is van kapcsolva a chrome-ra... Másrészt a JS team tesztelte, és a JM nem volt gyorsabb a chrome-on a TM-nél. Persze a TM Fx4-es változata magában gyorsabb az Fx3.x-nál, szóval vmennyire igazad van.

Természetsen egyetértek, az Fx4 gyorsabb, reszponzívabb, az egész UX sokkal jobb mint az Fx3.x-nél. De sajnos az előbb említett okok miatt szörnyeb be tud lassulni. Egy pl.:

- töltesz egy odlalt
- közben megnyitsz egy új fület
- az animációja szaggatni fog, mivel a JS motort lefoglalja az oldal betöltésekor futó szrkiptek

Ezt pl. chrome-content processz szeparációval totál lehetne oldani. És meg is fogják, de az Electrolysison való munka csak egy pár napja kezdődött el...

Persze, h. marha jó dolog a XUL, talán a legjobb dolog az Fx-ben, de sajnos ez a nagy hátulütője van.

Azon csodálkozom, hogy eddig nem írtak XUL → natív kód közötti fordítót (vagy csak nem tudok róla).

Tudtommal nem, bár hirtelen nem is tudom elképzelni, hogyan működne úgy (bár a JS fordítókat se tudtam ezelőtt...)

A Jetpack alapú bővítmények minél gyorsabb elterjedése azért lenne jó, mert eléggé nagy tehermentesítést jelentene, ha eddigi script alapú közvetítő rétegek helyett az addonok közvetlenül natív kóddal kommunikálnának.

ööö, milyen natív kód?

xabolcs: Nem, egyáltalán nem tévedsz, a jetpack nem tud mélyebben belenyúlni az Fx-be, egy picit kibővített userJS-ek ezek, a lényeg itt az egyszerű írhatóságon van.

A Jaegermonkey ezen semmit se segít. Egyrészt mert ki is van kapcsolva a chrome-ra...
Na, ezt nem tudtam. Nekem annyira természetesnek tűnt, hogy az Fx sebességérzetét itt tudják a legjobban növelni, ergo külön optimalizálják is erre, de nem.

Ezt pl. chrome-content processz szeparációval totál lehetne oldani. És meg is fogják, de az Electrolysison való munka csak egy pár napja kezdődött el...
Sajnos másnak sem jön be teljesen a CPU idő thread-szintű igazságos elosztása: Opera alatt ha az egyik fülben megnyitok egy 500+ hozzászólásos blog.hu oldalt, akkor az egész böngésző képes lemerevedni pár másodpercre. Betöltés után már minden szép és jó, de valahol az oldal feldolgozása megállítja az Operát nálam.

A Jetpack alapú bővítmények minél gyorsabb elterjedése azért lenne jó, mert eléggé nagy tehermentesítést jelentene, ha eddigi script alapú közvetítő rétegek helyett az addonok közvetlenül natív kóddal kommunikálnának.

ööö, milyen natív kód?
Akkor én téves feltételezésben éltem Végig azt hittem (már nem emlékszem, honnan szedtem ...), hogy a Jetpack API Fx oldali felületét natívan írják meg, hogy bár limitáltabb a mostani addonoknál, cserébe kisebb erőforrásigénnyel képes működni (és itt CPU-ra gondolok elsősorban, nem memóriára). bónuszként meg támogatja a dinamikus betöltést. Lehet, hogy el kellene olvasnom egy mélyebb szintű Jetpack leírást

tAm6DAHNIbRMzSEARWxtZW50ZW0gdmFka5RydIJ6bmkuDQoNClOBc4Ek

De itt nem csak threadeket, hanem külön processzeket fognak használni, mint a plugin-container esetében.

Nos, lehet, h. igazad van, és én nem tudok róla. Mindenesetre Google semmi ilyesmit nem dob ki.