Vizuális fejlesztőeszközök
2014-01-19T22:17:33+01:00
2014-01-27T15:13:50+01:00
2022-07-23T00:52:35+02:00
  • oksi, ha neked nem jött be, hát ez van
    pont egy elvont válasz is lehet a topikra :)
    Mutasd a teljes hozzászólást!
  • Én is évekig voltam DTP-s. Talán úgy az AI 6-tól fogva használom.  Megkerülhetetlen program, de sohase voltam hasra esve tőle. 

    Az a rész amiről én beszélek akkor jön elő, hogyha nem egy kész vektoros ábrát kell átalakítani, hanem valami újat csinálsz, és mondjuk nem kézi rajzot csinálsz mert arra jobb a Blob Brush + Warp + Shape Builder tool. 

    egyáltalán nem ellent akarok mondani neked, biztos szereted meg jól dolgozol vele. 

    Csak példának hoztam fel a témát, hogy azoknak akik rendszeresen használnak - akár egy ilyen vizuális eszközt - ( főleg tervezéshez, fejlesztéshez ) azoknak pont az ilyen egyedi UI elemek mint amilyenek ezek a toolok teszik használhatóvá a programot. Így ezeknek a létrehozása, használhatósága. Dinamikus shortkeyellhetőség fontos eleme a programozásnak.
    Mutasd a teljes hozzászólást!
  • ha te mondod :)
    világszerte DTP-sek milliói (köztük én is) mind oly tudatlanok, hogy Illustratort használunk vektorhoz PS helyett
    Mutasd a teljes hozzászólást!
  • Hali!

    Objective-c hez van az Xcode.
    Oszt kb ennyi.

    Szeretem-e? Háááát...mivel nincs más.
    Arra jó, hogy felépítsem az alkalmazás felületét, már ha standard üzleti alkalmazásról van szó, és nem XML-ben kell túrni.

    Aztán az adatmegjelenítő réteggel vizuálisan meg adatkötöm a kódot. Erre jó...meg arra, hogy a view-k közötti logikai kapcsolatot vizuálisan kiépíthetem, és látom, mi fog történni.

    Viszont ami a logikai kódolást, adatfeldolgozást érinti...annyira mindegy, hogy milyen csillivilli van fölötte, hogy hihetetlen. Legyen azért codeSense (intellisense), mert hajlamos vagyok bármit elgépelni...oszt ennyi. 

    A debuggere úgyis egy rakat sz...akarom mondani lehetne jobb is.

    Példa erre a tegnapi nap. Szerver oldalon megváltozott a JSon adatstruktúra.
    Progi elindít...lefagy..nagyszerű.

    Kaptam egy hibakdot...az a memóriacím, ahol a hiba volt. :DD
    Dehogy a kódban hányadik sor, vagy legalább mellyik osztály, arról semmi...van 30 valahány osztályom, és most olyan 4000 sor kb. Lehet picit több.

    Azt mondta a debugger...hogy egy tömb üres. :DDD

    Jó félnap volt, hogy szépen megnéztem honnét jönnek az adatok..mi van bennük, milyen reakciót vált ki a kódban, és hol lehet null array, vagy legalább egy rossz pointer vagy valami.

    És azajóó ha 2-3 naponta ezt el kell játtszani...mert a debugger annyit azért mondhatna, hogy ....figyejjjééémááá abban a forráskódban van a hiba...vagy valami, de odab_sz elém egy hexa címet meghogy üres tömb aztán oldjam meg.

    Na jól kipanaszkodtam magam.
    Mutasd a teljes hozzászólást!
  • Pont, hogy PS alatt jól ki van dolgozva  a SHIFT, ALT, CTRL használata ... használom is rendesen, ellenben AI-ban  ALT-al P közben még lehet a vektorokat nem simított helyzetbe hozni, de a CTRL totál használhatatlan, kijelöli az egész vonalat, ahelyett, hogy az egyes pontokkal vagy az ívekkel tudnék vele valamit kezdeni. Katasztrófa az egész.
    Mutasd a teljes hozzászólást!
  • Nyilván ez azért is van, mert nehéz is ilyet csinálni. Ehhez az kell, hogy először is a vizuális szerkesztő jól átlátható és bővíthető kódot generáljon, utána pedig a specialitásoktól, amit kézzel szerkesztünk a kódba, ne hülyüljön meg, hanem ismerje fel és ne nyúljon hozzá

    Na ez tényleg nagyon jó lenne
    Én XAML szemmel nézem és sajnos kb kivitelezhetetlen.

    Arról nem is beszélve, hogy itt még ezer dolog változtathatja meg a kinézetet
    Converter-ek, attached property-k
    ezeket háttér nélkül lekezelni vagy ignorálni szinte lehetetlen

    Saját Control létrehozásakor is simán belefutsz egy exception-be, ha véletlenül átmész design módba a VS-ben, mert épp nem fért hozzá valami komponenshez
    gondolom a "DesignerProperties.GetIsInDesignMode(this)" se véletlenül lett kitalálva.
    bár ez utóbbi inkább tűnik gányolásnak (nem is kicsit), de legalább használható
    Mutasd a teljes hozzászólást!
  • azért mert nem tudod az illustratort használni...
    javaslom kezdetnek ismerkedj meg a CTRL gombbal.
    Sokat segíthet görbe rajzolás közben
    rögtön utána jöhet az ALT
    Mutasd a teljes hozzászólást!
  • Olvasgatom a vitát, látom vannak, akik az XML meg más olvasható formátumot gondolják a problémának, amiért manapság alig használunk vizuális fejlesztőeszközöket az UI megalkotásakor.

    Nos, én nem a szöveges formátumot látom problémának, hanem azt, hogy nagyon kevés az olyan vizuális fejlesztőeszköz, amelyben jól összehangolható lenne az, hogy a triviálisabb dolgokat vizuális szerkesztőben csináljuk, a speciális dolgokat viszont már a felületet reprezentáló kód szöveges szerkesztésével. Nyilván ez azért is van, mert nehéz is ilyet csinálni. Ehhez az kell, hogy először is a vizuális szerkesztő jól átlátható és bővíthető kódot generáljon, utána pedig a specialitásoktól, amit kézzel szerkesztünk a kódba, ne hülyüljön meg, hanem ismerje fel és ne nyúljon hozzá, a többi rész pedig továbbra is szerkeszthető legyen vele. Ez bizonyos esetekben lehetetlen feltételrendszer, bizonyos esetekben viszont úgy látom, hogy megvalósítható, csak még nem valósult meg.

    Rossz példának hozom a Vaadin keretrendszer Eclipse pluginjának az UI szerkesztőjét, ami egyébként Java forráskódot generál, tehát bizonyos értelemben még nehezebb dolga van, mint XML esetén lenne. Na ez a szerkesztő a legkisebb kézi változtatásokra behülyül, képtelen annyit kezelni, ha a komponensek szövegei dinamikusan generáltak (többnyelvűség esetén ez elkerülhetetlen), de használhatatlan nem abszolút méretű layoutok és komponensek esetén is. Éppen ezért egyáltalán nem használom ezt az UI szerkesztőt, és mindent az alapjairól kézzel írok meg. És hogy meg lehetne jobban valósítani, arra ott van példának a Swinghez készült szintén Eclipse pluginként működő UI szerkesztő, amely például ezt a két problémát nagyon jól tudja kezelni, és ha jól szétválasztott a megjelenítés és az üzleti logika rétege, akkor egész normálisan használható belenyúlásokkal együtt is. Tudom, hogy látszólag rossz az összevetés, mert egyik egy webes keretrendszer, másik meg egy desktop alkalmazások fejlesztésére használható library, de aki ismeri a Vaadin-t, az tudja, hogy nem a hagyományos webalkalmazás fejlesztésről szól és inkább hasonlít a Swingre vagy más desktop eszköznél megszokottra egy-egy oldal Java kódjának felépítése.
    Mutasd a teljes hozzászólást!
  • "hol is tér el pontosan az UI?"

    Szinte mindenhol, de legélesebben a layerek kezelésénél.

    "Photosop alap vektor szerkesztője jobb mint egy kifejezetten vektor szerkesztésére kitalált program szerkesztője?"

    A photoshop és az illustrator Pencil tooljáról (shortkey:P) beszélek ( röv: iP, aP ).
    Mindkettőnek az a feladata, hogy bezier görbékből sorozatából álló vonalakat rajzolhassunk.

    ( Minden görbe szakaszt 2 pont és a hozzájuk tartozó 2 irányvektor ( szintén 1-1 pont ) határoz meg.
    Ha egy pont két irányvektora - nem vég vagy kezdőpont - egy egyenesre esik, akkor a vonal az adott részen az ív sima lesz,
    az az törés nélküli. Ha a vektor éppen a következő pont felé mutat, vagy megegyezik a ponttal, akkor az adott szakasz egyenes.
    Ha az első és utolsó pont megegyezik akkor egy szép zárt alakzatot kapunk. )

    Alapvetően az iP és az iA is ugyanúgy működik:
    mouseDown -> pont lerakása
    kövektekőz mouseDown -> újjabb pont lerakása.
    start pont over -> kis karika jelzi, hogyha ide klikkelünk akkor bezárjuk az alakzatot.
    Ezzel a módszerrel nagyon gyorsan lehet egyenes vonalakból álló alakzatot létrehozni.

    overPath -> jelzi, hogy új pontot tudunk elhelyezni a szakaszon
    overPoint -> jelzi, hogy az adott pontot törölni tudjuk

    Ha íves szakaszokat szeretnék létrehozni, akkor:
    a mouseDown után nyomvatartva az egeret draggelhetjük a vektor pontot,
    így sima íveket hozhatunk létre. A két funkciót vegyesen használva már szinte tetszóleges alakzatot
    hozhatunk létre.

    Az iP ott veszti el a csatát a photoshop megoldásával szemben amikor menet közben módosítani szeretnénk a
    pontok, vektorok és ívek helyzetén. Mivel ehhez a funcióhoz mindketten egy másik toolt az A-t használják,
    aminek Photoshopban Path Selection Tool, Illustratorban Direct Selection Tool a neve. Az ikonjuk nagyjából megegyezik,
    viszont a Photoshopban nem kell a toolok között cserélgetnünk, mivel elég a shiftet nyomvatartani és máris mozgathatjuk a pontokat,
    és a szakaszokat. Illustrátornál ugyan át tudunk váltani A-al selection-re, és a pontokat mozgathatjuk is, viszont az
    íveket már hiába fogjuk meg valami megmagyarázhatatlan oknál fogva miközben az ívet mozgatnánk a hozzá tartozó
    két vektort normál irányba mozgatja, ami igen furcsa eredményt okoz, gyakorlatilag ahelyett, hogy a kívánt irányba tudnánk
    mozgatni a görbét egy villanás alatt csinálunk egy hurkot, amit amúgy az esetek 99%-ban kerülni kellene.
    És akkor ez az adobe illustrator a világ jelenlegi legprofibb vektoros rajzolóprogramja, amit ugyanaz a cég ír,
    mint a photoshoppot (sic.)
    Az átváltás se megy mindig AI gyorsbillentyűzettel ( A,P - messzebb nem is lehetne egymástól ) , hanem lehet az UI-n klikkelni az ikont.

    Még a pont törlést is rosszabbúl csinálja az Illustrator mint a Photoshop, az iP egyszerűen kiveszi a pontot, míg a photoshop
    a két vektor változtatásával igyekszik megtartani a formát a pont törlésével.

    Plusz még 10-20 egyéb apróság mind a gyorsbillentyűk és egér használat terén amit most nem írok le.

    Gyakorlatilag ezért inkább használok PS-t ha egy precíz vektoros ábrára van szükségem, mint AI-t.
    Inkább szenvedek a konverzióval.

    PS-ben akkor használom a vektorokat, amikor akár pixel alatti maszkolásra van szükség.
    De eleve könnyeben javítható nem destruktív maszkolást tesz lehetőve mint a lasszó.

    "feltöltésében biztos. mindegy egyéb...."

    Talán nem meglepő, de az ívek és a pontok mozgatásában is alul marad az AI a Flash-el szemben. 

    Állítólag pont az AI CC-nek az egyik "nagy" újítása az ívek mozgatása ... végül is még csak 2014-et írunk. Ennek ellenére rengeteg olyan terület van ahol az AI teljesít a legjobban, például talán a CS5 óta veri a Flash-t a nyomásérzékeny táblával való rajzolásban ( addig az a funkció igazából hiányzott belőle ).

    Az is érthetetlen, hogy az amúgy egy olyan remek ötlet, mint a width tool miért nem működik a brush-al rajzolt vonalakkal, hogyha a P-el működik.

    ( a feltöltés AI-ben Shape Builder Toolnak nevezik - shift+M - az se triviális )
    Mutasd a teljes hozzászólást!
  • Gyakorlatilag inkább olyan mintha egy ősosztály propertyjeit állítgatnád. Mint ha mondjuk delphiben lenne egy formod, ami mindegyik őse (így is szokott lenni), és annak állítgatnád a magasságát/szélességét. Csak ahogy ott is egy idő után a többszörös öröklődés lenne jó, itt is pillanatok alatt eljutsz oda. A css-nél meg a "többszörös öröklődés" megoldható. Hiszen lehet egy dived, amit több css  osztállyal formázol. Mondjuk: 
    <div class="floatleft bgred corner-all">
    Mutasd a teljes hozzászólást!
  • A css-ben gyakorlatilag property-ket állítgatsz, csak elég kényelmetlen módon.
    Mutasd a teljes hozzászólást!
  • Érdekes módon az egy igen megosztó program ( sokat használtam / használom ), mármint a tervező kollégáim általában használják, de nem kedvelik. Pont amiatt, hogy az UI-ja annyira eltér a Photoshoptól, amit viszont szinte mindenki szeret. 
    Én pozitívabban állok hozzá, mert vannak bizonyos vektoros feladatok amiket a legjobban Illustratorban lehet megoldani. Valamint verzióról verzióra nagyon sokat fejlődött. Ugyanakkor meg kell jegyezni, hogy a photoshop alap vektoros szerkesztője fényévekkel jobb, mint az illusztrátoré. A flash pedig fényévekkel az illusztrátor előtt járt a vektoros ábrák feltöltésében.

    1. hol is tér el pontosan az UI?
    2. Photosop alap vektor szerkesztője jobb mint egy kifejezetten vektor szerkesztésére kitalált program szerkesztője?
    3. feltöltésében biztos. mindegy egyéb....
    Mutasd a teljes hozzászólást!
  • Most volt egy érdekes vita a weben, hogy
    PSD to HTML is Dead
    PSD to HTML is not dead

    Edit: Ez a hozzászólásszerkesztő nem tudja elmenteni a linkek neveit, legalábbis Firefox, Linux alatt...
    Mutasd a teljes hozzászólást!
  • Én nehezen tudnám elképzelni komponens alapokon a weboldalakat.
    Például az egyik oldalon minden elemnek van kerekítése, a másikon nincs. Persze származhat minden vizuális komponens a kerekíthető komponens ősosztályból. De mivel a kerekítés nem mindig ugyanolyan, így ennek az ősosztálynak is fel kellene kerülnie a oldalra, hiszen jó lenne valami alapértelmezett kerekítés. Igen ám, de ha változtatok egy elemen, akkor annak a kerekítése minden tekintetben egyedi lesz? Vagy csak abban a tekintetben, amit megváltoztattam? Nagyon hamar eljutsz oda, hogy szeretnél egy kicsit kézzel hozzátenni csak ahhoz az elemhez...

    Persze részben már megoldották a kívánságod, egy elemet jól formázhatsz csak css osztályok megadásával, például jquery-ui. Én nem vagyok ebben nagyon elmélyülve, de biztosan létezik valami eszköz amivel alap html elemeket "rádobálhatsz" egy ablakra és azoknak megadhatsz css osztályokat és akár formázhatod is (dreamweaver?). Persze a végeredmény általában az, amit itt többen jeleztek, hogy utólag nem szeretnének belenyúlni abba a generált kódba. Ráadásul nem az a sok idő, amíg elkészül egy html oldal css és html része. Hanem az, amíg megtervezed, hogy hogyan vágd szét a psd-t, ami amúgy csillió layerből és vektorgrafikus ikonokból áll. Egy profi sitebuilder akár egy óra alatt megvan azzal, amivel én mondjuk 2 napot sz..k. Ha Ő elkér érte 25e+áfát (ami órabérben számolva horror magas), akkor is nagyjából fele áron csinálta, mint én, mondjuk munkaidőben. Nem beszélve a minőségről, meg arról hogy nem kell nekem megvenni se a windowst, se a photoshopot (és még ki tudja mit, ami kellhet még a kapott psd darabolásához).
    Mutasd a teljes hozzászólást!
  • Adobe Illustrator, igazad van kihagytam ( mert nem is gondoltam rá )

    Érdekes módon az egy igen megosztó program ( sokat használtam / használom ), mármint a tervező kollégáim általában használják, de nem kedvelik. Pont amiatt, hogy az UI-ja annyira eltér a Photoshoptól, amit viszont szinte mindenki szeret. 
    Én pozitívabban állok hozzá, mert vannak bizonyos vektoros feladatok amiket a legjobban Illustratorban lehet megoldani. Valamint verzióról verzióra nagyon sokat fejlődött. Ugyanakkor meg kell jegyezni, hogy a photoshop alap vektoros szerkesztője fényévekkel jobb, mint az illusztrátoré. A flash pedig fényévekkel az illusztrátor előtt járt a vektoros ábrák feltöltésében.
    HTML fejlesztésnél jól jön, hogy tud SVG-t menteni. Igaz, hogy néha a saját maga által elmentet SVG-t már nem tudja beolvasni ( CS6-ost használok, lehet, hogy a CC verzióban már orvosolták ezt. )

    A minap kipróbáltam az Inkscape-t is,  abban is találtam olyan megoldásokat ami a többiekből hiányoznak - vagy csak én még nem találtam még meg - egy bajom van vele, PC-n rettenetesen lassú egy ctrl+A 50+ vonal esetén. 

    a blender tényleg ingyenes(talán ez az egyetlen előnye ngv). mindösszesen 1 embert ismerek, aki ezt használja

    Én is használom, no nem azért, mintha profi lennék benne, hanem vannak olyan helyzetek, amikor egy 3D modellezővel olyan eredmény születik, ami pusztán 2D-ben nem lenne lehetséges, mint konkrét tárgy tervezésnél (  Kwandera: háromdé - a terv a páromé én csak a megjelenítésen dolgoztam ).  

    Gyakran használom csak úgy - free hand - modellezésre, szobrászkodásra. Készítettem már érme nyomó géphez mintát vele. De akkor is elengedhetetlen volt, amikor 3D-s flash programhoz csináltam vele grafikát - semmi komolyra nem kell gondolni ( sajnos) -- még mindig nem tisztult le bennem, hogy three.js-el vagy flash+away3D-el érdemesebb-e 3D feladatoknál gondolkodnom, mindkettővel lehet alkotni, de mindkettőnek vannak olyan megoldásai, amik miatt nem folytattam velük a küzdelmet  --

    A lényeg, hogy a blender fut szinte mindenhol: linux, osx, windows , bárki használhatja, nem kell tőle tartani, szinte minden tervezési feladathoz jól jön. Ha csak 2 program lehetne a gépemen, akkor a chrome után tuti ez lenne a második, annyira generikus.
    Mutasd a teljes hozzászólást!
  • A grafikus designer pont azért volt jó a Delphiben, mert általános dolgokat meg lehetett vele oldani gyorsan, és átláthatóan, a specialitásokat pedig le lehetett fejleszteni kódból, és onnantól kezdve ezek ugyanolyan elemek voltak mint minden más.  Ha megnézed a weboldalak 99%-át, Pl. a prog.hu-t, de ilyen Pl. az index.hu is, vagy bármelyik hírportál vagy céges weblap, kb. szabványos elemekből épülnek fel. Nem sok olyasmijük van, amit ne lehetne akár egy 20 évvel ezelőtti Delphis form szerkesztővel vizuálisan megszerkeszteni.

    Vannak persze spéci oldalak, Pl. játékok weboldalai, vagy egyes prémium márkák oldalai amik speciális vezérlőket / effektusokat tartalmaznak, de ez nagyon a kisebbség, és jórészt itt is meg lehetne oldani az egyediséget komponens alapon.
    Mutasd a teljes hozzászólást!
  • ja igen, az hogy a téma elment "mivel irjuk le a htmlt jobban" irányba, az ugyan nem baj, de a html nem minden fejlesztés netovábbja. mindenesetre főleg mobilon/pc-n futó programok elkészítsére gondoltam az elején. ehhez használható vizuális editorra, programozást könnyítő eszközre.
    Mutasd a teljes hozzászólást!
  • akkor flash helyett inkább illustrator, ha már vektorgrafikáról van szó, de legyünk teljesek.

    photoshop, illustrator
    ezzel a pixel és vektor grafikát le lehet fedni
    flashbe és blend-be is lehet mindkettőt importálni(meg szinte az összes 3d-be)
     
    3d progik
    a blender tényleg ingyenes(talán ez az egyetlen előnye ngv). mindösszesen 1 embert ismerek, aki ezt használja, igaz Ő profi ebben, a művei is kint voltak (talán most iskint vannak) a belender oldalán.
    Amúgy kicsit olyan mint a CAD. különbözik mindentől, szokatlan megtanulni

    Az elöbbi vitákat olvasva, itt most kitérnék a MAYA-ra, amiben lehet ascii és bináris formátumba elmenteni. És ez nem véletlen. Pont a 3rdparty pluginek miatt elég csúnyán el tud szállni a cucc,ilyenkor jó, hogy egy ascii állományt kézzel lehet szerkeszteni.

    visszatérve nekem a ligtwave a favorit, de ha realtime shader kell akkor marad a maya

    shaderek
    UDK - Npp - fxcomposer - maya kombó
    az udk shader editora nagyon jó. a grafikus pontosan meg tudta mutatni mit akar.

    flash -director
    na ezt a kettőt nem tudtam megszokni
    valahogy nem jött kéz alá, hogy frame-ben adjam meg azt, amit időben kellene.
    Mindettől függetlenűl sokáig használtam mindkettőt. Tényleg könnyen és gyorsan lehet velük eredményes munkát felmutatni.

    most wpf van.
    ott az expression blend. kezdésnek tényleg jó.
    de ahogy már meg lett fogalmazva, komolyabb projektet már nem érdemes vele csinálni.

    tehát marad a kézzel gépelés.
    nem értem, hogy pár gyártó hülyesége miatt (képtelenek egységes böngészőt csinálni)miért fejlesztők százezreit akarjátok szivatni :)
    Mutasd a teljes hozzászólást!
  • Felmerült bennem, hogy vajon mennyire tudjuk használni ezeket az eszközöket.

    nem tértél el nagyon, sőt, az egyik kérdéskör pont erre vonatkozott, miszerint mennyire használhatóak ezek az eszközök. szivesen veszek minden véleményt, de nyilván a gyakorlat során szerzett tapasztalat többet ér bárki részéről, mint a "mi lenne ha" okfejtés. de hangsúlyozom, utóbbi is kell.
    jó lenne igazából sok olyan összehasonlítás, hogy xy dolgot z vizuális eszközzel nagyon könnyen oldottam meg, míg gépelős programozással macera lett volna, viszont w problémát szinte lehetetlen ezzel az eszközzel megoldani azért mert ..., és itt a gépelés mentett meg
    Mutasd a teljes hozzászólást!
  • Szerintem az UI teljesen szétválasztható a fejlesztés többi komponensétől és emiatt nyugodtan lehet a geometriai modellezés mentén, vizuálisan fejleszteni.


    Szerintem ez azért így nem teljesen igaz, mert az UI nem csak megjelenő interakciós elemekről szól, hanem az interakció kezeléséről is. Legegyszerűbb esetben mondjuk egy egér ( 1 időpontban csak 1 koordináta változik, plusz 2 gomb meg a wheel ).
    Amit gyorsan bonyolíthat, ha  hozzávesszük a billentyűzetet is.  A történet az új mobil eszközök megjelenésével még tovább eszkalálódik, az érintő képernyőkkel, gesztusokkal, gyorsulás, hő, irány ... stb. érzékelőkkel, netalán hangfelismerés. 
    Pont egy-egy új UI megvalósításnál jön elő az nagyon gyorsan, hogy még korlátozott eszköz esetén ( desktop + adott feladat ) esetén sem triviális, hogy a általános UI elemek úgy működnek, ahogy az mi szeretnénk.

    Egy vizuális fejlesztőrendszernél nagyon gyorsan belefutunk abba a szituációba, amikor nem érhetjük el vele a kívánt célt.   
    Ellenben hagyományos programozási módszerekkel mindezek a feladatok "könnyedén" megoldhatók. 

    ----

    Vizuális fejlesztő eszköznek én a papírt és az írószert tartom. Rendelkezik ugyanazzal az előnyel, mint a sima szövegszerkesztő: bármilyen gondolat megjelenítésére képes, gyors és mindig kéznél lehet. Ha ez túl hétköznapi, akkor ott vannak a rajzoló programok. - ismétlem magam, de a flash a legjobb ilyen rendszer, mert gyorsan lehet benne rajzolni, F7 és már jöhet is a következő rajz.  [ , ]  a mászkálás a képek között.  Fontos még szerintem, hogy egy 3D-s tervező programot is megismerjünk, ez az a terület, amit a sima papír alapú rendszer már nem pótol, mert nem mindenki tud jól rajzolni térben. Itt komoly segítség egy ilyen program. Ebben a blender az egyik legjobb. Free, elég gyors, szinte mindent meg lehet benne csinálni - a hátul ütője, hogy kicsit nehéz kiismerni.

      -----
    Felmerült bennem, hogy vajon mennyire tudjuk használni ezeket az eszközöket. Bocsánat, hogy eltértem az "eredeti" vizuális fejlesztőeszközök felvetéstől, én inkább az említett univerzális eszközökben hiszek
    Mutasd a teljes hozzászólást!
  • Jó hosszú az okfejtésed, csak semmi értelme nincs. Hiszen az alapprobléma az, hogy különböző (böngésző)gyártók különböző módon haladnak a fícsörök implementálásával, a nem specifikációk által nem tárgyalt vagy nem rögzített pontokon eltérő értelmezéseket alkalmaznak, illetve különböző kísérleti vagy saját maguk által kitalált, nem szabványos dolgokat raknak bele a böngészőikbe. Ezért nem működik minden weboldal pontosan ugyanúgy minden böngészőben. Nem pedig azért, mert a felhasználó vizuális szerkesztő nélkül is, kvázi a kódolási szinten összeállíthat egy tetszőleges adatállományt.

    A 3. pontod azért is totál értelmetlen adott esetben, hiszen nyílt szabványokról beszélünk a web esetében, amik másképpen nem is működhetnek, mint nyíltan, ill. ez a lényegük, hogy nyíltak, és bárki megismerheti és implementálhatja őket. Innentől kezdve pusztán csak felvetni is azt, hogy valami saját, a végfelhasználó/fejlesztő által kvázi nem ismert formátumban tárolom az adatokat, teljesen értelmetlen, azon túl is, hogy mennyire öncélú, hogy mindezt csak azért csinálnám, hogy a felhasználó ne nyúlkálhasson bele.

    Ha ilyen módon történő "megoldása" a problémának megengedhető is lenne, akkor sem security through obscurity révén kellene ezt megcsinálni (tehát hogy azzal gátlom a felhasználót, hogy nem mondom el neki az adatok kódolásának módját), mert hogy az visszafejthető, megkerülhető. Hanem úgy, hogy a generátor/szerkesztő eszköz valamilyen digitális aláírással látja el a vele létrehozott, megtervezett adatállományt, amit feldolgozás előtt pedig a futtatókörnyezet ill. az értelmező ellenőriz. És ami mellett akkor akár szöveges formában is lehetne az adatokat tárolni annak bármiféle veszélye nélkül, hogy abba bárhol bele tudna "rondítani" a felhasználó triviális módon.

    Persze mondom, ezen a vonalon pusztán elméleti síkon gondolkodni is teljesen értelmetlen, mert hogy webes környezetben minden ilyesmi kizárt, ill. mert az LC által említett kompatibilitási problémákat nem az keletkezteti, hogy a felhasználó közvetlenül szerkesztheti a markupot - így utóbbinak bármiféle gátlása, akadályozása sem oldja meg azt.

    Ráadásul a vizuális tervezéshez is - ami a topik témája lenne - nagyjából nulla köze van.
    Mutasd a teljes hozzászólást!
  • ui3.: Kellően obfuszkált szöveges fájl is megteszi egyébként, csak ami már annyira obfuszkált, hogy ember számára:
     - nem olvasható
     - nem írható

    ^^az szerintem akár már lehet inkább bináris is azonnal
    Mutasd a teljes hozzászólást!
  • Hát én erre most csak úgy reagálnék, hogy érvelni és szöveget érteni egyaránt nem úgy érdemes, hogy szó szerint próbálja az ember érteni a másik mondanivalóját, hanem sokat segít, ha megpróbálkozunk mondjuk olyannal, hogy észleljük mi volt a hasonlat célja és miért hozta a másik. Mellesleg nyilván minden hasonlat sántít, de a lényegi információ nem arra vonatkozott, amin lovagolsz:

    "Ezzel szemben pl. egy XML és egy bináris XML, egy szöveges és egy bináris WML is pontosan ugyanazokat a szerkezeteket, pontosan ugyanazt az információt és pontosan ugyanabban a struktúrában tartalmazza - pedig bájtszinten nyilván abszolút nem hasonlítanak megjelenésükben egymásra."

    Nem az a lényeg, hogy maga a bináris reprezentáció közvetlenül előnyös, hanem arról, hogy közvetett módon az. Tegyük fel, hogy írok egy html helyettesítő technológiát, ahol egy grafikus szerkesztő van a felhasználói felület kialakítására. Hasonlítsuk össze mi történik, ha bináris xml-ben tárolom a fájlformátumomat, ha szöveges xml-ben és mi akkor, ha valami saját bináris formátumban, ami nem dokumentált (mármint nyilvánosan nem az, de belsőleg nyilván az és tervezett):

    1.)  Szöveges XML:
     - Fogom a vizuális tervezőt és kattintgatok, hogy mi hogyan legyen a gui-ban.
     - Egyszer csak jön valami, amit nem tudok érdemben megoldani a vizuális szerkesztővel, sem pedig a vizuális szerkesztő official extension point-jai segítségével (tehát amivel mondjuk bean-eket tehetsz be újakat, amit a rendes nyelvi leírással adsz meg), vagy utóbbival csak bonyolult módon.
     - Rájövök, hogy amit a felületen kattintgatok és amit a felület által adott grafikus modell segítségével leírok, az egy xml formájú köztes nyelvre fordul le, amit aztán a böngészőm web4 pluginja értelmez.
     - Rákeresek, hogy van-e megoldás a problémámra ebben a nyelvben.
     - Ha megtalálom a megoldást, akkor valamit hekkelek: mondjuk az adott modult / képernyőt megírom eleve kézzel xml-ben, vagy a kigenerált xml-t módosítom kézzel, de az is lehet, hogy azt mondom magamban, hogy fú, egy rakás kutya.... ez a grafikus editor - használom inkább közvetlen a leírónyelvet mert végülis nem olyan rossz dolog az xml...
     - Sose szólok a fejlesztőnek, hogy ez a probléma fellépett. Akkor kezdődik csak valami, ha a kóderek napi munkájának 2/3-át érinti a baj kb. a többit így meghekkelgetjük.

     + Jön a microsoft és megtetszik neki a web4 technológiám.
     + Implementálják az interpretert és kiegészítik az ő menő dolgaikkal.
     + Kialakul mindenféle szabványügyi bizottság, de az IE11 ami elterjed a világ 89%-án és 10 év múlva is fut legalább 20%-án, az csak egy korábbi szabványt (vagy nem szabványos web4-et) támogat.
     + Rájönnek az emberek, hogy a web4 xml régi változatának random tagjeinek a kombinálásával elérhető egy későbbi featúra, de csak IE11-en fut ez így.
     + Fogják a kódot és teleírják ilyenekkel, meg külön szakember lesz rá, aki ezzel foglalkozik.
     + A kód egy nagy részében tök jól fog keveredni az ui leírás és az ilyen nem-funkcionális követelmények különböző dolgai.


    2. ) Bináris xml:
     - Fogom a vizuális tervezőt és kattintgatok, hogy mi hogyan legyen a gui-ban.
     - Egyszer csak jön valami, amit nem tudok érdemben megoldani a vizuális szerkesztővel, sem pedig a vizuális szerkesztő official extension point-jai segítségével (tehát amivel mondjuk bean-eket tehetsz be újakat, amit a rendes nyelvi leírással adsz meg), vagy utóbbival csak bonyolult módon.
     - Ha elég egyszerű ember vagyok és fogalmam sincs arról mi az a bináris xml, akkor megáll a tudomány és vagy abbahagyom a termék használatát, vagy írok a fejlesztőknek.
     - Ha nem egyszerű ember vagyok, vagy nagyon kell egy megoldás, akkor elszánt keresgélés után rájövök, hogy amit a felületen kattintgatok és amit a felület által adott grafikus modell segítségével leírok, az egy bináris xml formájú köztes nyelvre fordul le, amit aztán a böngészőm web4 pluginja értelmez.
     - Megnézem milyen xml-t reprezentál a bináris, utánaolvasok hogyan épül fel egy bináris xml stb...
     - Rákeresek, hogy van-e megoldás a problémámra ebben a nyelvben, vagy találok egyet (valszeg kevesebb találat lesz a keresésemre, de lesz lásd itteni pontok)
     - Ha megtalálom a megoldást, akkor valamit hekkelek: mondjuk az adott modult / képernyőt megírom eleve kézzel xml-ben, amit binárissá fordítok, vagy a kigenerált xml-t módosítom kézzel hexedit-ben, vagy egy bináris xml editálására szolgáló dologban, de az xml-t maximum úgy használom, hogy totál előről megírom újra és mindig lefordítom egy binárisra fordítóval. Természetesen ekkor rá vagyok hagyatkozva a bináris xml fordító szoftver minőségére is, ami megint csak third party dolog lesz valószinűleg...
     - Ha nem találok megoldást más gyártó web4 terméke után nézek.
     - Valószínűleg ha nem tudom megoldani, akkor szólok a fejlesztőnek, hogy a probléma fellépett, de még mindig előfordulhat, hogy annyira pró valaki, hogy maga megoldja és elfelejt visszajelezni...

     + Jön a microsoft és megtetszik neki a web4 technológiám.
     + Implementálják az interpretert és kiegészítik az ő menő dolgaikkal. Természetesen mindenképpen kell egy vizuális szerkesztőt is fejleszteniük ez esetben, mert nem elég az alapnyelvet kiegészíteni.
     + Kialakul mindenféle szabványügyi bizottság, de az IE11 ami elterjed a világ 89%-án és 10 év múlva is fut legalább 20%-án, az csak egy korábbi szabványt (vagy nem szabványos web4-et) támogat.
     + Rájönnek a nagyon pró emberek, hogy a web4 xml régi változatának random tagjeinek a kombinálásával elérhető egy későbbi featúra, de csak IE11-en fut ez így.
     + Az ilyen nagyon pró emberek vagy írnak majd saját új web4 implementációt, ami versenyezni fog a meglévővel, vagy nem, de nem mindenki fog ezzel játszani, hanem inkább kerülik a furaságokat a fejlesztők, mondjuk más termékre állással, vagy frissítéssel.
     + A felhasználók pedig azt fogják látni, hogy a weblap nem működik, csak "web4.9 kompatibilis böngészővel".


    3.) Saját belső bináris formátum:
     - Fogom a vizuális tervezőt és kattintgatok, hogy mi hogyan legyen a gui-ban.
     - Egyszer csak jön valami, amit nem tudok érdemben megoldani a vizuális szerkesztővel, sem pedig a vizuális szerkesztő official extension point-jai segítségével (tehát amivel mondjuk bean-eket tehetsz be újakat, amit a rendes nyelvi leírással adsz meg), vagy utóbbival csak bonyolult módon.
     - Ha elég egyszerű ember vagyok és fogalmam sincs arról mi az a hexeditor, akkor megáll a tudomány és vagy abbahagyom a termék használatát, vagy írok a fejlesztőknek.
     - Ha nem egyszerű ember vagyok, vagy nagyon kell egy megoldás, akkor marha sok elszánt keresgélés, szívás és próbálgatás után TÖBBÉ-KEVÉSBÉ rájövök, hogy amit a felületen kattintgatok és amit a felület által adott grafikus modell segítségével leírok, az milyen bináris reprezentációban kerül eltárolásra.
     - Rákeresek, hogy van-e megoldás a problémámra a bináris piszkálásával. Nem túl sok találat, eleve a formátumról megoszlanak a vélemények, hogy pontosan mi micsoda benne.
     - Ha megtalálom a megoldást, akkor valamit hekkelek: mondjuk megszerkesztem a grafikus szerkesztővel a felületet, majd módosítom kézzel hexedit-ben.
     - Ha nem találok megoldást más gyártó web4 terméke után nézek. Ez ebben az esetben elég valószínű lesz.
     - Valószínűleg ha nem tudom megoldani, akkor szólok a fejlesztőnek, hogy a probléma fellépett, de még mindig előfordulhat, hogy annyira pró valaki, hogy maga megoldja és elfelejt visszajelezni, de azért ennyi szívás után ennek nemigen van esélye...

     + Jön a microsoft és megtetszik neki a web4 technológiám.
     + Implementálják az interpretert és kiegészítik az ő menő dolgaikkal. Természetesen mindenképpen kell egy vizuális szerkesztőt is fejleszteniük ez esetben, mert nem elég az alapnyelvet kiegészíteni és még az is lehet, hogy a bináris formátumuk is teljesen egyedi lesz, ezzel ellehetetlenítve a fent leírt trükközést / hekkelést.
     + Kialakul mindenféle szabványügyi bizottság, de az IE11 ami elterjed a világ 89%-án és 10 év múlva is fut legalább 20%-án, az csak egy korábbi szabványt (vagy nem szabványos web4-et) támogat. Ahhoz, hogy menjenek a régi dolgok mindenképpen szükséges a vizuális editort használni, mert az a garancia rá, hogy mindenhol legalább hasonlón nézzen ki, hiszen a különféle binárisok eltérhetnek rendesen.
     + Rájönnek a nagyon pró emberek, hogy a web4 xml régi változatának random tagjeinek a kombinálásával elérhető egy későbbi featúra, de csak IE11-en fut ez így. Nemigen történik semmi, maximum lokális hekkelések egyedi projekteknél, de azokat mindenki kerüli mint a franc.
     + Az ilyen nagyon pró emberek vagy írnak majd saját új web4 implementációt, ami versenyezni fog a meglévővel, vagy nem, de mindenki kerülni fogja a hekkelést, mert nem akar szívni. Marad a más termékre állás, vagy frissítés.
     + A felhasználók pedig azt fogják látni, hogy a weblap nem működik, csak "web4.9 kompatibilis böngészővel".


    Mint mondtam: Nem az a lényeg, hogy technikailag tudod reprezentálni szövegesen és binárisan (és 42-es számrendszerbeli adatfájlként, vagy sql adatbázisként)  is magát a struktúrát, hanem az, hogy milyen emberi és játékelméleti vonzata van az egyes lehetőségeknek.

    Amúgy ha megfigyelitek, akkor elég sok helyen elhangzott az "más gyártó termékét kezdi használni" jellegű szöveg, ami egy ilyen technológiát kitaláló és protezsáló cégnél egy plusz veszély lehet a sikerre nézve (amikor mondjuk a web4 technológia leváltaná a html-t), de így legalább nem olyan cég fog ebbe belekezdeni, aki nem tud ennyit bevállalni a veszély területén...

    Persze azért ez csak az én véleményem. Nem azt mondom, hogy csak ez az út járható, hanem szerintem bizonyos esetekben ez a jobb. Munkában a legtöbbször olyan reprezentációt használok külső tárolásra, ami a legegyszerűbb éppen az adott esetben, de az otthoni hobbiprojektjeimben, illetve a diplomamunkámban direkt erőltetem a binárist, ahol ezeket a lehetséges jelenségeket látni vélem. Ez mérlegelés kérdése természetesen és a turing teljes / whitespace vs C hasonlattal arra szerettem volna csak rámutatni, hogy bár szerinted csak reprezentáció-technikai kérdésről beszélek, itt sok emberi vonatkozása is van a dolognak és esetemben ez a fontosabb oldala a megfontolásoknak.

    ui.: A bináris xml-re való utalásodat plusz bónuszként értékelem, mert enélkül nem tudnám ezt a szintet külön bemutatni itt feljebb. Én kicsit bináris döntésként a teljesen szöveges és a teljesen saját és olvashatatlan között döntök, de ez a köztes tényleg egy másik eset még pluszban, más pro-kontrával.

    ui2.: Szerintem az UI teljesen szétválasztható a fejlesztés többi komponensétől és emiatt nyugodtan lehet a geometriai modellezés mentén, vizuálisan fejleszteni. Azért amikor a felületet tervezi valaki, akkor szerintem sokszor akkor is rajzol mondjuk papíron, ha html-ben, xaml-ben, vagy ilyenekkel ír le dolgokat kézzel, illetve ha nem is rajzol, de a saját agyában grafikusan képzeli el a dolgokat. No emiatt gondolnám, hogy érdemes eleve grafikusan fejleszteni, vagy legalábbis van bizonyos előnye, természetessége. Seperation of concers elv egy alkalmazása.
    Mutasd a teljes hozzászólást!
  • Ez megint ugyanaz a dolog, mint ha azzal érvelnénk mondjuk különböző nyelvek használhatóságát tekintve, hogy mindhárom tesztalany turing teljes, így tökéletesen jó mind - aztán mondjuk eközben a brainf*ck-ot, whitespace-t, C-t és PHP-t akartam volna mondjuk összehasonlítani, ami ebben a formában láthatóan fals eredmény lenne ezen szemlélet mellett.

    A hasonlatod teljesen rossz, hiszen a programozási nyelvek nem csak az információkódolási modelljükben térnek el (tehát, hogy milyen kulcsszavakkal, írásjelekkel kell kódolni bennük egy-egy algoritmust szöveges formára), de képességeikben (az általuk támogatott típusokban, nyelvi szerkezetkben) is. Sőt, tipikusan még identikusnak tekinthető forráskóddal is jellemzően alapvetően eltérő tényleges műveletsort kódolnak. Hiszen pl. egy tök sima szorzás is valójában teljesen más mögöttes műveletsort jelent PHP-ben és C-ben (eltérő futásidejű ellenőrzések, dinamikus típuskiterjesztés, stb.).

    Ezzel szemben pl. egy XML és egy bináris XML, egy szöveges és egy bináris WML is pontosan ugyanazokat a szerkezeteket, pontosan ugyanazt az információt és pontosan ugyanabban a struktúrában tartalmazza - pedig bájtszinten nyilván abszolút nem hasonlítanak megjelenésükben egymásra. És ha a HTML-nek is lenne bináris formája, arra is ugyanaz lenne igaz. A képességei, az hogy mit tud reprezentálni, ettől önmagában nem változnának. És a böngészők se kezdenék el hirtelen mind ismerni és tudni az összes képességet, az összes CSS attribútumot, az összes API-t, pontosan ugyanúgy.

     A lényeg itt az volt, hogy a szöveges reprezentáció magában hordozza azt, hogy a közvetlen reprezentáció emberek számára is olvasható és írható - nem csak a program belső használatára van (illetve még ha arra is lenne, akkor is bele tudsz könnyen firkálni).

    Ami (ti. hogy az emberek szerkeszthetik) nem keletkeztet semmiféle kompatibilitási problémát, aminek megoldását LC látni vizionálta egy bináris formátumban. Ráadásul nyilvánvalóan egy úgymond bináris formát, fájlt is szerkesztgethetnek az emberek. Abba is belemódosíthatnak, vihetnek fel úgymond érvénytelen értékeket - sőt, igazából utóbbit még sokkal könnyebben és sokkal nagyobb eséllyel teszik, pont azért, mert nem tudják olyan könnyen maguk is ellenőrizni és átlátni az adathalmaz érvényességét, mint egy szöveges kódolás esetén.

    A példához visszatérve, ha a weboldal megjelenítési részét csak grafikusan tudnád szerkeszteni egy-egy erre való szoftverrel és binárisan elmentené a kinézetet, amihez mondjuk csak az adat-bindingeket és hasonlókat írnád meg szöveges kóddal és a backing részeket, akkor nem lenne olyan

    Milyen nem lenne?

    Nem arról beszélt, hogy megoldja a kompatibilitási gondokat, hanem hogy mivel szét lenne választva az a reprezentáció, aminek a segítségével szerkesztesz (grafikus reprezentáció a képernyődön), attól amivel tárolódik az egész (egy bináris, rejtett reprezentáció, amit nem piszkálsz) az történne várhatóan, hogy az olyan böngészők (és természetesen azok a grafikus szerkesztők), amik nem pontosan tudják implementálni a szabványt eltűnnének a süllyesztőben és nem lennének versenyképesek lévén nem lenne megoldás arra, hogy egy gagyi böngészővel futtass valamit pl. olyan módon ahogy most van rá mód, hogy IE6-ra elágazol a reprezentációban.

    Ez megint nem igaz. Nyilvánvalóan a bináris reprezentációt is éppen úgy lehetne félre- - vagy legalábbis eltérő módon vagy hiányosan - értelmezni, mint a szöveges reprezentációt. Ezt a bináris kódolás semmilyen értelemben nem akadályozná meg. A másik oldalon a szöveges reprezentáció értelmezése is lehet egységes (lásd HTML5).

    Csak magam tudom ismételni: a bináris, az egy információkódolási forma, ami definíció szerint nem lehet képes önmagában semmilyen módon sem befolyásolni azt, hogy az adott információhalmaz értelmezésére, feldolgozására megalkotott különböző implementációk (adott esetben böngészők) mennyire egységesek, milyen szándékos vagy szándékolatlan eltérésekkel rendelkeznek.

    Viszont ha úgy választjuk szét a dolgokat, hogy minden olyat, amit lehet, azt így vizuálisan szerkeszd meg, mentsed el egy ember számára nem piszkálható bináris formátumba és csak a többit írd le kóddal az szerintem a jó/jobb irány.

    Miért? Miért lenne jó ha mondjuk azért, mert vizuálisan tördelek egy dokumentumot, nem férnék hozzá a szöveges formájához és nem tudnék abban belejavítani egy komplex vizuális szerkesztő hiányában is? Miért lenne jó ha egy kis kapacitású, gyenge és így a vizuális környezet futtatására nem képes eszközön nem tudnám szerkesztni az adathalmazt, ha közben én pontosan ismerem a kódolás struktúráját, és az említett szerkesztő hiányában manuálisan is elő tudom állítani ugyanazt az eredményt?

    A kétpaneles nézőkés szerkesztők se véletlenül alakultak ki, hiszen nagyon fontos, hogy pontosan lássa az ember mi is lesz a végeredmény és teljesen más mentálisan egy szövegalapú és egy vizuális elképzelés folyamata is.

    A kétpaneles szerkesztők pont annak bizonyítékai, hogy a vizuális tervezés adott esetben nem (vagy legalábbis nem minden esetben) hatékonyabb. Ha az lenne, akkor nem lenne szükség két panelre, hanem elég lenne csak maga az úgymond vizuális panel, és azon folyhatna a tervezés, az adatbevitel. Viszont valójában nem ott folyik, hanem a másik - tipikusan szöveges - panelen (vagy ott is), amely esetben a vizuális panel csak a visszaellenőrzést szolgálja. Tehát kvázi csak egy előrehozott tesztet testesít meg, de a tervezés ill. adatbevitel maga nem azon, hanem a szöveges panelen történik - mert ott célszerűbb, gyorsabb, ott lehet csak minden funkciót korlátozás nélkül elérni, stb.
    Mutasd a teljes hozzászólást!
  • "

    'Nem. Akkor nem kezdene el agyalni senki, hogy hogyan lehet rágányolni a böngészőre az adott funkcionalitást, hanem szépen kimondanák hogy ez a böngésző ezzel az oldallal nem kompatibilis.'
    Mert miért? Attól, hogy teljesen vizuálisan tervezel meg, építesz fel és stilizálsz valamit, funkcionálisan változik bármi annak a működésében? Ugye hogy nem? Ha egy formot Delphi-ben vizuálisan tervezel meg, a jellemzőit vizuálisan állítod be, akkor másként fog működni, mint ha ugyanazt a formot sorról sorra Delphi forráskódból építenéd fel és állítanád be a jellemzőit ugyanúgy? Ugye hogy nem? Vagy ha egy JPEG grafikát Photoshop-ban rajzolsz meg vizuális módon, az bármivel többet fog tudni, másként fog viselkedni, stb. mint ha ugyanazt a grafikát procedurális úton generálnád le mondjuk egy C programból? Ugye hogy nem? Semmi teteje nincs annak amit mondasz.

    Értsd már meg, hogy az egész szöveges-bináris dolog csak kódolási, reprezentációs különbség, ami önmagában semmilyen funkcionális, sőt, információtartalmi különbséget sem jelent (leszámítva a redundanciát). Ennél fogva pedig semmilyen funkcionális probléma (mint pl. kompatibilitási gondok) kezelésére nem képes, illetve eleve, semmilyen hatással nincs a funkcionális működésre.

    "

    Ez megint ugyanaz a dolog, mint ha azzal érvelnénk mondjuk különböző nyelvek használhatóságát tekintve, hogy mindhárom tesztalany turing teljes, így tökéletesen jó mind - aztán mondjuk eközben a brainf*ck-ot, whitespace-t, C-t és PHP-t akartam volna mondjuk összehasonlítani, ami ebben a formában láthatóan fals eredmény lenne ezen szemlélet mellett.

    Itt nem az volt a lényeg, hogy a már futó programban van-e jelentősége a reprezentációnak, mert akár 42-értékű logikával rendelkező változókkal is reprezentálhatsz valamit ha az nem látszik kifele. A lényeg itt az volt, hogy a szöveges reprezentáció magában hordozza azt, hogy a közvetlen reprezentáció emberek számára is olvasható és írható - nem csak a program belső használatára van (illetve még ha arra is lenne, akkor is bele tudsz könnyen firkálni).

    A példához visszatérve, ha a weboldal megjelenítési részét csak grafikusan tudnád szerkeszteni egy-egy erre való szoftverrel és binárisan elmentené a kinézetet, amihez mondjuk csak az adat-bindingeket és hasonlókat írnád meg szöveges kóddal és a backing részeket, akkor nem lenne olyan

    "Tehát ha a HTML nem szöveges lenne ill. nem létezne szöveges reprezentációja, az az ég világon semmiféle kompatibilitási problémát nem oldana meg."

    Nem arról beszélt, hogy megoldja a kompatibilitási gondokat, hanem hogy mivel szét lenne választva az a reprezentáció, aminek a segítségével szerkesztesz (grafikus reprezentáció a képernyődön), attól amivel tárolódik az egész (egy bináris, rejtett reprezentáció, amit nem piszkálsz) az történne várhatóan, hogy az olyan böngészők (és természetesen azok a grafikus szerkesztők), amik nem pontosan tudják implementálni a szabványt eltűnnének a süllyesztőben és nem lennének versenyképesek lévén nem lenne megoldás arra, hogy egy gagyi böngészővel futtass valamit pl. olyan módon ahogy most van rá mód, hogy IE6-ra elágazol a reprezentációban.



    Szöveges tárolás esetén nem segít teljesen sajnos még az, ha a fent említett két reprezentáció (tervezési és amivel tárolódik) fogalmilag így külön lenne választva (vannak ugye most is grafikus html szerkesztők ilyen huzogatósak), mert hiszen a végső tárolási állapot akkor is ember számára érthető és MINDIG lesz valaki aki ezt kihasználja.



    Amikor nagyobb a szabadság, akkor teljesen más irányvonalak rajzolódnak ki és feleslegesen túl sok szabadságot engedni meg nem érdemes és butaság sok esetben. Arra gondolok, hogy oké, nyilván ha szövegesen tárolod, akkor is elképzelhető olyan "lefutása a világnak", hogy soha senki se piszkál bele a reprezentációs kódba, de ez nyilván a valóságban nem így zajlik majd. Hasonlóképpen azzal, hogy szöveges a tárolás és nem egy elrejtett bináris, amit a hozzávaló eszközzel alakítasz grafikusan mint azt mondtuk kisebb a nyomás arra, hogy jól legyen a rendszer kitalálva és kompatibilis legyen minden ezt megvalósító szoftverben, mert esélyed sincs érdemben kézzel belematatni abba, ami így fekete dobozzá válik, persze mondhatjuk, hogy hát így is lehetnek olyan cégek akik figyelnek ugyanezekre a tervezési szempontokra, mert hát mégis csak versenyelőny ez is, de mindegy, hogy mennyit nyom az ilyesmi a latba: ha ugyanis totálisan használhatatlan az, ami nem szabványos (mert nem tudsz beletúrni) akkor nem keletkeznek hekk-megoldások hanem az emberek még kínában is befrissítik az IE6-ot valami másra, mivel, míg ha meg lehet oldani, hogy azzal is fusson az oldal (mert a technológia engedi a trükközést), akkor sokkal nehezebben cserélődnek a technológiák és marad a gányolás.

    Persze szerintem ennek az egésznek semmi köze a webhez, bár én örülnék egy ilyen formátumnak a html helyett, amit csak vizuális szerkesztővel tudsz szerkeszteni és bytekód keletkezik, a kódot pedig csak bindingokra és hasonlókra írod meg közvetlenül...

    "A vizuális tervezés nem önmagában attól és azon keresztül segít sok esetben, hogy vizuális, hanem attól, hogy elrejt bizonyos megvalósítási részleteket előled, illetve él bizonyos alapértelmezésekkel, amik megadását megspórolja neked."

    Viszont ha úgy választjuk szét a dolgokat, hogy minden olyat, amit lehet, azt így vizuálisan szerkeszd meg, mentsed el egy ember számára nem piszkálható bináris formátumba és csak a többit írd le kóddal az szerintem a jó/jobb irány. Egyébként ami azzal nem értek egyet, hogy ami alapvetően vizuális, annál nem hátrányos ha azt szövegesen írod le. A kétpaneles nézőkés szerkesztők se véletlenül alakultak ki, hiszen nagyon fontos, hogy pontosan lássa az ember mi is lesz a végeredmény és teljesen más mentálisan egy szövegalapú és egy vizuális elképzelés folyamata is. De szerintem józan ember egyetért pl. azzal, hogy ha újságot tördélsz, akkor kényelmesebb egy grafikus WYSIWYG eszköz annál, hogy fogsz egy hatalmas text fájlt és abban firkálod mi hogyan legyen - mert kb. erről a két lehetőségről vitázgatunk (sarkítva persze)
    Mutasd a teljes hozzászólást!
  • Mit magyarázzak el? Azt, hogy ugyanolyan sokfajta funkciót és beállítási lehetőséget csak ugyanolyan összekomplexítású rendszerben lehet megvalósítani és elérhetővé tenni? Vagy azt, hogy ha mesterségesen leszűkíted (pl. csak úgymond vizuális jellegűekre) azt a modellt, amelyben a funkciókat és lehetőségeket ábrázolni ill. elérhetővé tenni akarod (ahelyett, hogy megengednéd a lehető leghatékonyabb, pl. nem feltétlenül vizuális reprezentációjukat), akkor azzal összességében nem hatékonyabbá, hanem nehezebbé és körülményesebbé teszed használatukat és elérésüket?

    A vizuális tervezés nem önmagában attól és azon keresztül segít sok esetben, hogy vizuális, hanem attól, hogy elrejt bizonyos megvalósítási részleteket előled, illetve él bizonyos alapértelmezésekkel, amik megadását megspórolja neked. Sőt, eleve előbbi (ti. az egyszerűsítés) az ami lehetővé teszi azt, hogy egyáltalán úgymond vizuális formában is hatékonyan ill. egyáltalán felfogható módon ábrázolni lehessen (pl. egy ikonnal) egy amúgy egy vizuális feldolgozáshoz egészében túl komplex elemhalmazt (pl. egy soros porti kommunikációs komponenst, vagy egy adatbázist, táblát, stb.).

    Tehát a vizuális tervezésben nem a vizualitás az ami elsődlegesen gyorsít, hanem a ritkán használt ill. az adott tervezési fázisban szükségtelen információk elrejtése és ezáltal a szerkezet átláthatóbbá tétele, illetve a már említett alapértelmezések automatikus alkalmazása, ami azok megadását spórolja meg neked.

    A fentiekből következik, hogy minél több mindent jelenítesz meg és teszel elérhetővé a rendszer valódi ill. teljes komplexitásából egy vizuális modellben, annál kevésbé lesz hatékony utóbbi, hiszen annál jobban csökken átláhatósága, és annál több kérdést kell feltennie neked (az alapértelmezések alkalmazása helyett). Végső soron pedig ha a vizuális felület ugyanolyan sok opciót kínál, mint a szöveges vagy bináris reprezentációs forma, akkor ugyanolyan komplexxé is válik felépítése, szerkezete, megértése és használata, mint előbbié. Ezzel együtt pedig értelmét veszti alkalmazása is, illetve gyakorlatilag ekvivalens lesz az említett szöveges vagy bináris reprezentációval.

    Hiszen lássuk be, hogy végső soron egy forráskód, sőt, a képernyőn megjelenő bináris bájtkód is vizuális reprezentációja a programnak, a szöveges szerkesztő pedig szintén egy vizuális tervezőeszköz. Hiszen látható formában, a monitorunkon jeleníti meg a program amúgy elvont mögöttes szerkezetét, struktúráját, és vizuális módon teszi lehetővé annak kialakítását, módosítását ill. az abban történő navigációt.

    A különbség közöttük (ti. a hétköznapi értelemben vizuálisnak hívott eszközök és a szöveges eszközök) között csakis annyi, hogy míg a szöveges eszközök nyelvi paradigmák mentén - ezzel összefüggésben pedig erősen lineárisan - strukturálják, ill. teljes komplexitásukban fejtik ki és vizualizálják a program vagy az adatok szerkezetét, addig a vizuális eszközök elsődlegesen geometriai paradigmák mentén szervezik a mögöttes információhalmazt, amelynek azonban egyes részeit vagy teljesen elrejtik, vagy legalábbis különböző vizuális rétegekbe, síkokba szervezik, amik közül jellemzően egyszerre csak egyet-egyet tesznek elérhetővé, átláthatóvá, manipulálhatóvá. Lényegük tehát a célzott egyszerűsítésben rejlik, nem abban, hogy tényleg szenzorikus szinten más formában ill. úton közölnék az információt velünk, mint a szöveges forráskód teszi.
    Mutasd a teljes hozzászólást!
  • ezt: A vizuális tervező egy bizonyos komplexitás és variábilitás felett már nem segít, hanem gátol. Szűkíti és/vagy bonyolítja egy-egy specifikus helyzet előállításába ölendő energia mennyiségét. kifejtenéd egy konkrét, szemléletes példán keresztül, hogy miért gondolod így?
    Mutasd a teljes hozzászólást!
  • Ez erősen függ a funkcionalitástól. Van amit jól lehet vizuálisan tervezni, van amit nem.

    Pontosan ezért lehet a HTML-t és a XAML-ot is forrásban szerkeszteni. Mert nem lehet nem ám hogy az összes funkciójukat, de azok akár csak egy nem elhanyagolható töredékét is hatékonyan elérni ill. elérhetővé tenni kizárólag vizuális tervezőeszközökkel.

    Az UI tipikusan az a dolog, amit vizuálisan jobban lehet tervezni - mivel maga a végeredmény is vizuális lesz.

    Ami persze, mint ok-okozati összefüggés, teljesen hamis. Pl. egy Mandelbrot halmazt ábrázoló grafikát sem vizuális eszközzel (pl. egy rajzprogrammal) legegyszerűbb megtervezi és elkészíteni  (hanem egy pár tucat soros C program szöveges forráskódjának beírásával, fordításával és futtatásával, amik egyike se vizuális művelet) - függetlenül attól, hogy annak végeredménye is vizuális lesz. Vagy hogy elemibb, banálisabb példákat mondjuak: autót sem autóval építünk, és ruhát sem ruhával szövünk. Tehát teljesen hamis és értelmetlen az állításod, ami szerint X jellegű termék előállításához X jellegű eszköz a leghatékonyabb eszköz.

    Rémlik még, hogy a delphiben voltak kontrollok ? Tudod, azok a kis kockák amiket ha ráhúztál a formra, akkor mindenféle új vezérlőket tehettél fel, anélkül hogy a szerkesztőt fejleszteni kellett volna.

    Na, és a komponenseket hogyan lehetett létrehozni? Emlékszel még? Vizuálisan? Ugye, hogy nem? Hanem jó öreg kódolással. Tehát akkor valójában mire is szolgáltattál éppen példát? Bizony arra, hogy a Delphi-ben is igen korlátosak voltak a vizuális tervezés határai, és hogy az nagyjából semmire se lett volna jó, ha nem lett volna ott egy mögöttes, szöveges reprezentációs réteg a vizuális tervezés mögött, amire a vizuális tervezés csak rásegített bizonyos pontokon, de amit semmilyen érdemleges mértékben sem volt képes helyettesíteni, még hatékonysági megfontolásoktól függetlenül sem.

    Nem. Akkor nem kezdene el agyalni senki, hogy hogyan lehet rágányolni a böngészőre az adott funkcionalitást, hanem szépen kimondanák hogy ez a böngésző ezzel az oldallal nem kompatibilis.

    Mert miért? Attól, hogy teljesen vizuálisan tervezel meg, építesz fel és stilizálsz valamit, funkcionálisan változik bármi annak a működésében? Ugye hogy nem? Ha egy formot Delphi-ben vizuálisan tervezel meg, a jellemzőit vizuálisan állítod be, akkor másként fog működni, mint ha ugyanazt a formot sorról sorra Delphi forráskódból építenéd fel és állítanád be a jellemzőit ugyanúgy? Ugye hogy nem? Vagy ha egy JPEG grafikát Photoshop-ban rajzolsz meg vizuális módon, az bármivel többet fog tudni, másként fog viselkedni, stb. mint ha ugyanazt a grafikát procedurális úton generálnád le mondjuk egy C programból? Ugye hogy nem? Semmi teteje nincs annak amit mondasz.

    Értsd már meg, hogy az egész szöveges-bináris dolog csak kódolási, reprezentációs különbség, ami önmagában semmilyen funkcionális, sőt, információtartalmi különbséget sem jelent (leszámítva a redundanciát). Ennél fogva pedig semmilyen funkcionális probléma (mint pl. kompatibilitási gondok) kezelésére nem képes, illetve eleve, semmilyen hatással nincs a funkcionális működésre.

    Tehát ha a HTML nem szöveges lenne ill. nem létezne szöveges reprezentációja, az az ég világon semmiféle kompatibilitási problémát nem oldana meg. Pláne nem a HTML5 korában és szintjén, ahol még a szöveges reprezentációt feldolgozó parser is olyan szintig van szabványosítva, hogy gyakorlatilag funkcionálisan teljesen identikus az implementációja minden böngészőben. Ami pedig e mögött ill. ezen túl van (ti. hogy milyen elemeket, vezérlőket, animációkat, stb. támogat egy böngésző), az pedig teljesen független attól, hogy milyen formában van kódolva a böngésző bemenete.
    Mutasd a teljes hozzászólást!
  • "Ez pedig oda vezetne, hogy szépen kihullanak a piacról azok a böngészők akik nem követik a szabványt."

    Pontosan ilyesmikre gondolok én is. Néha a feleslegesen túl sok szabadság és rugalmasság egy inkompatibilitási rendszer felé halad, mert hát játékelméleti szempontból ez jön ki belőle. Én szívesen beáldozok a gányolásból valamennyit, hogy egy stabil rendszert kapjak cserébe, de nem biztos, hogy ezzel mindenki így van, mert lássuk be azért az is egy élmény, amikor a szöveges cuccokban bogarászva kitrükközöd, hogy valami nem támogatott dolog menjen

    Viszont azért én ha valami tényleg stabil dolgot akarok csinálni, akkor kerülöm a szöveges reprezentációt.
    Mutasd a teljes hozzászólást!
  • Ugyanezt a felületet GUI szerkesztőben kb. negyedannyi idő alatt megcsinálhatta volna a polgár, és közben nem kap ínhüvelygyulladást a sok körmöléstől.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd