Administrator
|
"A moldable presentation consists of a set of basic presentations selected according to the current development context... Currently defining a development context and filtering presentations based on it is not supported" [1]
Is there a timeline for this feature? [1]. http://scg.unibe.ch/archive/papers/Chis14a-MoldableInspector.pdf
Cheers,
Sean |
Hi Sean, Depending on what you understand by development context and selecting presentations based on the development context there is already a solution in the image that can filter presentations based on annotations and method signatures. GTInspector can be customized with a presentationFilter. This is an instance of GTInspectorPresentationFilter, and it is used by the inspector to filter views. For examples you can look on the class side of GTInspectorMethodListFilter and GTInspectorTagFilter. (Spotter also has similar support for filtering available searches.) This is described more in Section 3 in [1]. For changing dynamically the tags (annotations) that are in the context you can use the 'Filter presentations' option from the window menu of the inspector window. The previous two filters are just two possible examples. Another possibility could be to automatically infer the context, but that's a bit more tricky. For that there isn't any timeline. However, we are slowly adding support for recording user actions in all GTools + ways to adapt the tools based on those actions. Does this answer your question or you had something else in mind? Cheers, Andrei On Sun, Aug 16, 2015 at 1:41 AM, Sean P. DeNigris <[hidden email]> wrote: "A moldable presentation consists of a set of basic presentations selected _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Administrator
|
This seems interesting, but how does one hook one's tags into this menu? For example, I expected my `<gtInspectorTag: #myCoolTag>` to appear in the window menu along with the usual tags, but when it didn't I noticed that GTInspector>>#initialize seems to hard-code which tags are available. Also, since multiple tags can be associated to the same view, why: <gtInspectorTag: #myCoolTag1> <gtInspectorTag: #myCoolTag2> <gtInspectorTag: #myCoolTag3> instead of: <gtInspectorTags: #(myCoolTag1 myCoolTag2 myCoolTag3)> ?
Cheers,
Sean |
Administrator
|
While we're on the API. I'm assuming that #when: blocks are the implementation of the "activation predicates" mentioned in the paper. Is that right? Two feature requests have been brewing as I've used GT intensively. They both have to do with crystalizing a workflow found in the Inspector: - Lock Panes - say I have a list of e.g. Morphs in pane 1, which propagates to the Morph presentation in pane 2, and the Raw presentation in pane 3. It would be great if one could indicate that changing the selection in pane 1 should not remove all panes to the right but preserve the current layout; bonus points if it realized that pane 2 and 3 were showing the same object and updated them jointly - Create Glamour Browser from Inspector Session - a more permanent version of the above. Take the current session and reify it into a dedicated tool. This is fun :)
Cheers,
Sean |
In reply to this post by Sean P. DeNigris
On Sun, Aug 16, 2015 at 7:10 PM, Sean P. DeNigris <[hidden email]> wrote: Andrei Chis wrote Yes, GTInspector>>#initialize hardcodes the available tags. Currently we did not use this feature much so it can still be improved. Still a general mechanism for discovering tags could slow down the inspector a bit. Maybe specifying the tags in class side methods could be an option?
We didn't really had this use case :) Until now we only added two tags to a presentation. Could be easily added. Cheers, Andrei
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Sean P. DeNigris
On Sun, Aug 16, 2015 at 7:59 PM, Sean P. DeNigris <[hidden email]> wrote: Sean P. DeNigris wrote Yes, it's a more fancy name for the #when: block.
This is something that we really want but, more or less, due to Glamour we didn't really got to implementing it. A general solution for saving the navigation in a glamour browser is a bit tricky. Now the long term plan is to rewrite the inspector on top of Bric. This should make saving the navigation workflow easier. Or at least we'll incorporate this feature from the start. Now if you want to dig into Glamour and see if we can't get at least some of these feature to work I can help. Though we do not really want to invest too much effort now into Glamour :)
:) Cheers, Andrei
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Administrator
|
Cool, I'm doing some experiments to integrate the presentations with Glamour proper. I'll clean them up and we can discuss.
Cheers,
Sean |
Administrator
|
In reply to this post by Andrei Chis
IIUC, by the time you would be dealing with the filter menu, GTInspector>>#gtInspectorPresentationsIn:inContext: has already enumerated the presentations to determine whether they should be shown. Can't we build the tag list almost for free here?
Cheers,
Sean |
On Mon, Aug 17, 2015 at 1:00 AM, Sean P. DeNigris <[hidden email]> wrote: Andrei Chis wrote Yes, this could work. We could keep both solutions. The tags set in the initialize method would always be shown. Any other tags that are discovered when loading presentations are added to the context but not selected. Can you start the implementation of this feature? Cheers, Andrei
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Administrator
|
In reply to this post by Sean P. DeNigris
The first hacked-in iteration, simply embedding GT presentations in the panes of a Glamour browser is: exampleBrowser | projects browser | projects := self uniqueInstance. browser := GLMTabulator new. browser column: #one; column: #two; column: #three. (browser transmit) to: #one; andShow: [ :a :b | b descriptionActiveProjects gtPresentation value: a value: nil value: b ]. (browser transmit) to: #two; from: #one; andShow: [ :a :b | b gtInspectorMagritteIn: a ]. (browser transmit) to: #three; from: #one; andShow: [ :a :b | b descriptionLinks gtPresentation value: a value: nil value: b ]. browser openOn: projects. All we need is a little glue where the blocks are and we're in business! But already quite useful...
Cheers,
Sean |
Administrator
|
Issue #1131: Glue between GT and Glamour https://github.com/moosetechnology/Moose/issues/1131
Cheers,
Sean |
Free forum by Nabble | Edit this page |