Surveydaddy
Check out Surveydaddy, the most easy-to-use survey software around. Start creating beautiful online surveys today.
Create an Online Survey
Posted 3 months ago.
See this poll on: http://wordpress.org/news/2011/11/wherefore-art-thou-widgets/…
http://www.sanjamusic.com/
danlod music
دانلود
Keep it until I delete the corresponding them OR
I manually delete the saved settings (all or for a particular theme)
Oh: Please let me also COPY widget-settings to and from Child themes!
Or, another idea: Let me define my own widget-pools, numbered from 1 to 20 (or as many as I need...)
Then, rather than putting a widget into a panel area, I put a link to my widget-group. Of course, the same group may and will be used in several different themes, as well as may be added to several different panel areas. If I then edit my widget group, the same changes will be reflected in every single place this group is referred!
Now that I think of it, it should be possible already now, to define a super-widget in an add-on. But I'm not they guy to code it! :)
How about also including an option to match widgets from current theme to widgets on new theme.
It drives me crazy to have all widgets setup and have to do it all again for the new theme too when I just want the same stuff.
I guess the other work around is to ALWAYS use custom widgets - at least they are there regardless of theme.
My vote is for the ability to export widget settings and import (into new placeholders) as and when required.
Maybe place the widgets into a 'Previous Theme' area instead of the inactive widgets panel.
In keeping with other comments here I'd say keep indefinitely, certainly as long as the previous theme is available.
Ian
Diane, hardly the place for questions. And no, unless you're using nightly builds for your site, there's absolutely no way this could've affected you. Fix the styling of your posts instead.
As for the widgets, drop this idea! There's obviously way too many complications with it no matter what solution is chosen, seems like it will cause more problems than it would solve. If someone wants to switch themes let them take responsibility for that themselves. I can imagine this is a nightmare from a coding standpoint. So drop it!
If an option has to be chosen, of all the options above the export/import option seems best if one is going to be chosen at all.
Allow for users to set their own times, with a reasonable default like 1 month, or even 90 days.
Currently WordPress has the *VERY BAD* default behaviour of dumping all widgets into the inactive widgets area even when you just switch between child themes and/or a parent theme which all by definition usually have the same number of widgetised areas.
Each time I changed the theme, I saved my DB to restore then. It would be the best if I could just save only the widget settings as an XML or such dump file for backup instead of the whole DB.
Looking at it from only switching themes is a little limiting.
We recently built a theme that allows the user to add/remove widget positions with ease to extend or slim down the theme as needed. Postions can be added, removed as well as temporarily disabled.
This caused massive issues, because disabling a position would mean all widgets were lost when re-enabling a widget position. So the same issue as switching themes is occuring within the same theme.
The timelines are kinda irrelavant, it should be saved as long as you are using the theme and until you delete it... or choose to do so manually.
Give us the options to
- Save widget states
- Restore widgets
- Reset widgets
The widget saver plugin does this and it works flawlessley and resolved our problems explained above.
http://wordpress.org/extend/plugins/widget-saver/
Just another suggestion.
Please make it easy to backup and restore (import/export) our widgets. So if I switch to a new theme and I want its widget configuration so my site looks like their demo. I can use the import file provided by the themelet developer to import the widget settings.
Currently the content importer works great for content, but widgets are left in the dark. This would make it easy to duplicate any theme demo with utmost ease.
I voted for indefinitely.
I have a theme that is hardly mentionable here in WordPress WalHalla, but there the configuration (until now) is kept indefinitely...and that is helpful.
I'd say "never", "indefinitely" or "ask". Any other time period seems arbitrary and unpredictable, which is definitely a bad UX call.
It seems like there are two related issues that need to be considered:
1. restoring Theme A's widgets if the configuration is different from Theme B, and
2. applying new Theme B widgets added subsequently
We can't programmatically make a decision about which Theme B widgets were added "post configuration" and which were added to correct a misconfiguration due to switching from Theme A.
I think the only choice would be, when switching back to Theme A, a dialog shows me my existing (Theme B) widgets, my Theme A (indefinitely saved) widgets and highlights the delta, allowing me to cherry pick before applying the Theme A switchover.
Probably out of scope for 3.3
t
My first reaction was "1 month", thinking this gives me time to reconsider during setup time of a new site. But in hindsight I do not believe that any time frame is the correct answer as each situation calls for a different approach. Once it gets in the way, then again you wish you had the original widget setup back. What would be perfect is to be able to save the states, just as you can do with revisions.
Theme A state 1 saved on so-and-so-date-and-time.
Theme B state 1 saved on so-and-so-date-and-time.
Theme A state 2 saved on so-and-so-date-and-time.
Have these saved states available on the widget page. Maybe even allow a state be applied on a different theme, which would cut back on the tons of redoing the same configurations over and over?
I'd prefer to keep it until I switch to another theme (Theme C) therefore the "Old Configuration" will be the config of Theme B or when the Theme A has been deleted
I would like it if there was a way to export/save the widget configuration to a file, and then be able to load/import/toggle between different configurations. Having it in a file would mean you could do things like install a widget configuration pre-optimized for your new theme.
How about saving the current configuration indefinitely with a user option to delete old or unused configurations after X days?
I think it would be best to be able to save, load, and delete widget snapshots. This could be in the database or to an external file. That gives the user the most control.
What the hell happened? I woke up this morning, pulled up my site, and the sidebar widgets in the Twenty Ten theme had dropped all the way to the bottom of the page, after the stories. There is still space for them next to the stories. I've tried but I can't figure out what to do about this. Does this have anything to do with you experimenting with the widgets?
TELL ME WHAT TO DO!
A potential problem with retaining widgets with themes over extended periods of time: while we're "away" from Theme A to flirt with B, Theme A isn't necessarily standing still. Which brings in the complications of (again, potentially) having to retain widget versions as well as theme versions.
I voted "other," suggesting that the admin be prompted for a duration at theme-change time -- default one week, as a compromise between CYA and OCD: enough time to realize, like, Whoops, I want to go back, while not prolonging a decision indefinitely. If you've got a drop-down box with numerous choices, the admin can choose the duration of his/her liking. No need to mandate a one-size-fits-all solution, I think.
This is good feature , suppose i have some widgets i set them on my sidebar , so there should be an option through which i can save these widgets with a name suppose i say "my 1st sidebar" , now if i got another theme it has by defult different widget , so i can swith it to my 1st sidebar , or i can save it with a differnet name! say "my 2nd sidebar" this will be cool option!
Yes, saving the widfet configuration is a good idea.
But, when I return to Theme A, it should ASK ME if I want to use the old configuration of widgets.
In some cases I could have added/removed so many widgets, that it would be easier to start from scratch than to use the old configuration.
I would love it keep the widget config indefinitely. Just because I change a theme, doesn't mean the information I've added to a widget is different. I still have the same Twitter and Facebook accts. I still want my Meta info to be on the page. That's one thing that I really hate about working with WordPress, having to start over whenever I change a theme. It would be amazing if you guys would fix this.
I simply love Wordpress. Please I beg you please to add this feature, it has been a pain in the butt for me as I have many times completely lost some widget content, one of them just an hour ago. The best would be, to add an option where users can choose how long to save them. I want to offer clients pre-designed themes on a demo site. Thus far if I add a theme switcher on the sidebar, the widgets are removed, making it impossible for users to switch back and forth. Needless to say when I change or upgrade an existing theme
I recall changing screen resolutions on my PC and Windows has 60sec delay for me to confirm before it reverts back to old resolution in case the new one messes up my screen.
For WP 3.3,
Other than Activate and Preview, add "Finalize". and "Cancel"
- When user Activate new theme, new theme takes over. (with warning about diff widget configs)
- When user is happy with results, he clicks Finalize and old theme widget config details are deleted.
- If user is not happy, he clicks Cancel and wordpress reverts to the old theme with its last known working configuration.
Save the old widget configuration indefinitely.
I prefer a wizard that asks the following when I change theme:
WARNING! Some widget areas do not match the new theme!
Do you want to
a) deactivate them or
b) select alternative locations for them now?
This will be more user-friendly.
The implementation is a small price to pay for user-friendliness.
-Wang
Sent from my iPhone.
Hahah! Way to astutely defend the philology of your existential antipathy, Jane. :D
But really, this feels a bit like a "lazy" feature to me. If I change themes like my socks then I accept responsibility, man up (or woman up, but I'm a man so...), and make the necessary changes. Be it websites, software, or PLC's, I don't expect the framework to offer such retention, especially given the hidden overhead. I'd rather see a preset system, so I can save the currently used widgets and make the adjustment for whatever purpose I deem (be it an existentially conflicted theme change). This keeps the tools in my hands as the developer, and I like new tools. :)
If you're going to implement this feature, may as well implement it all the way, and have it save the widgets indefinitely. Otherwise, it will probably be useless, since people don't normally plan on switching themes. It just happens.
Need to transfer widgets and their settings/data as a unit, between blogs.
I voted for 'other'. Specifically, default it to one day but allow a user to specify in their settings what the default time is for their staging area.
I'm all over the idea of saving any number of widget groups or configurations for easy retrieval, editing and activation.
I think having all the options available would be the best idea personally.
Dear Kevin Taylor: I'm familiar with the definitions of wherefore (why isn't the only one). I never thought it meant 'where' as you suggest. If you'd dug a little deeper (as I see Paul Gregory eventually did), you'd have found that this widget change thing is not a 'where' question.
I personally don't like the feature, I think it is too potentially confusing, and I would have preferred this not happen at all/that we tackle a better widget project in 3.4 that's more wizard style instead of the application making unexpected changes to sidebars at all. But, I don't get to just decide things myself (much as I sometimes get accused of same), and I was outvoted on this one, so getting some high-level user feedback is meant to help us come to agreement on what implementation of this makes sense for 3.3. (And no, that doesn't mean we won't do an overall better job later. Iterative improvement is always the plan.)
So, in fact, I was using the word intentionally to represent my own existential crisis-like feelings about the very existence of this widgets feature and the eventuality it portends. Hmph.
Set this up like Windows 'System Restore' where you can take 'snapshots' of your theme/widgets whenever you want (or it happens automatically when you switch themes), and you can restore them to any point in history any time you want.
I posted some text between arrows and dashes and it disappeared...lol
Here it is again.
It is the "widget map" I am referring to.
"WIDGET MAP"
(--------------HEADER WIDGET--------------)
( content )(----RIGHT---)
(---FOOTER LEFT--)(--FOOTER-RIGHT--)
Cheers!
First off, the present Wordpress Widgets area interface really needs some brushing up.
Unless I am using it wrongly, I just hate to scroll down, hold & drag a widget from the bottom of page, scroll to top of page where widget area is and let go. Sometime I misses...
The convenience of drag-n-drop is lost. .. Give me a drop down menu too.
As for saving of widget configurations,
I voted OTHERS.
My suggestions:
1. Widget configuration should be THEME BASED. It holds the last widget placement config before it was deactivated.
2. Show us widget areas the way AS THEY APPEAR ON MY SITE. A "widget map" if you will. Not just a long list of boxes on the right side of the screen.
>
3. Each template to include its "widget map" by default. Can be a XML file.
4. As themes are deactivated, the "widget map" snapshot is saved.
I use both Wordpress and Joomla. I believe both can learn from one another. (Well, the widget map is my own idea...)
Looking forward to constructive comments and bashing :)
-Will
Can I recommend using a dictionary before misquoting Shakespeare?
Wherefore means "why", not as you appear to believe, "where".
In the scene misquoted, Juliet is bemoaning the fact that Romeo is a member of the Montague family, sworn enemies of her own family, the Capulets, and she asks why (wherefore) this should be.
Until the admin delete it manually
How about... never? I design and deploy WordPress-based sites for clients, and there is never a reason to switch themes until/unless they pay me or someone else to do it for them.
But since so many seem to favor this, an option to turn off the retention of widget placement data would be nice... otherwise it's just more junk in the database.
After reading through the Trac conversation on this, a couple of thoughts:
1. This is not just a UX problem. (Re: @ipstenu) We're now talking data retention, DB maintenance, etc.
2. Widget data could have been created by either a plugin or a theme, so to remove them on theme change doesn't make sense.
3. A full-fledged widget manager and migration wizard is the "ideal" solution to deal with orphaned widget data. But in the absence of that, WP should keep the data until the admin decides to delete it. This problem is sustantial enough to warrant user notifications on theme change, and an "orphaned" area in the widget section.
Bottomline, anyone knowledgeable enough to switch themes should be responsible enough to manage their data.
I've chosen the option Other in the Poll.
My motivation: I'd say as long as the theme where the widgets are saved to is installed, keep the configuration of the widgets.
When the theme gets uninstalled, generally you don't want to return to it (for whatever reason) so then delete the widget configuration along with it.
Regards, Mike.
It's pretty simple. One should be able to save the appearance configuration of their site multiply and severally, irrespective of theme such that any previous configuration may be restored. All that need be done is to implement the use of multiple .conf files.
If there's anyting wrong with Wordpress, it's how the Widgets are managed. For CMS development, the Widgets can be really important, but every time I put one in, I tremble to think what would happen if they suddently disappear.
There is a plugin that saves Widgets settings, but I can't say I really trust it - when I move the CMS from the development server to the final server, some of the Widgets simply vansih, and the Widget Settings plugin doesn't help there at all.
There ought to be a way to keep the Widgets saved perpetually in the database, so that CMS developers could have some faith in them still being there tomorrow.
It would be great if 'we' could decide from the admin back end whether we wanted to keep them indefinitely, a week, a month etc ourselves.
Just an option page with how long to store them from they WP back end is all that's needed. Extremely useful feature nonetheless looking forward to 3.3 more and more.
I like the idea of being able to save a configuration, but otherwise, saving it until the associated theme is deleted sounds good to me.
Make it so that you can save widget configurations, thus allowing users to have different configs for the same themes.
1a) When linking themes, there could also be a "widget reconciliation" that gives the admin the ability to copy widgets between the themes, or have it automatically done by dumping unmatched widgets into purgatory zones.
Hmmm...
Alternatively... you could just have a "Theme Reconciliation" feature by itself, without the linking, so that the admin is always in control of widgets across themes. Still, in this case, it would be useful if duplicate widgets could be made to have their settings stay in synch, if the admin wants it that way.
I agree with previous comments that this should be a stored configuration. I'd like the overall ability to save combinations of widget placements and their positions with the ability to switch back and forth between them at will. Something like this could be easily modified to save module configurations for different themes for an indefinite period, or you could go back and delete the configuration when you decided you didn't need it anymore.
I'm concerned that this problem is not being approached from the best angle.
After some consideration, "indefinite" is probably the best choice from the list, but then that leaves open the possibility of switching back to an old theme after piling widgets into a new one, and then thus having to add back the newer widgets. Also consider that some WordPress sites allow users to switch themes.
Might I suggest a solution...
1) First, provide a way to "link" themes, I guess similar to how layers are linked in Photoshop (not sure if that's the best analogy, but I'll run with it). This would keep Theme A "widget placement aware" while Theme B is having its widgets updated. Part of this linking would give the admin the option of matching sidebars between the themes being linked for the sake of what I describe in #2 -- just because sidebars have the same name doesn't mean they should be considered as the same).
2) When adding a widget to Theme B in a sidebar not present (actually, not matched) in Theme A, add a duplicate widget to Theme A's new widget purgatory zone called "Theme B Additions" (using actual theme name, plus "Additions"). This way, the widget's settings are preserved, and if the admin goes back to using Theme A, the widgets are there and already tailored for use. There could also be a confirmation for this add to Theme A.
3) This would all work in both directions as long as the themes are linked.
4) If any updates are made in a widget that was duplicated in another theme, the updates would also apply to the duplicate.
Anyone care to join my brainstorming? :)
I'd say for as long as the theme files exist (as long as the theme is still in the blog).
Could you treat it like "revisions" ? plus associate a theme and theme version with it.
Allow the saving, and sharing of widget areas.
When a person changes themes step in and ask, do you want to backup your previous widgets?
Yes, creates a freeze associated with the theme and theme rev #
Install the new theme and it continues...
What does it store though? Sometimes a sites CSS will focus on something like "widget-3" if you save a configuration of widgets and then reload it, would the "widgets" be renumbered?
I voted for indefinitely. What if someone, like me, wants to test that new theme for a month or more? Then if they suddenly dislike the new set up, they can return to their old set up, whenever they like. Oh there should be an option in the dashboard to configure this, and a manual deletion of the old configuration by pressing a button, and a confirmation box will appear telling the user that if they chose to delete the old configuration, they lose it forever. Something like that would be really cool.
I agree with Douglas Bell. It should save indefinitely and ask when you revert to an old theme whether you would like the widgets to revert as well.
I think taht all we need is an option to export the widget configuration.
This way we can
a) store it until we need.
b) move it from one site to another (maybe when we go live with a new site we developed elsewhere)
c) apply it to whatever site we need.
Stefano
I'm going with "Other" here and also suggesting we need "Save/Export" functionality. Great to recreate stuff if we reuse on other sites.
Why not create a "widget manager" that would allow you to create and save multiple arrangements of widgets, or "widget groups". When you switch templates, the widget manager could save an instance of the widgets at that moment and copy this instance into a new group for the new theme. Then, upon switching back to the old theme, you could prompt the user to choose between their old widget group or their new widget group (or even to create a whole new group).
Of course the admin should be able to manage these groups and add/modify/delete them at any time. Not sure how possible any of this is, but it's a suggestion worth thinking about.
Have a field where the user can simply enter the number of days to save widget setting.
Would a system similar to the current export system for content work? Have an xml file that can either 1) be downloaded or 2) saved into the theme folder - WordPress can either scan the folder for the file and bring it in manually upon a new theme activation or you can specify to upload the file manually.
I don't think, saving widget configurations would take up much spaces. So, let it be saved indefinitely. However, a way to configure it (through plugin or build-in) would be better.
a week is good enough.
Just put a select menu in the Settings panel with all or some of these choices...easy as it gets!
OK. I may have given the impression (mainly elsewhere) that I thought our polling host Jane was on the bad side of this nonsense. It is clear to me from the IRC logs and Trac that Jane has been on the side of sanity from day 1.
I've now read the Trac (above link and http://core.trac.wordpress.org/ticket/19291 ) and relevant IRC for the "auto-expiring backup" idea. I thank Jane for bringing this stupidity to my attention. The answer to Jane's question "At what point does it go from handy timesaver to unexpected widget mangler?" is "about three months ago".
I still don't think everyone commenting or voting understands that the archiving of widget configs with a "best before" date stamped on them is new for 3.3.
I think it is an absolutely horrendous idea. It's rotten in its implementation.
Matthew Boynes, and others calling for better widget configuration, I agree. It looks like this kind of major overhaul was a possible for 3.4. However I suspect that the short-sighted faffing about with widgets seen in 3.3 makes it less likely. A shame.
Some great comments. I voted for other. Adding versioning to widgets is a good idea and take a screenshot using gd is a nice thought. The biggest issue is if you upgrade the system and many plugins, and try and load an old config it could break.
This could be overcome by using similar to Drupal where it drops plugins if they don't meet the health check. You'd simply use the same method when previewing templates to see if they work, but it would be cool to have a debug/performance dump at the same time to review the health.
Good luck, I know you'll make the right choice.
Associate the widget configuration with the theme. Delete the theme then the widget configuration goes with it. Perhaps offer an option to purge a theme's widget configuration within the widget admin area. To be honest, the poll is delivering somewhat expected results in keeping the configuration indefinitely. However, I'm not keen on redundant configuration data just hanging around in the database.
I like what Sid has suggested, and I was thinking something similar. Widgets could get stored in configuration groups (or sets, as Sid proposed) that can easily be swapped in or out. Store them indefinitely with the option to delete at will. There could be an area on the widget page for "recent configurations" which would allow one to easily map previous sidebar areas after switching themes.
Thanks Ipstenu. I'll wade through that and see if it's just too late to steer this ship away from the iceberg. I'm not particularly happy about data storage decisions being led by user expectations rather than use cases. There are times when UX should not be the squeakiest wheel.
I think there's a lot of misunderstanding in the above comments (including no doubt in my own piece) about what is actually proposed and how it works now.
See, the problem (if I understand correctly) is that in 3.2 widget area config isn't theme based, it's widget area based. Some widget areas are common to themes, some aren't.
Upon reflection, I have sites where I would want to go back to one configuration and sites where I'd want updates to one widget configuration to be reflected in other themes that use the same one. Although my alarm was at needlessly deleting things, I now realise that the "keep a backup forever" would actually be rubbish for the second case! Essentially though, I'm right to be scared by the notion of "old".
It looks like WP widget area reuse is headed in a direction that I cannot influence by the appropriate naming of widget areas in themes I control.
For what it's worth, I'd prefer to see widget management along the lines of what TJ List suggests - which is basically the way that Menus currently work. User defines Menu, assigns it to a menu position in the Theme Locations box. User can remove any menus that are no longer in use after theme changes.
The Menus approach is good - but would be better if there was an option to automatically create matching menus if there weren't any. With that in place, it would be a good model for how widgets should work.
Anyway. Off to Trac to see what exactly led to this peculiar poll. (If this poll was "How long do you need widget configurations for non-active themes to be retained?" it would be of far more use.)
Make it theme-based. Problem solved.
Paul Gregory - Two things.
1) Jane works for Automattic - her control over UX is her job :)
2) The trac ticket is http://core.trac.wordpress.org/ticket/17979
I agree with what one of the early commenters (Greg Robson) said above. I don't see this option as taking up much disk space and it would certainly not affect the speed of the new (current) theme (as the setting would be linked to the old theme). So why not just make it a permanent setting ("indefinitely"), only to be deleted with the deletion of the theme itself (that part is important, I would think)?
Your average human can't keep track of things at such an abstract level. That's why we have todos and calendars, and I can't really see adding "WARNING: Wordpress will reset widget cache" to either.
Don't enforce granularity for the sake of it. The more we're forced to manage our time the less time we have to manage. I can hardly believe the amount of space used by widget-config data is any more than an hours worth of apache logging for the average site, so keep the data around please.
Until the theme is deleted/removed is the best answer.
Either an admin confit or even better widgets per theme are saved with the theme until the theme is deleted.
I voted for one week, and now I want to change my vote to "indefinitely."
I agree that the current system is broken. I tell people to take a screen shot of the active widgets before changing their theme because they will get lost.
I would rather have a way to save a widget's settings as a site-based "group" that is theme-independent. Then I could determine whether to assign this group of widgets to a particular area of my site.
For example, I might name one group "Sidebar Widgets," another "Footer Widgets," or "Home Page Widgets-left column."
I could select, update, or activate multiple widgets into a particular theme's widget area(s) with one drag/drop.
Changing a theme? Simply assign a widget group to the appropriate area. Done.
This is a great idea for the already awesome widget framework! Maybe have an option (that's enabled by default) to "remember prior widgets?" Users who rarely change their theme have no reason to store that additional info, regardless of how little.
I cannot believe that this question is seriously being asked in this way. It leaves me shaken and scared.
If there is configuration information in the database for a theme, keep it for as long as the theme is installed. As Greg Robson says, it should be removed when the theme is deleted (unless the widget area is used by another installed theme).
Just because a theme is not the "active" theme does not mean that the data associated with it is not in use. Any process that removed inactive theme widget data would break plugins which present a different theme to the user.
"Imagine being able to change themes and modify widgets as needed, and if you decided to go back to your old theme, it would return your widgets to how they were the last time you had that theme activated. Sounds good, yeah? The problem we’re facing is deciding how long to save the old widget configuration, since there are so many potential workflows."
If one size does not fit all, ask user for required size. Keep the configuration for as long as the theme is installed. If there is a choice to be made upon reactivation (of Widget Area At Point Of Deactivation Vs Widget Area Now), inform the user and ask for each widget area which they wish to use. Think of the changes to Theme B which could be applied to Theme A as being an "auto-save" of changes. In post editing, a difference between published content and auto-saved content prompts a choice. There is no time limit on the decision. The system uses one set of data publicly by default, but gives the admin the ability to switch to different data. Why should a widget configuration conflict be any different?
From my experience of themes under 3.2, if widget areas have the same name then their configuration is carried forward. If the names are different, they're not. So in many cases, right now, when widget areas have different names, going back to an old theme already returns the widgets to how they were last time. Perhaps that's why what you describe sounds so bad rather than "good".
I haven't tracked down the Trac ticket for this idea (it would be nice if one was provided in the blog post). I assume that at the core, there is a positive change in the way widget area configurations are saved and this "how long do we keep the old copy" is a side-effect.
The thinking that leads to "how long to save the old widget configuration" is flawed. Themes that are installed but not active are not always just there in order to stop that naff "live a little" text from showing up. And as I've said, not active does not mean old.
The Widgets screen (in 3.2) only shows the widget areas of the current active theme. Being able to easily copy settings from an inactive widget area to an active widget area, and indeed to manage widget areas from installed (but inactive) themes would be fantastically useful.
I appreciate that WordPress setups that use multiple themes are in the minority. That only makes me more scared by a ill-thought-out change being decided by a majority vote in a poll where none of the answers are right.
until i delete them manually. give options to save/backup widget setting, rename & restore.
Indefinitely. If it's there once people will expect it to always be there.
Save widget location indefinitely. But don't save what widgets are active. If you go from Theme A to B, and then delete widget 1 and add widget 5, when you switch back to A it will load widgets 2-4 where they were previously, will not load 1, and will put 5 in a default location.
I think this would be best to be handled like Revisions on Posts and Pages. Allow restoring back to any configuration desired from your history.
why time based saving? Use theme based instead and keep it for all time until theme delete
An interesting option would be to save different widget positioning in a setting. And have a page to load and delete these sets. This way you could have multiple configurations, even multiple configurations for the same theme. You could save different sets and switch between them allowing you to change layouts easily.
Just have it ask what to do when you switch back. When you change a theme, put a little message up top indicating that the widgets layout for this theme is different; do you want to restore your original widget layout from the last time you used this theme? Yes/No.
Seems simple enough.
I imagine saving the configuration doesn't take up much space and has no effect on the speed of the site. If so, I see no harm in keeping it until the theme is deleted.
It would be nice to be able to configure this with a function.