Omnibrowser in 1.4

Does anyone have OB working in 1.4?

Thanks.
Sean
(On an extended vacation in Edinburgh for most of the week thanks to hurricane Irene)

Oh forgot to mention, "(Smalltalk at: #ConfigurationOfOmniBrowser) project latestVersion load" from MetacelloRepository seemed maybe old, with references to Preferences, and errors after loading.

S

There are currently no plans to make OB work in upcoming Pharo
versions; Pharo 1.4 is supposed to have its own much better browser
framework.

On 28 August 2011 11:59, Sean P. DeNigris <[hidden email]> wrote:
> Oh forgot to mention, "(Smalltalk at: #ConfigurationOfOmniBrowser) project
> latestVersion load" from MetacelloRepository seemed maybe old, with
> references to Preferences, and errors after loading.

References to Preferences were removed from OB a long long time ago (>
1 year). Use the following script to  get the latest code (for Pharo
1.3 core images):
https://github.com/renggli/builder/blob/master/scripts/omnibrowser.st

Lukas

>
> S
>
> --
> View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3774181.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
>



--
Lukas Renggli
www.lukas-renggli.ch

Lukas Renggli wrote

There are currently no plans to make OB work in upcoming Pharo
versions; Pharo 1.4 is supposed to have its own much better browser
framework.

Until that happens, all development in Pharo 1.4 will be done without a refactoring browser?

On Aug 28, 2011, at 12:45 PM, Sean P. DeNigris wrote:

>
> Lukas Renggli wrote:
>>
>> There are currently no plans to make OB work in upcoming Pharo
>> versions; Pharo 1.4 is supposed to have its own much better browser
>> framework.

People can use OB if they want. Since we never maintained OB (only lukas and we are grateful for that)
we will just continue like that. We cannot take responsibility to maintain something we do not understand in addition to all the rest.

> Until that happens, all development in Pharo 1.4 will be done without a
> refactoring browser?

It was always like that in the past. Just that you use the image with the work of lukas loaded.
Now for 1.4 yes we are fedup to use the old browser without RB. So Benjamin started to write some
widgets for all the request question of RB engine so that Nautilus supports RB.

So you see we are improving the core image.

Stef

>
> --
> View this message in context: http://forum.world.st/Omnibrowser-in-1-4-tp3774180p3774231.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Stéphane Ducasse wrote

So you see we are improving the core image.

Okay, I got it. Thank you Lukas and Steph. Sounds good.

Sean

2011/8/28 Lukas Renggli <[hidden email]>:
> There are currently no plans to make OB work in upcoming Pharo
> versions; Pharo 1.4 is supposed to have its own much better browser
> framework.
>

Which framework?

I think Lukas means Nautilus.

On Sun, 28 Aug 2011, Lukas Renggli wrote:

> There are currently no plans to make OB work in upcoming Pharo
> versions; Pharo 1.4 is supposed to have its own much better browser
> framework.

What are the advantages compared to OB?


Levente

>> There are currently no plans to make OB work in upcoming Pharo
>> versions; Pharo 1.4 is supposed to have its own much better browser
>> framework.
>
> What are the advantages compared to OB?

I do not know. I will continue to use OB.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

Lukas Renggli wrote

I do not know. I will continue to use OB.

Lukas, if you get a version working in 1.4, will you let me know/release it?

Sean

Since there is ob, I personally use Nautilus. It provides interesting functionalities such as grouping packages and the hierarchies view (such as in vw). Importing things are missing however, including refactorings.

Alexandre



Le 29 août 2011 à 07:28, "Sean P. DeNigris" <[hidden email]> a écrit :

>> I do not know. I will continue to use OB.
>
> Lukas, if you get a version working in 1.4, will you let me know/release it?

It took several man-weeks to get everything running in Pharo 1.3 and
there are still quite a few of issues left. Next on my list is to
stabilize everything and to get some productive/fun things done.

There is no plan in moving things (RB, OB, eCompletion, ...) to Pharo
1.4 in the foreseeable future: All the groundbreaking changes to the
system (RPackage, System Announcements, Ring, Opal, RB, ...) will
require a lot of work and will likely also introduce new issues
(@stef: this is not a complaint, I just don't have the time to keep up
with it).

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

On 29 August 2011 13:54, Alexandre Bergel <[hidden email]> wrote:
> Since there is ob, I personally use Nautilus. It provides interesting functionalities
> such as grouping packages and the hierarchies view (such as in vw). Importing
> things are missing however, including refactorings.

Personally I wonder what the goal of Nautilus is?

Nautilus looks to me like yet another Smalltalk-80 browser that works
exactly the same as all previous Smalltalk browsers in the last 32
years (including OB). IMHO fixed lists, a text field and ugly buttons
do not cut it anymore. Did any Smalltalker ever work with XCode,
Eclipse, VisualStudio, ...?

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

On Aug 29, 2011, at 2:22 PM, Lukas Renggli wrote:

:)
We will pay attention to RB, eCompletion, Shout, AST.


>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>

Have a "basic" browser so that we can get rid of StringHolder.
No more for me.

Stef

>> Nautilus looks to me like yet another Smalltalk-80 browser that works
>> exactly the same as all previous Smalltalk browsers in the last 32
>> years (including OB). IMHO fixed lists, a text field and ugly buttons
>> do not cut it anymore. Did any Smalltalker ever work with XCode,
>> Eclipse, VisualStudio, ...?
>
> Have a "basic" browser so that we can get rid of StringHolder.

You could push down all the code of StringHolder into the subclass(es)
and remove the empty class. This can be done with RB with a few
clicks.

> No more for me.

Introducing more code into Pharo that depends on more parts of Pharo
(RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it
easier to maintain and change Pharo. Or did I misunderstand something
about cohesion and coupling? :-)

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

On Mon, Aug 29, 2011 at 6:35 PM, Lukas Renggli <[hidden email]> wrote:
> Or did I misunderstand something
> about cohesion and coupling? :-)

you certainly got a bad teacher ;-)

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

On Aug 29, 2011, at 6:35 PM, Lukas Renggli wrote:

With that philosophy, we can just declare Pharo as finished and do something
else.

My point of view is that I invent new abstractions *and than use them* on and
for the system itself.

        Marcus


--
Marcus Denker -- http://marcusdenker.de

On Aug 29, 2011, at 6:35 PM, Lukas Renggli wrote:

I want to remove all the code of the hierarchy

>> No more for me.
>
> Introducing more code into Pharo that depends on more parts of Pharo
> (RPackage, Announcement, Pragma, Ring, RB, Shout, ...) doesn't make it
> easier to maintain and change Pharo. Or did I misunderstand something
> about cohesion and coupling? :-)

Why do you say that
Ring = replacement for MethodComment, MethodReference, PseudoClass, PseudoMethod, .....
Pragma is compiler stuff
Shout should be pluggable
Announcement = replacement for SystemChangeNotifier
RPackage = replacement for PackageInfo

So I do not see the problem of coupling.

>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>