customizing menus for moose entities in moose finder

List overview All Threads
Download

newer

older

glamour placing last character on...

Mondrian new method...

Usman Bhatti

8 May 2012 8 May '12

2:25 p.m.

Hi, As discussed, I am working on the idea how to customize menus for entities in Moose Finder. As the menu construction depends on the pragmas defined on moose entity hierarchy, the idea is to read pragmas in some specific way. We tried something with Stéphane yesterday and here I am sending you the change set. Can you please have a look? The change set does not complete resolve the problem :-). The problem is that menus are duplicated and changes are still invasive (that is the code overrides the default moose finder behavior). But this can be a possible approach to resolve it. tx Usman

Attachments:

attachment.htm (text/html — 1.1 KB)
HookForMoose.1.cs (application/octet-stream — 3.2 KB)

Show replies by date

Tudor Girba

8 May 8 May

3:03 p.m.

Hi, I took a quick look, and I think this is the wrong way to approach the problem. The default Moose menu relies on a lightweight implementation that is useful for just that: being a default menu. If you are adding multiple layers to this mechanism it will become too complex. If you want to go into customization, than the way to go is to reify each action as an object and then assembly the menu by putting those objects together in the menu logic. Basically, you would need to implement a command hierarchy (like the hierarchy of MoosePanelCommand). Cheers, Doru On Tue, May 8, 2012 at 2:25 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:

...

-- www.tudorgirba.com "Every thing has its own flow"

Stéphane Ducasse

8:28 p.m.

On May 8, 2012, at 3:03 PM, Tudor Girba wrote:

...

But how can we get rid of the default behavior? Stef

...

Cheers, Doru On Tue, May 8, 2012 at 2:25 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:

Stéphane Ducasse

8:30 p.m.

Doru I do not understand why having some hooks methods are the wrong way. To me having a method without hooks in the top of the hierarchy is not so good. And this is cheap to get a couple of hooks when they can already solve part of the problem. So now I got it we will build our own solution and nuke the default one of Moose. Stef

...

Tudor Girba

10:42 p.m.

Hi, Maybe I did not understand the change set, so let me tell you what I see: each class specifies the superclass from which to start building the menu. For example, in your implementation, MooseEntity says that the menu is built starting from the MooseEntity downwards. This might be Ok for your context, but it breaks the original requirement for this menu: to provide a quick way to get to the default menu (including Inspect which is quite important during prototyping) for any object from a script like Mondrian or Glamour. This is why I do not see it working right now. I believe that what you want is more of an object-specific menu, or even better a browser specific one. Am I wrong? Cheers, Doru On 8 May 2012, at 20:30, Stéphane Ducasse wrote:

...

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Usman Bhatti

9:53 p.m.

On Tue, May 8, 2012 at 3:03 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:

...

I agree that adapting the current system for customization will make it more complex and difficult to manage.

...

If you want to go into customization, than the way to go is to reify each action as an object and then assembly the menu by putting those objects together in the menu logic. Basically, you would need to implement a command hierarchy (like the hierarchy of MoosePanelCommand).

So, you mean we need to create a default object for menu construction and customization are done by subclassing the default object? Usman So meaning that

...

Cheers, Doru On Tue, May 8, 2012 at 2:25 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:

Hi, As discussed, I am working on the idea how to customize menus for

entities

in Moose Finder. As the menu construction depends on the pragmas defined

moose entity hierarchy, the idea is to read pragmas in some specific

way. We

tried something with Stéphane yesterday and here I am sending you the

change

set. Can you please have a look? The change set does not complete resolve the problem :-). The problem is that menus are duplicated and changes are still invasive (that is the

code

overrides the default moose finder behavior). But this can be a possible approach to resolve it. tx Usman _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

10:47 p.m.

Hi Usman, Could we start from your actual requirement? As I understood, you would just want to have a subclass of MooseModel, and then have a MoosePanel that has a special menu for this entity. Is that so? If yes, the simplest way would be to define a YourPanel and build the menu you want there. Would this not work? Cheers, Doru On 8 May 2012, at 21:53, Usman Bhatti wrote:

...

On Tue, May 8, 2012 at 3:03 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: Hi, I took a quick look, and I think this is the wrong way to approach the problem. The default Moose menu relies on a lightweight implementation that is useful for just that: being a default menu. If you are adding multiple layers to this mechanism it will become too complex. I agree that adapting the current system for customization will make it more complex and difficult to manage. If you want to go into customization, than the way to go is to reify each action as an object and then assembly the menu by putting those objects together in the menu logic. Basically, you would need to implement a command hierarchy (like the hierarchy of MoosePanelCommand). So, you mean we need to create a default object for menu construction and customization are done by subclassing the default object? Usman So meaning that Cheers, Doru On Tue, May 8, 2012 at 2:25 PM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:

-- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Presenting is storytelling."

Usman Bhatti

9 May 9 May

11:02 a.m.

On Tue, May 8, 2012 at 10:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:

...

This is just one requirement and it was not difficult to resolve and its done away with. The problem is occurring from the requirement that I need to build customized menus for entities in the model (FAMIXClass, FAMIXMethod, etc.) in my browser: I want to eliminate some menus (inspect, evaluate, etc.) for my entities. Now, the menus are defined in MooseEntity hierarchy so even if I am creating a different browser/finder, my patch blocks the menus for all browser and not just mine. So, the change set provides a way to resolve this problem, though not completely :-). hence the question: how to resolve the problem of customized menus for moose entities without impacting other browsers and without making the solution complicated? we can talk about it if you want. Usman

...

If yes, the simplest way would be to define a YourPanel and build the menu you want there. Would this not work? Cheers, Doru On 8 May 2012, at 21:53, Usman Bhatti wrote:

On Tue, May 8, 2012 at 3:03 PM, Tudor Girba <tudor(a)tudorgirba.com>

wrote:

more complex and difficult to manage.

and customization are done by subclassing the default object?

Usman So meaning that Cheers, Doru On Tue, May 8, 2012 at 2:25 PM, Usman Bhatti <usman.bhatti(a)gmail.com>

wrote:

> Hi, > > > As discussed, I am working on the idea how to customize menus for

entities

> in Moose Finder. As the menu construction depends on the pragmas

defined on

> moose entity hierarchy, the idea is to read pragmas in some specific

way. We

> tried something with Stéphane yesterday and here I am sending you the

change

> set. Can you please have a look? > > > The change set does not complete resolve the problem :-). The problem

> that menus are duplicated and changes are still invasive (that is the

code

> overrides the default moose finder behavior). But this can be a

possible

approach to resolve it. tx Usman _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Presenting is storytelling." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

11:23 a.m.

Hi Usman, Ok, so what you want is definitely not a class based specification of the menu (as I see it now in your proposed changes), but a browser-specific one. So, in this case, why is it not enough to just build the menu manually? Here is an example: t := GLMTabulator new. t column: #one. t transmit to: #one; andShow: [:a | a list display: [:model | model allClasses ]; selectionAct: [:list | list selection viewBlueprint ] entitled: 'Blueprint' ] t openOn: MooseModel root allModels anyOne Another option would be to just create your own polymorphic method for MooseEntities that provides your desired set actions. So, instead of using the default mooseFinderActions, you would use your own like this: yourOwnActions ... ^ aCollectionOfGlamourActions And then in the browser: a list ... dynamicActionsOnSelection: [ :list | list selection yourOwnActions ] Would that not be enough? Cheers, Doru On Wed, May 9, 2012 at 11:02 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:

...

On Tue, May 8, 2012 at 10:47 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:

If yes, the simplest way would be to define a YourPanel and build the menu you want there. Would this not work? Cheers, Doru On 8 May 2012, at 21:53, Usman Bhatti wrote:

-- www.tudorgirba.com "Presenting is storytelling." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Every thing has its own flow"

Usman Bhatti

11:38 a.m.

On Wed, May 9, 2012 at 11:23 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:

...

That's perfect because I want to reuse some existing menus... That's resolves my problem. thanx a lot. Usman

...

Cheers, Doru On Wed, May 9, 2012 at 11:02 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:

On Tue, May 8, 2012 at 10:47 PM, Tudor Girba <tudor(a)tudorgirba.com>

wrote:

> > Hi Usman, > > Could we start from your actual requirement? > > As I understood, you would just want to have a subclass of MooseModel,

and

> then have a MoosePanel that has a special menu for this entity. Is that

so?

etc.)

in my browser: I want to eliminate some menus (inspect, evaluate, etc.)

for

my entities. Now, the menus are defined in MooseEntity hierarchy so even if I am

creating

a different browser/finder, my patch blocks the menus for all browser and not just mine. So, the change set provides a way to resolve this problem, though not completely :-). hence the question: how to resolve the problem of customized menus for

moose

entities without impacting other browsers and without making the solution complicated? we can talk about it if you want. Usman > > If yes, the simplest way would be to define a YourPanel and build the

> you want there. Would this not work? > > Cheers, > Doru > > > On 8 May 2012, at 21:53, Usman Bhatti wrote: > > > > > > > On Tue, May 8, 2012 at 3:03 PM, Tudor Girba <tudor(a)tudorgirba.com> > > wrote: > > Hi, > > > > I took a quick look, and I think this is the wrong way to approach the > > problem. The default Moose menu relies on a lightweight implementation > > that is useful for just that: being a default menu. If you are adding > > multiple layers to this mechanism it will become too complex. > > > > I agree that adapting the current system for customization will make

> > more complex and difficult to manage. > > > > > > If you want to go into customization, than the way to go is to reify > > each action as an object and then assembly the menu by putting those > > objects together in the menu logic. Basically, you would need to > > implement a command hierarchy (like the hierarchy of > > MoosePanelCommand). > > > > So, you mean we need to create a default object for menu construction > > and customization are done by subclassing the default object? > > > > Usman > > > > > > So meaning that > > > > > > Cheers, > > Doru > > > > > > On Tue, May 8, 2012 at 2:25 PM, Usman Bhatti <usman.bhatti(a)gmail.com> > > wrote: > > > Hi, > > > > > > > > > As discussed, I am working on the idea how to customize menus for > > > entities > > > in Moose Finder. As the menu construction depends on the pragmas > > > defined on > > > moose entity hierarchy, the idea is to read pragmas in some specific > > > way. We > > > tried something with Stéphane yesterday and here I am sending you

the

> > > change > > > set. Can you please have a look? > > > > > > > > > The change set does not complete resolve the problem :-). The

problem

> > > is > > > that menus are duplicated and changes are still invasive (that is

the

> code > overrides the default moose finder behavior). But this can be a > possible > approach to resolve it. > > > tx > > Usman > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Presenting is storytelling." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Usman Bhatti

12:32 p.m.

On Wed, May 9, 2012 at 11:38 AM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote;wrote:

...

On Wed, May 9, 2012 at 11:23 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:

That's perfect because I want to reuse some existing menus... That's resolves my problem.

Not all :-) For example, this method in MooseEntity does not allow me to polymorphically invoke my own actions. My browser is collecting this method because of the pragma moosePresentationOrder: and the default mooseFinderActions gets executed again populating undesirable menus. I want to use the method to keep the finder-type navigation. Any idea of a neat solution to this problem? mooseFinderNavigationIn: composite <moosePresentationOrder: 1> composite list title: 'Navigation'; titleIcon: MooseIcons mooseNavigation; updateOn: MooseEntityAdded from: [ :anObject | anObject announcer ]; updateOn: MooseEntityRemoved from: [ :anObject | anObject announcer ]; display: [ :anObject | |entity col| entity := anObject mooseInterestingEntity. entity propertiesToDisplay: entity complexPropertySelectors ]; icon: [:each | each mooseInterestingEntity mooseIcon]; format: #mooseDisplayString; " when: [:input | input mooseInterestingEntity isCollection not or: [ input mooseInterestingEntity isKindOf: MooseModel] ]; " dynamicActionsOnSelection: [ :list | list selection mooseInterestingEntity *mooseFinderActions* ]

...

thanx a lot. Usman

Cheers, Doru On Wed, May 9, 2012 at 11:02 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote:

On Tue, May 8, 2012 at 10:47 PM, Tudor Girba <tudor(a)tudorgirba.com>

wrote:

> > Hi Usman, > > Could we start from your actual requirement? > > As I understood, you would just want to have a subclass of MooseModel,

and

> then have a MoosePanel that has a special menu for this entity. Is

that so?

etc.)

in my browser: I want to eliminate some menus (inspect, evaluate, etc.)

for

my entities. Now, the menus are defined in MooseEntity hierarchy so even if I am

creating

a different browser/finder, my patch blocks the menus for all browser

and

not just mine. So, the change set provides a way to resolve this

problem,

though not completely :-). hence the question: how to resolve the problem of customized menus for

moose

entities without impacting other browsers and without making the

solution

complicated? we can talk about it if you want. Usman > > If yes, the simplest way would be to define a YourPanel and build the

the

> > problem. The default Moose menu relies on a lightweight

implementation

> > that is useful for just that: being a default menu. If you are adding > > multiple layers to this mechanism it will become too complex. > > > > I agree that adapting the current system for customization will make

> more complex and difficult to manage. > > > If you want to go into customization, than the way to go is to reify > each action as an object and then assembly the menu by putting those > objects together in the menu logic. Basically, you would need to > implement a command hierarchy (like the hierarchy of > MoosePanelCommand). > > So, you mean we need to create a default object for menu construction > and customization are done by subclassing the default object? > > Usman > > > So meaning that > > > Cheers, > Doru > > > On Tue, May 8, 2012 at 2:25 PM, Usman Bhatti <usman.bhatti(a)gmail.com

> > wrote: > > > Hi, > > > > > > > > > As discussed, I am working on the idea how to customize menus for > > > entities > > > in Moose Finder. As the menu construction depends on the pragmas > > > defined on > > > moose entity hierarchy, the idea is to read pragmas in some

specific

> > > way. We > > > tried something with Stéphane yesterday and here I am sending you

the

> > > change > > > set. Can you please have a look? > > > > > > > > > The change set does not complete resolve the problem :-). The

problem

> > > is > > > that menus are duplicated and changes are still invasive (that is

the

> > code > > overrides the default moose finder behavior). But this can be a > > possible > > approach to resolve it. > > > > > > tx > > > > Usman > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Presenting is storytelling." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

6:34 p.m.

Yes this is what should be done, still I think that providing some hooks would be good.

...

Another option would be to just create your own polymorphic method for MooseEntities that provides your desired set actions. So, instead of using the default mooseFinderActions, you would use your own like this: yourOwnActions ... ^ aCollectionOfGlamourActions And then in the browser: a list ... dynamicActionsOnSelection: [ :list | list selection yourOwnActions ] Would that not be enough?

Stef

4370

days inactive

4371

days old

moose-dev@list.inf.unibe.ch

Manage subscription

11 comments

3 participants

tags (0)

participants (3)

Stéphane Ducasse
Tudor Girba
Usman Bhatti