Vývoj linuxového portálu alebo prečo to ešte nie je hotové (diskuse)

[Člověk z Horní Dolní]

Tlačítka, oddělovače, přechody atd. bych doporučil dělat v CSS. Aby byly ikonky v jednotném a nekýčovitém stylu, použil bych tohle. Takže jediná bitmapa, co je potřeba, je logo.

Bude se to nějak lišit od podobných komunitních webů, tj. nějaká inovace, zajímavá funkce?

[mirec]

Příloha:

• fa.png (69759 bytů)

Mne to otvorilo totálne rozbité.

[Člověk z Horní Dolní]

Jaký prohlížeč?

[mirec]

Konqueror (ten štandardne používam pri bežnom surfovaní).

[Člověk z Horní Dolní]

Příloha:

• Screenshot.png (104145 bytů)

Aha... no kdyz jsou nacteny fonty, vypada to tahkle:

[mirec]

Fonty mám všade kde sa to dalo zakázané. Freetype je pekne deravé. Nemyslím, že by bolo dobré spolierať sa na to, že u klienta je možné renderovať externé fonty.

[kralyk z abclinuxu]

Třeba github na to spoléhá Ale asi bude mít i nějakej fallback... Jinak se zakázanými fonty budeš pravděpodobně dost výjimka.

Docela dobrý nástroj na generování font-face je font squirrel.

[Michal Karas]

Třeba github na to spoléhá Ale asi bude mít i nějakej fallback...

Nemá. Na některých strojích proto mám rozhraní GitHubu rozbité. Zatím jsem nezkoumal, čím to je způsobené.

[mirec]

Bude se to nějak lišit od podobných komunitních webů, tj. nějaká inovace, zajímavá funkce?

Na Slovensku toho moc nemáme, len 2 portály z čoho len 1 má akú-takú komunitu (hoc rozhádanú). Ten jediný kde ako-tak funguke komunita má pomerne staré hrozné CMS ktoré som kedysi písal. Preto chcem vymeniť staré CMS za nové.

Nie som človek, ktorý by opúšťal potápajúcu loď alebo nejako závažnejšie menil svoje rozhodnutia, takže keď som sa kedysi dávno pustil do správy budem pokračovať až kým nebude zrušený, alebo kým nebudem mať fakt veľký dôvod na odchod.

[bibri]

Neber to zle, ale toto je zcela zbytečná práce - portálových řešení je docela dost, některé z nich za 15 minut fungují a za den stylování máš hotovo. Když se podívám na linuxos.sk, tak daleko rozumnější mi připadá vzít funkční software a zbylý čas věnovat raději obsahu. Staré CMS opravdu není největší potíž toho portálu...

[mirec]

Štýlovanie je práve problém, s ktorým sa tu trápim asi pol roka. Napísať nové CMS je práca na týždeň ak neviem pracovať s frameworkom, alebo približne 2 dni v prípade, že s frameworkom robiť viem. Napísanie vlastného riešenia však ušetrí pomerne veľké množstvo času pri presune obsahu keďže mi nekladie odpor prakticky nič (nemusím riešiť iné rozvrhnutie tabuliek lebo ho navrhujem ja, nemusím riešiť redirecty na nové ID objektov lebo je to kompletne v mojej réžii ...). Pokusy o hotové portálové riešenie tu už boli, ale udržať komuntu veľmi náročných užívateľov je pomerne ťažké. Vie si tu napr. niekto predstaviť prechod abclinuxu na phpBB?

[Ondra]

Vie si tu napr. niekto predstaviť prechod abclinuxu na phpBB?

s timhle souhlasim a uprimne receno by me zajimalo, jake portalove software pan Bibr mysli. Take bych rad neco, co nastavim za den a bude v tom pekna diskuze a jednoducha moznost tam dodavat clanky, sprava uzivatelu a jine veci.

Zkusil jsem uz lecos, ruzne wiki, drupal, joomla , ale vzdycky se nejde nejaky zadrhel. Budto to nevypada pekne nebo to vypada jak wordpress, we wiki jsou videt cele historie editaci (a kdyz to chci potlacit, tak bych tu wiiki musel rovnou prepsat), u drupalu jsou butony a grafiky velke jako Afrika (a 3 sloupcove skiny nekdy funguji a nekdy ne) a kdyz jsem te firmy ze Smichova (No.1 v Praze na drupal) ptal, za kolik by to napasovali, tak rekli ze by to celkove vyslo na 20 tisic.

Takze ti vlastne docela dobre rozumim, ze se s tim patlas.

[mirec]

Příloha:

• 38rk_sk.png (85379 bytů)

Ja som v práci webový vývojár, ktorý robí hlavne s Wordpressom a Drupalom. Teoreticky za najlepšiu považujem joomlu, ale tú nepoužívame (možno preto ju považujem za najlepšiu ). Často sú po mne požadované dosť šialené veci, na ktoré wordpress nebol nikdy stavaný a končí to opatchovaním samotného wordpressu (nerobím to rád a keď to už urobím musím mať na to poriadny dôvod).

Osobne radšej staviam sám na nejakom frameworku, čo zvyčajne trvá od začiatku projektu po hotový projekt 1 deň (za predpokladu, že dostanem kompletné šablóny html+css a ja riešim len aplikáciu, nie frontend). Ukážka admin rozhrania jedného takého projektu v prílohe. V podstate ide o úplne na mieru robené riešenie.

[Josef Kufner]

A jaké frameworky se ti nejvíce osvědčily?

[mirec]

Najviac django. PHP frameworky nemám moc naštuované (vlastne nemám v práci ani dovolené, takže asi sa to tak skoro nezmení).

[w4rr10r]

Reddit je open source.

[Člověk z Horní Dolní]

Jaký prohlížeč?

[manasekp]

Proc na to nepouzit neco hotoveho, treba wordpress nebo Drupal? Pripada me to jako dost zbytecna prace, ve vysledku pujde stejne predevsim o obsah, pokud bude kvalitni tak si to navstevniky najde, pokud ne tak ti nepomuze jakkkoliv zazracny CMS.

[mirec]

Čiastočne som odpovedal vyššie. Neviem, či dokážem zohnať dobrých autorov článkov. Ja sám toho moc nezvyknem písať a ťažko by sa to dalo považovať za kvalitné.

Hlavnou časťou bude predovšetkým fórum (momentálne je v databáze asi 20 000 tém fóra). Implementácia vlastného fóra je na pár hodín práce (porovnateľné s integráciou phpBB do CMS). Za phpBB by ma však asi súčasní užívatelia ukameňovali (vlastne by som to urobil aj ja sám :D).

[Člověk z Horní Dolní]

Příloha:

• linuxossk.jpg (36546 bytů)

Nápad na logo

[Krumpy]

Žiletky a EMO hudbu k tomu také dodáváš?

[Člověk z Horní Dolní]

Nechapu, jak s tim souvisi emo?

[mirec]

Celkom vtipné a trochu militantné, čo by aj sedelo s hodnosťami Ako default asi nie, ale v takom trochu tmavšom a depresívnejšom dizajne by vyzeralo super.

[kralyk z abclinuxu]

Prakticky všetky prvky sú bitmapové. Teoreticky by to šlo riešiť aj gradientmi, tieňmi, bordermi … v CSS. Keď som sa naposledy o niečo také pokúšal prestali štýly zvyčajne po pár týždňoch / mesiacoch fungovať. Kým o štandardoch rozhodujú ľudia, ktorí vyberajú vlastnosti podľa toho ako sa vyspia nemá zmysel zaoberať sa novými vlastnosťami CSS.

Tos asi musel testovat už dost před časem. Co se týče kulatých rohů a gradientů, doby vlastností jako -moz-* nebo webkit- už jsou naštěstí pryč a tyhle vlastnosti dnes s CSS3 fungují pěkně ve všech prohlížečích. (Vyjma té parodie jménem Internet Explorer, tam to AFAIK stále nefunguje.)

To řešení s tou jednou bitmapou je ale asi taky ok, protože má koukám jen 47kB a prohlížeč to beztak nejspíš nacachuje...

[kralyk z abclinuxu]

Btw.

Chrome je novodobý internet explorer. Vážne uvažujem napríklad o odstránení vizuálneho editoru kvôli neschopnosti chromu generovať rozumný kód. Zvyšné vychytávky ako nekorektné renderovanie tabuliek, ktoré hnijú v bugzille radšej ani nespomínam.

Toto je podezřelé. S Chromem by neměly být problémy. Doufám, že nepoužíváš tabulky na layout...

[=^..^= AmigaPower®]

Tabulky jsou zatím nepřekonaný, při dnešní rychlosti internetu není co řešit...

[robert st.]

Prosím tě, alespoň si odstraň z profilu odkaz na ty nejhnusnější stránky pod sluncem, když se tu bavíme o webdesignu, díky trolle.

[mirec]

Smutné je akurát, že ono to má tak trochu pravdu. Tabuľky riešili layout dobre ... akurát v súčasnosti keď má byť layout responzívny to už nie je tak celkom v poriadku. Dnešným problémom layoutov sú všadevytekajúce texty ak presiahnu určitú dĺžku, nemožnosť poriadne zarovnávať vertikálne ... CSS strašne chýba možnosť jednoducho definovať layout pre človeka prirodzeným sôsobom.

[Jakub Lucký]

Na tohle se mi osvědčil Twitter Bootstrap... Nic nepřetéká...

[=^..^= AmigaPower®]

Odpusť si svý poznámky, napočítej si do desíti, vezmi kuchyňskej nůž a uřízni si ptáka, aby se nemohli narodit další takoví trotlové jako jsi ty. Tabulky jsou daleko modulovatelnější než si myslíš a maj spolu s CSS slušnej potenciál, respektive jednim lze "retušovat" nedostatky druhýho a naopak...

[abc]

nezlob se na me, ale tohle je uplne typicky mysleni lidi od lopaty (nebo z autoservisu). Ale i ty, kdyz se nad tim poradne zamyslis, tak na to taky musis prijit, ze tim resenim musi byt odstraneni varlat, uriznuti penisu k zabraneni reprodukce nestaci. (reprodukce znamena to co jsi nahore napsal - 'nemohli narodit' - to abys to cizi slovo nemusel hledat)

[kralyk z abclinuxu]

Tabulky jsou zatím nepřekonaný, při dnešní rychlosti internetu není co řešit...

Imho ve většině věcí překonaný dávno jsou.

Například typicky fotogalerii neuděláš v tabulkách zdaleka tak dobře jako s css. Ale i další věci...

[frEon]

tabulky sou nahovno uz treba jenom proto, ze kdyz si zvetsim stranku, tak mi text vyjede mimo okno prohlizece, pokud se nevejde - ono zprehazet tabulku by totiz tak docela znicilo jeji vyznam.

[mirec]

No analógií medzi chromom a internet explorerom je niekoľko.

Momentálne je to najpoužívanejší prehliadač a mnohí sa spoliehajú na to, že užívateľ používa len chrome a na zvyšok sa vykašlú. Chrome podporuje dosť vecí nad rámec štandardov a keď sa niekto na ne spolieha je logické, že to fungovať nebude.

Ďalším problémom sú dlho neriešené bugy. Napríklad som mal problém s tabuľkou kde som potreboval podľa triedy voliteľne skryť stĺpec ale bez toho, aby som mu nastavil display: none pretože jeho obsah prekrýval celý riadok tabuľky (position: absolute; width: 100%; height: 100%). Je to dosť špecifický prípad, ale v tomto prípade jediné rozumné riešenie. Žiaľ chrome sa rozhodol, že mi nedovolí užší stĺpec než 2 pixely.

To by boli však len drobné problémy oproti vizuálnemu editoru. Ja konkrétne používam WYMeditor. Prakticky všetky vizuálne editory závisia od implementácie v prehliadači. Ak v tomto editore v chrome kliknem na číslovaný zoznam, ukončím ho dvojitým enterom za zoznam mi chrome začne vkladať prvok div namiesto p. Občas dokonca vkladá zbytočné span-y bez toho aby som od niekiaľ kopíroval kód a absolútne netuším prečo. Vo firefoxke to napr. funguje korektne.

[mirec]

Ešte ma napadla taká katastrofálna vec, ktorá ma čaká v pondelok v práci. Tou sú formulárové prvky. Ako nechápem ktorý expert vymyslel to, že input[type="text"], textarea a button sú štýlovateľné, ale checkbox, radiobutton, select, prakticky všetky formulárové prvky HTML5 štýlovateľné nie sú. To by fakt niekoho zabilo pridať niečo takéto?

input[type="radio"]:shape {
  width: 1em;
  height: 1em;
  border-radius: 0.5em;
  ...
}

input[type="radio"]:marker {
  ...
}

Namiesto toho sa tu budem trápiť s blbými checkboxmi, ktoré skript skryje a nahradí ich divmi a poriadne ani nezaregistruje handlery na zmenu checkboxov, takže ich ani poriadne nemôžem meniť programovo. Samozrejme záleží na tom aký skript mi tam hodí HTML koder, ale väčšinou sa s programovým nastavením hodnoty checkboxov neznáša. Ak úplnou náhodou zvláda tak nezvláda to, že checkbox môže byť uzavretý v labeli. Kliknutie na label v takom prípade funguje, ale kliknutie na checkbox najskôr zachytí label, ktorý zmení jeho stav a potom samotný prvok chceckboxu, ktorý ho zase zmení, takže zostane v rovnakom stave ako predtým. Ak náhodou nájdem skript, v ktorom všetko toto funguje tak nefunguje v chrome kým ho nedonútim celý input skryť a zobraziť, alebo iným spôsobom ho ručne prekresliť. Fakt som nenašiel ešte dobrý skript na naštýlovanie checkboxu.

Ah zlatý konqueror, kde sa dajú checkboxy aj radiobuttony ako-tak naštýlovať.

[kralyk z abclinuxu]

No tak se budou checkboxy a radiobuttony zobrazovat nativně, je to opravdu takovej problém? A skriptovat by je taky neměl být problém. Když už bys je ale chtěl něčim nahrazovat, tak bych sáhl po hotovým řešení, třeba jquery UI nebo tohle nebo něco na ten způsob...

[mirec]

Jej to sú presne tie posraté checkboxy a radiobuttony, ktoré nefungujú. A prečo nie natívne ... no pýtal by som sa skôr grafika, ale keď vidím na tmavom vebe hodené bielo-modré checkboxy, ktoré vyzerajú ako z inej galaxie tak sa tomu vlastne ani nečudujem.

[kralyk z abclinuxu]

Přijde mi, že v tom Konqueroru ti toho vůbec nefunguje nějak moc. Skoro bych na vývoj webu sáhl po běžnějším prohlížeči...

[xkucf03]

třeba jquery UI nebo tohle nebo něco na ten způsob...

Až tam půjde používat klávesnici (Tab, Shift+Tab, mezerník), tak jsem pro.

[xkucf03]

Žiadne rozumné jednotky veľkosti pre zobrazovanie na elektronických zariadeniach neexistujú.

Pokud použiješ bitmapy, je prakticky jedinou rozumnou jednotkou px i pro vše ostatní – tedy pokud chceš, aby rámečky měli správnou velikost s ohledem na bitmapu a texty nevytékaly z rámečků.

[mirec]

V prípade, že by CSS podporovalo niečo ako BorderImage v QML vyriešilo by to celý problém s bitmapami. Žiaľ mám taký pocit, že tvorcovia štandardov žijú niekde úplne mimo realitu.

[chrono]

CSS3 border-image podporuje určite dlhšie ako QML.

[mirec]

Akosi mi examply v prehliadači nefungujú.

[xkucf03]

Možná je to trochu chybné chápání webu. HTML je hyper-text markup language. V první řadě jde o ten text, ve druhé o provázanost pomocí odkazů a ve třetí o strukturu dokumentu (nadpisy, seznamy atd.). Nějaká grafika je celkem podružná. Proč by vlastně na webu měla být tak precizní a na bod přesná grafika, jako považujeme u tištěných výstupů (knihy, vizitky, plakáty atd.)?

Ne že by web měl být hnusný, ale je co se týče grafiky mnohem volnější a pružnější – např. když budu sázet vizitku, časopis, plakát, pracuji s pevně daným rozměrem papíru, chci mít vše přesně zarovnané, každý rozměr dává nějaký smysl, vyberu konkrétní řezy písma, pohraji si s kerningem…

Web má svoji typografickou krásu někde jinde. K čemu mi jsou přesně napozicované bitmapy a divy s přesnou šířkou v pixelech, když je autor/editor prase (nebo má neschopný nástroj) a nepoužívá nedělitelné* mezery, nerozlišuje pomlčku a spojovník, neví, jak se píší uvozovky… o pravopise, stylu a obsahu raději ani nemluvě?

Mezery současného webu vidím hlavně v absenci sémantiky (byť standardy tu jsou: XHTML + RDF, Dublin Core), honit nějaké pixely a bitmapy považuji za nepodstatné.

*) smutné je, že je nepoužívají často ani tištěné deníky

[mirec]

V první řadě jde o ten text, ve druhé o provázanost pomocí odkazů a ve třetí o strukturu dokumentu (nadpisy, seznamy atd.).

To je chybné chápanie reality. HTML je v súčasnosti jazykom pre vyjadrenie obsahu a vzhľadu zároveň. Nie je možné flexibilne zmeniť vzhľad webu len zmenou CSS. Preto mám napríklad obsah obalený v 4 divoch lebo inak by som ho do 2 stĺpcov nezarovnal. To je žiaľ smutná realita webu. Občas by som mal chuť ľudí čo navhovali štandardy zavraždiť za to ako ich navrhovali

Inak o typografickú správnosť by sa mal starať hlavne sám prehliadač. Myslím, že to dokonca aj do istej miery podporuje (videl som niekde podporu rozdeľovania slov a teraz nemyslím ­).

[chrono]

Skôr je problém v prehliadačoch, pretože stĺpce v CSS sú.

[xkucf03]

Můj předchozí komentář nebyl o tom „jak“ ale o „jestli“ případně „proč“? Na některé věci (např. na bod přesná grafika/design) bych na webu rezignoval a věnoval se raději jiným (sémantika, negrafická* část typografie… a samozřejmě obsah).

Ale když už chceš řešit to „jak“ – tady bych považoval za ideální, když základní dokument ponese sémantickou hodnotu (zvláštní XML, DocBook, RDF…) a na klientovi se nastyluje pomocí XSL a CSS případně i JS. To umožňuje mít čistý a sématický dokument obsahující pouze data a od něj zcela oddělenou formu v šablonách.

HTML(5) tady krutě selhává, XHTML(1) se to snažilo řešit, aby pořád to bylo polovičaté řešení – příliš se ohlíželo na zpětnou kompatibilitu. Chce to čistě sémantický formát pro data – z něj se pak dá generovat ta prezentační forma třeba v (X)HTML(5) (a z něj se naopak ty sémantické pokusy můžou vyhodit a zjednodušit ho).

*) nevím, jak to nazvat, myslím tím ty nedělitelné mezery, pomlčky, spojovníky, uvozovky trojtečky atd., co se objeví v textu, ale není potřeba je nijak stylovat nebo pozicovat.

[mirec]

Starý web bol práve riešený cez XSLT, ale na strane servera. Síce trochu pomalé, ale išlo to. Mám tento jazyk a celkovo XML rád. Kvôli výkonu som však musel od XSLT odísť.

Na strane klienta by bola nádhera ak by boli informácie oddelené od formy. Žiaľ podpora nie je ktovie aká ani u grafických browserov a čítačky pre zrakovo postihnutých / textové prehliadače nemajú podporu XSLT.

[Josef Kufner]

Jenže XSLT, zejména server-side, se se sémantickým webem prakticky vylučuje. Psát sémanticky hezký dokument, nechat ho někde schovaný a pak z toho dělat druhý, který vypadá hezky, je hromada zbytečné práce. Oproti tomu je CSS mnohem lepší cesta, jen je škoda, že ho W3C tak zmršilo, a že podpora je pořád dost mizerná.

[mirec]

Má to zmysel v prípade, že sa má renderovať niekoľko verzií webu (mobilný, desktopový ...). Keby bolo CSS pekne implementované tak, že samo o sebe stačí na naštýlovanie webu nebol by to problém, ale občas je potrebné zmeniť aj samotný HTML kód a kvôli tomu som tam mal XSLT. So sémantickými XML by sa dal celý web krásne oajaxovať, ale mám voči tomu trochu averziu Takže reálny prínos pre ľudí nulový, ale ja som sa naučil XSLT a teraz ho takmer denne používam pri rôznych prevodoch formátov pri importe / exporte dát.

[Josef Kufner]

Vzhledem k tomu, že HTML dokument snad nikdy nepředstavuje zdrojová data, tak je XSLT zbytečný mezikrok a mnohem praktičtější je mít více základních šablon, do kterých se dosadí data (ať už HTML fragment nebo cokoliv jiného).

Na teoretické úrovni má XSLT pár pěkných vlastností. Přecijen, je to XML dokument, který generuje XML dokumenty, což přináší celkem zajímavé možnosti, ale prakticky je celkem na prd.

[kralyk z abclinuxu]

Na teoretické úrovni má XSLT pár pěkných vlastností. Přecijen, je to XML dokument

Lépe řečeno, formát založený na XML. Protože podobně jako např. SVG trpí XSLT tím nešvarem, že krom syntaxe XML zavádí další pravidla syntaxe v některých atributech. (U toho SVG je tahle situace ještě o dost horší.)

[xkucf03]

Ano, u svg je to docela hrůza, je to takové polovičaté a nevyužívá plně potenciál XML. Ale u XSLT je to jen XPath a pár výjimek, jinak je vše v elementech/atributech.

[xkucf03]

Přecijen, je to XML dokument, který generuje XML dokumenty, což přináší celkem zajímavé možnosti, ale prakticky je celkem na prd.

• může generovat i jiný výstup než XML (třeba prostý text)
• ze šablon můžeš generovat šablony
• XSLT mi ušetřilo spoustu práce a umožnilo hodně věcí dělat jednoduše a rychle… takže bych neřekl, že je na prd

[xkucf03]

Oproti tomu je CSS mnohem lepší cesta, jen je škoda, že ho W3C tak zmršilo

Nevím, jestli až tak zmršilo – spíš mi to přijde z podstaty toho (jednoduchého) jazyka CSS – hodně věcí tam prostě nejde a jít nemůže. Ale nepovažoval bych to za nějakou vadu – přijde mi dobré to zkombinovat s tím XSLT na straně klienta a pak to může být super.

[Josef Kufner]

Ono by to chtělo CSS už dávno rozšířit o proměnné a jednoduché aritmetické výrazy (to přichází až teď s CSS3). A pak to chtělo před cca patnácti lety nerozbít box model. Další kritickým nedostatkem je absence slušného layoutu, to už měli nějak vymyslet dávno, když se evangelizovalo proti tabulkám, kdy v podstatě fungující řešení nahradila snůška hacků…

[xkucf03]

Ono by to chtělo CSS už dávno rozšířit o proměnné a jednoduché aritmetické výrazy…

Někteří ho už rozšířili – viz LESS a některé další jazyky – teď už to chce jen nativní podporu v prohlížečích (zatím se to emuluje přes JavaScript na klientovi nebo přegenerováním na serveru). Ostatně proto má v XHTML element <style/> atribut type="…", který je tu připraven pro další jazyky, jako je ten LESS. Napojit hotovou knihovnu do prohlížeče by neměl být takový problém…

[xkucf03]

Starý web bol práve riešený cez XSLT, ale na strane servera.

Na serveru to není úplně ono, jak píše J.K. níže. Sémantika se nedostane na klienta. Navíc v aplikačním serveru nebo v aplikaci už nějaký šablonový systém máš, tak je většinou zbytečné tam přidávat druhý XSLT – smysl bych viděl ve škálování a rozkladu zátěže: aplikační server jen jeden (nebo menší počet) a k němu větší počet serverů, kde se provádí XSLT transformace – to se dá krásně škálovat.

Kvôli výkonu som však musel od XSLT odísť.

To je spíš věc konkrétní implementace procesoru než jazyka. Ale na klientovi to už vůbec nevadí – tam se v jednu chvíli bude transformovat jen jedna stránka a to není problém zvládnout ani při neefektivní implementaci.

Na strane klienta by bola nádhera ak by boli informácie oddelené od formy.

+1

čítačky pre zrakovo postihnutých / textové prehliadače nemajú podporu XSLT

Jednak je triviální ji tam dopsat a jednak (a to hlavně) oni ji nepotřebují – právě nezajímá ta prezentace, oni potřebují ty nejčistší data + sémantiku.

[Člověk z Horní Dolní]

S tou grafikou zasadne nesouhlasim. Mit na bod presnou grafiku na webu samozrejme ma smysl, variabilni velikost stranky je vicemene irelevantni. Kazde medium si zaslouzi kvalitni grafiku.

K te semantice - podle me by bylo idealni, kdyby byl pro kazdou stranku oddeleny soubor napr. pro vyhledavace, kde by byla ciste semantika, cili trochu jako ciste HTML.

[xkucf03]

Mit na bod presnou grafiku na webu samozrejme ma smysl

Viz co jsem psal výše – jde to, ale pak musíš v px určovat rozměry všeho včetně písma.

Kazde medium si zaslouzi kvalitni grafiku.

Ano, ale ta kvalita je na různých místech definovaná různě. Když se někdo pokouší na web přenést klasickou grafiku, tak to většinou dopadá tak, že použije „fixní layout“ a často i vektorová písma musí zavrhnout a použít místo nich bitmapy, aby dosáhl požadovaného výsledku.

Já si kvalitu na webu představuji trochu jinak a mám tu jiné nároky než třeba u knížek nebo u tištěné grafiky – chci obsah, sémantiku, nedělitelné mezery, pomlčky, uvozovky a další zvláštní znaky… a pak to nastylovat nějakým rozumným způsobem (co daná technologie umožňuje), aby se to dobře četlo – nemusí to být ale na bod přesné a už vůbec to nemusí vypadat na všech zařízeních a ve všech prohlížečích stejně.

K te semantice - podle me by bylo idealni, kdyby byl pro kazdou stranku oddeleny soubor napr. pro vyhledavace, kde by byla ciste semantika, cili trochu jako ciste HTML.

Oddělený soubor je nesmysl – vždyť samotný protokol HTTP nám umožňuje servírovat různé výstupy podle toho, co klient požaduje – indexovací robot pošle HTTP hlavičku:

Accept: text/nějakýSémantickýFormát

[Člověk z Horní Dolní]

Na bod presna grafika = je jasne definovany, jak bude vypadat stranka v prohlizeci, takhle to chapu ja. To ale neznamena, ze musim na vsechno pouzivat px, vetsinou staci relativni pozice nebo rozmer, treba ze tenhle div bude pod timhle divem. Vyznam se spis v Androidu a tam se misto pixelu pouziva dp, coz je zjednodusene realna velikost pixelu na 160 dpi displeji. Na webu se da pouzit mm, em, mam pocit ze se chysta i obdoba dp.

Nejvetsi technologicke prekazky kvalitni grafiky na webu je male dpi monitoru a rozdilna implementace standardu v prohlizecich, ne variabilni layout.

To co jsi vyjmenoval (nedelitelne mezery atd.) neni problem, ne technologicky... Co se tyce typografie, prohlizece nejsou o moc pozadu za Latexem.

S poslednim odstavcem souhlas.

[xkucf03]

Na webu se da pouzit mm, em, mam pocit ze se chysta i obdoba dp.

Souhlasím, že tohle jsou daleko lepší jednotky, protože fyzická velikost px se může i několikanásobně lišit. Akorát je pak potřeba používat vektorovou grafiku, protože bitmapy jsou v tomhle na nic (prohlížeč je sice může škálovat, ale to je nedokonalé a často potřebuješ úplně jinou bitmapu – viz třeba ikony 16x16 a 64x64, ty nebývají jen přeškálované, ale nakreslené úplně znova s ohledem na menší rozlišení)

[Josef Kufner]

No, ono zrovna s ikonama tenhle problém vektorová grafika moc neřeší. Na malém obrázku toho není moc vidět, tak je potřeba ubrat detaily. Takže stejnak je většinou potřeba víc variant.

[dumblob]

+1

[pavlix]

Ale pořád je lepší mít dvě varianty vektoru než deset variant bitmapy.

[kralyk z abclinuxu]

+1, Třeba u takového SVG hrozně chybí (AFAIK) nějaké nástroje na práci se zvětšováním, třeba označit část, která se škáluje pomalejc nebo se neškáluje vůbec (typicky třeba nějaké okraje apod.)

[loki]

V jakem narodnim kontextu Tvuj portal pobezi? Bude Cesky || Slovensky || CeskoSlovensky || Mezinarodni? Rad bych se na tomto projektu podilel - samozrejme i financne a to doufam, ze velmi stedre. Byl bys pro? Moc se mi to libi, prosim odepis zde do fora.

Abych to upresnil a Tebe uklidnil. U tohoto projektu neverim v navratnost sve investice, coz by mi ale vubec nevadilo. Komunita je komunita. Pro FOSS komunitu delam dost nezistneho, ale pod absolutne jinou identitou, ve ktere vyuzivam svych skromnych vyvojarskych schopnosti, ktere mi dalo vzdelani ze soukrome vysoke skoly, na kterou jsem si vydelaval jako vymahac dluhu. Ale to bylo hodne za mlada Je to slozita kapitola meho zivota, ale kdyz vazite 104 kg, merite 206 cm, tak je to jasna volba. Troufam si tvrdit, ze nekteri zaslouzili panove zde mne znaji pod pravou identitou a snad si mne i vazi. Tyto veci zde rikam jen proto, abych demonstroval sve zasluhy a svou prislusnost ke zdejsi komunite, ktere si i pres ruzne levicaske projevy velmi vazim a cenim. A to prosim znamena, ze si cenim i te livecove komunity! Zde jsou proste velmi chytri lide. Opravdu. Jinak svou pravou identitu priznat nehodlam a nemuzu, jelikoz lide dnes bohuzel zavidi schopnosti, nadhled, humor, bohatsvi, myslenky... ale podle mych zkusenosti i ctyrkolku a "mladsi" zenu, a dokonce i to, ze vas otec a matka pochazi z Nemecka... Ano, ma Cestina neni nic moc, jsem vlastne +- samouk.. Ma zakladni skola proste byla jinde - vlastne i kousek stredni ... coz mne mczi. Soucasna partnerka je take bohuzel z Nemecka, coz nekteri lide a "sousedi" neslysi moc radi... Btw nevim proc, ale prijde, ze puvod a "rasa" hraje v jistych "velmi vysokych kruzich" dnes velkou roli, coz je vec, kterou osobne prilis nechapu...

Jinak abych trochu nastinil to, cim se momentalne zivim, a hlavne to, z ceho budou eventualne pochazet penize, ktere jsem ochoten Vam venovat. IT oborem se nezivim jiz cca 14 let, ale mam cca 1 nabidku tydne od ruznych headhunteru, kteri mi slibuji horydoly. To samozrejme ignoruji. Prijmy mam z cca 60 % z pronajimani ruznych objektu. Zbytek je z dalsich podnikatelskych aktivit.

[mirec]

Komunita v česku je na rozdiel od Slovenskej veľmi silná. Ja by som sa chcel zamerať hlavne na Slovenskú komunitu.

Čo sa týka financovania tak ja to našťastie neriešim. Kedysi som bol platený za vytvorenie starého CMS na linuxos.sk, dnes pre tento portál robím nové CMS zadarmo. Prevádzka portálu stojí približne 30 € ročne (doména) a hosting je vďaka Tomášovi Srnkovi zdarma. Zvyšné náklady sú hlavne náklady na honoráre (10 € - 21 € za článok), ale moc článkov sa nepíše a aj keby neviem kto všetko honorár odmieta, takže táto suma asi tiež nebude moc vysoká. Kedysi sme boli prakticky bez príjmu, ale pred pár dňami som na linuxos.sk vľavo dole v sekcii podporte nás pridal paypal. Ako sa však prostriedky použijú neriešim ja (som fakt rád, že finančné záležitosti sú úplne mimo mňa a môžem sa venovať prakticky výlučne technickej stránke riešenia).

[Bystroushaak]

Zajímavé. Jak šla ta práce vymahače?

[Aleš Kapica]

Vymáhat peníze pro někoho, je vždycky snazší, než vymáhat peníze vlastní.

[messi]

no, jestli je to jednodussi s tim vymahanim ?? - trochu OT (a tim se take sklanim pred humorem Brnaku):

kamarad z Brna, student VUT byl nacapan revizorem a nechtel zaplatit ani rict jmeno, takze se vystoupilo na pristi zastavce, kam mel prijet prislusnik, aby zjistil totoznost. Revizor si zapalil cogaretu a kamarad rika:

- ja bych si cigaretu nezapaloval

- proc?

- bude se utikat ...

[občan]

..., ktere mi dalo vzdelani ze soukrome vysoke skoly, na kterou jsem si vydelaval jako vymahac dluhu.

es ist nur gut, dass solche aufgeblasenen Idioten wie Du, auch manchmal platzen koennen ...

[dumblob]

Ich sehe keinen Ausbruch in seinem Text.

[eMDi]

Loki: momentalne financie a snahu o rozbeh portalu riesim ja, ako aj casom honorar pre Mirca. takze pripadne ma kontaktuj na emdi zavinac emdi dot sk

[retroslava]

Když se ti něco nelíbí a neznáš to očividně, tak to prosím alespoň nepomlouvej. Myslim tím tvojí zmínku o RoR.

[mirec]

Nepovedal som, že to neznášam, sám používam na niekoľkých projektoch. Vo všeobecnosti mám však radšej kontrolu nad každou drobnosťou v projekte. Mám rád keď mi nič nebráni v opatchovaní čohokoľvek od loaderea šablón cez generátory dotazov až po externé moduly.

[shadowhand]

Co tomu brání v RoR?

[retroslava]

autorova neznalost

[mirec]

Pretože ma to zaujíma tak sa pýtam. Ako v RoR integrujem podmienený loader šablón podľa 1. nastavení užívateľa, 2. cookies, 3. fallback na default cesty s oddelenými šablónami pre rôznych užívateľov a zariadenia (kvôli niečomu takému), preprocessorom pre kompresiu výstupu a nejakými tými ďalšími nechutnosťami? Uznávam, že som z RoR blbý, preto sa pýtam ako sa takéto veci riešia.

[retroslava]

Jasně že můžeš mít podmíněný loader šablon.

Nebudu to tu moc rozvádět. Ale můžeš mě chytit na irc freenode (nick retro|cz) nebo mi napiš tady přes zprávy a rád ti to rozepíšu a pošlu i s ukázkou. Napadá mě hned několik způsobů.

Šablony se hledají v cestách a ty si můžeš přidat cestu i svojí a to i dynamicky. Takže si pak stačí držet stav, který styl chceš použít, a pokud takový styl není, tak fallbackem to spadne do nějáké univerzální cesty, kde budou šablony všechny.

Ideální je tady mít šablonu jen jednu a měnit styly. Pak by mohlo stačit nějáké body class="tenhle styl" a interpolace tam, kde je něco jako 'stylesheet_link_tag("application")'. A pak si jednotlivé styly přidat do manifestu, ať projdou přes sprockets a minifikujou a spojí se. Nebo můžeš jedním řádkem celé sprockets vypnout a starat se o to sám jako ve starších verzích.

Nechci tady tím moc nudit nikoho. Pro víc info se ozvi a rád s tebou srovnám třeba jak to děláš ty a ještě se oba dozvíme něco novýho.

[User682]

zdravim,

kdybych nekdy mel znovu zacit delat linuxovy portal, tak bych se prvni ptal, kde mam 100 tisic do zacatku nebo kde mam ten obsah, co na tom portalu bude.

Vetsinou pokud projekt zacina tim, na jakem engine to pobezi, tak to je jeho konec. Jenomze na to clovek prijde az po par letech zkusenosti.

Anebo pokud prezentujete na webu, jak co bude a nebude, tak si akorat vyseknete na par let ostudu, coz se mi tu pred casem v tomto smeru hodne povedlo. Na trh se musi chodit s jiz necim hotovym.

gf

[xxxxxxxxxxx]

+1 Ještě bych doplnil že si myslím že by šli dělat užitečnější věci...

[xxxs]

mohol by ti napriklad cez vikend naprogramovat parametricky cad.

[xxxxxxxxxxx]

a nebo naprogramit nějaký stránky který budou míst smysl.

[mirec]

Stránky nerád programujem Toto robím preto, že môj starý kód je proste zlý a ja zásadne neopúšťam len tak projekt, kotrý som kedysi začal. Rovnako neopúšťam distribúciu, s ktorou som začínal (Gentoo od roku 2004 nepretržite), neopúšťam firmu bez toho aby sa našla vhodná náhrada za mňa ... Snažím sa k tomu, čo robím pristupovať zodpovedne.

[Marv-CZ]

S velikostí v px je to chyba implementace v prohlížečích. Ono totiž podle specifikace 1px != 1 fyzický bod obrazovky. U běžného rozlišení displeje tomu tak být může, u vysokého rozlišení by to tak být nemělo.

[dumblob]

Definuj bezne a vysoke rozliseni.

[Marv-CZ]

To není důležité. Důležitá je definice velikosti toho pixelu. A ta je celkem volná. Ale stačí místo hraní se slovíčky trochu přemýšlet, a fungovalo by to. Na W3 je tento popis:

The px unit is the magic unit of CSS. It is not related to the current font and also not related to the absolute units. The px unit is defined to be small but visible, and such that a horizontal 1px wide line can be displayed with sharp edges (no anti-aliasing). What is sharp, small and visible depends on the device and the way it is used: do you hold it close to your eyes, like a mobile phone, at arms length, like a computer monitor, or somewhere in between, like a book? The px is thus not defined as a constant length, but as something that depends on the type of device and its typical use.

To get an idea of the appearance of a px, imagine a CRT computer monitor from the 1990s: the smallest dot it can display measures about 1/100th of an inch (0.25mm) or a little more. The px unit got its name from those screen pixels.

Nowadays there are devices that could in principle display smaller sharp dots (although you might need a magnifier to see them). But documents from the last century that used px in CSS still look the same, no matter what the device. Printers, especially, can display sharp lines with much smaller details than 1px, but even on printers, a 1px line looks very much the same as it would look on a computer monitor. Devices change, but the px always has the same visual appearance.

[dumblob]

No, ta jejich definice vypada docela dobre. Ale meli by tam zduraznit, ze je to extremne zavisle nejen na vsude proklamovanych rozmerech obrazovky (v horsim pripade rozliseni te obrazovky), nybrz na vzdalenosti oka od obrazovky!

Idealni obrazovku (at uz jakehokoliv tvaru) si predstavuji tak, ze si na ni natukam v OSD vzdalenost, ze ktere na ni koukam a ona tuhle informaci posle do pocitace, ktery zohledni vsechny 3 parametry - rozliseni + rozmer obrazovky + vzdalenost oka. Potom lze definovat cokoliv. Nikde jsme vsak tohle nevidel a nechapu, proc to jeste nikdo neuvedl na trh (jak SW, tak takova zobrazovaci zarizeni). Krome toho si muze s dnesnimi moznostmi klidne merit tu vzdalenost oci zarizeni samo (web kamera je prilisny zasah do soukromi, ale lze vyuzit mnoho dalsich, k ktomuto ucelu vhodnych technologii). Tento problem jsme resili s Petrem Kobalickem ve Fog frameworku, ale nejak nam trochu zamrznul vyvoj .

Osobne jsem zastance toho, ze by se v navrzich GUI/layoutu melo uplne zapomenout na existenci rozliseni a brat v uvahu pouze ty 2 zbyvajici faktory - tedy skutecny rozmer obrazovky v mm a pak ta vzdalenost oka od teto obrazovky. Tedy rozliseni by bylo interne pouzivano pouze ke vzorkovani vystupniho obrazu (samozrejme je rozliseni potreba pro vetsinu vypoctu v grafice, ale to je pro hrubou predstavu irelevantni a resila by to prave implicitne samotna GUI knihovna). Ano, tedka me ukamenujete, ze to nebude tim padem "sharp", ale ja vam budu kontrovat, ze rozliseni roste a krome toho, ze tento problem se da vyresit prave implicitne v pouzite graficke knihovne (obdelnik 10x10cm carou 1mm bude na 1000x1000 displeji velikem 15x15cm vypadat fakt nerozmazane oproti stejne velikemu displeji s rozlisenim 50x50 - ale jak pisu vyse, tohle je v pohode resitelne implicitne).

Pak vyvojarum UI staci jiz vse definovat pouze tim koeficientem zahrnujicim skutecny rozmer a tu vzdalenost (vyrobce urci ten skutecny rozmer - ten je natvrdo dany HW; uzivatel si urci pouze tu vzdalenost, kterou by bylo mozne v case menit; rozliseni je jak pro vyvojare, tak pro uzivatele irelevantni a melo by imho slouzit opravdu vyhradne pro "miru presnosti" diskretizace okolniho spojiteho sveta). Samozrejme by bylo mozne graficke knihovne "rict", aby se vykaslala na tu vzdalenost oci a tim padem byla mm-perfect, tedy jinymi slovy typograficky presna, aby si clovek mohl dat A4 pres monitor a na bod presne by to sedelo.

Ty webovky jsou asi fakt nejzajimavejsi - chceme na ne koukat na desktopu, coz je jine nez notebook, coz je o hodne jine nez smartphone/tablet/netbook, coz je diametralne odlisne od televize (na tu koukame vetsinou z opravdu velke dalky v porovnani s ostatnimi), coz je extremne odlisne od projektoru v prednaskove mistnosti pro 300 lidi atd.

[pavlix]

No, ta jejich definice vypada docela dobre. Ale meli by tam zduraznit, ze je to extremne zavisle nejen na vsude proklamovanych rozmerech obrazovky (v horsim pripade rozliseni te obrazovky), nybrz na vzdalenosti oka od obrazovky!

Vždyť to v té citaci je.

[dumblob]

Proto jsem psal zduraznit a ne ze to tam chybi.

Zduraznenim mam na mysli treba obdobny popis jako jsem popsal v predeslem prispevku (tzn. BFU-friendly).

[pavlix]

Mně to přišlo zdůrazněné, tak proto reaguju takto.

[Bystroushaak]

Krome toho si muze s dnesnimi moznostmi klidne merit tu vzdalenost oci zarizeni samo (web kamera je prilisny zasah do soukromi, ale lze vyuzit mnoho dalsich, k ktomuto ucelu vhodnych technologii).

Jak se to bude chovat v případě, že monitor sleduje víc lidí?

[dumblob]

Token ring.

[dumblob]

Ale tobe bych doporucil verzi s tim rucnim nastavovanim bez automatiky .

Btw je to naprosto irelevantni - hlavne, aby sla ta vzdalenost operativne nastavovat/menit v case.

[Bystroushaak]

Proč je to irelevantní?

[dumblob]

Protoze to uz je zalezitost konkretni implementace (tedy navrhare uzivatelskeho rozhrani) a ne technika, ktery resi podstatu (tzn. samotnou moznost manipulace se vzdalenosti obrazovka-monitor v case a vyuziti v kodu UI).

Kdyz melu maso ve strojku, take je strojku jedno, jak a co tam cpu (rukou, lzickou, s/bez kosti, hovezi, veprove...), hlavne, ze je porad "plno" a mam co mlit. Nas techniky zajima, zdali to strojek umi (a jak moc dobre) a ne jak se ta "informace" (maso ) do strojku dostane.

[Bystroushaak]

Protoze to uz je zalezitost konkretni implementace (tedy navrhare uzivatelskeho rozhrani) a ne technika, ktery resi podstatu (tzn. samotnou moznost manipulace se vzdalenosti obrazovka-monitor v case a vyuziti v kodu UI).

Takže tohle je diskuze techniků, kteří řeší pouze podstatu?

[dumblob]

Myslim, ze to neni diskuze o tom "jak ma vypadat a spravne reagovat UI", nybrz "jak vytvorit spravne UI".

Pokud se vsak mylim, tak se omlouvam a mohu akorat dat k dispozici muj textak (vytvoreny asi pred pul rokem) se seznamem bezne dostupnych uzivatelskych vstupnich metod, kterymi lze do pocitace pechovat data (je jich docela dost) a k tomu navrhnout nekolik z nekonecna moznosti jak resit mikro problemy typu "ktery z peti lidi bude mit pred obrazovkou zrovna peska".

[Člověk z Horní Dolní]

Tohle umi Android, az na to ze to nebere v uvahu realtime vzdalenost oci od displeje. Pro rozmery se poziva jednotka dp (=velikost 1 pixelu na 160 dpi displeji) a pak se to prevede na pixely, podle toho, jake dpi je nastaveno v systemu. Coz je casto jina hodnota nez fyzicke dpi displeje. Takze napriklad Android televize muze mit nastavene dpi tak, aby aplikace nevypadala z 10 metru prtave.

[dumblob]

Nejsem znalec Androidu, ale jeste jsem fakt nevidel, ze bych mohl skalovat cele Androidacke GUI jako bych skaloval bitmapu akorat "ostre" (tedka myslim rucne - zadnou automatiku).

Nevim, zdali je na vine implementace v Androidu, ci neznalost programatoru GUI (nedivil bych se - 160 DPI mi nic nerika - musim si to prepocitat na mm) ci neco jineho, ale bohuzel to z meho hlediska (ktere se v tomto pripade shoduje s hlediskem BFU) "nefunguje".

[Člověk z Horní Dolní]

Jde to dost kostrbate, je treba root, editace nejakeho souboru a restart telefonu.

Pokud bys chtel, aby slo skalovat UI zive, musela by se provest velmi jednoducha uprava Android OS a k tomu by byla potreba podpora ze strany aplikaci (coz by myslim nemuselo byt tezky).

Kdyz se zmeni jazyk, orientace telefonu, velikost displeje nebo prave dpi, tak se normalne aplikace restartuje a obnovi stav pred restartem. Ale jde nastavit, aby se pri zmene dpi, jazyka, atd. restart neprovadel s tim, ze aplikace jenom dostane zpravu o zmene.

[dumblob]

Super, tak tohle co popisujes chci mit "bez namahy" (treba slider v GUI) a chci to mit na vsech zarizenich (ne jenom na Androidu; btw WPF ma take fixni jednotku, ale tam je kupa vyjimek a je to stejne k nicemu ) a k tomu implicitni podporu ve vsech aplikacich . Pak uz staci nahradit "javu" v Androidu necim bez latence (treba Lua) a hned bych vyhodil tu moji dosluhujici Nokii 6210.

Konec sneni a zpatky do reality - proste kdyz to shrnu, tak zmena DPI na Androidu je bolestiva a prinasi akorat problemy (nepouzivam ani tak Android jako hlavne aplikace, ktere s tim proste ve vetsine pripadu nepocitaji). A jsme tam, kde jsme byli .

Ale diky za info, netusil jsem, ze to je v Androidu natolik funkcni, ze muzu skalovat to GUI bez zmeny proporci mezi objekty (napr. vzdalenost pisma od okraju tlacitek apod.), to bych oznacil za velky skok vpred, ktery jsem zjevne zaspal (stejne se mi tomu moc nechce verit - musim si to nekde vyzkouset/overit).

[Člověk z Horní Dolní]

nahradit "javu" v Androidu necim bez latence

Java v Androidu je rychla

hlavne aplikace, ktere s tim proste ve vetsine pripadu nepocitaji

Vetsina aplikaci pouziva dp, takze na zmenu dpi reaguje. Jenom se pri zmene restartuji, podobne jako kdyz se zmeni jazyk.

[dumblob]

Java v Androidu je rychla

Rychlost vypoctu neimplikuje nizkou latenci. Jako vtip vsak dobry. Ale to uz jsme moc off-topic.

Vetsina aplikaci pouziva dp, takze na zmenu dpi reaguje.

No, budu si muset nekde overit jak na to reaguji. Kazdopadne jeste jednou diky.

[Člověk z Horní Dolní]

Ted nevim co konkretne myslis latenci. Dej nejaky priklad pomalosti Javy na Androidu.

[Josef Kufner]

No, ... na 1GHz CPU bych čekal rychlejší reakce od aplikací, ale je to mnohem lepší než ta desktopová Java.

[Člověk z Horní Dolní]

To bude spis problem aplikace, viz muj koment nize.

[Josef Kufner]

No, ale to asi všech aplikací, neboť to pozoruju globálně. I když to není nic tragického, něco optimalizování by to ještě zasloužilo.

[dumblob]

Vezmi do ruky iPhone a neco s Androidem a chvili si na obou hraj. Zjistis, ze iPhone jaksi reaguje svizneji (tim nemam na mysli kratsi doby animaci, to opravdu ne), ackoliv na stopkach nameris stejne doby spousteni obdobnych/stejnych aplikaci (od tapnuti po objeveni se "okna" aplikace). Je to obdobne jako latence mysi v X a ve framebufferu - doporucuji vyzkouset, je to fakt zazitek (sam jsem zasnul na nasi domaci plecce).

A prosim zadne pripominky typu, ze iPhone ma jiny HW nez Android a ze jsou tedy neporovnatelne.

[Člověk z Horní Dolní]

Zalezi o jaky Android telefon jde. Plynulost UI a latenci hodne zlepsili v Androidu 4.1. Napr. tripple buffering, vsync nebo to, ze kdyz se dotknu displeje, zvysi se frekvence CPU na maximum. Teoreticky by nemel byt problem udelat aplikaci plynulou stejne jako na iOS. Jenom je potreba aby a) kresleni trvalo max 16 ms a b) pri kresleni se nevytvarely novy objekty – aby se nespoustel garbage collector (ktery ale umi bezet v jinem vlakne).

[dumblob]

b) pri kresleni se nevytvarely novy objekty – aby se nespoustel garbage collector (ktery ale umi bezet v jinem vlakne).

To, ze bezi v jinem vlakne je jedno. Synchronizace vlaken take stoji cas - latenci. Krome toho jestli se nemylim, tak diky (get|set)terum neni mozne zajistit, aby se neprovolavaly stovky az tisice fci (tzn. to stejne mnozstvi instrukci pro praci se zasobnikem - proste pro mobilni zarizeni a latenci jednoznacna sebevrazda). Ackoliv se vyhneme vytvareni objektu (coz se dobre eliminuje temi buffery apod. - ale i tak to je casto v aplikacich problem), porad to je dalsi prirustek k latenci.

Nejhorsi je, ze vyse uvedene ma technologie zasobnikoveho automatu "java" proste zadratovane v sobe (rekneme, je to jeji charakteristika) a imho se na mobilni aplikace zase tak moc nehodi zejmena kvuli te zvysene latenci.

[kralyk z abclinuxu]

Java neinlinuje funkce (tam kde se to hodí)?

[dumblob]

Urcite inlinuje (a verim, ze to dela i Dalvik, respektive ten kompilator pro Dalvik VM). Vezmi si ale ten iPhone a neco s Androidem a uvidis "kolik" jich inlinuje a jaky to ma dopad na latenci.

[Člověk z Horní Dolní]

No, kdyby to bylo jedno, neobtezovali by se to implementovat. Rezie volani metody je pod 0.1 ms, uz si nepamatuju kolik presne, nedavno jsem se snazil vtesnat cyklus se 100 000 iteracemi do 20 ms, takze o tom vim sve :) Navic Android kod se vetsinou optimalizuje ProgGuardem, ktery gettery / settery eliminuje. Android ma JIT, takze hodne protezovane metody nebo kusy kodu se zkompiluji do nativniho kodu. Takze latence Androidi Javy je spis mytus nez realita.

[dumblob]

Takze latence Androidi Javy je spis mytus nez realita.

O Platonove jeskyni jsi slysel? Vyzkousel jsem si nejen Android a bohuzel ve mne zustal od posledne negativni dojem (tusim, ze to byla verze 4.1).

Uznavam, ze to nemusi byt jenom technologii (tedy javou) ale treba totalne prasacky psanym SW nebo i necim jinym, ale kazdopadne na me Android diky latenci jeste porad (takze ten JIT asi nestaci) nepusobi dobre .

[Člověk z Horní Dolní]

S tim souhlasim, pomalost Androidu mi taky hodne vadila a ani ted to neni idealni. Ale je to hlavne o tom, ze vyvojari iOS se snazili mnohem vic (o designerech nemluve).

[Člověk z Horní Dolní]

A dalsi vec je, ze na latenci se podili i HW (kapacitni displej).

[dumblob]

A prosim zadne pripominky typu, ze iPhone ma jiny HW nez Android a ze jsou tedy neporovnatelne.

[Bedňa]

LOS vidím rovnako na PC aj v mobile, nejak mi uniká pinta.

[kralyk z abclinuxu]

nejak mi uniká pinta

Jó, to je známý efekt. Pinta začne vždycky po čase nebezpečně unikat Musíš objednat další

[Bedňa]

Tak nalej Kralyku

[tsLnox]

LOL