Thanks for the replies. Honestly, I'm surprised. I thought there was some important technical reason behind this change.
On 8 фев, 00:31, Dave Land <[email protected]> wrote: > On Feb 7, 2011, at 7:39 AM, GrayFace wrote: > > -- The feature was all but unused by any but the most technical > users, who represent a tiny sliver of the overall GM user base. > > -- I gather that some sensed that the UI of GM was too complicated > for the majority of "casual" users. Removing the feature hardly makes anyone's life easier. I think Greasenonkey is used by somewhat technical people anyway, so they shouldn't get scared by UI simplicity not being taken to extreme. GM UI was very simple. The number of users of the feature may also be underestimated. The new UI has its flaws. 1) Scripts can't be rearranged by dragging, only via context menu. 2) I prefer more compact list of script names used in old version. 3) New version dosn't focus the scripts tab of Extensions window when I click "Manage scripts", it just sows the Extensions window at the last visited tab of it. And then, when I open Extensions window to manage extnsions I get to Greasemonkey scripts tab because it was open the last time. More clicks for no reason. > -- Other browsers' "GM-like" features (such as Google Chrome's > support for user scripts as a kind of "poor man's extension") do > not maintain a separate database of includes and excludes (as GM > has done 'til now, in the form of the config.xml file) but > require "technical" users who want to change which sites a > script addresses to find and modify the scripts themselves. Yep, GM is superior to them. On 8 фев, 01:00, Anthony Lieuallen <[email protected]> wrote: > > Generally correct. Plus the long standing issue of the strange fact > that Greasemonkey would always re-load changed source code, but not > changed metadata, when the file is (e.g.) edited. Now, any change to > the whole file is read and used, including adding a @resource or > @require (a feature that I find very useful). Yet, the number of people who change GM's xml manually is a very tiny fraction of those people that do change includes/excludes, hence prefer the old way... Now, here's what I think would be best: Basically the old way. When a script is updated GM can compare @includes in script with user's includes. If includes weren't customized, it can safely use includes from new script. If includes were customized and have changed in new version of the script, GM should ask user what to do. The most disturbing thing in the new version is that it doesn't carry over the old customizations in terms of editing. I mean, I needed to change includes for one of scripts and to do so I would have to manually look them up in some xml found in an unknown location, then add them into script as @include. I'm yet to see any advantage of the new version. WBR, Sergey Rozhenko -- You received this message because you are subscribed to the Google Groups "greasemonkey-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/greasemonkey-users?hl=en.
