bugGNUstep - Bugs: bug #21478, Selection issues and invisible...

Group
 
 

bug #21478: Selection issues and invisible view control points with current GNUstep svn

Submitter:  Quentin Mathé <qmathe>
Submitted:  Tue 30 Oct 2007 02:21:42 PM UTC
   
 
Category:  Gorm Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  gcasa
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 06 Mar 2013 06:57:46 AM UTC, comment #9: 

No comments in six years.  Marking fixed and closing.  A fix was submitted and tested by me, but never replied to when testing was requested from the reporting party.

Gregory John Casamento <gcasa>
Group administrator
Tue 22 Jun 2010 07:52:38 AM UTC, comment #8: 

selection in Gorm seems in quite good shape to me. Are any cases left that still need fixing, Quentin?

Riccardo Mottola <rmottola>
Group Member
Tue 06 Nov 2007 02:49:01 PM UTC, comment #7: 

Before committing, I went through the list you have below.  All seem to work properly to me.

Please post additional details and let me know what you are seeing when you can.

Thanks, GJC

Gregory John Casamento <gcasa>
Group administrator
Tue 06 Nov 2007 12:08:41 PM UTC, comment #6: 

Looks and feels a lot better now, the control points are now drawn in most cases.

However selection still doesn't work reliably in my tests.
I have been experimenting selection issues in Gorm for a long time now (including previous releases), but I reported the problem in details for the first time in this bug report.
The -drawRect: bug you fixed was probably the first part of the problem.

Some selection problems I report in my first post still exist, but they may manifest a bit differently now that the selection is properly drawn. I'm working on an update to my control-by-control summary.

Thanks,
Quentin

Quentin Mathé <qmathe>
Group Member
Mon 05 Nov 2007 06:59:01 AM UTC, comment #5: 

Changed code to use drawRect: and it appears to be working properly.  Please test.

Gregory John Casamento <gcasa>
Group administrator
Sat 03 Nov 2007 09:28:44 PM UTC, comment #4: 

Thank you for explaining this. Still I don't see, why most of these methods just duplicate code from the super implementation, but most likely this is not important for the current issue.

Did you make any progress? As I said, I would like to help but would need some pointers, where to look in Gorm. Where are these control points generated? And where do they get displayed?
Was my last comment of any help or completely off the topic?

Fred Kiefer <FredKiefer>
Group Member
Thu 01 Nov 2007 09:39:30 PM UTC, comment #3: 

The event method overrides are implemented there to pass any events to the containing editors, if the current editor doesn't handle it.  It's possible, in Gorm, to have editors within other editors... such as when a button is inside of a NSBox and other examples.

Gregory John Casamento <gcasa>
Group administrator
Thu 01 Nov 2007 11:30:20 AM UTC, comment #2: 

I would like to help out on this problem, but will need some more information on the internal working of Gorm.

First I would expect that there could be two possible sources for this problem. One would be just a redraw issue, trickered by Gorm missing some of the draw method calls from gui. In this case the changes to the draw mechanism in NSView would be the reason. I noticed that Gorm overrides some internal NSView methods in GormViewEditor (no idea, if this class is really relevant here). There displayIfNeededInRectIgnoringOpacity: and
displayRectIgnoringOpacity: are defined. Now the correct call to override would be displayRectIgnoringOpacity:inContext: and it would be even better not to work on that level, but to do what ever is needed for the view in drawRect:. This would also be save against futher changes of the internal drawing code, which is to be expected as soon as we start to optimize NSView.

The other potential cause I see is event processing. Here I am really lost, as I don't have a glue where to look in Gorm. Just the same class GormViewEditor has a very strange set of event method overrides.

So please give me a hint and I join in to chase this bug.

Fred Kiefer <FredKiefer>
Group Member
Thu 01 Nov 2007 06:20:39 AM UTC, comment #1: 

As far as I can tell something in the recent NSView changes has broken this functionality.  I am in the process of tracking it down.

Thanks GJC

Gregory John Casamento <gcasa>
Group administrator
Tue 30 Oct 2007 02:21:42 PM UTC, original submission:  

Linux Ubuntu 6.10
GCC 4.1.2
GNUstep r25530 (including Gorm)

Usually when you click a view inside a window or another view, Gorm display four square corners (knots) which can be used to resize the view. With latest GNUstep, I observe these control points are invisible most of time or I need to click several times on special view areas to obtain the black or gray knots.

Below you can find a summary explaining how the issue varies with each kind of controls and how to reproduce it in each case.
The exepected behavior in all cases is that the control points should appear immediately on the first click when you click anywhere on the view.

- NScrollView & NSTableView
If I double-click anywhere on a table view, then I double-click on the vertical scroller area of the table view, four black knots are shown.

- NSBox
If I double-click anywhere on a box, then I double-click on the label area of the title area, four black knots are shown.

- NSTabView
If I triple-click on the content area of a tab view, four black knots are shown. Nothing happens if click any number of times on the tab view items area.

- NSForm
If I double-click anywhere on a form two times (two double-clicks), four black knots are shown.

- NSButton & NSComboBox & NSTextField (including labels without borders like System, System Bold etc.)
I must double-click it to obtain nine gray knots.

- NSPopUpButton & NSSlider & NSStepper & NSColorWell
No knots at all.

- Radio and checkbox buttons case
If the radio/checkbox button is made of a single button, then the NSButton issue appears (mandatory double-click to have selection feedback). But if I turn the radio/checkbox button into a matrix of radio/checkbox buttons, then no knots are ever displayed no matter how many times I click.

- NImageView
No knots at all.

- NSTextView
If I double-click anywhere on a text view, then I make a third click in vertical scroller area, four black knots are shown. This also works if you just do a triple-click on the vertical scroller area. As a note, time to time these steps I describe to display the knots doesn't work. I don't really understand why and it's very hard to reproduce (only happens approximatively one time in ten tries).

Quentin.

Quentin Mathé <qmathe>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by qmathe (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-03-06 gcasa StatusIn Progress Fixed
        Open/ClosedIn Test Closed
    2007-11-05 gcasa Item GroupNone Bug
        Open/ClosedOpen In Test
    2007-11-01 gcasa StatusNone In Progress
        Assigned toNone gcasa

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code