[sldev] Direction for Snowglobe 1.3

[Lawson English]

Dzonatas Sol wrote:
> Sorry, I never intended to call your proposal bloat, as it wasn't the 
> proposal itself I didn't consider bloat.
>
> The built-in UI would need many hooks to support a plugin for such 
> features. If the UI is externalized into a plugin, then none of those 
> specific hooks would be needed to be programmed within the viewer 
> itself, especially if the UI used the OS's default windows system. 
> D.N.S., for example, already knows how to manipulate Windows.
>
> I meant bloat in the sense of maintenance of features in a monolithic 
> code base... specifically the merges/rebase. The plugin idea, as you 
> propose, could be a specially designed UI that works with well D.N.S.
>
> With the UI code moved into a plugin, this would avoid the special 
> #if-#then-#else cases for desired features. Instead of a recompile with 
> different option... load a different UI plugin. That's what I meant.
>
> I just took your proposal and pushed it a little further to suggest the 
> entire UI be put into a plugin.
>
> Cheers
>   


There's at least two levels of HI interface that can be exposed: 
low-level mouse/keyboard/interface events and high-level user events. 
Most people think in terms of the low-level events. Far more 
interesting, to me are the high-level events based on user actions. E.G. 
Login (name, password [location]), TP (destination), Give Item (item) 
etc. Those can be made cross-viewer and allow at least some level of 
cross-platform scripting.

Other kinds of events suitable for exposure for a plugin include any/all 
standard packets. No doubt others are appropriate as well such as the 
ability to generate GUI elements such as handles and rotation widgets on 
the scene-graph ala what the puppeteering controls use. (for standard 
GUI stuff, just go with what Zero suggested ages ago: use xhtml and a 
webbrowser connected either to local host or to a remote service with 
nifty new features).

Lawson