Chachereau Nicolas:
Basically the only change since the last version sent to the
mailing list is that you can now call register: with a
correspondant field as well, that is, sending
:filepath:register:, where filepath is a file you created
and to which SciTE will write the name of the pipe you
Neil Hodgson wrote:
Doesn't that remove the need for /tmp/SciTE.register?
Well, yes I guess so. If everybody's okay with that, we can remove it.
On Windows, ActivateWindow(const char *timestamp) is less obviously
useful (and the argument isn't) so I'm not sure whether this should go
in
On 7/5/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
Neil Hodgson wrote:
Doesn't that remove the need for /tmp/SciTE.register?
Well, yes I guess so. If everybody's okay with that, we can remove it.
I'll vote for that; I was never happy with having yet another _named_
temp file which was
Hi everybody!
I think we're almost done with the changes. I uploaded some
files. I tried to break up the changes in steps, so that they
can be looked and committed separately.
First, the revised DirectorExtension.
http://nico.esoxprojects.net/scite/director.zip
Basically the only change
Sorry, I forgot the urls. Here they are:
[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2510465
[2] http://www.msu.edu/~huntharo/xwin/docs/xwindows/PROTO.pdf (p.165)
[3] http://standards.freedesktop.org/desktop-entry-spec/latest/
[4]
On 7/3/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
This starts filerx and tells it which instance it is supposed to
talk to. The X window ID isn't useful for this purpose, what a
director started from SciTE would need is the name of the pipe
SciTE is listening to. We could simply call this
On 7/3/07, Chachereau Nicolas [EMAIL PROTECTED] wrote:
Sorry, I forgot the urls. Here they are:
[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2510465
[2] http://www.msu.edu/~huntharo/xwin/docs/xwindows/PROTO.pdf (p.165)
[3]
Steve Donovan wrote:
Yeah, but how real a problem is this? The typical situation is that
you are working with the Director program, and it wants to bring up
SciTE to show us a file (like scitePM). Having an extension running in
the background which brings up SciTE is just bad-mannners.
That's not
steve donovan:
There is a danger of overengineering. This is a slipperly slope which
will end up with us using something like DBus...!
I had a another look at DBus. It probably is too complex although
since there is a per-user instance there will be less opportunity for
interference on
Chachereau Nicolas:
That's not really the use case. Suppose the director, for some reason,
takes a while before asking SciTE to be activated. You might then
have switched to another application, e.g. might be reading something
in your web browser. It would then be an annoyance if SciTE was
Steve Donovan wrote:
That's what I think - named pipes are so easy, you don't need a higher
degree or special equipment ;) Although controlling a remote instance
of SciTE might be entertaining, it wouldn't be high on most people's
list of piorities. But, it's true, pipes are global. I was
Roy Wood wrote:
I'm the author of scitepm, so thanks for the nice words. :-)
I'm very happy to modify scitepm to work with whatever IPC strategy
you guys want to set up in scite. The code in scitepm is very clean,
and implementing the required changes would be a snap. Just let me
know what the
That's the next thing on my todo list, and I already have some pointers.
Basically we need to call gtk_window_present() but there is some stuff
with timestamps - to ensure the window gets fronted unless it's
annoying for the user - that I've got to research. What would the
message be called? I'd
13 matches
Mail list logo