Introduction
On 19 March 2016 at 20:56, Torsten Paul Torsten.Paul@gmx.de wrote:
Yes, this has some groundwork in the parser and a partial UI.
It's not really in a state where we can merge it and give it
to users. I do have to refresh my mind about the exact state
of that code, but I think the remaining topics are well
enough to fill the timeline of a GSoC project. And if we
find there's some time left, there's lots of room to expand
to another use case, some of those I started collecting in
https://github.com/openscad/openscad/wiki/Meta-Data-Use-Cases
I have figure out some features by talking to some of my group and
civil students regarding UI that I am sharing for feedback-:
- Make UI modular so as make it easy to work and adjust panels
according to users need (like that of gimp) - grouping of parameters
- collapsing and expanding of individual parameter widget.
- option to hide certain parameters from display.
- saving .scad file without annotation code after setting value of
parameters it will make scad file backward compatible. - option to make slider vertical (as for parameter like height it
would make more appealing with vertical slider). - possibly radio buttons.
and their is last one for which I don't the difficulty level of this.
- A Pearson get list of all parameter associated with the object by
clicking on it in view plane.( like a Pearson click on cube in a
drawing he may get all parameter associated with that square in
parameter widget).
Please share the if some issues associated with parser are their and
share your feedback for above suggestions
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"
Useful from my point of view would be an input console line acting on the
view-port to pan, rot, zooming, and defining rotation point in an easy
typing way like:
r(x,y,z) t(x,y,z), z(v), rp(x,y,z), or even better: rx, ry, rz, etc
Optionally a reset viewpoint command "rv" without automatic zoom would be
useful, although this option already exist in a UI button for viewing all
the scene.
The standard views are not enough and using $vpr and $vpt in the script is
not user friendly, and for complex multi-part objects is an head ache. The
use of mouse drives me crazy mostly because the extreme lag and the lack to
define a rotation point.
jpmendes
--
View this message in context: http://forum.openscad.org/Introduction-tp16322p16632.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 21 March 2016 at 21:09, jpmendes jpmendes54@gmail.com wrote:
Useful from my point of view would be an input console line acting on the
view-port to pan, rot, zooming, and defining rotation point in an easy
typing way like:
r(x,y,z) t(x,y,z), z(v), rp(x,y,z), or even better: rx, ry, rz, etc
You mean to say a separate command line mode like control below view
port to control the view point.
Optionally a reset viewpoint command "rv" without automatic zoom would be
useful, although this option already exist in a UI button for viewing all
the scene.
A shortcut key can be added for reset view.
The standard views are not enough and using $vpr and $vpt in the script is
not user friendly, and for complex multi-part objects is an head ache. The
use of mouse drives me crazy mostly because the extreme lag and the lack to
define a rotation point.
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"
Like this idea. Maybe if I could hit r for render or b for build, f5 can go
back to being find next as my muscle memory keeps demanding
--
sent from nexus c
On Mar 21, 2016 10:13 PM, "Amarjeet Kapoor" amarjeet.kapoor1@gmail.com
wrote:
On 21 March 2016 at 21:09, jpmendes jpmendes54@gmail.com wrote:
Useful from my point of view would be an input console line acting on the
view-port to pan, rot, zooming, and defining rotation point in an easy
typing way like:
r(x,y,z) t(x,y,z), z(v), rp(x,y,z), or even better: rx, ry, rz, etc
You mean to say a separate command line mode like control below view
port to control the view point.
Optionally a reset viewpoint command "rv" without automatic zoom would be
useful, although this option already exist in a UI button for viewing all
the scene.
A shortcut key can be added for reset view.
The standard views are not enough and using $vpr and $vpt in the script
is
not user friendly, and for complex multi-part objects is an head ache.
The
use of mouse drives me crazy mostly because the extreme lag and the lack
to
define a rotation point.
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 21 March 2016 at 21:09, jpmendes wrote:
Useful from my point of view would be an input console line acting on the
view-port to pan, rot, zooming, and defining rotation point in an easy
typing way like:
r(x,y,z) t(x,y,z), z(v), rp(x,y,z), or even better: rx, ry, rz, etc
Interesting idea. Blender has a similar type of control which is
very useful, and I've seen that in other places too.
Von: "Tony Godshall"
Like this idea. Maybe if I could hit r for render or b for build,
f5 can go back to being find next as my muscle memory keeps
demanding
Right, I guess that could be extended to most of the GUI actions
available, not just to viewport manipulation.
Actually the core infrastructure for the feature itself is already
part of the branch that is working on adding more input devices
(mainly for 3d-mouse devices, but at least for Linux this could
easily add an udev-based remote control command interface).
That topic is a bit different from the meta-data/customizer discussion,
so I guess it would be better to continue in a separate thread and
not mix both...
ciao,
Torsten.
On 21 March 2016 at 14:33 Amarjeet Kapoor wrote:
- Make UI modular so as make it easy to work and adjust panels
according to users need (like that of gimp)
We are a bit restricted by the features Qt provides, which
is not as nice as Gimp shows with the flexible docking&floating
windows. But it should be possible to find way that's working
well enough.
- grouping of parameters
For bigger models, that's useful for sure.
- collapsing and expanding of individual parameter widget.
That probably depends a bit on what a single widget
will show. It might be a bit tedious to open and
collapse lots of small widgets.
Assuming we want to show a long description for all
the parameters, maybe there could be a single on/off
for all the detailed descriptions to make more room for
the actual parameters?
- option to hide certain parameters from display.
If we annotate the parameters to show, we'll get that
automatically. I think it's good to not just show all
available variables.
- saving .scad file without annotation code after
setting value of parameters it will make scad file
backward compatible.
This might be useful, but I'd rate it as relatively
low priority as it's main usefulness is for the time
of migration (which could be a couple of years though).
- option to make slider vertical (as for parameter
like height it would make more appealing with vertical
slider).
Good point, in a more general way this is would give
the user a way to define options for the actual
presentation of the parameter. In the simple case
this could be automatically determined based on the
values the user specified, but having some addtional
control about the presentation might be useful.
- possibly radio buttons.
This should be covered by a generalized point 6.
- A Pearson get list of all parameter associated with
the object by clicking on it in view plane.( like a
Pearson click on cube in a drawing he may get all
parameter associated with that square in parameter
widget).
Object picking would be a very nice thing to have,
but I think that's a bigger topic in itself, so I'd
recommend to leave that as separate project.
ciao,
Torsten.
On 22 March 2016 at 23:23, Torsten Paul Torsten.Paul@gmx.de wrote:
On 21 March 2016 at 14:33 Amarjeet Kapoor wrote:
Thank you for your views but their are some features which I was not
able to convey
correctly.
- option to hide certain parameters from display.
If we annotate the parameters to show, we'll get that
automatically. I think it's good to not just show all
available variables.
I was explaining the situation when person has annotated the variable
and he has been changing the value from form but he want to fix that
particular value for some time and want to remove that parameter from
parameter form so has to make room for other parameters in that
widget.
- saving .scad file without annotation code after
setting value of parameters it will make scad file
backward compatible.
This might be useful, but I'd rate it as relatively
low priority as it's main usefulness is for the time
of migration (which could be a couple of years though).
We can modify this feature that is we can assign new values to
variables from form i.e changes we made to model through form are
temporary, don't exist after we open that model file again but we can
make it permanent in program.
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"
I have written project proposal according to features that I think could
be added you can suggest more.
Milestones are not fixed till now.
Need your review on it
--
Amarjeet Singh
https://amarjeetkapoor1.wordpress.com
https://github.com/amarjeetkapoor1
https://bitbucket.org/amarjeetkapoor
"knowledge about knowledge is power"
On 03/23/2016 11:55 AM, Amarjeet Kapoor wrote:
I have written project proposal according to features that I think
could be added you can suggest more.
Thanks. Just a quick first response...
The detailed description already has some good points and
lists examples for the topics we discussed. That looks
like a good base for approaching the project and defining
the specific things to do.
The Milestones part could use some more details. I know it's
not easy to give a very detailed plan for this type of project
with a number of unknowns that will only become clear in the
first phase. So one option to get the steps a bit clearer
could be to explain how you want to approach the different
parts of the project.
So what I mean is basically the first part of the proposal
list some things to do with "We can...", the milestone part
should outline the (small) steps that say how it will be
possible to decide what will be done, ideally on a weekly
basis.
(Note that weekly here mainly stands for "something that
might be done in a couple of days and does not need like
3 weeks"; The timeline given will be guideline, not a strict
work plan and can be adjusted)
ciao,
Torsten.
Hello,
Maybe I'm wrong but I'm not enthusiastic about the use of sliders on the UI.
I would prefer a direct entry of values or both options. Since we do not
have real variables, each time you move a slider the script is recompiled to
reflect the actual state, when the project gets complicated the lag will be
not negligible if not insupportable. And not everybody have top speed
machines.
With direct entree boxes you could define ranges for the parameters and
observe the respective evolution result.
Another thing I feel is important, although outside the scope of the UI,
would be the existence of an echof() echo to file functionality. That would
allow the recording of parameters, or even better, interacting with the
outside world. For instance the use of sound, or performing real actions.
I'm seeing for instance a python script interacting with the logs from the
OpenSCAD app.
jpmendes
--
View this message in context: http://forum.openscad.org/Introduction-tp16322p16684.html
Sent from the OpenSCAD mailing list archive at Nabble.com.