A Widescreen Blender-Style Interface

BrendaEM wrote: There is an issue: as you might have noticed, some buttons are custom and quite unique, such as the jog buttons, and the probe buttons, which really are based from the Probe menu. You know what I mean.

I think we can compromise on the probe buttons by using an icon with a transparent background, and not having the "work material" go all the way to the edge of the button. For something with a lot of options like probing you could use popups with progressive selection, like the Renishaw probe screen ...

The jog buttons are a challenge . I have spent some time trying to duplicate them using shape masks and qss, but to not much avail. I can get the shape right, but the border does not continue around the shaped end. It should be possible to do by overriding the button paint event, but that is a bit over my head!

For safety, we would need an are-you-sure before executing a goto, but the MDI is going to get less use : )

I always wanted to add a 'go-to' functionality in hazzy by typing into the DTG DRO! Do you intend to be able to set the work offsets by typing into the DRO too?

Cheers,
Kurt

cmorley wrote: kurt
Hope you are gonna add that widget to qtvcp...

Chris M

Chris, I hope to give back at least a small portion of what I have stolen
I have made a lot of changes in my QtPyVCP branch (not pushed yet), when I get it cleaned up a bit I would like to see what you think.

Cheers,
Kurt

kcj wrote:

cmorley wrote: kurt
Hope you are gonna add that widget to qtvcp...

Chris M

Chris, I hope to give back at least a small portion of what I have stolen
I have made a lot of changes in my QtPyVCP branch (not pushed yet), when I get it cleaned up a bit I would like to see what you think.

Cheers,
Kurt

Looking forward to it.
It would be great if Qtscreen could help Brenda realize her ideas too.

Chris M

Hi Kurt,

I just wanted to make sure the probe controls fit, and they seem to.

Yes, I did want a click to go-to in the numerical display. There are some hardcore Gcode people who may not see the need, as there is the MDI, but I like convenience. There may be other action that can be used to replace repetitive Gcode commands, which beginners don't know anyway.

Perhaps the pointy jogs can be placed in a square button. Although the the button border may confuse they eye. In places placing legends inside arrows seem to improve recognition, and reduce visual clutter.

The Gmoccapy-style incremental indicators that you see everywhere were an excellent design by the designer of Gmoccappy. Once again, this interface is a blend of Axis and Gmoccapy, with some Hazzy, a touch of Craftsman and Touchy--all colored like Blender.

(I've had a cold, and have been struggling to get my CNC going, bickering with someone on the forum, but I want to track down the creator of Gmoccapy and post to him that the design of Gmoccapy has contributed greatly to this design. The thing is: it's really difficult sometimes to wear two hats. As established, there likely is not enough time for me to learn how to program this interface, so, as you said, I am concentrating on the design. The person who did Cmoccapy did both, and that's not easy. To be blunt and to the point: The one thing that Gmoccapy has not done: replace Axis. I had a friend stop by, look at Axis, and tell me that it looks like a Windows 95 program. No...no, that's not a compliment. Still, Axis is very useful and adaptable, and that is why it has endured and been expanded upon.)

Anyway, the incremental indicators have:

• Incremental buttons, that should be settable in the .ini
• A static text legend inner above
• A dynamic readout inner below
• Proportion indicators

The indicators are taken right from Gmoccapy, but add the static legend line.

Once again, the design of this interface:

• From the get-go be for 16x9 aspect ratio widescreen 1920x1080 and above for the future.
• Should be touch-compatible, which means long-presses instead of double-clicks.
• Should be modular with several sections to do different things.
• Should be made with open tools, so other can work on it.

As you might have read, I respect how much effort it will be to program this interface, and so, to the chagrin of others, I've wanted to get it pretty solid before moving forward. I don't see a big paradigm change. I am trying to decide if Pycam should be on the main menu.

One thing that's been a nagging detail for me: switching out some of the separator lines, when certain panels are changed.

"I always wanted to add a 'go-to' functionality in hazzy by typing into the DTG DRO! Do you intend to be able to set the work offsets by typing into the DRO too?"

.... As long as it can be done safely, that would be up to the programmer. Perhaps you can have a sit-down with him : )

Do you know both GTK+ and QT?
I am not asking because I want you to do both, it's just that my heart beats a little faster for GTK+

Perhaps the pointy jogs can be placed in a square button. Although the the button border may confuse they eye. In places placing legends inside arrows seem to improve recognition, and reduce visual clutter.

From a design and usability standpoint I think the shape of the jog buttons is very good. I have been studying how to make them, and I am confidant that it can be done, but they may not make it into the first prototype.

When I get some time will see about implementing the incremental indicators, shouldn't be too hard. What do you think about being able to swipe the indicator area to increase/decrease the setting in addition to the -/+ buttons?

One thing that's been a nagging detail for me: switching out some of the separator lines, when certain panels are changed.

The separators can be dynamically moved/hidden/shown as needed. Does that relieve the nag?

Do you know both GTK+ and QT?
I am not asking because I want you to do both, it's just that my heart beats a little faster for GTK+

My heart beats faster for Gtk+ too, but only because it reminds me of all the time I have spent fighting with it!
I know Gtk+3 (including a good many of it's various quirks and bugs) pretty well, maybe too well given that I have helped people do things that the devs thought was impossible, but life is too short. Don't get me wrong, I really like it in many ways. It has some great features and there is no question that it beats Qt in look and feel, but it is a nightmare trying to use it for anything remotely complicated.

My new preferred method of testing toolkits is to give the IDE a spin. On the surface GNOME Builder (the IDE for developing Gtk apps) looks very nice and is loaded with features, but in reality it is so slow and buggy it struggles to open and syntax highlight a single file. On the other hand the Qt IDEs (QtCreator and QtDesigner) are pretty bare bones, but they work well, have all the features that are actually needed, and are reliable. This seems to be consistent for most Qt and Gtk apps.

I have only been playing with Qt for a few weeks, but so far I have been very impressed. It is MUCH simpler to use than Gtk and I have yet to encounter anything that does not behave exactly as expected. Also it seems to run better on old hardware and does not have the graphics problems Gtk tends to. Anyway, so far I feel like the practical advantages of Qt far outweigh the aesthetic ones of Gtk. I only wish I had listened sooner to all those that told me to run from Gtk ..

I should clarify that I have only had problems with Gtk+3 , Gtk+2 (as use by Gmoccapy, gscreen, touchy, gladeVCP ...) is a very solid toolkit. The problem is it is getting old and probably will not be supported for much longer, so would probably not make sense to use in a new project.

I hope your cold gets better soon.

Cheers,
Kurt

I don't expect the first prototype to be perfect. There is a lot of ground to cover, here.

If the swiping to make a fader-like control could be done safe, it would be good, but what I am worried about is someone putting a milling fly cutter in a chuck, or a heavy part in a 4-jaw lathe chuck, and sneezing while they adjust it, creating mayhem and an ambulance ride.

I should think that the increments should be settable, and the arrows on the end could repeat if held, like a keyboard repeat.
Can you think of a way way to make an analog slider safe?

I would like to also be able to long-press on an indicator to type a numerical entry, using an onscreen pop-up keyboard, like in NativeCAM. If you haven't noticed, I am a big proponent of NativeCAM because it's handy for one-off tasks and small projects.

The separators can be a little complicated--even in Inkscape layers. As the layout progresses, I think I am going to have to be consistent with them if I expect others too.

I do like GTK+ because it adds consistency to many Linux distributions.

I wonder also if a meta button layout language like an .XML file could be used, as they are in Axis. In other words, I worry that if it's too hard for people to customize the interface, then this project might instead futher fragment LinuxCNC further instead of drawing it together.

I wonder if more than one person could help code this.