On Wed, May 6, 2015 at 9:17 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:

On 06 May 2015, at 15:05, Tudor Girba <tudor@tudorgirba.com> wrote:

I would like to still be careful about those contextual actions and not mix the global with the contextual ones.

I know. 
But common sense is to have all possible actions in a tool with a visible representation (in toolbars, menus, others). Functionality accessible *just* through the contextual menus

Just confirming I read this right, by "contextual menus" you don't mean right-click "context menus" but menus that change their visible menu items per the theme of the rest of your post.  I have a strong preference for not hiding menu items, just disabling them.  It helps discoverability.  If its disabled, I can google the term for how-to use/enable it.  If I can't see it, I'm blind, and if it appears, its a surprise - and surprises are not good in UI design.

btw, some discussion here...
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=94078

cheers -ben
 
are not good (and you will see no serious GUI design guidelines recommend it… quite the oposite). 
One example: I made a configurations browser replacement. It shows all packages in a list, with tags for filtering and another pane to show descriptions (btw… a readonly text panel also would be ok)… 
Now, by selecting a configuration and right clicking, you can install it. 
This is plain wrong. 
Why?
Because the main purpose of such tool is to allow users to install. 
So by making them live just in the context menu you are hiding (or at least making not obvious) the main interaction the tool has as a purpose. 

Btw… I already reported this like 3 years ago, when I used Glamour to doing real life apps. This was the first observation I had each time I explained the system to users. 
At the moment, I just made my extensions.
But now I’m making tools for Pharo, so I cannot just extend. 



@Esteban: do you need these for lists or other presentations?

Lists, Tables, Trees… anything that can have a contextual menu with important interactions. 

Esteban


Cheers,
Doru



On Wed, May 6, 2015 at 2:58 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:


On Wed, May 6, 2015 at 11:50 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
honestly, right now I can “tolerate” not having it… probably in the future I will need it, but I’ll let you know. 
Right now, in fact, I would like to propose a fix for:

- toggle action in toolbars 
- selection visible actions in toolbars (the ones that appears also when right clicking, for example… I want some of them to be also visible in the toolbar, but enabled/disabled according necessity)

AFAIS, both are needed to achieve what I want on the tools I made: all important options should be always visible. 

will you accept a contribution in this sense? 

Definitely :)
Just one comment about selection visible actions in toolbars. Right now the purpose of the toolbar is to show actions that apply on the entire presentation.
Adding actions here that depend on the selection would complicate things. Still as long as those actions do not disappear, but get disabled it could work.


Cheers,
Andrei


 
Esteban

On 05 May 2015, at 22:13, Andrei Chis <chisvasileandrei@gmail.com> wrote:

There is no dedicated presentation for having an input text. 
Lists and tree presentations can have an input text at the bottom for filtering/searching.

The closest solution would be to maybe have a pane fixed width in a tabulator and them add a text area inside that pane.
It would look sort of like a text input, but I'm not sure how well it would work for you.

If the above doesn't work and you really need a text input we can add one :)

Cheers,
Andrei

On Tue, May 5, 2015 at 6:48 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Since GLMInputTextPresentation (or how it was called, I forget it) is gone, and actually was never there…
how can  I have the equivalent? I’m sure you had the problem in which you need some… how do you solve it?

Esteban