Suggestion: Visibility toggle for individual bags/backpack
tflo opened this issue · 18 comments
Could be implemented in the submenu of the contextual menu of the main button (along with 'Assign to Bag', 'Ignore this Bag').
Why?
Usually the backpack or/and one of the bags are filled with my char's "private" basic stuff, like hearthstones, teleport cloaks/tabards/rings, Battle Standard, Glider Kit, etc.
These items are exclusively used via keybind/button/script/macro, that is, they are never actually right-clicked in the bag. Seeing them every time the bag is opened is basically just a (visual) waste of space.
This would be similar to AdiBag's visibility toggle for categories, just for bags.
Thanks for considering,
– Tom
PS2:
In case you're gonna implement it, please make the bag visibility setting char-specific, not global.
(Normally, as a multi-alt player, I passionately hate any addon with char-specific settings, but in this case it really is better.)
PS:
I just found out that Bagnon has this implemented via simple left click on a bag icon. This is indeed more elegant than my context-menu proposal, and I think it would perfectly fit also with LiteBag, since it seems left and right click on a bag icon have redundant functionality in current LiteBag (picking up a bag for moving).
Nice that this is still open :)
Recently I was playing around with LiteBag again and I was delighted to see that you have added a visibility toggle via bag-clicking for the reagent bag.
Well, this is almost what I suggested, and with a little bit more, it does exactly what I suggested:
diff --git a/LiteBag/BagButton.lua b/LiteBag/BagButton.lua
--- a/LiteBag/BagButton.lua
+++ b/LiteBag/BagButton.lua
@@ -159,22 +158,22 @@
-function LiteBagBagButtonMixin:OnClick()
+function LiteBagBagButtonMixin:OnClick(btn)
local bagID = self:GetID()
if CursorHasItem() then
if bagID == Enum.BagIndex.Backpack then
PutItemInBackpack()
elseif not self.purchaseCost then
PutItemInBag(self.slotID)
end
elseif self.purchaseCost then
PlaySound(SOUNDKIT.IG_MAINMENU_OPTION)
BankFrame.nextSlotCost = self.purchaseCost
StaticPopup_Show('CONFIRM_BUY_BANK_SLOT')
- elseif IsShiftKeyDown() then
- if bagID == Enum.BagIndex.ReagentBag then
+ elseif btn == 'LeftButton' then
+ if bagID ~= Enum.BagIndex.Backpack then
local hide = LB.GetGlobalOption('hideBagIDs')
hide[bagID] = not hide[bagID] or nil
LB.SetGlobalOption('hideBagIDs', hide)
end
elseif bagID ~= Enum.BagIndex.Backpack and bagID ~= Enum.BagIndex.Bank then
PickupBagFromSlot(self.slotID)
end
end
- Visibility toggle for all bags except backpack.
- Works with simple left click (could not detect any interference, right click and left-dragging are still available for pickup).
- Since we have two mouse buttons that do exactly the same on the bag buttons, that means one of them is free for other things. So no need for a modified click, IMHO. (Also, this is not a destructive action, so no click protection needed either.)
Hi there,
Actually doing all the bags would be a little bit less work. But I tried it and I don't think it fits with LiteBag and the way it puts all the slots together. it works for Reagent Bag because it's always separated out but not nicely for the others. I think it's better suited to other addons that keep the bags separate.
Thanks for your suggestion and I do appreciate it, but what's there now is all that I'm going to do.
Best wishes, X.
Actually doing all the bags would be a little bit less work.
Now, I'm using it as posted in the diff above, and it works fine. Am I missing some unexposed (to me) problems with this?
But I tried it and I don't think it fits with LiteBag and the way it puts all the slots together. it works for Reagent Bag because it's always separated out but not nicely for the others.
Good point. I always use LiteBag with the Separated Bags layout, so this was completely out of my awareness.
Thanks for your reply, and most of all for LiteBag! It's my preferred bag addon at the moment (with my little additional mods), and I think it will be for quite a while
All the best to you too
– Tom
Sorry that was my (poor) attempt at a joke, that actually I had to do a little bit more work originally to restrict it just to the reagent bag. I should know better than to try jokes at my age!
I'm sure it's not much consolation but I do feel bad about it. I've just been doing this long enough to have a gut feel for what kinds of things are going to cause me a support nightmare and this looks like one of them. To tell the truth I'm still not sure the hideable Reagent Bag is a good idea either.
As a real consolation I've released 10.1.7-3 with a hidden slash command to allow you to hide more bags.
/lb allowhide
Options for allowhide (multiple possible):
- [1] Bag_1
- [2] Bag_2
- [3] Bag_3
- [4] Bag_4
- [5] ReagentBag *
- [6] BankBag_1
- [7] BankBag_2
- [8] BankBag_3
- [9] BankBag_4
- [10] BankBag_5
- [11] BankBag_6
- [12] BankBag_7
/lb allowhide 1
/lb allowhide 2
/lb allowhide 3
/lb allowhide 4
You'll still have to hold SHIFT but you can at least force LiteBag to allow you to hide them
I kind of half-assed the way the hidden bags are indicated.
Maybe adding a "Hide" dropdown menu entry (like for the reagent bag) could make it more obvious too? Not that I'm using the dropdown to hide the bags, but I think for a user who is wondering why his bag has "disappeared", it could be a helpful clue.
Out of interest what rez do you run in?
Running native resolution (5120×2880) with a render scale somewhere in the range of 0.375 and 0.5. But I think the last weeks I always had it at 0.4, which translates to 2048×1152:
"Resolution" is the one for the UI elements, "render scale" is the effective resolution for the "World".
But it seems that the render scale does not affect the snap area at all, and if I change the base resolution, the snap area remains the same relative to other UI elements (of course, if I were to measure the snap distance with a yardstick on the screen, it would become larger at lower resolution).
I should know better than to try jokes at my age!
Then, I guess, that was another joke (the correlation between age and the funnyness of jokes) 🙃
things are going to cause me a support nightmare and this looks like one of them
Understandable. 10 new issues a day with "%^&#$ LiteBag has deleted my bag #2 and all of its contents!" is nothing to joke about.
As a real consolation […] hidden slash command to allow you to hide more bags
I took that :) Since I currently only hide bag #5 (sometimes) and #4 (always), it's not much of a hassle.
Though I've merged back my 'no Shift modifier' change (as I'm un/hiding bag #5 quite often), but I promise you to never complain about deleted bags ;)
While we're at it: 2 more small changes I'm using for some time and I'm finding quite good:
- Less Alpha for hidden bag buttons (I'm using 0.24 instead of 0.333)
- Larger snap area (using 128^2 instead of 64^2)
Not going to open a separate issue for this, as I'm sure you've played around with different values and found your current ones to be optimal. But who knows…
Thanks again for the good addon!
I kind of half-assed the way the hidden bags are indicated. When I was doing most of the playing with it I couldn't figure out what the texture for the circle was (turns out its just :GetNormalTexture()) and I never went back to it. It does need to be more obvious but I'm not sure even less alpha is the answer. It may be that desaturating is enough now that I can grey out the ring too. I'll try to have another look at it when I have time.
Out of interest what rez do you run in? I suspect the snap area might be better scaled with the screen. 64 seemed ok or a bit big with 1080p, and ok or a bit small with 1440p. If you are running 2k it might definitely be too small. I think 128 is going to be way too big for people with smaller resolutions. Or maybe I've forgotten how it works and it scales automatically.
Good thing, with the higher opacity but additional desaturation in 10.1.7-4 :) It looks good, and the visual difference to the unhidden buttons is OK too, I think.
The snap area is too big at 64 pixels
Out of curiosity, what is your horizontal snap distance? (In relative terms, e.g. compared to the width of the quest tracker or minimap.)
The (edit) snap circle will be more into the screen if you have right action bars activated, as it uses the blizzard default bag position.
Looked at this again, and in fact I have the opposing view (unlike what I remembered). The snap area is too big at 64 pixels, not too small. Oops. I think I'll leave it alone.
(As an aside, it's not a 64x64 square, it's a 64 pixel distance from the cursor to the snap point, essentially a circle.)
I've adjusted the way the hidden bags are shown with desaturate and 0.5 alpha. I think this is probably the opposite of what you want, but I think it looks great. Regardless, thanks for prompting me to take another look at it.
I'm not 100% sure how to answer that.
I meant just the horizontal distance immediately before it snaps.
I assume your screenshot shows the snap distance for 64^2, then it's (relative to the objective tracker width) indeed roughly the half of my 128^2. I just wanted to be sure if we really have such a different perception of what is too big and what is not. But apparently we do ;)
I've set up the LiteBagSnapAnchor
frame like in your snippet (with 128 size), but the circle is far from my actual snapping distance (with 128^2 at line 40 in Frame.lua):
The bag frame position shows my actual snap distance (well, a few pixels left to the snap distance):
You need to SetSize yours to (256, 256) to get the size if you have the radius distance set to 128 (the diameter is 2 x radius).
It's not squared I'm just not bothering to sqrt for no reason.
Pythagoras theorem:
x^2 + y^2 = z^2
so my z is 64 pixels. I could do
sqrt(x^2 + y^2) < 64
but I dont bother because
x^2 + x^2 < 64^2
is the same check.