[sldev] Direction for Snowglobe 1.3

Dzonatas Sol dzonatas at gmail.com
Mon Nov 30 17:21:49 PST 2009


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

Aleric Inglewood wrote:
> I'm afraid I don't know what your patch does. I'm not happy with
> calling my proposal bloat though.
> If your patch changes all floaters into OS windows, then still I
> wonder if one could access the
> menu from a plugin, or the local chat.
>
> On Tue, Dec 1, 2009 at 12:02 AM, Dzonatas Sol <dzonatas at gmail.com> wrote:
>   
>> Aleric Inglewood wrote:
>>     
>>> As a first step it should be *possible* to write a plugin
>>> that 'takes over' the keyboard. The plugin itself does not
>>> need to be written yet, of course. With taking over the
>>> keyboard, I rather mean, the user input (chat, switching
>>> floater focus, allow opening menu's and choosing an item).
>>> The hooks for that should be there (accessible from a
>>> plugin).
>>>
>>>       
>> With the detach windows patch I have, would this be a simple step to hook up
>> Dragon Naturally Speaking or such? It comes with ways to speak and manage
>> windows, already. That would avoid any need to program another bloat into
>> the main viewer to specifically support TTS/STT/Speech-automation.
>>
>>     
>
>   



More information about the SLDev mailing list