HTML5 Canvas UI
2011-08-18T10:50:48+02:00
2011-08-19T00:15:41+02:00
2022-07-19T04:37:35+02:00
  • A te kommentjeiddel csak annyi a gondom, hogy úgy jön le, hogy nincs benned bizonytalanság, nem 'lehetséges problémkat' vetsz fel, hanem 'deklarálod az igazságot, bemutatod a valóságot'.

    Nyilván azért, mert meg vagyok győződve róla, hogy valós, létező problémákat vetek fel. Ha nem lennék biztos benne, nem írnám le, vagy maximum kérdeznék, nem kijelentenék.

    Ettől függetlenül persze lehet, hogy a probléma nem valós vagy egyszerűen megoldható. Ebben az esetben akkor egyszerűen meg kell írnod, hogy miért nem probléma vagy hogyan oldható meg - és máris ki fog derülni, hogy nem volt igazam vele kapcsolatban.

    Nem értem mi ezzel a probléma...
    Mutasd a teljes hozzászólást!
  • Nem gondolod komolyan, hogy a világnak úgy kell működnie, hogy senki nem innovál, senki nem kísérletezik, hanem mindenki mindent elfogad ahogy van...

    Nem, de azt gondolom, hogy alaposan át kell gondolni a dolgokat, meg kell tervezni őket, mielőtt nekiállunk kódolni. És ha ez az előzetes tervezés során kiderül, hogy millió sebből vérzik a koncepció és rengeteg óriási hátránya van, akkor ugye egy sort sem írunk le belőle, mert nem érdemes megcsinálni.

    Na, most én úgy látom, hogy sikerült a millió seb, hátrány közül néhány igen súlyosat kiemelni, amelyeknek gyakorlatilag egyikére sem tudtál semmit mondani - és amik alapvetően megkérdőjelezik a koncepció, a megoldás jogosultságát, abban az értelemben, hogy annak sokkal több hátránya és korlátja lesz, mint amennyi előnyt hoz ill. ahány korlátot lebont.

    Ettől függetlenül persze tőlem azt csinálsz amit akarsz, és éveket is rááldozhatsz. Csak amíg még elméleti, koncepcionális szinten sem sikerül választ és megoldást találnod a felvetett problémákra, addig ugye gyakorlatilag se tudsz majd azokra megoldást nyújtani. És ha valami több gondot keletkeztet, mint amenyit megold, akkor azt a valamit semmilyen épeszű ember nem fogja használni.
    Mutasd a teljes hozzászólást!
  • Egyébként pedig kifejezetten örülök, ha felvetik a cuccal való problémákat, fontosak a visszajelzések, és még véletlenül sem veszem személyes sértésnek.
    A te kommentjeiddel csak annyi a gondom, hogy úgy jön le, hogy nincs benned bizonytalanság, nem 'lehetséges problémkat' vetsz fel, hanem 'deklarálod az igazságot, bemutatod a valóságot'. De ez csak stílusprobléma, összességében örülök, ha minél többen minél több problémát felvetnek. (Akkor is, ha amit írsz, azok nagyrészén már rengeteget agyaltam.)
    Mutasd a teljes hozzászólást!
  • Mindenképpen kevesebb böngészőspecifikus szívásom van mint pl. a JQuery készítőinek, akiknek sokkal több böngészőfüggő cuccot kellett eltakarniuk, hiszen nem szakadtak el a DOM-tól. Ha nekik sikerüllt kiszenvedniük, akkor nekem miért ne sikerülne a kisebb szívást kiszenvednem?
    Mutasd a teljes hozzászólást!
  • egyetlen józan vezető és a vele az autópályán szembejövő millió őrült ámokfutó példáját juttatja eszembe...


    Az innováció már csak ilyen Sting. Innoválni úgy kell, hogy a legtöbb dologban követed a megszokottat, majd egyvalamiben szándékosan szembemész a millióval, és megnézed, hogy mi lenne ha... És persze nagyeséllyel kiderül, hogy nem működik. Kis eséllyel működik.
    Nem gondolod komolyan, hogy a világnak úgy kell működnie, hogy senki nem innovál, senki nem kísérletezik, hanem mindenki mindent elfogad ahogy van... Persze, ne a 14 éves kezdők akarjanak M.I.- írni, de egy tapasztalt szakember miért ne innoválhatna? A többi 1millió egy nagyrésze kezdő, egy másik része fásult, sohasemmi újat nem alkot, a harmadik része meg mással kísérletezik, ezért nem kísérletezik pont azzal, mint én. Ilyen egyszerű ez.
    Mutasd a teljes hozzászólást!
  • Aha. És pl. ha neki egy window.onload esemény kell? Vagy egy XMLHttpRequest.onreadystatechange esemény? Azokat is emulálod? Vagy ott már szenvedhet majd a böngészőspecifikussággal?

    Flash applet, videó, iframe, stb. hogyan lesz beágyazható az UI-ba? Ezek is z-order-helyesen fognak megjelenni?
    Mutasd a teljes hozzászólást!
  • Arról már ne is beszéljünk, hogy az egész "pixelpontosan mindenhol ugyanolyan UI" koncepció is önmagában is értelmetlen, és a világ sem efelé megy. Ti. nem azt akarjuk mindenhol elérni, hogy ugyanúgy nézzen ki az alkalmazásunk, hanem azt, hogy mindenhol a mindenkori körülményeknek legmegfelelőbb, legoptimálisabb legyen a megjelenése. Ami többek között azt jelenti, hogy pl. egy mobilon tök másnak érdemes az UI-nak (és leginkább annak) lennie, mint egy asztali gépen, mert más beviteli eszközök állnak a két platformon rendelkezésünkre, más pontossággal, és a felhasználói szokások, prioritások is jellemzően mások a két környezetben.


    Hogy a 3 különféle PC-s oprendszeren böngésző embereknek ugyanolyan lesz a megjelenés, az nem nagy gond. Az sem, hogy az n különféle mobilplatformon lesz ugyanolyan. Amit valós gondnak látok, és valóban a legnagyobb dilemma a rendszerem sikerességével kapcsolatban az az, hogy a touchscreenes, picikijelzős mobilokon tényleg más kell, mint egy egeres nagymonitoros PC-n.
    Erre egyelőre azt mondom, hogy egyeőre a rendszeremet desktop rendszerekre szánom, és később megpróbálok ráfeküdni arra, hogy jól le tudjam kezelni a mobilokat is. Ez nem biztos, hogy könnyű lesz, és valszeg az alkalmazásprogramozónak bizonyos kódokat külön meg kell majd írnia mobilra és desktopra. Ez amúgy minden más technológiával is ilyen nehéz kérdés szvsz.
    Mutasd a teljes hozzászólást!
  • A getCursorPosition semmi, ez egyetlen egy fajta input (és annak is csak egy része), ami ráadásul önmagában max. pollozásra jó


    Én garantáltan nem pollozok. Picit leegyszerűsítva ezt csinálom: Rálistenelek a canvas feletti következő dom eseményekre: mousemove, mousedown, mouseup. Képzeld úgy ezeket, mintha hardver megszakítások lennének: megmozdult az egérkurzor a canvas felett, lenyomták az egérgombot a canvas felett, stb... Ezen 'hadrver megszakítások' alapján én okoskodok, gondolkodok a js kódomban (mint más UI rendszerek a C++ kódban), pl. megnézem, hogy azon a pozíción melyik komponenst is érte el az egér, kinek a legnagyobb ott a z koordinátája? (raycast). Aztán a sok gondolkodós kódban szintetikus eventek gazdag tárházát fire-olom a fenti 3 primitív domevent alapján: a komponensekre tüzelek saját mousemove, mousedown, mouseup mellett mouseout, mouseover, click, dblclick eventeket (és még ki tudja miket a jövőben). (Igen, pl. mouseout-ot úgy fireolok, hogy 'rájövök', hogy az előző eseménynél még valamely komponens felett volt a cursor, most meg nem) Az alkalmazásprogramozó csak a szintetikus eventeket látja, garantáltan nem kell törődnie böngészőkompatibilitási problémákkal. (Nekem is csak 10-20 sor kódban amúgy.)
    Mutasd a teljes hozzászólást!
  • - B verzió: megvalósítottam egy getCursorPosition metódust a canvason, ami a domos egérevent canvashoz képesti x,y koordinátát adja vissza.

    A getCursorPosition semmi, ez egyetlen egy fajta input (és annak is csak egy része), ami ráadásul önmagában max. pollozásra jó. Én eseményekről beszéltem, meg főleg arról, hogy hiába lesz egységes a frameworköd a megjelenítés vonatkozásában, ha az események nem lesznek egységesek benne, ill. ha maga a feldolgozó JS kódnak továbbra is szenvednie kell majd a meglévő kompatibilitási problémákkal (pl. abban a vonatkozásban, hogy pl. egyes ojjektumok milyen metódusokat támogatnak, vagy hogy eleve milyen beépített osztályok, típusok találhatók meg a böngészőben).

    A prezentációs réteg hiába lesz tök egységes ha közben a feldolgozó kód ill. az alkalmazási logikai szempontjából fontos funkcionalitás tekintetében a futtató böngészőkben továbbra is jelentős különbségek lesznek, akkor ugyanúgy és ugyanannyira nem lesz hordozható végső soron az alkalmazás. Pl. ha nincs LocalStorage, akkor azon az UI frameworköd nem fog segíteni semmit, még akkor sem, ha kiterjeszted csak UI-ról egy generikusabbá, mert JS kódból nem fogod tudni (effektíven) soha sem emulálni a LocalStorage-et. De mondhattam volna a WebSockets-et vagy bármi mást is.

    A lényeg, hogy ez a frameworköd ill. a benne írt kódok még annyira sem lehetnek majd self-contained-ek, mint amennyire egy ActiveX vezérlő, egy Java applet vagy egy Native Client csomag az. Innentől kezdve az, hogy egységesen lehet majd benne megjeleníteni dolgokat és az pixelpontosan ugyanúgy fog kinézni minden platformon irrelevánssá válik, hiszen önmagában ez kevés lesz.

    Arról már ne is beszéljünk, hogy az egész "pixelpontosan mindenhol ugyanolyan UI" koncepció is önmagában is értelmetlen, és a világ sem efelé megy. Ti. nem azt akarjuk mindenhol elérni, hogy ugyanúgy nézzen ki az alkalmazásunk, hanem azt, hogy mindenhol a mindenkori körülményeknek legmegfelelőbb, legoptimálisabb legyen a megjelenése. Ami többek között azt jelenti, hogy pl. egy mobilon tök másnak érdemes az UI-nak (és leginkább annak) lennie, mint egy asztali gépen, mert más beviteli eszközök állnak a két platformon rendelkezésünkre, más pontossággal, és a felhasználói szokások, prioritások is jellemzően mások a két környezetben. Az ilyen, a környezethez, a lehetőségekhez és a felhasználói szokásokhoz leginkább illeszkedő megjelenés biztosításának legegyszerűbb és legpraktikuabb módja pont annak a fordítottja amit te csinálsz: ti. nem a minél alacsonyabb, hanem a minél magasabb szintű beviteli és prezentációs absztrakciók megvalósítása, mert ez teszi lehetővé a mindenkori futtatókörnyezet számára leginkább, hogy az saját sajátosságaihoz igazítsa az adott vezérlő, beviteli eljárás, stb. működését, megjelenítését.

    Ráadásul a különböző hardveres gyorsítások (akár 2D akár 3D) is csak ilyen, magasszintű absztrakciók, vizuális modellek esetében működhetnek - te meg pontosan szembemész ezzel, és teljesen lehetetlenné teszed, hogy bármiféle gyorsítás működjön, azon keresztül, hogy pixelenként magad akarsz kezelni mindent. Ami megint csak az egyetlen józan vezető és a vele az autópályán szembejövő millió őrült ámokfutó példáját juttatja eszembe...

    Ezt meghívva pedig felépítettem a saját szép és elegáns teljesen szintetikus event rendszeremet, ami természetesen már egységes kód, és semmi köze a dom eventekhez.

    Tervnek szép és jó, de előre borítékolom, hogy ez önmagában marha nagy szívás lesz, és rengeteg kompatibilitási probléma forrása, csak magán a frameworkön belül is. Bár mint írtam, ez lesz a legkisebb problémád a fentiek mellett, amik nagyjából értelmetlenné és okafogyottá teszik az egészet.
    Mutasd a teljes hozzászólást!
  • Ezt meghívva pedig felépítettem a saját szép és elegáns teljesen szintetikus event rendszeremet

    Túl tömören fogalmaztam: Magyarul a domeventeket beszedem, dolgozok velük max 10-20 sornyi ronda kódbaan és helyettük szintetikusan generálom a saját eventjeimet (pl. van rayCast metódus, ami megmondja, hogy melyik komponenst találta el az 'egérsugár'), a saját szintetikus komponensfámon a saját logikám szerint, amelyek szépek, konzisztensek, bönészőfüggetlenek és a komponensek már ezekre aszintetikus eventekre listenelnek.
    Mutasd a teljes hozzászólást!
  • TÖRÖLVE, nadamhu már válaszolt, kár tippelgetnem :)
    Mutasd a teljes hozzászólást!
  • de eseményeket is kezel, adatokat is bekér, és azokat fel is dolgozza valamilyen procedurális módon. Ott is sikerül egységesíteni és elfedni minden különbséget? Ha nem, nem sokat ér az egész. Vagy eddig még el sem jutott a koncepcionális tervezés, annak ellenére, hogy "a Buttonnak pl. már most van vagy egytucat propertyje"?


    Rádbízom, hogy megtippeld.

    - A verzió: a buttonnak már van egy tucat propertyje, 2 hét múlva tech preview, 4000 sornál rart a cucc, de eszembe nem jutott, hogy egy UI rendszernek eseménykezeléssel is foglalkoznia kell. Most hogy mondod, bedől az egész koncepció.

    - B verzió: megvalósítottam egy getCursorPosition metódust a canvason, ami a domos egérevent canvashoz képesti x,y koordinátát adja vissza. Ez a néhány sor ronda kód, a mai JS+HTML fejlesztésre emlékeztet ami böngészőfüggő ifet is tartalmaz. (Szinte egyedüliként a teljes eddigi 4000 sorban) Ezt meghívva pedig felépítettem a saját szép és elegáns teljesen szintetikus event rendszeremet, ami természetesen már egységes kód, és semmi köze a dom eventekhez.

    Az egész libben szinte _egyetlen_ (ok + van pár sor a billentyű eventekre is) ronda, dommal foglalkozó függvény kódja ez:

    CCUI.Canvas.prototype._getCursorPosition = function(domEvent) { // TODO: determine border, and calculate with it... var x,y; if(domEvent.pageX !== undefined && domEvent.pageY !== undefined) { x = domEvent.pageX; y = domEvent.pageY; } else { x = domEvent.clientX + document.body.scrollLeft + document.documentElement.scrollLeft; y = domEvent.clientY + document.body.scrollTop + document.documentElement.scrollTop; } return {x: x - this.browserCanvas.offsetLeft, y: y - this.browserCanvas.offsetTop}; }

    Tippem: Az 'A' verziót nézed ki belőlem.
    Mutasd a teljes hozzászólást!
  • Mivel csak a Canvas-t és a JS core-t használom, ezért a böngészőknek kevés lhetősége va negmással inkompatibilisnek lennie. A Canvas megvalósításban hálistennek szinte nincs is inkompatibilitás a böngészők között, de még ha találok is minimális különbségeket, azt i eltakarom majd a programozók elől. Szóval nem lesz inkompatibilitási szívás.

    Aha. Csak az a baj, hogy a programok, webalkalmazások 99%-a nem csak kiír valamit, de eseményeket is kezel, adatokat is bekér, és azokat fel is dolgozza valamilyen procedurális módon. Ott is sikerül egységesíteni és elfedni minden különbséget? Ha nem, nem sokat ér az egész. Vagy eddig még el sem jutott a koncepcionális tervezés, annak ellenére, hogy "a Buttonnak pl. már most van vagy egytucat propertyje"?
    Mutasd a teljes hozzászólást!
  • Egyelőre úgy gondolom. (De most még 2-3 hónapig szóba sem jön a fejlesztőeszköz készítése, amíg egy 'production ready' mag el nem készül.)
    Mutasd a teljes hozzászólást!
  • A fejlesztőeszközt még mindig webesre akarod elkészíteni? (ilyesmit írtál régebben)
    Mutasd a teljes hozzászólást!
  • Köszi. Reálisan, amíg egyedül csinálom, addig komótosan fog haladni a fejlesztés. Ha találok esetleg később befektetőt vagy ilyesmit akkor van esély, hogy bele lehessen tenni azt a munkamennyiséget, ami elég ahhoz hogy kinője magát, elterjedjen.
    Mutasd a teljes hozzászólást!
  • Csak a teljesség kedvéért, hogy miért van szükség AbstractButton-ra...
    Pl. az AbstractButton-ból származik az ArrowButton is, ami a scrollbarok nyilacskája. Hozzá tartozik a következő stilizáló kód a default stylesheetben, ami a fentiek után jön a kódban:


    if(component instanceof CCUI.ArrowButton) { component.firstActionRepeatTime = 300; component.subsequentActionRepeatTime = 20; component.setArrowColor('#ffffff'); component.setShadow(null); component.setBorderColorAddition(null); }

    Remélem így lehet érezni, hogy kb. milyen jellegű cuccról van szó.
    Mutasd a teljes hozzászólást!
  • Remélem elterjed a megoldásod, és nagyobb cégek is beállnak a kezdeményezés mögé mert amit a böngészőgyártók kínálnak az egy rakás .os
    Mutasd a teljes hozzászólást!
  • Mivel csak a Canvas-t és a JS core-t használom, ezért a böngészőknek kevés lhetősége va negmással inkompatibilisnek lennie. A Canvas megvalósításban hálistennek szinte nincs is inkompatibilitás a böngészők között, de még ha találok is minimális különbségeket, azt i eltakarom majd a programozók elől. Szóval nem lesz inkompatibilitási szívás.

    A komponensekre ortogonálisak a stylesheetek, amik szintén JS kódok, amelyek propertyket injektálhatnak a komponensekbe. (de akár új paint metódust is.)

    A Buttonnak pl. már most van vagy egytucat propertyje, a benne lévő szöveget tetszőlegesen lehet stilizálni, megadható a lekerekítettség, a bevel színe, a háttérszín, árnyék, meg még egy csomó szín addíció, ami az átmeneteket paraméterezi finoman.

    Konkrétan jelenleg így van style-olva a Button a Default stylesheetben:


    if(component instanceof CCUI.AbstractButton) { component.setColor(CCUI.hsla(0, 0, 10, 1)); component.setGradientAdditions([CCUI.hsla(0, 0, 25, 0), CCUI.hsla(0, 0, 17, 0), CCUI.hsla(0, 0, 0, 0), CCUI.hsla(0, 0, -8, 0)]); component.setBorderColorAddition(CCUI.hsla(0, 0, 20, 0)); component.setRoundRadius(3); component.setHoveredColorAddition(CCUI.hsla(0, 0, 12, 0)); component.setPressedColorAddition(CCUI.hsla(0, 0, 0, 0)); component.setShadow(new CCUI.Shadow('rgba(0,0,0,0.6)', 2, 3, 3)); component.setBorderOffset(0); } if(component instanceof CCUI.Button) { component.setMinPadding({top: 2, bottom:2, left: 2, right: 2}); component.setPreferredPadding({top: 5, bottom:2, left: 10, right: 10}); component.setBorderOffset(2); component.setRoundRadius(5); var label = component.getLabel(); if(label) { label.setTextFillStyle('#ffffff'); } }
    (A Button az AbstractButtonból származik, vagyis rá mindkét ág lefut.)
    Mutasd a teljes hozzászólást!
  • Ez jól hangzik.
    Mutasd a teljes hozzászólást!
  • Színátmenetes, lekerekített div-et lehet benne megadni egyszerűen, úgy hogy ie9-ben is működjön? :)
    Mutasd a teljes hozzászólást!
  • Nekem van egy lovam ezen a pályán. A böngészőből csak a JS engine-t és a Canvas-t használja, amúgy egy tisztességes (sőt az én ízlésemnek kifejezetten kafa) vastagkliens technológia (a Swinges gyökerem talán érződik rajta, de azért egész más.). Nem kell a usernek letöltenie semmit, mindenhol megy, ahol van HTML5: tisztán Javascriptben van írva (és tisztán csak a Canvasra rajzol, szóval a DOM-ot le lehet tojni.). Most 4100 sor a kicsike, 2 hét múlva jön a 0.1 (tech preview). Számításaim szerint további 2-3 hónap, mire meglesz annyi komponens, hogy production ready legyen és még nem beszéltünk tooling támogatásról, meg xml-ben megadásról, meg sample, tutorial és marketing hegyekről, csak a központi technológiáról és egy központi minimalista doksiról. Szal' nem két perc, mire egy ilyen kinövi magát.
    A protokoll a UI technológiámat nem érinti, az teljesen ortogonális rá, de nyilván elsősorban JSON over HTTP-vel fogják használni ha használják majd.
    Mutasd a teljes hozzászólást!
abcd