3x2 spacebar toolbox....

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

Post Reply
LukeW
Posts: 0
Joined: Mon Mar 03, 2003 1:14 pm

3x2 spacebar toolbox....

Post by LukeW » Sun Oct 19, 2003 5:15 am

My toolbox idea is a little like thorwil's
Image
(here's his thread)

In mine, there are always between 2 and 6 items in the menus. With 6 items, it would look like this:

Code: Select all

+---------+---------+----------+
|  item1  |  item2  |  item3   |
|         |         |          |
|      W   \   E   /  R        |
|        +-----------+         |
|________|  Category |_________|
|        |   Title   |         |
|        +-----------+         |
|      S   /   D   \  F        |
|         |         |          |
|  item4  |  item5  |  item5   |
+---------+---------+----------+
The W, E, R, S, D, and F are the menu hotkeys. They could be very tiny. The regular hotkeys for the items could also be shown since the regular hotkey is the fastest way for the user to do a command in the first place.[/code]

Here is what the layouts could look like for various numbers of items:
WER
SDF

WE
SDF

E (aligned with the d)
SDF

SDF

S F

I chose those layouts because I think the hotkeys used become progressively easier. I mean for the 5 item layout, the upper-right "R" hotkey is no longer used - since it is a little hard for me assuming my left hand is in the "home row". I guess the upper-left "W" is a bit hard to reach too.

You'd also be able to use the spacebar and escape key. The escape key would be used to exit the toolbox straight-away, and the spacebar, besides being used to enter the toolbox, could also be used to used to go back a level in the toolbox menu in case you made a mistake. You'd be able to use the mouse to move through the menus as well, and each time a new level of menus pops up, the mouse would begin in the centre (which repeats the title of the category you have gone to). I think it would be faster for experienced uses to use the keyboard to navigate around it though since it would be easier to move the mouse to slightly the wrong place when doing it fast and therefore make a mistake. With the keyboard you'd just use 3 fingers and a thumb and only move 1 key away from the "home row" at the most. And usually your left hand would begin near the home row anyway. (since it is used for a, d, r, g, x, w, tab, ctrl, etc)
BTW, the menu hotkeys used have a very direct spatial relationship to the proposed toolbox menus... i.e. the middle upper hotkey is in the middle upper position on the menus and on the keyboard, etc. (BTW, if a menu item has a hotkey that uses w, e, r, s, d, or f, that menu item would be moved so that both the normal hotkey and menu hotkey match [or nearly match, in the case of s and shift-s [the snap menu])
So what do people think?

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Sun Oct 19, 2003 12:24 pm

I don't think keyboard navigation inside the Toolbox is important enough to base the whole design on it.

However, my design could be navigated with numpad keys and cursor keys for the submenus.

If you use a menu per keyboard, the menu is only a map of the keys to type. It's most effective to have traditional pulldown menus with mnemonic keys. So you might type Alt+F, N for File:New_Tab (example taken from my Browser). I think this is superior to any special way of keyboard navigation inside the Toolbox and would make such superfluous.

Problems I see with your proposal:

Number of Items
The restriction on 6 items could make things difficult (well, I had designs with only 4 top items, but that was before I worked out all the stuff that must fit into the menu (3D view, Object or Edit Mode, no other windowtype/mode should require more commands)).

Radial Submenus
If I understand you correctly, you propose to use radial submenus. You will have to show how you fit all the commands into nice sets of upto 6 items!

Or Consistency
Without radial submenus you would have a special navigation technique just for the top level!

Indicating Keys
You will need different styles of showing navigation keys that only work inside the menu and actual shortcuts/hotkeys. Could be confusing.

Autocompletion
No (sane) way to integrate command autocompletion here. I know some people are sceptical about that feature, but Ton already stated that he likes it (twice), the only question is, when it will be implemented and if it will index all commands or only the contents of the current Toolbox right from start (that's at least my understanding of the situation).

In principal, autocompletion could be seperated from the Toolbox, but the spacebar is ideal for it, and I'm sure it's going to fit into the Toolbox well enough.

LukeW
Posts: 0
Joined: Mon Mar 03, 2003 1:14 pm

Post by LukeW » Sun Oct 19, 2003 2:21 pm

thorwil wrote:I don't think keyboard navigation inside the Toolbox is important enough to base the whole design on it.
I'm still taking the mouse efficiency into account a lot...
However, my design could be navigated with numpad keys and cursor keys for the submenus.
There doesn't seem to be a clear way of navigating in the top level of your menu though... and in the submenus, you'd have to press the arrow or number pad keys repeatedly to move through longish menus... in my idea you just press 1 key to get through each submenu.
If you use a menu per keyboard, the menu is only a map of the keys to type. It's most effective to have traditional pulldown menus with mnemonic keys. So you might type Alt+F, N for File:New_Tab (example taken from my Browser). I think this is superior to any special way of keyboard navigation inside the Toolbox and would make such superfluous.
But how can this be done in blender? alt-o, alt-a, alt-t, alt-r, etc are already hotkeys.
BTW, the idea is that the menu keys here have a direct spatial relationship with the menus you are navigating. The actual key letters aren't very important. It is a bit like in many games, you use a, s, d, and w to move around.... people wouldn't be conscious exactly what letter name they're pressing... they'd just know if they're pressing the leftmost one, or the uppermost one, etc. In some other games, you'd use j, k, l, and i to navigate around and it's the same principle.
Problems I see with your proposal:

Number of Items
The restriction on 6 items could make things difficult (well, I had designs with only 4 top items, but that was before I worked out all the stuff that must fit into the menu (3D view, Object or Edit Mode, no other windowtype/mode should require more commands)).
I think you should have to press tab beforehand to enter editmode and access the editmode commands (maybe you'd agree). BTW, I'm talking about having a maximum of 6 items at the toplevel and in all the submenus.
Radial Submenus
If I understand you correctly, you propose to use radial submenus. You will have to show how you fit all the commands into nice sets of upto 6 items!
In 2.29, the menus are already broken up into small groups with 5 or less items (usually about 2 or 3) and the groups are separated by gaps. I could get ideas from there and combine and reorganize some of the groups.
Or Consistency
Without radial submenus you would have a special navigation technique just for the top level!
The submenus are in the same form. They would have between 2 and 6 items and be in the layouts I listed in my first post. And the last item you moved on or press the hotkey for would become the title for the new submenu which would be should in the middle and centered on the mouse.
Indicating Keys
You will need different styles of showing navigation keys that only work inside the menu and actual shortcuts/hotkeys. Could be confusing.
There could be tiny icons like black circles with a white letter for the menu hotkeys. And maybe if the menu hotkeys aren't used to get past the first level, they could disappear? Or they could just show on the first level for everyone? Or maybe they're not shown there at all but they're a hidden feature?
Autocompletion
No (sane) way to integrate command autocompletion here.
Yeah, it would be incompatible with command autocompletion...
I know some people are sceptical about that feature, but Ton already stated that he likes it (twice), the only question is, when it will be implemented and if it will index all commands or only the contents of the current Toolbox right from start (that's at least my understanding of the situation).

In principal, autocompletion could be seperated from the Toolbox, but the spacebar is ideal for it, and I'm sure it's going to fit into the Toolbox well enough.
Well if there is command autocompletion in the toolbox then I doubt the toolbox would be able to be navigatable using the keyboard as fast as you can as with the mouse... (like would be the case with my idea for experienced users). But maybe it is better to rely on the mouse in the toolbox menu and have a command auto-completion thing. Only relevant things should be listed there... so no posemode stuff if a mesh is selected, and no editmode commands if you're not in editmode. (It is easy to switch into edit mode first.... and maybe mode switch could be done within the toolbox using tab or ctrl-tab, then not exiting but instead allowing you to see the updated list of commands...?)

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Sun Oct 19, 2003 3:38 pm

Something I forgot in my last post:
Your menu will be not as easily browsable as mine. Because you need special means of going back a level. That's not a concern after some training, but affects learning.
If you use a menu per keyboard, the menu is only a map of the keys to type. It's most effective to have traditional pulldown menus with mnemonic keys. So you might type Alt+F, N for File:New_Tab (example taken from my Browser). I think this is superior to any special way of keyboard navigation inside the Toolbox and would make such superfluous.
But how can this be done in blender? alt-o, alt-a, alt-t, alt-r, etc are already hotkeys.
The shortcuts would have to be revised or a special key would have to be used to start keyboard usage.
BTW, the idea is that the menu keys here have a direct spatial relationship with the menus you are navigating.
That's clear from your original post.
I think you should have to press tab beforehand to enter editmode and access the editmode commands (maybe you'd agree).
Sure I agree, remember that it was already decided to make the menu fully context sensitive.
In 2.29, the menus are already broken up into small groups with 5 or less items (usually about 2 or 3) and the groups are separated by gaps. I could get ideas from there and combine and reorganize some of the groups.
Sure the submenus are rather small. But the first levels of "View" and "Mesh" are not! You can't use the same top levels because of that.

Were you might run into problems:

Add:
1. Mesh
2. Curves
3. Surfaces
3. Text
4. Metaball
5. Empty
6. Camera
7. Lamp
8. Armature
9. Lattice

Could be splitted in 2 groups, like "Actors" and "Crew".
But remember that any additional level makes the menu harder to use (oversight ans access times). Or would you leave it out entirely? (I've decided for me to include things relating to the 3D cursor, so these are in.)

Transform (from my proposal, but using the 2.29 organization directly doesn't work anyway, the Mesh menu is loong!):
1. Grab
2. Rotate
3. Scale
4. Shear
5. Warp
7. Shrink/Fatten
8. Numerical
9. Apply > (Size/Rot ...)
10. Clear > (Loc/Rot ...)

Even without "Clear" and "Apply" which can be placed somewhere else easily, you still have 8!
Grab/Rotate/Scale are not in the menus, because they don't work that good started from menu and are used very often. But because of this, I think they should be in the Toolbox to give hint at the G, R and S keys.

Curve: Control Points:
1. Tilt
2. Clear Tilt
3. Toggle Free/Aligned
4. Vector
5. Smooth
6. Make Vertex Parent]
7. Hide Selected Control Points
8. Show Hidden Control Points

Vertices:
1. Merge
2. Split
3. Seperate
4. Smooth
5. Remove Doubles
6. Make Vertex Parent]
7. Select Connected Vertices
8. Hide Deselected Vertices
9. Hide Selected Vertices
10. Show Hidden Vertices
11. Make Edge / Make Face

Faces:
1. Fill
2. Beauty Fill
3 .Convert Quads to Triangles
4. Convert Triangles to Quads
5. Flip Triangle Edges
6. Hide Selected Faces
7. Hide Deselected Faces
8. Show Hidden Faces

And keep in mind, that the number of functions available in Blender will only grow!
There could be tiny icons like black circles with a white letter for the menu hotkeys. And maybe if the menu hotkeys aren't used to get past the first level, they could disappear? Or they could just show on the first level for everyone? Or maybe they're not shown there at all but they're a hidden feature?
A little many maybes! I think it's going to be hard to solve this problem. And hidden features are no solution, but a problem (well, at least in most cases).
Well if there is command autocompletion in the toolbox then I doubt the toolbox would be able to be navigatable using the keyboard as fast as you can as with the mouse... (like would be the case with my idea for experienced users).
I think that it is possible to reach very high speed on the Toolbox without keyboard navigation. So there's not that much to gain in speed. In most cases, the user will have one hand on the mouse, the other on the keyboard. Placing your fingers to work some keys that share a spational relationship with something on the screen might cause quite some delay!

I would like to recommend, that you put keybaord navigation aside and work on the organization of menu items. And if you can't fit it into 6, try 8! The maximum number of items recommended for radial menus is 12.

LukeW
Posts: 0
Joined: Mon Mar 03, 2003 1:14 pm

Post by LukeW » Sun Oct 19, 2003 4:46 pm

Ok, I guess it isn't such a good idea for blender.... Pity I emailed the Blender committers mailing list about it 3 times.... :oops: (I don't want to get a reputation for having lousy ideas...)
BTW, with your mock-up, it is only for 8 items on the lowest level... would different contexts have different numbers of items at the lowest level?

Also, how about this as an idea for a radial type menu... (note that it isn't really keyboard navigatable)

Code: Select all

  ____________
 /    |    |   \
|  1 | 2  | 3  |
|___  \__/  ___|
|   \ /  \ /   |
| 4  | X  | 5  |
|___/ \__/ \___|
|     /  \     |
| 6  | 7  | 8  |
 \____|____|___/
I know it looks funny but the point is that it is basically a radial menu with 8 items. The items could be squarish by having 2 word entries on 2 lines, and putting the hotkeys on the separate line (not having everything on one long line).
Anyway, when they hover their mouse over the corner items (1, 3, 6, 8), a submenu would appear that is a radial menu - well actually it could be 3/4 or 1/2 of a circle, where the previous menu fills in the gap. It would be easy to go back to previous menus (since they don't need to disappear or me covered up) and even go to other items in the previous menus... e.g. you could go to 6, then one of its submenus, then go back... to 7 and when you go over 7, its submenus would appear. For 2, 4, 5 and 7, there would be radial menus that are about 1/2 to 1/3 of a circle.

I think it would be easier to remember there things are this way because you'd be constantly moving away from the centre. This contrasts with a menu that has full radial submenus since you could be going back and forth a lot which would be harder to remember I think, plus it would be harder to go back a level. The items could be different shades of grey or something to help experienced users rapidly get your bearings without having to read things.

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Sun Oct 19, 2003 5:26 pm

LukeW wrote: BTW, with your mock-up, it is only for 8 items on the lowest level... would different contexts have different numbers of items at the lowest level?
Would you say that a general has a low level? So please, the menu starts with the highest level! ;-)

Yes, the menu will propably have 6 or even only 4 top level items in some cases. But I'm aiming at having 8 for most.

I will not comment on your latest idea until you give me something I can look at (real graphics)! Well, two things: my first design was based on this "filling the gap" thing, and it costs you at least 1 item per submenu.

It seems you still avoid the hard part of working out the organization. I can understand that, realy! But it would be more helpful for the project if you would work on that. You should first make sure, that the number of items that can go into a submenu is sufficient!


You could help me by defining top levels and items for the other window-types.

LukeW
Posts: 0
Joined: Mon Mar 03, 2003 1:14 pm

Post by LukeW » Mon Oct 20, 2003 7:36 am

thorwil:
Sorry about the high-level/low-level mixup...
Anyway, here's that idea I just suggested:
Image
Basically it is easy to go back to the previous levels.

I applied that idea to yours:
Image
(Though yours is only radial at the start)
I think ton proposed something like that earlier...

This is a related variation:
Image
Basically, when you put your mouse on "Object", the object menu will pop-up, but not cover the mouse. When you mouse the mouse over to the object menu, the next submenu might cover the original radial menu sometimes...

The reason why I don't think the radial menu should immediately be covered as soon as the mouse is hovering over the word "Object" is because the user might have actually been wanting to select "Relation", but now they can't since "Relation" is now covered up... I mean it could be pretty hard to correctly move the mouse into the right area, especially if you're doing it pretty quickly. Plus this latest suggested way (in that last mock-up) would be less confusing for the user since nothing gets covered up too quickly. (I know the user could get out of the "Object" submenu and get into the "Relation" submenu using your original method, but it is a bit confusing)

So now I'm favoring a variation of your method. Your method (where "Object" immediately would get covered up) would be faster for coordinated users due to the reduced mouse movement though.
You could help me by defining top levels and items for the other window-types.
It depends what you want to have in the toolbox - whether you want to include the View, Animation and the File menus.... I mean should all of the menu items be duplicated? Or just the ones that aren't in the file, etc, menus? (But maybe the file, etc, menus aren't visible, like when the 3D view is maximized...)

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Mon Oct 20, 2003 3:42 pm

You variations on my design would mean much longer ways. With the first example, you would have to cross the whole width of the word "Object" plus the width of the submenu to reach the 3rd level. It would also mean that mousepointer and menu would have to be moved away from the screen edge much sooner, to make sure the lowest level menu will fit on screen.

One very important feature of my design is that 3rd level menus are shown to the inside of the toolbox. This way, you have to move the pointer only a short distance sideways to access the 3rd level from 2nd.
And you will end out closer to your starting point after using the Toolbox. Only a detail, but I think a nice one!
LukeW wrote: The reason why I don't think the radial menu should immediately be covered as soon as the mouse is hovering over the word "Object" is because the user might have actually been wanting to select "Relation", but now they can't since "Relation" is now covered up... I mean it could be pretty hard to correctly move the mouse into the right area, especially if you're doing it pretty quickly.
It isn't that hard to hit the right item directly, because the active area starts with some distance to the center, so the target areas are quite large. And you don't need to worry about overshooting the target, because you than move the pointer over the submenu. So here is another advantage of placing the submenus right over their labels besides distance (and thereby another argument against your variation).
Plus this latest suggested way (in that last mock-up) would be less confusing for the user since nothing gets covered up too quickly. (I know the user could get out of the "Object" submenu and get into the "Relation" submenu using your original method, but it is a bit confusing)
I don't think it's that confusing. The advantages far outweighs this very little disadvantage.
You could help me by defining top levels and items for the other window-types.
It depends what you want to have in the toolbox - whether you want to include the View, Animation and the File menus.... I mean should all of the menu items be duplicated? Or just the ones that aren't in the file, etc, menus? (But maybe the file, etc, menus aren't visible, like when the 3D view is maximized...)
Ton made clear there's no way rather global things like "File" make it into the Toolbox. And if I recall corectly, he doesn't want to see things like view-options there either.

I think that items relating to things inside a window should be in the toolbox, but items relating to the window itself not.

I would like to have the possibility to directly access all menus even from maximized 3d views. But then I think it should be like in Maya, with the Hotbox (spacebar) including everything and the context-sensitive marking-menus (right-click-hold). That's because a Toolbox containing everything will be rather slow to operate, so it would make sense to have another kind of right-under-the-mouse-menu. I mentioned the possibilty of a right-click-hold radial menu on the bf-funboard list, but nobody replied!
Well, for fast access to everything at all times I can point to the command autocompletion feature!

LukeW
Posts: 0
Joined: Mon Mar 03, 2003 1:14 pm

Post by LukeW » Tue Oct 21, 2003 11:39 am

thorwil wrote:.....It isn't that hard to hit the right item directly, because the active area starts with some distance to the center, so the target areas are quite large.
Image
In your starting menu the little space you've got to get your mouse pointer through is about 11 or 12 pixels long... that is about half the height of the "Add" and "Object" areas. BTW, when the Object submenu appears it could just be partly covered up - so maybe the "O" is still visible, and the whole word could be moved closer to the centre of the toolbox...
And you don't need to worry about overshooting the target, because you than move the pointer over the submenu.
The problem is that you have to squeeze the mouse through a relatively small space, and if you aren't steady enough you'll accidently go through the wrong gap and so go to the wrong submenu, making it a little difficult to get back to the correct submenu. Plus, if you weren't familiar with the submenus you mightn't even be aware if you were at the wrong submenu straight-away. If the "O" was still visible, there would be instant feedback that you were at the correct submenu, without you having to read the items in the submenu.
I don't think it's that confusing. The advantages far outweighs this very little disadvantage.
What about moving the first submenu over to the side a bit so that the first letter of the top-level menu is still visible. That way the submenu doesn't suddenly appear in front of the mouse, allowing people to clearly visually confirm that the submenu came from the correct item (Add, Group, Relation, etc) They'd also be able to browse through the submenus easily since none of the toplevel names would be completely covered up - unless you moved your mouse over to a submenu, like this:
Image
Note that the Object submenu would be shifted to the left a lot.
I'll guess I'll drop that then... I mean I guess the toolbox should sacrifice user-friendliness in order to be faster. If it is too slow to use people could just use the regular menus or hotkeys....
Ton made clear there's no way rather global things like "File" make it into the Toolbox. And if I recall corectly, he doesn't want to see things like view-options there either.
Ok...
I think that items relating to things inside a window should be in the toolbox, but items relating to the window itself not.
I'd assume that doesn't apply to buttons windows, just some things like 3D views, IPO, NLA, Action windows, etc.
I would like to have the possibility to directly access all menus even from maximized 3d views. But then I think it should be like in Maya, with the Hotbox (spacebar)
Do you mean totally everying should be in the toolbox menu? Or just context+view+file stuff? Or just view+file stuff?
including everything and the context-sensitive marking-menus (right-click-hold). That's because a Toolbox containing everything will be rather slow to operate, so it would make sense to have another kind of right-under-the-mouse-menu. I mentioned the possibilty of a right-click-hold radial menu on the bf-funboard list, but nobody replied!
It just doesn't seem very productive to have to wait for the right mouse button menu to appear... and if the delay was too short, it would be annoying if you never use it and you just want to select things... And you'd have to make sure you're far away from stuff so you don't accidently select stuff. (I think in some cases, at least for vertices, you don't have to click on them precisely)
Well, for fast access to everything at all times I can point to the command autocompletion feature!
I'm not a fan of it, but fortunately the feature wouldn't really annoy me since it wouldn't usually be using up screen space or anything.

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Tue Oct 21, 2003 1:05 pm

LukeW wrote: In your starting menu the little space you've got to get your mouse pointer through is about 11 or 12 pixels long... that is about half the height of the "Add" and "Object" areas.
There's need for a prototyp. I did some work on a flash version, but it's not ready for the public yet and I don't know when I find time to finish it.

I will propably change the submenu positioning, so that they appear just outside the space with the diagonal lines.

And by increasing the size of the whole menu, the target areas can be enlarged.
I think that items relating to things inside a window should be in the toolbox, but items relating to the window itself not.
I'd assume that doesn't apply to buttons windows, just some things like 3D views, IPO, NLA, Action windows, etc.
Yes, buttons windows might be special case. In the end it's more important to have useful options in the Toolbox, than strictly adhering to some rules the user will not know or (conciously) care for.
I would like to have the possibility to directly access all menus even from maximized 3d views. But then I think it should be like in Maya, with the Hotbox (spacebar)
Do you mean totally everying should be in the toolbox menu? Or just context+view+file stuff? Or just view+file stuff?
Totally everything, but only when other means of accessing often needed options are provided.
including everything and the context-sensitive marking-menus (right-click-hold). That's because a Toolbox containing everything will be rather slow to operate, so it would make sense to have another kind of right-under-the-mouse-menu. I mentioned the possibilty of a right-click-hold radial menu on the bf-funboard list, but nobody replied!
It just doesn't seem very productive to have to wait for the right mouse button menu to appear... and if the delay was too short, it would be annoying if you never use it and you just want to select things... And you'd have to make sure you're far away from stuff so you don't accidently select stuff. (I think in some cases, at least for vertices, you don't have to click on them precisely)
The delay will be no problem for advanced users, because they can operate the radial menu blindly. And the delay can be very short, because normal mouseclicks are even shorter. You can already use the LMB for positioning the 3d cursor or making some gestures. I don't use those often, but I tested it and it works without any problems!

But for now I guess it's more productive to concentrate on a nice context-sensitive Toolbox. It raises more than enough problems and scepticism for my taste!

LukeW
Posts: 0
Joined: Mon Mar 03, 2003 1:14 pm

Post by LukeW » Thu Oct 23, 2003 12:38 pm

thorwil wrote:....I will propably change the submenu positioning, so that they appear just outside the space with the diagonal lines.
I like that idea... and original main menu item you've selected could be highlighted (though you'd only see a small part of it) - so that you can see that the right one was selected while you "crossed the line" from the initial mouse starting position
And by increasing the size of the whole menu, the target areas can be enlarged.
That would make the toolbox cover things up more though... maybe + and - could be used to resize the toolbox? (and the mouse wheel could do something - maybe resize it as well)
I would like to have the possibility to directly access all menus even from maximized 3d views. But then I think it should be like in Maya, with the Hotbox (spacebar)
Do you mean totally everying should be in the toolbox menu? Or just context+view+file stuff? Or just view+file stuff?
Totally everything, but only when other means of accessing often needed options are provided.
Do you mean "but only when other means of accessing often needed options areN'T provided" ?
So if the 3D window is maximized, the main menu would have to be squeezed into the toolbox somehow...
...And the delay can be very short, because normal mouseclicks are even shorter. You can already use the LMB for positioning the 3d cursor or making some gestures. I don't use those often, but I tested it and it works without any problems!
The gesture thing is different... if there is a still LMB click and release, then it repositions the cursor. If it is a moving LMB click, then the gesture lasts for as long as the LMB is held and ends when it is released, then it goes into grab, rotate or scale mode. I don't think any delay is involved in the gesture thing.
But for now I guess it's more productive to concentrate on a nice context-sensitive Toolbox. It raises more than enough problems and scepticism for my taste!
What about the layouts for various numbers of toplevel categories? e.g. 7 categories, etc?

thorwil
Posts: 0
Joined: Tue Sep 09, 2003 10:30 am

Post by thorwil » Thu Oct 23, 2003 1:17 pm

LukeW wrote:
Totally everything, but only when other means of accessing often needed options are provided.
Do you mean "but only when other means of accessing often needed options areN'T provided" ?
So if the 3D window is maximized, the main menu would have to be squeezed into the toolbox somehow...
No I mean with an all-including Hotbox like thing there would be the need to have another menu for fast access to often needed items (context-sensitive).
What about the layouts for various numbers of toplevel categories? e.g. 7 categories, etc?
For 7 toplevels, 2 sections would have to be combined.
And sorry Luke, but I'm tired of this dialogue, since I don't think anybody cares for what we're writing in this thread anyway. And that's justified, because this stuff is hard to read with all the long posts and quotations.

I need to do some work on my Toolbox and you should try to organize and work out your ideas into something coherent and presentable.

LukeW
Posts: 0
Joined: Mon Mar 03, 2003 1:14 pm

Post by LukeW » Thu Oct 23, 2003 2:04 pm

thorwil wrote:.....And sorry Luke, but I'm tired of this dialogue, since I don't think anybody cares for what we're writing in this thread anyway.
Well I'd be happy to leave it there... I just didn't want to seem rude and not reply.
I need to do some work on my Toolbox and you should try to organize and work out your ideas into something coherent and presentable.
Ok, but my ideas won't involve the toolbox for the forseeable future.... you sound like you're on the right track and I'd like to concentrate on things that others aren't (copy/paste issues, automatic panel size and arrangement optimization, etc).

Post Reply