Local printer on remote desktop via RDP

Bug #233784 reported by Procion
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
tsclient
Fix Committed
Undecided
Unassigned
tsclient (Baltix)
New
Undecided
Unassigned
tsclient (Ubuntu)
Won't Fix
Low
Unassigned
Declined for Jaunty by Martin Pitt

Bug Description

Binary package hint: tsclient

I have a local printer at lan, and I want to map it on a remote terminal server in my session, but tsclient don't provide such option. Rdesktop can do this from command line (... -r printer:<printername>[=<driver>],... )

Revision history for this message
Procion (klebed) wrote :

I suggest dirty solve for the problem. At sources of tsclient in support.c file, add something like:

      // Added support for mapping local printers to remote desktop
      FILE* fptr;
      gchar *prn_filename = g_build_path ("/", tsc_home_path(), "printers.list", NULL);
        if ((fptr = fopen(prn_filename, "rd")) != NULL) {
  gchar *prnline = fgets(fptr) ;
         sprintf(buffer, "-r printer:%s", prnline);
         c_argv[c_argc++] = g_strdup (buffer);
  fclose (fptr);
 }

I don't have time to find out how to get printers list from system. If somebody can help with it, it would be great!
I'am just new in linux and for now have problem with compilation of tsclient sources. I just dont understand why ./configure don't create makefile.

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :
Revision history for this message
Joseph Miller (josephcmiller2) wrote :

This patch adds printer redirection support. Please note that configure.in is broken and needs:

- pkg_modules="libpanelapplet-2.0"
+ pkg_modules+=" libpanelapplet-2.0"

and then autoconf needs to be run again before configure. This patch applies to tsclient-0.150 with no other patches applied to it. I do not know if this is appropriate or if I should have provided a patch with some of the other patches applied. If someone could tell me the proper way to do this, I would be grateful. Please know that I am not a GTK programmer and I don't really know the proper way to do things. I have copied most of this code from the Disk Drive redirection patch.

I don't like the sprintf that is used in support.c, I wonder if buffer overruns are possible and if this is a security risk. I used it to be uniform with the rest of the code.

I am not reporting this upstream because it appears that Ubuntu maintainers had to add the file redirection as it was not in the original code either. I'm hoping that Ubuntu maintainers will get to this in a timely manner. It's a silly feature to be missing. I think next I'd like to see that disk redirection be done for each of the mounted disks so that removeable media is more easily accessible in the terminal server.

Revision history for this message
Joseph Miller (josephcmiller2) wrote :

Here is an update. I think this is the correct way to provide the patch. This patch applies to tsclient_0.150-1ubuntu6 source with all patches applied. I recommend stealing the printer icon from Ubuntu themes for this. Also, the patch to configure.in is no longer necessary, someone already did it (I just hadn't applied the patches properly the first time).

This patch uses gtk_enumerate_printers() to read the printers on your system, then loads each of them via '-rprinter:printer1,printer2,printer3' so that all printers would be available.

Revision history for this message
Joseph Miller (josephcmiller2) wrote :

Icon for the printer - stolen from /usr/share/icons/Human/48x48/devices/gnome-dev-printer.png on Jaunty

debian/rules
  build/tsclient::
          uudecode -o debian/harddrive.png debian/harddrive.png.uue
+ uudecode -o debian/printer.png debian/printer.png.uue
  # clean .png
  cleanbuilddir/tsclient::
          rm -f debian/harddrive.png
+ rm -f debian/printer.png

I don't know where else to modify to make this file become part of the build. I thought it should be in ./pixmaps/ not in ./debian/. Maybe someone can shed some light on this for me. I want this to be as easy as possible so the maintainers will update this.

Revision history for this message
Martin Pitt (pitti) wrote :

Joseph, can you please send the patch to the upstream bug, too, to get their feedback?

Changed in tsclient (Ubuntu):
status: New → Triaged
Revision history for this message
Joseph Miller (josephcmiller2) wrote : Re: [Bug 233784] Re: Local printer on remote desktop via RDP

Martin,
Thanks for your response, I was starting to feel like this patch had
been ignored. I have uploaded a patch to
http://sourceforge.net/tracker/?func=detail&aid=2795819&group_id=192483&atid=941576
but I don't know if that is the right place. Maybe I need to sign up
for their mailing list too? I guess I'll try that. Thanks.

-Joseph

On Thu, May 28, 2009 at 4:15 AM, Martin Pitt <email address hidden> wrote:
> Joseph, can you please send the patch to the upstream bug, too, to get
> their feedback?
>
> ** Also affects: tsclient
>   Importance: Undecided
>       Status: New
>
> ** Changed in: tsclient (Ubuntu)
>       Status: New => Triaged
>
> --
> Local printer on remote desktop via RDP
> https://bugs.launchpad.net/bugs/233784
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in tsclient: New
> Status in “tsclient” source package in Ubuntu: Triaged
> Status in “tsclient” source package in Baltix: New
>
> Bug description:
> Binary package hint: tsclient
>
> I have a local printer at lan, and I want to map it on a remote terminal server in my session, but tsclient don't provide such option. Rdesktop can do this from command line (... -r printer:<printername>[=<driver>],... )
>

Revision history for this message
Procion (klebed) wrote :

I'am very glad to see that patch has been written, thanks!
I wonder if it can be commited and passed to repository in less than another year. =)
Seems like project mantainers not interested in it's development.

Revision history for this message
Joseph Miller (josephcmiller2) wrote :
Download full text (3.9 KiB)

Yeah, I messaged the project maintainer who had made the latest
patches, but we'll see what happens. That is why I have also made a
patch against the Ubuntu package. If the upstream patch gets delayed
from inaction, I'll start pestering people until one of the package
maintainers does something about it. I've been using this patch daily
in a production environment with no issues. If the package
maintainers won't do anything, I'll just build a .deb package and post
the URL. I hear all this "if you don't like it, submit a patch" talk,
but when someone finally builds a patch, they have to jump through
hoops to get it applied. I have to contact upstream, then Debian
package maintainer, then Ubuntu package maintainers. This has got to
be a major deterrent to anyone wanting to distribute code. My patch
is really simple, easy to read, and almost an exact copy of the
existing disk redirection patch which was applied by package
maintainers because upstream won't do anything. It can't be that hard
to review, test, and make a new package revision. I would hope that
issues like this would be brought more to light from the wine DIB
discussion, but I'd bet that's asking too much as well.

My big problem is that I emailed the package maintainer listed for the
package, but it was just the generic package maintainers for Ubuntu.
If an email is listed as a package maintainer, the person at that
email should be someone who can execute action, not just tell me "go
upstream" when I know damn well that upstream isn't doing anything on
the project. I guess that if I don't hear anything in the next few
days, I'm going to start sending emails to everyone I can find until
someone gets pissed off enough to just apply the damn patch.

As a side note, this is a pretty ridiculous feature to be missing from
the application. The application is well thought out and easy to use,
as well as extremely useful for those who need it. What I don't
understand is why the printer redirection wasn't included in the first
place. Imagine if any commercial company had released this
application in the state that it's in. They would get rave reviews -
easy to use, save/load feature, everything anyone would want - oh wait
- WTF? Why can't I use my printer? And that would be the end of the
good review, and many customers would return the product, or just
never buy it. It took me an afternoon, but I am not a Debian
developer (had to figure out how to build from Debian source package),
C programmer (well, how hard can it be?), or GTK programmer
(documentation not as easy to use as I would want - getting a list of
printers was pretty hard to figure out how to do). I imagine the
project developers could have done this in less than an hour.

Anyways, the patch it written, and if it doesn't get applied soon, I'm
going to start to get noisy. Now I understand why Linus, Wine devs,
and some of the other OSS devs get so aggressive in their statements
and policies. My first useful patch to the OSS community, and it may
discourage me from ever sending another one. Really dumb.

-Joseph

On Fri, May 29, 2009 at 1:26 AM, Procion <email address hidden> wrote:
> I'am  very glad to see that ...

Read more...

Revision history for this message
Cyclops (rms) wrote :

Looking into it. Sorry, for being lax for far too long.

Revision history for this message
Joseph Miller (josephcmiller2) wrote :

Cyclops,
Have you had a chance to look at this yet? Is there someone else that I
should forward this to? I'm about to start repeatedly emailing anyone I can
find dealing with Ubuntu packaging until I can get this moving. It's
unfortunate that my first patch attempt has been so discouraging. I would
like to learn how to submit more patches for more programs, but at this
point, I still don't know what the process even is. I have submitted my
packages, contacted Debian and upstream. I've done everything that has been
requested of me so far and zero results and zero feedback.

-Joseph

On Sat, May 30, 2009 at 1:32 PM, Cyclops <rms@1407.org> wrote:

> Looking into it. Sorry, for being lax for far too long.
>
> --
> Local printer on remote desktop via RDP
> https://bugs.launchpad.net/bugs/233784
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in tsclient: New
> Status in “tsclient” source package in Ubuntu: Triaged
> Status in “tsclient” source package in Baltix: New
>
> Bug description:
> Binary package hint: tsclient
>
> I have a local printer at lan, and I want to map it on a remote terminal
> server in my session, but tsclient don't provide such option. Rdesktop can
> do this from command line (... -r printer:<printername>[=<driver>],... )
>

Revision history for this message
pinzia (pinzia) wrote :
Revision history for this message
Procion (klebed) wrote :

Some days ago, I have tried grdc. It's really good alternative for tsclient... Since tsclient don't have option like "additional command line parameters", printer issue become critical for it, but grdc have such option, and I can make it works by manual editing parameters string. Grdc have very good feature - panel, sticked on top of rdesktop window, then user can control rdesktop and some options even if -K and -y options of rdesktop is broken, I think. Also grdc have connection list, this is more convenient than save/load connections in tsclient.

Easy GUI switch for printer in grdc will make it much better, and I agree that patch is needed for that package. May be author of grdc will become more sympathetic, and accept patch quickly.

Changed in tsclient (Ubuntu):
importance: Undecided → Low
Revision history for this message
Procion (klebed) wrote :

Sure it have low importance! I've posted request here more than year ago! Joseph suggested patch, that implements feature from request, some months ago! But no one from mantainers or developers looked into it, and applyed! It's too hard for them? nobody cares, who cares?

I'am very disappointed...

Revision history for this message
Cyclops (rms) wrote :

Adding the patch.

Revision history for this message
Cyclops (rms) wrote :

Patch commited.

Changed in tsclient:
status: New → Fix Committed
Revision history for this message
pinzia (pinzia) wrote :

remmina (ex grdc) has support for local printer in the new version (0.7) http://remmina.sourceforge.net/index.shtml

bug for inclusion https://bugs.launchpad.net/ubuntu/+source/grdc/+bug/396831

Revision history for this message
Aaron Whitehouse (aaron-whitehouse) wrote :

This does not seem to be working in 10.04.

Is there any reason why this patch was committed in August last year but didn't make it into 10.04? Will it be in 10.10 automatically?

Revision history for this message
Procion (klebed) wrote :

Aaron, you can use Remmina from PPA. Since it works on FreeRDP (not rdesktop) and it solves most of annoying rdesktop/tsclient bugs and lacks.

add repo by this command: sudo apt-add-repository ppa:llyzs/ppa
then install new remmina by: sudo aptitude install remmina

goodluck!

Revision history for this message
Sebastien Bacher (seb128) wrote :

Unsubscribing the sponsors, the change is non trivial and nobody is maintaining that software, better to use a better alternative rather than waiting on this change to be reviewed

Revision history for this message
Procion (klebed) wrote :

Sebastien, I hope Maverick will come with remmina+freerdp in-box. We using it at some client infrastructures, and it's works very good.

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

Closing this bug as tsclient is no longer in the Ubuntu archives (starting from Oneiric).
The default remote desktop client in Ubuntu is now Remmina.

Changed in tsclient (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.