On the original message, highlight what you want to quote. A “quote reply” popup should appear, and if you click it a new reply window will open with the quoted passages already inserted for you.
Basically,… one needs to also look at the API Release Notes page as well as the Application Release Notes, to understand the full scope of work, that actually happened.
This past (2016) cycle was a very “special” cycle:
The major visible change (feature) was the introductory implementation of the Microsoft tray system for inspector dialogs. (LayOut was introduced with it. But it has been a long time in coming for SketchUp, where the floating “snappy” toolwindows never worked at 100%. They’d eventually lose track of their stack origin, and get shuffled in their stacking order, despite repeated attempts in each cycle to fix the bug.)
But the a lot of the work was “under the hood” and “behind the scenes”.
A major overhaul of the API observer sub-system for stability.
Major implementations and additons within the ongoing C API project.
The initial release of the LayOut C API.
Introduction of Ruby extension encryption v2.
Part 1 of High DPI display support, ie, toolbar icons and cursors. (Coming in Part 2 should be drawing area support for tool drawing, inference dots and and tooltips.)
Major overhaul of the inferencing engine and how the native toolset works with it.
Likewise, the previous (2015) cycle also had a lot of “engine” work done:
The introductory release of 64-bit editions for MS Windows platforms.
Extension licensing. Application “cloud” licensing.
Then, in the 2014 cycle was a massive overhaul of the API from Ruby 1.8 to 2.0.
- Introduction of the Classifier system.
This is the most important (and profound) thing that has been said here on the forums, regarding SketchUp development and maintenance, in a long time.
It is definately very informative to the public, in understanding the Trimble in-house development philosophy for maintaining SketchUp.
(IMO, it should be quoted or pasted into this forum’s header “intro” post.)
It again reminds me of a “promise” made by Tyler Miller, Engineering Director at SketchUp, (some years and cycles ago,) that they would try their best in Boulder to avoid the traps of “feature creep” with the SketchUp application.
Everyone (who posts a feature request) should first be made to read the following wikipedia article:
No more new features?
Main Limitations of Dynamic Components
So, having assumed you (the reader) has now read this article on “feature creep”,…
Where do you think SketchUp is in it’s lifecycle ?
What kinds or types of feature requests should be accepted as core features ?
What kinds or types of feature requests should be rejected as extra-core features ?
Has the switch to subscription based releases, helped or hindered with regard to avoiding “feature creep” ?
Yes, Dan you are correct. Sometimes we do not really get to see/appreciate all that goes on behind the scenes. My real preference would be for them to continue working on the engine to improve performance. There are tons of external tools to do most everything.
It might be that English is not my native language, but the the post that Tommy opens this thread with reads to me as a warning that we cannot expect the coming releases of SketchUp to bring about any essentially new features but only minor bug fixes. Has SketchUp passed the apex of its development path? Is it on the decline?
One could read it that way. Nothing personal, but I hope you are wrong .
To me it sounds more as if we can still expect some new features (so not only bug fixes). But only if they fit into the program that was originally intended as (sort of quoted) simple yet powerful.
My suggestion as a new feature would be two (or even three) section planes per context, planes in any direction, not only parallel.
I hope I am wrong too…
But the goal of the simple basic core pre-dated the Pro editions. I think it is more a warning to the host of requests to add non-core features to the Make editions.
Look through this forum and you’ll see requests by Free/Make users to add Pro features into Make (like SolidTools.). When prompted they admit that no, they do not want to pay for them.
So a main point in Tommy’s OP is that many requests must be implemented as extensions, rather than core features. What ratio? The wiki on feature creep mentions a “80/20 rule” (core/extension.) But I think we’ve reached the point that those numbers are reversed. Ie, 80% of SketchUp feature requests should be satisfied by extensions (or external utilities.) Perhaps only 20% can be seriously considered for core feature implementation.
to me the strength of a spreadsheet program is the ability to customise it to ones specific needs. So the VBA ide in excel with the use of user forms provides a safe and fairly easy way of creating solutions. As such within a period of five years I was able to compile a AutoCad / Excel solution to do layouts and takeoffs which enabled be to do accurate projects in a shorter time. (that was 10 years ago, and I am using the same with little change, howbeit 2D)
This feature is what ruby is for Sketchup? but where are the inbuilt forms, programing interface? it seems the same as its always been, a ruby console and a very limited userform. Then we are directed towards java script…
I believe if there is need to offset the “features” to extensions then make that environment as easy to use as sketchup itself with some Macro features, userforms…coding ide.
I would like to do my work in 3D using Sketchup and Layout
I also vote for a native section tool extended to solid-group.
As to keep it simple, it should render solid-sections only on solid-groups.
No need to implement additionnal contextual window for the optional material render style of the solid group, just use the same paramaters as cut-edge color, in style option. The advanced options to choose special material on sections are naturally an extension…
One other request : it could be really cool to enable easy partial section (only one side of a symetry axis for example), broken section (X parallels planes), and pie section by :
- Right click on a section plane, to acces to context menu option “divide section plane”
- Select, then move one side to make a broken section
2b) Select, then rotate one side to make a pie section
2c) Select, then delete one side to make a partial section…
In fact I am often making big buildings model, with lot of groups.
It appears that making a pie section within a big construction tree is really awfull.
If I want a clean and flexible result, I do multiple copy of the groups and various section cuts within… And if I want it quick, I use Zorro, erase, and then cleanup, but it’s still dirty work and destructive modeling…
A better section tool could really be usefull.
Please integrate VR module