If having a dialog like in the previous post is workable for what you want (I guess that would still be useful if you're in full screen mode), you may want to make some custom dialogs that have various stuff on them, rather than trying to use the command set directly as a dialog which will probably have some odd line breaking in it since those command sets are really meant to fit within the side pane.

To set up a dialog, go find the command set .htm file and you can grab the buttons for various commands out of there.

Then to make a dialog make a new .htm file and to control the line wrapping in the dialog surround sections that you want to have all one one single line with <nobr></nobr>

Then put your new dialog in either the \commands or \ui sub-folders, then to refer to it with createDialog use an address of moi://commands/dialogname.htm if it's in the \commands folder or moi://ui/dialogname.htm if it's in the UI folder.

- Michael

This

script: /* Pop up the lines */ moi.ui.createDialog( 'moi://commands/Lines.htm' );

Popup the menu in the center of the UI (not only the viewport, so it's slightly to the right if you got your browser on the right)
Is it possible to make the popup diseapear as soon as you click one of the icon ? That would be cool :)

Hi DesuDeus,

> Is it possible to make the popup diseapear as soon as you
> click one of the icon ? That would be cool :)

Yup, that's possible by making a custom dialog that calls an endDialog() function whenever anything has been clicked.

If you use the attached Lines2.htm file as a dialog it will do that, if you copy this one into the \ui sub-folder then you would use this script on a shortcut key to call it:

script: /* Show lines dialog */ moi.ui.createDialog( 'moi://ui/Lines2.htm' );

- Michael

Reading this I remembered the cycling shortcuts of the adobe products. For example you press "G" for the bucket tool in photoshop, but if you press "Shift+G" you cycle through the tools grouped with the bucket tool. In the preferences menu you can uncheck a box for just pressing a shortcut more than one time and cycle through a set of tools grouped. In MoI it can be for example, pressing "C" one time it activates the control points curve, two times through points, and a third time it takes you to the sketch curve tool. It can be super useful to assign a letter to a group of tools instead of just one tool. You can still have the option of assigning a key to just one tool and the option of pressing a letter and a modifier key to cycle or just without the modifier key! Just an idea that came to my mind while reading...

Hi Michael,

is it possible to create a frameless moi dialog window? kinda like the the way the fullscreen window works...

also, how can I change the border of a flyout menu...seems like the outer frame with rounded corners and white bkg is controlled by Moi. I couldnt find any references in the CSS.

Thanxs,

--Luis

Hi Luis,

> is it possible to create a frameless moi dialog window?
> kinda like the the way the fullscreen window works...

Right now there is no way to turn off the title bar for a dialog - dialogs are mainly meant to have titles and flyout menus are the ones that do not have a title on them.

The only thing you can control for a dialog frame right now is if it has a resizeable outer border or not.


> also, how can I change the border of a flyout menu...seems like
> the outer frame with rounded corners and white bkg is controlled by Moi.

This is one of the few remaining border-type things that is still image based - the border comes from the image FlyoutBorder.png or FlyoutBorder2.png in the \ui subfolder.

At some point that will get converted to be procedurally drawn instead. But it's actually drawn around the outside of the HTML frame by MoI itself and not the HTML engine.

- Michael

>>At some point that will get converted to be procedurally drawn instead. But it's actually drawn around the outside of the HTML frame by MoI itself and not the HTML engine.

That would be great. If while you're at it you can make it such that the borders are actual CSS borders and the rendering is done by the webkit engine then it would make it a whole lot easier to develop more panels in a fully customizable way. BTW, is it possible today to have semi-permanent flyout menus...(e.g. they stay up on top like the dialogs but with no window border).

Hi Luis,

> If while you're at it you can make it such that the borders
> are actual CSS borders and the rendering is done by the
> webkit engine then it would make it a whole lot easier to
> develop more panels in a fully customizable way.

It's probably not going to happen like that though - doing kind of fancy borders like that is somewhat laborious in HTML, there are some things like that which are easier to do outside of HTML that can help to simplify the structure and use of the UI.

It would not be that great just for general development if flyouts had to contain some kind of elaborate markup in each one - the way it works now is you can make a flyout that just contains only the controls that you need, that makes it a lot easier to develop stuff.

One thing that I could do though would be to make an option to have a borderless flyout so that you could make a custom one with whatever fancy markup you wanted inside of it.


> BTW, is it possible today to have semi-permanent flyout
> menus...(e.g. they stay up on top like the dialogs but with
> no window border).

No, not currently - flyouts are designed to be transient popup menu like things, and it is built in to them that they automatically close when they lose activation, like when you click on some other window.

For a persistent modeless window you will need to use a dialog for that right now.

- Michael

Hi Michael,

>> doing kind of fancy borders like that is somewhat laborious in HTML.

I would've thought differently. but ok.


>> It would not be that great just for general development if flyouts had to contain some
>> kind of elaborate markup in each one...

perhaps a base structure could've helped here whereby all others inherit from it.


>> One thing that I could do though would be to make an option to have a borderless flyout
>> so that you could make a custom one with whatever fancy markup you wanted inside of it.

Yes, yes...

I think that would actually take care of most stuff and I would definitely make use of it.

In the end, I would like at some point to be able to create DIV-like panels that can be shown, hidden,
positioned and/or destroyed via javascript so I can better manage and control the look and feel. So
whenever you get to it that would be fine.

>> For a persistent modeless window you will need to use a dialog for that right now.

Ughh. :p

BTW, thanks for your replies. They are always very informative.

--Luis

Hi Luis,

>> doing kind of fancy borders like that is somewhat laborious in HTML.
>
> I would've thought differently. but ok.


Some kinds of things can be quite annoying to do in HTML - the particular tricky thing about the flyout border is that it's not just a static border, it has a connector piece that's variable width, that expands to match the launching element's size.

Here are a couple of examples where you can see the difference in the width of the connector piece of the border:

  


Then on top of that variable width part, the connector can also go on any side of the window, like above you see one is on the bottom-left and the other is on the top-right.

Here's one with the connector on the side:




That flyout border thing is quite a bit more complex than you might think it is at first glance.

- Michael

Hi Michael,

I certainly understand about the annoyances. The connector piece is one of them of course, but that is exactly what I would like to be able to control and modify.

I figured, if I can set and/or get the window panel coordinates via js then I should be to draw a custom connector anywhere along any of the borders as a separate entity on top. Kinda of a hack, but it may just work.

I plain webkit-enabled panel without any Moi-drawn borders/or edges at some point would be just great (i think that's what you mentioned before). Of course, it probably wouldn't be for everyone, which is why I would just make the default border style live in a CSS definition for all children to inherit from it...

Just wishful thinking at this point...

Thanks,

Luis

Hi Luis,

> which is why I would just make the default border style
> live in a CSS definition for all children to inherit from it...

I will probably end up with the colors defined in the CSS (or possibly in a separate color definition file that will contain all colors in it) - it's possible for custom C++ code to read some parameters out of the moi.css file itself, for some things that are drawn directly and not using the HTML engine.

It's actually doing that already in certain cases - including for the flyout border, the border comes from an image file that is defined as a flyoutBorderImage CSS property set on the body, that's how some flyouts have that darker style image on them, they are set to use the FlyoutBorder2.png image.

I do not think it will be feasible to make the borders drawn using the HTML engine though, I've tried to describe above the issues that make that difficult.

- Michael

Thanks Michael.

FYI, as long as the corner roundness and background colors are controllable then it doesn't matter to me which engine draws it. I would use whatever you can make available... :)

If you do plan on enabling something like that during the beta let me know so I can test it...opacity and padding would also be of interest...

Best,

Luis