Full Version: V4 released!

Show messages:  1-20  …  61-80  81-100  101-120  121-140  141-160  161-180  181-188

Hi Michael!

re:
> I'm not sure why you think it would be a "big step forward".

Well...on MacOs/iOS/iPadOS machines, Metal APIs are much much better than the old OpenGL simply because they're heavily optimised for the MacOS/iPadOS system.

There are already dozens of apps, both for 2D and 3D, on MacOS/iPadOS that now really fly, thanks to the porting to Metal API.

See you.

---

Hi Marco,

re:
> Well...on MacOs/iOS/iPadOS machines, Metal APIs are much much better than the old OpenGL simply
> because they're heavily optimised for the MacOS/iPadOS system.

No that's not exactly correct, it's only in certain circumstances that there is a big difference at the API level, such as with overhead from smaller batches.

MoI already does a good job of batching things up and so it's not likely to be affected really at all by such things.

It's not likely that there will be any noticeable difference in Moi after targeting Metal. The reason for MoI to target it does not have any thing to do with performance, it has to do with compatibility with future OS versions.

I've also seen some developers say that Metal had more driver bugs for them than OpenGL until pretty recently. But hopefully it will be easier for them to maintain the Metal drivers than the OpenGL ones from here on out though.

- Michael

---

Hi Michael,

Interesting info, thanks. I assumed that addressing the Metal graphics library would mean making full use of Apple's CPU + GPU hardware power.

But compatibility is also very important of course.

I'm planning a return to macOS in the very near future, hopefully this year, when a more powerful Apple Silicon iMac is released, for a pro-level alternative to the just introduced candy-colored consumer-level iMacs. So I'm happy to read that you're looking into support of the new hardware.

---

Hi Metin,

re:
> I assumed that addressing the Metal graphics library would mean making
> full use of Apple's CPU + GPU hardware power.

Not particularly... the OpenGL drivers were already doing that. That's why for example these benchmarks had better performance in OpenGL than in Metal on the same machine for many cases:
https://forums.macrumors.com/threads/metal-vs-opengl-benchmark.1957306/

But the OpenGL drivers will get less attention over time and maybe eventually be discontinued. Or maybe it will end up something like how it is on Windows where OpenGL is provided by the video card vendors instead of by the OS. That also leads to flaky drivers as well though.

- Michael

---

Really interesting. This relativizes my romanticization of the power of Metal.

---

I'm sorry Michael...not that I want to be pedantic but...the whole history of GPU cards, especially for the Windows side, is totally full of heavily unoptimized software/drivers.

This is a fact.

I put my hands on many powerful machines equipped with really powerful GPUs and none of them was capable to express all of the the potential of the cards, and this totally due to the obsolete and heavy OpenGL layer.

Metal API has already proven that is capable to get the best out of the modern cpu/gpu

So, I really hope that very soon, we all say a definitive goodbye to the "the dinosaur" OpenGL :)

Ciao.

---

Hi Marco, yes definitely OpenGL drivers have been problematic. Video drivers are the most complex piece of software running on your machine and so they also tend to be the most problematic as well.

I'm sorry to say that no Metal is not a magic API that somehow automatically solves this. There can still be plenty of unoptimized areas and bugs in Metal as well. You don't have to take my word for it, just see the above link for examples where OpenGL was faster than Metal on the same machine.

We are getting to the point now where on new operating systems Metal is going to be better quality than OpenGL though. The reason why is simply that Apple is not doing any work on OpenGL beyond some bare minimum level and all their effort is going in to Metal instead.

- Michael

---

Hello Michael.

I need a quick help on a very simple thing, that I hadn't nail because I don't know how to find the proper documentation.

Some days ago I finally found some spare time to port to the V4 some parts of my old "very personal Moi's UI" that I wrote years ago for the V3.
(I'm running Moi V4 on my MacBook Pro)

I always liked the side panel without any commands but only with the sene browser.

So I moved ALL the standard commands into a popup menu that I open in this way (I assigned the action to the A key):

A=script: moi.ui.showMenu('moi://appdata/customui/my/AllStdMoiCommandsPanel1.htm', moi.ui.getUIPanel('moi://ui/CommandBar.htm').document.body.firstChild.firstChild, 4, 0);

And this is how it looks when opened (the red little labels remind me what's the shortcut that I have associated with the command)

Now...my question is:
How can I make the popup menu automatically close as soon as I press a key on the keyboard?
Currently the popup menu only closes when I click on an icon inside it, or I press the ESC key or I click outside of it.


Actually, if I press any key (the shortcuts that I've associated to the commands), the popup menu doesn't close but only executes the selected command, but I have to press the ESC key to first close the popup.

Thanks for your help.




Ciao.

---

HI Marco, if you show it as a dialog it's possible for a dialog to implement a function OnKeyDownEvent( event ) in it which will give it a chance to process keyboard events if it is the current focus window. There's an example of that in ShortcutKeyDialog.htm .

So for your case where you want it to hide on any keystroke, you could implement this script function inside the page:

			function OnKeyDownEvent( e )
			{
				moiWindow.close();
			}

Then for showing your UI use moi.ui.createDialog( 'DialogUrl.htm' ); instead of showMenu().

Does that work?

I'll see about making the keyboard event processing work for flyout menus as well as dialogs for v5.

- Michael

---

Thanks Michael for your tip.

But...no, I'm sorry, It doesn't work properly.

let me explain...

If I use your suggested "OnKeyDownEvent" and I open the popup as a DIALOG, ok, it works.
But ONLY for single keystrokes.
But most of my shortcuts are a combination of a key and qualifiers, and if I use OnKeyDownEvent, as soon as I press a qualifier, the dialog closes.

So I've tried the OnKeyUpEvent instead.

But, if open the popup ad DIALOG, it immediately gets the focus, and while I'm releasing the A key (that opens the dialog) it automatically closes.

SO, I'VE FOUND THIS PARTIAL SOLUTION:

I open the popup NOT as a dialog BUT as a MENU with showMenu(...) and I use the OnKeyUpEvent so I can handle the shortcuts that are combination of a key and qualifiers.
And all works fine :)

But now I only would need that the popup menu could gets automatically the FOCUS as soon it open.
Because if I don't first click inside it, but only press any of the keyboard shortcuts, the related command starts, but the popup menu doesn't close.
Instead, if I first click inside it, then when I press a keyboard shortcut, the popup menu close correctly.



Thanks for your help.

---

Hi Marco,

re:
> But now I only would need that the popup menu could gets automatically the FOCUS as soon it open.

Unfortunately this does not happen with a popup menu, it's because it uses the Qt popup mechanism. When Qt shows a popup window all key events are sent to it regardless of what window has the current focus.

I've fixed this up for v5 so that popup windows will get the script keyboard events sent to them always but for v4 it's only reliable on a dialog not on a menu.


> But most of my shortcuts are a combination of a key and qualifiers, and if I use
> OnKeyDownEvent, as soon as I press a qualifier, the dialog closes.

Your OnKeyDownEvent() handler could look at what key the event is for and if it's for a modifier don't close the window. There is documentation on the event properties in ShortcutKeyDialog.htm .

- Michael

---

Hi Marco, also maybe it would be easier to handle launching commands inside of OnKeyDownEvent/OnKeyUpEvent , bypassing the regular keyboard shortcut launcher. To do that set event.handled = true; that will prevent Moi from doing anything further with that key event.

Your event handler can call moi.command.execCommand( 'command_name' ); to launch a command itself.

- Michael

---

Hello Michael.

Ok. Thanks for the tips.

re
> Your OnKeyDownEvent() handler could look at what key the event is for...

I'll try it asap, and I'll let you know.

re:
> I've fixed this up for v5...

Maybe you could publish some intermediate versions like 4.x.y
I said this because it would be good for us if you'll be able to publish new versions with small useful changes, rather than wait for a long period before you can publish another major version.

re:
> ...bypassing the regular keyboard shortcut launcher....

Ok. I'll try also this tip, and I'll let you know.

Thanks.

---

Hi Marco,

re:
> Maybe you could publish some intermediate versions like 4.x.y

It's not easy for me to do that because I don't want to make a final release version that has not had some time spent in beta release first to try and avoid regressions,. The next beta release will be for v5 so that's where changes like this will be going into.

- Michael

---

Hello Michael.

So...after your suggestion, I nailed it :)

I open my custom UI in a pop-up dialog and I manage all the shortcuts is this way:

<script>
	var cmds = [];
	cmds[parseInt("0x31")] = "line";
	cmds[parseInt("0x32")] = "curve";
	... other commands ...

	var cmdsAlt = [];
	cmdsAlt[parseInt("0x31")] = "polyline";
	cmdsAlt[parseInt("0x32")] = "interpcurve";
	... other commands ...

	var cmdsCtrl = [];
	cmdsCtrl[parseInt("0x35")] = "circletangent";
	cmdsCtrl[parseInt("0x36")] = "arccontinue";
	... other commands ...

	var cmdsShift = [];
	cmdsShift[parseInt("0x32")] = "sketchcurve";
	cmdsShift[parseInt("0x33")] = "rect3pts";
	... other commands ...

	function OnKeyDownEvent(e) {
		e.handled = true;

		var cmdName = null;

		if (e.shift) {
			cmdName = cmdsShift[e.keyCode];
		} else if (e.ctrl) {
			cmdName = cmdsCtrl[e.keyCode];
		} else if (e.alt) {
			cmdName = cmdsAlt[e.keyCode];
		} else {
			cmdName = cmds[e.keyCode];
		}

		if (!cmdName) {
			return;
		}
		
		moi.command.execCommand(cmdName);

		moiWindow.close();
	}
</script>

Then I also use a "fake" class to attach the "moiWindow.close();" command to all the moi:CommandButton that I use in the dialog:

<moi:CommandButton class="myCmd" ...

<script type="text/javascript">
	var buttons = document.querySelectorAll(".myCmd");

	for (var i = 0; i < buttons.length; i++) {
	   buttons[i].addEventListener("click", function (event) {
	       moiWindow.close();
	   });
	}
</script>

I hope you will ad soon the capability of trapping key event also in pop-up menu.

Thanks and have a nice day.

---

That's great Marco, I'm glad that is working!

- Michael

---

Hello Michael.

A quick (for you) help, if you can.

I need a very quick inline script that have to do the following:

Select all objects (solids or surfaces) that belongs to the currently selected edges (and, at the same time, deselect the input selected edges)

Could you tell me?

Thanks and have a nice day.

---

Helo Michael.

I'm sorry if I ping you again...

Could you help with the little inline script I asked for?
(you can find the answer in my previous message)

Thanks.

---

Hi Marco,

re:
> Select all objects (solids or surfaces) that belongs to the currently selected edges (and, at
> the same time, deselect the input selected edges)

You can get the selected edges using this:

var edges = moi.geometryDatabase.getSelectedObjects().getEdges();

Then you'll want to loop through every edge something like this:

for ( var i = 0; i < edges.length; ++i )
{
var edge = edges.item(i);
....
}

To deselect the edge you would do:

edge.selected = false;

To get the parent surface or solid of the edge you would do:

edge.getParentBRep();

So putting that all together it would go something like this:

var edges = moi.geometryDatabase.getSelectedObjects().getEdges();
for ( var i = 0; i < edges.length; ++i )
{
   var edge = edges.item(i);
   edge.selected = false;
   edge.getParentBRep().selected = true;
}

Hope that helps! - Michael

---

Perfect Michael!

Exactly what I needed.
Thanks!

One question...

Trying to write some new scripts for my very personal workflow, I've seen that the version of JS that Moi can interpret is rather...aged.
I can't use any modern construct or technique of ES6 like, arrow functions, let and const, deconstructing and so on...

Which version of JS Moi is capable of?

Are you thinking of support newer and more modern version of JS?

Thanks again.

---

Show messages:  1-20  …  61-80  81-100  101-120  121-140  141-160  161-180  181-188