gnustep-dev
[Top][All Lists]
Advanced

[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
>> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]