Developer access to native trays and panels and Developer ability to create and dock new trays and panels

I’d like that Extension Developers would be able to integrate their extensions better in the native Sketchup UI.

Sketchup relies on Extensions yet they feel, somehow, disconnected from Sketchup at an UI level.

Every extension developer has to reinvent the wheel, if the extension they are developing becomes too powerful.

Example:
When JBB developed Layers panel, instead of being able to extend the native layers panel with folders, he had to create a full UI for a new layers panel, he had to reproduce the existing functionality, design room for that and only then introduce the new functions he needed. Wouldn’t it have been wiser to have him add functionality to the native panel instead? Organizing layers in groups and subgroups, while keeping the same functionality…

I think that Sketchup should allow extension developers to:

  • Have access to dockable panels;
  • Extend the functionality of the existing panels by adding tabs, buttons, tick boxes and advanced features.
  • Modify the contents of the lists that appear on native panels panels, increasing thumbnails of content, allow for more info to show, extend left click and right click functionality, allow for new menu entries like buttons or tickboxes, and so on.

These should be allowed to happen and there should be safe methods for people get rid of the changes made by extensions, when uninstalling them, effectively resetting sketchup to the prior state.

1 Like

Personally I generally agree with you, but here I’m questioning it in details.
For example to access the dockable panels - Trays - would be nice (several times requested already).
But I would not allow to modify the native ones, but create a new .

BTW:
The “official chanel” where SU staff like to see the feature request is here:
https://github.com/SketchUp/api-issue-tracker/issues

Devs are already asked for similar improvements.
e.g.:
https://github.com/SketchUp/api-issue-tracker/issues/384
https://github.com/SketchUp/api-issue-tracker/issues/49

3 Likes

Alright then, duplicate the existing and modify them, simply by adding extra functionality or modules?

What doesn’t make sense to me is that, in order to improve trays, a developer as to create new trays redoing all tools that are already working properly.

Note:

The official Github channels for devs, seem to be a bit off from users. I actually have a github account, but I think this sort of discussion should be held here, with the community.

I can think of a few reasons why directly modifying the built-in trays could be difficult to implement and to manage.

For starters, what if two extensions added equivalent or incompatible items to the tray? It could become quite a mess! It could easily destabilize SketchUp as a whole!

I don’t know how the existing trays on Windows are programmed (I’m a Mac user). If they are done using the kind of technology employed by the Ruby API’s HtmlDialog (html, css, javascript) perhaps hooks for Ruby callbacks could be added. But if, as seems more likely, they are compiled C atop compiled Windows GUI libraries, there is likely no way for run-time code to intrude into them.

So, I think that it would indeed be necessary to come up with some way to provide a modifiable clone of the built-in tray that the extension developer could modify. This might require the extension developer to learn Windows GUI C programming - yet another language and library to deal with!

2 Likes

But if it would be possible, don’t you think that plugin development and integration into sketchup, would benefit a lot? I feel that, as a user, this would really fell more inline with the sketchup experience. Even with two monitors, it’s very difficult for me to deal with all the floating windows that plugins require.

At the same time, it feels awkard that we need whole plugins for managing the same stuff and then we get two layer managers, two scene managers, two or three component browsers, while most of these could be solved by just inserting a couple of specific features to the existing UI.

Of course I don’t know what your workflow is or how extensive your projects are and therefore how you need to work…

I don’t have any plugin toolbars visible or even native ones - I rely exclusively on keyboard shortcuts using AutoHotKey and a Streamdeck to extend the capability of shortcuts.

And with the new search it’s easier to find the less used plugin functions that you might need from time to time.

I agree.

The native GUI panels are meticulously laid out to account for local language localization.

The usability of the native GUI has a bearing upon Trimble’s ability to provide technical support and limited warranty for use of a commercial product.

They were based upon the old Microsoft Foundation Class C++ libraries.

The SketchUp Team has shown that they are migrating to cross-platform Qt libraries.
Although meant for C++ use, there are quite a range of Ruby gems that use Qt or provide Ruby bindings for Qt.

If it would be possible, I think that some developers and some already existing extensions would benefit a lot. I also think that a lot more development could arise from this as a lot of the development effort is probably concentrated in UI and not actual functionality. Adding functionality to an already existing UI, would probably easen that side of work.

1 Like

I might not be opposed to adding extension tabs to those inspector panels that have tabs.

1 Like

Within reason, that could a clean way to handle this idea. In many ways it is equivalent to adding menu items, though there are look and feel matters that menus don’t have.

2 Likes

I think that for most situations, adding a tab would be enough. But what about adding an extra tool to a panel, a tickbox or a search/filter box.

Every panel and their existing tabs, could have some extra space, like s roll down section, that would be active only when an extension required it in order to add a new function.

This is a very interesting topic. Forwarding it internally. :+1::+1:

2 Likes