Hi everybody! I finally had some time to play with both scitepm [1] and scite-gdb [2] (impressive work), as well as having a look at the code of the director extension and the single instance. Here are some of my conclusions about the work that has to be done in that area. I still need to do more research, especially about IPC (interprocess communication), but I wanted to write down my first thoughts.
For those wondering, my interest for this area started because of the bugs discovered about the way SciTE exits on GTK+ [3]. Everything I'm going to write concerns *only* the version of SciTE for GTK+. I warn you, it's going to be a lengthy email. Single instance problems ------------------------- While researching things about interprocess communication and single-instance handling, I found this page [4]. It describes some of the problems related to single-instance applications, and you'll notice SciTE is guilty of both focus stealing and startup notification issues. To see what I mean, set the property check.if.already.open to 1 (be sure that ipc.director.name is NOT set), launch SciTE, minimize it, and then open a file in SciTE from your file browser (I use Ubuntu and an unmodified Gnome, with Nautilus and Metacity. I can't guarantee that the hints needed are also sent in other configurations). You'll see the following: 1) instead of coming to the front, SciTE flashes in the taskbar 2) your cursor shows a "waiting" status for a very long time, and there is an entry in the taskbar saying someting like "opening <filename>", which stays for a very long time as well... This should definitely be fixed and I'm going to work on it. Director: Bugs and Assumptions ------------------------------- First of all: how do check.if.already.open and the director extension work together? I didn't why SciTEGTK::Run() only checked for an already existing instance if ipc.director.name was not set. This actually relies on an assumption made: ipc.director.name is supposed to be only set if SciTE was started by a director process. In that case, we have to open a new instance. This assumption is an important one in the director extension. Basically, the idea behind this is that SciTE communicates only with ONE director process, and this process has started SciTE. Furthermore, it is assumed that the director process has created the pipe SciTE writes to, and that it will take care of removing it. There are quite a few bugs as well, upon which Steve stumbled when making scite-gdb. - If the pipe SciTE is supposed to listen to is already open when it is launched, it doesn't listen to it. - Sometimes, several commands launched are processed as only one. - What, after all, brought me here: the pipe is never removed. Those bugs could probably be fixed without changing much the underlying assumptions. Another bug is SciTE's behaviour when it is sent a quit: command and a modal dialog is open. Extending the Director API specification ----------------------------------------- I think we should decide in which way SciTE reacts when it is sent a message. I think SciTE should be raised above the other windows in some cases, like: find:, goto:, insert:, loadsession:, macrocommand:, macrolist:, menucommand:, open:, output:, replaceall: I'm unsure about some of the other messages. 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? 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. According to the documentation, it is possible on Windows, SciTE can send its window handle to the process through command line parameters, if it starts the Director. I would say that any process should be able to communicate with SciTE, as long as it knows how to, whether it was started by SciTE or not. This means SciTE would always be listening for messages, and this has consequences for the single instance code. Single-instance is only a special case of IPC, and I think it should make use of the Director extension. We could keep the current code for people defining the NO_FILER constant, and use Director for everybody else. Right now, SciTE is always supposed to have only one "director". I would propose we try to make it possible for several process at the same time to communicate with SciTE. It is actually already possible, since a named pipe can have multiple writers... which means several process can send commands to SciTE. However, a named pipe can't have multiple readers, so only ever one process can read messages send by SciTE. To achieve this, we may have to change the method we use for IPC. As I'm unsure what the upper limit for mails sent to the mailing list, and since this is already long enough, I'll keep the discussion for later. Tell me what you think. Nicolas [1] http://scitepm.sourceforge.net/ [2] http://mailman.lyra.org/pipermail/scite-interest/2007-June/009335.html [3] http://mailman.lyra.org/pipermail/scite-interest/2007-June/009358.html [4] http://live.gnome.org/SingleInstanceApps _______________________________________________ Scite-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scite-interest
