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

vložil Radek Červinka 12. dubna 2012 22:02

Ačkoliv jsem opravdu velký fanda FireMonkey a považuji to za geniální a použitelnou věc s velkým potenciálem do budoucna, je několik věcí co mi radost kalí. Je mi jasné, že v další verzi bude FireMonkey výrazně vylepšena, ale v současné verzi mám tyto problémy:

  • není podpora TAction a ActionList
  • není RTF editor (nebo něco podobného)
  • reporty
  • problém s vykreslováním textu (aliasing)
  • není portován Virtual TreeView (ale za to tak úplně EMBT nemůže)

Action List (viz. můj starší článek) a spol. považuji za jednu z klíčových věcí a velmi mne překvapilo, že FireMonkey neobsahuje podporu (zvláště když předchůdce jistou podporu měl, a nějaké náznaky jsou tam zapoznámkované). Ptal jsem se na setkání s DavidI a on mi řekl něco ve smyslu, že to plánují a zapsal jsi poznámku že jsem se ptal.

RTF editor nebo něco takového je komplikovanější věc, jelikož TRichEdit ve VCL je postaven kolem Windows prvku se všemi jeho nevýhodami. Což samozřejmě z podstaty věci nejde použít pro FireMonkey (multiplatformní, vektorový). Existuje ale TRichEdit - autorem je Sergey Tkachenko - což je překvapivě zase Rus. Jedná se o nativní VCL komponentu pro editaci textu s podporou RTF. Navíc autor slíbil port pro FireMonkey v budoucnosti. Nejlepší by bylo kdyby ho EMBT koupilo ;-) - myslím tím celou firmu. Delphi by získalo konečně kvalitní editor pro VCL (lepší než je součástí Windows) a zároveň i editor pro FireMonkey.

Reporty - FastReport má být portován (podle slov autorů). Navíc spolupráce lidí z FastReport s EMBT je už teď celkem výrazná (viz oříznutá verze FastReportu nebo FastCube). No být EMBT tak bych je koupil taky (pokud jsou na prodej)…

Problém s vykreslováním textu je peklo. V Update 4 se to snaží nějak řešit (už jsem tady o tom psal) a nebylo to ono. Jedná se o dokumentované chování při vykreslování v GDI+ a DirectWrite / bohužel neexistuje rozumné přímé řešení. Zajímavé je, že pokud si vzpomínám, tak MS ve WPF se potýkal se stejným problémem a pak to nějak obešel. Ale že by sakra opravil chování GDI+ to tedy ne. EMBT slibuje řešení v nějakém update i pro XE2. Ale je to komplikované.

No a Virtual TreeView. Tato komponenta mi velmi chybí - zde je anketa o podpoře FireMonkey. S tím souvisí i neexistence TImageList - což komplikuje portování některých komponent. Tady jen doufám.

Jen tak pro zajímavost, koho by jste koupili vy být na jejich místě?

Tagy: ,

FireMonkey

Komentáře

13.4.2012 0:42:53 #

PS

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 9:48:36 #

Radekc

>ako to VŽDY skončí
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.

>neskutočnou pomalosťou
To prostě není pravda. Pokud to spouštíte z IDE tak je to pomalé, ale bez IDE to je na průměrné kartě velmi slušně rychlé. Ještě je rozdíl mezi XP a vyššími verzemi, kdy na XP se používá GDI+ (tam bych i věřil že někdo může mít problém). Jinde se používá DirectX potažmo DirectWrite. Navíc jste Pavle nenapsal zda píšete 2D nebo 3D aplikaci.

Ale od Vás nic jiného než stížnosti samozřejmě ani nečekám.


Radekc

13.4.2012 10:02:37 #

Radekc

BTW: Nemusíme chodit daleko: Codegear byl také pohlcen Embarcaderem a jak to dopadlo? VGScene bylo koupeno Embarcaderem a vzniklo z toho FireMonkey (což pro mne je plus, pro tebe asi mínus ;-)).

Instagram byl koupen Facebookem a je to to nejlepší co se jim mohlo stát - zůstanou tím čím jsou, jen každý dostal x dolarů.

Radekc

13.4.2012 10:58:12 #

Leoš

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 #

PS

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 11:19:34 #

Radekc

OK, ja byt firma o 2-3 lidech tak jsem rad kdyz mne nejaka rozumna firma koupi, protoze pak se nemusim starat o zakazky, reklamu atd. Ale je to vec nazoru.

>Priority vo vývoji bude nastavovať niekto iný ako komunita, alebo vývojár.
Pokud vím tak priority zrovna u EMBT nastavují pravě tito lidé. Viz. 64bit, Unicode, iOS a Android.

>Resp. ak to používali v Lazaruse? Alebo ak by Fastreport kúpil EMBT, čo ostane chudákom .NET užívateľom?
Takovy je zivot. Mimochodem, proc by nemohlo EMBT prodavat verzi i pro .NET. MS ma taky většinu přijmu u mobilů z iOS nebo Androidu.

Radekc

13.4.2012 17:27:36 #

petr

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

14.4.2012 12:43:36 #

Radekc

2petr: Android - je na bázi ARM a OpenGL ES. Jelikož FMX je celá custom draw, bude se pro vykreslování používat OpenGL ES (takto už je to dělané na OSX a iOS) a Delphi kompilátor bude produkovat NATIVNI (tj. ARM) kod (stejně jako pro iOS a další mobilní procesory).

Jinak samozřejmě pro Android se dá programovat i za pomoci C nebo C++ za pomocí Native Development Kit -
http://en.wikipedia.org/wiki/Android_software_development#Native_development_kit

Ohledně Delphi to oficiálně naznačuje JT (Delphi Product Manager) - http://blogs.embarcadero.com/jtembarcadero/2011/09/17/may-the-roadmap-rise-with-you/

A jinak mi prostě věř :-)

Radekc

23.4.2012 14:39:03 #

JaroB

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

Přidat komentář





  • Komentář
  • Náhled
Loading



Naše nabídka

Partial English version.

MVP
Ing. Radek Červinka - Embarcadero MVP
profil na linkedin, Twitter:@delphicz

Nabízím placené poradenství a konzultace v oblasti programování a vývoje SW.
Dále nabízíme i vývoj speciálního software na zakázku.

Neváhejte nás kontaktovat (i ohledně reklamy nebo burzy práce).

Pokud chcete podpořit tento server libovolnou částkou, můžete použít PayPal. Moc děkuji.

Delphi Certified Developer

O Delphi.cz

Delphi je jediný moderní RAD nástroj podporující tvorbu nativních aplikací pro platformu Win32 a Win64 (a Mac OSX a na iPhone a s výhledem na Android a další platformy díky FireMonkey) na současném trhu (včetně Windows 7).

V současnosti je světová komunita přes dva miliónů vývojářů.

Delphi.cz je nezávislý portál pro uživatele Delphi. Portál není koncipován pro úplné začátečníky, i když i ti se zde nebudou nudit, ale spíše na programátory, kteří již něco znají a chtějí své znalosti dále rozvíjet a sledovat novinky.

Burza delfínů nabízí pracovní možnosti pro programátory v Delphi.

Anketa


Poslední komentáře

Comment RSS