Glamour: how can I have an input text?

On 06 May 2015, at 15:05, Tudor Girba <[hidden email]> wrote:

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

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

Cheers,

Doru

On Wed, May 6, 2015 at 2:58 PM, Andrei Chis <[hidden email]> wrote:

On Wed, May 6, 2015 at 11:50 AM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 06 May 2015, at 16:18, Ben Coman <[hidden email]> wrote:

On Wed, May 6, 2015 at 9:17 PM, Esteban Lorenzano <[hidden email]> wrote:

On 06 May 2015, at 15:05, Tudor Girba <[hidden email]> 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 <[hidden email]> wrote:

On Wed, May 6, 2015 at 11:50 AM, Esteban Lorenzano <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev