We should try to minimise the use of dialogues in general, but especially we should avoid modal dialogues. A modal dialogue can block the workflow badly. The reasons against modal dialogues should be obvious. Those that don't follow this rule, should be hunted down, skinned alive and then slowly be roasted." "GUI developers should avoid modal dialogues at all cost. The general advice is to not use them if you can avoid it. Most usability guides today try to downplay the role of modal dialogue. Maybe even some more fine-grained settings would be useful. In this case the editor needs a setting that determines, if a new editing component is opened in a new window or in the same. One possible way to implement this is to have a top level window (any number of top level windows), that acts as a container for one or more editing component. But it must be unobtrusive and not get in the way of a more distributed workflow. We may use some kind of docking system (either tabs or sub-windows or both) to satisfy the needs of people with only one screen and one workspace. But our CS consists of collection of semi-autonomous sub-editors with only loose coupling. This is already true for a much more simple type of editor. Having a few editing components on one screen and a few others on the second can be pretty useful. And finally, some people have multiple screens. Also people may want to spread out their stuff across multiple workspaces. Some people prefer to have individual windows that can be moved around individually on their desktop. Keep in mind that not everybody is comfortable with working in maximized/full-screen mode. Being configurable is a very important feature of a GUI. If we ignore the primary rendering context problem, OGRE delivers it out of the box and I hope Qt does the same.ģc. So just lets make this short and declare that all models should have multiple views.Īgain this feature should be pretty simple to implement. And I am sure, if we look around long enough, we will find arguments for each component. We could continue like this and argue for each editing component why having multiple views can be useful. But having multiple specialised palettes open at once will make worldbuilding much easier. You can simply switch filters within one view. That means you need different filter settings during an editing session. Now we discussed already that ID lists should be filtered. To view a location from multiple viewpoints at once. Here are some usage scenarios related to the CS: Its a shame, because this is an incredibly useful feature and once you got used to it using an application without it, is about as comfortable as using an application without copy & paste functions. Of all major applications I can only name three that do support it (OpenOffice, Inkscape, Gimp). This is a very old feature and I am rather surprised, that it hasn't caught on more. More work and probably slower, but should work with 1.7. Startup Ogre again and recreate all rendering widgets. ![]() ![]() When the primary window/widget is closed, close all rendering widgets. If we do the rendering components last, we may not even have to wait. Just waiting for the next major OGRE release should sort everything out. Actually, this problem will bite us in a few more cases (see 3b and 3c). This won't work with two documents open at once in the same instance, when they are closed in the wrong order. Once this is gone, OGRE can't continue to run. OGRE insists on a primary rendering context (i.e. There is a problem with this approach though. Just avoid document-related static variables and close the application when the last document is closed. That is potentially a huge optimisation.Īnd thirdly, implementing this feature is completely trivial. By running only one instance we can make OGRE load these shared resources only once. In most cases it even will be pretty big. That means usually if you have two group of master/plugin files, the intersection of the resources used by these two groups will be non-empty. Currently all mods and TCs use the same resources file directory tree (textures, meshes and such). One example would be a race-condition when writing user preferences to disc. ![]() Second, running multiple instances of the editor can cause all kind of problems. Since copying it directly might not be viable, you will want to have the plugin open in a separate window alongside your own project. A usage scenario would be a plugin, that already implements a feature, that you want in your own project. Reuse of existing stuff is extremely common in the MW modding community. What might not be so obvious is that this is true for the CS too. ![]() The reason for this design rule are manifold.įirst, for most editor types it is obvious that you want to be able to edit more than one document at a time. Every editor should be able to handle multiple documents at once (without starting a second copy of itself).
0 Comments
Leave a Reply. |