Smalltalk › Pharo › Pharo Smalltalk Users

calypso modularity

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Peter Uhnak

calypso modularity

Hi,

how modular is Calypso in respect to:

* taking the UI apart and compositing it in a different manner

* reusing parts of it in a different place/application (e.g. just the code editor, or just the method list, ...)

* using alternative abstractions to just package/class/protocol/method

* e.g. instead of showing classes SomeSubject, SomeSubjectTest it would show "Some Subject" (a string returned by SomeSubject class>>myName) and clicking on it would show the combined methods from both the SomeSubject and SomeSubjectTest.

Also would such alternate usecases be considered a feature of Calypso (so it is intentional in building Calypso to use it in a different manner), or purely coincidental (as in, if it is possible, Calypso is built for different purpose and I cannot expect that some property will not disappear in the future).

Thanks a lot!

Peter

Stephane Ducasse-3

Re: calypso modularity

I would like to have calypso built on top of spec so that we can
rearrange some elements.
Denis is starting to check the missing element of spec.

Stef

On Sat, Jan 20, 2018 at 9:40 PM, Peter Uhnák <[hidden email]> wrote:

> Hi,
>
> how modular is Calypso in respect to:
>
> * taking the UI apart and compositing it in a different manner
> * reusing parts of it in a different place/application (e.g. just the code
> editor, or just the method list, ...)
> * using alternative abstractions to just package/class/protocol/method
> * e.g. instead of showing classes SomeSubject, SomeSubjectTest it would
> show "Some Subject" (a string returned by SomeSubject class>>myName) and
> clicking on it would show the combined methods from both the SomeSubject and
> SomeSubjectTest.
>
> Also would such alternate usecases be considered a feature of Calypso (so it
> is intentional in building Calypso to use it in a different manner), or
> purely coincidental (as in, if it is possible, Calypso is built for
> different purpose and I cannot expect that some property will not disappear
> in the future).
>
> Thanks a lot!
> Peter

Denis Kudriashov

Re: calypso modularity

In reply to this post by Peter Uhnak

Hi Peter.

Calypso is modular but maybe not in the parts which you need.

There are two core packages which are not related to the "Smalltalk navigation":

- navigation model based on first class queries.

- UI components for possible browsers

And I imagine how I would use them in particular business applications which I built in may career.

Now the only example is "Smalltalk navigation" which is packaged in multiple "SystemQueries" and "SystemTools" packages.

2018-01-20 21:40 GMT+01:00 Peter Uhnák <[hidden email]>:

Hi,

how modular is Calypso in respect to:

* taking the UI apart and compositing it in a different manner

Calypso is not a browser framework like Glamour. So the UI part is restricted by the required browsers controlfow in the abstract class ClyBrowser:

- top half of window is used to place navigation panes which should be defined by subclasses

- bottom half of window is used by tabs.

- and toolbar at the middle.

Tabs, toolbar items, context menu and shortcuts are all pluggable. They all extended by annotating required classes with context where they should be used.

So they are not hardcoded and reusable.

Navigation panes are defined as instances of ClyQueryView which is reusable widget to show result of any calypso query. It implements correct updating after system changes, maintains item selection and provide menus and shortcuts.

* reusing parts of it in a different place/application (e.g. just the code editor, or just the method list, ...)

It is in todo.

But now these tools are required to be in browser tabs, they know about tab. But I want to be able annotate arbitrary widget that it should be shown as browser tab.

* using alternative abstractions to just package/class/protocol/method
* e.g. instead of showing classes SomeSubject, SomeSubjectTest it would show "Some Subject" (a string returned by SomeSubject class>>myName) and clicking on it would show the combined methods from both the SomeSubject and SomeSubjectTest.

So as I said these panes are based on ClyQueryView. Whatever query you would pass it will show result items. Query can return mixed items. For example QueryBrowser shows together methods, classes and class comments. All menus and shortcuts are continue work with known types. And you can implement new commands for new items type.

Only questions is how inject special queries to the required panes. It is now hardcoded. And there is hardcoded logic how to handle selection changes.

For example FullBrowser knows that it should show methods for selected classes. It expects that class pane will provide classes and not something else.

But there is already system of browser plugins and we can delegate some logic to them. The question is what use cases we need.

For example to support optional trait methods visibility I will need to allow plugins decorate default scope for methods. Trait plugin will extends with inherited traits (when trait visibility is enabled by default).

In addition it could provide possibility to implement mixed instance side and class side mode.

Also would such alternate usecases be considered a feature of Calypso (so it is intentional in building Calypso to use it in a different manner), or purely coincidental (as in, if it is possible, Calypso is built for different purpose and I cannot expect that some property will not disappear in the future).

Yes. I think it is important to be able experiment.

Thanks a lot!
Peter