[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: group/ungroup in Gorm
From: |
Tim Schmielau |
Subject: |
Re: group/ungroup in Gorm |
Date: |
Fri, 6 May 2011 22:51:21 +0100 |
Thanks for taking the time to explain this.
I now think that this problem and the other one I've posted about (connections
sometimes going to the wrong controls), are actually related to a third
observation I've not yet posted to the list:
Using Gorm and GNUstep from current SVN (or Gorm 1.2.12 compiled for current
SVN GNUstep), I observe occasional hiccups, where Gorm does not react to
anything for about a second or so. This seems to be related to tooltip code, as
often at the end of this period a white (or in rare cases light blue or light
yellow) strip occurs in a random position near the mouse pointer, which looks
suspiciously like a partially drawn tooltip. I'm wondering if also other parts
of the window miss updates on screen at that time, which would explain the
seemingly random behavior in other regards.
If I have understood your explanation correctly on how to edit controls inside
a subview, then I think I have already tried this, however with no success (the
black handles appear, but the content of the subview appears frozen and does
not react to user input). It might well be that this is a result of missing
screen updates as mentioned above.
With regard to selecting views inside a subview, I very much like the method
chosen by Interface Builder: Select the outmost containing element first. Then
while that selection still exists, each repeated (single) click instead selects
the element one step deeper into the hierarchy.
However I am also fine with the current behavior as you describe it, as long as
I can actually see that happen on my screen.
Thanks,
Tim
On 6 May 2011, at 22:22, Gregory Casamento wrote:
>
> I can understand how this can be confusing and many people have asked
> for it to be improved.
>
> If you group a control in a subview (box, etc)... then you should be
> able to access the subview by double clicking the view which contains
> it. This should turn the handles on the containing view black and you
> should now be able to select the view/control inside. Please try it,
> and see if it works...
>
> I have been thinking about changing this behavior so that if you click
> on, say, an NSButton in an NSBox that the editor which holds the box
> (Gorm uses editors to handle each element in the gui... the editors
> define how the object is edited... i.e. how the element responds to
> clicks) that it would select the NSButton instance.
>
> The alternative is to better document this behavior so that it doesn't
> confuse so many people. But it would be nice if it could do this
> since it's more natural.
>
> Later, GC
>
> On Fri, May 6, 2011 at 1:35 PM, Tim Schmielau
> <address@hidden> wrote:
>> On 6 May 2011, at 18:30, Banlu Kemiyatorn wrote:
>>> On Fri, May 6, 2011 at 10:55 PM, Tim Schmielau wrote:
>>>
>>>> So is the only available option going back to my last backup, and recreate
>>>> all steps from there? That would probably keep me from using this feature
>>>> again...
>>>
>>> Or just save, try to fix Gorm's ungroup method, and reload the project
>>> to ungroup?
>>
>> I'm trying to do that, yes. For now I've recreated the gorm file from
>> backup, but I'll see if I can fix this in Gorm (so I can contribute a tiny
>> bit to the GNUstep project).
>>
>> Thanks,
>> Tim
>>