+- Wings 3D Development Forum (https://www.wings3d.com/forum)
+-- Forum: Wings 3D (https://www.wings3d.com/forum/forumdisplay.php?fid=1)
+--- Forum: Design & Development (https://www.wings3d.com/forum/forumdisplay.php?fid=6)
+--- Thread: Preview Dialog Observations. (/showthread.php?tid=142)
Preview Dialog Observations. - ggaliens - 01-18-2013
Preview Dialog Observations.
Something about this dialog starting on AUTO and also not requiring an OK for the first iteration is very bothersome.
How do I take control of situations where parameters get out of control ?
It almost seems like OK should need to be pressed at least one time for something to happen.
I like it all ... but I think some nuances need re-working for it to be awesome. It probably should default to manual.
Also ... if I "OK" after being in auto for a few iterations because I like what I last saw ... it should not do the last calculation AGAIN, I don't think. That achieves nothing ... but potentially an unwanted LAG. The user is really "OK-ing" the current St. It would not run the calculation twice.
RE: Preview Dialog Observations. - micheus - 01-21-2013
I'm going to make comments based in my experience with heightmap previews...
(01-18-2013, 11:43 PM)ggaliens Wrote: It probably should default to manual.I think that would be better if we could have this as optional. For the basics primitives it is better have it Auto, but for complex meshes/operations it would be good start it in Manual mode.
It could be something like call the dialog/ask function with the current {preview,Dlg} (for default mode = auto) or {preview,Dlg,<start_mode>}.
ggaliens Wrote:if I "OK" after being in auto for a few iterations because I like what I last saw ... it should not do the last calculation AGAIN, I don't think.I agree with you.
I don't know how complicated it could become the code for that, but for both current situation (fun({dialog_preview,Res}) and fun(Res)) it would be very useful get the #st back (as a parameter) as well get the information about if the mode be manual or auto (delaied would be considered auto in this case) - so, we would be able to decide when rebuild/recalculate something after the user hit OK.
Currently we already can get that #st{} by rewriting the wings_wm:get_current_state() in our module, but I don't think this can be acceptable.
The wings_wm:get_current_state() code was not designed to be used with dialogs window - for that, it would ask for display_lists property from the dialog owner window.
We know that geom window always is using that #st{} data, so the rewritten code just query it about display_list.
This function would be added to wings_ask in order to be used for return the #st{} used for preview.
I'm using this way in the heightmap plugin :
Code:
get_current_state() ->
DispLists = wings_wm:get_prop(geom, display_lists),
get({wm_current_state,DispLists}).but, in the wings_dlg maybe it could be used this way:
Code:
get_current_state(#s{owner=Owner}) ->
DispLists = wings_wm:get_prop(Owner, display_lists),
get({wm_current_state,DispLists}).RE: Preview Dialog Observations. - optigon - 01-22-2013
You can set the pref to get the initial preview mode. But set it back to whatever it was after.
Code:
PreviewMode = wings_pref:set_value(preview_dialog, auto_preview)The other part about the st being reused gets complicated.
Currently there are no real optimizations, but there should be.
I could try and fix things, but lately I'm having trouble concentrating on the code long enough to get anything done. If someone wants to continue the work on previews, please do. Part of the problem, as I remember was keeping the undo stack proper.
RE: Preview Dialog Observations. - micheus - 01-22-2013
Thanks Optigon.
By using your tip and that get_current_state I've proposed, I believe we can do work around for many situations.
RE: Preview Dialog Observations. - ggaliens - 03-25-2013
(OK)
(Keep)
(Cancel)