[bugs #10876] Starting of pasteboard server should be sooner

[Alexander Malmberg]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #10876] Latest Modifications:

Changes by: 
                Alexander Malmberg <alexander@malmberg.org>
'Date: 
                Wed 11/03/04 at 13:41 (Europe/Stockholm)

            What     | Removed                   | Added
---------------------------------------------------------------------------
         Assigned to | None                      | alexm


------------------ Additional Follow-up Comments ----------------------------
I have no strong opinion on whether we should start gpbs at app startup or not. 
However, it is safer not to do so, so since others would rather not do this, I 
think that's best.

Fortunately, there is another solution. I've been toying with the idea of 
implementing a fast-autostart-mechanism that would help with things like this. 
I hacked up a proof-of-concept patch yesterday, and it worked nicely; instead 
of a 5 second wait, pasteboard access when gpbs wasn't running took ~0.01 
seconds. I'll commit after finishing the rest of this and cleaning it up.






/**************************************************************************/
[bugs #10876] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=10876>
Project: GNUstep
Submitted by: Stefan Urbanek
On: Tue 11/02/04 at 22:37

Category:  Gui/AppKit
Severity:  3 - Ordinary
Item Group:  Change Request
Resolution:  None
Privacy:  Public
Assigned to:  alexm
Status:  Open


Summary:  Starting of pasteboard server should be sooner

Original Submission:  the pasteboard server (gpbs) should be started sooner, 
not 'when requested'. Despite the lazy initialisation is a good practice, 
running the pasteboard server is not the right place to use it. It is making 
unpleasant user experience, when one tries to do cut/copy and more unpleasant 
when one wants to do drag&drop operation for the first time.

Therefore I would suggest that gpbs, when not started automatically by some 
init/login scripts, should be started by the first GNUstep application run, 
before the application enters the main run loop. So the request for running the 
gpbs will be 'first gnustep application run', not 'first use of pasteboard'.

Users are going to use PBS in most cases anyway.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Wed 11/03/04 at 13:41         By: Alexander Malmberg <alexm>
I have no strong opinion on whether we should start gpbs at app startup or not. 
However, it is safer not to do so, so since others would rather not do this, I 
think that's best.

Fortunately, there is another solution. I've been toying with the idea of 
implementing a fast-autostart-mechanism that would help with things like this. 
I hacked up a proof-of-concept patch yesterday, and it worked nicely; instead 
of a 5 second wait, pasteboard access when gpbs wasn't running took ~0.01 
seconds. I'll commit after finishing the rest of this and cleaning it up.

-------------------------------------------------------
Date: Wed 11/03/04 at 09:09         By: Richard Frith-Macdonald <CaS>
Just an opinion but ...
I agree that the pasteboard should be started early (just like the other 
daemons).
When I coded the automatic startup for these daemon, my intention was to 
provide a final fallback solution to start them if they had either crashed/been 
killed, or hand not been started earlier.
As such, I thought (and still think) that startup at the last possible moment 
is correct.
So, I do not really think that starting them earlier within an application is 
the right thing to do ... they should be started either at system boot time or 
at user login (for user specific daemons).  That being said, we might write a 
tool  to check daemons and start them if necessary.  It would be easy to run 
such a tool on login and/or run it in a subtask when an app start up.













For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=10876>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/