progress bar inspector horiz/vert

[gcasa]

While changing definite/indefinite triggers a visual update, horizontal/vertical seems to have no effect.
Originally submitted by @rmottola https://savannah.gnu.org/bugs/?58173

[gcasa]

This issue appears to be a GUI issue as the object is changing state.

[rmottola]

• I debugged, by checking drawRect and setVertical in NSProgressIndicator. setVertical does not get called on toggling the "vertical" checkbox in the palette, so no event is sent to it and no state is changed.
• Opening the GormNSProgressIndicatorInspector.gorm file looks pefect, "ok:" is connected as action and vertical is connected to the NSOwner.
• I disconnected and reconnected the ok: action, no change
• I remove the NSButton from the inspector, redo all connection -> it works (but looks the same)

[gcasa]

This should now work. Thanks! :)

[rmottola]

@gcasa but whats broken? it looked fine!

[gcasa]

Huh?? I took your changes.

[gcasa]

Oh... I misread this. In old .gorm files there was an issue with connections. Some things were being persisted that shou.dn't have. My guess is that it was setting some older settings that didn't need to be there. This was particularly true with target action data which is established AFTER the nib/gorm/xib is loaded in an application OUTSIDE of Gorm/InterfaceBuilder. I haven't researched the .gorm in this case, but my best guess is the above as I had seen this OVER AND OVER before. Why I thought it was GUI is beyond me.

Just FYI, I tested it and it looks perfect. Thanks for catching this. :)

[gcasa]

For further explanation... the model loading process is THUS, for an application:

• Read the data
• determine which kind of model (nib/gorm/xib/gmodel)
• Unarchive (respecting substitute classes/when loading in Gorm there are some proxies used)
• establish connections (if we are NOT in IB/Gorm)
• call awakeFromNib (if we are NOT in IB/Gorm) ... this is why there is a method called isInInterfaceBuilder

The issue with this gorm file was (likely) that when the data was archived the NSButton for changing the NSProgressIndicator's vertical status was archiving target/action data. This data probably overode or caused an issue when establishing the connections.

Nevertheless, I think chasing this down too much is going down a rabbit hole. So, if it happens again, I will take a deeper look.

[gcasa]

@gcasa but whats broken? it looked fine!

In short... nothing is broken at this point but was in the past.

[gcasa]

@gcasa but whats broken? it looked fine!

Also. To my original comment. This was a GUI bug since it was due to how NSButton was being archived. Gorm compensates for this by eradicating hard coded target action data. The code to do that has been part of of the application for years. Actually all you needed to do was load and then re-save the file to fix the issue because Gorm filters this out.

It was sort of a gorm bug as well since the app should have been setting this data. But back then I didn't know better. 😂