Bug 852078

+++ This bug was initially created as a clone of Bug #542717 +++

27 Aug 2012  

This bug (a missing Reuuires: xfprint)  persists with the current RawHide candidates

The patch is a single line in the .spec file ...

versions: 
  mousepad-0.2.16-6.fc17.src.rpm 
  xfprint-4.6.0-5.fc15.src.rpm 
are the current RawHide versions

building and manually installing xfprint-4.6.0-5.fc15.src.rpm solves the problem.  Without the xfprint, mousepad will not print.  

-- Russ herrold



Description of problem:

Mousepad fails to print on default install, as it requires xfprint.
xfprint wants to drag in ~ 65 MB of dependencies (mostly tetex*), which is annoying.
 
This bug is mainly against the XFCE spin, where the impact is most severe - if there's a way to somehow assign an XFCE tag, that would be useful.

Version-Release number of selected component (if applicable): 

0.2.16-2


How reproducible:

Always


Steps to Reproduce:
1.open mousepad
2.print
3.
  
Actual results:

Error message:

"Can't open pipe to process"

Expected results:

Print dialog

Additional info:

Mousepad tries to do:
execve("/usr/bin/xfprint4", ["xfprint4", "/dev/stdin"], [/* 28 vars */])
but fails.

All xfprint really does in this case is link together mousepad and cups.

Having to drag in all of tetex* just to allow mousepad to print seems excessive, therefore either mousepad needs to be able to print directly to cups, or the dependencies of xfprint need to be re-evaluated.

Given that mousepad is the default text editor of the xfce spin, this is rather irritating.

--- Additional comment from kevin on 2009-12-01 23:34:11 EST ---

This is a nasty one. Mousepad hard codes calling xfprint. ;( 

I'll see if I can come up with a patch for something else. 

There is a RFE upstream to implement the gtk print dialog: 
http://bugzilla.xfce.org/show_bug.cgi?id=2542

Failing that, perhaps we should choose another simple text editor.

--- Additional comment from james.findley on 2009-12-02 10:20:23 EST ---

One possible (admittedly not pretty) solution is to do the following:

cat /usr/bin/xfprint4
#!/bin/bash

IFS=
data=`
while read -d '' -r -n1 x ; do
    case "$x" in
        '') printf "\x00" ;;
        *) printf "%s" "$x" ;;
    esac
done
`
printf "%s" $data | lpr -h


Of course this way we lose the print dialog, which is a bit of a usability issue, especially as the menu option for print has the '...' clue for a dialog.

I looked at the possibility of lifting the print dialog from leafpad, but leafpad is (usability wise) a drop in replacement for mousepad, with the addition of "print preview" and "open recent" functions, as well as a proper gtk print dialog,is not noticeably bigger (only 4k bigger binary & rpm), and so it may be easier and a better use of everyone's time to ditch mousepad in favour of leafpad.

--- Additional comment from cwickert on 2010-01-06 20:40:03 EST ---

Mousepad is a fork of leafpad with printing support added. Unfortunately development is pretty much stalled and in the meantime, leafpad has taken over again. I agree that the main reason for forking is obsolete, but the decision to ditch mousepad in favour of leafpad is something that should be done upstream. Upstream still plans to maintain it and do a complete rewrite:

"Regarding my rewrite, it's still
on the TODO list and now we depend on GIO a lot of things can be fixed
quite easily, however the amount of developers working on the Xfce
core is already (extremely?) low, so I'd rather focus on that until
4.8 is released (still have a panel to get into shape). But you never
know, maybe I'm done with other stuff and fixup some Mousepad issues
and do a development release. Who knows, but it's definitely not dead
yet."
http://foo-projects.org/pipermail/xfce4-dev/2009-December/027911.html

IMO we really should consider using leafpad (or the mousepad development version if there is one) in the F13 Xfce spin.

--- Additional comment from kevin on 2010-01-06 23:13:26 EST ---

>IMO we really should consider using leafpad (or the mousepad development
>version if there is one) in the F13 Xfce spin.

Ageed. 

Thanks for the other upstream news. Hope there is time to re-write it and fix this up.

--- Additional comment from cwickert on 2010-02-10 21:32:07 EST ---

Here are some testing packages of mousepad 0.3.0svn-r375a246:
http://cwickert.fedorapeople.org/xfce4/mousepad-svn/

Looks promising!

--- Additional comment from kevin on 2010-02-11 20:18:53 EST ---

Wow... very nice. :) 

I would be happy moving to that version. Tabs are good, it's still fast, printing seems to work fine. 
Having the encoding style is nice.

--- Additional comment from cwickert on 2010-02-11 20:55:29 EST ---

The problem is that it lacks translations ATM. If we can fix this with upstream, I have no problems shipping a snapshot. For me it turned out to be very stable.

--- Additional comment from kevin on 2010-03-08 11:38:23 EST ---

*** Bug 571401 has been marked as a duplicate of this bug. ***

--- Additional comment from frankly3d on 2010-03-08 11:51:22 EST ---

(In reply to comment #5)
> Here are some testing packages of mousepad 0.3.0svn-r375a246:
> http://cwickert.fedorapeople.org/xfce4/mousepad-svn/
> 
> Looks promising!    

mousepad-0.3.0-0.1.r375a246svn.fc12.x86_64

Is printing ok, on F13, F14(Rawhide) x86_64

--- Additional comment from kevin on 2010-07-18 15:43:45 EDT ---

I think we can close this now? The snapshot mousepad is in now?

Feel free to re-open if anything still needs to be done here.

--- Additional comment from cwickert on 2010-07-18 16:04:31 EDT ---

No, rawhide still had 0.2.16, see http://cvs.fedoraproject.org/viewvc/rpms/mousepad/devel/mousepad.spec?revision=1.15&view=markup

The problem with the 0.3.0 snapshot is that it lacks translations, see
http://git.xfce.org/apps/mousepad/tree/?h=mousepad-0.3.x&id=302307f9514125953b8520f40c5978dd2de423d8

--- Additional comment from kevin on 2010-07-18 16:07:45 EDT ---

Oops. I checked my machines here, where I had installed the new version to test. ;( 

Sorry about that.

--- Additional comment from triage.org on 2010-11-04 00:51:53 EDT ---


This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from triage.org on 2010-12-03 21:31:10 EST ---


Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.