Project Tree improvements
Moderator: Moderators
This has nothing to do with the previous part of the thread but it still falls under "Project tree readability" so here goes...
Am I the only one who finds the order of certain Project Tree entries inconsistent / confusing? For example I always somehow expect Model's OnSpawn entry to be near the top, just like main "OnLoaded" is.
Similarly, every time I want to access "OnRemove" of a Model, I instinctively tend to look at the bottom of its Project Tree sublist (it's probably the last thing the Model will do, so it'd make sense for OnRemove to be there). Main program's "OnClose" (in my eyes the equivalent to "OnRemove" but for the whole program) on the other hand is in the middle...
...and to make it a bit more confusing, individual States of the model have the order reshuffled again, for example Model's "Definition" is on top of the sublist, while State's "Definitions" are second from bottom. Shouldn't "Definitions" be called "Content" anyway like in the main program Project Tree entry?
I'm not saying everything should match 1:1 to everything else, but maybe it'd be nice if at least Model and States had a similarly listed Project Tree entries?
(The ideal solution would be to have everything mapped 1:1, and the lower part of the Project Tree just reserved for "Content", but that'd probably be wrong...)
Am I the only one who finds the order of certain Project Tree entries inconsistent / confusing? For example I always somehow expect Model's OnSpawn entry to be near the top, just like main "OnLoaded" is.
Similarly, every time I want to access "OnRemove" of a Model, I instinctively tend to look at the bottom of its Project Tree sublist (it's probably the last thing the Model will do, so it'd make sense for OnRemove to be there). Main program's "OnClose" (in my eyes the equivalent to "OnRemove" but for the whole program) on the other hand is in the middle...
...and to make it a bit more confusing, individual States of the model have the order reshuffled again, for example Model's "Definition" is on top of the sublist, while State's "Definitions" are second from bottom. Shouldn't "Definitions" be called "Content" anyway like in the main program Project Tree entry?
I'm not saying everything should match 1:1 to everything else, but maybe it'd be nice if at least Model and States had a similarly listed Project Tree entries?
(The ideal solution would be to have everything mapped 1:1, and the lower part of the Project Tree just reserved for "Content", but that'd probably be wrong...)
rrTea, for sure you are not the only one, but the others somehow get used to the current not so logical ordering of sections. Your proposal makes sense - sections ordered by lifecycle, e.g.:rrTea wrote:Am I the only one who finds the order of certain Project Tree entries inconsistent / confusing?
ZAppliation
- OnLoaded
- States
- OnRender
- OnBeginRenderPass
- OnUpdate
- OnClose
- Lights
- Content
AppState
- Definitions
- OnStart
- OnRender
- OnUpdate
- OnLeave
Model
- Definitions
- OnSpawn
- States
- OnRender
- OnUpdate
- OnCollision
- OnRemove
Remarks:
1. I think Definitions is semantically different than Content, therefore, I used the original names.
2. Ville, is the Lights section really needed? Cannot be lights put to the Content section?
Hi guys,
Hmm .. I'd keep all events ( everything starting with "On" ) grouped together and follow the order in which events are executed.
But as long as it's logical in some way i don't really mind ( which isn't the case right now ).
+ Not sure why ModelState has a Definitions node as well ( accidental inheritance? ).
K
Hmm .. I'd keep all events ( everything starting with "On" ) grouped together and follow the order in which events are executed.
Code: Select all
ZApplication
- States
- OnLoaded (Create)
- OnUpdate (Update)
- OnBeginRenderPass
- OnRender (Render)
- OnClose (Delete)
- Content
AppState
- OnStart (Create)
- OnUpdate (Update)
- OnRender (Render)
- OnLeave (Delete)
- Content
Model
- States
- OnSpawn (Create)
- OnUpdate (Update)
- OnCollision
- OnRender (Render)
- OnRemove (Delete)
- Definitions
ModelState
- OnStart (Create)
- OnUpdate (Update)
- OnCollision
- OnRender (Render)
- OnLeave (Delete)
The Definitions node of AppState should be called Content instead .. I actually talked to Ville about this a couple of months ago.Rado1 wrote:I think Definitions is semantically different than Content, therefore, I used the original names.
+ Not sure why ModelState has a Definitions node as well ( accidental inheritance? ).
K
Hi Rado1,
K
I only listed the events like that to make it easier to compare the order between the different component .. not as a suggestion to rename themRado1 wrote:I'm fine with suggestion of Kjell with unified/simplified names, but instead of Delete I would prefer Destroy (as antonym to Create)
Did you mean AppState.Definitions instead of Model.Definitions? Since i do think Model.Definitions should stay that way.Rado1 wrote:Model.Definitions can be Model.Content.
K
Same here Obviously there will be some exceptions but hey.Kjell wrote:But as long as it's logical in some way i don't really mind
I actually occasionally use those for storing some Model state-specific values etc... Maybe it's just my weird habit.Kjell wrote:+ Not sure why ModelState has a Definitions node as well ( accidental inheritance? ).
(Maybe in a distant future it'd work well to have the lower part of the Project Tree reserved for "Content / Definition" field that appears when the App / Model / ModelState is selected / clicked on, similar to how "Properties" appear right now. This'd remove the currently necessary requirement to have the App branch end with "Content"... One problem I see with this is that the number of Content entries can vary a lot - the main App will have many entries in Content while a Model can have only a few... and a State almost nothing...)
Kjell, I meant all Definitions renamed to Content; AppState.Content, Model.Content... but that's maybe not a good idea, I'm fine with Definitions sections as they are now.Kjell wrote:Did you mean AppState.Definitions instead of Model.Definitions? Since i do think Model.Definitions should stay that way.Rado1 wrote:Model.Definitions can be Model.Content.
Last edited by Rado1 on Wed Dec 24, 2014 2:49 pm, edited 1 time in total.
Hi Rado1,
K
I just think it's beneficial to indicate there's a clear distinction between Model.Definitions and App.Content ( and AppState.Content ) as Definitions get allocated for each individual clone, whereas for Content there's no such feature.Rado1 wrote:I meant all Definitions rename to Content; AppState.Content, Model.Content... but that's maybe not a good idea, I'm fine with Definitions sections as they are now.
K
Looks better. There are a few little things I found surprising, nothing major but for example the Model and ModelStates don't have the same order of sublists (ModelState has OnCollision as last entry for example - due to the structural similarity of Model / ModelState I'd expect sublists of both to be almost identical), and if I understood correctly the content / code of ModelStates are executed after the main Model events, so I would expect States to be after OnUpdate / OnRender / OnCollision but Before OnRemove.
But this is just a minor observation really. It does make more sense than before so definitely an improvement.
But this is just a minor observation really. It does make more sense than before so definitely an improvement.