Dialog groups

On 24/04/2014 at 15:58, xxxxxxxx wrote:

Since the C4D dialog interface isn't WYSIWYG but instead more like general HTML layout, it is difficult to get precise control of elements in the interface.  Groups are a good way to get some control but you still can't put elements at precise locations or give precise sizes (only starting or minimum sizes).

If you are going to try to use C4D dialog elements in a 'non'-C4D dialog, this might be the painful path.  If you can use, say, OS-related dialog elements in an OS-related dialog, all you need to do is make the interface connections between the OS-related elements and the C4D elements in some way (maybe with a dummy, undisplayed dialog as intermediary?).

On 24/04/2014 at 16:23, xxxxxxxx wrote:

I've been searching for an interface connection like that for months Robert.
The main problem I can't get around is that we can't send an OS message to C4D from our OS dialogs.
If I click on any gizmo in my OS dialog. It sends out a generic message that C4D receives. Which I can use to do something like create a cube.
But that's the only message C4D will see. So I can't have more than one gizmo in my dialog sending their own message to C4D like the built-in GeDialog.

The other problem is that my OS dialog fights with C4D for resources.
The cube will get created in the OM. But it won't show up in the scene until I move the OS window around a little bit.
The OS window also seems unstable. Like C4D is fighting with it.

I've done tons of experiments with it. But the results are very unstable.

-ScottA

On 26/04/2014 at 19:53, xxxxxxxx wrote:

For me, I'm not too concerned at whether we have a WYSIWYG system or not, it's more to do with whether or not you can get it to work the way you want it too. I'm happy doing it in plain code, but only if you know what you are hard-coding is reliable and will work. For the plugin I'm making, I've got it close enough to work I guess, but in this day and age, close enough isn't really good enough. If the underlying system is nearly 20-odd years old, then it's of no surprise it doesn't work well. There really shouldn't be any reason why we can't control these things ourselves by now. For a program that is known for it's intuitive and user friendly layout, it is horribly out of touch for the coders to work with!
 
I'll probably stick with cinema's layout for now, but am curious to know how much difference there is between OS' in regards to making dialogs - are win and mac able to use the same system?
 
WP.

On 27/04/2014 at 03:52, xxxxxxxx wrote:

Originally posted by xxxxxxxx

I'll probably stick with cinema's layout for now, but am curious to know how much difference there is between OS' in regards to making dialogs - are win and mac able to use the same system?

WP.

Short answer, very different and no. Building an interface on a PC using Visual Studio and C# is easy and intuitive, and getting the controls working with the code is simple. On a Mac I find it to be confusing and tricky to understand the concept behind how the controls work with the code, but that's just me. Point being though that the resource files created in Windows are of no use at all in Objective C programming on OSX, and vice versa.

Seriously, I would strongly recommend not wasting your time. Just accept that Cinemas's GUI will not allow you to layout your interface *exactly* as you would like it, and learn to live within its restrictions. Once you accept that, it becomes easy enough to get a decent layout.

On 27/04/2014 at 04:42, xxxxxxxx wrote:

Actually, I've found the C4D UI very intuitive and easy to implement,
especially in contrast to other applications/frameworks. But for this
ease of use, you must draw some limitations.

There's still user areas in case you need somethin special

-Niklas

On 27/04/2014 at 07:02, xxxxxxxx wrote:

Originally posted by xxxxxxxx

On a Mac I find it to be confusing and tricky to understand the concept behind how the controls work with the code, but that's just me.

That's because the Mac uses an MVC (Model-View-Controller) pattern which means that the gui 'displays' information, the controller 'gathers' user input, and the model 'stores' the data.  This disconnect can be difficult to design and follow but the advantage is that the data can be changed and displayed in various ways without having to associate it directly with gui elements.

On 27/04/2014 at 19:56, xxxxxxxx wrote:

Originally posted by xxxxxxxx

Seriously, I would strongly recommend not wasting your time. Just accept that Cinemas's GUI will not allow you to layout your interface *exactly* as you would like it, and learn to live within its restrictions.

Bit of a shame win and mac don't use the same 'stuff', but no surprise really. I'm fairly certain I'll stay with Cinema's system - at the moment I don't have much of a choice anyway. I've already had to replace native elements with my own user areas, looks like I'll just have to keep going down that track. A little annoying though given all we're doing is building something that's "almost" already there!
 
WP.

On 28/04/2014 at 03:01, xxxxxxxx wrote:

Originally posted by xxxxxxxx

That's because the Mac uses an MVC (Model-View-Controller) pattern which means that the gui 'displays' information, the controller '<span style="line-height: 1.4;">gathers' user input, and the model 'stores' the data.  This disconnect can be difficult to design and follow but the advantage is that the data can be changed and displayed in various ways without having to associate it directly with gui elements. </span>

On the rare occasions I have developed Cocoa software on the mac, it usually takes several days before I can get my head round the concept. But when that happens, I would have to agree that it is logical enough.

I grew up with Visual Basic in various flavours and then C# so for me the windows way is comfortably familiar. I guess if I'd always been mac programming that way would seem best

On 28/04/2014 at 13:20, xxxxxxxx wrote:

I'm not sure if this is related or not.
But have you guys noticed this job opening: http://www.maxon.net/about/jobs/singleview/article/user-experience-designer-mw.html
I wonder if this has anything to do with Maxon looking for help in possibly updating their ancient SDK GUI stuff?

I can't remember when this was first posted. But it seems like it's been there for a very, very long time.
Maybe even a year?

Maybe they want to update these things.
But they're having a hard time finding a qualified person to do it?

-ScottA

On 30/04/2014 at 22:21, xxxxxxxx wrote:

Not sure if I've seen that one before or not Scott. I wonder if it's a new position or an existing one?
 
WP.