SHOW:
|
|
- or go back to the newest paste.
| 1 | - | This is pseudo code for how it would appear while you're pointer is free and you're in the inspector part of the editor. You're past the intro already. |
| 1 | + | There are two modes of manipulating stuff in the editor: |
| 2 | 1) pointer locked fps style where you can't click on the sidebar and other things | |
| 3 | - | *** Version 1 *** (more compact, more prone to error on the programming end) |
| 3 | + | 2) pointer free where your mouse is visible and you can click on the sidebar and other things. |
| 4 | ||
| 5 | *** During pointer lock fps mode these things will be available: *** | |
| 6 | "sidebar" area (on the right part of the screen): | |
| 7 | the sampler | |
| 8 | "majority" area (the rest of the screen): | |
| 9 | the reticule | |
| 10 | the inventory | |
| 11 | ||
| 12 | *** During the pointer free clickity mode, these things will be available: *** | |
| 13 | "sidebar" area (on the right part of the screen): | |
| 14 | the inspector | |
| 15 | the assets hierarchy | |
| 16 | (only one is visible at a time) | |
| 17 | - | *** Version 2 *** (easier to program hiding and showing) |
| 17 | + | "majority" area (the rest of the screen): |
| 18 | the code-editor (sometimes hidden) | |
| 19 | the inventory | |
| 20 | the bottom bar | |
| 21 | ||
| 22 | I am trying to figure out how best to organize these in the dom. Below is pseudo code for different ways I could do that | |
| 23 | ||
| 24 | The below is pseudo code for how the elements would be organized in relation to each other - what the parent elements would be, what they would contain. This would determine how the elements were programmed to appear and disappear | |
| 25 | ||
| 26 | This pseudo code is a snapshot of what elements would be collapsed and which would be showing when the pointer was free to click all over the place: | |
| 27 | ||
| 28 | ||
| 29 | ************************** | |
| 30 | Version 1: One "majority" area and one "sidebar" area. | |
| 31 | The elements that are nested by one tab are the elements that would be individually shown and hidden when the pointer status was changed. | |
| 32 | - CONS: The javascript is more prone to error during the changes in development when littler elements are changed, moved around, removed, or added depending on how the application is changing. | |
| 33 | - PROS: No duplicate elements, more compact. | |
| 34 | ************************** | |
| 35 | - | *** Version 3 *** (pointerlock and pointerfree applied as classes to other elements. A little prone to error again as, in development, parents could be added or removed.) |
| 35 | + | |
| 36 | < .intro (collapsed) > | |
| 37 | < .reticule (collapsed) > | |
| 38 | < .code-editor > | |
| 39 | < .bottombar > | |
| 40 | < .inventory > | |
| 41 | < .sidebar > | |
| 42 | < .sampler (collapsed) > | |
| 43 | < .editor > | |
| 44 | < .inspector > | |
| 45 | < .assets (collapsed) > | |
| 46 | - | < .assets .collapsed > |
| 46 | + | |
| 47 | ||
| 48 | ************************** | |
| 49 | Version 2: Two full page divs (.pointerlock and .pointerfree), each with a "majority" element and a "sidebar" element. | |
| 50 | - CONS: This would have duplicate elements - two sidebar elements and two majority elements. Possibly two inventory elements, which I'm not sure how to handle. | |
| 51 | - PROS: Less prone to error all around. To switch between pointer states in javascript I'd just handle the big elements, no fiddling with the smaller ones. In the html I don't have to worry about changing anything about the interior elements. | |
| 52 | ************************** | |
| 53 | < .pointerlock (collapsed) > | |
| 54 | < .majority > | |
| 55 | < .intro (collapsed) > | |
| 56 | < .reticule > | |
| 57 | < .inventory > (how does this move between the pointerlock and pointerfree?) | |
| 58 | < .sidebar > | |
| 59 | < .sampler > | |
| 60 | < .pointerfree > | |
| 61 | < .majority > | |
| 62 | < .code-editor > | |
| 63 | < .inventory > (If it isn't in the dom and in flow with the other elements, manipulating it in relation to the other elements becomes more complicated) | |
| 64 | < .bottombar > | |
| 65 | < .sidebar > | |
| 66 | < .inspector > | |
| 67 | < .assets (collapsed) > | |
| 68 | ||
| 69 | ||
| 70 | ************************** | |
| 71 | Version 3: Back to all little elements again, but this time there would be a .pointerlock class and a .pointerfree class to make the functionality more clear. | |
| 72 | - CONS: The html is more prone to error. Keeping those classes on the right elements may be more fiddly than even Version 1 | |
| 73 | - PROS: Programming less prone to error, I'd just toggle two classes, no fiddling with individual elements: hide(.pointerlock), show(.pointerfree) and hide(.pointerfree), show(.pointerlock) (aproximately) | |
| 74 | ************************** | |
| 75 | < .majority > | |
| 76 | < .intro .pointerlock (collapsed) > | |
| 77 | < .reticule .pointerlock (collapsed) > | |
| 78 | < .code-editor .pointerfree > | |
| 79 | < .bottombar .pointerfree > | |
| 80 | < .inventory > | |
| 81 | < .sidebar > | |
| 82 | < .sampler .pointerlock (collapsed) > | |
| 83 | < .editor .pointerfree > | |
| 84 | < .inspector > | |
| 85 | < .assets .collapsed > | |
| 86 | ||
| 87 | ||
| 88 | ************************** | |
| 89 | It is unclear to me which would be better practice regarding html and css | |
| 90 | ************************** |
