Hi Phil,
On Mo 11 Apr 2011 10:26:16 CEST "--[ UxBoD ]--" wrote:
Agreed Mike; though I have the feeling it may be less worth than the
effort involved unless somebody knows the internal working of Perl
and SSHFS ? A sleep could be added though I have tried to avoid
slowing down the process to much. Since adding that loop code we
have not experiencing any further failures; though time will tell.
I already had a look at the printing code in x2go some time ago.
There basically are three components:
o cups-x2go o x2goprint o x2goclient
If I recall it corrently the interaction between cups-x2go and
x2goprint was not optimal then. I guess it was cups-x2go that left
over some print job files whenever a print job was sent to the client,
but I am not sure anymore. A person that was not in the x2goprint
group also created orphaned print jobs in /, because they were not
picked up properly by x2goprint. My observations all were a little
odd. Whenever I have time, I will take a look at the mechanism and
come up with some patches.
The x2goprint <-> x2goclient communication is rather simple: x2goprint
drops two job files in the spool dir: <job>.pdf and <job>.pdf.ready.
The X2go client has to run a thread that watches this spool dir (it's
in the x2go session cache folder under ~/.x2go/C-.../spooll). On each
incoming print job it has to wake up and take over the task of
processing the print job. My Python implementation of this printqueue
can be found here (if you prefer Python to Perl for a lecture...):
http://code.x2go.org/gitweb?p=python-x2go.git;a=blob;f=x2go/printqueue.py;h=...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
----- Original Message -----
Hi Phil,
On Mo 11 Apr 2011 10:26:16 CEST "--[ UxBoD ]--" wrote:
Agreed Mike; though I have the feeling it may be less worth than the effort involved unless somebody knows the internal working of Perl and SSHFS ? A sleep could be added though I have tried to avoid slowing down the process to much. Since adding that loop code we have not experiencing any further failures; though time will tell.
I already had a look at the printing code in x2go some time ago.
There basically are three components:
o cups-x2go o x2goprint o x2goclient
If I recall it corrently the interaction between cups-x2go and x2goprint was not optimal then. I guess it was cups-x2go that left over some print job files whenever a print job was sent to the client, but I am not sure anymore. A person that was not in the x2goprint group also created orphaned print jobs in /, because they were not picked up properly by x2goprint. My observations all were a little odd. Whenever I have time, I will take a look at the mechanism and come up with some patches.
The x2goprint <-> x2goclient communication is rather simple: x2goprint drops two job files in the spool dir: <job>.pdf and <job>.pdf.ready. The X2go client has to run a thread that watches this spool dir (it's in the x2go session cache folder under ~/.x2go/C-.../spooll). On each incoming print job it has to wake up and take over the task of processing the print job. My Python implementation of this printqueue can be found here (if you prefer Python to Perl for a lecture...):
http://code.x2go.org/gitweb?p=python-x2go.git;a=blob;f=x2go/printqueue.py;h=...
Greets, Mike
Thanks, Phil
Hi Phil,
On Mo 11 Apr 2011 12:07:57 CEST "--[ UxBoD ]--" wrote:
Yep that is my interpretation of the process as-well, Mike. One
thing I have noticed is that if you print the resultant PDF the file
is left in the spool directory without being deleted; yet if you
cancel from the x2go-print dialogue box the file is removed.
is that x2goclient or PyHoca-GUI/Python X2go? With PyHoca-GUI this
should not happen, otherwise it is a bug I have missed so far...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
----- Original Message -----
Hi Phil,
On Mo 11 Apr 2011 12:07:57 CEST "--[ UxBoD ]--" wrote:
Yep that is my interpretation of the process as-well, Mike. One thing I have noticed is that if you print the resultant PDF the file is left in the spool directory without being deleted; yet if you cancel from the x2go-print dialogue box the file is removed.
is that x2goclient or PyHoca-GUI/Python X2go? With PyHoca-GUI this should not happen, otherwise it is a bug I have missed so far...
Greets, Mike
Thanks, Phil