811
Software / Re: Sh scripty a mezery v názvech souborů
« kdy: 30. 01. 2011, 03:47:41 »
No tak zrovna jak uvozovky, tak i \n se v názvu souboru použít může. Jediný opravdu zakázaný znak je null char a lomítko.
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
812
Vývoj / Re: PHP: zvýraznění výrazu a diakritika
« kdy: 25. 01. 2011, 22:43:42 »
To moje řešení trvá tak dlouho díky použitýmu kódování. UTF-8 nemá pevnou délku znaku a tam nejde skákat rozumně doprostřed řetězce indexem. A na to jsem zapoměl.
Řešením je počítat v mb_string s nějakym kódováním s pevnym znakem, např. UCS-2. Pak je to najednou rychlejší, dle mejch testů cca 2x rychlejší:
2,5s ku 4,7s.
Problém je, že vstupní texty budou pravděodobně v UTF-8 a pak teda je nutné dělat dvojí konverzi (na vstupu a výstupu fce), takže se rychlost smrskne na
3,9s ku 4,7s
a tady je už asi rychlejší použít ten substring. I když todle řešení je robustnější, tamto bude při velkym počtu vyhledanejch řetězců (popř. vyhledávanejch řetězců, kde zas stačí jeden UTF/UCS převod) zpomalovat víc, tam se projeví rychlost kódování UCS-2 (zkoušel jsem jen svůj algoritmus, při vyhledání 'a' byl najednou rozdíl
mezi UCS a UTF-8 1 ku 5,9s (menší počet iterací).
Ideální by bylo, kdyby (mb_)substr řetěazce nekopíroval, ale to bychom chtěli od php příliš....
Jo, ještě v těch řešeních je nadužívání mb_strlen - vzhledem k tomu, že u mb se musí projít celej řetězec, tak tam to vadí, i když jsem předtim tvrdil, že ne... :-(
Ad na klientu: Šlo by to i zkombinovat: na serveru převést utf8 na ascii a na klientu to zvýraznit :-)
PS: Jo a UCS-2 nemá všechny znaky, takže přijdeš o starou čínštinu apod... UCS-4 to řeší, ale to by bylo zas pomalejší, přecijenom cca 3x větší paměťový nároky se poznaj....
Řešením je počítat v mb_string s nějakym kódováním s pevnym znakem, např. UCS-2. Pak je to najednou rychlejší, dle mejch testů cca 2x rychlejší:
2,5s ku 4,7s.
Problém je, že vstupní texty budou pravděodobně v UTF-8 a pak teda je nutné dělat dvojí konverzi (na vstupu a výstupu fce), takže se rychlost smrskne na
3,9s ku 4,7s
a tady je už asi rychlejší použít ten substring. I když todle řešení je robustnější, tamto bude při velkym počtu vyhledanejch řetězců (popř. vyhledávanejch řetězců, kde zas stačí jeden UTF/UCS převod) zpomalovat víc, tam se projeví rychlost kódování UCS-2 (zkoušel jsem jen svůj algoritmus, při vyhledání 'a' byl najednou rozdíl
mezi UCS a UTF-8 1 ku 5,9s (menší počet iterací).
Ideální by bylo, kdyby (mb_)substr řetěazce nekopíroval, ale to bychom chtěli od php příliš....
Jo, ještě v těch řešeních je nadužívání mb_strlen - vzhledem k tomu, že u mb se musí projít celej řetězec, tak tam to vadí, i když jsem předtim tvrdil, že ne... :-(
Ad na klientu: Šlo by to i zkombinovat: na serveru převést utf8 na ascii a na klientu to zvýraznit :-)
PS: Jo a UCS-2 nemá všechny znaky, takže přijdeš o starou čínštinu apod... UCS-4 to řeší, ale to by bylo zas pomalejší, přecijenom cca 3x větší paměťový nároky se poznaj....
813
Vývoj / Re: PHP: zvýraznění výrazu a diakritika
« kdy: 25. 01. 2011, 12:40:31 »
Peterson: viz např. ghostovo řešení. Zvýrazňovat celý slovo - to je takovej problém získanej index (respektive interval indexů) "rozšířit" o všechny nebílý znaky na obě strany?
Ghost: ten strlen by tak nevadil, v php je dýlka stringu uložená, takže se nemusí projít celej string. Horší je, že v každym kroku cyklu vytváříš novej $_string, místo toho, co bys nechal původní a hledal od určitýho indexu. No a pak ještě to jde taky dělat "inplace", stačí si pamatovat délku vloženejch segmentů. U hodně dlouhýho řetězce (řádově stovky kilobajt) to může udělat znatelnej rozdíl, nejen ve spotřebě paměti, ale taky potažmo rychlosti díky procesorový cache.
Ale možná úplně nejlepší řešení je ne budovat ten string inkrementálně, ale jeho vytvářený kousky házet do pole a pak výslednej řetězec vytvořit pomocí implode. Odpadne vytváření spousty pracovních pomocnejch řetězců a v implode se vše naalokuje a zkopíruje najednou.
Dokonce některý knihovny by to tak zvládly bez jakýhokoli kopírování částí řetězců - někde je substr implementovaný tak, že nevytváří novej buffer, ale používá buffer
původního řetězce, takže by se opravdu řetězec kopíroval pouze jednou. To ale bohužel není případ php.
Ghost: ten strlen by tak nevadil, v php je dýlka stringu uložená, takže se nemusí projít celej string. Horší je, že v každym kroku cyklu vytváříš novej $_string, místo toho, co bys nechal původní a hledal od určitýho indexu. No a pak ještě to jde taky dělat "inplace", stačí si pamatovat délku vloženejch segmentů. U hodně dlouhýho řetězce (řádově stovky kilobajt) to může udělat znatelnej rozdíl, nejen ve spotřebě paměti, ale taky potažmo rychlosti díky procesorový cache.
Ale možná úplně nejlepší řešení je ne budovat ten string inkrementálně, ale jeho vytvářený kousky házet do pole a pak výslednej řetězec vytvořit pomocí implode. Odpadne vytváření spousty pracovních pomocnejch řetězců a v implode se vše naalokuje a zkopíruje najednou.
Dokonce některý knihovny by to tak zvládly bez jakýhokoli kopírování částí řetězců - někde je substr implementovaný tak, že nevytváří novej buffer, ale používá buffer
původního řetězce, takže by se opravdu řetězec kopíroval pouze jednou. To ale bohužel není případ php.
814
Vývoj / Re: PHP: zvyrazneni vyrazu, preg_replace vs. diakritika
« kdy: 25. 01. 2011, 09:25:07 »
ehm.... jednodušší? výkonější? To tvoje řešení je kulantně řečeno jedno z nejhorších. Jedinou devizu má, že je vcelku krátký, i když hromada lepších řešení by nebylo o moc delších.
O co je výkonější rozdělit text do pole a zkonvertovat každej prvek pole, než zkonvertovat celej text najednou? (A už vůbec nemluvim o tom, že text v ASCII si lze
připravit jednou a načítat z databáze už zkonvertovanej....) Už jen to zbytešný rozdělování do pole...
O co je výkonější provnávat každej prvek pole, než vyhledávat najednou v celym řetězci? Nemluvě o x-násobný kompilaci regulárního řetězce.
A každý nalezený slovo v řetězci navíc v každé podobě (s diakritikou nebo bez) hledáš v řetězci znovu. Takže pokud se ti tam vyskytuje Počítač, počítač, pocitac a Pocitac, tak místo jednoho převedení textu na lowercase ascii a vyhledání pomocí jednoduchého strpos (značně levnější než preg_match) to vyhledáváš 5x... To je výkonnost :-)
PS: Jako detail už je, že když už používáš str_replace, tak bys moh to aspoň nahradit vše najednou, viz argument typu pole u str_replace, nebudeš tak x-krát sestavovat dlouhej řetězec.
PPS: Kdyby každej programátor povinně rok psal v C/C++,. to by byl svět krásnej :-)
O co je výkonější rozdělit text do pole a zkonvertovat každej prvek pole, než zkonvertovat celej text najednou? (A už vůbec nemluvim o tom, že text v ASCII si lze
připravit jednou a načítat z databáze už zkonvertovanej....) Už jen to zbytešný rozdělování do pole...
O co je výkonější provnávat každej prvek pole, než vyhledávat najednou v celym řetězci? Nemluvě o x-násobný kompilaci regulárního řetězce.
A každý nalezený slovo v řetězci navíc v každé podobě (s diakritikou nebo bez) hledáš v řetězci znovu. Takže pokud se ti tam vyskytuje Počítač, počítač, pocitac a Pocitac, tak místo jednoho převedení textu na lowercase ascii a vyhledání pomocí jednoduchého strpos (značně levnější než preg_match) to vyhledáváš 5x... To je výkonnost :-)
PS: Jako detail už je, že když už používáš str_replace, tak bys moh to aspoň nahradit vše najednou, viz argument typu pole u str_replace, nebudeš tak x-krát sestavovat dlouhej řetězec.
PPS: Kdyby každej programátor povinně rok psal v C/C++,. to by byl svět krásnej :-)
815
Vývoj / Re: PHP: zvyrazneni vyrazu, preg_replace vs. diakritika
« kdy: 24. 01. 2011, 16:29:52 »
No jedna možnost je pocčítač přepsat na něco typu
po[cč][ií]ta[cč]
písmen s diakritikou není tolik, takže výslednej regexp nebude tak dlouhej.
Druhá možnost je převést text na text bez diakritiky, vyhledat tam pocitac
a zvýrazňovat pak v orioginálním textu pomocí indexu.
po[cč][ií]ta[cč]
písmen s diakritikou není tolik, takže výslednej regexp nebude tak dlouhej.
Druhá možnost je převést text na text bez diakritiky, vyhledat tam pocitac
a zvýrazňovat pak v orioginálním textu pomocí indexu.
816
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 11. 01. 2011, 13:45:51 »
A todle si nechám na samostatnej post, protože je to důležitý :-)
Obrovskej rozdíl mezi WINAPI + DirectInput kontra onepes a multies je v tom, KDO POŽADUJE ZJEDNODUŠENÍ.
U myši 99% aplikací chce pouze vědět, kam se kliklo. Proto se udělalo jednodušší rozhraní pro myš. Původcem zjednodušení je tedy typický klient.
Naopak u jedno a multipsa není původcem zjednodušení klient, ale server! Většina klientů myslivce (ať na honu, kde přeci nebude mít myslivec u nohou tři psy a furt posílat jen jednoho, tak u veterináře, který očkuje všechny psy, nebo na hranicích atd....) chce pracovat se všemi psy myslivce. Akorát aktuální implementace myslivce počítá jen s jedním psem. Takže zjednodušení rozhraní tady vychází nikoli z potřeb klientů rozhraní, ale od serveru. A to je myslím klíčový problém.
Pokud zjednodušuji na žádost klientů, tak server umí poskytovat i komplexní služby, není tedy problém mít od začátku dvě rozhraní (jednodušší a komplexní), popř. v horším případě to komplexní dopsat. Nemohu se přitom dopustit chyby, kompilátor vychytá, u kterých všech objektů je nové rozhraní potřeba doimplementovat.
Pokud ale zjednodušuji kvůli serveru, tak v okamžiku, kdy chci vytvořit plnohodnotný server, musím opravit všechny klioše, používající zjednodušené rozhraní. Ale TADY MI NIKDO NEPOVÍ, kteří to všechny jsou. S velkou pravděpodobností se dopustím chyby.
PS: A klientů je velmi často hodně: např. krásně to jde ukázat na myši. Čeho je více? Typů myší, nebo aplikací myš používajících? Nebo čeho je více? Typů soubor (soubor, socket, nějaký bitový device apod.), nebo aplikací starajících se o soubory? Existuje více databází, nebo více uživatelů databází.
PPS: Navíc ten příklad jen podporuje mojí teorii, protože se věci poněkud změnili :-).
DirectInput je deprecated, místo něho se má pro myš použít RAW Input, komunikující standardně pomocí windowsích zpráv. Z pohledu WINAPI jde v podstatě o rozšíření původního rozhraní o jednu zprávu - metodu.
Proč tedy microsoft ustoupil od definování nového rozhraní a místo toho rozšířil staré rozhraní, když je to tak špatně???
Nebo jsi možná myslel DirectInput rozhraní pro herní ovladače? I to je deprecated a místo toho je XInput. A kupodivu to je nedoporučené používat pro myši a podobné zařízení. Proč? No protože myš není herní ovladač. Opět to potvrzuje to, co jsem tvrdil. Pro věci stejné povahy má být jedno rozhraní, a naopak věci různé povahy implementovat stejné rozhraní nemají.
Obrovskej rozdíl mezi WINAPI + DirectInput kontra onepes a multies je v tom, KDO POŽADUJE ZJEDNODUŠENÍ.
U myši 99% aplikací chce pouze vědět, kam se kliklo. Proto se udělalo jednodušší rozhraní pro myš. Původcem zjednodušení je tedy typický klient.
Naopak u jedno a multipsa není původcem zjednodušení klient, ale server! Většina klientů myslivce (ať na honu, kde přeci nebude mít myslivec u nohou tři psy a furt posílat jen jednoho, tak u veterináře, který očkuje všechny psy, nebo na hranicích atd....) chce pracovat se všemi psy myslivce. Akorát aktuální implementace myslivce počítá jen s jedním psem. Takže zjednodušení rozhraní tady vychází nikoli z potřeb klientů rozhraní, ale od serveru. A to je myslím klíčový problém.
Pokud zjednodušuji na žádost klientů, tak server umí poskytovat i komplexní služby, není tedy problém mít od začátku dvě rozhraní (jednodušší a komplexní), popř. v horším případě to komplexní dopsat. Nemohu se přitom dopustit chyby, kompilátor vychytá, u kterých všech objektů je nové rozhraní potřeba doimplementovat.
Pokud ale zjednodušuji kvůli serveru, tak v okamžiku, kdy chci vytvořit plnohodnotný server, musím opravit všechny klioše, používající zjednodušené rozhraní. Ale TADY MI NIKDO NEPOVÍ, kteří to všechny jsou. S velkou pravděpodobností se dopustím chyby.
PS: A klientů je velmi často hodně: např. krásně to jde ukázat na myši. Čeho je více? Typů myší, nebo aplikací myš používajících? Nebo čeho je více? Typů soubor (soubor, socket, nějaký bitový device apod.), nebo aplikací starajících se o soubory? Existuje více databází, nebo více uživatelů databází.
PPS: Navíc ten příklad jen podporuje mojí teorii, protože se věci poněkud změnili :-).
DirectInput je deprecated, místo něho se má pro myš použít RAW Input, komunikující standardně pomocí windowsích zpráv. Z pohledu WINAPI jde v podstatě o rozšíření původního rozhraní o jednu zprávu - metodu.
Proč tedy microsoft ustoupil od definování nového rozhraní a místo toho rozšířil staré rozhraní, když je to tak špatně???
Nebo jsi možná myslel DirectInput rozhraní pro herní ovladače? I to je deprecated a místo toho je XInput. A kupodivu to je nedoporučené používat pro myši a podobné zařízení. Proč? No protože myš není herní ovladač. Opět to potvrzuje to, co jsem tvrdil. Pro věci stejné povahy má být jedno rozhraní, a naopak věci různé povahy implementovat stejné rozhraní nemají.
817
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 11. 01. 2011, 13:10:43 »
Pokud jediné kritérium, podle kterého budete kvalitu měřit, je zisk v době uvedení na trh, tak bude nejlepší naprosto nedokumentovaný kód napsaný jedním vývojářem někde v garáži. Ten se totiž napíše nejrychleji a tedy nejlevněji. Kupodivu takový kód považují všichni za špatný.
Pokud ho chcete posuzovat podle zisků, které přinese v budoucnu, tak pokud nemáte křišťálovou kouli, tak je to úplně stejně vágní kritérium, jako čistota kódu (už proto, že tato kritéria jsou zcela jasně korelované).
Ona ta "výhleová ekonomická výhodnost" kódu je poměrně složené kritérium: zahrnuje čas na napsání, čas na zaučení nového vývojáře pro úpravu kódu, reusabilitu atd... Pokud umíte od pohledu všechna tato kritéria odhalit najednou, asi jste machr. Noirmální člověk zhodnotí jednotlivá částečná kritéria a udělá syntézu. Proto tvrdím, že se bavit o čistotě kódu má smysl (byť jak celou dobu tvrdím, to není jediné a tedy absolutní kritérium).
---
Pokud si jednu knihovnu budou půjčovat různá oddělení, tak o co jiného jde, než definici standardního rozhraní?
A kde tvrdím, že ovladač pro myš by měl být společný pro všechny druhy ovládání? Já tvrdím, že ovladač pro myš by měl být společný pro všechny myši v tom smyslu, že kterákoli myš, když ji zapojím do počítače, má aplikacím vysílatstejné zprávy a chovat se konzistentně.
Ad databáze - ten příměr je mimo z mnoha důvodů. Zaprve různé databáze nejsou různá rozhraní, ale různé implementace. O unifikaci rozhraní různých databází se výrobci evidentně snaží, proč jinak by schvalovali standardy SQL? Další věc je, že databáze není služba, kterou by měl poskytovat OS. Pokud by byla, mělo by být jedno API, jenže to tak prsotě není. Jednotná služba je např. filesystém, přístup ke konfiguraci atd... A tady jde jednoduše ukázat, že filesystémy maj všude jednotné api, i když implementací v linuxu je mraky - a nikdo nenapíše filesystém, který by byl nekompatibilní. Naopak konfigurace ve windows je vcelku jednotná (registry) zatímco v linuxu každý pes jiná ves. Nechci hájit registry, maj dost much, ale samotná myšlenka jednotného ukládání konfigurace linuxu velmi schází.
---
Ad linux: ale přeci to, že jsou v linuxu ovladače se považuje za velké plus linuxu. Strčím placku a funguje to.
Problém linuxu není v tom, že má v sobě ovbladače. Problém linuxu je v jeho naprosto nemodulárním jádře, které se musí kvůli každé blbině překompilovat.
Problém linuxu není v tom, že není v C++. Takto by to šlo napsat i v C (byť o něco pracněji). Problém je v tom, že kdyby tam bylo x verzí rozhraní pro každou blbost, tak by jádro místo jednoho volání vždy muselo dělat x emulací a výkon by šel do kopru. Zrovna v linuxovíém jádře je to, že stará rozhraní nenechají dožít, ale odstraňují je pokud možno hned, pochopitelné.
Pokud ho chcete posuzovat podle zisků, které přinese v budoucnu, tak pokud nemáte křišťálovou kouli, tak je to úplně stejně vágní kritérium, jako čistota kódu (už proto, že tato kritéria jsou zcela jasně korelované).
Ona ta "výhleová ekonomická výhodnost" kódu je poměrně složené kritérium: zahrnuje čas na napsání, čas na zaučení nového vývojáře pro úpravu kódu, reusabilitu atd... Pokud umíte od pohledu všechna tato kritéria odhalit najednou, asi jste machr. Noirmální člověk zhodnotí jednotlivá částečná kritéria a udělá syntézu. Proto tvrdím, že se bavit o čistotě kódu má smysl (byť jak celou dobu tvrdím, to není jediné a tedy absolutní kritérium).
---
Pokud si jednu knihovnu budou půjčovat různá oddělení, tak o co jiného jde, než definici standardního rozhraní?
A kde tvrdím, že ovladač pro myš by měl být společný pro všechny druhy ovládání? Já tvrdím, že ovladač pro myš by měl být společný pro všechny myši v tom smyslu, že kterákoli myš, když ji zapojím do počítače, má aplikacím vysílatstejné zprávy a chovat se konzistentně.
Ad databáze - ten příměr je mimo z mnoha důvodů. Zaprve různé databáze nejsou různá rozhraní, ale různé implementace. O unifikaci rozhraní různých databází se výrobci evidentně snaží, proč jinak by schvalovali standardy SQL? Další věc je, že databáze není služba, kterou by měl poskytovat OS. Pokud by byla, mělo by být jedno API, jenže to tak prsotě není. Jednotná služba je např. filesystém, přístup ke konfiguraci atd... A tady jde jednoduše ukázat, že filesystémy maj všude jednotné api, i když implementací v linuxu je mraky - a nikdo nenapíše filesystém, který by byl nekompatibilní. Naopak konfigurace ve windows je vcelku jednotná (registry) zatímco v linuxu každý pes jiná ves. Nechci hájit registry, maj dost much, ale samotná myšlenka jednotného ukládání konfigurace linuxu velmi schází.
---
Ad linux: ale přeci to, že jsou v linuxu ovladače se považuje za velké plus linuxu. Strčím placku a funguje to.
Problém linuxu není v tom, že má v sobě ovbladače. Problém linuxu je v jeho naprosto nemodulárním jádře, které se musí kvůli každé blbině překompilovat.
Problém linuxu není v tom, že není v C++. Takto by to šlo napsat i v C (byť o něco pracněji). Problém je v tom, že kdyby tam bylo x verzí rozhraní pro každou blbost, tak by jádro místo jednoho volání vždy muselo dělat x emulací a výkon by šel do kopru. Zrovna v linuxovíém jádře je to, že stará rozhraní nenechají dožít, ale odstraňují je pokud možno hned, pochopitelné.
818
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 11. 01. 2011, 01:51:10 »
BLEK.: To co píšeš je ale čistě ekonomické hledisko. Z hlediska čistoty zdrojového kódu i uživatelské přítulnosti GUI to jednoznačně řešení horší. Čili jak jsem psal: někdy člověk musí slevit z dobrého kódu kvůli ekonomice.
To, že pro microsoft je levnější, když to za něj napíšou jiné firmy je jasné, ale v původním problému, z kterého se diskue vivinula, bych to musel tak jako tak napsat všechno já (nebo nějakej kolega ze stejný firmy).
Btw. modulární systém Ti nic neříká? Kdo říká, že to tam musí být napevno?
A ad klávesnice pro blondýny: to je normální klávesnice a ovladač na ní samozřejmě ve windows je. To ale nic nemění na tom, že kromě ceny nemá chybu :-)
To, že pro microsoft je levnější, když to za něj napíšou jiné firmy je jasné, ale v původním problému, z kterého se diskue vivinula, bych to musel tak jako tak napsat všechno já (nebo nějakej kolega ze stejný firmy).
Citace
(kdyby bylo ovládání všech možných klávesnic a myší v základním systému, tak to při chybě neodinstaluješ).Ty nepoužíváš linux? Tam jsou v jádře ovladače snad na všechno a že by to způsobovalo nestabilitu....
Btw. modulární systém Ti nic neříká? Kdo říká, že to tam musí být napevno?
A ad klávesnice pro blondýny: to je normální klávesnice a ovladač na ní samozřejmě ve windows je. To ale nic nemění na tom, že kromě ceny nemá chybu :-)
819
Vývoj / Re: Příklad na plánování - jaké je řešení ?
« kdy: 10. 01. 2011, 20:56:33 »
Hele, bez Tvý snahy Ti to nikdo za Tebe řešit nebude. Alespoň teda já ne. Rád Ti zkontroluju řešení, u kterýho bude vidět, že ses to snažil pochopit a třeba dovysvětlim to, co si pochopil špatně. Klidně i zodpovím jakoukoli konkrétní otázku k tomu, textu, co jsem linkoval, najdeš v něm všechno, co potřebuješ.
Ty ale evidentně chceš, aby to vyřešil někdo za Tebe a to ochotnej nejsem. Navíc nám trochu kecáš, v třetim postu se tváříš, jako že máš řešení a jen ho potřebuješ zkontrolovat, a najedou přiznáváš, že žádný nemáš... :-)
Ty ale evidentně chceš, aby to vyřešil někdo za Tebe a to ochotnej nejsem. Navíc nám trochu kecáš, v třetim postu se tváříš, jako že máš řešení a jen ho potřebuješ zkontrolovat, a najedou přiznáváš, že žádný nemáš... :-)
820
Vývoj / Re: Jste zastánci OOP programování?
« kdy: 06. 01. 2011, 15:01:20 »Citace
o kolik zdraží navrhovat aplikaci, aby pracovala s více klávesnicemi současně...Ale aplikace ať klidně pracuje s jednou klávesnicí. API OS by mělo být postaveno tak, aby kdyby aplikace chtěla, tak by mohla pracovat s více...
Stejně tak myslivec mže poskytovat více psů a aplikace může pracovat pouze s prvním psem. Náročnost oproti jednopsu je tady minimální.
Citace
ale třeba i volantu na závodní hry, polohového/akceleračního senzoru, podložky na tancování, EEG snímačno z volantu myš snad udělat nejde, podložku na tancování nikdo jako myš používat nebude. Multitouch displej je od začátku zamýšlen jako něco, co má zároveň emulovat myš. To je trochu rozdíl, ne?
Citace
Pak z toho WINAPI nebude krásné sjednocené rozhraní, ale totální bordel zasypaný spoustou technologií s minimálním podílem na trhu.A co jiného je hromada integrovaných driverů dodávaných s windows nebo ještě lépe do linuxového kernelu? To konverzní rozhraní může bejt modul, kterej se doinstaluje v okmažiku, kdy se naisntaluje první multitouch. Proč by z toho měl být bordel nechápu.
Citace
A co se týče multitouch, rozšíří se natolik, aby mělo cenu kvůli tomu Windows zesložiťovat a dávat do nich obecnou konverzi?Nechápu, co je na tom za zesložitění. Jeden "abstraktní ovladač" bez nějakejch závislostech na ostatních komponentách systému.
Na windows v podstatě skoro každá myš, lepší klávesnice atd... si instaluje vlastní ovládací programy, kterejma se víceméně nastavuje to samý, co v stadardním dialogu plus jedna blbina navíc. To se Ti zdá lepší řešení, než kdyby nastavení těch blbin poskytovali jednotně windowsy?
---
Samozřejmě, že někdy se ekonomicky nevyplatí to řešit vše "správně a maximálně obecně" . To ale nic nemění na tom, že všechna zjednodušená řešení mají své chyby a své limity, na které člověk zpravidla později či (z mých zkušeností spíš) dříve narazí.
Zásadní ale je, že k rozhodnutí, jestli to udělám "systémově správně", nebo to zjednodušším mohu udělat až poté, co vím, jak by to mělo být. Pokud budu obě řešení považovat za "rovnocené", tak nemám důvod, proč volit to složitější řešení. Pouze "uvědomění si" problémů jednoduššího řešení mi umožňuje "svobodně" volit mezi nevýhodami (časová náročnost x rozšiřitelnost).
821
Windows a jiné systémy / Re: Přesunutí volného prostoru mezi oddíly disku na serveru 2003
« kdy: 05. 01. 2011, 19:17:08 »
Existují programy, které umí oddíly zmenšovat či zvětšovat (např. to uměl partition magic, nevím, jeslti zvládá to NTFS, co je v 2003, ale těch programů je hafo). Akorát to není nikdy bez rizika ztráty dat, takže stejně se zálohování nevyhneš a pak už je skoro jednodušší oddíly zrušit, vytvořit nový a zkopírovat data zpátky.
822
Software / Re: UNIX ve vyberovem rizeni
« kdy: 04. 01. 2011, 13:26:11 »
Taky bych se silně přikláněl k tomu, že pokud máte s Windows otřesné zkušenosti, co se týče ergonomie, tak jako jedno hodnotící kritérium ji dát. Když se zamyslíš čím vším Tě ještě jednotlivé programy štvou, tak těch podmínek můžeš vymyslet i víc a koupíte určitě to, co pro Vás bude nejlepší.
Když bude v podmínkách jen cena, tak riskuješ, že Tě pak nějakej "chytrej manažer" přinutí koupit nejlevnější šmejd...
Když bude v podmínkách jen cena, tak riskuješ, že Tě pak nějakej "chytrej manažer" přinutí koupit nejlevnější šmejd...
823
Software / Re: UNIX ve vyberovem rizeni
« kdy: 03. 01. 2011, 12:07:41 »
eifell: Pokud je to v nemocnici, tak to bude asi podle zákona o veřejnejch zakázkách a pak si rozhodně růžou krabici naporoučet nemůžou....
Osobně bych ale stejně se snažil winy vyloučit nikoli předem, ale díky hodnotícím kritériím. Protože jak už někdo psal, může to snížit cenu...
Osobně bych ale stejně se snažil winy vyloučit nikoli předem, ale díky hodnotícím kritériím. Protože jak už někdo psal, může to snížit cenu...
824
Vývoj / Re: Příklad na plánování - jaké je řešení ?
« kdy: 02. 01. 2011, 23:23:03 »
Tak sem dej svoje odůvodněný řešení a my Ti ho zkontrolujem, popř. řekneme kde máš chybu a pokud pochopíme, cos nepochopil, tak i dovysvětlíme.... :-)
825
Vývoj / Re: Příklad na plánování - jaké je řešení ?
« kdy: 29. 12. 2010, 21:29:15 »
http://oreilly.com/catalog/linuxkernel/chapter/ch10.html
Přečti si to a řekni, co přesně nechápeš.
Přečti si to a řekni, co přesně nechápeš.
