3 ms·
This looks completely out of place on every Desktop, in my opinion, which makes Qt Quick unfortunately not an option for me. Related: Did they stop developing
by Longhanks 10y ago
This looks completely out of place on every Desktop, in my opinion, which makes Qt Quick unfortunately not an option for me.
Related: Did they stop developing Qt Widgets?
- joezydeco 10y agoEmbedded Widgets developer here and, yeah, Widgets hasn't gotten a lot of attention in a long time. Probably since 4.8. Given that plus the QWS backend change with v5 and the new LGPL terms, I'm probably staying here for a long time to come.
- pfranz 10y agoA few months ago I was at a conference where Qt representatives were saying something to the effect of, "We have completed development on Qt Widgets." They were very clear that there were no current plans to deprecate them. Just that no new development was planned. This was a conference for the VFX industry and the people in the room mainly wrote tools for 3d packages. So we had no interest in QML and just wanted native dialogs and widgets to automate things.
- joshuak 10y agoI'm from the VFX industry. I have a hard time understanding the logic of your last sentence. "just wanted native dialogs and widgets to automate things" is pretty much exactly the benefit of QML in the way I use it for production tools. It's certainly an improvement over multi platform compiling, and onerous build cycles or way out of date python integration. Quick, non-product oriented, tool development would in my mind be faster and easier to deliver to tight production timelines via an easy to edit document in a performance oriented declarative UI language over having to write fully compiled application UIs that are affectively hard coded. QML is a high performance easy to edit 'scene' file that is in effect a game engine level description for GUIs. Am I missing something?
- pfranz 10y agoI didn't mean in any way that QML was a worse solution than what qt4 offers. More that it's not accessible (not shipping along with current 3d software) so it is off the radar for most people. 6 months ago I was at a place where all code had to be compatible with Python 2.6 (we had moved off of Python2.5 only a year or so before). When I've looked at playing with PySide2 using Python2 I see that it's not there yet.[1] I feel like I'm in the minority of people I work with who have even seen Python3, let alone know what features it has. At my current place we don't compile anything. Most of the work I see are forms, running inside 3d software, that are basically arguments for a process...maybe read from a database or your local scene/environment. Designer UI files or hand-written UIs seem to be good enough for most people (it's way better than the alternative scripting UIs used before Qt). It needs to run inside and outside of Maya and other packages, which usually means is compatible with Python 2.6 and 2.7, likely need to support PyQt and PySide, and might need to work in Linux and Windows (ideally following that OS' conventions). Performance isn't a huge concern since loading the data takes way more than drawing the UI. Also, people are really averse to learning a new language. The understanding I had for qt5 was focusing on UI elements for alternate devices like cellphones and touch. While a lot more flexible, in many cases you'd have to reimplement normal UI widgets from lower-level pieces. At the same meeting, the few people familiar with QML were asking about getting a QML Tree View. I'm curious to know more about qt5, but like Python3, it's currently not an option. [1] https://github.com/PySide/pyside2/wiki https://github.com/PySide/pyside2/wiki