f



Yes, yes nanny me. Spank me, spank me, oooh.

I think everyone has run into the "feature" where you're extending
some kind of core Smalltalk class and as soon as you accept the method
you're writing, it turns grey and you're unable to edit it. This is of
course because it's not in the package you've designated as working on
so it's not "available" for writing. Better yet, the method you just
created is **not available for repackaging**. When this "feature"
first comes up for the new user, it's a rude and horrific awakenening
since obviously Dolphin SEEMS broken. Even after you learn what's
going on ....

Well, it's not like you can keep both of the packages open
simultaneously since the Package Categories (top-left-most in the
system browser) TREE pane doesn't allow you to select multiple
branches simultaneously. So whenever the issue comes up you're forced
to switch packages to the core Smalltalk package just so you can
repackage your loose method, then you have to go back to YOUR package
just so you can continue editing the method. All told, about a dozen
mouse clicks. That you may have to repeat every 5 minutes. I'm looking
at creating a dozen small methods in the next 5 minutes so this
nannying crap doesn't make me happy.

Alternatively, in order to avoid this totalitarian infantilism we have
the helpful "set as default package" feature. (Features to avoid other
nannying features. Does this stink of diaper shit yet?) I don't know
about other people's work habits but I currently am extending core
Smalltalk classes from two different packages. One package has my
domain objects which extend SmallInteger, the other package has
testing stuff which naturally enough extends TestCase. Am I making
myself clear here? I DO NOT HAVE A DEFAULT PACKAGE.

The best part is that I have two OTHER packages which I'm going to be
switching back and forth to in order to avoid burning out or stalling,
so the whole default package idea is a ridiculous non-starter. And of
course, the moment you start designating a default package, you can
never STOP. You're stuck with that useless timewasting crap for ever
and ever.

Dolphin seems to have been infected with the unfortunate Windows
philosophy which says the user is an infant.

Short of getting rid of the checks entirely (no checks isn't as bad as
bad checks, there's a reason I'm writing in Smalltalk and not C++), my
proposed solution is:

1) allow ANY method to be repackaged at ANY time. Don't make it a
goddamned catch-22. Get rid of this Kafkaesque shit, please.

2) allow a method to be created *no matter what* even if it was done
from a grey pane. or more likely, a yellow pane that later turns out
to be grey for some incomprehensibly obscure reason.

3) provide an 'Unset default package' method near 'Set as default
package'
0
11/27/2009 6:58:29 PM
comp.lang.smalltalk.dolphin 3769 articles. 0 followers. Post Follow

8 Replies
453 Views

Similar Articles

[PageSpeed] 48

Hi,

I have been using Dolphin for ten years and i do not have the problems
you are having.

Can you put some code example or test ?

May you can use a Class Browser instead of System Browser.

> 3) provide an 'Unset default package' method near 'Set as default
package'

* You can "Unset default package" by selecting it again.
* You can drag&drop Methods into Packages.

We can help you, but you should post some code or test.

Regards,
Bruno
0
Bruno
11/27/2009 7:39:04 PM
On Nov 27, 2:39=A0pm, Bruno Buzzi Brasesco <bruno.brase...@gmail.com>
wrote:
> Hi,
>
> I have been using Dolphin for ten years and i do not have the problems
> you are having.

Yeah, I've noticed that other people forget problems they've had after
working around them instead of bitching about them. Maybe they're not
self-righteous enough about their anger to nurse grudges?

> Can you put some code example or test ?

Sorry but this is all interactive you know. I don't even know under
exactly what conditions the fault occurs. I DO know that if you create
methods of MyPackage in, say, Number using a SystemBrowser and then
you keep editing / creating new methods in Number while having
MyPackage selected all the while .... sooner or later you're gonna run
into this fault.

I suspect there's some kind of interaction so that the fault only
shows up if you move away from the methods you're editing - to other
methods of Number or to another class in that hierarchy. Unless it's
even weirder than that and there's an interaction between multiple
browsers and/or IdeaSpaces.

Unfortunately I'm not going to be able to narrow down the conditions
of the fault since ...

> May you can use a Class Browser instead of System Browser.

That's what I ended up doing by accident and I found out the problem
doesn't occur.

> > 3) provide an 'Unset default package' method near 'Set as default
>
> package'
>
> * You can "Unset default package" by selecting it again.

Very useful to know, thank you. Of course, it is STILL a failure that
this is non-obvious.

> * You can drag&drop Methods into Packages.

That makes it half shorter than having to select the other package and
back, but still longer than right-clicking and selecting Package from
the context menu then OK from the dialog. In any case, the latter is
something you SHOULD be able to do.

> We can help you, but you should post some code or test.

I wish I could.

I really wish I could post some code or at least a procedure that
reproduces the "accept button is greyed out despite the method you're
trying to accept being in a yellow pane because it's really SUPPOSED
to be a grey pane" fault. That one is particularly head-scratching and
hairy until you start to develop a mental model of how Dolphin's IDE
fails to work instead of worrying about writing your code.

Thanks for your reply,

Richard
0
Richard
11/27/2009 9:06:05 PM
Hi Richard,

> I think everyone has run into the "feature" where you're extending
> some kind of core Smalltalk class and as soon as you accept the method
> you're writing, it turns grey and you're unable to edit it.

I can't recall ever running into this.  If I create a new method or edit
an existing method, then save it, it is still available for editing.  It
is not gray.

> <snip> Better yet, the method you just
> created is **not available for repackaging**.

Again, I've never run into this.  Also, a search through this
newsgroup's archives shows no reference to that phrase.

You didn't mention which version of Dolphin you are using.  That info
might help us here help you there.

> Well, it's not like you can keep both of the packages open
> simultaneously.

You absolutely can keep both packages open at once.  It sounds like most
of your problems throughout your post are happening because you are
trying to do everything in one browser.  Just use two browsers.  Edit
your method in one browser and then drag and drop it on your package in
the other browser.  There are also other ways to repackage loose
methods, but this may be the easiest.

A Smalltalk developer (using any Smalltalk software) will typically have
many windows open at one time.

> 1) allow ANY method to be repackaged at ANY time.

As mentioned above, this is already available.

> 2) allow a method to be created *no matter what* even if it was done
> from a grey pane. or more likely, a yellow pane that later turns out
> to be grey for some incomprehensibly obscure reason.

As mentioned above, I've never seen this.  It might be I don't fully
understand what you are experiencing.

> 3) provide an 'Unset default package' method near 'Set as default
> package'

As Bruno said, this is a toggle menu option.  If you set a default
package and go back into the menu, you will see it is checked.  Click it
again to unset the default package.

Andy might have more insight into what you are describing, but this is
my take on it.  Hope this helps.

-- Louis

P.S.  You don't deserve a spanking, you naughty boy.  You will have to
wait for your birthday for that :)

0
Louis
11/28/2009 7:31:14 AM
Richard,

Hello again.

> I think everyone has run into the "feature" where you're extending
> some kind of core Smalltalk class and as soon as you accept the method
> you're writing, it turns grey and you're unable to edit it. This is of
> course because it's not in the package you've designated as working on
> so it's not "available" for writing. Better yet, the method you just
> created is **not available for repackaging**. When this "feature"
> first comes up for the new user, it's a rude and horrific awakenening
> since obviously Dolphin SEEMS broken. Even after you learn what's
> going on ....

As you've noted, this is caused by having a Default Package set when you 
compile a new method from a System Browser set to a different package. 
The Default Package mode was really intended for use in DCE where one 
doesn't have a System Browser. I, and I guess most others who haven't 
seen this problem, don't tend to use it in DPRO.

The fact that the method has been placed in another package than the one 
you currently have selected in the SB means that it should appear 
read-only and that includes not being available for repackaging.

Please don't accuse me of being defensive here.. it's how it was meant 
to work.

A possibility might be to make the Default Package setting be ignored 
when one is working in the SB? Would you like that recorded as a 
possible enhancement?

> Well, it's not like you can keep both of the packages open
> simultaneously since the Package Categories (top-left-most in the
> system browser) TREE pane doesn't allow you to select multiple
> branches simultaneously. So whenever the issue comes up you're forced
> to switch packages to the core Smalltalk package just so you can
> repackage your loose method, then you have to go back to YOUR package
> just so you can continue editing the method. All told, about a dozen
> mouse clicks. That you may have to repeat every 5 minutes. I'm looking
> at creating a dozen small methods in the next 5 minutes so this
> nannying crap doesn't make me happy.

There are two ways to keep two packages open in the SB. The first has 
been mentioned by Louis and that is to use an IdeaSpace to hold two SBs 
with each one focussed on one of the packages you are interested in. 
This is normally the way I work. You can drag methods and classes 
between the two by first dragging over the IdeaSpace tab of the 
destination browser to bring it to the front.

The way to work with two packages is to realize (and accept) that the 
Package Categories tree is not actually a "categories" tree. It is 
simply a filter based on the directories that the packages are in. If 
the packages you are interested in are in different sub-trees then it 
doesn't help. In such cases you need to choose a common root folder (or 
the ultimate root, $) and then you can multi-select the packages you 
want to work with from the list below.

> Alternatively, in order to avoid this totalitarian infantilism we have
> the helpful "set as default package" feature. (Features to avoid other
> nannying features. Does this stink of diaper shit yet?) I don't know
> about other people's work habits but I currently am extending core
> Smalltalk classes from two different packages. One package has my
> domain objects which extend SmallInteger, the other package has
> testing stuff which naturally enough extends TestCase. Am I making
> myself clear here? I DO NOT HAVE A DEFAULT PACKAGE.

> The best part is that I have two OTHER packages which I'm going to be
> switching back and forth to in order to avoid burning out or stalling,
> so the whole default package idea is a ridiculous non-starter. And of
> course, the moment you start designating a default package, you can
> never STOP. You're stuck with that useless timewasting crap for ever
> and ever.

As I said above, I would recommend not using Default Package if you have 
DPRO.

> Dolphin seems to have been infected with the unfortunate Windows
> philosophy which says the user is an infant.
> 
> Short of getting rid of the checks entirely (no checks isn't as bad as
> bad checks, there's a reason I'm writing in Smalltalk and not C++), my
> proposed solution is:
> 
> 1) allow ANY method to be repackaged at ANY time. Don't make it a
> goddamned catch-22. Get rid of this Kafkaesque shit, please.
> 
> 2) allow a method to be created *no matter what* even if it was done
> from a grey pane. or more likely, a yellow pane that later turns out
> to be grey for some incomprehensibly obscure reason.
> 
> 3) provide an 'Unset default package' method near 'Set as default
> package'

I'd prefer to get rid of the Default Package idea completely or 
implement the change to it that I suggested above.

Regards

Andy Bower
0
Andy
11/28/2009 2:27:09 PM
Andy,

> I'd prefer to get rid of the Default Package idea completely or 
> implement the change to it that I suggested above.
I'd like to keep the Default Package stuff (or something similar) for 
exactly one reason:
I normally only use it when I file in foreign .st files. The intention 
is to keep things organized - even if the .st file extends/modifies base 
image classes.

However if there would be some kind of "extended file-in" asking for the 
package or a file-in option in the packages context menu it would be 
fine (or even better) for me. In this case I have nothing against 
removing the default package stuff.

CU,

Udo
0
Udo
11/28/2009 2:45:52 PM
Andy Bower wrote:

> The way to work with two packages is to realize (and accept) that the 
> Package Categories tree is not actually a "categories" tree. 

This should read, "The other way to work with two packages..."

> Regards
> 
> Andy Bower
0
Andy
11/28/2009 2:46:50 PM
Hello Andy,

On Nov 28, 9:27=A0am, Andy Bower <bo...@SnipThisObject-arts.com> wrote:
> As you've noted, this is caused by having a Default Package set when you
> compile a new method from a System Browser set to a different package.
> The Default Package mode was really intended for use in DCE where one
> doesn't have a System Browser. I, and I guess most others who haven't
> seen this problem, don't tend to use it in DPRO.

I haven't been using the Set Default Package feature since I
reinstalled Dolphin (and yes, it's PRO). So even though that feature
caused my first shocked encounter with the fault, my current run of
faults isn't caused by that.

I CAN report that creating a new package in one system browser causes
all other system browsers to recompile the list of packages. And THAT
causes the core Dolphin packages to be selected and the previous state
of the Packages pane is lost.

Among the nasty consequences, this causes whatever methods you were
editing that you no longer have the right to edit to be treated as if
you've deliberately moved away. Not only is this horrific interaction
design in principle (the IDE is generating events that ought to be
reserved for the user) but methods which you can only guess at are
asking you to put themselves in the clipboard.

Just a few minutes ago I created a new package and two different
methods asked to be put in the clipboard. I know what the first method
was because I'd been working on it, but I haven't the faintest clue
what the second method was since I last worked on it maybe 2 days ago.
And the clipboard came up blank the second time. Nasty.

It gets worse because now the packages and classes are deselected from
the systems browsers all over the IDE and I can only guess at where
some of them were at. In fact, I have one IdeaSpace that contains only
a class browser with Object selected and a reset system browser. Very
informative.

As if this weren't bad enough, I know there are more actions that
cause the spontaneous greying out fault to happen. I've run into the
fault maybe ten times now but I've only made 4 packages total. If I
were up to investigating, I'd first check whether selecting the other
packages in the packages tree causes something to happen in unsaved
loose methods packaged in other branches. Then whether selecting the
core packages branch. I'd also check Save As, though Save itself seems
safe.

> The fact that the method has been placed in another package than the one
> you currently have selected in the SB means that it should appear
> read-only and that includes not being available for repackaging.

Read-only methods should be repackageable. There is nothing in any
package that is read-only in practice. The user can modify everything
in every package in principle. Dolphin doesn't have any security.
Don't pretend it does by throwing sticks in people's bicycle wheels.
That's security through obscurity at best, security theater at worst,
and in all cases is heinous design. What Dolphin DOES have is advisory
policies. Treat them as such. By letting users freely repackage read-
only methods to other packages.

If you look at Dolphin as an operating system, which it is, then it
becomes more obvious that security on packages is strictly advisory.
In order to have real security, you would have to turn every object
pointer into an object capability. And in order for that to be useable
(ie, ordinary users would use it to set policy), you would have to
know certain bleeding edge things about capabilities. Short of going
that route, Dolphin remains a fundamentally open and insecure system.
It doesn't pay to forget this or to pretend otherwise.

(Opentalk and GemStone have some rudimentary security at the borders
of Smalltalk, but these serve only to underline that once you're in
the OS, you're *all the way* in.)

> Please don't accuse me of being defensive here.. it's how it was meant
> to work.

The subject of security design (not the insecurity engineering which
passes for "security" these days, but the conceptualization of what
users have a right to do, what they do not have a right to do, and
what both of these entail) is an interesting one. It is the very first
design subject I interested myself in and I do consider myself
something of an expert in it. And in my opinion, you made the wrong
design choice.

It has to do with the user's identity (a persistent set of rights and
privileges) being naturally tied to IdeaSpaces (a place -- a medium
containing persistent artifacts -- which embodies the user's *role*)
and not at all to the Tree pane in the systems browser. And the reason
why is because IdeaSpaces are places which the user *mentally enters*.
The user doesn't mentally enter the packages in the Package Tree pane.
(Or even a particular browser.)

For one thing, if they did, the pane wouldn't have an auto-hide
feature. One cannot enter and live in a "place" that doesn't exist in
one's perception. And if it were the role of system browsers to embody
the user's role in the system (their identity) then the package tree
pane would hardly be the LEAST prominent of all the panes in system
browsers. For another thing, the whole question of 'what role am I
playing wrt the system' is entirely independent of how many and what
browsers you have open. Such a role can be well-defined while having
zero browsers open, or having 10 browsers open.

Perhaps long, long ago users mentally entered packages. But if they
did, then they must have been very focused individuals and not
scatterbrains like me. Of course the question is moot since you
created IdeaSpaces, correctly judging that people don't live in single
browsers. In case you're interested, yes I do mean that IdeaSpaces
should contain a (one, un, 1) single pane that allows users to select
what packages are active (writeable) throughout the IdeaSpace. That's
not to say the package pane should disappear from system browsers,
just that it should be stripped of all security functions.

You know, reflecting upon it, this isn't so much security design as it
is human-computer interaction design. Or perhaps HCI design of
security. Fortunately, HCI design is my *current* field of interest.

> A possibility might be to make the Default Package setting be ignored
> when one is working in the SB? Would you like that recorded as a
> possible enhancement?

This point is moot to me. And I suspect that what I want (a
reengineering of security & identity away from individual browsers and
towards ideaspaces) would cost a lot of time and effort. Unless you
made security accessible exclusively through Package Browsers, and
only one such can be open per IdeaSpace?

Note that my current work habits involve creating one IdeaSpace for
every package I want open, one System or Package Browser within that
IdeaSpace, and multiple class and other browsers as needed.

Regardless, I *would* like the system browsers to be made independent
so that they do not cause each other to lose state.

> There are two ways to keep two packages open in the SB. The first has
> been mentioned by Louis and that is to use an IdeaSpace to hold two SBs
> with each one focussed on one of the packages you are interested in.
> This is normally the way I work. You can drag methods and classes
> between the two by first dragging over the IdeaSpace tab of the
> destination browser to bring it to the front.

This shouldn't be necessary. And since I'm using system browsers as
poor men's adjuncts to IdeaSpaces, what you're describing shouldn't
even be possible. An IdeaSpace shouldn't contain multiple lists of
writeable packages. It should contain a unique multi-list.

> The way to work with two packages is to realize (and accept) that the
> Package Categories tree is not actually a "categories" tree. It is
> simply a filter based on the directories that the packages are in. If
> the packages you are interested in are in different sub-trees then it
> doesn't help. In such cases you need to choose a common root folder (or
> the ultimate root, $) and then you can multi-select the packages you
> want to work with from the list below.

Well yeah, but that doesn't help when the package is in no-space.
Packages in $ aren't actually anywhere. That's probably part of the
problem.

To summarize, the system browsers are interfering with each other in
such a way as to make the 'active packages' security feature
effectively global across the entire IDE. Currently this feature is
supposed to be specific to individual browsers. Clearly this isn't the
case. But fixing the feature so that it IS specific to individual
browsers would cause pain to users (and bitching by those with low
pain tolerances). The correct level of granularity for this feature is
at IdeaSpaces.

IdeaSpaces are at a convenient middle ground, more general than
browsers and more specific than the entire IDE. For my uses,
IdeaSpaces are small enough for protection (an IdeaSpace can be
created to host a single browser), and large enough for freedom and
comfort (which I value greatly). I suspect many other users agree, or
would agree if they reflected upon their interactions with the IDE.
And then of course there are all the novice users who don't know
enough to bitch when they're in pain. Note that if users want finer-
grained security then this may be retained as a strictly optional
feature. Security should never be finer grained than the user demands
it to be.
0
Richard
12/1/2009 3:20:59 AM
Richard,

> I CAN report that creating a new package in one system browser causes
> all other system browsers to recompile the list of packages. And THAT
> causes the core Dolphin packages to be selected and the previous state
> of the Packages pane is lost.

Yes, I can see this is a bug. I've recorded it as #2276. I've created 
some failing tests but fixing it might be a little harder.

> Well yeah, but that doesn't help when the package is in no-space.
> Packages in $ aren't actually anywhere. That's probably part of the
> problem.

Actually, $ doesn't represent "no-space". Instead, it's the folder where 
the image is located.

Best regards

Andy Bower
0
Andy
12/10/2009 1:07:18 PM
Reply: