bugGNUstep - Bugs: bug #25384, validateToolbarItem: not being...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #25384: validateToolbarItem: not being called very often

Submitted by:  Doug Simons <theeggcamefirst>
Submitted on:  Thu 22 Jan 2009 10:03:02 PM UTC  
 
Category: Gui/AppKitSeverity: 4 - Important
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: Gregory John Casamento <gcasa>
Open/Closed: In Test

(Jump to the original submission Jump to the original submission)

Sun 08 Mar 2009 01:12:45 AM UTC, comment #6:

I'm not sure if this is a related issue or not (if not I can open a different bug report), but since I updated to the latest SVN copy (r28049) the Bean's toolbar has been flickering real bad whenever I move the mouse around the application. I can be moving it on the text area and the tool bar will still go insane with the flickers.

This is on a laptop with a Turion 64 X2 processor, 3 GB of RAM and the nvidia proprietary drivers... so resources should not be an issue.

Stef <stefanbidi>
Project Member
Tue 10 Feb 2009 10:10:08 PM UTC, comment #5:

Please try this now. I have made the fix you suggested and tested it on a number of different applications.

Gregory John Casamento <gcasa>
Project AdministratorIn charge of this item.
Sat 31 Jan 2009 06:30:24 AM UTC, comment #4:

I'm not familiar with the toolbar code, but out of interest I had a quick look.

The comments at the start of the file make it clear that the validation code here is designed to only update infrequently and only update if the mouse is in the window. indeed there's quite a bit of complex code there which seems (to my naive eye) intended primarily to ensure that things are NOT validated once per window update.

Looking at the Apple documentation, I haven't seen anything to say that validation should be done either infrequently or only when the mouse is in the window, and my natural intuition is to say that validation should be done as long as the toolbar is visible, whether the mouse is in the window or not, and should be done for every window update (though not recursively).

However, I'll leave this one to Greg as I guess he knows the rationale behind the current setup.

Richard Frith-Macdonald <CaS>
Project Member
Sat 31 Jan 2009 01:21:25 AM UTC, comment #3:

That didn't fix it. I set a breakpoint in the windowDidUpdate: method in NSToolbar.m and found that the _inside ivar wasn't set so it was returning without calling validate. I removed the test of _inside from that method here and the toolbar is updating perfectly.

So I'm not sure why _inside doesn't get set in this window (I think toolbars in my other windows were working fine before, but seem to update more quickly now, although that is a subjective impression that may be wrong). Anyway, is that test necessary? I haven't seen any ill effects yet, but of course I haven't done extensive testing and don't know what sort of problems to look for.

Doug Simons <theeggcamefirst>
Fri 30 Jan 2009 01:08:33 PM UTC, comment #2:

I made a change to NSApplication.m which might have fixed this issue.
I was correcting the logic for when -updateWindows was called, and as far as I can see, validateToobarItem should be called whenever its window is updated.

Richard Frith-Macdonald <CaS>
Project Member
Thu 29 Jan 2009 09:38:29 PM UTC, comment #1:

Perhaps I should have given this bug a more urgent-sounding title, like "Toolbar validation is broken!".

The fact is that toolbars don't validate correctly because the validation method is called very rarely. This results in a number of significant problems, including functionality being unavailable (because toolbar items are not enabled when the should be) and crashes or other errors (because toolbar items are enabled when they shouldn't be, allowing methods to be called when the app isn't in a state to handle them properly), as well as confusion resulting from incorrect titles or images being shown that don't reflect the current state of the application.

So I'd really appreciate it if someone would figure this one out, or at least bump the severity on this report up a notch so it doesn't get ignored. Thanks!

Doug Simons <theeggcamefirst>
Thu 22 Jan 2009 10:03:02 PM UTC, original submission:

We have toolbar items that become enabled or disabled depending on the state of the application. On OS X the validateToolbarItem: method is called frequently, allowing us to update this, but in GNUstep that method is called very rarely, so the state of our toolbar items doesn't keep up with the state of the app.

Doug Simons <theeggcamefirst>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by stefanbidi (Posted a comment)
  • -unavailable- added by CaS (Posted a comment)
  • -unavailable- added by gcasa (Updated the item)
  • -unavailable- added by theeggcamefirst (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 10 Feb 2009 10:10:08 PM UTCgcasaStatusIn Progress=>Fixed
      Open/ClosedOpen=>In Test
    Fri 30 Jan 2009 07:14:23 AM UTCgcasaStatusNone=>In Progress
      Assigned toNone=>gcasa
    Thu 29 Jan 2009 11:06:01 PM UTCgcasaSeverity3 - Normal=>4 - Important

    Back to the top


    Powered by Savane 3.1-cleanup1