libs-gui icon indicating copy to clipboard operation
libs-gui copied to clipboard

progress bar inspector horiz/vert

Open gcasa opened this issue 1 year ago • 1 comments
trafficstars

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 avatar Aug 09 '24 02:08 gcasa

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

gcasa avatar Aug 09 '24 02:08 gcasa

  • 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)

rmottola avatar Sep 19 '24 21:09 rmottola

This should now work. Thanks! :)

gcasa avatar Sep 20 '24 01:09 gcasa

@gcasa but whats broken? it looked fine!

rmottola avatar Sep 20 '24 04:09 rmottola

Huh?? I took your changes.

gcasa avatar Sep 20 '24 08:09 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 avatar Sep 20 '24 08:09 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 avatar Sep 20 '24 08:09 gcasa

@gcasa but whats broken? it looked fine!

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

gcasa avatar Sep 20 '24 10:09 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. 😂

gcasa avatar Sep 20 '24 10:09 gcasa