Neil Hodgson wrote: > Fronting windows with insufficient reason became such a problem on > Windows that recent versions of Windows try to stop applications > fronting themselves except in particular cases. SciTE should not be > fronted by default for most of these commands as they damage use cases > where SciTE is being controlled by a foreground application that wants > to retain focus over a sequence of actions. > True, it's a complicated issue. The window manager actually controls some of that and doesn't always allow a window to be fronted. In Ubuntu, the button in the taskbar then flashes if it didn't allow it to be fronted. You're probably right about the sequence of action, but could we have a command to explicitly ask SciTE to be fronted? SciTE would then provide the necessary hints for it to be fronted, and the window manager would then decide what to do.
>> How strict should we be about the "closing:" message? If there >> are any unsaved files, and the user cancels the quit, should >> SciTE send a message to tell the director it didn't quit? Or >> should it be impossible for the user to cancel a quit when the >> director is closing? > > There should probably be an alternative command for one or the > other since it depends on the controlling application. > Maybe we could say the director sends closing: to force exit, otherwise it sends quit: and awaits a closing: message from SciTE... We should also think about "orphaned" instances... what is supposed to happen to a SciTE instance started by a director if its director is gone? >> I don't really like the assumption that a process can only >> communicate with SciTE if it started it. I think a process >> should be able to become a director even after SciTE started. > > Say you have a director application along with SciTE instances >attached to it. You don't want the director to interfere with SciTE >instances that you (or another director) started independently. I see no reason why it would do that. A director like scitepm should always send its messages to the instances it created. What I was thinking about was a way to start a SciTE instance, and then attach a director to it (for example scitepm). I actually had the following use case in mind: a script that would allow one to open a file in an already launched SciTE and wait until that file is closed. I just realised that we would actually need a new message sent by SciTE, "closed:<path>", to achieve that. Fortunately, with the new OnClose, that shouldn't be a problem. The more I think of it, the more I'm convinced breaking backward compatibility and going for sockets would be worth it. But I'm not the only one to decide here :) Nicolas _______________________________________________ Scite-interest mailing list Scite-interest@lyra.org http://mailman.lyra.org/mailman/listinfo/scite-interest
