RFB server again

Hi Lukas,

sometime ago I asked which of the RFB/RemoteFrameBuffer versions should
be the one to go for. I choose yours
(http://source.lukar-renggli.ch/unsorted) because the one on squeak
source hasn't had commits (maybe because they were not necessary) but
more importantly, yours has been tailored to Pharo.

I want to make some modifications to the code to better support
configuration of preferences by scripts and not by GUI prompts (I am
working my script to install and configure all I want in a pharo core
image, something like Damien's work, but only with my code and its
dependencies). For this, I want to share the code. Should I upload to
your repo? It is open to upload (I'm almost sure it is)?

Wouldn't be better to copy the RFB code from your repo to the
Pharo/PharoInbox repo given that it will be used heavily with
pharo-web/pharo-dev and more related to pharo than to lukas (I don't
have anything against your repo, in fact it is full of good code, but I
think that the more projects for pharo are stored in the same place, the
better for the final user. Also, I foresee this version as the official
one for pharo, not a version with addons/modifications/hacks for lukas'
servers.

Now the technical:

In RFBServer class side:

shouldConserveMemory
        "Answer whether the server should try to conserve memory at all costs."
       
        ^true

always returns true. Why?

this is used in the initializePreferences (class side)

        self shouldConserveMemory
                ifTrue:
                        [ConserveMemory := true.
                         EnableDamageFilter := false.
                         EnableRawFilter := false]
                ifFalse:
                        [ConserveMemory := false.
                         EnableDamageFilter := true.
                         EnableRawFilter := true].

to set the class variables and it doesn't permit other behavior.
Shouldn't this be a preference method and when called, assing the
apropriate variables values?

I can't find users of initialize on RFBServer class side. Where it is
called? On loading by Monticello?

What is the difference between names initialise (on instance side) and
initialize (on class side). Is a typo?

I want to make and upload a new version with some modifications. After
review, do you agree to copy them to PharoInbox or do you prefer to have
it in your repo?

Cheers,
Miguel Cobá


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> sometime ago I asked which of the RFB/RemoteFrameBuffer versions should
> be the one to go for. I choose yours
> (http://source.lukar-renggli.ch/unsorted) because the one on squeak
> source hasn't had commits (maybe because they were not necessary) but
> more importantly, yours has been tailored to Pharo.

Yes, the one in my repository works with the new event system in
Pharo. It does not work in any other image though.

> I want to make some modifications to the code to better support
> configuration of preferences by scripts and not by GUI prompts (I am
> working my script to install and configure all I want in a pharo core
> image, something like Damien's work, but only with my code and its
> dependencies). For this, I want to share the code. Should I upload to
> your repo? It is open to upload (I'm almost sure it is)?

Sure, feel free to commit the code to my repository.

Actually I already patched out most of the annoying GUI prompts
myself. I use the code in many headless production images for years
already and start/stop the server with "RBFServer start: 2" /
"RBFServer stop".

> Wouldn't be better to copy the RFB code from your repo to the
> Pharo/PharoInbox repo given that it will be used heavily with
> pharo-web/pharo-dev and more related to pharo than to lukas (I don't
> have anything against your repo, in fact it is full of good code, but I
> think that the more projects for pharo are stored in the same place, the
> better for the final user. Also, I foresee this version as the official
> one for pharo, not a version with addons/modifications/hacks for lukas'
> servers.

Feel free to post it to a new repository if you want. I did not commit
my changes to the official repository because the repository is
read-only and because I changed many things that might not be to the
linkings of a wider audience.

> to set the class variables and it doesn't permit other behavior.
> Shouldn't this be a preference method and when called, assing the
> apropriate variables values?

I don't remember. Presumably I changed that because it was the only
reasonable setting.

> I can't find users of initialize on RFBServer class side. Where it is
> called? On loading by Monticello?

Yes, class-side initializers are called when the code is loaded.

> What is the difference between names initialise (on instance side) and
> initialize (on class side). Is a typo?

#initialize on instance-side is called when the object is instantiated
with #new.

> I want to make and upload a new version with some modifications. After
> review, do you agree to copy them to PharoInbox or do you prefer to have
> it in your repo?

I don't think this should go to the PharoInbox, this is not a
core-image package.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

El lun, 03-08-2009 a las 20:45 +0200, Lukas Renggli escribió:
Yes, but I want to add accessor to set/get the different preferences by
code and not by the menu.
This is what I want to add, so we can completly configure a RFB server
with a script in a workspace or as a initial script, for booting
core-images for production use (the aim of core-images as I remember).

Yes, but I mean the name, not the function. Instance side use
initiali"s"e and the class side use initiali"z"e, maybe it is just a
typo.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project