Hirdetés
-
2024 - Alig egy nap múlva jön a Sony új State of Play előadása
gp Az előzetes tervek szerint több mint 30 perces lesz a műsor.
-
Felpörög az asztali CPU-piac a következő pár hónapban
ph A friss pletykák szerint az AMD és az Intel is a frissítésein dolgozik.
-
Egyre több európai használja a Telegramot, ezért megkereste az EU
it Hamarosan sokkal szigorúbb szabályozás alá esik az EU-ban a Telegram, mivel egyre több a helyi felhasználója.
-
PROHARDVER!
Új hozzászólás Aktív témák
-
Penge_4
veterán
válasz
LonGleY
#19844
üzenetére
Ja, hogy H-IPS. Azon lehet, hogy nekem se tetszene. Dzsunka TN panelen viszont más a helyzet.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Kiegészítőkkel úgy finomhangolod, ahogy akarod.
(#19391) dqdb: Van egy apró gáz a kiegészítőddel. Textboxokban is aktiválódik a + lenyomására. Ezt nem tudnád valahogy kiküszöbölni?
[ Szerkesztve ]
-
Penge_4
veterán
Egy Desktop Team-es kommentben bukkantam rá, hogy az Opera oldalain milyen érdekes változások történtek.
A korábbi oldal: http://web.archive.org/web/20130305084711/http://business.opera.com/company/vision
És a mostani oldal: http://business.opera.com/company/vision
Az még oké, hogy feladták minden korábbi elveiket és mintha valami rossz kapitalista kiáltványt olvasnék, de hogy még a környezetvédelmi policy-jüket is leszedték... Tényleg ennyire kell a pénz a részvényeseknek?
-
#19900
Penge_4
veterán
Sk8erPeter
#19882
Penge_4
veterán
válasz
Sk8erPeter
#19882
üzenetére
"Ha volt már részed webfejlesztésben, akkor tudod jól, hogy a böngészők rettenetesen toleránsak, túlzottan is, igyekeznek a legundorítóbb tákolmány kódból is kihozni valamit, valamilyen módon megjeleníteni azt, hogy ezzel még egy idiótának is lehetőséget biztosítsanak a zzzinterneten való megjelenésre."
Pedig gondolj bele, ha még az XML-től is szigorúbban ragaszkodnának a szabványokhoz, akkor milyen lehetőségek lennének. Akár 50 megát zabálva képes lenne bármilyen böngésző villámgyorsan megnyitni 10-20-30 weboldalt. A RegExp nem csak az Adblockban és a Linkifierben jelent baromi nagy memória és CPU igényt, hanem akkor is, ha a motornak kell renderelés közben/előtt tesztelgetnie a különböző stringeket és hibákat és on-the-fly javítania.
Egyébként még egy Chrome fejlesztőnek is pozitív véleménye volt a Presto-ról.
"Ha Te is a testreszabhatóság miatt használtad annak idején a Prestós Operát, emiatt tartottál ki mellette, akkor viszont meglepő, hogy most piedesztálra emeled az új Chromium-koppintást."
Egyébként az a vicces, hogy a nagy, nemzetközi My Operán alig van ember, aki kiállna az új Opera mellett. Még a legpozitívabb kritika is annyi, hogy optimistán néz a jövőbe és várja, hogy x meg y funkciókat visszapakolják.
A GS Statcounter-en Hungary-ra szűrve is érdemes megnézni a júniusi peak-et. Nem semmi. Mindenhol máshol meg inkább csökkent a részesedése.(#19883) LonGleY: "Csak néha kiakadok, hogy mennyire nem megy pár dolog a v12-vel, és hogy alapfunkciókkal kell szívózni benne."
Akármilyen hihetetlen, én sem örülök, hogy pl. a Magyar Opera blogot vagy jegyzetek panelen írom meg forráskódban, vagy Chrome alól szerkesztem, mert Operában a forráskód nézet szar, lassú, villog és minden baja van neki. Pl. ha elrontok egy tag-et, akkor nem lehet kitörölni, meg kijelölni sem, hogy kitöröljem. Berakja a kurzort a </p> közé, majd Del-re és Backspace-re a szöveget törli két sorral feljebb/lejjebb és egyéb easter egg-ek.
De ettől még képes vagyok elvonatkoztatni a Chrome hype-tól és belátni, hogy a Presto bár elhanyagolt motor volt, de én azért nem temetném és nem örvendeznék.
"Máskülönben úgyse lesz open source. Ha pedig mégis (ami kizárt), akkor abból új böngészőt faragni, ami még működik is a mai/holnapi oldalakkal.. eleve reménytelen."
Te nem érzed itt az ellentmondást? Ha valami annyira szar, amilyennek lefestették és teljesen új böngészőt írtak a 0-ról, akkor miért is kéne nekik félniük a forráskód kiadásától? Kiadják, mindenki látja, hogy szar, javíthatatlan, kész, finító.
Ellenben akkor jelentene nem kis problémát számukra a forráskód kiadása, ha hazudtak. Mert akkor a nyílt forráskódú közösség kapna egy korszakalkotó motort, amit kiganézna és nagyobbat robbanna, mint anno a KHTML. Mindenki azt a motort akarná. Az ChrOpera pedig szépen eltűnne a süllyesztőbe, ha nyílt lenne, akkor talán még a Mozilla is átállna rá.
-
#19901
Penge_4
veterán
Sk8erPeter
#19884
Penge_4
veterán
válasz
Sk8erPeter
#19884
üzenetére
"Láttál bárhol komolyabb Opera-reklámozást? Én nem."
Franciaországban még a metrómegállóban is. Csak túl diszkrét és elnyomja a sok Chrome reklám.
"Ezzel együtt természetesen nyilván maradt rengeteg örökség a kódban, amit előbb-utóbb újra kellett volna írni vagy pedig kidobni"
Most ezeknek a korát éljük. HTTP nem jó, lesz helyette SPDY, TCP megint nem jó, lesz helyette QUIC, JavaScript se jó, lesz helyette Dart. Az X is 30+ évig szolgált, aztán most lesz helyette Wayland (ami még a jobbik eset a tapibaszos Mir helyett). De ezt legalább nem a Google fejleszti, nem úgy, mint az első hármat.
(#19887) LonGleY: "A Blink önmagában nem akadályozza a fejlődést, a hozzáállásuk az, ami megkérdőjelezhető."
Miért, talán ismered a forráskódját?
(#19899) Sk8erPeter: "habár hozzáteszem, azért az durva, hogy ilyen szinten össze volt drótozva minden mindennel, hogy számtalan feature-t képtelenek lettek volna átvenni, mert több idő lett volna toldozgatni-foltozgatni-korrigálni Blinkre, mint újraírni"
Anno Linus Torvalds-nak is volt ilyen vitája, amikor ő képviselte a mindent egybe, összedrótozva (monolitikus) álláspontot a professzor meg a másikat. Aztán azóta melyik kernel is van a szerverek döntő hányadán és melyik kernel él ha alacsony részesedéssel is, de a mai napig a desktop szegmensben is?
Mondtam már, hogy a modulatitás okozta absztrakciós rétegekkel csínján kell bánni, mert nem mindenkinek van brutális teljesítményű szuperszámítógépe otthon. A natív, beépített megoldások mindig gyorsabbak és erőforráskímélőbbek lesznek a karácsonyfás megoldásoknál.
Most egy My Operás komment eszembe juttatta a Search panelt Operában, mint elavult fícsört. Évek óta nem is találkoztam vele. Még valamikor 2008-2009 körül szerkesztgettem saját gombokat, amivel így egy kattintással lehetett MDI módban, osztott képernyőn több keresővel keresni egyszerre. Aztán valahogy feledésbe merült. De a lényeg: Bántott ez a funkció valakit? Fájt valakinek? Nem, sokan a létezéséről sem tudtak.
Amíg az Opera telepítője és telepítve is kisebb volt, mint az összes többi böngésző, amíg memóriaigényben, CPU igényben is a többiek alatt maradt (vagy az adaptív memóriakezelésének köszönhetően gyorsabb volt több memóriával szerelt gépeken), addig engem az sem érdekelt volna, ha egy komplett Linux kernel van beleintegrálva. A beépített funkciói közül is a torrentkliens volt egyedül tolakodó.
"Na igen, jó bizonyíték arra, hogy nem kell power usernek lenni ahhoz, hogy valaki hiányolja a könyvjelzőket és az akárhova pakolható könyvjelzősávot..."
Azt valószínűnek tartom, hogy a könyvjelzők visszakerülnek valamilyen formában, csak amiatt aggódom, hogy nem-e olyan ratyi lesz, mint Chrome-ban, hogy nincs sem tags/nickname, sem description, sem metaadatok (visited date, created date, modified date). illetve faszerkezet, oldalsáv meg sorba rendezési opciók. Ezek nekem mind kellenek.
[ Szerkesztve ]
-
#19915
Penge_4
veterán
Sk8erPeter
#19909
Penge_4
veterán
válasz
Sk8erPeter
#19909
üzenetére
"A rétegezés vagy valamilyen szintű absztrakció, feladatok szeparálása azért nem feltétlenül egyenlő a karácsonyfa-díszítéssel"
A legújabb Opera 15 egy sima Chromium frissítés miatt lett 30 mega helyett 40. Erről beszéltem többek között.
"Viszont abban az érvben nem látok rációt, amit írtál egyszer, hogy az, hogy a Presto-t nem teszik nyílt forráskódúvá, már önmagában bizonyíték lenne arra, hogy nincsenek benne fájó tákolmányok."
Nem arról van szó, hogy ne lettek volna benne fájó pontok, hanem arról, hogy nem menthetetlen. A kettő között azért van némi árnyalat. Tehát az egyik oldalon:
Presto kiganézása és az oldalkompatibilitás megoldása
A másik oldalon pedig:
Chromium API-ra visszaépíteni az Operás fícsöröket az oldalsávtól kezdve az eszköztár konfiguráción át egészen az M2-ig.Ezt a kettőt egymással szemben állítva én a Presto-t hoznám ki győztesen. Annyira szar nem lehet az a motor, hogy nehezebb legyen megjavítani és versenyképessé tenni, mint egy kőbalta böngésző köré írni rengeteg fícsört.
Ennek fényében pedig a Chromium API akkor jobb választás a Presto-tól, ha a cég feltett szándéka, hogy butaböngészőt akar innentől terjeszteni.
-
Penge_4
veterán
válasz
LonGleY
#19923
üzenetére
"míg a Wand jónéhány oldalon nem működött, addig a LastPass azokat is lekezeli (pl. a Citibank virtual keyboard-os belépője stb.)."
Ez az egy előnye van a LastPass-nak (és az egyedül Firefoxra elérhető Saved Password Editor-nak). De ezért az előnyért, leginkább semmilyen előnyért nem bíznék egyetlen third party felhőre sem jelszavakat. Most őszintén, minek nagyobb az esélye? Hogy valaki betör az otthonomba, hozzáfér fizikálisan a gépemhez, majd ellopja a jelszavaimat, vagy az, hogy felnyomnak egy felhős, központi jelszókezelő szolgáltatót és jól lenyúlják az ember pénzét?
Nem a PH-s accountomat féltem, azzal nem mennek semmire, maximum spameket tudnak küldeni az e-mail címemre. Azokat félteném, amiket nem jegyez meg a beépített kezelő (SSL-es oldalak), mert azokat offline még lehetne tárolni, de online semmiképp. Inkább olyan cucc kéne Operához is, mint a Saved Password Editor. Egyszer elmented, onnantól felkínálja.
(#19924) slashing: Wand-nál csak third-party szoftverrel tudtad visszafejteni a jelszavakat, azt is csak akkor, ha nem volt mesterjelszó. Az összes többi böngészőben látható a jelszó két kattintással.
(#19926) LonGleY: "Ha feltörik az adatbázist, akkor sem jutnak a jelszavaidhoz, mert az lokálban van dekódolva."
Na ne vicceljünk már. Ha feltörik a szervert, akkor
1. Manipulálhatják azt, hogyan érkezzenek meg a jelszavak.
2. Valahol tárolják azt a mesterjelszót, vagy annak a hash-ét, amivel akár webes felületen is dekódolhatod a jelszavadat.(#19933) LonGleY: "Hát, hajrá. :] Szerintem egyszerűbb a géphez jutni. Én már számtalanszor csórtam el így mások jelszavát."
Az átlaguserekéhez biztos. De próbálnál az enyémhez hozzájutni.
(#19934) slashing: De miért engedsz embert a gépedhez?
-
#19944
Penge_4
veterán
Sk8erPeter
#19941
Penge_4
veterán
válasz
Sk8erPeter
#19941
üzenetére
"(épp ezért hirdettek versenyt 10000$ jutalommal, akinek sikerül értelmes adatot kinyernie (úgy, hogy ugyanazt láthatja, mint a tulajok), megkapja a lóvét"
És biztos lehetsz benne, hogy a tulajok amellett, hogy normál esetben értelmetlen karaktersorozatot látnak, nem rendelkeznek valami visszafejtő algoritmussal, amit elfelejtettek a versenyben résztvevők rendelkezésére bocsátani? Vagy az NSA nem kapott ilyen visszafejtő algoritmust, amivel bárkinek vissza tudja fejteni az értelmetlen karakterhalmazát értelmes adattá?
A centralizált akkor is centralizált marad, ha bármilyen titkosítást alkalmazol. És ma még talán nem, de ha meghatározó szereplő marad a piacon, akkor jön az NSA és megkörnyékezi, hogy ők bizony szeretnének valamilyen módon belelátni a dolgokba.
Nevezz paranoidnak, de én aszerint az ősi szabály szerint élek, hogy ami kikerült a webre, az onnantól már nem a tiéd és potenciális akár teljesen publikus is lehet.
Feltörhetetlen titkosítás meg különben sincs, csak kevés számítási kapacitás (ami bármikor megváltozhat a kvantumszámítógépek megjelenésével).
-
Penge_4
veterán
Remélem azért, mert meg akarják csinálni normálisan.
ps: Viszont aktiválták a default Advanced Shortcuts-t (ha bekapcsolod a beállításokban), szóval már natívan mennek a következők:
- Ctrl+Tab-os aktivációs fülváltás (ezt opera:flags alatt kell engedélyezni)
+/-*-os Zoom (ami nem akad a Rich Text szerkesztőkkel)
- 1-es és 2-es fülváltás. -
Penge_4
veterán
válasz
Dr_Syrex
#19997
üzenetére
"de cserélni sem szeretném idő előtt garanciában "
Az elhasználódásra gondolom nem vonatkozik a garancia, mert ha így lenne, akkor a garancia lejárta előtt mindenki vadul futtatna rajta benchmarkolós progikat és szépen leperegne az írási limit, majd vinné vissza, hogy ingyen adjanak neki egy újat.
-
Penge_4
veterán
0x006459e0: int $3
Modules:
Module Address Debug info Name (134 modules)
PE 400000- 2b68000 Export opera
PE 4ad00000-4b682000 Deferred icudt
ELF 7ac00000-7ac60000 Deferred riched20<elf>
\-PE 7ac10000-7ac60000 \ riched20
ELF 7b800000-7ba5b000 Deferred kernel32<elf>
\-PE 7b810000-7ba5b000 \ kernel32
ELF 7bc00000-7bcd9000 Dwarf ntdll<elf>
\-PE 7bc10000-7bcd9000 \ ntdll
ELF 7bf00000-7bf04000 Deferred <wine-loader>
ELF 7d447000-7d44c000 Deferred libgpg-error.so.0
ELF 7d44c000-7d463000 Deferred libresolv.so.2
ELF 7d463000-7d4ad000 Deferred libdbus-1.so.3
ELF 7d4ad000-7d4c1000 Deferred libp11-kit.so.0
ELF 7d4c1000-7d4d3000 Deferred libtasn1.so.3
ELF 7d4d3000-7d557000 Deferred libgcrypt.so.11
ELF 7d557000-7d560000 Deferred libkrb5support.so.0
ELF 7d560000-7d588000 Deferred libk5crypto.so.3
ELF 7d588000-7d656000 Deferred libkrb5.so.3
ELF 7d656000-7d668000 Deferred libavahi-client.so.3
ELF 7d668000-7d72d000 Deferred libgnutls.so.26
ELF 7d72d000-7d76a000 Deferred libgssapi_krb5.so.2
ELF 7d76a000-7d7c9000 Deferred libcups.so.2
ELF 7d7d3000-7d7e6000 Deferred gnome-keyring-pkcs11.so
ELF 7d7e6000-7d81c000 Deferred uxtheme<elf>
\-PE 7d7f0000-7d81c000 \ uxtheme
ELF 7d81c000-7d823000 Deferred libxfixes.so.3
ELF 7d823000-7d82e000 Deferred libxcursor.so.1
ELF 7d82e000-7d83e000 Deferred libxi.so.6
ELF 7d83e000-7d842000 Deferred libxcomposite.so.1
ELF 7d842000-7d84d000 Deferred libxrandr.so.2
ELF 7d84d000-7d857000 Deferred libxrender.so.1
ELF 7d857000-7d85d000 Deferred libxxf86vm.so.1
ELF 7d85d000-7d861000 Deferred libxinerama.so.1
ELF 7d861000-7d868000 Deferred libxdmcp.so.6
ELF 7d868000-7d86c000 Deferred libxau.so.6
ELF 7d86c000-7d88e000 Deferred libxcb.so.1
ELF 7d88e000-7d894000 Deferred libuuid.so.1
ELF 7d894000-7d8ae000 Deferred libice.so.6
ELF 7d8ae000-7d9e5000 Deferred libx11.so.6
ELF 7d9e5000-7d9f7000 Deferred libxext.so.6
ELF 7d9f7000-7da00000 Deferred libsm.so.6
ELF 7da04000-7da08000 Deferred libkeyutils.so.1
ELF 7da08000-7da0d000 Deferred libcom_err.so.2
ELF 7da0d000-7da1b000 Deferred libavahi-common.so.3
ELF 7da1d000-7daaf000 Deferred winex11<elf>
\-PE 7da30000-7daaf000 \ winex11
ELF 7daff000-7db27000 Deferred libexpat.so.1
ELF 7db27000-7db60000 Deferred libfontconfig.so.1
ELF 7db60000-7dbfb000 Deferred libfreetype.so.6
ELF 7dc18000-7dc88000 Deferred setupapi<elf>
\-PE 7dc20000-7dc88000 \ setupapi
ELF 7dc88000-7dcbe000 Deferred wintrust<elf>
\-PE 7dc90000-7dcbe000 \ wintrust
ELF 7dcbe000-7dce4000 Deferred iphlpapi<elf>
\-PE 7dcc0000-7dce4000 \ iphlpapi
ELF 7dce4000-7dd11000 Deferred netapi32<elf>
\-PE 7dcf0000-7dd11000 \ netapi32
ELF 7dd11000-7dd44000 Deferred secur32<elf>
\-PE 7dd20000-7dd44000 \ secur32
ELF 7dd44000-7dd65000 Deferred oleacc<elf>
\-PE 7dd50000-7dd65000 \ oleacc
ELF 7dd65000-7dd89000 Deferred imm32<elf>
\-PE 7dd70000-7dd89000 \ imm32
ELF 7dd89000-7ddb4000 Deferred msacm32<elf>
\-PE 7dd90000-7ddb4000 \ msacm32
ELF 7ddb4000-7de6d000 Deferred winmm<elf>
\-PE 7ddc0000-7de6d000 \ winmm
ELF 7de6d000-7de81000 Deferred psapi<elf>
\-PE 7de70000-7de81000 \ psapi
ELF 7de81000-7dec3000 Deferred usp10<elf>
\-PE 7de90000-7dec3000 \ usp10
ELF 7dec3000-7def9000 Deferred ws2_32<elf>
\-PE 7ded0000-7def9000 \ ws2_32
ELF 7def9000-7df11000 Deferred wtsapi32<elf>
\-PE 7df00000-7df11000 \ wtsapi32
ELF 7df11000-7df4e000 Deferred winhttp<elf>
\-PE 7df20000-7df4e000 \ winhttp
ELF 7df4e000-7df75000 Deferred mpr<elf>
\-PE 7df50000-7df75000 \ mpr
ELF 7df75000-7df8e000 Deferred libz.so.1
ELF 7df96000-7dfab000 Deferred dhcpcsvc<elf>
\-PE 7dfa0000-7dfab000 \ dhcpcsvc
ELF 7dfab000-7e026000 Deferred wininet<elf>
\-PE 7dfb0000-7e026000 \ wininet
ELF 7e026000-7e15a000 Deferred oleaut32<elf>
\-PE 7e040000-7e15a000 \ oleaut32
ELF 7e15a000-7e1fd000 Deferred urlmon<elf>
\-PE 7e170000-7e1fd000 \ urlmon
ELF 7e1fd000-7e215000 Deferred userenv<elf>
\-PE 7e200000-7e215000 \ userenv
ELF 7e215000-7e255000 Deferred winspool<elf>
\-PE 7e220000-7e255000 \ winspool
ELF 7e255000-7e2cf000 Deferred shlwapi<elf>
\-PE 7e260000-7e2cf000 \ shlwapi
ELF 7e2cf000-7e502000 Deferred shell32<elf>
\-PE 7e2e0000-7e502000 \ shell32
ELF 7e502000-7e5ee000 Deferred comdlg32<elf>
\-PE 7e510000-7e5ee000 \ comdlg32
ELF 7e5ee000-7e6f6000 Deferred comctl32<elf>
\-PE 7e600000-7e6f6000 \ comctl32
ELF 7e6f6000-7e777000 Deferred rpcrt4<elf>
\-PE 7e700000-7e777000 \ rpcrt4
ELF 7e777000-7e8b3000 Deferred ole32<elf>
\-PE 7e790000-7e8b3000 \ ole32
ELF 7e8b3000-7e922000 Deferred advapi32<elf>
\-PE 7e8c0000-7e922000 \ advapi32
ELF 7e922000-7ea40000 Deferred gdi32<elf>
\-PE 7e930000-7ea40000 \ gdi32
ELF 7ea40000-7eb9b000 Deferred user32<elf>
\-PE 7ea50000-7eb9b000 \ user32
ELF 7eb9b000-7ec69000 Deferred crypt32<elf>
\-PE 7eba0000-7ec69000 \ crypt32
ELF 7ec69000-7ed5c000 Deferred cryptui<elf>
\-PE 7ec70000-7ed5c000 \ cryptui
ELF 7ed5c000-7ed69000 Deferred libnss_files.so.2
ELF 7ed69000-7ed75000 Deferred libnss_nis.so.2
ELF 7ed75000-7ed8e000 Deferred libnsl.so.1
ELF 7ed8e000-7ed97000 Deferred libnss_compat.so.2
ELF 7ef97000-7efda000 Deferred libm.so.6
ELF 7efda000-7efe3000 Deferred librt.so.1
ELF 7efe6000-7f000000 Deferred version<elf>
\-PE 7eff0000-7f000000 \ version
ELF f7186000-f71ba000 Deferred msctf<elf>
\-PE f7190000-f71ba000 \ msctf
ELF f7306000-f7323000 Deferred libgcc_s.so.1
ELF f7327000-f7340000 Deferred msftedit<elf>
\-PE f7330000-f7340000 \ msftedit
ELF f7344000-f7349000 Deferred libdl.so.2
ELF f7349000-f74fc000 Dwarf libc.so.6
ELF f74fd000-f7518000 Dwarf libpthread.so.0
ELF f7529000-f7530000 Deferred libnss_dns.so.2
ELF f7535000-f76eb000 Dwarf libwine.so.1
ELF f76ed000-f770f000 Deferred ld-linux.so.2
ELF f770f000-f7710000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
0000000e services.exe
0000001e 0
0000001d 0
00000014 0
00000010 0
0000000f 0
00000012 winedevice.exe
0000001b 0
00000018 0
00000017 0
00000013 0
00000019 plugplay.exe
00000020 0
0000001f 0
0000001a 0
00000021 explorer.exe
00000023 0
00000022 0
00000035 (D) C:\Program Files (x86)\Opera Next\16.0.1196.14\opera.exe
00000053 0
00000050 0
0000004f 0
0000004e 0
0000004d 0
0000004a 0
00000031 0
00000032 0
0000003b 0
00000034 0
0000002e 0
0000002f 0
00000025 0
00000026 0
0000002b 0
00000030 0
0000002c 0
0000002d 0
00000029 0
00000028 0
00000027 0
0000000d 0
00000009 0
0000000b 0 <==
00000047 0
00000046 0
00000045 0
00000044 0
00000043 0
00000042 0
00000041 0
00000040 0
0000003f 0
0000003e 0
0000003d 0
0000003c 0
00000036 0
00000037 opera_crashreporter.exe
0000003a 0
00000039 0
00000038 0
System information:
Wine build: wine-1.6-rc5
Platform: i386 (WOW64)
Host system: Linux
Host version: 3.8.0-26-genericCsak nem akar működni még 1.6-os Wine alatt sem...
-
Penge_4
veterán
1. Mennyivel használ ez kevesebb RAM-ot, mint a Stylish és a TamperMonkey?
2. A matches-nél mi a feketelistás megfelelő? Amikor mindenhol le akarom futtatni, kivéve néhány oldalon, akkor megadhatok sima csillagot a matches-nél (ami required a dokumentáció szerint) és az exclude_matches-nél (ami pedig csak optional) a kivételeket?
3. Működik *://www.example.com/* helyett úgy is, hogy http*://www.example.com/* vagy csak az első és utolsó karakter lehet csillag? Mert van, ahol csak http-re és https-re akarom alkalmazni, ftp-re nem.
4. A mindenhol működő mód vonatkozik a localhostra is, amikor pl. helyi html/mht fájlt nyitok meg?A content script limitations-nál nem tetszik ez a rész "Use variables or functions defined by web pages or by other content scripts"
Akkor innentől nem lehet kicsapni oldalakon azt a scriptet, ami ellenőrzi, hogy használsz-e adblockot vagy sem? Ez így nagyon behatárolja a lehetőségeket.
A document_start, document_end és document_idle elég soványnak tűnik az Operás userJS kezelés után. Az abc sorrend szerinti végrehajtás azonos ütemezés esetén itt is működik?
-
Penge_4
veterán
"Ez a linkelt példához hasonló esetektől eltekintve egyáltalán nem ajánlott megoldás, ezt a viselkedést ma már általában külön kell engedélyezni."
Aha, szóval akkor ezért lett hirtelen ez ritka, nem pedig azért, mert az üzemeltetők lettek hozzáértőbbek és biztonságtudatosabbak. Régebben gyakoribb volt és őszintén szólva tök jó volt, hogy egy csomó tartalomhoz hozzá lehetett férni a szarul konfigurált webszervereken (főleg fizetős oldalakon volt jó).
Most meg csak akkor, ha eltalálod a pontos URL-t. Néha még az is tiltva van.
"a visszaadott hiba 403 (nincsen jogosultság) vagy 404 (nem létezik), mindkettő jogos és mindkettőre van bőven példa."
403-nál van olyan, hogy belekattintasz az URL sávba, majd nyomsz egy Entert (gondolom valami cookie eltárolás vagy referrer lehet a háttérben) utána már működik. Általában hotlinkelést tiltó képeknél figyelhető ez meg.
(#20022) Orlin: Nem egészen normális. Normális esetben csak az eggyel korábbi verziót kéne megtartania, a többit törölni.
[ Szerkesztve ]
-
Penge_4
veterán
"Helyi fájlokra, ha így adod meg, és beállítod, hogy a file:// címekre is működjön, akkor menni fog:"
Tehát hiába a "*://*/*", a file://-t is külön hozzá kell adnom?
"A sorrendet az határozza meg, hogy te milyen sorrendben definiáltad a scripteket."
Mármint a manifest.json-ban, felülről-lefelé?
"Az pozitívum a szememben, hogy a szűrőkön fennakadó scriptek már eleve le sem futnak ellentétben a @include-tól mentes user JS-ekkel."
Ezt nem értem. Itt a manifest.json-ban definiálod ugyanazt, amit sima userJS-eknél UserJS specifikusan a headerben include-okkal és exclude-okkal. Szóval nem teljesen mindegy, hogy egy központi helyen definiálod, hogy hol futhat le, vagy egyenként? Amit a manifest.json-ban úgy definiálsz, hogy mindenhol fusson le, az ugyanúgy mindenhol lefut, amit pedig úgy, hogy csak adott oldalakon, az ugyanúgy nem, mint a UserJS-ek sem, ahol exclude-olva voltak az oldalak, vagy nem volt egyezés az include-ra.
Amúgy a match meg az include között mi a különbség? Mert UserJS-ben is láttam már
// @match http://example.com/*-t -
#20042
Penge_4
veterán
Sk8erPeter
#20041
Penge_4
veterán
válasz
Sk8erPeter
#20041
üzenetére
"Hát az elég vad lenne, ha a Prohardveren fájlokba írogatnák, és azokból olvasgatnák a cikkeket adatbázisba írogatás és abból olvasás helyett..."
Miért? A hozzászólásoknál (hsz_20001-20050.html vagy friss.html) még oké, mivel dinamikus tartalom. De a cikkek statikusak maradnak. Szóval akár simán lehetne 1-1 statikusan behívott .html fájl is, nem?
(#20034) dqdb: "Ezek szerint komolyan gondolták, és tényleg elhitték, hogy nincsen szükség könyvjelzőkre egy böngészőben."
Mindig újra és újra képes vagyok meglepődni azon, hogy egyes fejlesztők (meg úgy főleg a menedzsment) mennyire el vannak rugaszkodva a valóságtól és mennyire halvány fingjuk nincs a felhasználási szokásokról, holott nekik ott van egy baromi átfogó statisztika is, ami torzít, de azért mégis statisztika. Mi pedig maximum a környezetünk felhasználási szokásaiból tudunk következtetéseket levonni.
[ Szerkesztve ]
-
#20046
Penge_4
veterán
Sk8erPeter
#20045
Penge_4
veterán
válasz
Sk8erPeter
#20045
üzenetére
"Google pedig mindkettőt bejárhatja, és azt duplikált tartalomnak érzékelheti, és azt nem szereti (bünti a találati listában)."
Szerintem van már annyira fejlett az algoritmusa, hogy a csak www-ben különböző (de még a www2, www3 és társai) URL-eket nem csaló duplikátumnak érzékeli, hanem balfasz duplikátumnak, ezért nem jár érte bünti. Elvégre a sponsored linkeket leszámítva a Google-nak az az érdeke, hogy azokat a népszerűbb oldalakat hozza előre. Tehát ilyen már maximum annyit fog jelenteni, hogy 22. helyett 30. leszel a listában az amúgy full Google barát oldaladdal, míg az első 10-ben akár teljesen összegányolt oldalak is lehetnek csak azért, mert baromi jó a Pagerank-jük és emiatt generálják önmaguk népszerűségét. Na meg a negatív reklám effektus itt is megvan. Pl. közzéteszi az ember ilyen-olyan nagyobb fórumokon, hogy "Figyeljetek már, van ez az example.com. Iszonyatosan gány, hulladék oldal. Aztán jön egy kilométeres hibalista." Ez pedig szépen +1 megjelenést jelent a PageRank algoritmusban. Még a nofollow-ot is figyelik, csak azt jóval kisebb súllyal.
"Sosem értem, egy ilyen béna konvenciót miért sírnak vissza az emberek, de ízlések és pofonok különböznek."
Azért, mert ott nem kellett manifest.json-nal mókolni, hanem egyszerűen név alapján futott le. Itt meg a manifest-ben ellenőrizd a központi jogosultságokat, meg a sorrendet, a scriptben a script saját forráskódját.
Régen természetes volt az átnevezés már csak azért is, mert egyszer userscripts.org-ról ID.user.js néven töltődtek le a scriptek, egy számsorról meg ha sok volt belőle nem tudtam ránézésre, hogy az most mit csinál. Másrészt a example.js néven natívan futott a JS, míg example.user.js néven Greasemonkey emulációban.
Szóval adta magát, hogy innentől ha valaminél feltétlenül fontos, hogy gyorsabban fusson le a többitől, akkor kap a neve mögé egy 0-t vagy egy a betűt.
"De ha jól emlékszem (na erre lehet, hogy rosszul), a user JS-eknél sem volt másképp, csak ott magát a progit kellett úgy, ahogy van, újraindítani. De javíts ki, ha ez téves."
Nem kellett semmi ilyesmit. Csak az oldalt kellett újratölteni. UserCSS-nél kellett újraindítani, ha töröltél vagy hozzáadtál újat. De ha meglévőt módosítottál (pl. adblocker.css-t szerkesztetted), akkor csak egy Reload stylesheets parancs kellett. Ez mondjuk nem tudom bug vagy nem, de ilyenkor újratöltötte a CSS-t minden megnyitott fülön. Azaz mondjuk 50+ tabbal picit megröccent a böngésző, de ennyi. Nem kellett újraindítani ehhez sem.
Sőt, INI szerkesztéseknél (menu, toolbar, skinek, mouse, keyboard) sem kellett újraindítani, csak át kellett váltani Operán belül egy másik INI-re addig, amíg a módosítandó INI-t módosítottad, majd elmentetted a változásokat. Utána visszaváltottál a módosított INI-re, Operán belül, újraindítás nélkül.
Na az ilyeneket hiányolom nagyon az újból. Mintha valami gányolt szar lenne ez a Chromium (mint a Windows), hogy minden apróságért újra kell indítani, miközben létező bizonyíték van/volt rá (Opera/Linux), hogy lehet ezt csinálni másképp is: Vagyis csak feltétlenül szükséges esetben újraindítani.
-
#20050
Penge_4
veterán
Sk8erPeter
#20049
Penge_4
veterán
válasz
Sk8erPeter
#20049
üzenetére
"Éppen ezért nagyon sajnálom, ha a mostani fejlesztőpanelt ideiglenesnek szánják, de majd ki akarják dobni, és valami saját fejlesztést akarnak a helyére tenni, mert eddig nem nagyon jött össze Operáéknak."
Én meg nem, mert eddig 4-ből 4-et nem tudtam megcsinálni a Chrome-os fejlesztői panellel.
- Színt lopni az oldal screenshotjából color pickerrel.
- Resources tabon normálisan, átlátható módon sniffelni, hogy miket kéne kicsapnom, ami nem tartozik az oldalhoz.
- HTTP headert egyszerűen olvasni, lehetőleg nem 8 kattintásból.
- Normális, logikus és átlátható módon CSS-t szerkeszteni egy oldalhoz, mert pl. mindig bele kell kattintani abba a rohadt nagyítóba, hogy kiválaszthassam az oldal elemeit, meg nehézkesebb is a kód szerkesztése, meg okosabb akar lenni, mint én (pl. az általános padding beállításokat is padding-left, padding-right, padding-top és padding-bottom-ra cseréli le, hogy utána már 4 helyen módosíthassam, meg ilyenek.Ja +1: kijelölni bizonyos területeket, amiket onnantól egyenesen bemásolok az adblocker.css-mbe, ha nincs sem egyedi class, sem egyedi id, pl:
HTML[class="sg.hu"]>BODY>DIV[id="center"]>TABLE[width="850"][height="100%"][bgcolor="#FFFFFF"]:nth-child(4)>TBODY>TR>TD[width="100%"][valign="TOP"]:nth-child(3)>DIV[class="cikk"][id="cikk"]:nth-child(4)>CENTER:nth-child(3),Szóval számomra meg pont szar még amellett is, hogy az nekem is tetszik, hogy nem minden tabon aktív a panel, csak ott, ahol bekapcsoltam.
"Nem értem, hogy lehetne tehát ebből következtetni arra, hogy gány lenne a program vagy a böngészőmotor."
Úgy, hogy ami úgy van felépítve, hogy menet közben újratölti a modulokat az a szememben átgondoltabb, mint az, ami ilyen ultimate "indítsd újra" faszságokra hagyatkozik. Egy példa: Bár a Windows elmebeteg Flash installere nem engedi, de Linuxon úgy tudom frissíteni a Flasht, hogy utána az opera:plugins oldalon nyomok egy "Reload"-ot és hipp-hopp, lecserélődött. Erre csak az Opera képes. Sem a Firefox, sem a Chrome (bár utóbbi peppert használ, de akkor is égő, hogy az FF szintjén van ezen a téren).
És ez ráadásul még nem is programkomponens, hanem egy nyamvadt külső fájl. Miért is kell lock-olni? Mert más logikus magyarázat nincs rá, hogy miért nem tudja futás közben ellenőrizni, hogy van-e vagy nincs.
-
Penge_4
veterán
Ennek nem tudja valaki az okát? Direkt megnéztem, semmi olyan userJS-em vagy kiegészítőm nem aktív, ami ezt okozná, mégis Opera 12-ben normálisan nyílik meg a kép, Chrome-ban meg átirányít a főoldalra. (Ráadásul a buta eseménykezelője miatt először lerendereli a főoldalt, majd utána irányít át még show just imege userJS esetén is).
-
Penge_4
veterán
Itt továbbra is azt érzem, hogy akár az oldal hülyesége, akár nem, az Opera valahogy sokkal jobban tudta ezeket kezelni, mint a többiek.
És van egy olyan gyanúm, hogy az oldal nem véletlenül működik így. Elvégre a webkites böngészők ma baromi nagy szeletet birtokolnak, ezek a képmegosztó oldalak meg abból élnek, ha nem direktlinkeled a képet, hanem nézed körülötte a reklámokat és a 2-3 felugró popupot.
ImageShack-nél ugyanez van, de ott a direktlinkelt kép Operában is az oldalra irányít vissza.
-
#20066
Penge_4
veterán
Sk8erPeter
#20061
Penge_4
veterán
válasz
Sk8erPeter
#20061
üzenetére
"Viszont ha a képre jobb klikkelsz, és kép megnyitása új lapon, akkor ezt a linket kapod, ami egy jpg-kiterjesztésű képet tartalmaz, nem pedig png-t, és így nincs semmiféle átirányítás:"
Az szép. Jobbklikk->Image properties: PNG az akkor is, csak JPG kiterjesztéssel. Hasonlót asszem még régen iWiW-en láttam, de ott JPG volt minden esetben, csak az Opera egyedüliként .jpg helyett .jpeg kiterjesztéssel mentette.
"Ez most így hirtelen nem világos, hogy mi nem átlátható benne, vagy milyen szempontból volt áttekinthetőbb az Opera Dragonfly-nál. Hogy érted?"
A Network tabon ömlesztve van, a Resources tabon viszont kategorizálva. Na, az Operában sokkal átláthatóbb az egész, Chrome-ban meg egyedül az az egy pozitívum van (bár gondolom a webRequest API miatt), hogy "failed"-del kiírja azokat, amiket blokkolt. Az Operában meg se jelennek a blokkolt elemek.
"1. nem értem, miért lenne muszáj belekattintani a nagyítóba az elem kiválasztásához, lehet jobb klikkelni az adott elemre, aztán "Elem megtekintése""
Mert alapértelmezésben nem tudod kiválasztani az oldalon az elemet, csak ha belekattintasz a nagyítóba. A DOM fában Dragonfly-jal is lehet navigálni, de én inkább kiválasztom a módosítandó DIV-et. Ez Web Inspectorban +1 kattintás minden alkalommal.
"2. a paddinget nem cseréli le 4 helyen, hogy 4 helyen kelljen módosítgatnod, de lenyitható, és akkor szétbontva is látszik - hogyan csináltad?"
Nem tudom hogy csináltam, de utána már nem tudtam a lenyílóba belekattintani, hanem a globálisat kellett átírnom. Olyan nehézkes az egész.
"Ha itt arra az elérési útra gondoltál, ami CSS-sel megcélozható"
Igen, arra. Erre külön nem akarok plusz egy kiegészítőt. Az Adblock és az Adblock Plus meg nem kezeli az nth-child-eket, ami miatt egy csomó esetben cseszhetem.
"Nálam az imgur.com a kedvenc képfeltöltésre, gyors, modern, van fejlesztői API-ja, így van lehetőség több programban is egyből felküldeni az oldalra"
Van rá kiegészítő is. Kár, hogy sem privát módban nyitott képeknél, sem localhostról nyitott képeknél nem működik.
(#20065) hunfatal: "Pl. ha kapsz egy közvetlen imageshack linket, a kép helyett pedig a szokásos béka tölt be, akkor a link mögé hányva egy kérdőjelet megjelenik a kép rendesen és nem vakerol a hotlink miatt."
Az beágyazott képeknél volt és azzal csak azt lehetett csinálni (mivel automatikusan banned.jpg-re (vagy valami hasonlóra) mutatott a link, hogy Ctrl+F3 (azaz forráskódnézet) és onnan kimásolgatni az imageshack linkeket. Ha túl sok volt, akkor (mivel ebben az esetben a domain volt banolva, azaz a fórum ahol megosztották) kimásolta az ember a forráskód nagyrészét, majd fogott egy másik tabot (mondjuk prohardver.hu) itt a doctype és a többi után beömlesztette a máshonnan kimásolt forráskódrészletet úgy, hogy a tag-ek meglegyenek, majd nyomott egy Ctrl+R-t (on-the-fly forráskódszerkesztés előnyei) és immáron megjelentek a beágyazott képek egy teljesen irreleváns domain alatt.
-
Penge_4
veterán
Azt nem tudom, de egyre több apró furcsaságot tapasztalok. Pl. a YouTube-on elkezdtek normálisabban futni a videók, viszont az összes hozzászólás mellett megjelent 1-1 üres scrollbar.
De az is lehet, hogy csak elkezdték a UA sniffinget lecserélni/kiiktatni és emiatt a változás. Mert a browser.js még megvan.
-
Penge_4
veterán
Akkor valószínűleg tényleg ezért hagytak ki egy csomó mindent, ami jött volna "gyárilag" a Chromium API-val. Pl. az a kezdetleges oldalsáv, ami Chrome-ban érhető el kiegészítővel.
Gondolom a HTML5 Notification-nek is valami hasonló oka lehet. Még az is elképzelhető, hogy ha tényleg a teljes rendszerintegráció a céljuk, akkor pl. KDE-n is a D-Bus-on fog üzengetni, Windows alatt meg mondjuk buborékban.
Na meg kérdezte valaki, hogy miért sokkal gyorsabb az Opera 15/16, mint a Chrome/Chromium párhuzamos verziója és valami skandináv voodoo-val poénkodtak a fejlesztők.
Remélem azért idővel jelentősen kiveszik a részüket a Blink motor kiganézásában és a szabványkövetés fokozatos kierőszakolásában. Mert ha már úgyis átírja egy csomó webfejlesztő HTML5-re majd a saját oldalát, akkor ne kezdjük már elölről ugyanazt a gányolásos időszakot, mint IE6 esetében.Még azt is járhatóbb útnak tartanám, ha a HTML szerkesztőkbe építenék bele a validációt, hogy ha a fejlesztő beleokádja is az általa megszokott kódot, az majd kijavítja a dolgokat, de ne a böngészőnek kelljen már minden részletre kiterjedő on-the-fly elemzéseket végeznie minden oldal betöltődése előtt csak mert megengedőbbek vagyunk.
-
Penge_4
veterán
-
#20102
Penge_4
veterán
scott_free
#20101
Penge_4
veterán
válasz
scott_free
#20101
üzenetére
"az Opera 15-ben miért mások a betűtípusok ugyanazon az oldalon, mint a 12-ben?"
Mert az Opera egyedi betűsimítást alkalmazott, ami olyan fasza volt, amit még egy Chrome fejlesztő is elismert.
"az alapértelmezett zoomot be lehet állítani 120%-ra 125 helyett?"
Nem. Maximum dqdb kiegészítőjével, de az kiegészítő, nem natív funkció, emiatt értelemszerűen küzd azokkal a korlátokkal, amikkel minden más kiegészítő.
"valahogyan lehet nagyítani a címsor (és a fülek neveinek) betűméretét?"
Windows beállításaiból globálisan igen, de Opera-specifikusan szerintem sehogy.
Amúgy minél többször próbálgatom a Chrome-ot, kényszerítve magamat az elkerülhetetlenre, annál inkább rájövök, hogy mennyire szerettem az Operát, amikor újra azzal böngészek. Olyan triviális dolgok is, mint a Linuxos topicban kialakult fontokkal kapcsolatos vitában is rájövök újra és újra, hogy mennyi minden volt alap és természetes az Operában, ami Chrome-ban nincs/nehézkes/körülményes vagy egyenesen lehetetlen.
Pl. itt gondolom a fejlett fontbeállításokat (akár h1-től h6-ig meg lehet adni egyedi dolgokat, tényleg mindent testreszabni, amihez nem kell egyedi UserCSS-kkel szopni) nem kell részleteznem. Chrome-ban ocsmány Times New Roman van. Ami önmagában még nem is lenne gond, de DejaVu Sans-ra módosítva a 16-os tényleg 16-os méretűnek tűnik (ugyanez az érték van Times New Roman-nál is, de az inkább 12-esnek tűnik), emiatt csúnya, nagy és széttolja a layoutot. Pl. itt IT Cafén a "Legfrissebb anyagok" dobozban 4-5 sorba tördelődnek a 16-os betűk. Nosza, csökkentsük le. Oh, wait! Nem csökken, csak egyszerre az összes, emiatt még a natív lapokon (beállítások, about:memory) is hangyafasznyi méretű betűk lesznek. Na akkor nézzünk bele a Preferences JSON-ba (ha megint el nem baszom és rakhatom újra a kiegészítőket, azok beállításaival együtt, mert a buborék 404-et mutat, miután sikerült visszaállítanom), hátha ott lehet specifikusan is módosítani. Nem, nem lehet ott sem...
Arról nem beszélve, hogy minél többször használom a Chrome-ot, annál inkább rájövök, hogy mennyi olyan bug van benne (durvább módon), ami régebben Operában is volt és mennyien "bezzegatöbbiböngésző"-ztek ilyenkor. Csak így hirtelen mikor be van ágyazva egy DIV-be egy sokkal nagyobb (akár több megapixeles) kép, akkor a görgetés veszedelmesen akad. Régen ez Operában is volt, de itt azóta már egész tűrhető.
[ Szerkesztve ]
-
Penge_4
veterán
"Itt van az URL maszkokról a leírás, rendes magyarázat, BNF és hasznos példák hozzá (Sk8erPeterrel együtt nem véletlenül dicsértem a dokumentáció minőségét)."
Miért azt jelzi, hogy a harmadik content script nulladik match-jával van gebasz, amikor a hiba (egész pontosan a csillag után nem tettem pontot) az ötödik content scriptben volt?
"De sok értelmét sem látnám, akkor már ott van a Tampermonkey/Stylish páros."
Csak azzal az a baj, hogy az értelmetlen karaktersorozat nevű kiegészítők könyvtárait rendszeresen kell backupolni, mert egyszer csesződik el valami a JSON-ban, és onnantól a kiegészítők megszűntek létezni. A kiegészítő könyvtárai eltűnnek és a kiegészítők chrome://-es (vagy opera://-es) URL-jei 404-es hibaoldalra mutatnak, a kiegészítőikon pedig puzzle ikonná változik.
A Tampermonkey meg fos, mert egy csomó mindent kell konfigurálni benne, meg egyenként kell hozzáadogatnom a scripteket.
Meg most komolyan, minden kiegészítőt egyenként backupolgassak? Natív funkció kéne ezekre, mert ez így katasztrófa. Instabil és veszélyes, ilyesmiben nemhogy Notes, Bookmarks, UserJS és társait nem szabad tárolni, de még napi ToDo-t sem bíznék rájuk. Korrumpálódik az adatbázis, törlődik az értelmetlen karaktersorozatú könyvtár, aztán elfelejtem megetetni a hörcsögöt és az kimúlik.
"és adott esetben a DOMContentLoad esemény használata miatt a user JS módosítása sem"
Oké. Hogy adom meg ezt? "run_at": [ "document_start" ],
Amúgy a DomContentLoaded (ami Operában még működött) részt ki kellett szedni a userJS-ből ahhoz, hogy egyáltalán működjön. De most a run-at-ra ezt a hibát dobja:
Invalid value for 'content_scripts[5].run_at'.
"Ugyanakkora betűméret esetén egy sans serif font betűi mindig nagyobbnak tűnnek egy serif font betűinél. Ráadásul a DejaVu Sans betűi a szokásosnál szélesebbnek tűnnek."
Ezzel megvigasztaltál. Operában ezt át lehet hidalni, Chrome-ban még ezt sem.
"míg a Linux számomra ronda fontkezelésétől rosszul vagyok."
Amiket mutogattak elrettentő példaként screenshotokon, azoktól én is, de amit én használok attól nem. Sőt, szerintem sokkal szebbek, mint a Windows 7-es TrueType.
(#20104) Sk8erPeter: Amit még kifelejtettem: WebDev Tools-ban nem lehet szerkeszteni a cookie-kat, csak megnézni meg asszem törölni. Szóval végképp el van lehetetlenítve a cookie szerkesztés, tényleg külön kiegészítő kell még erre is. Még a DevTools sem tudja.
"A nyomorult Dragonfly-ban rámegyek az elemre, és nem is tudom így egyből módosítani a tulajdonságait az épp kijelölt elemnek:"
De nem is 4 különböző érték lesz ott, csak 1. Az, amit szerkesztesz akár globálisan, akár lokálisan. Ha az összes többi padding 10, kivéve a left, ami 8, akkor ne jelölje már ki nekem az összeset.
Még egy: Jelöld ki a "Legfrissebb anyagok" egy linkjét Dragonfly-ban és nyisd le a "Computed Styles"-t. Fogsz látni egy ilyet:
font: normal normal 400 12px/16px Arial;
Chrome-ban meg bontva van, egyenként másolgassam ki az összeset."úgy viselkedik, mint az inline style-nál (mint amikor a style attribútumba pötyörészem az értékeket), hanem csak mintha a CSS-fájl végére dobáltam volna be... na ez a másik, ami rettenetesen idegesítő. Hát milyen szinten béna már ez?"
Én pl. kifejezetten szeretem, ha nem akar a program okosabb lenni, mint én, mert az ilyen próbálkozások mindig kudarccal végződtek. Nem létezik olyan algoritmus, ami engem ki tudna ismerni.
Pl. Dragonfly-ban ha HTML nézetben ráklikkelek duplán egy tag-re, akkor nem a taget akarja szerkeszteni, hanem az egész tag alá tartozó részt. Itt meg ez is külön van csapva gondolom userbarát célból. De nekem nagyon nem tetszik ez sem.
"Hogyhogy "nem kezeli"?"
Úgy, hogy natívan a blokkolandó DIV kiválasztásánál nincs ilyen funkcionalitása. Pedig 150-200 megát zabáló cuccnak illene ilyennek is lennie.
"tulajdonképpen nem tudom, ezzel most mit akartál igazolni... (Vagy ez a szokásos csak-azért-is-megpróbálom-megtalálni-a-sebezhető-pontot-jellegű kötekedés?)"
Nem. Ez a szokásos "még a legjobb és viszonylag egyszerű ötletet is képesek elbaszni" típusú monológ volt.
Pl. tegnap ért sokkhatásként az is, hogy a VLC (legújabb verzió) a mai napig nem képes olyan triviális dologra, hogy a feliratot az alsó fekete sávra renderelje rá. Pedig úgy gondoltam, hogy legalább ezt már tudja, de ezek szerint még ezt sem. Ennek általánosságban annyi köze van az Operához, hogy vannak fasza, funkciógazdag szoftverek, amiket senki nem használ, meg vannak buta, funkciószegény szoftverek, amik népszerűek és ha megpróbálsz érvelni teljesen logikus dolgok mellett, akkor néznek rád, mint valami UFO-ra, mintha ezek a dolgok annyira rétegigények lennének.
"itt dqdb elég jól igazolta, hogy jelen esetben rossz dologba kötsz bele, és rossz dolog miatt minősíted a WebKit/Blink-vonalat szarabbnak."
Oké, elismerem, a népszerűség átka, hogy köcsög oldalak visszaélnek a helyzetükkel. De ettől még az tény marad, hogy ha a böngészőben nincs konfigurálási lehetőség, hogy felülbíráld egy oldal hülyeségét, akkor az igenis faék.
Szar meg nem azért lesz, mert jelenleg faék, hanem azért, mert 2008-as megjelenése óta nemhogy Opera szintre, de még Firefox szintre sem sikerült senkinek felhozni eme nyílt forráskódú csodát. Pedig forkokból Dunát lehet rekeszteni. Még beépített torrent klienses Torch Browser is van.
Ha pedig valami 5 éve képtelen erről a buta szintről feljebb emelkedni, ott erősen gyanítható az, hogy nagyon mélyen bele kéne nyúlni abba a "solid foundation"-be (mondhatni, pincét és mélygarázst utólag húzni a már felépült Burj Dubaj alá), hogy akár csak megközelítse a Presto-s Opera szintjét bármilyen téren.
Egyébként a standalone M2 is jó móka így a Presto-val. Szerintem az is csak azért van, hogy legyen indokuk, miért nem adják ki a Presto forráskódját. Mert akkor kiderülne az igazság... Aztán nem kizárt, hogy én esnék pofára. Bárcsak úgy lenne. De sajnos eddig minden pesszimista megérzésem bejött.
"A JSON egy nagyon egyszerű, programozásban jól és könnyen használható, széles körben támogatott formátum, nyilván nem véletlenül."
De miért kell ágyúval verébre? Programozásra biztos jó, de arra, amire nekem kellett egy INI is bőven megfelelt. Linuxban miért is nem JSON-ban vannak a config fájlok? Talán mert elmebetegség lenne ilyen triviális célokra egy karácsonyfa programnyelvet alkalmazni? Jó, hogy nem brainfuck-ban kell UserJS-eket menedzselni.
"Te csesztél el valamit a kódban, még ha nehéz is beismerni, és nem a JSON-formátum a szar..."
Igen. Úgy adtam meg, hogy http://*example.com/* nem pedig úgy, hogy "http://*.example.com/*"
A dokumentáció szerint ez a sima example.hu-ra is vonatkozni nem csak a www-re (meg a többi aldomainre, ha van olyan).
Na ez például logikus? Mert én eddig abban a (tév)hitben éltem, hogy a csillag helyettesítő karakter. Ennél fogva helyettesíti a . (azaz pont)example.com előtti részt. De mivel a domain http://example.com (pont nélkül), nem pedig http://.example.com, ezért logikusnak tűnt, hogy így adom meg.
[ Szerkesztve ]
-
#20118
Penge_4
veterán
Sk8erPeter
#20117
Penge_4
veterán
válasz
Sk8erPeter
#20117
üzenetére
"Miért értelmetlen karaktersorozat a nevük?"
hlojmnjdcnblobllbpphiemfbdilpiol, hompjdfbfmmmgflfjdlnkohcplmboaeo és társaira gondolok.
"A kiegészítők léteznek, csak legfeljebb nem tudnak betöltődni, mert már a manifest.json-validáció során elbuknak. Javítani kell a hibát, és máris megszűnik ez a probléma."
Elméletben biztos. A gyakorlatban viszont a backup fájl visszaállítása után már eltűntek a kiegészítők az Extensions mappából.
"Csak az extensionök oldalánál hasonló hibaüzenetet kiírt, mint nálad, javítottam, újratöltöttem, és már volt kiegészítő."
Ez nem az a probléma. Csak az unpacked extensionoknál van Reload gomb. Továbbá még felül sem lehet írni (reinstall), mert az a túlintelligens Chrome Webstore látja, hogy telepítve van már a kiegészítő és nem tudsz felülírást csinálni.
"A régi Operánál is nyugodtan elcsesződhettek kiegészítők. Az pedig a kiegészítő felelőssége, hogy biztosít-e mondjuk adatexportálási lehetőséget."
Igen. De a régi Operánál az alapfunkciók natívan voltak megcsinálva, így csak kb. 10%-ban kellett kiegészítőkre támaszkodni. Itt meg 100%-ban. Ez nem mindegy.
"Pontosan ezért dobta tehát teljes joggal az "invalid value"-t, mert valóban érvénytelen értéket (stringet tartalmazó egyelemű tömböt (lásd szögletes zárójelek)) adtál meg."
Köszi. Így már működik. Már csak arra kell rájönnöm, hogy hogyan lehet a három (azaz kettő, mivel a document_idle a default) közül valamelyikkel az Operás működést elérnem.
Konkrétan most annyit akartam, hogy a tab aliaser nevű kiegészítőm akkor fusson le, amikor Operában. De document_start-ra az egész title mező törlődik és csak URL lesz title helyett, document_start pedig ugyanaz, mint a document_idle. Vagyis a teljes betöltődés után cseréli ki a title-t.
"A "külön kiegészítő kell még erre is" speciel a fejlesztői panel esetében picit túlzás, mivel amit eddig hiányoltál, és ami egyáltalán nem volt meg (vagy más formában), az a screenshot-készítő és color picker natívan."
Dragonfly-ban a Storage fülön lehet szerkeszteni is a cookiekat. Mellesleg natív funkció is egyben az oldal tulajdonságainál. Szóval ez is megvolt.
"Ezt jelenti tehát a fentebbi padding:4px 3px 2px 1px; sor, a kettő teljes mértékben ekvivalens, DE CSAK EGY HELYEN KELL SZERKESZTENI, NEM 4 HELYEN... capisce?"
Oké, akkor mondom: Ha nekem van már két padding !important-os értékem a left-re és a right-ra, akkor egyben szeretném egyetlen (nem kettő, egy) érték átírásával módosítani.
Vagyis jelenjen meg, hogy padding: 5px, ami vonatkozik elviekben mind a 4-re, de csak annyi jelenik meg, hogy 5px.
Nem 5px 5px 5px 5px (amiből kettő át van húzva az !important-os felülbírálás miatt).
Ha viszont közös paddingot szeretnék mind a 4 oldalnak, akkor is kényelmetlen, hogy 4 értéket jelöl ki. 1 globálisat jelöljön ki, az vonatkozzon mindenre.
"Hogy mit ne jelöljön ki? Ezt most már nem is értem. Mintha két külön nyelvet beszélnénk."
Oké, akkor képpel magyarázom:
Web Inspector:
Dragonfly:
"valamint nem a CSS-fájlokban megadott módon szedi szét a stílust, hanem összegzi a végső renderelés eredményét, és kész."
Pont látszik, mivel így ha userCSS vagy kiegészítő módosított valamit is mutatja.
"Hidd el, a külön-külön módosítás kényelmesebb, mert akkor teljesen egyértelmű, hogy épp mit módosítasz, csak ránézel a tulajdonság nevére, és már tiszta, nem kell gondolkodni, milyen sorrendben is van."
Tényleg nem értelek. Pont Dragonfly-ban tudod külön-külön szerkeszteni pl. a paddingot, míg Chrome-ban kibonthatod, de nem felül tudod szerkeszteni csak. A kibontottra hiába kattintgat az ember.
Mellesleg Dragonfly-ban van jobbklikk menü. Olyan, ami a Chrome-os DevToolsban nincs. Ott meg van olyan, hogy "Expand shorthands", ha te arra vágysz.
"és hogy ne kelljen alkalmazni az amúgy kerülendő !important kulcsszót, ez nagyon is számít"
Webfejlesztésnél biztos, userCSS-nél nem hiszem.
"egy szar, kényelmetlen megoldást választottak, hogy nekem manuálisan kelljen hozzáadnom egy attribútumot, jobb klikk, Add attribute, "style" bepötyögésének bénázásával"
Miért kéne ilyet csinálnod? Duplaklikk egy teljesen irreleváns, de az adott DIV-hez tartozó elembe, majd Enterrel csinálsz egy sortörést, az új sorba meg már azt írsz, amit akarsz.
"Itt olyan jellegű problémáról beszélünk, mintha kábé az otthoni fürdőszobádban a WC-tartályodon végül is lehetne egy lehúzózsinór, de te minden alkalommal inkább felmászol a vécédeszka tetejére, és kézzel lenyomod a lehúzókart, mert az úgy tök vagány."
A régebbi, nem víztakarékos WC tartálynál, ami lehúzáskor leengedte a teljes tartály tartalmát, úgy csináltam, mert úgy vissza is lehetett tolni a kart.
"Fejlesztés során nem egyszer fordult már elő, hogy mondjuk egy divet p-re akartam cserélni, vagy egy p-t spanre, vagy hasonló, ebben az esetben ráklattyolok az adott tagre, és mind a kezdő-, mind a zárótaget egyből lecseréli, szemben az Opera megoldásával, ahol nekem ezt manuálisan kell megtennem, még a HTML-szerkesztős részben, vagy ha rosszul csinálom (pl. elfelejtem lezárni), az is lehet, hogy a Dragonfly automatikusan kicsapja a kódból az adott taget"
Most próbáltam ki. Duplaklikk a DIV-en, megnyílik szerkesztésre egy <i></i>-vel körülzárt rész. A felső i-re duplaklikkelek, kijelölődik az i betű. Átírom p-re, majd nyomok egy Enter-t. Meglepő módon a zárótag is kicserélődött p-re.
"Ennél a résznél is elvesztettem a fonalat, most milyen hülyeséget is akarunk felülbírálni? Hogy ne irányítson át?"
Pl. Fit-to-Width, pl. Cookie szerkeszthetőség és még folytathatnám a sort. Az Operában volt egy csomó olyan, amivel felül tudtad bírálni az oldalak hülyeségét. Egyébként oldalspecifikusan az átirányítást is le lehetett tiltani :-) Ahogy a send refferer information-t is és még sok mást.
"Aha, tényleg, amit nem látunk, amit letakarnak előlünk, az tényleg tuti sokkal jobb."
Az egyik logikailag nem következik a másikból, viszont a történelem során eddig az esetek többségében amit rejtegettek azt okkal rejtegették. Úgy értem, mindig volt mögöttes ok a publikus és nyilvánvaló okokon kívül.
De valóban, amíg nem látjuk a forráskódot, addig nem tudjuk eldönteni, hogy melyik a jobb, csak egyéni, szubjektív véleményünk lehet. Az enyém az, hogy a Presto egy forradalmi motor volt, amely még abban a szellemiségben született, amikor a webet geekek és programozók uralták, nem marketingmenedzserek és zombi átlaguserek, a bugjai többsége a népszerűtlenségéből és annak utóhatásából (workaroundok sorozata) keletkezett (pl. 10.00-s Operában semmi probléma nem volt a position:fixed oldalakon való scrollozással, próbáld ki ha nem hiszed el. Gyönyörűen gördül a szöveg fix hátteres és fix dobozos oldalakon is).
Illetve szarul marketingelték, a piac hiénái pedig megölték. Ahogy tették azt régebben is párszor fejlettebb, korukat meghaladó innovációkkal (BetaMax, Dymaxion vagy EV1).
"Ja, tényleg, mielőtt megfeledkezem róla, a JSON-fájlok feldolgozása, írása gyorsabb, mint az INI-fájloké."
Az XML-é meg még gyorsabb. Vagy ha már gyorsaságra megyünk, állítólag a Lua script a leggyorsabb. És az még hasonlít is a JSON-ra.
"A *example.com egyébként ilyen alapon illeszkedne az "example.com" és "fosexample.com" hostokra is (fosexample meg nyilván tök más domain, míg a fos.example.com esetében a "fos" egy aldomain az "example.com" domainhez)."
Végül is, ebben van igazság. Csak így meg olyan furcsa, hogy az a pont nem értelmeződik.
Mert ha én pl. úgy adom meg, hogy *.example.com, akkor lehet, hogy direkt az a célom, hogy a http://example.com-ra ne vonatkozzon, csak az example.com oldal ezernyi subdomainjára.
Hogy életszerű példát mondjak: pistike.atw.hu-n meg gizike.atw.hu-n meg józsika.atw.hu-n is jelen lévő valamit akarok módosítani, létrehozni, törölni, de azt nem szeretném, ha a fő atw.hu oldalon is módosulna/létrejönne/törlődne.
Ezt gondolom úgy oldom meg, hogy a sima domaint ilyenkor az exclude_matches-be rakom bele.
-
#20127
Penge_4
veterán
Sk8erPeter
#20124
Penge_4
veterán
válasz
Sk8erPeter
#20124
üzenetére
"Kérlek, mondd már meg, hogy Opera Dragonfly-ban mégis hol mutatja a Computed Styles részben azt, hogy pontosan az adott tulajdonság melyik fájlokból is származik:"
Mivel alul mutatja, így nem tartottam szükségét, hogy ott a szerkeszthetetlen computed styles-ban is mutassa.
"Szóval megint elég következetlen az érvelésed, mert egyszer azt mondod, hogy te akarsz mindent irányítani, most meg elégedett vagy azzal, hogy a Dragonfly helyetted okoskodik. Ez akkor hogy jön össze?"
Úgy, hogy Dragonfly-ban van expand shorthands toggle, míg Chrome-ban azt kapod, amit a fejlesztők megálmodtak neked, nincs opciód.
"Hopsz, az Opera Dragonfly megint alulmaradt."
Ezt nem értem. Eddig akárhány helyen ganéztam a CSS-t, mindenhol volt element.style a Dragonfly-ban is az ID és Class nélküli tageknél.
"nem tudom, miért érvelsz amellett, hogy jobb a Dragonfly, ha neked mégis sikerült duplaklikkre NEM azt a viselkedést előidézni, amit szeretsz.... (ismét ellentmondás, nemde?)"
Duplaklikkre megnyitja a HTML formátumú szerkesztést. Utána duplaklikk a tag <> közötti betűin és kijelöli az egész taget.
Viszont most jöttem rá egy újabb hiányosságra a DevToolsban. A nyitó tag szerkesztésénél valóban megváltozik a zárótag is, de a zárótaget nem tudod szerkeszteni. Tehát ha elcseszték a zárótaget, akkor nem tudod egyszerűen megváltoztatni. De most próbáltam ki HTML-ként szerkesztve átírtam a h3 lezáró h3-ját h4-re és visszaváltoztatta Enter után h3-ra.
-
Penge_4
veterán
"Rossz hír:
what about Opera Notes? Extremely useful feature.
Sorry, it's currently somewhere at the bottom of our priorities."Annyira nem rossz. Legalább ott van a prioritások között, nem pedig elzárkóztak előle teljes mértékben.
"Even though we have Blink as browser engine, we've made enough changes around it that the problems exist only for Opera."
A végén még visszajön az NSL és a position:fixed is.
más: Tök jó ez a natív UserJS/UserCSS megoldás. Még külön processzt (emiatt egy rakás memóriát) sem használ. Kár, hogy egy pár régi Operás userJS nem megy Chrome-mal, például a Snap Links. Pedig a Linkclump is 10 megát zabál külön processzben a semmiért.
Egyébként hogyhogy nem rendeződik külön processzbe? Mert eddig egy Chrome-os kiegészítőnél tapasztaltam ezt, az pedig a Fine Link Selector volt (ki lehet jelölni a linkek szövegét).
[ Szerkesztve ]
-
Penge_4
veterán
"Snap Links: linket tudsz adni?"
Mindkettő ugyanannak tűnik.
"LinkClump: legtöbb saját ikonnal nem rendelkező, csak az oldalba belepiszkáló kiegészítő átírható, csak ebben az esetben bukod a beállítások oldalt."
Tehát akkor gyakorlatilag egy hülye gomb vagy egy beállítások oldal (amit ritkán vagy általában csak első alkalommal piszkál az ember) miatt rendeződik külön processzbe, ezzel nagyban megnövelve a saját memóriaigényét? Ennek semmi értelme nincs. Mikor egy kiegészítő elcrashel, akkor különben is újra kell tölteni az összes lapot, ahhoz, hogy aktív legyen a kiegészítő.
Mert még ha valami buborékfüggő kiegészítőről van szó, vagy dinamikus gombról (időjárás ikon, árfolyam, stb., aminek különben is kicsi az a gomb, egy speed dial már célirányosabb), de általában a legtöbb esetben nem erről van szó.
Amúgy meg régen a scripteket is jobban megírták, hogy magában a scriptben írt át az ember boolean meg integer értékeket a kikommentelt dokumentáció alapján, de mivel ezeket a kiegészítőket úgy tervezték, hogy a beállítások oldalon lehessen elvégezni a beállításokat, kétlem, hogy ilyen szépen lenne a kód megvalósítva.
"Ezt olvasd el, így a jövőben könnyebb lesz olyan specifikációkat megértened, ahol formalizálják a szabályokat, mint a content_script blokknál."
Itt relációs jelek között van az érték, vessző helyett pipe választja el, a végén, sima egyenlőségjel helyett ::= van, és a sorok vége sincs lezárva vesszővel. Ettől még magát a JSON-t nem fogom jobban érteni, csak ha bemagolom a szintaxist. De azt utáltam mindig, ezért inkább használat során sajátítom el, így könnyebben rögzül hosszútávon. Ha elolvasnám a dokumentációt, mivel nincs fotografikus memóriám, pár nap múlva már tuti félrenéznék valamit (_ helyett - vagy fordítva) és megint nézhetném meg újra a dokumentációt. Azért köszi.
Más: btw, seems that rocker gestures will be included in the initial O17 release
Bár ez a teljesértékű Wand-dal és a Fast Forwarddal lenne az igazi. De már ez is valami.
[ Szerkesztve ]
-
#20165
Penge_4
veterán
atillaahun
#20164
Penge_4
veterán
válasz
atillaahun
#20164
üzenetére
Vertikálisan: Shift+F6
Horizontálisan: Alt+F6
Maximalizálás: Ctrl+Shift+F5Ezek az eredeti 9.2x kompatibilis billentyűparancsokban voltak, ezeket szoktam használni is, de bármilyen sajátot beállíthatsz nekik itt: Ctrl+F12->Advanced->Shortcuts
-
Penge_4
veterán
Az első mivel jobb, mint a Speed Dial? Mert szerintem baromság. Ott is megadhatod a kedvenc oldalaidat és az legalább szép.
A második meg no comment. Szánalmas ágyúval verébre módszer, amit itt már ki is fejtettem.
(#20170) dqdb: És ez a generált JS mennyivel fog több erőforrást zabálni a RegExp miatt, mint a régi, jól bevált maszkos módszer?
"Ha szükség van a jobb klikk > Block Content menüpontra, akkor az első pont ugrik, de a második továbbra is áll."
Nem lenne, ha normálisan megcsinálnák a DevTools-t és ki lehetne másolni a CSS útvonalakat is, nem csak az Xpath-ot.
"Ha engedélyezik a fileSystem API-t is egyszer, akkor egy külön tool nélküli önjáró kiterjesztéssel megoldható a régi tartalomblokkolás."
A beta.html5test.com szerint már engedélyezve van. Nem lehet, hogy valami kapcsoló alatt van elrejtve? Experimental WebKit features vagy Experimental Extensions, vagy hasonló?
(#20171) hunfatal: "és lényegesen többet tud, mint a régi, Operás tartalomblokkoló."
Annyival nem, amennyivel többet zabál. 150-200 körül önmagában.
-
#20202
Penge_4
veterán
Sk8erPeter
#20192
Penge_4
veterán
válasz
Sk8erPeter
#20192
üzenetére
"Szóval ez az idézett állítás egyszerűen hülyeség, sorry."
Erőforrásigény szempontjából egyáltalán nem az. Átlaguser meg ne buzeráljon ilyen mélységű beállításokat grafikus felületen sem. A Windows-os Registry-t is csak szétcseszi a hozzá nem értő, egy hozzáértő meg a parancssorral is elboldogul.
"Milyen natív UserJS/UserCSS? Nem az új, Opera >=15-ről beszélünk már egy ideje?"
dqdb írta, hogy így natív kódban fut le a UserJS/UserCSS, nem úgy, mint TamperMonkey-val.
"Majd azért erre a kedves óvóbácsikhoz rohanó illető igazán reagálhatna, ha ezt olvassa, és van egy kis vér a pucájában."
Nem véletlenül lett anonim topic a modker. Tisztára, mint régen a fekete autó...
-
Penge_4
veterán
+ az elmaradhatatlan "a program okosabb akar lenni, mint a felhasználó" Highlight: "javascript URI removed when pasted in the address field (fraud protection)"
-
#20222
Penge_4
veterán
Sk8erPeter
#20218
Penge_4
veterán
válasz
Sk8erPeter
#20218
üzenetére
"Egyrészt ez nem tudom, hogy jön ide, másrészt már az is kérdéses, egyáltalán most miféle "ilyen mélységű" beállításokról beszélsz."
Úgy jön ide, hogy egy boolean vagy integer vagy string állításához meg lehet nyitni egy .js kiterjesztésű szövegfájlt is, nem kell hozzá komplett HTML lapot csinálni checkboxokkal, legördülőmenükkel meg hasonlókkal.
"de amikor valaki arra képtelen, hogy először moderátor megkeresése nélkül (óvóbácsihoz rohanástól mentesen) annak az illetőnek szóljon, akinek a viselkedése valamilyen módon őt zavarja, az igencsak töketlen balfék."
Azért az "Júújjj! Megmondalak a moderátornak!" sem a legmegfelelőbb, nem vagyunk már az oviban.
"Egyébként megmondom őszintén, én először rád gyanakodtam, mivel te kardoskodtál nagy hévvel a "Javítsuk a Prohardvert!"-topicban az ellen, hogy valaki külön-külön címezze a hsz.-eit."
Nem, ennyire sunyi nem lennék. Meg fel sem tűnt. De azt bevallom őszintén, hogy felröhögtem mikor megláttam a két moderátori figyelmeztetést, pont a "Javítsuk a Prohardvert!"-topicbéli vitánk miatt.
Én a modkerbe már nem járok. Régebben néha a duplázások miatt szóltam, de eddig két troll (silver star és VladimirR) elleni panaszom egyike sem ért semmit, (ezeket egyébként még a publikus időkben követtem el), azóta nem nagyon érdekel. De ezeket is csak azért jelentettem, mert már annyira a fejemre nőttek, hogy nem tudtam hogyan védekezni. Mert ha indexes stílusban visszaszólok nekik, akkor én kapok megint büntit (mint évekkel ezelőtt visszaszemélyeskedésért), mivel itt szigorúbbak a szabályok.
Amúgy nem vagyok híve a túlzott moderációnak meg az árulkodásnak, a legjobb az lenne, ha csak a spamet, floodot és a tényleg nagyon eldurvult személyeskedéseket büntetnék. És az egész konzekvens lenne nem az, hogy egyszer még a light-os személyeskedéseket és az irtózatos nagy offolásokat is elviselik, máskor meg valamelyik moderátor karatekiflit reggelizett és kitöröl több tíz vagy száz hozzászólást csak mert felmegy benne a pumpa és kiosztogatja a büntetést meg a tömeges figyelmeztetéseket. Ilyet még Kim Jong Il sem csinált, hogy lebontotta a drótkerítést, kivárta, amíg az emberek elindulnak szépen lassan és körülnéznek odakinn, majd utána sortűz. 
-
#20296
Penge_4
veterán
Sk8erPeter
#20295
Penge_4
veterán
válasz
Sk8erPeter
#20295
üzenetére
"Na de akkor, amikor rájöttek, hogy mégis, vajon miért nem rakták vissza a Chromium-félét?"
Gondolom azért, mert a Chromium-féle is egy fos. Csak nevet és URL-t tárol, egy vicc az egész. Ők meg már csak a Bookmarks.db-ben található oszlopok alapján is szeretnék visszahozni a nickname-et, a description-t, a created_date-et, visited_date-et és a Trash-t is.
Meg gondolom lesz "sort by" funkció is.
-
Penge_4
veterán
válasz
Rimuru
#20330
üzenetére
Ez a screenshot elég meggyőző. Kár, hogy GTK alapú.
Viszont ezek hasonlóak, mint a Rekonq, Midori meg a többi. Születik egy csomó ilyen kisebb webkit fork, pár hasznos funkcióval, de nem lesznek elég népszerűek és nem is fejlődnek tovább. Vagy a fejlesztők a saját preferenciáik alapján rakják össze és utána azt csiszolgatják éveken át. De egyik esetben sem lesz a régi Operához fogható funkcionalitású.
-
#20354
Penge_4
veterán
Sk8erPeter
#20350
Penge_4
veterán
válasz
Sk8erPeter
#20350
üzenetére
Nem csak szerinted. Egy jól bekonfigurált 12-es verhetetlen még ma is. Még a Chromium alapú Operától is, ami még a Chrome-tól is gyorsabb (nem tudom miért, de tényleg az).
Meg lehet, hogy csak az én szemem érzékeny rá, de például fáj látni, mikor felvillan a Click to Play placeholder egy pillanatra és csak utána kezd el dolgozni az Adblock (ami elvileg már blokkolja betöltés előtt, nekem viszont mégsem úgy tűnik). A 12-nél szinte folyik a render. Főleg a normálisan kódolt egyszerűbb oldalaknál, hírportálok, ilyesmi.
-
#20367
Penge_4
veterán
Sk8erPeter
#20364
Penge_4
veterán
válasz
Sk8erPeter
#20364
üzenetére
"1.) például az komoly, hogy nem lehet kihúzni a fület az ablakból egy másik ablakba, vagy úgy, hogy egy teljesen új ablak keletkezzen, mert nem másik Operás ablakra dobom rá?"
Van rá switch a flags-ben.
"2.) Ezenkívül ami megint csak vicces: nem lehet textarea-ban kijelölt szövegre jobb klikkel kattintva rákeresni a kifejezésre a keresővel. Ha már Chromium-alapokon van, akkor miért nem?"
Főleg úgy, hogy míg a régi Operában ez is megoldható volt menu.ini szerkesztéssel, addig itt meg vagy lőve. Amúgy a linkesített szöveg kijelölésénél mi a helyzet? Mert valamikor 10.50 körül azt is módosították, hogy legyen benne az összes "Open in...."-os menü. Ami hülyeség, mert ha ez a célom, akkor nem kijelölöm a szövegét, hanem simán jobbklikkelek. Ha meg kijelölöm, valószínűleg a keresés és a keresés ezzel fog érdekelni, illetve a Go to Web Add3.)
"Ha már Chromium-alapokra helyezték a böngészőt, akkor mi a büdös francért kellett kiszedni azt az igen hasznos funkciót, hogy a "Vissza" nyílra Ctrl-lal kattintva új fülön (!) jelenik meg a history-ban korábbi lap?ress."
Ráadásul Chrome-ban a jobbklikk menün lehet középsőklikkel is kattintani. De mivel ott tök hülyén van (az Open link in New Tab és az Open image in New Tab is háttérben nyit, ezért a középsőklikk redundáns), ezért Operában lenne az igazi. Menüszerkesztési lehetőséggel ötvözve pedig meg is lehetne spórolni az Open in Background-ot. Sőt, én akár még azt is el tudnám képzelni, hogy a mozdulatparancsok is működjenek (ahogy a régiben is működtek, pl. füleken adva ki a jobbklikk fel-le parancsot újratöltötte a fület anélkül, hogy át kellett volna rá váltani). Vagy mivel a jobbklikk is működik (csak Chrome-ban ugyanazt csinálja, mint a bal klikk), lehetne advanced menüt hegeszteni, hogy balklikkre target="_blank" figyelmen kívül hagyós Open lenne, jobbklikkre Open in new tab in foreground, középsőre pedig Open in background. És ugyanez működne a context search-nél is.
Tényleg olyan nehéz lenne ezt leprogramozni? Vagy így gondolták, hogy nem Chromium klónt akarnak csinálni, hogy azt a pár értelmes funkciót is kiveszik belőle és letiltják.
"de a régi Operánál is csak az aktuális fül klónozásával lehetett megoldani, majd ott nyomni egy vissza nyilat"
Erre voltak jók a 9.2x kompatibilis billentyűparancsok. Ctrl+Shift+Alt+N-nel tudtam klónozni, onnantól meg egy z-t nyomva (egygombos) már el is értem a célomat. Rövid megszokás után pedig rááll az ember keze. Bár kétségkívül kellemesebb lenne a középsőklikkes megoldás.
"nincs implementálva, például a fülek közötti Ctrl+Tabos váltás lehessen olyan, mint a régi Operában, ne csak sorban lehessen haladni balról jobbra, vagy jobbról balra, ha a Shiftet is nyomjuk)"
Szintén van rá switch a flags-ben. Ellentétben Chromiummal, ott erre nincs lehetőség.
-
#20381
Penge_4
veterán
Sk8erPeter
#20371
Penge_4
veterán
válasz
Sk8erPeter
#20371
üzenetére
"mégis milyen racionális magyarázat támaszthatja alá azt, hogy ez alapból tiltva legyen?"
Lehet, hogy másképp akarják majd megvalósítani, mint a Chrome-ban (esetleg fejlettebb tabkezeléssel karöltve) és úgy gondolták, hogy jobb ha egy félkész dolgot default nem engedélyeznek, mivel elcrashelhet bármikor, aztán az átlaguser meg bús panda lesz tőle.
-
Penge_4
veterán
"az első 17-es buildben biztonságra hivatkozva dobták az opera:// oldalakon működő kiegészítőket"
Erről egy mai cikk jutott eszembe: "több mint 800 ezer olyan felhasználó adatait szerezhette meg, akik a Google Chrome böngészőjét használják."
-
#20423
Penge_4
veterán
Sk8erPeter
#20416
Penge_4
veterán
válasz
Sk8erPeter
#20416
üzenetére
"Ááá, gratulálok nekik! Ez igen! Korábban a szabványok betartásának ékesszólói voltak, most pedig szembemennek vele. Remek irány, mondhatom!"
A szabványt akkor tartsák be, ha értelme is van. Nehogy már a befőtt tegye el a nagymamát. Milyen jogon határozza meg nekem felülbírálhatatlanul egy webfejlesztő, hogy egy mezőben az autofill vagy éppen a jelszókezelő kitöltheti-e a formokat? Vagy milyen alapon határozza meg, hogy egy szövegdobozt átméretezhetek-e? Vagy milyen alapon határozza meg, hogy működik-e a jobbklikk menü? Vagy lementhetek-e az oldalról szöveget vagy képet vagy bármit?
Ezeket böngészőoldalon kell szabályozhatóvá tenni. A webfejlesztő maximum ajánlást adhat a droidoknak. Ha viszont én nem vagyok droid, akkor én felül fogom bírálni. Ahogy akár a komplett CSS-t is át fogom írni, ha nem tetszik a háttér, betűtípus, betűméret vagy térköz, sorköz.
Engem inkább ez a patcheléses móka aggaszt, meg az, hogy már megint olyan elmebeteg módon oldották meg, hogy még külsőleg sem lehet egyszerűen pár fájl másolásával beleintegrálni opcionálisan az mp3, h.264 és mpeg4 támogatást.
Pedig ez az egy nekem kellő ok volt arra, hogy mindig kiherélt Chrome-ot használjak Chromium helyett. Látszik, hogy a cég szemlélete nem változott a Presto dobása óta. Ugyanolyan elmebetegek, mint Tetzchner távozása óta folyamatosan. Elhiszem, hogy jogdíj meg minden, de ezt nem így kell megoldani, tekintve az elterjedtséget és a támogatottságot. Lehetne valami olyat, hogy ilyen videóknál van egy felső nagy piros villogó link, ami egy oldalra visz, ahol éhező afrikai árvákkal szimbolizálják, hogy ők mind jól lakhatnának abból a pénzből, amit pár csúnya, gonosz öltönyös tetű zsebre tesz az ötödik generációs jogutódok révén. Persze ez akkor működhetne, ha a nagyok is beszállnának. A Google-nek alapból elemi érdeke is lenne, mivel a saját VP8-VP9-et szeretné terjeszteni az Apple és a Microsoft pedig jelenleg leáldozóban van. Szóval még akár sikeres is lehetne egy ilyen kampány. Főleg, hogy akár még az EU bizottság is kardoskodhatna mellette + a PRISM botrányt is meg lehetne lovagolni. Szóval lennének itt lehetőségek, ha tényleg az lenne a cél, hogy nyomjuk le minden eszközzel a szabadalmakat és tereljük a világot a nyílt szabványok és megoldások felé.
-
Penge_4
veterán
"A új Opera valószínűleg soha nem lesz ilyen szinten testre szabható."
Az egyetlen esély, amit már hónapokkal ezelőtt mondtam: Ha végre az Opera Classic megszűnik mobilon, meg a különválasztott Opera Mail is és akkor kiadják a Presto forráskódját.
Egyedül ebben van halvány remény, hogy az open source közösség felkarolja. Mert ahhoz gyenge, hogy a 0-ról hozzon létre egyet, de ott van igény arra, hogy legyen egy szénné konfigurálható böngésző.
Az üzleti szegmensben sajnos nincs...
-
#20459
Penge_4
veterán
Sk8erPeter
#20454
Penge_4
veterán
válasz
Sk8erPeter
#20454
üzenetére
Szerinted miért fejleszt akkor annyi mindenki eleve halálra ítélt böngészőt? Ha x év múlva kiadják, amikorra már senkit nem érdekel, akkor az lesz a forgatókönyv, amit te jósolsz.
De ha idejében adnák ki és tényleg rácsapna valami olyan csoport, akinek ugyanez a filozófiája (pl. a KDE csapata), csak eddig hiányzott az alap, akkor akár még jól is elsülhetne. És ezt pontosan tudja az Opera Software is.
Mert tudod vannak dolgok, amik üzletileg nem érik meg és csak mindenféle zárt forráskóddal meg licenszekkel meg jogdíjakkal bevédve magukat tudják megtartani a pozíciójukat, de ugyanakkor ingyen, lelkesedésből szárnyalhat.
A piaci részesedés pedig 17 évig senkit nem érdekelt a részvényeseken kívül. Még a felhasználók is úgy voltak vele, hogy annak ellenére, hogy közvetett hasznuk ugyan származna belőle, de közvetett hátrányuk is (lásd: mainstreammé válás), úgyhogy senki nem erőltette különösebben.
A Presto kódja meg már csak azért is jobb, mint a WebKit/Blink motoré, mert míg utóbbi "csak" egy motor, de még ha a Chromium API-t is veszed alapul is "csak" egy GUI-s renderelőmotor címsorral, addig nincs olyan, hogy külön Presto. Ha ez lehetséges lett volna, akkor valószínűleg a régi alá rakták volna be a Blinket, ahogy azt a hivatalos postok valamelyikében is
hazudtákmondták.Szóval Presto forráskód az én szememben = a teljes funkcionalitású Opera a maga teljességében.
Ha valami kiherélt szart kap a közösség, azzal valóban nem lenne előrébb. De mivel
1. A Presto teljesen össze van/volt drótozva a régi Operával. Még az Opera Mail is egy letiltott böngészőrésszel rendelkező teljesértékű 12.x-es Opera.
2. Az új Opera egy sort nem tartalmaz éppen ezért a régi kódból, szóval számukra a Presto köré épített böngésző sem bír nagyobb jelentőséggel, mint maga a Presto core (már ha ebben az esetben van éles határvonal a core és a böngésző között). -
#20560
Penge_4
veterán
Sk8erPeter
#20559
Penge_4
veterán
válasz
Sk8erPeter
#20559
üzenetére
Lassan már a BIOS-t/EFI-t is flashelni kell ahhoz, hogy elkezdhesd a böngészőt patchelgetni, hogy végül korlátozott módon buherálni tudd.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
A GS Statcounter-en Hungary-ra szűrve is érdemes megnézni a júniusi peak-et. Nem semmi. 
Új hozzászólás Aktív témák
Kérdés előtt olvasd el az
összefoglalót!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs