Itt a teljesen új grafikus csatolót használó Qt 6.0
2020-12-14T10:19:07+01:00
2021-01-22T08:48:01+01:00
2022-07-20T11:57:09+02:00
  • Egy komolyabb játékmotor kb. 5000x többet volt tesztelve mint a Qt. Ez utóbbit pár ipari alkalmazáson túl max. a KDE projekt, és egy-két kisebb tool használja elenyészõ számú felhasználóval. Ráadásul a 4.0 óta a KDE sem annyira népszerû már linuxon mint korábban.
    Mutasd a teljes hozzászólást!
  • Nem tudom te hogy vagy vele de en nem szeretnek olyan rontgengep ala fekudni, vagy autoba ulni, aminek a rendszeret game engine-el fejlesztettek. Nemcsak a sebessegrol van szo, hanem ezek, bugos, teszteletlen eszkozok, amiknek semmi keresnivaloja nincs komoly alkalmazasban. Terinformatika, egeszsegugy, kepfeldolgozas, security, hogy csak nehany teruletet emlitsek, ahol fullstack cpp-vel megy a fejlesztes. Egy kodbazis, nincsen zagyvalas c#-al, plane nem typescripttel meg ilyen marhasagokkal. Orulunk, ha egyfele nyelven atlatjuk a rendszert, nincs varialas,fuggetlenul attol, hogy mobil, vagy desktoprol van szo, vagy akar server oldali dolgokrol, esetleg embedded eszkozrol.
    Mutasd a teljes hozzászólást!
  • Azért nagyon sok játékmotorban egész komoly UI van: akár a Unity-ben, akár a Godot-ban, de még az Urho3D-nek is van UI-a (bár az azért nem annyira erõs mint a fentieknek). De az átlag C++-proginak szerintem nem kell sok UI. Az olyan üzleti appok pedig amik datagridet, tabot, tree-t, és más hasonló dolgokat igényelnek az alapvetõ UI-on túl (button, checkbox, radio, textbox, esetleg combo és listbox) általában már nem C++-ban készülnek, különösen a UI részük. Egy üzleti appot java-ban, C#-ban, rosszabb esetben PHP-ben vagy java/typescriptben fejlesztenek mostanság, a UI pedig vagy webes vagy xaml vagy valami mobil cucc.
    Mutasd a teljes hozzászólást!
  • Maguk a játékmotorok is használnak az editorhoz olyan eszközöket, mint a Qt, vagy a wxWidgets pont azért, mert egy game UI az esetek többségében, amilyen játékokhoz kell olyan egyszerű, mint a faék, az editorhoz meg ettől jóval komolyabb dolgok kellenek. Például Unreal határeset, mert neki profibb a game UI rendszere is, mint egy átlag játékmotornak (de ez továbbra se egyenlő az editorban használt UI-al, ami egy teljesen másik project, mégha az is 3D API használ is), viszont cserébe akkora erőforrásokat használ, ami viszont meghaladja egy autó múszerfalához használt embedded eszköz képességeit. Komolyabb üzleti apphoz meg kevés még az Unreal game UI-ja is, mert azért ilyenek is vannak én is ilyen projectekben dolgozom, ahol desktopra és mobilra is használjuk a Qt-t. Mobilnál hasonló a helyzet mint az embedded-nél, túl sok erőforrást használ egy Unreal engine, ahhoz képest, mint amennyit tud UI-ban. Meg azért a Qt nem csak egy UI, hanem egy komplett framework, egyféle natív .NET-nek is tekinthető. Tehát, ha valahogy használnánk is egy játékmotort egy UI-hoz nagy kompromisszumok árán, akkor is az üzleti oldalhoz kéne még egy framework és akkor már ugyanott vagyunk.
    Mutasd a teljes hozzászólást!
  • Ránéztem a QT oldalára, meglepődtem. Az LG tévém UI-a is abban van írva, de a Merci műszerfal se rossz. Legalább megtalálták a megfelelő piacot, mert a Linux desktop az nem annyira jött be.

    Mindig ilyen nosztalgiával nézek a QT-re, anno ebben írtam a diploma munkám, 20 éve :) mondjuk azóta se programoztam benne.
    Mutasd a teljes hozzászólást!
  • Commercial use-ra is jó az opensource verzió, amennyiben megfelelsz az LGPL3-nak (dinamikusan linkelsz a QT libhez, nem használsz nagyon elvont modulokat, nem módosítasz a Qt forrásokon, a user-nek megadod a lehetőséget, hogy helyettesítse az általad nyújtott dinamikus qt dll-eket saját verziójával, ha akarja, stb..)

    Ahol meg már nagy pénzek gurulnak, ott azért ez nem halálos tétel. Persze nem örülök az iránynak, de megértem, hogy ők is pénzből élnek, a QT pedig elég profi dolog.
    Mutasd a teljes hozzászólást!
  • Arról nem is beszélve, hogy ma már a beágyazott rendszereken túl (azaz Pl. egy autó műszerfala vagy hasonló) nemigen használunk C++-t GUI felülettel. Az persze megint egy másik kérdés, hogy Pl. én legalábbis egy autó mûszerfalához valami kisebb játékmotort használnék, azzal látvángyosabb UI-t lehet csinálni, és ott kevésbé fontos hogy legyen mondjuk datagrid. Szerintem pont azért is ilyen drága, mert nem nagyon van vevõ.
    Mutasd a teljes hozzászólást!
  • Mindig neccesek első ránézésre a hasonló árak, de én ezt mindig más szemszögből szoktam nézni:
    A $8,400 dollár még a magyar fizetési viszonyok mellett is lazán egy fejlesztő két havi bérköltsége (C++ fejlesztőnél lehet, hogy csak másfél).

    Ha egy olcsóbb, vagy ingyenes kevésbé stabil, vagy kevesebbet tudó libraryt használ a cég, a hibakeresésekkel, saját komponensek lefejlesztésével lazán elköltik ezt az összeget a fejlesztőre, arról nem is beszélve, hogy akkor még saját maguknak kell supportálniuk a dolgokat.
    Tehát ha úgy nézzük, hogy másfél-két havi fizuból egy ilyen tudású komponenskészletet lehet kapni, akkor már egyáltalán nem olyan vészes ez az ár. Van, hogy a drágább a sokkal olcsóbb.

    Kisebb cégeknek, startupoknak a töredékébe kerül, arról nem is beszélve, hogy open source projektekhez ingyenes. (Tehát akár belső felhasználású szoftverekhez is)
    Mutasd a teljes hozzászólást!
  • Mondj legalább ilyen jó eszközt C++ hoz, ami nem ilyen drága.
    Mutasd a teljes hozzászólást!
  • Ha nem csak játszadozni kell, akkor fejlesztőnként:

    with 3-yr. prepayment of $8,400

    Nem gyengén brutális ár ám ez!
    Mutasd a teljes hozzászólást!
abcd