Blocs 3.4.6 beta Build 4

Hey everyone,

I’ve just pushed Blocs 3.4.6 beta build 4. This release, is again, all about stability with a range of bug fixes and minor improvements.

Blocs v3.4.6 will go live early next week.

Download Blocs 3.4.6 Beta Build 4

6 Likes

Great with a new Beta, Norm. I just tested the issues I’ve had before, no change so far…

Hi @Norm

Beta 4 has improved things with regard to Margin and Padding field data, but Blocs is still selectively hiding data. Consider this screenshot (LG breakpoint)…

I am holding down the SHIFT key while clicking the bottom tab of the selected text item, and the blue part beneath it is showing that a Bottom Margin exists. (You can also see each line in that numbered list is also separated by the same bottom margin.) And yet, the Class Editor shows Padding and Margin are BLANK for the bottom margin! That is clearly a bug.

A Margin clearly exists, but the Class Editor is hiding that data. This is nothing new. I am just saying that this sort of problem still exists in Beta 4. Oh, and when I check in the smaller breakpoints which had the bottom Margin set to 0, then and only then Class Editor starts to show me that data in the Margin field…

Lastly, to my fellow Beta testers, I appeal to you to please test Padding and Margin field data across all breakpoints. If you know a Padding or Margin exists but isn’t showing up in the Padding and Margin fields in Class Editor, please report it.

Thanks.

@JDW. I can not replicate that issue sorry (unless I am doing it wrong?)

Norm beat me too it below, But I was going to mention that overriding nature of classes, and multiple classes. You will be able to work out what classes are applying in Safari’s Inspector.

Is the padding and margin value assigned to the class you have open in the Class Editor?

Remember items can have multiple classes so values will only show in the class editor for the selected class, if a second class or a margin is assigned in the sidebar it will display margin space on the free hand control but not in the class editor as it’s not a value stored in that specific class.

The Class Editor doesn’t show all values for an item, it shows all values for the selected class.

1 Like

Yes this is still being worked on.

My screenshots show everything. You can see the left sidebar which shows the selected item and it’s only class, and that single class you can see open in the Class Editor. So unless Blocs assigns a hidden class that I cannot see, what you see in my screenshot is all you get. And yet, as I said in my previous post, you can clear see a bottom margin in the screenshot (LG breakpoint), yet the Class Editor shows the Margin field to be blank.

This is something that has been driving me mad for as long as I’ve used Blocs, actually. It’s utterly impossible that I alone am experiencing this. Not a chance.

Again, look closely at the screen shots in my previous post. There is no class assigned to the parent List item at all. And there is only that one class “p-2698-margin-bottom” assigned to the lone paragraph inside that List item. Yet the Margin field for BOTTOM margin is blank in LG. But then when I switch to any of the lower breakpoints, the Margin field contains “0” which is correct. So Blocs is telling me the truth in every breakpoint except LG, for reasons unknown. That is the bug.

Ok, thanks!

@Norm, I think @JDW is talking about the default spacing between the ul and ol items maybe?

Because you can use Blocs to drag that to 0 margin.

I actually don’t know what sets them in the first place, I can’t see any classes that do it? Its obviously a bootstrap thing??

if You remove the only class on the object does it still have the margin on the bottom?

If it does the value is being inherited from either bootstrap of a class further up the chain.

Could you let me know which gives you broken results please.

  1. Package project on external drive then move to main local Mac HD and open.

  2. Package project on external drive then move to new location on same drive and open.

  3. Package project on external drive then move to another external drive and open.

  4. Package project on main Mac HD then move to an external drive and open.

I think the outstanding issues are coming from those situations that use external drives.

In this case number 2.

Note 1: In this case, before generating the Package to the external Drive (here named “S1”) the project was originally stored on another external HD, here named “S3”.

Note 2: “Internal” or “external” drives, should that really matter, shouldn’t Blocs just adjust the “path” to where the Package is generated, shouldn’t it just point to the correct “path” wherever that is?

So the others work?

Note 3. It does matter to the OS, it’s a security issue with a component Blocs users to generate the design canvas. It’s super annoying but it’s just the way it is devs need to work around it.

To rephrase this, let’s call them additional drives that don’t have the core OS and file system on them.

As I hope is visible in the video, the original (in this case all files placed on an external drive named S3) works very well and when choosing “Show In Finder” it for sure points to the correct/current path for the images/assets.

After “Generate Package”, to whatever disk – internal or external I suppose – the paths will get wrong.

Should I test also this?

Hi all,

I just noticed a minor issue that affects 3.4.6 beta4 as well as 3.4.5. If I open a project and only change a project setting (say disable Lazy Load) and then do a project Save, the updated setting is not saved. If I do a Save-As for the project, the updated setting will be saved.

Just wanted to mention in case this can be fixed for the next beta.

Thx.

pruthe

1 Like

Are you actually saving before quitting? I wonder if this is the reminder not prompting you to save after making a change to the settings. That’s something I have seen in earlier versions of Blocs.

So no matter what you do if you generate a package regardless of location the links are always wrong.

Have you tried with a new project with a few assets thrown in just to rule out it being specific to that project.

Just also tested this:

  1. “Generate Package” from original, external disk (Disk named “S3”) to a new folder on the same disk. Result: All worked perfect/all paths etc OK!

  2. “Generate Package” from original, external disk (Disk named “S3”) to one of the internal disks (in this case OSX system disk). Result: All worked perfect/all paths etc OK!

1 Like

So the only time it breaks is when you generate to a second external drive.