Zamyšlení o problémech FireMonkey a co by s tím EMBT mohlo udělat

13.4.2012 0:42:53 #

Ja by som kúpil nejakú firmu čo opraví bug pri uvoľňovaní ikony formu, strašne ma to štve.

Skupovanie nezávislých tvorcov komponent nie je najlepšia cesta. Kto zažil niekedy pohltenie menšej firmy väčšou určite vie ako to VŽDY skončí ... Už pri FastReporte som dosť tŕpol, hľadať zaň alternatívu by bolo dosť ťažké. Pochybujem, že by so mnou chcel niekto v EMBT preberať zmeny v spôsobe BIFF exportu.

Okrem vykreslovania textu má problém FM samozrejme aj s neskutočnou pomalosťou, už som to písal. Je to strašne všetko pomalé, komplikovanejší formulár potrebuje silnú 3D kartu ...a ešte to pritom vypadá rozpadnuté :(

PS

13.4.2012 10:58:12 #

FastReport má i dotNet verzi a je klidně možné, že Delphi je pro ně "druhý v řadě". Takže bych se spíše bál, aby je nekoupil Microsoft :)

Leoš

13.4.2012 11:05:26 #

A čo mám písať, že FM je rýchle aspoň tak ako VLC keď to nie je pravda? Samozrejme som myslel 2D (3D bude na tom ešte horšie viď posty Erica G.). Ono predsa len je väčšina ovládačov odladená na GDI ako na D2D. Druhá vec je implementácia, kde D2D napr. vo Firefoxe je výrazne funkčnejšie ako vo FM. Plus problém s textom je katastrofálny. Vo výsledku je preto FM aktuálne nepoužiteľné pre reálne nasadenie.

Pre mňa je FM určite plus, pretože vgscene by som si nikdy nekúpil a takto ho dostanem zadarmo, a možno už v použiteľnej verzii keď budem upgradovať :) Horšie sú na tom tí čo si ho kúpili a teraz keď si nekúpia nové delphi majú z toho čo? Resp. ak to používali v Lazaruse? Alebo ak by Fastreport kúpil EMBT, čo ostane chudákom .NET užívateľom? atď.

>Tak jak to vždy skončí? Nemám rád takové řeči protože to není v žádném případě vždy pravda.
Čo nie je pravda? Nepísal som konkrétny prípad :) Neviem si predstaviť, že by vývojár mal toľko voľnosti a slobody v rozhodovaní v tak veľkom tíme a nebol tlačený termínmi, nebol zamestnávaný poradami, poradami o poradách atď ...ako v malom tíme 2-3 vývojárov. Priority vo vývoji bude nastavovať niekto iný ako komunita, alebo vývojár. Možno lepšie, možno horšie.

Iný názor je sťažnosť? Zaoberám sa hlavne UI tak niektoré veci sú pre mňa zásadnejšie ako pre niekoho iného :)

PS

13.4.2012 17:27:36 #

FM je určitě dobrý projekt s obrovským potenciálem do budoucna. Ovšem v rané fázi vývoje. Věcí, které je třeba dodělat, je daleko víc. Např. data binding.

>Pokud vím tak priority zrovna u EMBT nastavují pravě tito lidé. Viz. 64bit, Unicode, iOS a Android.
Není mi moc jasné, jak by mělo FM podporovat Android. Pro ten se programuje v Javě (navíc se specifickou JVM). Struktura formuláře se definuje deklarativně pomocí XML a jednotlivé controly vykresluje operační systém. Není tu tedy žádný prostor pro přímý přístup na grafickou kartu. Ani pro kreslení pomocí něčeho podobného GDI.

petr

23.4.2012 14:39:03 #

Na jedné straně konzervativní zákazník, který nemá rád budoucí očekávání a je schopen kvůli banalitě shodit obchod, a na druhé straně nadšený uživatel, kterému zas tak nějaká chybka nevadí a zvědavě očekává novou verzi doufaje, že bude lepší než ta minulá.

Všechno to souvisí se zásadní otázkou:

Buď zůstat na stávající a osvědčené verzi Delphi (každý nechť dosadí dle svých zkušeností), byť s vědomím, že s prověřenou technologií nedosáhnu na momentální technologické novinky,

nebo se vrhnout do nové verze Delphi, přenést naň komerční aplikace a věřit, že se nevyskytne žádný skrytý defekt, který poškodí dobré jméno aplikace nebo firmy, nesníží zisk, nevžene potenciální klienty do náruče konkurence atp. s bonusem, že budou využity všechny myslitelné novinky a vylepšení.

Taky je možné k tomu přistupovat i jinak, s vědomím, že se jedná o novinku, mohou se vyskytovat chyby a zákazníci na to musí být připraveni, třeba neustálými aktualizacemi aplikace, knihoven, datových souborů a co já vím ještě v této fázi veřejných beta-testů…

Z mého pohledu není asi problém přenést aplikaci z nižší verze na vyšší (např. do XE2), pokud už znám technická úskalí přenesení, ale je problém přesvědčit zadavatele o technologických novinkách, obchodníky o přínosech, uživatele, aby si to vůbec spustili, a testery, aby celou aplikaci znovu vyzkoušeli…

A taky je to o nevratnosti rozhodnutí.
Použiju-li extended records a margins při návrhu, už se nemůžu vrátit před Delphi 2006. Použiju-li  generika a anonymní metody, tak se nemůžu vrátit před Delphi 2009 a o unicode ani nemluvě. V aplikaci to asi není tak hrozné, ale v komponentech je to humáč. Buď jít cestou jako JCL tj. odřezávání nejnižších verzí a zavedení super podmíněných konstrukcí (pro inline, generika, spec unity a funkce, mapování atp.) aby se pokrylo široké spektrum verzí Delphi nebo cestou definování nejnižší verze a basta (čímž zavřu dveře třeba uživatelům Delphi verzí 6/7 nebo i 2005). Pořád jsou nějací uživatelé těch mezistupňových verzí, kteří čekají na stabilní verzi a někteří na ní i zůstanou, většinou z finančních důvodů a možná i vidiny neúměrné pracnosti a času na převedení svých aplikací či komponent na novější platformu.

Všiml jsem si, že požadavky třetích stran, které zadávají vývoj např. specifické funkce nebo komponentu, je i konkrétní verze překladače s požadavkem na použití pouze systémových prostředků dodaných k překladači resp. konkrétní verzi Delphi.
S tím jsem měl kdysi problém,  já to udělal v Delphi 2005, ale požadavek na zdroják byl Delphi 5 (protože zrovna tuhle verzi měl  úřad licencovanou), a já byl v kopru jak s dfm tak i s utf-8 zdrojáky.

Třeba se pletu, a skepse není na místě. Možná už všichni dělají komerční aplikace jen v XE2, co já vím.

Před časem jsem byl nucen vzít svou starší VCL aplikaci, kterou jsem před osmi lety v nadšení z nové technologie stvořil v Delphi 2005 for NET. Byla funkční, ale uživatelé před časem přešli na nový počítač s novými Windows. Podařilo se mi tuto aplikaci i s komponenty úspěšně importovat do BDS 2007 a přeložit v této verzi CLR. A funguje to dokonce lépe, než dříve, čímž jsem byl sám velmi překvapen.
Protože už Embarcadero nepodporuje VCL for NET, tak jsem aplikaci naportoval zpět do Win32 a to do D2010 (s minimem úprav, už to jako Unicode bylo navržené).
Takhle bych si představoval využití zdrojáku, jeden pro všechny platformy, jedno VCL s danými mantinely a možnost zvolit jednoduše cílovou platformu. To co se mi hlavně nelíbí, je množství mezistupňů, které jsou navzájem mírně nekompatibilní, a pro tvůrce komponent drahé, neboť musí mít k dispozici všechny mezistupně, aby ověřil, že komponent je OK (když prohlásím, že komponenty jsou kompatibilní s Delphi 6, tak musím bez chyby otevřít všechny dfm soubory v této verzi, protože, když budou např. vytvořené ve verzi 2007 (nebo jenom v této verzi upravené), tak mi při překladu balíku překladač nic neoznámí a po instalaci balíku do IDE a prvním spuštění takovéhoto formuláře mi to shodí prostředí). Ale to je jenom stesk.

JaroB