"Olyan biztonsági rést találtak, ami elméletben lehetővé tette, hogy kiegészítőkkel módosítani lehessen akár a beállításokat is. Ez az jelenti, hogy a fejlesztés alatt álló "Clean Speeddial" kiegészítő megy a kukába."

Nem biztonsági rést találtak, hanem megint túlzásba viszik a hülyebiztosságot. A natív funkcionalitás kevés. Még a régi Operában is hiányoltam, hogy egy csomó kiegészítő nem férhet hozzá bizonyos dolgokhoz. Egy jól megtervezett kliensoldali jogosultságkezelést kellene megvalósítani, ahol az átlaguser kapna egy ilyen szokásos egyszerű felületet, hogy HTTPS-en meg file:// protokollnál engedélyezi, a power user meg olyat, hogy a böngésző egész területére kiterjedően hol, mely részeken engedélyezi, akár kiegészítőspecifikusan.

Amúgy a legnagyobb biztonsági rés az, hogy HTML oldalon vannak ilyen kritikus dolgok, mint a beállítások.

"és igen jó eséllyel az oldalspecifikus beállításokkal van összefüggésben."

Remélem fejlettebb lesz, mint a Chrome-os buta változat. Legalább olyan, mint Opera 12-ben, hogy referrertől a JavaScript beállításokon át a popupokig mindent lehetett kontrollálni.

Meg az sem ártana, ha már tényleg jönne Linuxra is.

Ugy lattom, hogy bejott, ha kalapacsod van akkor minden szognek latszik effektus. Ez ezestben csinaljunk meg mindent HTML+JS+CSS el. Ja hogy "biztonsagi problemak" lehetnek vele, akkor tiltsuk le. Ha paranoid lennek akkor inkabb arra megy ki, a dolog, hogy ne irtsuk le a Google kereso mezot; meg szerencse, hogy nem vagyok az.

A rendszer mutat fejlodest, bar ahhoz kepest, hogy teljesen ujra irt az UI es eleg sok HTML+JS+CSS alapu megoldas... Valoszinuleg itt csak megint en vagyok tulsagosan is rabszolga hajcsar.

Visszont egy valami nem hagy nyugodni. Ahogy lattam van "Bookmark Bar", meg Bookamark API, de bepitett Bookmark Managerol meg nem mondtak semmit. Sot a Bookmark Importer is vagy Speed Dial vagy Quick Access Bar import celokat ajanl fel.

Nagyszerű a könyvjelzősáv, de amit egyszer feltettél oda azt le nem szeded.. (legalábbis e buildban). Se jobbegérgombbal nem lehet módosítani/törölni, egyébként meg semmiféle könyvjelzőkezelő menü sem elérhető.

A görgetés is elcsesződött, idáig normálisan működött, frissítés után fél képernyőket ugrik, bekapcsolva a simított görgetést pedig túl nagy sebességgel. Előző buildben ez rendben volt.

Valamint: ha teljes képernyőn használod (F11) akkor hiába mutatja a könyvjelzősávot, nem használhatod a rajta lévő linkeket.

@Cobalt: Nem kell ehhez összeesküvés. A Google kialakított egy trendet, ami fekszik neki. Pár nagy (Apple, Microsoft, stb.) rájött, hogy mivel félig-meddig van benne logika (csak részben), kár lenne ellenszegülni, inkább gyorsan ők is oda akarták verekedni magukat a húsosfazékhoz (kinek mennyire sikerült).

Voltak nekünk fasza, natív programnyelveink, meg x86-os utasításkészletünk, már nem tudott hova fejlődni, de jött a válság is, a GDP nem pörgött, valamit tenni kellett. Kezdjük újra teljesen más alapokon.

Igazi Dubaj effektus. Drága, erőforrásigényes ilyen várost felhúzni a SIVATAGBAN, de baszni rá, van erőforrásunk, ha meg nincs, akkor majd lemegyünk még kisebb nanométernyi csíkszélességekig és lesz. Majd vesznek az emberek újat és pörög a GDP.

Már lassan egy évtizede parádéznak ezzel a webkettő dologgal meg a HTML+CSS+JS "mesterhármassal", ami alatt elérték, hogy a korábban néhány KILOBÁJT memóriával néhány MEGAHERZES processzoron futó Pacman meg Supermario szintű játékokat WebGL-ben meg JS-ben le tudják programozni úgy, hogy közel 1 GIGÁT eszik a böngésző és 2x3 GIGAHERZ-es CPU magot csúcsra járat eközben.

Tapsvihar!

@knorbert
Értelek meg minden de ez DEV.verzió....
Remélem a hibákat bugreportolod az operának.

@penge™:
Na most őszintén válaszolj nekem arra, hogy te észrevennéd-e, ha egy addon átállítana valamit a flags-ben?

@Cobalt:
A beépített könyvjelzőkezelőről azt mondták, hogy készül.

Amúgy örülök neki, hogy most lefutjuk a "van rajta sapka vagy nincs" című játék harmadik fordulóját, de remélem, ez már rövidebb lesz, mint az előzőek. Először az volt a baj, hogy nem volt semmi információ. Aztán az, hogy kijött egy csupasz böngésző, most meg az, hogy nem olyan ütemben és sorrendben haladnak a fejlesztések, ahogy ti elképzelitek. Tényleg nem unjátok még ezt az állandó elégedetlenkedést?

@knorbert:
Nagyon nehéz lenne elolvasni azt a bejegyzést, amihez hozzászólsz? Csak azért kérdezem, mert direkt szóltam, hogy bugos a könyvjelzősáv, és nem lehet róla törölni.

@Nekomajin: Jelen állapotában nem, de ezért mondtam a fejlett jogosultságkezelést. Amíg az nincs, addig meg marad az óvatosság.

Amúgy ha egy normális fájlban lenne letárolva (mint anno az operaprefs.ini), akkor simán lehetne még akár workarounddal is, hogy ha változik a fájl mérete, akkor jelezzen, mutassa meg a változást és kérdezzen, hogy maradjon-e a változás, vagy állítsa vissza a korábbi verziót.

Szóval meg lehet ezt oldani. Mellesleg megint visszatérünk oda, hogy egy átlagusernek mi keresnivalója van az about:flags-ben? Azon belül is miért kapcsolná be az opera:// protokolon működő kiegészítőket? Ha meg ész nélkül kapcsolgat, akkor vessen magára.

@penge™:
De ez a jelenlegi állapot. Megint az van, hogy nem tudjuk, milyen fejlesztések lesznek a jövőben. Az viszont már többször bebizonyosodott az elmúlt ~2 hónapban, hogy felesleges volt szitkozódni meg találgatni, mert utána jött a pofáraesés.

Fájlméretet, vagy módosítási dátumot meg nem csak az ini fájloknál lehet végezni. És a JSON meg az SQLite ugyanolyan normális fájl, mint az ini, csak maximum te nem szereted.

@Nekomajin: "Nagyon nehéz lenne elolvasni azt a bejegyzést, amihez hozzászólsz?"
Elolvastam, csak átsiklottam felette. Veled biztosan nem történt még ilyen. Köszönöm a kioktatást.

@knorbert:
Bocs, ha kicsit nyers voltam, csak a két elégedetlenkedő megadta az alaphangulatot. No offense.

Egyébként a Desktop Team hozzászólások alapján úgy tűnik, hogy ha a könyvjelzősávra importálod a régiből a könyvjelzőket, akkor egy az egyben átvesz mindent, (és talán még plusz funkciók is lesznek,) csak még belső lapos vagy lenyíló menüs GUI nincs hozzá.

Más téma:
Megkérdeztem, hogy miért kellett átnevezni a Turbót. Tulajdonképpen annyi oka volt, hogy ez az "off-road mód" jobban kifejezi, hogy mire is jó tulajdonképpen. Ez végül is jogos, mert voltak ugye félreértések abból, hogy valaki 10 megás sávszélességnél bekapcsolta, és csodálkozott, hogy lassabb lett a netje.

Saját gom lehetőségről valami hír esetleg? Vagy nem is lessz olyan?

@RaidX:
Eddig nem került elő ez a téma, de majd rákérdezek. Szerintem ha lesz is, kiegészítő formájában lesz.

@Nekomajin: Igen keszul csak meg ne alljon egy Activity Bar-ban meg egy extension API-ban.

Vissza olvasva nem problemaztam a sorrend miat, a sebesseg az mas kerdes, de arra irtam, hogy valoszinuleg velem lesz a gond.

Nekem ugytunik, hogy tulsagosan is naivan nezed a vilagot foleg a "nagy vallalatok" viselkdeses es mukodese szempontjabol. Altalanossagban mindig a legkevesebb eroforrassal a legtobb elegedetlenkedu felhaszanlo pofajat befogo dolgokat lepik meg.
Az Opera eddig nem ilyen volt, legalbbis az elvakult fanatizmusunkban nem ilyennek akartuk latni.

Koszonom szepen a rezidens elegedetlenkedo cimet, buszken fogom viselni.
Ettol fuggetlenul egy eddigi altalam egyetlen hasznalhatonak tartott termekert erzet, kritikus hangvetelu, aggodast, elegedetlenkedesnek nezel az a te problemad.

Én még mindig az Opera 12.16-ot használom...:/
Kipróbáltam az új 15-ös verziót , de engem zavar hogy nincs könyvjelzősáv... és a kezdőlap beállítását se találtam rajta...

@penge™: Sajnos ez egy elege idegesito trend, hogy mindent HTML+JS+CSS komboval probalnak megoldani, mivel gyors es "noveli a fejlesztoi produktivitast". Egyszer majd ez is veget er.

@Cobalt:
Emlékszel, mekkora kört futottunk a Linkkel kb egy hónapja? Akkor is hiába magyaráztam, hogy ne pörögjünk ezen, amíg meg nem kapjuk az első buildet vagy hivatalos információt, mert nem tudjuk, hogy mire készülnek. Igazam lett? Igen.

Most is meg van mondva, hogy dolgoznak a GUI-n. Nem csak azonosítók lesznek, de lehet, hogy még keresni is lehet majd köztük a címsávban. Sőt, elvileg még a gyorshívó elemekhez is lehet majd kulcsszavakat/azonosítókat rendelni. Kismillió könyvjelzős bejegyzés van a changelogban.
De ha valamilyen bolygó együtállás miatt mégse csinálnak hozzá belső lapot vagy lenyíló listát, akkor lesz olyan addon fejlesztő, aki egy hét alatt megcsinálja az API segítségével. És az nem olyan lesz, mint az az Opera Software-es bohóckodás, hanem normális. És mivel ha lesz hozzá belső lap, az is "HTML5" lesz, ezért tulajdonképpen ha csak addonként lehetne telepíteni, akkor is ugyanazt a teljesítményt tudná. De egyelőre erről szó sincs. Konkrétan hivatalos Opera fejlesztő írta, hogy lesz "bookmark manager", ami nem a könyvjelzősáv lesz. Azt nem részletezték pontosan, hogy mit fog tudni, de tetszőleges szintű mappázás például lesz benne.

@Nekomajin: Miben lett igazad? (Se bookmark manager, se link, igeret azert van rajuk) A hivatalos fejleszto velemenye ugyan szamit, de kozel sem annyit mint fel eve. Egyenlore ami ismert az egy sav es egy API, meg egy import opcio a savhoz. Innetol fogva szepen visszabb lehet venni a prioritas listan a manager reszet. Mellesleg a Bookmark Manager, meg nem feltetlenul jelenti, hogy jar hozza UI resze is.

Tovabba azt se felejtsd el, hogy a belso oldalakon mar nem mukodnek a kiegeszitok.

Nyugodtan rugozhatunk azon, hogy te tovabbra is szeretnel fentartasokkal hinni nekik, hogy nem fognak atverni es vissza kapsz mindent idovel, en meg ezt csak fentartasokkal es ennek hangott is adva vagyok hajalando elfogadni.

Gyozkodhetjuk egymast a 2 filozofia felsobbrendusegerol, de ugysem fog sikerulni dulore jutni.
Visszont amikor a sajatodat gyoztesnek nyilvanitod, elote ne felejetsd el, hogy ha nem sirtunk volna minden lehetseges forumon a konyvjelzok ert akkor meg igeretet sem kaptunk volna arra, hogy vissza rakjak, nem hogy megvalositas kezdemenyeket lassunk.

"És mivel ha lesz hozzá belső lap, az is "HTML5" lesz, ezért tulajdonképpen ha csak addonként lehetne telepíteni, akkor is ugyanazt a teljesítményt tudná"

Nana az addon fejleszto az hobbibol fejelszt, ingyen es sajat idelyebol. Mig a rendes belso oldalt fizett fejleszto rendes munka idoben. Na ez a kulonbseg ami miat ezt nem szeretnem addonkent visszont latni. Kulonben is hasznalhato API-t nem lehet fejleszteni ugy, hogy ne legyen hozza legalabb 1 az API iroja altal karbantartott kliens.

@Cobalt:
Ajánlom figyelmedbe a 3. bekezdést: magyaropera.blog.hu/2013/08/08/opera_17_az_elso_fejlesztoi_kiadas/fullcommentlist/1#c20400020
Azóta kiderült, hogy nem lettek kész a szerverek beállításával, ezért még egy hetet biztosan várni kell a szinkronizálásra. (Mellesleg pont ez a szépsége a gyorsított kiadásnak.)

"Nyugodtan rugozhatunk azon, hogy te tovabbra is szeretnel fentartasokkal hinni nekik, hogy nem fognak atverni es vissza kapsz mindent idovel, en meg ezt csak fentartasokkal es ennek hangott is adva vagyok hajalando elfogadni."
Nem hiszek fenntartások nélkül, főleg nem abban, hogy minden visszakerül, mert megmondták, hogy nem fog. De ugyan hadd higgyem már el, amit a saját szememmel olvastam. Nem majd valamikor lesz, nem valaki mondta, hogy olvasta, hogy azt ígérték, hanem Opera dolgozó írta le, hogy most, ebben a percben is dolgoznak rajta.

"Nana az addon fejleszto az hobbibol fejelszt, ingyen es sajat idelyebol. Mig a rendes belso oldalt fizett fejleszto rendes munka idoben. Na ez a kulonbseg ami miat ezt nem szeretnem addonkent visszont latni."
Ha nem te fejleszted a saját idődben ingyen, akkor miért zavar az téged, ha más teszi?

"Kulonben is hasznalhato API-t nem lehet fejleszteni ugy, hogy ne legyen hozza legalabb 1 az API iroja altal karbantartott kliens."
Tökéletes végszó volt. Pont ezért lesz rendes könyvjelzőkezelő az új Operában is.

Namost az a könyvjelző, hogy mostmár egy harmadik helyen is sorba lehet rakni a nagy semmit? (Gyorsindító, gyűjtó, meg most már ez a valami)
Hát ez igazán fantasztikus. Ennél már lassan egy kockáspapír/ceruza kombó is jobb.

@MosoMasa:
Ma tényleg mindenki readonly módban van?

@Nekomajin:
Márminthogy writeonly-ban.

@Nekomajin: Ha én nem elégedetlenkedek, valaki megteszi helyettem, különben felborulna az egyensúly. :D

@penge™:
:DDD

Egyébként hogy mennyire komolyan gondolják, hogy nem Chrome másolat akarnak lenni, azt pont a könyvjelzők példázzák nagyon jól. Simán megtehették volna, hogy a kezdeti követelőzések után betolják a Chrome könyvjelzőkezelőjét, aztán max beleraknak pár extra mezőt később. Ehelyett fejlesztettek egy saját könyvjelző adatmodellt, építettek rá egy API-t, és rögtön a könyvjelzősávot is visszahozták, megelőzendő a könyvjelzők utáni második követelőzés hullámot.

Szóval ha még ezek után is azt gondoljátok, hogy csak a pénz érdekli őket, akkor már tényleg nem tudom, hogy minek kéne történni.
Illetve de, tudom. Majd ha lesz megint jegyzetek meg oldalsáv... :D

Kipróbáltam az új könyvjelzőt és eltüntek a gyűjtő lapon lévő adataim. Még jó, hogy előtte csináltam egy mentést és vissza az egész.

@Nekomajin:

"Ajánlom figyelmedbe a 3. bekezdést: magyaropera.blog.hu/2013/08/08/opera_17_az_elso_fejlesztoi_kiadas/fullcommentlist/1#c20400020
Azóta kiderült, hogy nem lettek kész a szerverek beállításával, ezért még egy hetet biztosan várni kell a szinkronizálásra. (Mellesleg pont ez a szépsége a gyorsított kiadásnak.)"

Ahogy a szememre hanytad az elobb, varjuk ki annak a veget. Az is kerdes, hogy egyaltalan kepes lesz-e az uj megoldas importalni az elzobol verziobol a tamogatot tartalamakat vagy sem.
A gyorsitott kiadas valojaban egy parasztvakitasi strategia amivel meg akarjak gyozni a felhasznalot, hogy gyorsan es dinamikusan fejlodik a rendszser, mikozben szinte semmi erdemi valtoztatas nem kerul bele a verziok kozott.

"Ha nem te fejleszted a saját idődben ingyen, akkor miért zavar az téged, ha más teszi?"

Enegem nem a fejelszto szemelye zavar, hanem a hosszu tavu kiszamithato support. Nem fughetek olyan alapveto kepesegtol aminek a tamogatasa hosszu tavon nincs megoldva. Azt pedig csak hivatalos termek tamogatas vagy egy aktiv kozoseg (itt most a konkret pluginra vonatkozolag ertsd) tudja garantalni, visszont az addon fejlesztes a legtobb esetben szolo jatek.

"Tökéletes végszó volt. Pont ezért lesz rendes könyvjelzőkezelő az új Operában is."
Itt megint te spekulasz, eddig egy API-t es egy "eszkoztar" szeru savot kaptunk. Konkret Manager implementaciot meg nem (amire egyebbkent nem szamitok).

A 2onk vilagnezete kozott az a kulonbbseg, hogy en mar csak azt hiszem el az Operatol amit latok (kesz hasznalhato implementacio es nem szoveges igeretek), hasonloan, mint a tobbi nagyvalalattol. Nem voltam mindig ilyen, fel evvel ezelott meg olyan optimista voltam veluk mint te.

-------------

"Simán megtehették volna, hogy a kezdeti követelőzések után betolják a Chrome könyvjelzőkezelőjét, aztán max beleraknak pár extra mezőt később. Ehelyett fejlesztettek egy saját könyvjelző adatmodellt, építettek rá egy API-t, és rögtön a könyvjelzősávot is visszahozták, megelőzendő a könyvjelzők utáni második követelőzés hullámot."
Ezt ugyan nem nekem irtad, de az ebben foglalt vak naivitas mellett nem tudtam szo nelkul elmenni.
A Chromeban van konyvjelzo tamogatas es meg API is van hozza. Ebbol kifolyolag szinte biztosan annak az atcimkezet verziojat probaljak eladni, mint uj fejlesztest (a helyukeben en is ezt tennem).

A fenti kijelentesd gondolkodasra kesztetett, hogy jobban utanna nezzek.
Szoval hozzadtam 2 bookamrkot a kerdeses savhoz. Es a profil konyvtarban megjelent egy JSON alapu file, Bookmarks neven, a hozzadott konyvjelzoimmel. Megneztem, hogy a Chromeban van-e ilyen nevu fajl. Es kepzeld volt, ugyan azzal a JSON strukturaval es rendeltetesi celal.

A sav visszont legalabb olyan feature ami az eredeti Chromeban nem volt benne. Tevedtem van Chromeban is support.google.com/chrome/answer/95745?hl=en
Erre ugy jottem, ra hogy a Chromos verzioban miert van egy ugyan olyan bejegyzes ("bookmark_bar":), mint az Operas "uj fejlesztesben". Nemi guglizas alapjan meg is talaltam a bekapcsolasi modot.

Ez alapjan visszont legalabb lesz mannager feulet, hogy el lehesen fedni, ezt az atverest. A Chromos berakasa tul nyilvan valo lenne.

A fentiek alapjan kepzeld megtettek, kikapcsoltak a Choromos verzio tiltasat. Szoval gratulalok a marketing maszlag totalis megkajalasahoz.

Osszegezve zero darabb fejlesztest eladtak, vadi uj featurkent es te szo szerint megeted. Gratulalok.

Ezek alapjan mar azt is ketsegbe vonom, hogy az uj Link nem-e a Chrome Sync atcimkezett verzioja lesz. Megjegyeznem, hogy nem zavarna ha az lenne, sot meg orulnek is neki a Link megbizhatosagaval szoktak gondok lenni.

@MosoMasa:

Ember ne égesd már magad...
Ajánlom ezt cikket olvasd el :magyaropera.blog.hu/2013/08/08/dev_next_mi_van hátha felkapcsolódik a villany...

@Cobalt: Láthatóan nem a te böngésződ az opera új irányvonala.Akkor meg miért szenvedsz?Prüszkölsz?Karmolsz?
Kezdhetném én is a hszed bekezdéseit tételesen cáfolni de minek?Szerintem hagyd meg a z operát azoknak akik elfogadják olyannnak amilelyen és válts ha eddig érthetetlen okokból nem tetted..Köszönöm.

@Cobalt: "Megneztem, hogy a Chromeban van-e ilyen nevu fajl. Es kepzeld volt, ugyan azzal a JSON strukturaval es rendeltetesi celal."

Akkor nézd meg jobban. Chrome-ban nincsenek olyan értékek, mint short_name, description, is_trash, visited_time

Valamint a created_date-nek sincs értelme, mert még kiegészítő sincs rá, ami kiolvassa ezt az értéket (kivéve az Xmarks, ami ágyúval verébre). Ja, és mappáknál van még olyan, hogy modified_date, aminek szintén semmi értelme pont amiatt, mert nem olvassa ki semmi és tooltipben sem jelenik meg.

"Ezek alapjan mar azt is ketsegbe vonom, hogy az uj Link nem-e a Chrome Sync atcimkezett verzioja lesz. Megjegyeznem, hogy nem zavarna ha az lenne, sot meg orulnek is neki a Link megbizhatosagaval szoktak gondok lenni."

Ezzel ki is mondtad a lényeget. Gondolom ezért írták, hogy nem lesz olyan, mint az Opera 12, amivel sokaknál kiverte a biztosítékot, még ha azt is mondták mellette, hogy Chrome-klón sem akarnak lenni.

Ami jobb a Chrome-ban az egyszerűen jobb a Chrome-ban. Az Opera usereket szerintem mindig is ez különböztette meg az átlagtól, hogy képesek vagyunk reálisan, objektíven tekinteni 1-1 funkcióra és nem vagyunk elvakult fanboyok.

Volt azért pár hasznos dolog, ami Chrome-ból lett átvéve a Presto-s Operába is, csak néhány említésképp:
- Fülhúzogatós animáció
- Ablak címsorának kiiktatása a fülek és a plusz helyspórolás kedvéért. Ezt Operáék a hülye "dragarea"-juk miatt nem is tudták normálisan implementálni. Pedig 10-ből 8 user azt igényelte volna, mint Chrome-ban és csak a maradék 2 nem, aki meg be tudta volna kapcsolni opera:config-ban. Csak éppen nem annak kellett volna akkor sem defaultnak lenni.
- On Demand Plugin. Igaz, hogy előtte is volt már Flashblock.js és hasonlók, de Chrome-ban jelent meg először beépített funkcióként a Click-to-Play. És oldalspecifikus is ott lett először. Operában meg először az is globális volt. Egyrészt azt sem marketingelték, asszem egy DSK bejegyzés volt összesen, hogy mostantól lehet blokkolni, utána meg könyörögni kellett, hogy legyen oldalspecifikus, mert úgy van értelme.
- Normális címsorkeresés. Igaz, hogy a kulcsszavas keresés már a Chrome előtt bekerült Operába, ahogy a teljes előzménykeresés is, de azért lássuk be, címsorkeresésre az Omnibar volt a legkényelmesebb.
- Ha jól emlékszem, a Pin tab-ot is ők vezették be. Operában Lock Tab volt, ami a (véletlen) bezárást tiltotta meg, a Pin meg kicsibe ment össze. Aztán ezt az implementációt is elcseszték, mert ha valaki lezárta a tabot az azt akarta, hogy le legyen zárva, aki meg "pinnelte" a tabot az azt akarta, hogy menjen össze kicsibe. Igény esetén az Opera korábbi action-funkcionalitásával még egy Pin & Lock is beleférhetett volna, de a lényeg: külön funkció. Ha valaki le akarja zárni, hogy ne zárva be véletlenül, rutinból, annak ne menjen össze és főleg ne mászkáljon el a fülsáv legszélére. Aki viszont ki akarja tűzni, mert mondjuk folyamatosan nyitva lévő, munkatab, amit faviconról felismer, akár e-mail, akár bármi, annak ne lockolja mellé, csak ha igényli. Mert lehet, hogy pont azért akarja kitűzni, hogy helyet spóroljon, de x óra munka után már zárja is be az összeset.

Szóval voltak azért pozitívumai a puritán Chrome-nak is, még ha nem is túl sok.

@Erdeg Fattya: Te meg inkább ne fokozd, mert nagyon jól tudod, hogy NINCS MIRE. Ez nem az, amikor valakinek nem tetszik az új Opel széria formája és vált Toyotára vagy Fordra, mert neki csak arra kell, hogy x fogyasztás mellett elmenjek y sebességgel A pontból B-be.

Ez az, amikor valaki megszeretett egy EGYEDI terméket, ami attól volt EGYEDI, hogy kategóriájában nem volt konkurenciája. Az autós példánál maradva, mintha a gazdag autókínálatot próbálnád ecsetelni, felajánlva a buszt, kamiont és tömegközlekedést is annak, akinek eddig helikoptere volt és játszanád az értetlent, hogy mégis mi szüksége volt arra, mert oké, hogy hosszútávon gyorsabb volt, de sokkal másabb, mint az autó, meg leszállni sem tudott annyi helyre és rövidtávon (1-2 km) meg különben is az autó a gyorsabb. Ráadásul többen használnak autót, mint helikoptert, ezért egymilliárd légy nem tévedhet.

@Cobalt:
Elkészült a könyvjelzősáv, de a belső lap még nem. A könyvjelzősávot már kiadták, lehet tesztelni, nem kell a többire várni. De nézzük nagyobb léptékben. Elkészült a saját keresők hozzáadása, de a szinkronizálás még nem. A keresőket már lehet tesztelni, a szinkronizálás még nem. Ha szerinted ez parasztvakítás, akkor tényleg nem tudom, hogy miről beszélünk. Pont nem érdekel, hogy milyen marketing halandzát tesznek mögé. Engem az érdekel, hogy ha egy feature tesztképes állapotban van ezen a héten, akkor ne kelljen rá várni a jövőhétig. Ez a gyorsított kiadás, a többi csak a szöveg. De úgy látom, hogy te inkább fikázod a szöveget, minthogy örülnél a valós előnyöknek.

"Az is kerdes, hogy egyaltalan kepes lesz-e az uj megoldas importalni az elzobol verziobol a tamogatot tartalamakat vagy sem."
Szerinted leírnának olyat kommentbe, hogy egyszeri alkalommal importál a régi Linkből, ha erre nem lenne képes? Szerinted hónapokon keresztül képesek segget csinálni a szájukból, mikor nagyon jól tudják, hogy az a 2% hip-hop elillan, és lehúzhatják a rolót?

"A Chromeban van konyvjelzo tamogatas es meg API is van hozza. Ebbol kifolyolag szinte biztosan annak az atcimkezet verziojat probaljak eladni, mint uj fejlesztest (a helyukeben en is ezt tennem)."
Nem tudom, hogy mennyire követed ezt a blogot, de már többször volt róla szó, hogy egy az egy egyben kukázták a Chromium UI rétegét, és sajátot írtak helyette. Ebbe bizony beletartozik a könyvjelzőkezelő _felülete_ is. Pont azért kukázták, mert szerintük túl buta, és ha azt használják, akkor nem tudnak egy csomó dolgot implementálni, amit akarnak. Ez is tényleg arra utal, hogy szarnak bele az egészbe, és csak a bevételt akarják növelni.

Az a te bajod, hogy többet foglalkozol a marketinges dumával, mint a szemmel látható fejlesztésekkel.

@penge™:
A fülrögzítés problémáját szerencsére pont meg lehetett oldani a fülcsoportosítással. Először én is szentségeltem, mert nem lehetett látni, ha egy script változtat a title-ön, de aztán rájöttem, hogy ha összehúzok két fület, akkor máris jóság van. Ilyen szempontból favágó módszer, de a célnak tökéletesen megfelelt.

@Erdeg Fattya: Azert "pruszkolok" mert meg lattok remenyt arra, hogy talan lesz belole valami amivel mar tudok mit kezdeni

@penge™: Valoban van benne par uj adat, visszont azok bepakolasa nem tulsagosan nagy problema programozas technikailag.

Nem az volt a celom, hogy lopassal vadoljam meg az Operat, ha annak hangzott akkor elnezest. Speciel orulok neki, hogy nem takoltak sajatot, hanem fogtak a bepitettet es azon csiszolgatnak. Ha mar meg van irva nincs ertelme ujra irni.

A problemam azzal volt, hogy volt kepuk azt mondani, hogy teljesen "uj" fejlesztes. Persze PR celokbol megertem, hogy ezt kellett mondani, de amikor altalam ertelmesnek tartot emberek (pl. Nekomajin) is beszivjak akkor elojon meg a probaljuk meg helyre rakni mentalitas.

@Nekomajin:
Rendben nezzuk sora.

A konyvjelzo sav, sima alap Chrome tartozek.
Mint ahogy az egyedi kereso motor hozadas lehetosege is. (UI oldalrol mindosze par fuggveny hivas.)

A paraszt vakitas arra is vontakozott, hogy az alap Chrome altal tudott kepesegeket ujra engedelyezeset ujdonsagkent adjak el, mikozben csak sima atcimkezesek.

Ismetlem orulok neki, hogy a meglelvo kodbazist hasznositjak ujra, csak annak nem, hogy etetik a nepet azzal, hogy ez uj zsir uj fejelsztes a reszukrol.

A gyorsitott release, mint paraszt vakitast tovabbra is tartom. Ha koveted rendesen a Desktop Team blogot akkor tudod, hogy eddig is pontosan igy csinaltak. Amint tesztelheto alapotba kerult a feature jott a Next csatornan, hetente, sot neha naponta, tobbszor is.

"Szerinted leírnának olyat kommentbe, hogy egyszeri alkalommal importál a régi Linkből, ha erre nem lenne képes? Szerinted hónapokon keresztül képesek segget csinálni a szájukból, mikor nagyon jól tudják, hogy az a 2% hip-hop elillan, és lehúzhatják a rolót?"

Minden tovabbi nelkul, minnel tovabb var a felhaszanlo az altala kedvelt, de elvesztett featurokre annal nagyobb a valoszinusege, hogy meghozza a mentalis mini komrpomiszumokat es marad, mert neki megigertek, hogy jonnek, meg ugy tulajdnoneppen a tobbivel meg tobb macera lenne. Na pontosan ezert, megeri seget csinalni a szajukbol.

"uj fejlesztest (a helyukeben en is ezt tennem)."
Nem tudom, hogy mennyire követed ezt a blogot, de már többször volt róla szó, hogy egy az egy egyben kukázták a Chromium UI rétegét, és sajátot írtak helyette. Ebbe bizony beletartozik a könyvjelzőkezelő _felülete_ is. Pont azért kukázták, mert szerintük túl buta, és ha azt használják, akkor nem tudnak egy csomó dolgot implementálni, amit akarnak. Ez is tényleg arra utal, hogy szarnak bele az egészbe, és csak a bevételt akarják növelni."

Eleg regota kovetem ezt es a hivatalos Operas blogokat. Az UI reteg egy reszenek a kidobasarol tudok es bizonyos szempontbol meg is tudom erteni.
Vissza terve az eredeti vita indito reszre. Azt mondtad, hogy oruljunk, hogy milyen rendesek es nem a Chromosat kapjuk vissza. Ezt par perc utana jarassal meg tudtam cafolni. (Itt most a Bookmark tamogatas erdemi reszerol beszelunk es nem a kulcsinyt biztosito UI oldali megjelenesrol.)

Utanna megprobaltad at terelni, hogy de hisz kidobtak a regi UI, ami csak reszben igaz. A tenyleges munkat vegzo backend kod marad. A belso HTML oldalak, jelnetos reszben az eredetik modositasai.
A Bookamrkok UI resze az eredeti Chromeban egy HTML alapu belso oldal volt es ez az Opera verziojaban is igy lesz. Mint ahogy az "ujrairt" UI reteg nagy resze is belsos HTML alapu oldal. A bookmark sav az kivetelesen, rendes (nem HTML) UI elemnek tunik.

"Az a te bajod, hogy többet foglalkozol a marketinges dumával, mint a szemmel látható fejlesztésekkel."

En nem foglakozom a marketing dumajukkal, az alapjan itelem meg oket amit lattok es hogy az amit modnank menyire fedi a valosagot. Te visszont ugytunik, hogy mindenfele fentartasok nelkul elfogadod a marketing dumajukat. (Elnezest a szemelyeskedesert.)

@Cobalt:
Ha az UI részének tekintjük a belső lapokat, akkor igazad van, ugyanúgy HTML-t használnak. Ez is egy megközelítés. De az UI részei a fülek, a címsáv, a gombok, az eszköztárak, a párbeszédablakok meg a menük is. Már pedig azt mondták, hogy ezt a nulláról újraírták, amit én el is hiszek, amíg valaki be nem bizonyítja a két forráskód összehasonlításával, hogy ez nem történt meg. Mégis miért kamuznának ekkorát, mikor kismillió egyébként elképzelhető dologra rá lehetne fogni, hogy miért tartott közel 6 hónapig kiadni a 15-ös verziót. Simán mondhatták volna, hogy átszervezés, meg barátkozás a kóddal, meg váratlanul felmerülő problémák, meg még számtalan dolog, ami mind tökéletesen eladható lett volna marketing körítéssel.

Az egy dolog, hogy sok mindent el lehet takarni a rizsálással, de az csak addig működik, amíg valamennyi fejlesztés is van a háttérben. Nem lehet a végtelenségig ígérgetni úgy, hogy időnként nem adnak ki valami kézzel foghatót. Már pedig pont az elmúlt pár hétben valósult meg az, hogy óvatosan ígértek, de azt be is tudták tartani. Soha egy olyan mondat nem hangzott el a Desktop Team blogon, hogy a következő verzióban XY feature 100%-os funkcionalitással benne lesz. Olyan mondatok, hangzottak el, hogy most éppen min dolgoznak, és az várhatóan mikor lesz kész.
Dolgoznak a skineken. Látjuk az eredményét? Igen. Hibátlanul működik már? Nem, mert ez egy alfa verzió.
Dolgoznak a könyvjelzőkön. Látjuk az eredményét? Igen. Minden működik már? Nem, mert a 17-es verzió még nem feature-complete.
A héten valamelyik nap azt is megmondták, hogy további fülkezelési funkciók vannak folyamatban, de lesz olyan, ami majd a 18-as verzióban lesz benne.
Úgy is hozzá lehet állni, hogy majd hiszem, ha látom, csak nem érdemes, mert eddig minden elkészült, amit konkrétan megígértek. Lehet arra várni, hogy egyszer majd közbejön nekik valami, és akkor lehet rájuk mutogatni, hogy ugye, hogy én megmondtam. Csak ennek mi értelme van?

"A Bookamrkok UI resze az eredeti Chromeban egy HTML alapu belso oldal volt es ez az Opera verziojaban is igy lesz"
Honnan tudod? Pont annyi esély van rá, mint egy natív GUI-ra. És azt se tudjuk még, hogy csak belső lap/natív felület lesz hozzá, vagy gombos-menüs megoldás is.

"A gyorsitott release, mint paraszt vakitast tovabbra is tartom. Ha koveted rendesen a Desktop Team blogot akkor tudod, hogy eddig is pontosan igy csinaltak. Amint tesztelheto alapotba kerult a feature jott a Next csatornan, hetente, sot neha naponta, tobbszor is."
1: Hányszor volt olyan, hogy hetekig, hónapokig nem kaptunk semmilyen buildet?
2: Hányszor volt olyan, hogy egy feature tesztelhető volt egy buildben, de hónapok teltek el, mire a stabil megjelent?
Most ez maximum két hónap. Augusztus végén kijön a feature-complete 17 Next, onnantól akár mindennapos használatra is alkalmas, ha van kedved bugreportolni. De legrosszabb esetben is szeptember végén elkészül a végleges.
Nem tudom, hogy mi a parasztvakítás abban, hogy időegység alatt ugyanannyi fejlesztést kapsz, csak nem egyszerre, hanem elosztva. Jobb lenne, ha be lenne lőve novemberre vagy decemberre a következő stabil, és addig várni kéne például a saját keresőkkel?

@Nekomajin: 1: Nagyon ritkán, főleg a nyári vagy a karácsonyi szünet alatt, máskülönben legalább 100 DSK módosítás volt benne. És komolyabb jellegűek, mint amiket most DNA-ként hoznak.

2: Sokszor, sőt olyan is, hogy verziót csúszott (pl. HWA), de attól benne maradt tesztelhető formában a véglegesben is.

De a gyorsított attól nem lesz semmivel gyorsabb, hogy hamarabb kapsz véglegest. Maximum durvább bugok átlagfelhasználókat fognak majd elriasztani.

Mert a véglegesnek az a célja, hogy betonstabil legyen, a fejlesztői változat meg fejlesztői változat. Verziószámozástól meg kiadási ütemtől függetlenül.

A gyorsított kiadás maximum azok számára gyorsított, akik eddig is véglegeseket használtak csak. De nekik is inkább átütemezettnek mondanám, mint gyorsnak. Mintha a fizetésedet naponta kapnád meg ahelyett, hogy a hónap elején kapod. Ugyanannyit kapnál, de több részletben.

Szóval semmivel nem gyorsabb. Az adminisztrációs problémák miatt pedig még kicsivel talán lassabb is. Extra compile time + testing time

@penge™: Összességében nem gyorsabb szerintem sem, a gyorsított kiadás, de egy-egy funkcióra vetítve lehet gyorsabb, mint már sokszor volt róla szó, talán te magad is írtad már, egy kevesebb munkát igénylő funkció hamarabb bekerülhet a véglegesbe és juthat el a felhasználókhoz, mint ha várni kéne, hogy összegyűljön egy csokor újítás egy nagy főverzióra mint régen, ez szerintem mindent egybevetve jó, gördülékenyebb a szoftver fejlődése ha összességében nem is gyorsabb, mint ahogy a fizetéses hasonlatodban is. Az egyetlen parasztvakítás benne a számozás, engem is idegesít kissé, de végül is ezzel a módszerrel nehéz is lenne a régi számozást tartani, mert mihez kötnék a főverziót, ha folyamatosan jönnek az új funkciók, ha mondjuk kiválasztanak egy nagyobbat akkor meg az lenne a baj, hogy mi az, hogy csak ennyi változás van egy főverziónál.

@Nekomajin: Nem, csak hát arról van szó, hogy ezt könyvjelzőknek nevezni azért erős túlzás, még akkor is, ha ez még csak a kezdet kezdete. Ezt a semmit még tesztelésre sem érdemes kirakni.
arról meg nem is beszélve, hogy ha egy ilyen stílusú cuccot kívánnak könyjelzőként eladni.

@Nekomajin:
"Honnan tudod? Pont annyi esély van rá, mint egy natív GUI-ra. És azt se tudjuk még, hogy csak belső lap/natív felület lesz hozzá, vagy gombos-menüs megoldás is."

Onnet, hogy olyan szinten nem akartak konyvjelozket, hogy meg a Chrome alapbol is letiltottak. Foleg ugy, hogy HTML alapu volt a manager is.
A felhasznaloi nyomas hatasara nekialtak "implementalni" ami nagyon ugytunik, hogy csak ujra engedelyeztek a Chromos backendet. Azt elismerve, hogy hoza adtak par uj mezot. A HTML alapu oldalak a tobbi funkcionalitasnal nagyon jol mukodtek, radasul a Chrome eseten is HTML+JS+CSS, azt szerkeszteni sokkal konyebb mint rendes UI elemeket le kodolni, melesleg ez esetben tul sok ertelem nincs is rendes UI-t irni hozza. Ugy kb ezekbol.

"1: Hányszor volt olyan, hogy hetekig, hónapokig nem kaptunk semmilyen buildet?
2: Hányszor volt olyan, hogy egy feature tesztelhető volt egy buildben, de hónapok teltek el, mire a stabil megjelent?"

Ez a gyorsitott verzioban is elofordult mar, hogy hetekig nem volt uj build.
Pontosan a regiben is tesztelheto volt az uj feature, de meg nem volt kesz es nem is adtak ki. Radasul a kiadas utan is egyre tobb bug volt benne.

Az uj rendszerben nem funkcionalitas menyiseghez hanem ido dobozokhoz vannak kotve a kiadasok. Ha csak a verzio szamot nezed akkor jaj de dinamikusan fejlodik erzesed keltodik. Ha megnezed a konkurenciat, hogy ott hogyan is nez ki a rendszer, akkor konyu belatni, hogy 3-4 vagy tobb verzionkent kerul bele egyaltalan olyan feature amiert erdemes lenne tenyleg kiadni.

@penge™:
Na fussunk neki sokadjára is. A gyorsított kiadás nem azért gyorsított, mert időegység alatt több munkát végeznek a fejlesztők. A gyorsított kiadás lényege az, hogy ami elkészült, az minél hamarabb a felhesználókhoz kerüljön. A fejlesztéseket kisebb csomagokra osztják, mint régebben, ezért a kevesebb munkát igénylő funkciók hamarabb jutnak el a felhasználókig.

Ha most nem gyorsított kiadás szerint dolgoznának, akkor például a fülek rögzítése nem szeptemberben, hanem lehet, hogy csak az év végén kerülne be a véglegesbe, mert addig nem jönne ki stabil verzió. Nem tudom, hogy miért nem akarod ezt megérteni, de tényleg jó lenne, ha nem futnánk már le ezt a kört többször.
Ha van kedved, számold össze, hogy korábban hány bejegyzés volt a changelogban egy hónap alatt, és most mennyi van. Akkor talán majd felfogod, hogy miről beszélünk.

"A gyorsított kiadás maximum azok számára gyorsított, akik eddig is véglegeseket használtak csak."
Na mégis melyik csoportból van nagyságrendekkel több szerinted?

@MosoMasa:
Pedig ez bizony könyvjelző. Régen is könyvjelző volt, mikor egy fület ráhúztál az eszköztárra, és ott maradt az ikonja. De kb. kismilliószor le lett írva, hogy már az utolsó lépésnél járnak, a felületet készítik. A Desktop Team blogon azt is leírták, igaz, ezt itt nem hangsúlyoztuk ki eléggé, hogy a Dev verziókba folyamatosan, hétről hétre kerülhetnek új funkciók. Ezzel szemben a Next verziókba új funkciók már nem fognak kerülni, csak a benne lévőket csiszolgatják.

Az meg teljesen relatív, hogy mit érdemes tesztelésre kiadni. Nekem például nagyon jól jön, hogy a Dev-ben engedélyeztem a könyvjelzősávot, mert a következő frissítéskor sokkal könnyebben el fogom érni akár a configot, akár a flagset, akár a Desktop Teamet. Korábban sosem használtam, most viszont nagyon kézre esik. Szóval maradjunk annyiban, hogy neked nem tetszik.

@Cobalt:
"Az uj rendszerben nem funkcionalitas menyiseghez hanem ido dobozokhoz vannak kotve a kiadasok."
Pontosan erről van szó. És ez jó dolog.

"Ha csak a verzio szamot nezed akkor jaj de dinamikusan fejlodik erzesed keltodik."
Melyik részét nem érted annak, hogy pont leszarom a verziószámot? Engem az érdekel, hogy ha megcsinálják az X funkciót, akkor azt rögtön adják ide nekem, és ne kelljen megváni, amíg megcsinálják az Y-t meg még a Z-t is. Ha ez szerinted nem jó dolog, akkor tényleg nincs miről beszélnünk.

"Onnet, hogy olyan szinten nem akartak konyvjelozket, hogy meg a Chrome alapbol is letiltottak."
A Chromium teljes UI rétegét kidobták a kukába, és nulláról megírták az egészet. Azt hitték, hogy a nagy innováció majd bejön, ezért a könyvjelzőket egyszerűen nem implementálták a saját UI rétegben.

Úgy látom, hogy most te lettél az ügyeletes jövőbelátó.

@Nekomajin: Ja persze, régen lehet, hogy az volt.
Régen az internet szövegalapú volt, ahhoz képest ugye minden fejlődésnek tudható be.

De a könyvjelzők esetén - ez így mennyivel másabb, mint a gyorsindító, ahol legalább csoportosítani lehet?
Ha ide teszik fel, akkor hogyan lesz könyvtárazva, és miért jó az, hogy a böngésző felület még keskenyebb lesz? Hová fog ott férni pár száz könyvjelző?

@Erdeg Fattya: Neked mi közöd ahhoz, hogy ki mit használ?
Szerinted nem lehet kritizálni, véleményt mondani?
"hagyd meg a z operát azoknak akik elfogadják olyannnak amilelyen" - Na ez a legnagyobb marhaság.
Azért van a desktop team blogja is és ez is pl., hogy szóvátehessünk dolgokat, meg lehessen vitatni, esetleg javaslatokat lehessen tenni.

@MosoMasa:
"Hová fog ott férni pár száz könyvjelző?"
Valószínűleg sehová, de nem is arra való. (Egyébként a kommentek alapján nem tartom kizártnak, hogy mappákat is ki lehet majd rá rakni, amik lenyíló menüként működnek majd, de ez tényleg csak találgatás.)

De tényleg nem értem ezt a felhajtást, amit most rendeztek. Ha most nem teszik be a könyvjelzősávot, hanem megvárják, amíg elkészül a rendes felület, akkor azon menne a siránkozás, hogy már 3 hét eltelt, és még mindig nincs könyvjelzőkezelő. Ehelyett berakták a könyvjelzősávot két okból: Egyrészt van, akinek pont ez kell. (Majdnem) kész van, használja egészséggel. Másrészt megmutatták vele, hogy igen is dolgoznak az ügyön, és hamarosan kész lesz a GUI is hozzá.

Sokan itt most azt játszák, hogy azokat a funkciókat követelik rögtönazonnal, amik nekik a legjobban hiányoznak, és magasról tesznek rá, hogy másoknak meg mások hiányozhatnak, meg hogy a fejlesztők jó esetben valami előre felépített terv szerint dolgoznak, hogy a saját munkájukat is megkönnyítsék. Nem értem, miért nem lehet türelemmel lenni. Addig is simán lehet használni a régi Operát. Én is azt használom, az égvilágon semmi baj nincs vele.

@Nekomajin: "Valószínűleg sehová, de nem is arra való."
Hát ugyan mire való egy bookmark, ha nem arra? O.o

"Egyrészt van, akinek pont ez kell. " - sokra megy vele ... mint írtam erre ott a gyorsindító, meg a gyűjtő, ami pont ugyan ezt tudja, csak valamivel jobban.

"amik nekik a legjobban hiányoznak, és magasról tesznek rá, hogy másoknak meg mások hiányozhatnak, "
Már ne haragudj ez egy baromság. Én mit foglalkozom azzal, hogy neked mi kell? Másrészt a mondatod visszafordítva: te sem foglalkozol azzal, hogy nekem mi kell ... épp most fejtetted ki ugye.

Nem tudom mi a frász bajod van - ha szerinted ez a könyvjelző ebben a formában hasznos és jó, akkor örülhetsz.
Szerintem ha ez így marad, az gagyi és használhatatlan, plusz elveszi a képernyő egy részét.

@MosoMasa:
Szerintem ezt a kommentet te sem gondoltad komolyan.

Egy 1-10-es skálán mennyire nehéz elképzelni, hogy valakinek csak pár darab könyvjelzője van, ami elfér egy eszköztáron is, vagy éppen nagyon sok van neki, de csak a leggyakrabban használtakat akarja kirakni?

"- sokra megy vele ... mint írtam erre ott a gyorsindító, meg a gyűjtő, ami pont ugyan ezt tudja, csak valamivel jobban."
Ja értem. Ha az Opera próbálja megmondani, hogy mit mire használj, akkor fujfujj, hogy képzelik, hogy beleszólnak a szokásaidba, de ha te csinálod ugyanezt, akkor az rendben van.

"Már ne haragudj ez egy baromság. Én mit foglalkozom azzal, hogy neked mi kell? Másrészt a mondatod visszafordítva: te sem foglalkozol azzal, hogy nekem mi kell ... épp most fejtetted ki ugye."
Ez is egy hozzáállás. Értelmi szint kérdése, hogy az ember felfogja-e, hogy rohadt sok munkát kell elvégezni a fejlesztőknek, vagy csak hisztizik, hogy most azonnal akar mindent. Egy teljes képernyőt teli tudnék írni azokkal a funkciókkal, amik nekem hiányoznak, csak én cikinek érezném, ha így viselkednék, mint például te.

"Nem tudom mi a frász bajod van - ha szerinted ez a könyvjelző ebben a formában hasznos és jó, akkor örülhetsz.
Szerintem ha ez így marad, az gagyi és használhatatlan, plusz elveszi a képernyő egy részét."
Az a bajom, hogy idejöttök kommentelni úgy, hogy el se olvassátok normálisan a bejegyzéseket meg a többi hozzászólást. Csak külön a te kedvedért részletezem még egyszer:
- A könyvjelzősáv egy lehetőség, amit nem vagy köteles használni. Ha nem kapcsolod be, akkor nem foglal helyet.
- LESZ rendes könyvjelzőkezelő, csak még nincs kész.
- Ez egy fejlesztői kiadás. Ez azt jelenti, hogy ami kész van, azt beleteszik, hogy ki lehessen próbálni. Nem azért tették bele előbb a könyvjelzősávot, mert azt akarják, hogy te ezentúl azt használd, hanem azért, mert az lett kész hamarabb.
- Most figyelj! A régi Operában is van könyvjelzősáv, csak azon nincs + gomb, hanem simán rá kell húzni a füleket.

@penge™:
>Voltak nekünk fasza, natív programnyelveink, meg x86-os utasításkészletünk, már nem tudott hova fejlődni, de jött a válság is, a GDP nem pörgött, valamit tenni kellett. Kezdjük újra teljesen más alapokon.

Lol, mondjál már nyelvet + grafikus frameworkot amiben egyszerűbb/olcsóbb lenne egy sima beállító felületet összedobni/módosításokat eszközölni rajta, mint HTML+JS+CSS alapon. Ja, legyen multiplatform is, lehetőleg fél perces homokóra meg bugok nélkül.

A Chromeval kapcsolatban mindenhol egyik legnagyobb hibájának hoztad fel, hogy belső oldalakon nem futnak a pluginek, párszor már írtam hogy nyilvánvalóan security okokból van így, hát tessék. :)

Nem azt mondom hogy ez így jól van, de a JS security szempontból nem a legjobb nyelv, a legbiztosabb és legegyszerűbb módszer a teljes tiltás. Így a malware pluginok már csak az e-banking bejelentkezési adataidat lophatják csak el, a webgl-t nem tudják kikapcsolni, ez is előrelépés. :D

>Szóval semmivel nem gyorsabb. Az adminisztrációs problémák miatt pedig még kicsivel talán lassabb is. Extra compile time + testing time

Az extra compile time nettó marhaság, látszik hogy nem fejlesztettél sosem szoftvert nagyobb cégnél. Mivel egyrészt úgyis valami automata build rendszer van, így ezzel nem nagyon megy el senki ideje, másrészt belső a buildek mellett ezek nem osztanak-szoroznak semmit.

A testing time meg nem értem szintén mennyiben változik.

ps.: rég jártam erre, a srácok elég jól tolják, ahogy látom persze a sírás még mindig megy.

@Nekomajin:
"Pontosan erről van szó. És ez jó dolog."
Elso blikre valoban az gyakorlatban mar mas kerdes.

"Melyik részét nem érted annak, hogy pont leszarom a verziószámot? Engem az érdekel, hogy ha megcsinálják az X funkciót, akkor azt rögtön adják ide nekem, és ne kelljen megváni, amíg megcsinálják az Y-t meg még a Z-t is. Ha ez szerinted nem jó dolog, akkor tényleg nincs miről beszélnünk."

Ertem en, hogy egy konstans beta alapotu szoftvert szeretnel. En is igy voltam a Next-el egeszen 9.5 ota.

"A Chromium teljes UI rétegét kidobták a kukába, és nulláról megírták az egészet. Azt hitték, hogy a nagy innováció majd bejön, ezért a könyvjelzőket egyszerűen nem implementálták a saját UI rétegben."

Nem egeszen a belso HTML oldlak csak atszabasra kerultek. A tobbi UI komponensre csak az o szavuk van ami, jelenleg csak fentartasokkal hiheto.
Ebben pont a Bookmark Bar implementalasa ingatott meg. Kifejtettem mar, hogy miert, igy annak a megismetlesetol eltekintenek.

"Úgy látom, hogy most te lettél az ügyeletes jövőbelátó."

Nem kell ide jovobe latas csak par ev nagyvalalati tapasztalat, mint programozo. Nagy mertekben segit abban, hogy ne nezzenek madarnak.

@franatixx: "Ja, legyen multiplatform is, lehetőleg fél perces homokóra meg bugok nélkül."

C vagy C++? Ja, hogy drágább, meg körülményesebb és jobban oda kell tenni magát a fejlesztőknek? Na és? Régen még nem vitték ennyire túlzásba a profitmaximalizációt és igényes programok születtek, igényes programnyelveken alacsony erőforrásigénnyel gyorsak és funkciógazdagok voltak.

Egyébként meg erőforrásigényben a Java-val vetekszik a HTML+CSS+JS, csak response time-ban gyorsabb.

"Mivel egyrészt úgyis valami automata build rendszer van, így ezzel nem nagyon megy el senki ideje"

Ennyi felesleges erőforrásuk van, hogy másra nem kell, mehet a compile 24/7-ben?

Mert nekem még anno, mikor kérdeztem, hogy miért nem osztanak meg gyakrabban buildeket, mint a Chromium trunk buildek, amik óránként jönnek, az volt valamelyik fejlesztő válasza, hogy sok lenne nekik leforgatni.

"A testing time meg nem értem szintén mennyiben változik."

Annyiban, hogy a véglegest jobban le kell tesztelni, mint a Next-et, a Next-et pedig szintén jobban, mint a Developert.

Ráadásul minél több idő telik el két végleges között, annál inkább kijönnek rejtettebb bugok is a snapshotokat tesztelők irányából is akár. Mint pl. régebben a 22 soros HTML crash vagy az Expressz.hu-n a kis képeknél a crash.

Mindent nem tudnak letesztelni WinGOGI-val, de még a QA csapattal sem. Kellenek hozzá az emberek.

Ebből adódóan ha folyamatosan, eloszlatva pakolják bele a feature-öket, akkor nagyobb az esélye az új bugoknak és a regresszióknak is, mint akkor, ha belerakják egyszerre és úgy kapja meg a szélesebb kör, így az internal team kiszűri a triviális bugokat, a többieknek marad a többi. Hosszabb tesztelési fázis, minőségibb kód.

Vagy ha a minőségre gyúrnak, akkor kevesebb új build tesztelése, több új funkció egy egységnyi idő alatt.

@penge™:
A C meg a C++ pont, hogy nem multiplatform, hiszen Winre, Linuxra és Macre is külön le kell fordítani. Arról meg már beszéltünk, hogy régen régen volt, most meg most van. Régen a böngésző egy HTML parser volt pár extrával, ma meg egy komplex programcsomag és futtatókörnyezet.
Egyébként nagyon rendes vagy, hogy még több munkát akarsz a fejlesztők nyakába varrni csak azért, mert a hardcore rétegen belül is egy kisebb csoport még a belső lapokat is át akarja szabni. Ha annyira nagy szükség lesz rá, akkor úgyis meg fogják találni a módját, hogy biztonságosan lehessen kiegészítőket futtatni a belső lapokon is, de a fejlesztés jelenlegi állapotában ne ez legyen már a legfontosabb feladat.

"Egyébként meg erőforrásigényben a Java-val vetekszik a HTML+CSS+JS, csak response time-ban gyorsabb."
Bizonyíték?

"Mert nekem még anno, mikor kérdeztem, hogy miért nem osztanak meg gyakrabban buildeket, mint a Chromium trunk buildek, amik óránként jönnek, az volt valamelyik fejlesztő válasza, hogy sok lenne nekik leforgatni."
Ebben lehet valami, hiszen óránként kiadni egy buildet pont ugyanaz, mint hetente egyet.

"Annyiban, hogy a véglegest jobban le kell tesztelni, mint a Next-et, a Next-et pedig szintén jobban, mint a Developert."
Ugye az megvan, hogy ha egy kiadásban kevesebb új funkció van, akkor a bugok száma is arányosan kevesebb?

"Ebből adódóan ha folyamatosan, eloszlatva pakolják bele a feature-öket, akkor nagyobb az esélye az új bugoknak és a regresszióknak is, mint akkor, ha belerakják egyszerre és úgy kapja meg a szélesebb kör, így az internal team kiszűri a triviális bugokat, a többieknek marad a többi."
Most megint ott tartunk, hogy kiemelsz egy szempontot, és ez alapján mondasz ítéletet. Eközben a valóságban ez úgy működik, hogy fognak egy papírt, és felírják az érveket mellette és ellene, majd megnézik, hogy melyikkel járnak jobban.
Jelen helyzetben például kifejezetten nagy PRO érv az, hogy minél hamarabb befogják a nép száját azokkal, amik már készen vannak.

@Nekomajin: Látom kissé beszűkültél.
Az értelmi képességekkel vagdalózni meg egyenesen tahóság - koma, ismersz?
A problémámat sem érted ...

"Az a bajom, hogy idejöttök kommentelni úgy ..."
Figyumá! Ez itt egy nyitott blog, fórum ha úgy tetszik, az ír ide aki akar, és nem kötelező naprakészen lenni Operából mindenkinek. Érti-e?

És ugyan bocsáss már meg, ha véleményem van - vagy ez itt tilos?

A Statcounter alapján növekszik Magyarországon az Opera felhasználók száma, az IE-t hamarosan le is hagyhatja: gs.statcounter.com/#browser-HU-monthly-201007-201307

@Nekomajin: Nekem 0 darab könyvjelzőm van és én például nem is akarom gyűjtögetni :)

@Nekomajin: "A C meg a C++ pont, hogy nem multiplatform, hiszen Winre, Linuxra és Macre is külön le kell fordítani."

De le lehet fordítani, tehát multiplatform. Ami nem az, az a .NET meg a Visual Basic, ezek még ha workarounddal megoldhatók is, nem mondhatók teljesen multiplatformos nyelveknek.

Igényes, normális programnál ne az legyen már a szűk keresztmetszet, hogy 3x kell leforgatni egy helyett. Úgyis dobtak egy csomó platformot (Solaris, OS/2), maradt a Windows, Mac meg a Linux/FreeBSD

Ja, és gondolom már a sima rendszerintegrációnál (Windows tálca, Gnome/KDE, stb.) is külön kell baszkurálni rendszerekkel, szóval ne ez legyen már a szűk keresztmetszet.

"Bizonyíték?"

www.cubeslam.com/rfbwsm

De sokat linkelhetnék.

"Ebben lehet valami, hiszen óránként kiadni egy buildet pont ugyanaz, mint hetente egyet."

Automata a rendszer, nem? Ha az erőforrás, ami forgatásra megy el, nem kell sehova, akkor pazarlás, ha parlagon hever. A szerver is akkor a leghatékonyabb, ha az erőforrásai 100%-a kihasználásra kerül folyamatosan HASZNOS céllal. Szóval ha nem hiányzik sehonnan az automata leforgatáshoz szükséges teljesítmény, akkor lényegtelen, hogy hányszor forgatnak le új buildeket.

Mellesleg nem kellett volna feltétlenül óránként, akár naponta is jó. Nem erre irányult sem a kérdés, sem a válasz, hanem arra, hogy nincs elég erőforrásuk, vagy jobb dolgokra kell, minthogy mi gyakrabban (ami lehet akár heti két alkalom is) kapjunk buildeket.

"Ugye az megvan, hogy ha egy kiadásban kevesebb új funkció van, akkor a bugok száma is arányosan kevesebb?"

Éppen annyival, amennyivel a teljes kiteszteléshez szükséges idő is kevesebb, mert hamarabb jön egy még újabb kiadás, amiben szintén kevesebb új funkció van, de ezek teljes kiteszteléséhez szintén kevesebb idő áll majd rendelkezésre, miközben a régiben is maradtak még bugok/regressziók.

A Debiannál is így van. A stabil ágat nagyon kitesztelik, híres is a stabilitásáról. Olyannyira, hogy még a testing ágat is használják egyesek ALAPNAK a saját disztrójukhoz.

@Bluemotion: Kár, hogy jelenleg az OPR-t a User Agentben szinte senki nem látja, így Chrome-nak érzékeli.

A Presto-s Opera részesedése nőtt, valószínűleg a negatív reklám okozta publicitás miatt.

@penge™:
>C vagy C++?

Szerinted ezek grafikus felületek összerakásához jó nyelvek? Szerinted melyik nyelven könnyebb egy szaros formot összedobni/módosítani (mert itt arról van szó), hol lehet jobban elszúrni, melyik megoldást könnyebb tesztelni:
- C/C++ alatt valami crossplatform UI framework (Qt, GTK, esetleg saját megoldás, amit persze szintén supportálni kell)
- egyszerű HTML form CSS-sel kicsicsázva, valami JS backenddel

Írtál már életedben egy sor kódot is C/C++ban vagy megint csak a szádat jártatod?

A HTML alapú megoldások egyébként csak sebesség kritikus alkalmazásoknál (pl. Canvasos/WebGL-es grafikák, übercsicsa modern webappok) erőforrás zabálóak, ha olyasmire használod amire a dolog eredetileg ki lett találva (dokumentumok, formok), semmi gáz nincs vele.

>Ebből adódóan ha folyamatosan, eloszlatva pakolják bele a feature-öket, akkor nagyobb az esélye az új bugoknak és a regresszióknak is, mint akkor, ha belerakják egyszerre és úgy kapja meg a szélesebb kör, így az internal team kiszűri a triviális bugokat, a többieknek marad a többi. Hosszabb tesztelési fázis, minőségibb kód.

Ez jó nagy bullshit, úgy nem igaz ahogy van. Pont hogy az "egyszerre sok módosítás" módszernél több a hibalehetőség és összetettebb a tesztelés.

RERO esetében nem határidőre fejlesztés folyik, amikor adott feature elér egy bizonyos stabilitási szintet, akkor bekerül a soron következő release csatornába, amikor meg elér a stabilhoz, bekerül a következő kiadásba. Ott nem az megy, hogy nagy csinnadrattával kihirdették mit fog tudni a soron következő verzió, aztán a pofáraeséstől félve inkább kiadják bogarasan a szoftvert (ugye ismerős?). Ha a soron következő frissítésig nincs kész a funkció, akkor kimegy majd egy hónappal később, na bumm.

Legalábbis ez az elmélet, aztán persze el lehet baszni ezt is, lásd Firefoxék. Chroméknak egész jól megy a dolog, bár nekik nem egy sok éve meglévő release infrastruktúrát kellett átgyúrniuk, nekik ilyen szempontból könnyebb volt.

@franatixx: Oké, feladom. Legyen HTML form. De akkor rakjanak már bele egy nyamvadt "Are you sure?" dialógust, vagy checkboxot vagy akármit, ne szopassák a usert. Mert megint ez a faszság, hogy el akarják dönteni a user helyett, hogy mi a jó neki.

Amúgy a HTML5 régen nem a dokumentumokról szól, hanem arról, hogy komplett webalkalmazásokat rakjunk össze ebben a sebességkritikusan erőforrászabáló nyelvben.

"Legalábbis ez az elmélet, aztán persze el lehet baszni ezt is, lásd Firefoxék. Chroméknak egész jól megy a dolog"

És az Opera szerinted melyikbe fog tartozni? Emlékeztetnélek: A Chrome nagyjából ugyanaz, mint a 0.2-es verzió volt. Annyit fejlődött 30 verzió alatt, amennyit más 5-6, maximum 7 verzió alatt. A hardvergyorsítást is 3 verzión át tologatták és a mai napig saját listájuk van, hogy hol van bekapcsolva és hol letiltva, ahol nem okoz problémát, amit a chrome:flags-ben lehet átírni.

De megint csak azt tudom mondani: Ne legyen igazam.

@penge™:
"De le lehet fordítani, tehát multiplatform. Ami nem az, az a .NET meg a Visual Basic, ezek még ha workarounddal megoldhatók is, nem mondhatók teljesen multiplatformos nyelveknek."
A .NET nem programozási nyelv, hanem futtatókörnyezet.

"De akkor rakjanak már bele egy nyamvadt "Are you sure?" dialógust, vagy checkboxot vagy akármit, ne szopassák a usert. Mert megint ez a faszság, hogy el akarják dönteni a user helyett, hogy mi a jó neki."
Ez teljesen jogos. És ha kulturált formában megírod ezt a fejlesztőknek, és elég sok felhasználó szavaz mellette, akkor biztosan fontolóra fogják venni a dolgot. De a jelenlegi helyzetben ne ez legyen már a prioritás. Kismillió dolgot kell megcsinálniuk így is. Most egyszerűbb volt letiltani az addonokat, és kész.
Nyilvánvalóan nem egy checkbox beszúrása lesz a megoldás, hiszen azt ugyanúgy meg lehet szkriptelni, mint a többi mezőt, de biztosan kitalálnak majd valamit.

"És az Opera szerinted melyikbe fog tartozni? Emlékeztetnélek: A Chrome nagyjából ugyanaz, mint a 0.2-es verzió volt. Annyit fejlődött 30 verzió alatt, amennyit más 5-6, maximum 7 verzió alatt."
Teljesen mások a prioritások. A Google egy ablakot fejleszt, amivel használni tudod a GMailt, az Opera meg egy izmos GUI-t, amivel eszközöket ad a kezedbe. De már megint a verziószámokban gondolkozol ahelyett, hogy időegység alatt elvégzett fejlesztésekben gondolkoznál. Persze a Chrome úgy is elmarad, de nem azért, mert ott hülyék ülnek, hanem azért, mert nekik nem érdekük többet fejleszteni.

"Amúgy a HTML5 régen nem a dokumentumokról szól, hanem arról, hogy komplett webalkalmazásokat rakjunk össze ebben a sebességkritikusan erőforrászabáló nyelvben."
Ez teljesen irreleváns ebből a szempontból. Ezzel csak akkor tudnál érvelni, ha a GUI egy nagy canvas lenne. A belső lapok egytől egyig sima űrlapok, csak szépen meg vannak formázva. Ettől eltekintve semmiben sem különböznek egy random weboldal random űrlapjától.

@penge™:
"Kár, hogy jelenleg az OPR-t a User Agentben szinte senki nem látja, így Chrome-nak érzékeli.

A Presto-s Opera részesedése nőtt, valószínűleg a negatív reklám okozta publicitás miatt."
A StatCounter az exportált CSV fájl szerint már az új Opera verziókat is méri. Egyébként ciki is lenne, ha két hónappal a 15-ös verzió kiadása után egy statisztikával foglalkozó oldal nem így tenne.

@MosoMasa: Szóvá teheted de ha nem használod az operát és itt csak a negatívabb dolgokat fröcsögöd attól se jobb se rosszabb nem lesz a a böngésző....

@Erdeg Fattya: Koma!
Hogy jössz te ahhoz, hogy itt rendre utasítgass engem, vagy bárkit is? Főleg ilyen tahó módon?
Szerinted ha nem használnám az operát, akkor nem lszarnám, hogy van-e könyvjelzője vagy nincs?
Meglehet régebb óta operázok, mint ahogy te internet közelébe értél!
Úgyhogy csak óvatosan azokkal a jelzőkkel!

Gondolt egyet és mától kezdve a router jelszavát mindig be kell írni.
Mi okozhatta a változást. A jelszó el van mentve csak nem teszi a helyére. A többi oldalnál még nem tapasztaltam ilyet.

A temporary mappába való letöltésről és megnyitásról van valami hír, hogy lesz-e?

Áthelyezhető cache?

@fatal:
Én jelenleg nem tudok egyikről sem.