A Widescreen Blender-Style Interface

BrendaEM: We posted at identical times

EDIT: If you can send me the SVGs (and preferably the icons as individual SVGs) I will see about turning your art work into reality ...
EDIT2: Hmm, maybe the icons all in one SVG would be easy to work with.

Hey, that looks pretty cool!!!
It's doing stuff!!
It's pretty close, already.

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 wonder if, I output the legends, if the background could be programmatically changed, for those that needs a graphic.

Some of the parts seem pretty solid.
I can output button svg's or pngs, or whathaveyou.
The font is OpenSans, which is free and, well, open. It has an advantage: it has a semi-bold, and even a semi-bold italic.

This is pretty exciting!

My talent lies in ripping off other ideas in reasonable portions : )

For safety, we would need an are-you-sure before executing a goto, but the MDI is going to get less use : )
Drat, I should have made everything one post, so your post with the graphic wouldn't get buried : (

kcj wrote:

Looking great as usual!

Before you spend any more time trying to export images ... I do not think it is a good idea to use images (in any format) for UI elements. It is a nightmare trying to keep up with all the image files for the different states, and if you want to tweak a color (or border width, or .. ) you have to regenerate ALL the files. Also it makes the code much more complicated and less efficient as you have to load and unload the images constantly,

A much better approach is to style widgets. Almost all modern GUI toolkits support styling in one way or another. Both Gtk3 and Qt use a form of CSS, which is easy to use and extremely powerful.

In a few minutes and 40 lines of code, I came pretty close to reproducing your DROs using Qt widgets styled with qss:

Concentrate on the design, that's is clearly where your talent lies. Don't worry too much about the implementation at this point!

Cheers,
Kurt

kurt
Hope you are gonna add that widget to qtvcp...

Chris M

I didn't know to do with the file menu until I came across this interface called Hazzy. Perhaps you've heard of it : )

It's a first File Menu draft. The more mischievous buttons are on the right'ish side. The wordwrap key on the keyboard idea I had can't go because the keyboard needs to be generic.

I included a Pycam Import button. I haven't seen it since they started working on it again, but it seemed useful, the last time I tried it. Perhaps it should be a tab, or a Plug-In. Supporting may encourage development. Perhaps also that it might even be modified to share LinuxCNC's tool table. I should give it a good reevaluation. Perhaps someone could offer some feedback. Pycam should be on the Distro, too. You, know, get them 15 minutes in the spotlight, before you ask them if they can do 5 axis : )

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+