assets/developer-notes/stephanie-gawroriski/2016/10/14.mkd

   1 # 2016/10/14
   2
   3 ## 09:44
   4
   5 The display server is best agnostic to its type.
   6
   7 ## 10:41
   8
   9 For some displays, I may have a temporary connection or even a longer term
  10 one. I suppose for that I need a method that gives me a wrapped closeable
  11 with the needed stream stuff for i/o. Basically this method will take a
  12 single argument, whether it should be a hold open operation. If it is false
  13 then the stream may be closed when `close` on the wrapper is called. If
  14 it is true, then `close` has no effect even if other instances are opened
  15 with false specified. When an item is associated with a display it will be
  16 held open. I would also need some kind of escaping system where if the
  17 server end closes the connection for some reason (perhaps I/O error) the
  18 wrapper could potentially detect such things and then terminate the display.
  19
  20 ## 12:05
  21
  22 There is a JSR related to displays called JSR 258, the Mobile User Interface
  23 Customization API.
  24
  25 ## 12:18
  26
  27 Essentially it allows custom theming of sorts.
  28
  29 ## 12:23
  30
  31 There is also AGUI, JSR 209.
  32
  33 ## 12:24
  34
  35 JSR 209 has AWT, Swing, and ImageIO. I do wonder which version of Java it
  36 best matches. From version 1.4.2 they came. Then there is also a mention
  37 of JSR 216. This is the personal profile which comes with many more
  38 classes.
  39
  40 ## 12:35
  41
  42 Feels like feature creep. I suppose what I should do is rename any projects
  43 that are grahics related so that they are prefixed with something such
  44 as `gfx`.
  45
  46 ## 12:39
  47
  48 I definitely need a project that defines scope of what will be in SquirrelJME
  49 and what will **NOT** be in it. For sanity purposes.
  50
  51 ## 16:37
  52
  53 And now that is complete, so I essentially looked at what was needed and it
  54 really is not that much at all. It would be much work, but there is quite
  55 some duplicating in the JSRs, so effectively implement one can give me
  56 multiple ones. I also definitely do not want to implement AWT or Swing, since
  57 they are essentially dead APIs.
  58
  59 ## 16:39
  60
  61 Otherwise, I thought about event handling in displays. Since IMC is
  62 asynchronous, I can essentially have two threads for a display. One thread
  63 would be active for each local display (on the client side) and pretty much
  64 would keep reading in packets and then peforming calls. So any events
  65 generated on a display can be pushed rather than polled. Also, whenever a
  66 request is made to the remote end, such as setting a title, there can just
  67 be a send. I should make it so that everything is for the most part send
  68 only or receive only. I also thought about something for capabilities. The
  69 capabilities of a display should not change at all, so when the display
  70 is initialized (the array that is), those capabilities can be specified as
  71 required. Since the call to `getDisplays` pretty much checks capabilities,
  72 that would be a pretty much waste of socket time making a new request just
  73 to waste such a thing. Then there can be other flags for the pointer events
  74 and pointer motion. So I should minimize that cross-talk and try to get that
  75 kind of static information all at once.
  76
  77 ## 16:59
  78
  79 Also means I do not have to go too crazy with some things.
  80
  81 ## 17:01
  82
  83 Well, effectively with these other JSRs, I would have to essentially
  84 redesign my display system to handle such things. However now that I actually
  85 went through them, I now know that I am on a good route.
  86
  87 ## 17:29
  88
  89 Actually, having bit flags and fields for properties of a display would be a
  90 bit ugly. What I essentially need is a kind of get of a property so to speak.
  91 For example, this information could be variable, but essentially just a
  92 group of integers that contain values. The information could be sourced from
  93 enumerations with IDs. So when writing, they would all be written and
  94 obtained. This would then mean that I could add new properties to a display
  95 and I would not need to have a manual 30-or-so variable passing or strange
  96 structure types. The enumeration set could also be passed in to the display
  97 initialization.
  98
  99 ## 20:53
 100
 101 Well my conversion from PPI to Dot Pitch (in microns) was spot on. Of course
 102 I verified it, which turned out I was correct.