A question
stephane ducasse
lukas told me that after our "great discussion" you were envisioning
to have tree support in OB.
Is it correct (which I hope)?
If this is the case I would like to have that in the chapter we wrote
on OB.
Stef
stephane ducasse
Begin forwarded message:
Colin Putney
Yes, I do plan to support tree widgets in OmniBrowser 2.1. Here's my
list of possible features:
- tree widgets
- multiple selection
- inclusion of OB-Tools (debugger, inspectors)
- file browser and dialogs
- workspace
- some sort of tabbed UI for different views of the same node
Any other ideas?
Colin
Damien Cassou
> Yes, I do plan to support tree widgets in OmniBrowser 2.1. Here's my
> list of possible features:
>
> - tree widgets
> - multiple selection
> - inclusion of OB-Tools (debugger, inspectors)
> - file browser and dialogs
> - workspace
> - some sort of tabbed UI for different views of the same node
>
> Any other ideas?
These would be cool for a 2.1 version already. No need to change the
world immediately :-).
--
Damien Cassou
http://damiencassou.seasidehosting.st
"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry
stephane ducasse
>
> Yes, I do plan to support tree widgets in OmniBrowser 2.1. Here's my
> list of possible features:
>
> - tree widgets
****Excellent*****!!!!!!!!
For me the tree is the most important one with the multiple selection.
It opens a lot of new spaces. Multiselection is a plus.
Now what is important is that we could have the distinction between a
Now I know that for certain propotyping in glamour
the default morphic tree was clearly limited, so doru used the beta
version
of a new tree from alain plantec published in Momo (squeaksource).
I'm not precise enough on it but the problem is be able to disinguish
how to obtain
from a root children and from children subchildren.
I would really suggest that you talk with doru about that and also
about the fact that
passing around symbol (instead of symbol and block) would avoid to
force the
developper to create classes.
Lukas Renggli
> list of possible features:
Wow, that sounds like christmas :-)
> - tree widgets
> - multiple selection
> - some sort of tabbed UI for different views of the same node
I would prefer if you focused on the infrastructure.
> - inclusion of OB-Tools (debugger, inspectors)
I feel bad that there are not tests in OB-Tools. I could certainly improve that.
If you have other tasks please post them here, so that we can help to
test, implement and build new browser.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
Lukas Renggli
> about the fact that
> passing around symbol (instead of symbol and block) would avoid to
> force the
> developper to create classes.
I don't exactly understand. The architecture of OB however builds
around the idea of having lots of classes to facilitate reusability,
adaptability and extensibility. I would not like to see that changed.
For me the OB project was an eye-opener in that regard.
stephane ducasse
On Sep 24, 2009, at 11:04 AM, Lukas Renggli wrote:
>
>> I would really suggest that you talk with doru about that and also
>> about the fact that
>> passing around symbol (instead of symbol and block) would avoid to
>> force the
>> developper to create classes.
>
> I don't exactly understand. The architecture of OB however builds
> around the idea of having lots of classes to facilitate reusability,
> adaptability and extensibility. I would not like to see that changed.
> For me the OB project was an eye-opener in that regard.
>
You should talk with doru because by email this is a pain.
But using block when necessary is also a good alternative to symbol
since they may force to
create extra classes that wrap others....
Lukas Renggli
>> around the idea of having lots of classes to facilitate reusability,
>> adaptability and extensibility. I would not like to see that changed.
>> For me the OB project was an eye-opener in that regard.
> You should talk with doru because by email this is a pain.
> But using block when necessary is also a good alternative to symbol
> since they may force to
> create extra classes that wrap others....
Doru and I had that discussion before several times already.
Using symbols and blocks is nice for something like Glamour or
Mondrian, but it absolutely doesn't fit the architecture of
OB/Magritte/Seaside/Pier/... ;-)
stephane ducasse
> Doru and I had that discussion before several times already.
>
> Using symbols and blocks is nice for something like Glamour or
> Mondrian, but it absolutely doesn't fit the architecture of
> OB/Magritte/Seaside/Pier/... ;-)
I was more thinking about the Morphic layer than OB layer/
because you do not want to have a subclass or wrap the presentation
layer.
stef
Colin Putney
Can you explain this a bit more? I don't understand what you are
talking about.
FWIW, I agree with Lukas on the architecture of OB. I'd even like to
get away from using pluggable morphs and have simpler morphs that
communicate with their models using a well-defined protocol. But that
would mean writing those Morphs from scratch, and sharing less code
with other graphical tools. Not worth it.
Colin
stephane ducasse
>
> Can you explain this a bit more? I don't understand what you are
> talking about.
>
> FWIW, I agree with Lukas on the architecture of OB. I'd even like to
> get away from using pluggable morphs and have simpler morphs that
> communicate with their models using a well-defined protocol. But that
> would mean writing those Morphs from scratch, and sharing less code
> with other graphical tools. Not worth it.
ok I will try and may be doru will complement it.
When you have morph class that rely on using symbol that are performed
to do something, you end up as a user to have to wrap them to be able to
get another behavior if what you need is slightly different but not
implemented
by default in the class.
What doru was proposing in pharo was that we overload symbol with value
so that everything you pass a symbol you could have a block
this way you avoid the class wrapping and class proliferation for just
simple case.
It looks like morphic did not use blocks well enough may be because
block were
not closure.
So this point is not related to OB design but to Morphic design.
Of course, when you have a OBcommand object it is better than a block
if you have to attach to it real state and behavior. This was not my
point.
My point was on the overall impact of the design of Morphic classes.
May it would time to think about them and slowly change that.
Stef