Bug 182712 - Folderview applet does not remember symbol-positions when applying settings, although new settings should not affect the positions.
Summary: Folderview applet does not remember symbol-positions when applying settings, ...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: plasma4
Classification: Plasma
Component: widget-folderview (show other bugs)
Version: 4.7.2
Platform: openSUSE Unspecified
: NOR major
Target Milestone: ---
Assignee: Ignat Semenov
URL:
Keywords: triaged
: 210585 244929 273761 306629 310595 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-01 13:49 UTC by H.H.
Modified: 2018-06-08 18:40 UTC (History)
17 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Proposed patch (805 bytes, patch)
2010-01-20 18:19 UTC, Dario Andres
Details
New proposed patch (2.75 KB, patch)
2010-01-21 23:48 UTC, Dario Andres
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H.H. 2009-02-01 13:49:38 UTC
Version:            (using KDE 4.2.0)
Installed from:    SuSE RPMs

I really spent much work in positioning my folder-view-icons in a custom way. And then changed some settings which should not affect the positions, but all icons were sorted again from top-to-bottom .. all work gone :(

Although I had the setting active for sort-order:unsorted (seems to be a misunserstanding?).

I would recommend following changes in the folder-view-settings:

If I activate a (new to implement) checkbox "symbol-order". if this checkbox is not checked, the options for "symbol order:vertical/horizontal" and "symbol-sorting:a,b,c,.." should be greyed out. And even these settings only should apply to newly added (not dragged) symbols. To force a reorder, this should not be a "setting" but an "action", for example from right-click-menu on folder-view. perhaps another checkbox for always forcing the selected order even for dragged items (or without such a checkbox,  force these settings always, so that the user is unable to drag something to special-position). Do the symbol-order-settings make sense, if icons are not aligned to grid (difficult)?

the only setting that should slightly affect the positions, should be "align to grid".

if a already have enabled the setting "align to grid", the setting-change for the icon-text-row-count should not effect the grid-structure (cell x,y) of custom positions in many cases. currently a change of this completely reorders the icons in every case.

same applies for the symbol-size-setting.

I see no reason why the preview-settings should change the positions.

If I do not have aligned my icons to a grid, then the first rule for applying such settings, which may effect the positions, should be aligning to grid, and trying to avoid big changes from positions in cell-grid.
Comment 1 Ruchir Brahmbhatt 2009-04-29 12:11:34 UTC
Qt: 4.5.1
KDE: 4.2.70 (KDE 4.2.70 (KDE 4.3 >= 20090415))
kdelibs: r960298
kdebase: r960293

I switched to folder view, changed some icon positions and did align to grid and also tried lock in place. No problem till now but when I changed the icon size, the icons were sorted and my changes were lost.
Comment 2 Beat Wolf 2009-10-14 22:53:18 UTC
*** Bug 210585 has been marked as a duplicate of this bug. ***
Comment 3 Dario Andres 2010-01-20 18:19:33 UTC
Created attachment 40077 [details]
Proposed patch

When enabling/disabling the previews, "needReload" should not be set to true, it is not really needed.... (the icons' size doesn't change)

However, as KFilePreviewGenerator will *force* a reload when disabling the previews (http://lxr.kde.org/source/KDE/kdelibs/kfile/kfilepreviewgenerator.cpp#1145), we need to manually save and restore the icons position after setting the previews to false.
Comment 4 Fredrik Höglund 2010-01-21 22:49:56 UTC
(In reply to comment #3)
> Created an attachment (id=40077) [details]
> Proposed patch
> 
> When enabling/disabling the previews, "needReload" should not be set to true,
> it is not really needed.... (the icons' size doesn't change)
> 
> However, as KFilePreviewGenerator will *force* a reload when disabling the
> previews
> (http://lxr.kde.org/source/KDE/kdelibs/kfile/kfilepreviewgenerator.cpp#1145),
> we need to manually save and restore the icons position after setting the
> previews to false.

The patch looks good except for one thing; setIconPositionsData() should only be called before the folder is opened/reloaded. The reason for this is that the data is used in the next layout pass and is then cleared. If the folder isn't reloaded after this function is called, the data will stick around and be used the next time something causes the layout to be changed instead.

So in this case it should only be called when m_showPreviews is false.
Comment 5 Dario Andres 2010-01-21 22:53:10 UTC
Thanks for checking it. - Can I commit the updated version of the fix ?
Regards
Comment 6 Fredrik Höglund 2010-01-21 23:19:40 UTC
(In reply to comment #5)
> Thanks for checking it. - Can I commit the updated version of the fix ?
> Regards

Sure, and thanks for looking into this issue.
Comment 7 Dario Andres 2010-01-21 23:37:34 UTC
Darn, I discovered a flaw...
Disabling/enabling plugins (without touching the previews enabled/disabled settings) also need a refresh in order to work .... :-\
May be I can think of another solution
Comment 8 Dario Andres 2010-01-21 23:48:05 UTC
Created attachment 40105 [details]
New proposed patch

Split up the handling of previews enabled/disabled and preview plugins (as the last one needs to manually a reload the view)
Comment 9 Dario Andres 2010-01-22 00:00:03 UTC
SVN commit 1078287 by darioandres:

- Preserve the icons' position when modifying the preview settings

CCBUG: 182712


 M  +36 -6     folderview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1078287
Comment 10 Dario Andres 2010-01-22 00:04:26 UTC
SVN commit 1078289 by darioandres:

Backport to 4.4 of:
SVN commit 1078287 by darioandres:

- Preserve the icons' position when modifying the preview settings

CCBUG: 182712


 M  +36 -6     folderview.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1078289
Comment 11 pier andre 2010-03-11 17:59:04 UTC
and add an horizontal scroll bar to folder view, if I place my icons where I like and then resize the folder view the icons are shifted from where I placed. If them are blocked on site and unsorted and unordered this shouldn't happen
Comment 12 Beat Wolf 2010-05-05 14:36:22 UTC
what is the status of this bug? i see a commited patch, is the problem solved now?
Comment 13 Beat Wolf 2010-05-18 10:46:38 UTC
For the lack of feedback i suppose the last commits fixed the problem.
Comment 14 H.H. 2010-05-18 14:07:55 UTC
sorry, i have to reopen.

some things are fixed for me now, like "align to grid" and some other options do not re-layout my desktop unintentionally. thanks for that.

but there are still cases, where these bug does apply:
for example I make the icon-size smaller. in this case there is really no need to throw away my relative icon-position-grid. and even if I would make the icons larger, I think there are better ways to re-align the icons than do a complete re-layout.
Comment 15 pier andre 2010-05-20 14:55:35 UTC
and also to what H.H says, should be fine to add an horizontal scroll bar to folder view, if I place my icons where I like and then resize the folder view the icons are shifted from where I placed.
If them are blocked on site and unsorted and unordered this shouldn't happen
Comment 16 H.H. 2010-08-21 15:08:37 UTC
another problem: drag a file (move) from dolphin to desktop: all positions are lost, and the symbol is not placed at the position, where I dropped it (it is sorted in the newly sorted icon-list)
Comment 17 H.H. 2010-08-21 15:09:09 UTC
forgot to say, that this is now kde-4.5
Comment 18 Aaron J. Seigo 2010-09-09 20:06:02 UTC
comment #16 is not the same issue as this one (which is about changes due to configuration). please keep reports to precisely one topic at a time. thanks.
Comment 19 Szokovacs Robert 2010-10-15 12:59:26 UTC
I'm not sure I have the same issue, so please let me know if I need to file a separate ticket.

I'm using the folderview activity on my desktop, and I noticed these strange things:
a, the file .kde/share/config/plasma-desktop-appletsrc have the savedPositions line, but it's not always reflects the actual position of the icons. Probably updated "lazily", but sometimes it's too lazy and doesn't get updated at all.
b, after logout/relogin, the icons go back to their default position, while the .kde/share/config/plasma-desktop-appletsrc contains the correct, saved position information, and the config file isn't updated until I move an icon; then (after a while) it will contain the default positions, except for the one I just moved.
Comment 20 Szokovacs Robert 2010-10-15 13:39:48 UTC
(In reply to comment #19)

> b, after logout/relogin, the icons go back to their default position, while the
> .kde/share/config/plasma-desktop-appletsrc contains the correct, saved position
> information, and the config file isn't updated until I move an icon; then
> (after a while) it will contain the default positions, except for the one I
> just moved.

One more thing: if I point it to an empty folder and create a couple of text files using the GUI and scramble those icons, they seem to be able to retain their position.
Comment 21 Stian Viskjer 2010-10-17 18:09:26 UTC
*** This bug has been confirmed by popular vote. ***
Comment 22 Ignat Semenov 2012-02-11 09:53:36 UTC
Now let us recap.

https://bugs.kde.org/show_bug.cgi?id=182712#c16 could not be present as of 2010-08-21:the commit that fixed that behavior is dated 2008!

The icon size change leading to a loss of saved icon positions is another bug and will be fixed.
Comment 23 H.H. 2012-02-23 12:28:36 UTC
I am now on kde-4.8 and tried again to drag a file from dolphin to the desktop:

- the other icons keep their positions (good)
- the dropped icon is not visible, I have to press F5 to make it visible (bad)
- the dropped icon has not the position I dropped it to, but seems to use the first free position from top-left to bottom (bad)
Comment 24 H.H. 2012-02-23 12:30:33 UTC
@Ignat Semenov: I forgot to say, thanks for your current work on folderview!
Comment 25 Ignat Semenov 2012-02-23 12:37:05 UTC
OK, thank you for the fast reply :)

The icon is not visible, have to F5 - I couldn't reproduce it, maybe it's because you have a lot of icons filling up all the desktop space or something? Certain details are obviously missing here.

Icon positioned not where it's dropped - well, at the moment it's put in the first empty position, that's correct. Now let's see. You have the icons custom positioned, so you wish the dropped icon to stay where you dropped it. But if the icons are sorted, then maybe the user wants to keep them sorted even after the drop? We need a compromise here. he code change is pretty trivial anyway :)
Comment 26 Ignat Semenov 2012-02-23 12:43:35 UTC
Also, the commit that fixed that problem is dated Sep 17 2008, so you could not experience this in 2010 Maybe you've mixed smth up there in c#16? :) It just couldn't be, according to the Git logs.
Comment 27 H.H. 2012-02-23 12:53:46 UTC
my desktop only has a few icons. I tried dropping a second time now, this time the icon appeared 1-2 seconds later without refreshing manually. I also have such problems sometimes with dolphin (that items are not refreshed automatically, or much later than they should).

for the other problem in c#16: I don't think I have mixed smth up, and I cannot switch back now to reproduce, but perhaps that was a cornercase like the above problem.

I suggest to close this bug (but not forget the problem with drop positions), and I reopen when I find a method to reproduce folderview destroying icon positions again?
Comment 28 Ignat Semenov 2012-02-23 12:59:36 UTC
The bug can not be closed as it's about icons size change destroying the positions as well.

Now Dolphin is a separate component, it uses a different view, soit's unrelated here.

Please, which kde package version are you using? If you use a *buntu derivative, could you please specify the version of the "plasma-widget-folderview" package?
Comment 29 H.H. 2012-02-23 14:52:39 UTC
I use opensuse kde-4.8 packages, for example
kdebase4-workspace-4.8.0-1.1.x86_64
Comment 30 Ignat Semenov 2012-03-03 12:23:53 UTC
*** Bug 273761 has been marked as a duplicate of this bug. ***
Comment 31 Ignat Semenov 2012-03-03 13:01:07 UTC
*** Bug 244929 has been marked as a duplicate of this bug. ***
Comment 32 Ignat Semenov 2012-03-03 13:01:41 UTC
Added one more corner case:changing the desktop font in system settings.
Comment 33 Volker Kuhlmann 2012-03-03 22:19:03 UTC
Bug still exists in KDE 4.7.2 of openSUSE 12.1. Just about any small change randomly swaps icons with each other, making folder view close to unausable.
Comment 34 Ignat Semenov 2012-03-04 08:55:52 UTC
Wait wait. "Just about any small change randomly swaps icons with each other" - what do you mean? There used to be a problem which I fixed for 4.8.1 where sorting results were sometimes inconsistent because the names were not taken into account for making the comparison, and this problem was sometimes described as random icon positioning.

Now this bug is about the following:

When you have custom icon positions (i.e. drag some icons around on the desktop and the sorting becomes "unsorted"), then on certain configuration changes, such as  icon size change, font size change, plasma theme change, and probably some others, the custom icon positions would be lost.

This is absolutely logical if you think about it, as the view needs to relayout the icons using the new size hints. Moreover, some icons may end up outside of the view if e.g. the new icon size is greater than the old one, and fixing this is not as simple as it may seem. We are working on a solution.
Comment 35 Volker Kuhlmann 2012-04-08 01:19:44 UTC
Ignat, you are seeing this from a programmer's perspective: you analyse the code, think about which part might be causing the problem, and look at how that can be changed. I am looking at it fromt he user's perspective. Where the problem is and what the problem report is called are not really of interest.

The problem is that people expect icons to remain in their grid position. This is expected behaviour ever since Billy 95, or over 17 years. The folderview locates itself prior to that. So someone changes icon size. All the icons become smaller. People still expect them to keep their position in their grid, even though each grid cell is now smaller/bigger. It has worked in 1995, and everyone is eager for KDE to catch up... ;-)

Likewise for basically every other change. Custom icon positions are expected to remain in their grid location. The absolute screen location is of no interest. Even if the grid is turned off, relative loations are expected to remain. Even after icon size changes. Multiply all screen coordinates by 0.8 for a 20% icon size reduction if you want/need.

"The view needing to re-layout" is or isn't logical, it's useless for the user. Icons "ending up outside of the view" doesn't make sense, there are scrollbars for that which suddenly appear, and that would probably be preferable - user can then decide whether to move icons, put up with scrollbars, make the view bigger, whatever, but doesn't loose the previous layout work, which is the worst possible view behaviour and extremely irritating.

I've turned the views off on all my hosts becuse for me they are unusable. I retested this after upgrading to openSUSE 12.1 / KDE 4.7.2.
Comment 36 pier andre 2012-04-08 09:51:38 UTC
"The problem is that people expect icons to remain in their grid position.">>>>>>>>=totally approve

"The view needing to re-layout" is or isn't logical, it's useless for the user. Icons "ending up outside of the view" doesn't make sense, there are scrollbars for that which suddenly appear, and that would probably be preferable - user can then decide whether to move icons, put up with scrollbars, make the view bigger, whatever, but doesn't loose the previous layout work, which is the worst possible view behaviour and extremely irritating.>>>>>=totally approve, many thanks Volker Kuhlmann to be able to express also my thinking so well, the idea to add horizontal scrollbar to folderview sprung to me too, and I cannot understund why this isn't made until now. :-)
Ciao Pier
Comment 37 Iacopo Benesperi 2012-06-25 16:21:23 UTC
I'd like to add another problem to this, I hope it fits this bug.

First: I'm running KDE 4.8.3 on Debian Wheezy and I use 1 activity with a full-screen folder view, to have a "classic" desktop.

Without changing settings or anything, if there are too many icons on the desktop, when I reboot the icons don't keep their position on the grid but they get moved (without any sort that I can see) from their position and put one after the other from top left going down. With "too many icons" I'm not talking about a big amount of icons, just the equivalent of three full columns of icons at 1280x800.
I don't know what trigger this precisely, but the number of icons present seems the only explanation to me right now.
Comment 38 Ignat Semenov 2012-06-25 18:29:05 UTC
Do you use custom icon positions Iacopo? (i.e. drag icons manually to a certain position, whether "Align to grid" is on or off does not actually matter here)
Comment 39 Ignat Semenov 2012-06-25 18:30:15 UTC
Oh wait, that comment was for another bug, sorry. Actually, the last report from Iacopo Benesperi is for the bug https://bugs.kde.org/show_bug.cgi?id=265774
Comment 40 Ignat Semenov 2012-09-11 20:07:41 UTC
*** Bug 306629 has been marked as a duplicate of this bug. ***
Comment 41 Holger Arnold 2012-09-13 12:00:54 UTC
> When you have custom icon positions (i.e. drag some icons around on the
> desktop and the sorting becomes "unsorted"), then on certain configuration
> changes, such as  icon size change, font size change, plasma theme change,
> and probably some others, the custom icon positions would be lost.
> 
> This is absolutely logical if you think about it, as the view needs to
> relayout the icons using the new size hints. [...]

This logic is flawed.  Whenever the user has manually moved some icons, no configuration change should _ever_ change the positions of these icons.  Do we want to automatically undo user actions?

The underlying problem of this bug is that the user can only get custom icon positions implicitly by setting "Sorting" to "Unsorted" and then moving his icons.  A better solution would be:
(1) let the user choose _either_ automatic _or_ manual arrangement;
(2) only when automatic arrangement is selected, let the user choose a particular layout (top to bottom etc.) and sorting order;
(3) when manual arrangement is selected, _never ever_ touch the icon positions.
Comment 42 Ignat Semenov 2012-09-13 12:41:58 UTC
Holger, it already works like that. If you drag some icons around, then folderview switches to "unsorted" automatically. Once you change the sorting strategy or the flow, folderview switched to the "sorted" mode the new sorting / flow settings are applied.

Now for the icon position loss on various view configuration changes. Imagine you have increased the number of text lines under icons, do you want the icon text to overlap the image of the icon below? Or if you change icon size like 2-3 fold, then some icons may end up being out of the view. This is a difficult problem that  requires a thorough analysis of all the possible corner cases, it can't be solved right on.
Comment 43 Ignat Semenov 2012-09-13 12:44:33 UTC
We can indeed classify the various reasons for icon position loss, like icon text related changes (global KDE font size or typeface change, number of text lines in folder view change), then icon size change, grid size change, etc., and handle them separately, in order to minimize the negative impact on the user. There is no generic solution for this problem.
Comment 44 Holger Arnold 2012-09-13 13:03:15 UTC
> Holger, it already works like that. If you drag some icons around, then
> folderview switches to "unsorted" automatically. Once you change the sorting
> strategy or the flow, folderview switched to the "sorted" mode the new
> sorting / flow settings are applied.

That's what I said: it is implicit.  There is no indication for the user whether is icons are arranged automatically or not.  I think it would be better to have the user explicitly say "yes, please arrange my icons" or "no, don't touch them".

> Now for the icon position loss on various view configuration changes.
> Imagine you have increased the number of text lines under icons, do you want
> the icon text to overlap the image of the icon below? Or if you change icon
> size like 2-3 fold, then some icons may end up being out of the view. This
> is a difficult problem that  requires a thorough analysis of all the
> possible corner cases, it can't be solved right on.

I agree that it's not easy for automatic arrangement, but for manual arrangement, it is: don't touch the icons.  A user who chooses to arrange his icons manually _wants_ to do it on his own.  If the icons overlap, let them overlap.  If some get out of view, the user can use a scrollbar.
Comment 45 Holger Arnold 2012-09-13 13:10:18 UTC
> We can indeed classify the various reasons for icon position loss, like icon
> text related changes (global KDE font size or typeface change, number of
> text lines in folder view change), then icon size change, grid size change,
> etc., and handle them separately, in order to minimize the negative impact
> on the user. There is no generic solution for this problem.

Well, there can be no generic solution, simply because no program can read the minds of its users.  For this reason, I would rather have a program that behaves predictably, rather than a program that tries to be semi-intelligent.
Comment 46 Ignat Semenov 2012-12-30 11:13:15 UTC
*** Bug 310595 has been marked as a duplicate of this bug. ***
Comment 47 Eike Hein 2013-05-22 01:35:02 UTC
Git commit f86bf88770cf2e3b6518ddbcb96990596b892d3f by Eike Hein.
Committed on 22/05/2013 at 03:22.
Pushed by hein into branch 'KDE/4.10'.

Preserve relative positions when changing icon size in containment case.

Icon positions are preserved by scaling the top-left coordinate pair
by the difference between the old and new grid sizes, or by recreating
the same logical column/row coordinate pair in the newly-calculated
grid if the align-to-grid option is enabled.

Icons that run out of bounds (or exceed the maximum column or row)
accumulate at the relevant screen edges. There is a precedent for
this behavior in the general align-to-grid code.

The left-to-right or right-to-left flow is taken into account when
scaling.

Smarter behaviors can be imagined as an optimization (e.g. identi-
fying groups of icons along screen edges and preserving their edge
alignment regardless of overall layout flow), but this simple scaling
implementation certainly beats throwing positions away altogether.

However, positions do still get thrown away in the non-containment
case - as the regular widget is capable of handling overflow via a
scrollbar, relayouting to exploit that felt better in practice.

M  +74   -9    plasma/applets/folderview/iconview.cpp
M  +1    -1    plasma/applets/folderview/iconview.h

http://commits.kde.org/kde-baseapps/f86bf88770cf2e3b6518ddbcb96990596b892d3f
Comment 48 Eike Hein 2013-05-22 01:36:49 UTC
Note that in addition to the above commit, I have recently fixed at least three different causes of loss of custom icon positions when modifying the Folder View config, moving icons while the config dialog is open, and changing the workspace theme. There may still be other problems lurking, but I hope it's getting increasingly rare for someone to use lose their carefully arranged icon positions. Cheers.
Comment 49 H.H. 2013-05-22 14:06:08 UTC
thank you! lately someone takes care of these very important issue :-)

I would be very happy, when these fixes would also apply for the non-containment (desktop?) case.  The case, when icons are out of sight, could be handled by taking the nearest free position for example? would be still better than losing all positions.
Comment 50 Eike Hein 2013-05-23 09:32:30 UTC
Yeah, would be nice ... I have to get back to some other stuff before feature freeze for now, but I'll think about what we can do there.

And for the QML port we can rethink things from the ground up to make handling position data a priority - IMHO this is simply a data loss problem and data shouldn't be lost without a good reason ...
Comment 51 Eike Hein 2013-05-31 19:34:25 UTC
Git commit c4a4efae68dc3bbb94fd67438853f6f50858d380 by Eike Hein.
Committed on 31/05/2013 at 21:33.
Pushed by hein into branch 'KDE/4.10'.

Don't throw away icon positions when changing the text color.

M  +1    -0    plasma/applets/folderview/folderview.cpp

http://commits.kde.org/kde-baseapps/c4a4efae68dc3bbb94fd67438853f6f50858d380
Comment 52 Eike Hein 2013-05-31 19:34:26 UTC
Git commit c0d0eadd0cbd7ffee3ea0a84cec2abf7609a5672 by Eike Hein.
Committed on 31/05/2013 at 21:33.
Pushed by hein into branch 'master'.

Don't throw away icon positions when changing the text color.

M  +1    -0    plasma/applets/folderview/folderview.cpp

http://commits.kde.org/kde-baseapps/c0d0eadd0cbd7ffee3ea0a84cec2abf7609a5672
Comment 53 leroy_tennison 2014-11-17 20:17:08 UTC
Icons "auto magically" rearranging themselves is still happening.  I'm guessing I'm on KDE 4.13 ('rpm -qa | grep -i KDE' shows 4.11, 4.12 and 4.13 depending on the rpm).  I arranged my icons as I wanted, right-clicked the desktop, selected "Icons->Align to grid" and this worked nicely.  Also selected "Lock  in place" and couldn't move the icons.  Then I decided to a taskbar...  Even with "Lock in place" the icons auto-rearranged.

My first recommendation is that, in this/these situation(s), a warning be issued about re-arrangement with an option to cancel.  Second recommendation, make every effort to accommodate the change without changing the relative layout (shift the icons up/down/left/right, compress spacing, reduce icon size if "increase" wasn't the requested action) if possible and, third recommendation, produce an error message (and abandon the change) if this isn't possible.
Comment 54 leroy_tennison 2014-11-17 20:20:42 UTC
In case the version specification is still ambiguous, I'm running a late version of  OpenSuse 13.1 (downloaded about a month before the 13.2 release).
Comment 55 Nate Graham 2018-06-08 18:40:55 UTC
Hello!

This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug has already been resolved in Plasma 5.

Accordingly, we hope you understand why we must close this bug report. If the issue described  here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham