5 ms·
You might be serializing your enums, but unless you serialize a lot more (button IDs, view IDs, etc), the IDs in your enums will be meaningless. I don't think y
by verdagon 5y ago
You might be serializing your enums, but unless you serialize a lot more (button IDs, view IDs, etc), the IDs in your enums will be meaningless. I don't think you're suggesting we serialize the entire GUI?
This also seems like the wrong layer to serialize. Normally we would want to serialize the model, not the view. Admittedly, the line is a bit blurry here (and for most small programs) so take my words with a grain of salt.
- b3morales 5y ago> I don't think you're suggesting we serialize the entire GUI? I am, exactly -- to enable WYSWIG construction/editing of the GUI. Just added another comment saying this below, but consider Android Layout Editor/Apple Interface Builder (or someone else mentioned QT Creator, which I'm not familiar with but has the same idea).
- amelius 5y agoYou might be right, but I feel that by filling out Enum structures I am helping the tools, whereas the tools should be helping me. And as a terminal-aficionado I don't want to use Design/Creator tools. So ... what I really want is a simple API with closures. And there should be no problem with that, as the Design/Creator tools can simply emit more complicated code if they want (e.g. closures that use enums).
- verdagon 5y agoI'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 agoHere'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 agoMy 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 agoI'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 agoMy 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.
- kortex 5y ago> I don't think you're suggesting we serialize the entire GUI? Yup that's exactly what people do in some GUIs. Tons of GUI frameworks and systems rely on varying degrees of defunctionalization and serialization. Microsoft COM and XServer for example. I don't know exactly how granular they get but I believe it's quite granular in what you can do over RPC.