[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The necessity of gdomap and gdnc?
From: |
Richard Frith-Macdonald |
Subject: |
Re: The necessity of gdomap and gdnc? |
Date: |
Tue, 25 Oct 2005 14:22:09 +0100 |
On 2005-10-25 09:37:19 +0100 Leigh Smith <address@hidden> wrote:
In an application that indeed relies on distributed processes, this would
be
the price to pay, but after some review of the GNUstep base code, it seems
the use of distributed notifications and distributed objects are tightly
linked into the pasteboard server, application services and even deeper in
the AppKit/gui, regardless of whether the application has any need for
such
functionality.
Yes and no ... if an app is genuinely standalone, and doesn't do pasteboard,
services, or communicate with anything else, or need to be contacted by
anything else (to shut it down for instance) it should be easy to hack the
gui to stop setting up to use those facilities, but that's a very
dumbed-down application
So my question is the degree to which gdomap and gdnc are indeed necessary
for an application not requiring explicit use of inter- process comms and
if
NSMessagePortNameServer would address this (since I see NSMessagePorts are
explictly excluded on the MinGW port).
Well, ideally someone would implement NSMessagePort and
NSMessagePortNameServer for win32 ... removing the need for gdomap, thoiugh
you would still need gdnc for workspace notifications unless you also
modified NSWorkspace to use some other mechanism (eg writing to a file and
polling the file for changes or some sort of peer to peer messaging for
workspqace notifications).
Is it, or would it be, possible to build GNUstep's gui with a ./ configure
option or use an NSUserDefault to limit notifications and objects to the
running GNUstep application and not attempt to connect to the gdomap &
gdnc
servers and if so, any hints on implementing this?
You would want to hack NSPasteboard to deactivate it.
You would want to hack NSWorkspace to stop it trying to communicate with a
workspace manager or send notifications.
You would want to hack the NSApplication/Services provider stuff to stop the
application making itsself available for things to connect to.
IMO that's the wrong thing to do though ... it's a case of throwing the baby
out with the bathwater ... rather than disabling all the functionality until
the problem goes away, you should be fixing the problem. While some apps
may not need cut and paste, drag and drop, to provide services, to interact
with a workspace etc these are all features which make for a good general
experience.
I think that means ...
1. Implement the NSMessagePort stuff (perhaps windows messages could be used
for that).
2. Either implement a distributed notification scheme that doesn't need a
server, or work out a way to automatically start/stop gdnc so that users
don't need to see it.