Red Hat Bugzilla – Bug 852078
mousepad requires xfprint to print
Last modified: 2012-09-21 16:30:54 EDT
+++ 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 ...
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):
Steps to Reproduce:
"Can't open pipe to process"
Mousepad tries to do:
execve("/usr/bin/xfprint4", ["xfprint4", "/dev/stdin"], [/* 28 vars */])
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 firstname.lastname@example.org 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:
Failing that, perhaps we should choose another simple text editor.
--- Additional comment from email@example.com on 2009-12-02 10:20:23 EST ---
One possible (admittedly not pretty) solution is to do the following:
while read -d '' -r -n1 x ; do
case "$x" in
'') printf "\x00" ;;
*) printf "%s" "$x" ;;
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 firstname.lastname@example.org 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
IMO we really should consider using leafpad (or the mousepad development version if there is one) in the F13 Xfce spin.
--- Additional comment from email@example.com 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.
Thanks for the other upstream news. Hope there is time to re-write it and fix this up.
--- Additional comment from firstname.lastname@example.org on 2010-02-10 21:32:07 EST ---
Here are some testing packages of mousepad 0.3.0svn-r375a246:
--- Additional comment from email@example.com 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 firstname.lastname@example.org 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 email@example.com on 2010-03-08 11:38:23 EST ---
*** Bug 571401 has been marked as a duplicate of this bug. ***
--- Additional comment from firstname.lastname@example.org on 2010-03-08 11:51:22 EST ---
(In reply to comment #5)
> Here are some testing packages of mousepad 0.3.0svn-r375a246:
> Looks promising!
Is printing ok, on F13, F14(Rawhide) x86_64
--- Additional comment from email@example.com 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 firstname.lastname@example.org 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
--- Additional comment from email@example.com 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 firstname.lastname@example.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:
--- Additional comment from email@example.com 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.
I'll look at updating to a git snapshot upstream.
Note that we don't have mousepad in the Xfce comps group or in the kickstarts for any media anymore...
I've updated mousepad in rawhide to a git snapshot that no longer has anything to do with xfprint. ;)
Depending on how stable it proves, might push it to stable releases as well.
We should also edit comps then and switch back from leafpad to mousepad.
ok, if we want to do that, should I also push to f18?
Or shall we save this until f19?
IHMO F18 should be fine.
mousepad-0.3.0-0.1.20120827git88aba4.fc18 has been submitted as an update for Fedora 18.