For now the startup s executed after the LayoutWindow created. But I think that

Ok.... so: The current start-up sequence is: Register all plug

The why is probably best a question for <a class="user-mention notranslate" data-h

I found this when I try to create -based primitive provider as a demo for <a cla

in LayoutWindow... <div class="snippet-clipboard-content notranslate position-rela

Probably bad Startup Scripts execution order about artofillusion HOT 11 OPEN

makiam commented on September 22, 2024

Probably bad Startup Scripts execution order

from artofillusion.

Comments (11)

peteihis commented on September 22, 2024

Ok.... so: The current start-up sequence is:

Register all plugins
Run all APPLICATION_STARTING parts of the registered plugins
Open files in args
Run start-up scripts
Open an empty scene if none were opened from args.

I did a little testing. Added an APPLICATION_STARTING bit in a start up script just writing a note to System.out. That part is missed in both cases, 3. and 5.

The I moved the 4. (line 177) right after 1. Now the APPLICATION_STARTING note appears in System.out.

I'm just wondering if there has been a reason to build it the way it is? Apparently start-up scripts have not been expected to make changes to the core program and it seems intentional that start up scripts are not applied on files that were given as arguments.

from artofillusion.

Sailsman63 commented on September 22, 2024

The why is probably best a question for
@peastman . The closest thing I can figure is that some startup scripts might do stuff like play with view settings, add or remove default objects, etc, and that should not be done to existing scenes. (Remember the one that's been floating around SF for years to remove the default light? It just grabs the first light in the scene...)

While it is possible to register a plugin from a startup script, it's always been best used for simple things, not stuff that requires setup on launch, etc.

from artofillusion.

peastman commented on September 22, 2024

You think I remember exactly why I did it that way after this many years? :) Possibly it didn't even occur to me someone would use a startup script to register a plugin. There's also the argument that a startup script might want to use a plugin. It can't do that if plugins haven't been registered. I would generally think of a plugin as "lower level" than a script, so I'd expect plugins to be registered before scripts are run, not the other way around.

from artofillusion.

Sailsman63 commented on September 22, 2024

You think I remember exactly why I did it that way after this many years? :)

It was worth checking, at least... :D

I tend to agree - startup scripts are for configuration and prototyping, not for full-scale plugins.

from artofillusion.

peastman commented on September 22, 2024

There's no reason you couldn't write a full plugin as a startup script. You just need to remember that APPLICATION_STARTING won't be called, because it's already past that stage by the time you register it.

from artofillusion.

makiam commented on September 22, 2024

I found this when I try to create script-based primitive provider as a demo for #322. The idea was to create and register script which implements PrimitiveFactory. Plugin can be registered but already created window known nothing about it.
Same way if I create and register Modelling tool it also will not visible for first created LayoutWindow

from artofillusion.

peteihis commented on September 22, 2024

Plugin can be registered but already created window known nothing about it.

As I recall plugins usually (or often) do their work on classes, like LayoutWindow.class, not the already exiting instances, but AFAIK nothing should prevent you from adding a plugin into an existing instance like window:

At least this works, call it NewDemoTool.groovy:

PluginRegistry.registerPlugin(new Plugin() 
{
    EditingWindow window;
    void processMessage(int message, Object[] args)
    {
        if (message == Plugin.SCENE_WINDOW_CREATED)
        {
            BMenuItem newDemoTool = new BMenuItem("New Demo Tool");
            newDemoTool.addEventLink(CommandEvent.class, this, "pop");

            window = (EditingWindow)args[0];
            window.getToolsMenu().add(newDemoTool);
        }
    }
    
    void pop()
    {
        BDialog pop = new BDialog("New Demo Tool");
        pop.addEventLink(WindowClosingEvent.class, pop, "dispose")
        pop.setContent(new BLabel("<html>New Demo Tool<br>Close by X</html>"));
        pop.pack();
        pop.setVisible(true);
    }
});

I'm just wondering if it would be possible to run a check on StartUp scripts and notify the user if they are trying to use APPLICATION_STARTING? I have a fading memory, that ran into this some time ago too. I was working on some default settings but I don't remember exactly what my idea was at the time...

from artofillusion.

makiam commented on September 22, 2024

in LayoutWindow...

private void createToolsMenu() {
modellingTools = PluginRegistry.getPlugins(ModellingTool.class);

in some script

PluginRegistry.registerPlugin(new ModellingTool() {
....
}

so none of already opened scenes will not take in account this new Tool

from artofillusion.

peteihis commented on September 22, 2024

so none of already opened scenes will not take in account this new Tool

What?

The "NewDemoTool.groovy" is a StartUp-script. If you had it in place and opened some scenes, it already did its job on those scene windows. If you then open another scene, it won't, can't, should not and must not go back and start to work on the already opened windows AGAIN !

If you want a script that does something to several open scenes, you can call ArtOfIlllusion.getWindows() to find the scene windows in the same java session. (Or so I think, correct if wrong. :) )

from artofillusion.

makiam commented on September 22, 2024

Take a deeper look at Application startup code. There a part where Layout Windows opens from command line arguments and this script based plugin may respond on this windows creation event or may not, because of threading race. (The layouts creates in separate EDT thread)

but if no Scene arguments passed via command line event response is OK.

from artofillusion.

peteihis commented on September 22, 2024

... from command line arguments and this script based plugin may respond on this windows creation event or may not ...

Ok, that's what you meant!

Yes. Just as you say above. When I tested (one time only) command line start with argument, the start-up script took effect, against my expectation. The code suggests that the scripts are ran after the scenes are read, but that was not the case at least that time.

The issue here is that on command line start you'd probably want the scripts to make changes to the UI (e.g. adjust the widow size) but you probably would not want start-up to make changes to the old scenes. Then again you might want to change something in an entirely new scene.

This may be something to look at but I don't see how to make it waterproof with the current building blocks.

from artofillusion.

Probably bad Startup Scripts execution order about artofillusion HOT 11 OPEN

Comments (11)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent