Go?

Involved development of the OpenMW construction set.
User avatar
Star-Demon
Posts: 73
Joined: 11 Aug 2011, 03:17
Location: New York
Contact:

Re: Go?

Post by Star-Demon »

Well, we mentioned organizing by workflow - many elements can be divided up by sets of tasks.
Spoiler: Show
You work on items separately from game and Other data - inserting and dragging and dropping from one window to another. They have thier own windows -and function like discussed. It's just that they are more accessible. Maybe icons? or just stick with a menu?

I don't think Docking would be a good idea - but we should also support it - I'll play with it.
User avatar
sirherrbatka
Posts: 2159
Joined: 07 Aug 2011, 17:21

Re: Go?

Post by sirherrbatka »

Menu, but I would think about shortcuts. EMACS style if needed ? but then we need to have any window or other area to display cominations and tooltips like in LyX (that is the best app ever ;-)). So for dialogs this could be M+w, d (alt+W for windows, d for dialog), for cells M+w, c and so one.

PS
I'm not EMACS nerd ? I thought about LyX; like in emacs every action can be accessed with key combo. We don't need to go so far since there is no oder way to control CS than with mouse anyway. Still keyshortcuts can help this CS pr0.
User avatar
Star-Demon
Posts: 73
Joined: 11 Aug 2011, 03:17
Location: New York
Contact:

Re: Go?

Post by Star-Demon »

So we have to decide what shortcuts would do what.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Go?

Post by Zini »

I suggest we add the keyboard shortcuts last. When we have the full functionality implemented (or at least designed), it will be easier to assign reasonable shortcuts and to resolve conflicts (e.g. two commands beginning with the same letter, which makes both a candidate for the same shortcut).
User avatar
sirherrbatka
Posts: 2159
Joined: 07 Aug 2011, 17:21

Re: Go?

Post by sirherrbatka »

I would even go further and ask how We want to use this editor. At the moment the guidance is not complete.

I think that windows are fine with menubar, but where the menubar will be? We are going with main window and subwindows or maybe something more like GIMP?
User avatar
Star-Demon
Posts: 73
Joined: 11 Aug 2011, 03:17
Location: New York
Contact:

Re: Go?

Post by Star-Demon »

I imagine it's going to be more like GIMP, with a main window - perhaps docking QtCreator/VisualStudio Style.

GIMP on windows is a real pain - the windows are not very customizable, so I'm constantly toying with moving round the tool and tool settings bar, because it's always in my way. Same goes for the layers window.

OTOH - the Linux version seemed to function better...

Anyways - without discussing it too much - I think the menu on top opening subwindows that fit the workflow and separation of content ideas should be fine.

Make a single main window - it has a menubar and a dock. The rest are their own windows that can be messed with or dock in the main editor window.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Go?

Post by Zini »

Make a single main window - it has a menubar and a dock. The rest are their own windows that can be messed with or dock in the main editor window.
I have to disagree with this one. Actually we discussed this topic before (see the archive). The concept of a single main window is the bane of modern GUIs. Typically now we would get the argument that most applications are build that way. But that isn't strictly true. Counter examples: GIMP (not that I would name GIMP as an example for good GUI design), Inkscape, Open Office, Firefox.
In all these applications you have a "New window" menu item/button/keyboard shortcut or whatever. These let you open a new window in which you can view a different part of the document (a different section of the drawing in a different zoom in Gimp/Inkscape; a different page in Open Office; a different internet page in Firefox).
Our editor will allow us to view/edit different parts of the document (the ESP) in the additional windows too. Not sure if everybody is entirely clear about it, but we are talking about content view windows, not tool windows (like dialogues, toolboxes and such). I don't see a reason why these shouldn't be fully featured (with menus and everything). Anything else will only limit the workflow and become a problem later on.
User avatar
sirherrbatka
Posts: 2159
Joined: 07 Aug 2011, 17:21

Re: Go?

Post by sirherrbatka »

But I'm not sure about this. The biggest benefit of multi window interface of GIMP is that you can toss all tools on the second desktop. This could be also handy with CS ? like desktop 1: render window and objects and cells; desktop 2: scripts etc. But generaly it's not as good as with gimp.

I don't know if is it possible (or easy to creat) but I would consider wmii like interface inside main window.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Go?

Post by Zini »

I don't agree on the benefits of the GIMP interface. Actually I think it has barely any benefits at all. The guys who developed this interface recognised the problems of a conventional main window based interface. But they learned mostly the wrong lessons.

Editing tools should generally be placed in the Window that they are editing. Depends on what you call tools here.

Editing mode selection buttons (of radiobutton style) should be a fixed part of the editing window. A colour or texture selector might receive the same treatment, if it is small enough.

Dialogues that represent a process should generally be transient. I would argue that other controls that do not fit well into the above scheme (fixed to the window) are best kept transient too, but apparently we have a disagreement here with some people.

And then we have dialogues that represent a persistent entity (like an ESM/P ID). These can be integrated into the general window handling system (including docking). But we should use these only lightly. In-place editing is better than using a dialogue (modify an ID by changing an entry in the table that lists the IDs).

I think this requires careful analysis, especially in the context of our CS which will be more complex than your average editor.
I don't know if is it possible (or easy to creat) but I would consider wmii like interface inside main window.
Don't know if Qt can do that. It looks like one of the more sensible approaches to sub-windowing. But we should absolutely make sure that this is optional. Not everyone is comfortable with using sub-windows instead of separate top-level windows. Firefox is a good example of how to do it (you can configure Firefox to hide the tab bar, if there is only one tab). A bad example would be Eclipse, because no matter how you configure it, you will always have a visual and functional docking/sub-window overhead.
User avatar
sirherrbatka
Posts: 2159
Joined: 07 Aug 2011, 17:21

Re: Go?

Post by sirherrbatka »

My main problem with multiwindow interface is connected to "the OS with realy crappy window management" (i won't tell the name but it starts with "W"). Besides of that I would (!) even prefer to work with the editor like that, especially if I could easily (and swiftly) hide and call needed tools (preferable via key shortcuts performed with left hand). Even with my favorite KDE.

But I never seen app like that in qt, or gtk (or any other toolkit).

PS
I like GIMP interface but it's not suitable for CS so we have practicly the same opinion.
Post Reply