Disabling USE flag toolbar on emerge =x11-wm/fluxbox-1.3.5 has no effect. Problem with this is that starting lxpanel with fluxbox gives the error "tray: another systray already running" and applications cannot sit in lxpanel's tray. Same error as Bug 537356.
Is this 1.3.5 or 1.3.7? The bug title says 1.3.7 but the first comment says 1.3.5.
Sorry for confusion. It is for 1.3.7 and the problem here is the same as was in 1.3.5 solved with Bug 537356.
(In reply to charles17 from comment #2) > Sorry for confusion. It is for 1.3.7 and the problem here is the same as > was in 1.3.5 solved with Bug 537356. Aha. Based on what I could find in my local portage tree, the fix I put for bug 537356 didn't get applied to fluxbox-1.3.7.ebuild as well. I'll attach a one-liner patch to fix this. It just needs `$(use_enable toolbar systray)` in src_configure(). I'm still in the process of becoming a developer, so it may be some time before it's in the Gentoo tree.
Created attachment 402502 [details, diff] Patch for fluxbox-1.3.7.ebuild, fixes systray bug This single-line patch "forward ports" the fix from bug 537356 to fluxbox 1.3.7
Created attachment 402540 [details, diff] Optional systray I had worked worked this a bit yesterday. I don't really like saying the systray must be enabled if toolbar is enabled. I can't really think of a use case for it, but it's easy enough to support it. If you're okay with it, I'll commit this to the tree.
(In reply to Aaron W. Swenson from comment #5) > > I can't really think of a use case for it, but it's easy enough to support > it. If you're okay with it, I'll commit this to the tree. I'd prefer the way how it works in 1.3.5-r1 (without additional USE flag).
(In reply to charles17 from comment #6) > (In reply to Aaron W. Swenson from comment #5) > > > > I can't really think of a use case for it, but it's easy enough to support > > it. If you're okay with it, I'll commit this to the tree. > > I'd prefer the way how it works in 1.3.5-r1 (without additional USE flag). The additional use flag is enabled by default; there wouldn't notice a difference unless the use flag is explicitly disabled. So, I don't understand your aversion to the additional use flag when it won't have an impact on you.
(In reply to Aaron W. Swenson from comment #7) > > So, I don't understand your aversion to the additional use flag when it > won't have an impact on you. Don't take me wrong. I just need way to disable systray since I am using systray of lxpanel. Putting "x11-wm/fluxbox -toolbar -systray" in package.use is ok for me. Looking forward to your patch hitting the tree.
(In reply to Aaron W. Swenson from comment #5) > Created attachment 402540 [details, diff] [details, diff] > Optional systray > > I had worked worked this a bit yesterday. I don't really like saying the > systray must be enabled if toolbar is enabled. > > I can't really think of a use case for it, but it's easy enough to support > it. If you're okay with it, I'll commit this to the tree. How many stand-alone systray applications are there, and will they even work with a Fluxbox built without systray support (but with toolbar support)? The only one I can think of is stalonetray, which hasn't been reported to work with Fluxbox and was only recently revived (0.8.2 this past February after nothing since 2010). I'm hesitant to add support for a use case that hasn't been described or confirmed to be possible. As it stands, running Fluxbox with toolbar but without systray would result in some applications becoming (almost) inaccessible when closed or minimized, since they depend on a tray being present. I'd like to have the chance to look around at what applications are actually available to fulfill the use case before we tack on an extra USE flag that would need testing. I have the next three days off of work, so I should have some sort of answer soon. But right now, I don't see it being a realistic case. If we do in fact decide to separate the USE flags, they need to depend on each other: the case that your patch covers (systray requiring toolbar), and the reverse (toolbar being disabled also disabling systray).
Created attachment 402626 [details] fluxbox-1.3.7-fix-systray-error.patch.out (In reply to Daniel Campbell from comment #4) > Created attachment 402502 [details, diff] [details, diff] > Patch for fluxbox-1.3.7.ebuild, fixes systray bug > > This single-line patch "forward ports" the fix from bug 537356 to fluxbox > 1.3.7 Tried to apply this patch 1. downloaded patch to /etc/portage/patches/x11-wm/fluxbox-1.3.7/ 2. created /etc/portage/bashrc with pre_src_prepare() from https://wiki.gentoo.org/wiki//etc/portage/patches 3. emerge -1avt =x11-wm/fluxbox-1.3.7 and got this error. What am I doing wrong?
(In reply to charles17 from comment #10) > Created attachment 402626 [details] > fluxbox-1.3.7-fix-systray-error.patch.out > > (In reply to Daniel Campbell from comment #4) > > Created attachment 402502 [details, diff] [details, diff] [details, diff] > > Patch for fluxbox-1.3.7.ebuild, fixes systray bug > > > > This single-line patch "forward ports" the fix from bug 537356 to fluxbox > > 1.3.7 > > Tried to apply this patch > > 1. downloaded patch to /etc/portage/patches/x11-wm/fluxbox-1.3.7/ > > 2. created /etc/portage/bashrc with pre_src_prepare() > from https://wiki.gentoo.org/wiki//etc/portage/patches > > 3. emerge -1avt =x11-wm/fluxbox-1.3.7 > > and got this error. What am I doing wrong? From what I can tell, the method described in the wiki is for patching the package itself (for ebuilds that don't use epatch_user), not the ebuild. If you want to apply my patch before it reaches tree, you'll need to copy the current fluxbox-1.3.7.ebuild into a local overlay, make sure it's present in /etc/portage/repos.conf/local.conf (or similar), apply the patch to the ebuild, and `repoman manifest` in the overlay. Or... I maintain an overlay on GitHub that can be used as an intermediary fix, if you'd like. It can be found at https://github.com/sporkbox/sporkbox-overlay . To add it, put the following into a file such as /etc/portage/repos.conf/sporkbox.conf: [sporkbox] sync-type = git sync-uri = git://github.com/sporkbox/sporkbox-overlay.git auto-sync = yes location = /usr/local/portage (I had it setup locally, so I tested this specifically to make sure it'd work for you :) Then run `emaint sync -r sporkbox`. Then you can either mask fluxbox::gentoo in package.mask, or explicitly install what you're after with this: USE="-toolbar" emerge -a1 fluxbox::sporkbox The version in my overlay should match the result of my patch. Note, however, that this bug isn't fixed until my patch (or an equal fix) is in the tree. I hope this helps fix your problem while we decide on how to go forward in the ebuild.
(In reply to Daniel Campbell from comment #11) > (In reply to charles17 from comment #10) > > From what I can tell, the method described in the wiki is for patching the > package itself (for ebuilds that don't use epatch_user), not the ebuild. If > you want to apply my patch before it reaches tree, you'll need to copy the > current fluxbox-1.3.7.ebuild into a local overlay, make sure it's present in > /etc/portage/repos.conf/local.conf (or similar), apply the patch to the > ebuild, and `repoman manifest` in the overlay. > Thanks so much for your help, it was my misreading that wiki article. So I did test your patch directly using patch /usr/portage/x11-wm/fluxbox/fluxbox-1.3.7.ebuild < attachment.cgi?id=402502 and it worked well. Now I am having fluxbox-1.3.7~ with lxpanel's systray.
Aaron: I've tested Fluxbox with the proposed systray USE flag. With fluxbox-1.3.7 [-systray toolbar slit], I have confirmed that both x11-misc/stalonetray and x11-plugins/docker will work (with some command line flag setting) and place systray icons in Fluxbox's slit. Since these use cases exist and are possible, I agree that changes should be made. Your patch works fine, so as far as I'm concerned, we're good. I'll apply it to my overlay, as well. :)
*fluxbox-1.3.7-r1 (06 May 2015) 06 May 2015; Aaron W. Swenson <titanofold@gentoo.org> +fluxbox-1.3.7-r1.ebuild, metadata.xml: Fix bug 547990. Thanks to Daniel Campbell for testing.
