I use (current-window-configuration) to save the size, layout etc of windows, and (set-window-configuration ...) to restore them, so that I can toggle between several window setups. However (current-window-configuration) also saves the current point in buffers, and I would like to only save the window sizes and which buffers they hold. I have tried two different ways to make this happen:
According to the function help of current-window-configuration, the variable window-persistent-parameters controls whats get saved. So now I only need a list of the available window-parameters. But when I look at this variable it's value is ((clone-of . t)), and I can't find a list of the available window parameters online.
I also tried looking at the object returned by current-window-configuration. It is a window configuration object, and gets printed as #<window-configuration>. Is there a way to get into this object, see whats inside and change stuff?
The parameters for window-persistent-parameters may be found in this manual page, though it does not seem to help with your question. A different set of parameters may be found by running (window-state-get nil).
The functions that deal with objects returned by (current-window-configuration) are listed here, but it also mentions:
Other primitives to look inside of window configurations would make sense, but are not implemented because we did not need them. See the file winner.el for some more operations on windows configurations.
At any rate, all these look like really low level stuff, so you might be better off just using winner.el rather than a custom made solution.
Related
I have created several figures in Matlab (using GUIDE) which act as a config-GUI for a model. The idea is that changes made in figure F1 should affect what choices can be made in figure F2, F3, .... However, there are 5 figures, all holding different information, and it is possible to navigate arbitrarily between the figures (push buttons on each figure, to every other figure).
A large issue is that I want only one figure to be open at any point in time. That is, when F1 has started FX, I want F1 to close. Hence, I think it is unsuitable to use global variables. (?)
My issue is that I am simply not capable of holding all the data up to date. Maybe this could be achieved using appdata or guidata, but I cannot wrap my head around it.
Examples:
Since the handles of F1 and F2 differs, passing F1.handles to F2 works (F1.handles shows up in varargin{1} in F2), but I cannot concatenate F1.handles with F2.handles. Hence, I have no apt way of sending F1.handles and F2.handles to F3 (or any other figure). (If this can be achieved in a more simple way, I might be okay with dropping the "arbitrarily navigation feature", but so far I have not been able to make it work.)
Using .mat-files (i.e., write FX.handles to a file and load each file in each Figure) seems such bad practice that I haven't even given it a serious go.
So far, I have not found it necessary to change the data in FN±X from FN, hence I guess the .mat-file approach could work, but my latest idea is using Matlab OOP and pass around a class instead of the handles. I found an old post on the topic (Global (shared) variables in Matlab GUI code behind. Is there better way to do it then using handles structure?) but it links merely to a File Exchange and I am unable to understand how to make it applicable for my use case.
Edit 1: I found this Using GUIDE with object-oriented MATLAB?, and will give it a try, but I am still having a hard time understanding exactly how to use it, since it seems to require using handles anyway.
U can try using global variables to retrieve handles for all the figures created by assigning handles values to a global variable in a structure format. Global variable persists in memory until you close the figures.
i have four variables which two of them,named 'lat' and 'long' get value in a popup, and two others, named 'lat1' and 'long1', which get value in the same way in a different popup menu and this four, finally would be used in a third popup menu.
first i tried global variables but didn't work at all, then i tried handles structures and read every thing about it and read everything about sharing data and value between functions and callbacks and every question in stack overflow around this topic but it didn't help me.
It's hard to know exactly what you need from your description, but I'll guess that you have a main GUI and are using separate pop-ups to get inputs? I think from what you have said, you are on the right track.
The handles variable is what you want. It is really useful for sharing data throughout a GUI (if you have used GUIDE to set up your GUI environment then handles should be available, if not then you will have to set it up yourself by calling guihandles - more details here). If you save your variables into it, e.g.
handles.long = ..., handles.lat = ...
and update the variables with guidata(hObject,handles) then you should be able to access handles.long and handles.lat throughout your GUI.
I am doing a group project and we are supposed to be using GUIS to create a presentation. In the presentation there is data that is loaded in using an edit text box and our code then goes through calculations and if statements and is supposed to pass certain values to a different GUI. Our instructors do not know how to do it because we have asked them on several occasions and they cannot figure it out. We have tried varargin method and the getappdata method and neither one is working. Does anyone have suggestions? PLEEAASE!!
I would write some "Controller" program that will know open the figures for you and know how to forward the data. Basically it would be a simplified mvc-pattern. It could also assure the figures are opened in correct order.
ipython auto-completion is great, but a lot of times I need to use previous output and the form Out[15] doesn't get auto-completion. I always have to repeatly do an assignment:
out15=Out[15]
Then use out15 for autocompletion.
Can we make this mechanism automatic?
( I know I can use _, but it lacks readability and if I re-run sth, it becomes untraceable)
There is no option to do that in IPython, and I don't see any good reason you would like to store thing in Out15 more than in a list.
A better question would have been, 'how can I get completion on dictionary and list element without using an intermediary variable'.
Like for me, Out[15].<tab> does trigger completion. I just set the completer greedy option (IPCompleter.greedy) to True, either in my profile, or using the %config magic.
Still this has side effect like :
if a attribute is in fact a property, it might get computed, which you might not want (like Sql query...etc).
It also work other dicts and lists , like pandas, also on function like 'mystring'.upper().decdoe().<tab> will work ... etc
Anyway that not what you asked, so it will probably not help you.
Let us say that I have a Matlab function and I change its signature (i.e. add parameter). As Matlab does not 'compile' is there an easy way to determine which other functions do not use the right signature (i.e. submits the additional parameter). I do not want to determine this at runtime (i.e. get an error message) or have to do text searches. Hope this makes sense. Any feedback would be very much appreciated. Many thanks.
If I understand you correctly, you want to change a function's signature and find all functions/scripts/classes that call it in the "old" way, and change it to the "new" way.
You also indicated you don't want to do it at runtime, or do text searches, but there is no way to detect "incorrect" calls at "parse-time", so I'm afraid these demands leave no option at all to detect old function calls...
What I would do in that case is temporarily add a few lines to the new function:
function myFunc(param1, param2, newParam) % <-- the NEW signature
if nargin == 2
clc, error('old call detected.'); end
and then run the main script/function/whatever in which this function resides. You'll get one error for each time something calls the function incorrectly, along with the error stack in the Matlab command window.
It is then a matter of clicking on the link in the bottom of the error stack, correct the function call, and repeat from the top until no more errors occur.
Don't forget to remove these lines when you're done, or better, replace the word error with warning just to capture anything that was missed.
Better yet: if you're on linux, a text search would be a matter of
$ grep -l 'myFunc(.*,.*); *.m'
which will list all the files having the "incorrect" call. That's not too difficult I'd say...You can probably do a similar thing with the standard windows search, but I can't test that right now.
This is more or less what the dependency report was invented for. Using that tool, you can find what functions/scripts call your altered function. Then it is just a question of manually inspecting every occurrence.
However, I'd advise to make your changes to the function signature such that backwards compatibility is maintained. You can do so by specifying default values for new parameters and/or issuing a warning in those scenarios. That way, your code will run, and you will get run-time hints of deprecated code (which is more or less a necessary evil in interpreted/dynamic languages).
For many dynamic languages (and MATLAB specifically) it is generally impossible to fully inspect the code without the interpreter executing the code. Just imagine the following piece of code:
x = magic(10);
In general, you'd say that the magic function is called. However, magic could map to a totally different function. This could be done in ways that are invisible to a static analysis tool (such as the dependency report): e.g. eval('magic = 1:100;');.
The only way is to go through your whole code base, either inspecting every occurrence manually (which can be found easily with a text search) or by running a test that fully covers your code base.
edit:
There is however a way to access intermediate outputs of the MATLAB parser. This can be accessed using the undocumented and unsupported mtree function (which can be called like this: t = mtree(file, '-file'); for every file in your code base). Using the resulting structure you might be able to find calls with a certain amount of parameters.