Community based Dialog framework?

Developers Ruby API
1

For many years I’ve thought that a community (and possibly Trimble) supported framework for dialogs would be very helpful.

Three main reasons come to mind. First, (and not based on any hard data), I think about all the duplicated code that exists when people have multiple plugins loaded. Secondly, I’m sure many plugin authors, although intelligent people, are not familiar with the OOP concepts that a good, full featured framework could be based on. Third, using dialogs requires javascript, so one must be fluent in two languages. I’ve programmed for a long time, and I still get tripped up when moving between languages…

So, the framwork would contain ruby, javascript, and css files, and a few sample (or tutorial) html dialog files that could be used as starting templates for plugin authors.

Background

Over the years, I’ve done quite a bit of html/js, including multi-column grids/tables with embedded radio, checkbox and text controls. I didn’t keep track, but I believe I rewrote almost all of the js used on File: SketchUp Ruby API — SketchUp Ruby API main, along with removing JQuery. So, at the minimum, I’m familiar with js. Also, years ago I started on a very involved SU dialog framework, and somewhat recently I wrote a simpler one.

When SU 8 was the current version, I started on some code for my own use, with one export dialog box. Two commercial companies then added it to their software. I think the final version had eight dialogs, two of which mimicked the SU layers & materials panes. Features like font-size, hide/show additional controls, added metadata, etc. Some dialogs were modal, others non-modal.

I mention this because I made more than a few revisions that dealt with creating more shared code (and removing duplicated code) from all my dialog code.

Initial Main Goals

  1. Wrap most the communication between a plugin and dialog boxes with an API.

Contrived example of SU → Dialog communication

MyDialog.checkboxes[:Transparent].checked = false
MyDialog.radios[:ColorBy].selected = :Layer
MyDialog.update                                # performs execute script
  1. Have code to make it easier to deal with:
    • MacOS vs Windows
    • WebDialog vs HTMLDialog
    • Changes between versions of SU (limit to?)

Long Term:

Other items that might be added to the framework could be handling of app settings, observers, etc.

Re observers, I recall creating a class for RenderingOptionsObserver that allowed registering callbacks based on a subset of options. If something like this was available, the framework could have one RenderingOptionsObserver, and call multiple plugins only when an option they were concerned about changed.

Any code that is likely to be duplicated across plugins could be considered for inclusion in the framework.

Misc

There are many js frameworks available, with many purposes. In a plugin, we are creating pc application windows, not web pages viewable on multiple devices. We also are not connnecting to a web server. Hence, I do not see a need to include a traditional js framework in a SketchUp framework.

Elephant in the room. I’m sure everyone would appreciate Dan and Thomas’s participation, but I’m not sure if they can help with something designed to work with as many versions of SketchUp as possible.

At present, I’m a windows only coder. I would need help with MacOS.

Anyone interested in helping?

3 Likes
2

I’m absolutely interested in this! Maybe @thomthom is too. We’ve been talking a little about this topic recently. There’s no need for every developer to reinvent the wheel!

3

I’m interested if it’s ‘lazy loading’ and uses vanilla js and css…

but, I’m only keen on HtmlDialogs and the single CEF… i.e. not IE woes

john

4

Good idea. Almost a year ago, as Steve Baumgartner (@slbaumgartner) and I were nearly finished on the Angular Dimension 2 plugin, I hoped to start such a project myself, based largely on Steve’s work for the WebDialogs in that plugin.

But most of my SU time since then has gone on helping Scott Baker on his RiverArch project so I have not had the opportunity to get started on it.

5
  1. Lazy loading is up to the people using it.
  2. If my doc site works with ‘vanilla js and css’, this certainly can.
  3. Re HtmlDialogs, I really feel that doing both won’t drastically increase the code base, and may increase adoption, both of the framework, and of HtmlDialogs.
  4. Re IE, I’ll get it to work.

@thomthom == Thomas

I didn’t make clear, but I’m envisioning this as a ruby & Javascript tool. What css and html is included would just be samples and possibly ‘suggested best practices’. I assume there are several, free html layout tools available for people who need help with that. But, we might include an API allowing different css to be loaded dependent on the platform, version, and dialog type.

Last question. I assume we’ll develop this in GitHub repo and symlink into SU. Where should we talk about it more? Continue here for a bit, or go elsewhere?

6

How will this differ from what Thomas Thomassen has already started ?

1 Like
7

Dan,

I haven’t looked at ThomThom’s framework for a while, but thanks for the reminder to review it more thoroughly.

  1. I don’t want this to be an html layout tool. If people are writing plugins for a graphical CAD package, they’ve probably done something with html, and they’ve probably worked with a few media layout apps. Also, there are probably plenty of free tools to help with that task.

  2. It uses JQuery. I really don’t see a need for that with this framework. I could go on for a while about people misusing JQuery, about how it became popular when browsers were a lot less compatible than they are now, etc, etc. I’ll admit that some of my bias is based on issues that are unlikely to exist with most people’s SU dialogs. Lastly, if I can get my doc site to work on Chrome, Firefox, IE11, and IOS Safari without JQuery, I don’t think SU dialogs need it.

  3. I commend ThomThom for starting it, but it never gained much support. I don’t know if this will go anywhere, but at least we can try to get it off the ground.

  4. This is really about one thing and one thing only - providing the code needed (ruby & js) to shield users from all the issues with moving data back and forth between dialogs and ruby. I suspect that many people will not have to write a single line of js to get their dialogs working with this framework.

For all I know, once a few of us start discussing this, we’ll discover that our needs are so different that we can’t fit them into one framework. For now, I’m betting against that…

8

I moved away from SKUI - because it became apparent that it quickly got very complex to support anything other than the most basic controls.

There was also the challenge of how to bundle and package it easily.

As of late I’ve moved to rely more on existing frameworks from the dev-dev world. UI frameworks for the layout and data binding frameworks for the data handling.

At DevCamp 2017 I demoed how to create dialogs with Semantic UI and Vue: GitHub - SketchUp/htmldialog-examples: Examples of using SketchUp Ruby API's UI::HtmlDialog class

The exact framework isn’t that important - they all have similar concepts.

UI frameworks like Semantic UI, Foundation and Bootstrap all provide tried and tested boilerplate layout and widgets. Usually you just need to add some classes to your HTML. (Bootstrap even have an online tool to customize the default theme)

Data binding frameworks like Vue, React and Angular let you very efficiently bind data to the view. As you can see in the examples, the data is stored in a central place in the JS vue app instance. Vue is then taking care of all the dirty work of manipulating the DOM.

I find this to be a more flexible solution, as it uses the tools that the web industry is already using. And you should be able to get up and running rather quickly.

We (the Extensibility Team) have been talking about working with our UX/UI team in making available a boilerplate version of one or two of the most popular UI framework customized to fit SketchUp’s own styleguide (which is currently being worked on). This, along with examples, would allow extension developers to quickly scaffold complex UIs in relative short time that have a consistent feel to SU itself.

In addition to the DevCamp examples we released a couple of weeks ago another example of how one could use UI::HtmlDialog to replace UI.inputbox: GitHub - SketchUp/htmldialog-inputbox: UI::HtmlDialog example recreating UI.inputbox functionality in the SketchUp Ruby API

It uses Vue and Bootstrap and demonstrate how to move data to and from the dialog.

4 Likes
9

@tt_su, Page not Found for the last link…

john

10

Ooops! it was still marked as private. Ok… now it’s published!

1 Like
11

Htmldialog-inputbox looks quite useful! I didn’t know show_modal paused the calling method from being finished. I thought you hade to yield the resulting value to a block, not return it, when using HtmlDialogs.

12

This is great, especially ability to achieve “consistent feel to SU itself”. UI would look far more serious and professional if it would become more unified.
What about handling of communication between Ruby and UI::HtmlDialog (are mentioned above frameworks able to handle asynchronous communication somehow)?

13

This only works on both platforms for UI::HtmlDialog. With the old UI::WebDialog class “modal” wasn’t really modal.

Web technologies are in large part asynchronous - so there are tools out here to handle that. Look at promises etc.

In general I find the communication to not be a huge challenge - at least if you keep business logic in Ruby and use the HTML/JS side for presentation.

1 Like
14

Yes in case if all logic is limited to a Ruby part, then type of communication is not a huge deal obviously. In case if developer needs a dialog for a bit more complex purpose, than just a presentation (for example dynamic generation/refreshing of dialog’s content with an information from an active model after user input from that same dailog is needed for some reason), than communication appears to be challenging though (I would even say “critical”).
Or in other words for some certain tasks feels like it can be more challenging (or even impossible) to implement all logic in Ruby such a way that there would be no need at all in synchronous communication with a dialog. Or maybe I’m just missing something.
[UPD]
In general (as far as I understand the situation) asynchronous communication/messaging is needed in distributed environments such as the cloud. It enables applications and services to communicate and cooperate and obviously requires implementation of a more complex logic (message queue). Seems like there are still a lot of simple tasks in a desktop application, which don’t require separate implementation of two processes (the process that implements the service and the process that consumes a service). But UI::HtmlDialog forces developers to employ such complex strategy even for some maybe trivial tasks.
Anyway I hoped that maybe existing frameworks mentioned earlier already have message queue implementation so there would be no need for extension developer to code it by himself/herself (that’s what my question in a previous reply was about actually).

15

I’d really recommend looking into something like Vue or React to bind data. If you look at the examples we have it demonstrates how to push data from Ruby to the dialog. Then using Vue templates bound to the data there is minimal work to update the UI. When you need user input you just bind the input to change your data and push it back to Ruby.

This is related to Chromium where everything is async.

Promises can help with async stuff.

And more recently the async await pattern

(Though I’ve not used them myself in a webdialog - never really had the need.)

16

Thanks for links to additional resources. I was able to code my own tiny message queue for UI::HtmlDialog and it seems to work fine both under win and OS X. But I would be really happy if this logic would be shipped somehow with SketchUp itself and I would be able just to use some ready made solution coded by professionals.
Speaking of sync/async the main reason for controversy I think is that Ruby code runs in a general case such a way, that it takes/freezes SketchUp until code is not finished (sort of synchronously). So seems like currently Ruby part in SketchUp is not a “process that implements the service” by definition, but UI::HtmlDialog appears to be a part that “consumes the service”. And as for me personally it is a some sort of inconsistency in logic (if I understand all that stuff correctly).

17

Do you have an example of where communication is a challenge? I think it would be easier to have some concrete code to talk about. Otherwise it’s easy for us to inadvertently talk about different things.

18

The point is that I have some certain pieces of code (spreaded here and there in my extensions) in Ruby and in JS parts, which were coded some time ago with synchronous communication in mind (or it’s better to say without asynchronous in mind). It is not easy to quickly isolate, those parts unfortunately. Partially this is the reason why it was easier to code message queue, than redesign all that old logic. I’ll try to find and expose some example, but it may take a while.
For now as I’ve came up with an implementation of a message queue it is not a problem or challenge for me personally. I’m just not sure about my own implementation (it just seems to work fine according to my own observations), but I’m not sure that it is implemented correctly and for example has all necessary fallbacks for all special cases or errors, which may take place in queue. That’s the reason why I would be totally happy to use some ready made solution from professional coders.

19

For many years, ‘coding’ was always something I was paid for, but it wasn’t one of my main job responsibilities. Hence, I’ve never coded full-time. Also, I’ve created real code in several languages.

I mention this because I can’t help but believe that many of the people creating plugins do so intermittently. They, like me, are not coding fulltime with the SU API, Ruby, and JS, and, they may be working with other languages.

When it comes to SU dialogs (especially if one has to maintain WebDialog compatibility), and you’ve not used any of those three for a while, (along with the platform async issues, etc), writing plugin code brings one back to reference material and google.

Because of this, I’d like to see a dialog framework with as minimal a ‘burden of entry’ as possible. Hence, I’d prefer it did not have a javascript library used for it.

I’ll look over my past code and get a demo that shows the general concept of the type of framework I’m thinking of. It will probably be a GitHub repo that you can symlink to from your plugins folder.

I may not have been clear, but my preference is to have the framework handle as much communication as possible between the dialog and SU. IOW, the coder does not have to write event code in js, nor callbacks in SU. They would just need to write a method like

def ui_change(info)
# …
end

Where info is a defined structure with info about the UI action. Something similar could be done for execute_script to allow dialog state changes.

Be careful what you call people…

Thanks, Greg

20

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.