Screenshots of the upcoming "designer scripts" feature

[Erel]

The next version will include a new feature named "designer scripts".

This is really a new feature. I'm not familiar with any IDE (Visual Studio, Eclipse, etc...) that includes such a feature.

The visual designer includes two modes: regular mode and script mode.
In script mode the visual designer allows you to write code and immediately see the results on both the abstract designer and the emulator / connected device (there is no need to compile your application and reinstall it).

The idea is to create the "rough" layout with the visual designer and then add the "fine tunings" with the more powerful and flexible script code.

The script engine is quite simple however it well serves its purpose to allow you to easily adjust the layout.

The abstract designer together with the scripts engine allow you to easily and quickly test your layout on different screens and resolutions.

Another advantage of this feature is better separation between the UI code / design and the logic code.

When the program is compiled the scripts are compiled together with the rest of the program.

I will write more about this new feature before the release.

Just to demonstrate it, lets assume that we want to build a layout with an EditText and two buttons at the bottom of the screen. The buttons are attached to the right side and the EditText view fills the entire available width.

The first screenshot shows the "rough" layout on a Galaxy Nexus and the standard phone layout:

In the second screenshot the designer is in "script mode":

You can see that the views are now located in exactly the correct position. We can choose different layouts in the abstract designer and immediately see how our layout will look on other screens.

 

[corwin42]

The quote you mention is from this thread. It has nothing to do with Z-order.

 

[Erel]

1. Is it possible to change other properties of views like the visibility? So it would be possible to hide some controls for smartphone size layouts an display them on tablets? This would be very nice.

Yes. It will include other properties as well (though not all of the properties). Text, visible image and others will be included.

2. I think this won't work with homescreen widgets. For better support of different screen sizes in widgets do you still have the first wish from this thread on your todo list? I think it shouldn't be too hard to implement.

It will not work with home screen widgets. I don't think that this feature will be implemented in the next version.

I do not see how this will solve the Z-Order issue? The code would appear to operate after the designed has added the views.

As corwin42 wrote, the quote you posted is not related to z-order.

 

[susu]

Yes. It will include other properties as well (though not all of the properties). Text, visible image and others will be included.

Just to be clear, it means I can use different images for different layout variants? For example: I can use "biglogo.png" for 800x600 layout and "smalllogo.png" for 240x320 layout (of course for the same imageview). If it's true, I will kiss you Erel

 

[Erel]

If it's true, I will kiss you Erel

It is true for ImageView. FontSize is also supported.

 

[COBRASoft]

Looks great...

 

[Smee]

This looks BRILLIANT!!!!!

 

[Jost aus Soest]

A dream comes true!

This makes developing display independent apps much easier! :sign0098:

 

[Penko]

Erel, that gets the B4A level higher Looking forward to receiving it.

P.S According to my understanding, we design the layout so it somehow corresponds to our idea and then use the designer scripts to to do fine tuning relative to other items? I am asking because your example is based on two buttons and they are dependent each other.

 

[Erel]

You understood correctly.

 

[pluton]

This is awesome. Can't wait to test it.

Great job Erel

 

[WizardOz]

Just to be clear, it means I can use different images for different layout variants? For example: I can use "biglogo.png" for 800x600 layout and "smalllogo.png" for 240x320 layout (of course for the same imageview).

And Erel said yes! I think I will put myself in a plane this minute and give Erel a real manly hug as soon as possible! I will actually put the design-portion of my new projects on hold because of this, because this update will be BIG!!!

Love you, Erel! :sign0098:

 

[Kevin]

I'm curious if this "script" will then be transformed into code that is added to the project and run behind the scenes (i.e. it will add code to the project but we will never see it in its finished state)? I assume it is this, because if we were able to further edit the code then it would break what the script is telling it to do. Assuming it is this though, if we have existing code that tweaks layouts, then which would be executed last? Could they conflict with each other?

The other alternative I can think of is that it would be used to generate fixed values for fixed layout variants but this seems unlikely since B4A cannot predict future layout variants any more than we can, unless it only tweaks the layout (generates fixed layout variants) for the variants contained in the layout.

No matter how it works, I think this will be a wonderful addition, but I don't see me rushing to change over my current existing project since it took me far too long to get it coded right and I'm not going through that again. I will definitely use this on future projects though!

 

[droman]

Looks Great!!

 

[Erel]

During compilation the scripts are compiled to java code. This code will not interfere with your code. The layout is first built and then the compiled scripts run (first the general script and then the variant specific script - if such exists).

The scripts are compiled to methods that expect three parameters: parent width, parent height and scale.

Note that %x and %y behave slightly different than in the regular code. In the regular code these units are always relative to the activity. In the script code these values are relative to the main parent. So if you call Panel1.LoadLayout then they will be relative to Panel1.

It is also possible that there will be a new method that will allow you to rerun the script code. This can be useful in cases where the available size changes but the activity is not recreated. For example when the keyboard becomes visible.