182712 2009-02-01 13:49:38 +0000 Folderview applet does not remember symbol-positions when applying settings, although new settings should not affect the positions. 2018-06-08 18:40:55 +0000 1 1 10 Unmaintained plasma4 widget-folderview 4.7.2 openSUSE Unspecified RESOLVED UNMAINTAINED triaged NOR major --- 1 cyberbeat i.semenov.kde andresbajotierra aseigo asraniel bugz57 cpigat242 ereslibre fredrik hein holgerar i.semenov.kde kde leroy_tennison pier_andreit registrazioni ruchir.brahmbhatt szo vo.zaeb 39 oldest_to_newest 709209 0 cyberbeat 2009-02-01 13:49:38 +0000 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. 749531 1 ruchir.brahmbhatt 2009-04-29 12:11:34 +0000 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. 845135 2 asraniel 2009-10-14 22:53:18 +0000 *** Bug 210585 has been marked as a duplicate of this bug. *** 902471 3 40077 andresbajotierra 2010-01-20 18:19:33 +0000 Created attachment 40077 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. 903097 4 fredrik 2010-01-21 22:49:56 +0000 (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. 903100 5 andresbajotierra 2010-01-21 22:53:10 +0000 Thanks for checking it. - Can I commit the updated version of the fix ? Regards 903139 6 fredrik 2010-01-21 23:19:40 +0000 (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. 903153 7 andresbajotierra 2010-01-21 23:37:34 +0000 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 903156 8 40105 andresbajotierra 2010-01-21 23:48:05 +0000 Created attachment 40105 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) 903162 9 andresbajotierra 2010-01-22 00:00:03 +0000 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 903163 10 andresbajotierra 2010-01-22 00:04:26 +0000 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 931960 11 pier_andreit 2010-03-11 17:59:04 +0000 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 957257 12 asraniel 2010-05-05 14:36:22 +0000 what is the status of this bug? i see a commited patch, is the problem solved now? 963604 13 asraniel 2010-05-18 10:46:38 +0000 For the lack of feedback i suppose the last commits fixed the problem. 963709 14 cyberbeat 2010-05-18 14:07:55 +0000 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. 964686 15 pier_andreit 2010-05-20 14:55:35 +0000 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 1007580 16 cyberbeat 2010-08-21 15:08:37 +0000 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) 1007581 17 cyberbeat 2010-08-21 15:09:09 +0000 forgot to say, that this is now kde-4.5 1016733 18 aseigo 2010-09-09 20:06:02 +0000 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. 1032509 19 szo 2010-10-15 12:59:26 +0000 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. 1032534 20 szo 2010-10-15 13:39:48 +0000 (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. 1033433 21 stian 2010-10-17 18:09:26 +0000 *** This bug has been confirmed by popular vote. *** 1225537 22 i.semenov.kde 2012-02-11 09:53:36 +0000 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. 1229778 23 cyberbeat 2012-02-23 12:28:36 +0000 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) 1229779 24 cyberbeat 2012-02-23 12:30:33 +0000 @Ignat Semenov: I forgot to say, thanks for your current work on folderview! 1229781 25 i.semenov.kde 2012-02-23 12:37:05 +0000 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 :) 1229785 26 i.semenov.kde 2012-02-23 12:43:35 +0000 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. 1229789 27 cyberbeat 2012-02-23 12:53:46 +0000 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? 1229790 28 i.semenov.kde 2012-02-23 12:59:36 +0000 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? 1229830 29 cyberbeat 2012-02-23 14:52:39 +0000 I use opensuse kde-4.8 packages, for example kdebase4-workspace-4.8.0-1.1.x86_64 1232544 30 i.semenov.kde 2012-03-03 12:23:53 +0000 *** Bug 273761 has been marked as a duplicate of this bug. *** 1232555 31 i.semenov.kde 2012-03-03 13:01:07 +0000 *** Bug 244929 has been marked as a duplicate of this bug. *** 1232556 32 i.semenov.kde 2012-03-03 13:01:41 +0000 Added one more corner case:changing the desktop font in system settings. 1232680 33 bugz57 2012-03-03 22:19:03 +0000 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. 1232743 34 i.semenov.kde 2012-03-04 08:55:52 +0000 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. 1243844 35 bugz57 2012-04-08 01:19:44 +0000 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. 1243890 36 pier_andreit 2012-04-08 09:51:38 +0000 "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 1269784 37 registrazioni 2012-06-25 16:21:23 +0000 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. 1269817 38 i.semenov.kde 2012-06-25 18:29:05 +0000 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) 1269818 39 i.semenov.kde 2012-06-25 18:30:15 +0000 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 1296368 40 i.semenov.kde 2012-09-11 20:07:41 +0000 *** Bug 306629 has been marked as a duplicate of this bug. *** 1296955 41 holgerar 2012-09-13 12:00:54 +0000 > 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. 1296961 42 i.semenov.kde 2012-09-13 12:41:58 +0000 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. 1296964 43 i.semenov.kde 2012-09-13 12:44:33 +0000 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. 1296974 44 holgerar 2012-09-13 13:03:15 +0000 > 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. 1296976 45 holgerar 2012-09-13 13:10:18 +0000 > 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. 1327328 46 i.semenov.kde 2012-12-30 11:13:15 +0000 *** Bug 310595 has been marked as a duplicate of this bug. *** 1370327 47 hein 2013-05-22 01:35:02 +0000 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 1370328 48 hein 2013-05-22 01:36:49 +0000 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. 1370436 49 cyberbeat 2013-05-22 14:06:08 +0000 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. 1370574 50 hein 2013-05-23 09:32:30 +0000 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 ... 1372903 51 hein 2013-05-31 19:34:25 +0000 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 1372904 52 hein 2013-05-31 19:34:26 +0000 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 1481640 53 leroy_tennison 2014-11-17 20:17:08 +0000 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. 1481641 54 leroy_tennison 2014-11-17 20:20:42 +0000 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). 1757984 55 nate 2018-06-08 18:40:55 +0000 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 40077 2010-01-20 18:19:33 +0000 2010-01-21 23:48:05 +0000 Proposed patch folderview-preview-donotrearrange.diff text/plain 805 andresbajotierra SW5kZXg6IGZvbGRlcnZpZXcuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGZvbGRlcnZpZXcuY3BwCShyZXZp c2lvbiAxMDc3MTk1KQorKysgZm9sZGVydmlldy5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTYyMSw5 ICs2MjEsMTUgQEAKICAgICAgICAgY2cud3JpdGVFbnRyeSgic2hvd1ByZXZpZXdzIiwgbV9zaG93 UHJldmlld3MpOwogICAgICAgICBjZy53cml0ZUVudHJ5KCJwcmV2aWV3UGx1Z2lucyIsIG1fcHJl dmlld1BsdWdpbnMpOwogCisgICAgICAgIC8vU2F2ZSB0aGUgaWNvbiBwb3NpdGlvbnMKKyAgICAg ICAgUVN0cmluZ0xpc3QgaWNvbkRhdGEgPSBtX2ljb25WaWV3LT5pY29uUG9zaXRpb25zRGF0YSgp OworCisgICAgICAgIC8vRW5hYmxlL2Rpc2FibGUgdGhlIHByZXZpZXdzIChkaXNhYmxpbmcgaXQg d2lsbCBjYXVzZSBhIHJlYXJyYW5nZW1lbnQpCiAgICAgICAgIG1fcHJldmlld0dlbmVyYXRvci0+ c2V0RW5hYmxlZFBsdWdpbnMobV9wcmV2aWV3UGx1Z2lucyk7CiAgICAgICAgIG1fcHJldmlld0dl bmVyYXRvci0+c2V0UHJldmlld1Nob3duKG1fc2hvd1ByZXZpZXdzKTsKLSAgICAgICAgbmVlZFJl bG9hZCA9IHRydWU7CisKKyAgICAgICAgLy9SZXN0b3JlIHRoZSBpY29uIHBvc2l0aW9ucworICAg ICAgICBtX2ljb25WaWV3LT5zZXRJY29uUG9zaXRpb25zRGF0YShpY29uRGF0YSk7CiAgICAgfQog CiAgICAgY29uc3QgUUNvbG9yIGRlZmF1bHRDb2xvciA9IGlzQ29udGFpbm1lbnQoKSA/IFF0Ojp3 aGl0ZSA6Cg== 40105 2010-01-21 23:48:05 +0000 2010-01-21 23:48:05 +0000 New proposed patch folderview2.diff text/plain 2820 andresbajotierra SW5kZXg6IGZvbGRlcnZpZXcuY3BwCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGZvbGRlcnZpZXcuY3BwCShyZXZp c2lvbiAxMDc3MTk1KQorKysgZm9sZGVydmlldy5jcHAJKHdvcmtpbmcgY29weSkKQEAgLTYwOCwy NCArNjA4LDQ1IEBACiAgICAgY29uc3QgaW50IGZpbHRlclR5cGUgPSB1aUZpbHRlci5maWx0ZXJU eXBlLT5jdXJyZW50SW5kZXgoKTsKICAgICBLQ29uZmlnR3JvdXAgY2cgPSBjb25maWcoKTsKICAg ICBib29sIG5lZWRSZWxvYWQgPSBmYWxzZTsKKyAgICBib29sIHByZXNlcnZlSWNvblBvc2l0aW9u cyA9IGZhbHNlOwogCiAgICAgaWYgKG1fZHJhd1NoYWRvd3MgIT0gdWlEaXNwbGF5LmRyYXdTaGFk b3dzLT5pc0NoZWNrZWQoKSkgewogICAgICAgICBtX2RyYXdTaGFkb3dzID0gdWlEaXNwbGF5LmRy YXdTaGFkb3dzLT5pc0NoZWNrZWQoKTsKICAgICAgICAgY2cud3JpdGVFbnRyeSgiZHJhd1NoYWRv d3MiLCBtX2RyYXdTaGFkb3dzKTsKICAgICB9CiAKLSAgICBpZiAobV9zaG93UHJldmlld3MgIT0g dWlEaXNwbGF5LnNob3dQcmV2aWV3cy0+aXNDaGVja2VkKCkgfHwKLSAgICAgICAgKG1fcHJldmll d0dlbmVyYXRvciAmJiBtX3ByZXZpZXdQbHVnaW5zICE9IG1fcHJldmlld0dlbmVyYXRvci0+ZW5h YmxlZFBsdWdpbnMoKSkpCi0gICAgeworICAgIGlmIChtX3Nob3dQcmV2aWV3cyAhPSB1aURpc3Bs YXkuc2hvd1ByZXZpZXdzLT5pc0NoZWNrZWQoKSkgewogICAgICAgICBtX3Nob3dQcmV2aWV3cyA9 IHVpRGlzcGxheS5zaG93UHJldmlld3MtPmlzQ2hlY2tlZCgpOwogICAgICAgICBjZy53cml0ZUVu dHJ5KCJzaG93UHJldmlld3MiLCBtX3Nob3dQcmV2aWV3cyk7CisKKyAgICAgICAgLy9BcyBkaXNh YmxpbmcgdGhlIHByZXZpZXdzIHdpbGwgZm9yY2UgYSByZWFycmFuZ2VtZW50LCB3ZSBuZWVkIHRv IG1hbnVhbGx5CisgICAgICAgIC8vc2F2ZSBhbmQgcmVzdG9yZSB0aGUgaWNvbnMgcG9zaXRpb25z CisKKyAgICAgICAgUVN0cmluZ0xpc3QgaWNvblBvc2l0aW9uc0RhdGE7CisgICAgICAgIGlmICgh bV9zaG93UHJldmlld3MpIHsKKyAgICAgICAgICAgIC8vU2F2ZSB0aGUgaWNvbiBwb3NpdGlvbnMK KyAgICAgICAgICAgIGljb25Qb3NpdGlvbnNEYXRhID0gbV9pY29uVmlldy0+aWNvblBvc2l0aW9u c0RhdGEoKTsKKyAgICAgICAgfQorCisgICAgICAgIC8vRW5hYmxlL2Rpc2FibGUgdGhlIHByZXZp ZXdzCisgICAgICAgIG1fcHJldmlld0dlbmVyYXRvci0+c2V0UHJldmlld1Nob3duKG1fc2hvd1By ZXZpZXdzKTsKKworICAgICAgICBpZiAoIW1fc2hvd1ByZXZpZXdzKSB7CisgICAgICAgICAgICAv L1Jlc3RvcmUgdGhlIGljb24gcG9zaXRpb25zCisgICAgICAgICAgICBtX2ljb25WaWV3LT5zZXRJ Y29uUG9zaXRpb25zRGF0YShpY29uUG9zaXRpb25zRGF0YSk7CisgICAgICAgIH0KKyAgICB9CisK KyAgICBpZiAobV9wcmV2aWV3R2VuZXJhdG9yICYmIG1fcHJldmlld1BsdWdpbnMgIT0gbV9wcmV2 aWV3R2VuZXJhdG9yLT5lbmFibGVkUGx1Z2lucygpKSB7CiAgICAgICAgIGNnLndyaXRlRW50cnko InByZXZpZXdQbHVnaW5zIiwgbV9wcmV2aWV3UGx1Z2lucyk7CisgICAgICAgIG1fcHJldmlld0dl bmVyYXRvci0+c2V0RW5hYmxlZFBsdWdpbnMobV9wcmV2aWV3UGx1Z2lucyk7CiAKLSAgICAgICAg bV9wcmV2aWV3R2VuZXJhdG9yLT5zZXRFbmFibGVkUGx1Z2lucyhtX3ByZXZpZXdQbHVnaW5zKTsK LSAgICAgICAgbV9wcmV2aWV3R2VuZXJhdG9yLT5zZXRQcmV2aWV3U2hvd24obV9zaG93UHJldmll d3MpOworICAgICAgICAvL0NoYW5pbmcgdGhlIHByZXZpZXcgcGx1Z2lucyB3aWxsIGFsc28gbmVl ZCBhIHJlbG9hZCB0byB3b3JrLCBzbyB3ZSBuZWVkIHRvIHByZXNlcnZlCisgICAgICAgIC8vdGhl IGljb25zIHBvc2l0aW9uCiAgICAgICAgIG5lZWRSZWxvYWQgPSB0cnVlOworICAgICAgICBwcmVz ZXJ2ZUljb25Qb3NpdGlvbnMgPSB0cnVlOwogICAgIH0KLQorICAgIAogICAgIGNvbnN0IFFDb2xv ciBkZWZhdWx0Q29sb3IgPSBpc0NvbnRhaW5tZW50KCkgPyBRdDo6d2hpdGUgOgogICAgICAgICAg ICAgUGxhc21hOjpUaGVtZTo6ZGVmYXVsdFRoZW1lKCktPmNvbG9yKFBsYXNtYTo6VGhlbWU6OlRl eHRDb2xvcik7CiAgICAgY29uc3QgUUNvbG9yIGNvbG9yID0gdWlEaXNwbGF5LmNvbG9yQnV0dG9u LT5jb2xvcigpOwpAQCAtNzIzLDggKzc0NCwxNyBAQAogICAgIH0KIAogICAgIGlmIChuZWVkUmVs b2FkKSB7CisgICAgICAgIC8vTWFudWFsbHkgc2F2ZSBhbmQgcmVzdG9yZSB0aGUgaWNvbiBwb3Np dGlvbnMgaWYgd2UgbmVlZCBpdAorICAgICAgICBRU3RyaW5nTGlzdCBpY29uUG9zaXRpb25zRGF0 YTsKKyAgICAgICAgaWYgKHByZXNlcnZlSWNvblBvc2l0aW9ucykgeworICAgICAgICAgICAgaWNv blBvc2l0aW9uc0RhdGEgPSBtX2ljb25WaWV3LT5pY29uUG9zaXRpb25zRGF0YSgpOworICAgICAg ICB9CisgICAgICAgIAogICAgICAgICBtX2Rpck1vZGVsLT5kaXJMaXN0ZXIoKS0+b3BlblVybCht X3VybCk7CiAKKyAgICAgICAgaWYgKHByZXNlcnZlSWNvblBvc2l0aW9ucykgeworICAgICAgICAg ICAgIG1faWNvblZpZXctPnNldEljb25Qb3NpdGlvbnNEYXRhKGljb25Qb3NpdGlvbnNEYXRhKTsK KyAgICAgICAgfQogICAgICAgICAvLyBTbyB0aGUgS0ZpbGVJdGVtQWN0aW9ucyB3aWxsIGJlIHJl Y3JlYXRlZCBmb3IgdGhlIG5ldyBVUkwuCiAgICAgICAgIGRlbGV0ZSBtX2l0ZW1BY3Rpb25zOwog ICAgICAgICBtX2l0ZW1BY3Rpb25zID0gMDsK