Qt Creator API: Difference between revisions
Jump to navigation
Jump to search
(Created page with "Category:QtCS2023 ==Session Summary== ==Session Owners== ==Notes==") |
No edit summary |
||
Line 8: | Line 8: | ||
==Notes== | ==Notes== | ||
* Who wants it? Quick check of hands at Qt WS did not show much interest | |||
* History | |||
** 15 year ago, project inherited from Oslo ( Workbench / Greenhouse ) | |||
** Was meant as replacement for Widget Designer as its started to become IDE’ish | |||
** Was supposed to be bound to one platform, one Qt version | |||
** Eclipse was “the” thing at the time. | |||
*** Had problems with platform | |||
** Feature creep happened in Qt Creator | |||
** Social issues kept development compartmentalised | |||
* Since then lots of work has happened to correct mistakes of the past and make Qt Creator be more flexible | |||
* Bugs started to outpace development | |||
** “We need a stable api” | |||
* Currently its ok’ish for people who know the internals, but the code is not really great for outsiders | |||
* We were only able to get this far this quick because we were able to break apis often/regularly, e.g. Remote File Access for Docker and SSH | |||
* Process class is another example | |||
* As long as there is only 2-3 new plugins a year the status is ok, but if more are coming this will not scale | |||
* We have a lot of the components in place now that we need, e.g. TaskTree | |||
* A lot of effort is currently put into cleaning up all the parts of Qt Creator | |||
** Removal of Boilerplate stuff | |||
** Builder patterns for recurring things like ActionBuilder | |||
** Aspects | |||
*** Collections of things you need for Settings, e.g. Current value, old value, some widget, connections between widget and data, etc. | |||
* Plugins still have to be compiled | |||
** Python POC was created 2019 | |||
** Problems: | |||
*** Language barrier has to be crossed | |||
**** Mapping between C++ and python needs to be maintained | |||
** QtScript? | |||
* Qt Creator is built against “some” publicly available Qt Version | |||
* Qt Design Studio is just a set of plugins | |||
* As long as we let people access all other plugins is basically impossible to provide a stable API | |||
** Provide a specific set of classes as API |
Latest revision as of 15:36, 30 November 2023
Session Summary
Session Owners
Notes
- Who wants it? Quick check of hands at Qt WS did not show much interest
- History
- 15 year ago, project inherited from Oslo ( Workbench / Greenhouse )
- Was meant as replacement for Widget Designer as its started to become IDE’ish
- Was supposed to be bound to one platform, one Qt version
- Eclipse was “the” thing at the time.
- Had problems with platform
- Feature creep happened in Qt Creator
- Social issues kept development compartmentalised
- Since then lots of work has happened to correct mistakes of the past and make Qt Creator be more flexible
- Bugs started to outpace development
- “We need a stable api”
- Currently its ok’ish for people who know the internals, but the code is not really great for outsiders
- We were only able to get this far this quick because we were able to break apis often/regularly, e.g. Remote File Access for Docker and SSH
- Process class is another example
- As long as there is only 2-3 new plugins a year the status is ok, but if more are coming this will not scale
- We have a lot of the components in place now that we need, e.g. TaskTree
- A lot of effort is currently put into cleaning up all the parts of Qt Creator
- Removal of Boilerplate stuff
- Builder patterns for recurring things like ActionBuilder
- Aspects
- Collections of things you need for Settings, e.g. Current value, old value, some widget, connections between widget and data, etc.
- Plugins still have to be compiled
- Python POC was created 2019
- Problems:
- Language barrier has to be crossed
- Mapping between C++ and python needs to be maintained
- Language barrier has to be crossed
- QtScript?
- Qt Creator is built against “some” publicly available Qt Version
- Qt Design Studio is just a set of plugins
- As long as we let people access all other plugins is basically impossible to provide a stable API
- Provide a specific set of classes as API