4 ms·

I'm not sure this is how WYSWYG really works. There's only one MyFancyTextEditor widget definition, a blueprint so to speak. It's IDs refer to other things ins

I'm not sure this is how WYSWYG really works. There's only one MyFancyTextEditor widget definition, a blueprint so to speak. It's IDs refer to other things inside that blueprint. But at runtime, we might instantiate two different MyFancyTextEditors, one for view A and one for view B. They probably shouldn't share IDs, lest we run into confusion. I think WYSWIG is more like defining a class, whereas at runtime we'd be serializing instances. Feel free to correct me if I'm wrong, I admit I've never been down this line of thought!

b3morales 5y ago
Here's an example snippet from a xib file for an actual iOS project of mine: <button opaque="NO" contentMode="scaleToFill" contentHorizontalAlignment="center" contentVerticalAlignment="center" buttonType="roundedRect" lineBreakMode="middleTruncation" translatesAutoresizingMaskIntoConstraints="NO" id="ykl-6F-b5r"> <rect key="frame" x="0.0" y="0.0" width="375" height="0.0"/> <state key="normal" title="Done"/> <connections> <action selector="doneEditingTitle" destination="POI-12-VR5" eventType="touchUpInside" id="14R-fR-990"/> </connections> </button> A xib is an XML description of a GUI layout. Note the `<connections><action ...>` element inside the `<button>` -- this is defining what happens when the button is tapped. The connection becomes active at runtime when the file is rehydrated into live objects. The `selector` string identifies the name of the method to be called. (This exact mechanism relies on ObjC, but the principle can be applied to other systems.)
- verdagon 5y ago
  My point was that when we hydrate, we don't use the same IDs as what was in the serialized data. Otherwise, we'd have conflicts when we hydrate the same definition multiple times.
  - b3morales 5y ago
    I'm sorry, I'm not following your point -- what are the IDs used for, in your example? (For the XIB system, they have no purpose at runtime; they're solely for the archive. Objects get their own identity as usual when they're instantiated.)
    - verdagon 5y ago
      My bad, I didn't really explain that part. In practice, when we receive a GUI event, we then modify something in our surrounding environment, usually some model, controller, or other view. To interact with any of those in Rust, we need to refer to it by some sort of ID. This is the same ID you're referring to, which objects get when they're instantiated, at least for views (models and controllers likely do something similar). My central question is: why would we want to serialize those IDs? Also, WYSWYG might not be the best example, as it's a GUI that produces another GUI, hence some confusion. If you think about this in terms of a simple app that maintains a Customer database, you'll see what I mean; we wouldn't ever want to serialize a button click event there, especially since the hydrated IDs aren't stable and we don't know what they refer to unless we serialize the entire app UI state.
      - b3morales 5y ago
        Maybe I'm missing something particular about Rust? When the archive is loaded at runtime, we don't need explicit IDs: we have a normal object graph, with references between things. The instantiated widgets have identity as objects in memory. The string `id="ykl-6F-b5r"` isn't relevant -- or used at all. You can create as many instances of `Button` as you want, and they are different, and their targets (the other widgets they message when tapped) are different because they were either created alongside or, if they were live before the archive was deserialized, a reference was made to them as part of the deserialization process.
        verdagon 5y ago
        I think what you might be missing is that, in (safe + idiomatic) Rust, we actually can't have references between things (unless we want to make our entire GUI immutable, which would be a tad silly). Since we can't use references, we need to "refer" to other objects via IDs.
        b3morales 5y ago
        Thanks, I'll have to look into how GUIs in Rust work then; that sounds utterly bizarre to me :) I thought you could take references to things in Rust. Also, in particular, I don't understand why you'd want to use closures -- inherently reference-y -- when everything else is (I guess?) a non-reference plain value.

b3morales 5y ago

Here's an example snippet from a xib file for an actual iOS project of mine: <button opaque="NO" contentMode="scaleToFill" contentHorizontalAlignment="center" contentVerticalAlignment="center" buttonType="roundedRect" lineBreakMode="middleTruncation" translatesAutoresizingMaskIntoConstraints="NO" id="ykl-6F-b5r"> <rect key="frame" x="0.0" y="0.0" width="375" height="0.0"/> <state key="normal" title="Done"/> <connections> <action selector="doneEditingTitle" destination="POI-12-VR5" eventType="touchUpInside" id="14R-fR-990"/> </connections> </button> A xib is an XML description of a GUI layout. Note the `<connections><action ...>` element inside the `<button>` -- this is defining what happens when the button is tapped. The connection becomes active at runtime when the file is rehydrated into live objects. The `selector` string identifies the name of the method to be called. (This exact mechanism relies on ObjC, but the principle can be applied to other systems.)

verdagon 5y ago
My point was that when we hydrate, we don't use the same IDs as what was in the serialized data. Otherwise, we'd have conflicts when we hydrate the same definition multiple times.
- b3morales 5y ago
  I'm sorry, I'm not following your point -- what are the IDs used for, in your example? (For the XIB system, they have no purpose at runtime; they're solely for the archive. Objects get their own identity as usual when they're instantiated.)
  - verdagon 5y ago
    My bad, I didn't really explain that part. In practice, when we receive a GUI event, we then modify something in our surrounding environment, usually some model, controller, or other view. To interact with any of those in Rust, we need to refer to it by some sort of ID. This is the same ID you're referring to, which objects get when they're instantiated, at least for views (models and controllers likely do something similar). My central question is: why would we want to serialize those IDs? Also, WYSWYG might not be the best example, as it's a GUI that produces another GUI, hence some confusion. If you think about this in terms of a simple app that maintains a Customer database, you'll see what I mean; we wouldn't ever want to serialize a button click event there, especially since the hydrated IDs aren't stable and we don't know what they refer to unless we serialize the entire app UI state.
    - b3morales 5y ago
      Maybe I'm missing something particular about Rust? When the archive is loaded at runtime, we don't need explicit IDs: we have a normal object graph, with references between things. The instantiated widgets have identity as objects in memory. The string `id="ykl-6F-b5r"` isn't relevant -- or used at all. You can create as many instances of `Button` as you want, and they are different, and their targets (the other widgets they message when tapped) are different because they were either created alongside or, if they were live before the archive was deserialized, a reference was made to them as part of the deserialization process.
      - verdagon 5y ago
        I think what you might be missing is that, in (safe + idiomatic) Rust, we actually can't have references between things (unless we want to make our entire GUI immutable, which would be a tad silly). Since we can't use references, we need to "refer" to other objects via IDs.
        b3morales 5y ago
        Thanks, I'll have to look into how GUIs in Rust work then; that sounds utterly bizarre to me :) I thought you could take references to things in Rust. Also, in particular, I don't understand why you'd want to use closures -- inherently reference-y -- when everything else is (I guess?) a non-reference plain value.