Re: how to add a custom view (a pair of controls) to an NSToolbar in Interface Builder
Thank you Joey! This most certainly works a treat. cheers Rua HM. On 30/11/2010, at 10:59 AM, Joey Hagedorn wrote: Rua, This won't work with an instance of the custom view in the toolbar. A workaround would be to use a borderless (Custom / No Border) NSBox instead of a custom view. This is probably the most straightforward fix. There is some more info in this older post to the list: http://www.cocoabuilder.com/archive/cocoa/236455-nstoolbaritem-with-custom-view-in-interface-builder-3-leopard.html --Joey On Nov 22, 2010, at 5:29 PM, Rua Haszard Morris wrote: What I have tried: - new window NIB file - add a toolbar - add a custom view to the nib - add controls to the custom view - a button, textfield, etc, tweak layout to taste - drag the custom view to the toolbar customise sheet (i.e. the allowed items area) - it looks like the view content will appear - the buttons are drawn in the allowed items area - drag the custom item to the toolbar (so it is in the default set) - oh no, the buttons disappear - simulate the interface - oh no, still no buttons! Perhaps my first email was not concise enough... thanks for the help Rua HM. On 23/11/2010, at 1:55 PM, Graham Cox wrote: On 23/11/2010, at 10:02 AM, Rua Haszard Morris wrote: Is this not possible? Yes, it's possible. But your question is too open-ended. What have you tried, what doesn't perform as expected? --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hagedorn%40apple.com This email sent to haged...@apple.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: how to add a custom view (a pair of controls) to an NSToolbar in Interface Builder
Any suggestions on how to do this? I simply want to use a bunch of controls, grouped via a custom view, in a toolbar, such that the controls form a single toolbar item (for add/remove), but the individual controls respond to mouse, draw, etc as normal. Is this not possible? thanks Rua HM. On 18/11/2010, at 12:44 PM, Rua Haszard Morris wrote: I would like to add an item to my window's toolbar that is a custom view containing other standard views. For example a popup button and a static text field. If possible I would like to do this in interface builder, without implementing NSToolbarDelegate. So to clarify.. I have a window with a toolbar in an interface builder file. I want to put a popup button and static text on the toolbar as a single item - I want them to be removeable/addable as a pair, and I want full control over their layout within the toolbar item. I want to run the interface in IB using the Cocoa Simulator and see the popup button and text draw. 1 - Is this possible in Interface Builder? If so, can someone briefly outline the steps? 2 - If this is not possible in IB, how would this best be implemented? If this is the case, can this work alongside configuring the toolbar in IB, or will the allowed items configured in IB be ignored at runtime? (This is why I'd prefer to do this fully in IB). What I have tried: - new window NIB file - add a toolbar - add a custom view to the nib - add controls to the custom view - a button, textfield, etc, tweak layout to taste - drag the custom view to the toolbar customise sheet (i.e. the allowed items area) - it looks like the view content will appear - the buttons are drawn in the allowed items area - drag the custom item to the toolbar (so it is in the default set) - oh no, the buttons disappear - simulate the interface - oh no, still no buttons! I didn't find any confirmation that this is not possible in these previous threads.. http://www.mail-archive.com/cocoa-dev@lists.apple.com/msg35450.html http://www.cocoabuilder.com/archive/cocoa/282463-custom-view-in-toolbar.html thanks for the help Rua HM. -- http://cartoonbeats.com___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/r.haszard%40adinstruments.com This email sent to r.hasz...@adinstruments.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: how to add a custom view (a pair of controls) to an NSToolbar in Interface Builder
What I have tried: - new window NIB file - add a toolbar - add a custom view to the nib - add controls to the custom view - a button, textfield, etc, tweak layout to taste - drag the custom view to the toolbar customise sheet (i.e. the allowed items area) - it looks like the view content will appear - the buttons are drawn in the allowed items area - drag the custom item to the toolbar (so it is in the default set) - oh no, the buttons disappear - simulate the interface - oh no, still no buttons! Perhaps my first email was not concise enough... thanks for the help Rua HM. On 23/11/2010, at 1:55 PM, Graham Cox wrote: On 23/11/2010, at 10:02 AM, Rua Haszard Morris wrote: Is this not possible? Yes, it's possible. But your question is too open-ended. What have you tried, what doesn't perform as expected? --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
how to add a custom view (a pair of controls) to an NSToolbar in Interface Builder
I would like to add an item to my window's toolbar that is a custom view containing other standard views. For example a popup button and a static text field. If possible I would like to do this in interface builder, without implementing NSToolbarDelegate. So to clarify.. I have a window with a toolbar in an interface builder file. I want to put a popup button and static text on the toolbar as a single item - I want them to be removeable/addable as a pair, and I want full control over their layout within the toolbar item. I want to run the interface in IB using the Cocoa Simulator and see the popup button and text draw. 1 - Is this possible in Interface Builder? If so, can someone briefly outline the steps? 2 - If this is not possible in IB, how would this best be implemented? If this is the case, can this work alongside configuring the toolbar in IB, or will the allowed items configured in IB be ignored at runtime? (This is why I'd prefer to do this fully in IB). What I have tried: - new window NIB file - add a toolbar - add a custom view to the nib - add controls to the custom view - a button, textfield, etc, tweak layout to taste - drag the custom view to the toolbar customise sheet (i.e. the allowed items area) - it looks like the view content will appear - the buttons are drawn in the allowed items area - drag the custom item to the toolbar (so it is in the default set) - oh no, the buttons disappear - simulate the interface - oh no, still no buttons! I didn't find any confirmation that this is not possible in these previous threads.. http://www.mail-archive.com/cocoa-dev@lists.apple.com/msg35450.html http://www.cocoabuilder.com/archive/cocoa/282463-custom-view-in-toolbar.html thanks for the help Rua HM. -- http://cartoonbeats.com___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
how do I get tracking, selection etc working with custom views in NSMenuItems?
Hi Cocoa-dev, I'm experimenting with using NSViews in menus, and was expecting that such items could continue to use Cocoa-provided implementations of mouse tracking, selecting an item and dismissing the menu, etc. After a lot of experimentation, doc reading and googling I've managed to hook up mouse tracking somewhat correctly - by implementing the delegate method menu:willHighlightItem:, and ensuring my views get setNeedsDisplay:YES when they get un-highlighted. This seemed to work correctly but was a lot more work than I expected. More importantly, I want the NSView items to behave the same as other menu items - i.e. when the user selects one, by mouse or keyboard, the menu dismisses and actions are sent (and the item highlight flashes briefly). I can't work out how to get this hooked up without reinventing the wheel. Note that my NSViews don't require mouse input - I'm just using NSView items for custom display, not the more complicated case displaying a control in the menu. Does anyone have any good pointers regarding using NSViews in an NSMenu and falling back to system-provided code for tracking and selection? thanks Rua HM.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: get the selection in an NSOutlineView
Thanks all, itemForRow was the missing piece of the puzzle. Now this thing makes sense.. At the time you call -selectedRowIndexes, you should then extract the items corresponding to those indexes from your data model (e.g. using [NSArray objectsAtIndexes:]) before the user has a chance to change the arrangement. Actually I just call -itemForRow: to convert each row index to an object. That way the code for that isn’t dependent on how my data source works. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
get the selection in an NSOutlineView
I have an NSOutlineView which has a single column, and 2 levels of tree - each item in the list can have child items but those subitems don't have children. How can I determine the selected items? NSTableView -selectedRow returns row indices that change dependent on whether parent items are expanded, so that won't do. I could attempt to keep track of the selection via delegate method outlineView:shouldSelectItem: but this seems a bad idea. Am I missing something? Surely it is possible to ask an NSOutlineView which items are selected? thanks Rua Haszard Morris.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: multiple-page print support in NSView
I am trying to write an NSView subclass to render a multi-page printout. What I would like is to use the page/paper size in calculating the dimensions of each page; for example, if the printout is made up of N rows of items, each item rendering as 60-point-tall row. So, assuming 10 rows of items, the rendered view needs to be 10 * 60 pt high, and the page boundaries need to be set appropriately - if the usable paper area is 120 points high, then we need 5 pages of 2 rows, and if the user specifies much larger paper, e.g. 240 points, then we need 3 pages, each with up to 4 rows (the last page only having two rows). How do I implement knowsPageRange, rectForPage, and locationOfPrintRect to achieve this? I have tried implementing these methods to set up arbitrary rectangles for each page, and I find that the rendering I do in drawRect is scaled weirdly in the printout, with a huge (half the page) right margin and an even huger (more than half the page, proportional to the total number of pages) top margin. I found my problem - I needed to set the pagination options on the NSPrintInfo appropriately, otherwise the automatic pagination interacts with my custom pagination. The trick was to implement print: myself and set up the NSPrintInfo and the current NSPrintOperation, so the rest of my view code could successfully query the page size, margins etc. NSPrintOperation* po = [NSPrintOperation printOperationWithView:self]; NSPrintInfo *pInfo = [po printInfo]; [NSPrintOperation setCurrentOperation:po]; [pInfo setHorizontalPagination:NSFitPagination]; [pInfo setVerticalPagination:NSClipPagination]; Is there sample code or a tutorial somewhere that explains how to set up custom page coordinates? I have read through Printing Programming Topics for Cocoa, and it seems I'm missing something critical here. That is pretty much it other than sample code. Are you aware of the sample code listings that come with each class reference document? Other than that, the only difficult-to-find documentation that is a real hiney-biter is that text is always rendered in a flipped coordinate system. Good point, I see there are a range of Sketch related and other samples listed in the links for NSPrintOperation, NSPrintInfo. I should mention that the documentation changed a lot over the weekend, the new Printing Programming Topics for Cocoa is slightly more helpful! thanks for the advice Rua HM. -- http://cartoonbeats.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
multiple-page print support in NSView
I am trying to write an NSView subclass to render a multi-page printout. What I would like is to use the page/paper size in calculating the dimensions of each page; for example, if the printout is made up of N rows of items, each item rendering as 60-point-tall row. So, assuming 10 rows of items, the rendered view needs to be 10 * 60 pt high, and the page boundaries need to be set appropriately - if the usable paper area is 120 points high, then we need 5 pages of 2 rows, and if the user specifies much larger paper, e.g. 240 points, then we need 3 pages, each with up to 4 rows (the last page only having two rows). How do I implement knowsPageRange, rectForPage, and locationOfPrintRect to achieve this? I have tried implementing these methods to set up arbitrary rectangles for each page, and I find that the rendering I do in drawRect is scaled weirdly in the printout, with a huge (half the page) right margin and an even huger (more than half the page, proportional to the total number of pages) top margin. A possibly related issue is that the view doesn't know it's actual size (i.e. frame) until it has rendered itself, because of the number of items, and the possibility of large items that take up more than a single row. There may be an interaction between a size given to the view at init time (if it isn't given a size then it doesn't render anything in the printout) and the actual size of the complete printout. In general my problems involve the relationship between page coordinates and view coordinates - if I can relate these two sizes appropriately then I might be able to get somewhere. Is there sample code or a tutorial somewhere that explains how to set up custom page coordinates? I have read through Printing Programming Topics for Cocoa, and it seems I'm missing something critical here. Thanks Rua HM.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
how to load an NSMenu out of a nib?
I'm baffled, this seems fundamental, I can't see how it's done! I have a Menu in a nib file, which I need to use in a few places in code. So I want to do something like NSMenu* myMenu = [NSMenu menuFromNib:@MyNibFile name:@MyUsefulMenu]; Is this possible - how can this be done? I have looked at the NSMenu reference, how to unarchive Carbon menus (but there is no toll free mapping/other conversion between MenuRef and NSMenu?). It seems the only way to get this working is to have an class with an outlet specifically for receiving a reference to my menu - which seems indirect... Hopefully this is a dumb question and there's an easy answer... thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: how to load an NSMenu out of a nib?
Making a class with an outlet, and passing an instance of that class as the nib's owner, is one way. You can also use the NSNibTopLevelObjects key as described at the bottom of http://developer.apple.com/DOCUMENTATION/Cocoa/Reference/ApplicationKit/Classes/NSNib_Class/Reference/Reference.html . You pass an NSMutableArray under this key, and after the nib is loaded, the array is populated with the top level objects in the nib. Thanks, I was not aware of the second option, which sounds a little low-level but good all the same. I have the outlet + spare class working, and it's not too weird, if I consider my nib a collection of utility stuff, and have a utility stuff class which loads the nib and has outlets (with accessors) for all the things in the nib.. still, I was expecting a line or two of code, not to have to make an instance variable for things I want out of the nib! I'm still shocked there's no standard way to do this... thanks for the help Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSPopUpButton pullsDown:YES and dummy first item - normal?
Thanks for the suspicion-confirmation and docs pointers. I had seen the conceptual info about the 1 versus zero thing: my problem with that documentation is it says the first item is stored at 1 - which is written the wrong way around, in that the first item is stored at zero, but is ignored. I'll fill in the docs feedback form.. thanks, Rua HM. On 3/04/2009, at 9:56 AM, Michael Ash wrote: On Thu, Apr 2, 2009 at 7:58 AM, Graham Cox graham@bigpond.com wrote: On 02/04/2009, at 12:55 PM, Rua Haszard Morris wrote: This seems like a weird hack, and makes me think I'm going about this the wrong way - is this a normal approach? I'm afraid so. I think the reason could be (pre)historic - the original Carbon Menu Manager (which Cocoa sits atop) constructed menus this way. It sucks, has always sucked, and looks likely that (as it has never been changed despite the vast catalogue of other changes elsewhere) will always suck. I doubt this is the case. NSPopUpButton long predates Mac OS X and therefore existed long before it was implemented on top of the Menu Manager. Sounds like convergent evolution to me. A silly choice I agree, but somehow it got made twice. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/r.haszardmorris%40adinstruments.com This email sent to r.haszardmor...@adinstruments.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSPopUpButton pullsDown:YES and dummy first item - normal?
I am using a pull-down NSPopUpButton for a little button which displays a little menu. The menu has some commands in it, i.e. it's not a selection menu, the title of the button just displays an icon, no title, no indication of a current item from the menu. I am calling (ahem, sending) setUsesItemFromMenu:NO on (to) the cell. It appears that with pull-down menus I need to insert a dummy item at index zero as my NSPopUpButton as a placeholder, and that NSPopUpButton/Cell (when in pull-down mode) will handily ignore this item. This seems like a weird hack, and makes me think I'm going about this the wrong way - is this a normal approach? The documentation mentions that the index of the first item in a pull- down should be 1, but it doesn't explain that you need to add a dummy item (for the zeroth) or else your first item will go missing. thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
how to set up nextKeyView, full keyboard access etc, for custom subviews set up in code (rather than nib)
I have a dialog that has a few controls as well as a complex custom view that itself contains other controls as subviews. The custom view (for various good reasons) is instantiated and added as a subview in code. A template view and NSView's replaceSubview:with is used so the positioning etc can be set in the nib. To fully support keyboard access, I need to somehow set things up so that the user can tab from the nib-instantiated controls to the controls within the custom view and then back out again. How can I achieve this? I'll also (presumably) need to set up the nextKeyView-chain for the controls within the custom view (composed of a hierarchy of subviews with their own subcontrols...), but I think I have an idea of how to do this. thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: SOLVED Re: NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
Or, you could create an NSView subclass instance with -isFlipped overridden shared among non-flipped views. You can add the flipped view to your view inside -drawRect: and - lockFocus to it temporarily. Depending on your rendering needs, this approach is preferable performance-wise than allocating graphics context. Yep, I did do this initially, but in the end I just implemented it using drawAtPoint to keep things simple (since my needs are fairly modest). The view class is pretty lightweight, its main role is to ensure the baseline lines up with where the caller needs it. thanks for all the informative suggestions, Rua HM. Aki On 2008/11/19, at 14:22, Ken Ferry wrote: On Tue, Nov 18, 2008 at 1:57 PM, Rua Haszard Morris [EMAIL PROTECTED] wrote: What are the different options for flipping the coordinates of the destination view? I've tried doing it by scaling and translating the CGContext, but this results in problems with underlining or the character orientation (depending on whether i flip the view back before or after drawing the text). At the moment the only method which results in correct text is to have a custom view and override isFlipped - is this the only recommended method? Doug answered the overall question, but maybe I'll chime on this bit specifically. As you're finding, -isFlipped and the CTM are entirely orthogonal pieces of data. If you're using NSLayoutManager, you need the current context to return YES to -[NSGraphicsContext isFlipped], and you also want the CTM set up so that the text goes where you want. There is no setter for -[NSGraphicsContext isFlipped], but you don't need to use a custom view. [NSGraphicsContext graphicsContextWithGraphicsPort:[originalContext graphicsPort] flipped:YES] would give you a graphics context object that is flipped without otherwise modifying the CTM or anything. -Ken I ask because I have to use these strings within custom views (which may for example have rotated contexts), as well as in standard controls, and simpler custom views purely for drawing these attributed strings. If the only method to have the attributes (particularly underline) interpreted correctly is to perform the drawing in a isFlipped NSView subclass, then I need to rejig things so the complex custom views embed an NSView rather than draw the attributed string manually. thanks Rua HM. On Nov 19, 2008, at 9:40 am, 11(November)/19/08, Rua Haszard Morris wrote: Thanks for the link, you are right, I had not seen that document! On Nov 19, 2008, at 9:33 am, 11(November)/19/08, Douglas Davidson wrote: On Nov 18, 2008, at 12:18 PM, Rua Haszard Morris wrote: To follow up.. below I have pasted the code that draws the text (for my test app, as opposed to the more complex ways of reproducing the bug elsewhere in my code). (the full test app is attached to the radar bug) I have been consulting the Text System Overview documentation, which I don't believe mentions this fact. http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/TextArchitecture.html I can understand that drawing text top to bottom makes sense, but I am surprised that the coordinate system of the destination context has such far-reaching side effects. You're looking at the Text Systems Overview, which is very general conceptual documentation, the sort you would consult to decide which class to use. What you want is the Text Layout Programming Guide for Cocoa, which gives more detailed direction as to how to use these classes. The first section, http://developer.apple.com/documentation/Cocoa/Conceptual/TextLayout/Concepts/LayoutManager.html under the heading Glyph Drawing says, The text system expects view coordinates to be flipped, like those of NSTextView. If you are going to be drawing using the layout manager directly, this is a hard-and-fast rule. Douglas Davidson ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/r.haszardmorris%40adinstruments.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/kenferry %40gmail.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update
Re: NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
On Nov 18, 2008, at 1:00 pm, 11(November)/18/08, Douglas Davidson wrote: On Nov 17, 2008, at 3:50 PM, Rua Haszard Morris wrote: I have found that NSSuperscriptAttributeName, NSUnderlineStyleAttributeName, and NSObliquenessAttributeName (those are the attributes that I have tested) render differently when Cocoa Text is used to draw the string. The attributes appear to be intrepreted inverted, in that 1 for superscript produces subscript, positive obliqueness is a leftward tilt, etc. In normal controls the attributes render as expected. Make sure that you are drawing in a flipped context. I was ensuring that I am _not_ drawing in a flipped context... (!) now, as you suggest I tried flipping the custom view (override isFlipped) that the attributed string is drawn in, and note that it works correctly! So an improved workaround is to tweak the positioning logic (to account for the flipped context) instead of tweaking (hacking) the actual attributes. I'm still not clear on why this should be the case. Thanks for the vastly better workaround though.. thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
SOLVED Re: NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
To follow up.. below I have pasted the code that draws the text (for
my test app, as opposed to the more complex ways of reproducing the
bug elsewhere in my code). (the full test app is attached to the radar
bug)
I have been consulting the Text System Overview documentation, which I
don't believe mentions this fact.
http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/TextArchitecture.html
I can understand that drawing text top to bottom makes sense, but I am
surprised that the coordinate system of the destination context has
such far-reaching side effects.
Thanks for all the info,
Rua HM.
- (void)drawRect:(NSRect)rect {
CGContextRef context = (CGContextRef)[[NSGraphicsContext
currentContext]graphicsPort];
CGContextSaveGState(context);
NSTextStorage* textStorage = [[NSTextStorage alloc]
initWithAttributedString:attribString];
NSLayoutManager *layoutManager;
layoutManager = [[NSLayoutManager alloc] init];
[textStorage addLayoutManager:layoutManager];
NSTextContainer *container = [[NSTextContainer alloc]
initWithContainerSize:NSMakeSize(, )];
[layoutManager addTextContainer:container];
NSRange glyphRange = [layoutManager
glyphRangeForTextContainer:container];
[layoutManager drawGlyphsForGlyphRange:glyphRange
atPoint:NSMakePoint(10, 10)];
[container release];
[layoutManager release];
[textStorage release];
CGContextRestoreGState(context);
}
On Nov 19, 2008, at 9:09 am, 11(November)/19/08, Douglas Davidson wrote:
On Nov 18, 2008, at 11:53 AM, Rua Haszard Morris wrote:
I was ensuring that I am _not_ drawing in a flipped context... (!)
now, as you suggest I tried flipping the custom view (override
isFlipped) that the attributed string is drawn in, and note that it
works correctly!
So an improved workaround is to tweak the positioning logic (to
account for the flipped context) instead of tweaking (hacking) the
actual attributes.
I'm still not clear on why this should be the case. Thanks for the
vastly better workaround though..
The text system generally prefers a flipped context, because text
generally runs from top to bottom rather than the reverse. You
didn't post code, so I'm not sure exactly what you're doing, but
this is a good general rule.
Douglas Davidson
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: SOLVED Re: NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
Thanks for the link, you are right, I had not seen that document! On Nov 19, 2008, at 9:33 am, 11(November)/19/08, Douglas Davidson wrote: On Nov 18, 2008, at 12:18 PM, Rua Haszard Morris wrote: To follow up.. below I have pasted the code that draws the text (for my test app, as opposed to the more complex ways of reproducing the bug elsewhere in my code). (the full test app is attached to the radar bug) I have been consulting the Text System Overview documentation, which I don't believe mentions this fact. http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/TextArchitecture.html I can understand that drawing text top to bottom makes sense, but I am surprised that the coordinate system of the destination context has such far-reaching side effects. You're looking at the Text Systems Overview, which is very general conceptual documentation, the sort you would consult to decide which class to use. What you want is the Text Layout Programming Guide for Cocoa, which gives more detailed direction as to how to use these classes. The first section, http://developer.apple.com/documentation/Cocoa/Conceptual/TextLayout/Concepts/LayoutManager.html under the heading Glyph Drawing says, The text system expects view coordinates to be flipped, like those of NSTextView. If you are going to be drawing using the layout manager directly, this is a hard-and-fast rule. Douglas Davidson ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: SOLVED Re: NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
What are the different options for flipping the coordinates of the destination view? I've tried doing it by scaling and translating the CGContext, but this results in problems with underlining or the character orientation (depending on whether i flip the view back before or after drawing the text). At the moment the only method which results in correct text is to have a custom view and override isFlipped - is this the only recommended method? I ask because I have to use these strings within custom views (which may for example have rotated contexts), as well as in standard controls, and simpler custom views purely for drawing these attributed strings. If the only method to have the attributes (particularly underline) interpreted correctly is to perform the drawing in a isFlipped NSView subclass, then I need to rejig things so the complex custom views embed an NSView rather than draw the attributed string manually. thanks Rua HM. On Nov 19, 2008, at 9:40 am, 11(November)/19/08, Rua Haszard Morris wrote: Thanks for the link, you are right, I had not seen that document! On Nov 19, 2008, at 9:33 am, 11(November)/19/08, Douglas Davidson wrote: On Nov 18, 2008, at 12:18 PM, Rua Haszard Morris wrote: To follow up.. below I have pasted the code that draws the text (for my test app, as opposed to the more complex ways of reproducing the bug elsewhere in my code). (the full test app is attached to the radar bug) I have been consulting the Text System Overview documentation, which I don't believe mentions this fact. http://developer.apple.com/documentation/Cocoa/Conceptual/TextArchitecture/TextArchitecture.html I can understand that drawing text top to bottom makes sense, but I am surprised that the coordinate system of the destination context has such far-reaching side effects. You're looking at the Text Systems Overview, which is very general conceptual documentation, the sort you would consult to decide which class to use. What you want is the Text Layout Programming Guide for Cocoa, which gives more detailed direction as to how to use these classes. The first section, http://developer.apple.com/documentation/Cocoa/Conceptual/TextLayout/Concepts/LayoutManager.html under the heading Glyph Drawing says, The text system expects view coordinates to be flipped, like those of NSTextView. If you are going to be drawing using the layout manager directly, this is a hard-and-fast rule. Douglas Davidson ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/r.haszardmorris%40adinstruments.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
NSAttributedString rendering bugs when rendered with Cocoa Text (rdar://6379047)
I have found that NSSuperscriptAttributeName, NSUnderlineStyleAttributeName, and NSObliquenessAttributeName (those are the attributes that I have tested) render differently when Cocoa Text is used to draw the string. The attributes appear to be intrepreted inverted, in that 1 for superscript produces subscript, positive obliqueness is a leftward tilt, etc. In normal controls the attributes render as expected. Has anyone else seen this problem? I've implemented some workarounds, tweaking the attribute values depending on whether the string is drawn via standard controls or within custom views, but I'd like to clear up whether I'm doing something wrong, or it's expected behaviour, or if it is a bug in Cocoa Text. I've reported the bug, with a small project demonstrating the problem: rdar://6379047 thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
compile error when protocol not implemented?
I'd like to get an error, not just a warning, when I pass an instance of a class to a method that takes a parameter conforming to some protocol, and the passed object does not implement the protocol. Is this possible? Is there a good way to set things up so an error is generated.. or is there some dynamism reason why a warning is more suited? e.g. for this code @protocol MyProtocol //... @end // (some class) -(void)doSomethingWithProtocol:(id MyProtocol)proto; @interface BobClientClass : NSObject // does not even attempt to implement MyProtocol! @end // some code somewhere where I want an error BobClientClass* bob; [someClass doSomethingWithProtocol:bob]; // generates warning instead of this warning warning: class 'BobClientClass' does not implement the 'MyProtocol' protocol' get an error something like error: class 'BobClientClass' does not implement the 'MyProtocol' protocol' thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: compile error when protocol not implemented?
I figured this must be the reason.. thanks for the detailed explanation. It did occur to me when i'd implemented the protocol method but hadn't yet declared conformance. At the moment this is a zero-warnings build so the warning stands out almost as much as an error... I guess a potential language feature would be some kind of option/ keyword in a protocol declaration to say this protocol must be used in an old-school, compile-time-typesafe way. But only objc newbies would want to use it, right? thanks On Aug 14, 2008, at 4:18 PM, Michael Ash wrote: On Wed, Aug 13, 2008 at 8:39 PM, Rua Haszard Morris [EMAIL PROTECTED] wrote: I'd like to get an error, not just a warning, when I pass an instance of a class to a method that takes a parameter conforming to some protocol, and the passed object does not implement the protocol. Is this possible? Is there a good way to set things up so an error is generated.. or is there some dynamism reason why a warning is more suited? As far as I know, there's no way to make this one thing into an error. Objective-C is based around the idea of duck typing. This is just a funny way of saying that the type of an object is irrelevant. All that matters is what methods it implements (i.e. what it can do; if it looks like a duck, quacks like a duck, then it's a duck). As such, *all* static typing information in an Objective-C program is strictly advisory in nature. Code like this is perfectly legal, although weird: NSString *array = [NSArray arrayWithObject:@hello]; NSLog(@%@, [array lastObject]); Now, protocols are supposed to *be* an indicator of capabilities rather than of type, but the same principle still applies to the use of protocols as part of static types. For example, you could implement the protocol methods without actually declaring conformance to the protocol. That said, good code should compile with no warnings anyway. I don't treat warnings much differently from errors. Occasionally I will tolerate a warning during development, for expediency or to denote something that I need to change later, and I am occasionally forced to accept warnings in external code that I didn't write but that I compile, but overall I treat warnings the same as errors, so the difference is not all that important to you. If you follow this approach but still want an actual stop-the-compile *error*, then you may be interested in the -Werror flag. This turns *all* warnings into errors, not just this one, but then again that may very well be a good thing. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/r.haszardmorris%40adinstruments.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
handling errors from NSNumberFormatter - how to determine exact nature of the error?
I'm using a NSNumberFormatters in a modal dialog to validate text fields. I want to give the user a specific and appropriate error message if they try to OK the dialog with an invalid number in a field. For example I want different error messages for no string entered, non numeric string entered, value larger than max, value less than min. In my implementation of control:didFailToFormatString:errorDescription: I get notified that a format failed, but the description is always Formatting error. I tried calling getObjectValue:forString:range:error: on the formatter, but as far as I can tell the NSError returned is the same for each error condition. So.. I could check the passed in string myself, for length, validity, then max/min, and generate my error message accordingly, but then I'm reimplementing the validation? Is there a better way to achieve this? thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
how to have a pop up menu from an ordinary button?
I am trying to implement a mini-size, square bevel button that pops up a menu, i.e. a popup button with a square appearance and mini size, but have not found a way to achieve this. NSPopupButton does not support square button appearance, and doesn't support setControlSize: (though it can of course be an arbitrary size). I have seen some suggestions for how to achieve this, for example making a NSPopupButton over the top of a square NSButton and setting the NSPopupButton transparent. This works but there are draw issues; sometimes a rounded white area appears around the NSButton (note that I have set the size location of the popup button to match the button, so the clicks are handled appropriately). I also had a look at NSMenu popUpContextMenu:, but this did not seem appropriate, as it seems solely for right-click/context menus. How can I do this? I want to avoid having to write the mouse tracking code if at all possible, so the popup behaves exactly like a system one. I'm not clear on how to do this either.. thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: how to have a pop up menu from an ordinary button?
On Aug 7, 2008, at 2:53 PM, Rua Haszard Morris wrote: I am trying to implement a mini-size, square bevel button that pops up a menu, i.e. a popup button with a square appearance and mini size, but have not found a way to achieve this. NSPopupButton does not support square button appearance, and doesn't support setControlSize: (though it can of course be an arbitrary size). In Leopard, NSPopUpButton supports any bezel style that NSButton supports (excluding uninteresting cases like Disclosure or Help). NSPopUpButton also supports setControlSize:. Are these not working for you? Right you are! I think I was forgetting to call setControlSize: on the cell rather than on the popup itself. I have not tested on 10.4 yet (am building against 10.4 SDK). The other thing I needed to do to make it look appropriate was set the font to a smaller size: [popup setFont:[NSFont systemFontOfSize:[NSFont smallSystemFontSize] - 1]]; It seems I still have a drawing issue, when the window first appears, there's a whiteish rectangle drawn above the button. I think this is due to the parent view not being notified about the menu invalidating the area - the rectangle is similar to the width of the menu and protrudes vertically by the same amount. thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
guidelines/tutorial for implementing custom controls
Can anybody point me to some good tutorials/guides for implementing custom controls? I've been reading the Cocoa Event Handling Guide, The reference and accompanying conceptual guides for NSControl, NSCell, NSActionCell and NSView, but I'm more confused than when I started. If anyone could answer these more specific questions or point me to good reference material I'd really appreciate it: 1. How does one setup the target/action mechanism for a custom control, i.e. client code can call setAction: and setTarget: and have these stored in the class? Does this come for free when you subclass NSActionCell? Or is it more correct to implement these methods yourself, in an NSView subclass? Or NSControl subclass? 2. Is wrapping existing controls in a custom control class a good idea? I.e. the custom control class is a container for a handful of standard controls, configures them in an appropriate way, and presents an interface to client code as if it were a single control, i.e. a target-action mechanism, and public properties for querying the state of the control? My (current) higher level goal is implementing a control that includes 3 momentary buttons, the middle button showing a menu when pressed. These buttons all edit one piece of data, a ratio. This control needs to be invoked (i.e. added to parent view) from code and be reusable. The client code needs to be informed when a button is clicked and be able to query the control's current value. The new control is responsible for the appearance, and the contents of the menu. In future I will also need to implement more complex custom controls/ views, that include custom drawing and a handful of subcontrols (that are all related and present a unified interface to client code). I've noticed that NSSegmentedControl can implement pretty much all of the control, so I think I want to use that internally, implementing all the config for the segmented control, and mapping the actions of the individual buttons to set the data in the control and invoke the custom action (that the client code, the target receives). Is there a way to achieve this? Am I barking up the wrong tree? thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: guidelines/tutorial for implementing custom controls
Can anybody point me to some good tutorials/guides for implementing custom controls? Do you have some objection to the examples at developer.apple.com ? http://developer.apple.com/samplecode/Clock_Control/index.html http://developer.apple.com/samplecode/TrackBall/ http://developer.apple.com/samplecode/bMoviePalette/index.html There are some fun third party samples: http://www.sticksoftware.com/software/CircularSlider.html http://developer.snowmintcs.com/controls/smdoubleslider/index.html http://www.stepwise.com/Articles/Technical/NSCell.html See also Omni Group http://www.omnigroup.com/developer/ There are some custom controls in the DrawDemo for DrawKit http://apptree.net/drawkit.htm Thanks for the links, of those I had only consulted Clock_Control, which seemed too out of date to bother with (it was a .pbproj). I'll have a look at the other links, thanks. 1. How does one setup the target/action mechanism for a custom control, i.e. client code can call setAction: and setTarget: and have these stored in the class? ... Subclasses of NSControl already have target/action support and can be connected via Interface Builder. You can also use NSActionCell without NSControl but won't automatically get Interface Builder interaction. Target action is also easy to implement on your own via NSApplication's - (BOOL)sendAction:(SEL)anAction to:(id)aTarget from:(id)sender method. I wasn't able to get it to work (from code, not from IB, the targetaction connection has to be made from code for my situation); when I called setTarget and setAction in the client code on an instance of my NSControl subclass, and queried the target and action, they were nil/nullselector. I did work out how to solve this though: implement (override) +cellClass for my custom control class, and return NSActionCell. Then I get target-action for free. This made sense, and indicated I did learn something when reading the docs :) 2. Is wrapping existing controls in a custom control class a good idea? I guess that would work. Why would you want to do that ? Well, because it seems that it may be a convenient and standard approach - is it? Or is it flawed and doomed to failure? Or just inelegant? My (current) higher level goal is implementing a control that includes 3 momentary buttons, the middle button showing a menu when pressed. ... I don't think you need a custom control to meet any of your goals. Just embed your buttons etc. in a convenient parent view and provide suitable Controller logic (ref: Model View Controller). You can save your embedded views in their own interface builder nib file for reuse or even add your pre-configured group of objects to Interface Builder's library. See Adding Modified Objects Back to the Library In Interface Builder's help. You will need to subclass NSView or one of its existing subclasses when you want custom drawing unless you use CALayer's instead.\ This is a valid point - that I am actually implementing a custom view rather than control. I may in future take this approach for more complex controls/views, but from code rather than in IB (these controls/views are instantiated from cross-platform code). I've noticed that NSSegmentedControl can implement pretty much all of the control, so I think I want to use that internally, implementing all the config for the segmented control, and mapping the actions of the individual buttons to set the data in the control and invoke the custom action (that the client code, the target receives). Is there a way to achieve this? Am I barking up the wrong tree? I think what you are suggesting is workable. Have you tried it ? Yep, it was perfect, except for the fact that the appearance I needed was 10.5+ (I need to support 10.4+), and I didn't have a solution for abstracting away the actions for the menu and buttons so the client just saw a unified value has changed type action. What I am looking at now, and it seems appropriate and workable, is subclassing NSControl, setting my class' cellClass to NSActionCell, instantiating and configuring NSButtons, the menu etc appropriately and handling their actions internally, dispatching the custom control's action when appropriate so the client code is notified. I'm still pondering whether I should be instantiating NSButtons, or NSButtonCells in the NSControl subclass, and if I should be splitting some of that logic into an NSActionCell subclass, but I guess until I have a reason to do so there's no need... I guess what I'm looking for is a when to subclass NSView vs. NSControl vs. NSCell guide, it seems there must be some rules of thumb. I.e. NSView = if you need to draw. NSControl = when you need target/action (remember to implement +cellClass:). NSCell = when you need to reuse your control draw etc logic for NSMatrix, table view etc. And then how to correctly set up the link with your NSControl and NSCell. And
Re: how to correctly set knob/thumb proportion and scroller orientation in NSScroller
Aha, that makes sense, pity it's not in the documentation I was referring to: http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSScroller_Class/Reference/Reference.html#/ /apple_ref/doc/uid/2340-1956 I'll fill in the feedback. (alas, I'll have to have a little compatibility method since we're still supporting 10.4). I have to use NSScroller directly because I'm porting existing (foreign platform XX) view code to work in an NSView, and it manages scrollbars itself (for good reason). Anyone have any comments on the orientation issue? I'll mention that in my documentation feedback... thanks for the info Rua HM. On Jul 24, 2008, at 4:29 PM, Graham Cox wrote: There is, in 10.5, setKnobProportion: to make up for the deprecated method. Is there some reason why you just don't embed a view inside an NSScrollView? It's much easier than trying to fiddle about with scrollbars yourself. Graham On 24 Jul 2008, at 2:15 pm, Rua Haszard Morris wrote: I'm implementing a scrollable pane and have come across to slightly weird issues with NSScroller, leading to me wondering whether I'm going about this the wrong way... 1. The thumb proportion can only be set by setFloatValue:knobProportion: method which is deprecated in 10.5. Is there any supported, non deprecated way to achieve this? 2. There is no direct way to set the orientation of the scroller - as far as I know, I have to specify an indicative frame rectangle in initWithFrame:, and NSScroller infers whether it is vertical or horizontal from that. I'm not aware of a way to specify orientation other than init. At the moment things are working well, but I'd be interested to hear if I'm missing the point here or if there are more appropriate ways to achieve the above. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
how to correctly set knob/thumb proportion and scroller orientation in NSScroller
I'm implementing a scrollable pane and have come across to slightly weird issues with NSScroller, leading to me wondering whether I'm going about this the wrong way... 1. The thumb proportion can only be set by setFloatValue:knobProportion: method which is deprecated in 10.5. Is there any supported, non deprecated way to achieve this? 2. There is no direct way to set the orientation of the scroller - as far as I know, I have to specify an indicative frame rectangle in initWithFrame:, and NSScroller infers whether it is vertical or horizontal from that. I'm not aware of a way to specify orientation other than init. At the moment things are working well, but I'd be interested to hear if I'm missing the point here or if there are more appropriate ways to achieve the above. Thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: how to prevent baseline shift when using NSSuperscriptAttributeName on a NSTextView's NSAttributedString ?
I need to support arbitrary superscript, not just squared... I should be clear: - I initially only set superscript attribute for the characters that are superscript, i.e. part of a larger string. - When this attributed string was given to an NSTextField (static non editable), the textfield draws it with the baseline offset downward, so the text looks incorrectly aligned alongside a neighbouring text field. - So, I experimented with setting NSBaselineOffsetAttributeName for the entire string to correct the problem (as I don't want to get into font and individual offset calculations unless I have to). What I discovered was that baseline offset has three effects: above, at or below normal position, corresponding negative, zero, or positive values, which seems to conflict with the documentation. However, setting a negative value fixes my issue, so I'm happy, if a little concerned. Note I just checked what happens if I set NSBaselineOffsetAttributeName and don't set NSSuperscriptAttributeName; it has no effect no matter what the value is... Thanks for the info Rua HM. On Jul 23, 2008, at 4:43 AM, Ross Carter wrote: The strange thing is that there only seem to be 3 baseline positions supported by NSTextField; any positive value, 0, and any negative value. I assume you've seen this, from http://developer.apple.com/documentation/Cocoa/Conceptual/AttributedStrings/Articles/standardAttributes.html#/ /apple_ref/doc/uid/TP40004903 The superscript attribute indicates an abstract level for both super- and subscripts. The user of the attributed string can interpret this as desired, adjusting the baseline by the same or a different amount for each level, changing the font size, or both. Are you perhaps setting a baseline attribute _and_ a superscript attribute? It sounds like the Cocoa text system is adjusting the baseline according to its notion of superscripts and ignoring your baseline attribute value. Personally, I don't think NSSuperscriptAttributeName is particularly useful. I just adjust the baseline and font size: newFontSize = oldFontSize * 0.75, baseline for superscript += 0.4 * oldFontSize, baseline for subscript -= 0.3 * oldFontSize. If the only thing you need to draw is a superscript 2, I like Andrew's solution. Ross ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
NSBaselineOffsetAttributeName support in NSTextField - bug? Re: how to prevent baseline shift when using NSSuperscriptAttributeName on a NSTextView's NSAttributedString ?
Update: If I set the superscript attribute for the exponent, and set a negative value (any negative value), the baseline is appropriate (i.e. lines up with surrounding controls). The strange thing is that there only seem to be 3 baseline positions supported by NSTextField; any positive value, 0, and any negative value. Is this correct behaviour? The documentation for NSBaselineOffsetAttribute name states that: The baseline offset attribute is a literal distance, in pixels, by which the characters should be shifted above the baseline (for positive offsets) or below (for negative offsets). http://developer.apple.com/documentation/Cocoa/Conceptual/AttributedStrings/Articles/standardAttributes.html#/ /apple_ref/doc/uid/TP40004903 I like the fact that I can specify a negative number and it appears to correctly account for my superscript exponent, but I'm concerned that the value may actually be used in future, and/or there is some complicated interaction between the attributes. Is there documentation on NSTextField's support for attributed strings that explains why this is happening? Or should I report this as a bug? Can anyone shed any light on why this is happening? thanks Rua HM. On Jul 21, 2008, at 4:27 PM, Rua Haszard Morris wrote: I am using NSSuperscriptAttributeName to make part of a string displayed in an NSTextView label display as superscript (to show to the power of 2). I may also use a smaller font attribute to make the 2 char smaller. My problem is that thebaseline of the text drawn in the NSTextView is moved down (presumably to accommodate the superscript 2) and the label now looks wrong as the text doesn't line up with the other edits and labels on the line in the dialog. Is there a correct, standard way to keep the baseline fixed when using an NSAttributedString in a NSTextView used as a label? I've tried using a multi-line NSTextView, but this makes no difference. There is the possibility of tweaking the NSBaselineAttribute, or even the position of the NSTextView, but both approaches seem hacky or overkill (i.e. I'd need to correctly determine the baseline offset by querying the font superscript offset? and converting to pixels?) thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/r.haszardmorris%40adinstruments.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
how to prevent baseline shift when using NSSuperscriptAttributeName on a NSTextView's NSAttributedString ?
I am using NSSuperscriptAttributeName to make part of a string displayed in an NSTextView label display as superscript (to show to the power of 2). I may also use a smaller font attribute to make the 2 char smaller. My problem is that thebaseline of the text drawn in the NSTextView is moved down (presumably to accommodate the superscript 2) and the label now looks wrong as the text doesn't line up with the other edits and labels on the line in the dialog. Is there a correct, standard way to keep the baseline fixed when using an NSAttributedString in a NSTextView used as a label? I've tried using a multi-line NSTextView, but this makes no difference. There is the possibility of tweaking the NSBaselineAttribute, or even the position of the NSTextView, but both approaches seem hacky or overkill (i.e. I'd need to correctly determine the baseline offset by querying the font superscript offset? and converting to pixels?) thanks Rua HM. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
I don't believe Peter Duniho's barking up the wrong tree - he sees room for improvement, and wants to discuss what to do to make it happen. I.e. he appears to care about making the platform better (probably something we all share)... These are the main valid issues from my point of view: 1 Apple's docs, particularly in relation to Objective-C Cocoa, have some room for improvement: - e.g. navigation (can't go back to list of methods after clicking a method name hyperlink for example) - lack of and generally un-useful sample code - too much cocoa is wonderful vs. not enough dry detail 2 Cocoa requires you when learning to implement things by clicking and dragging, which makes learning harder for some people (this is a real annoyance to me, why can we not see/edit these connections in a text file? why is there so much other crap in the nib xml? etc). 3 There's a belief (among) that Cocoa is in some way special and these documentation (or more general) shortcomings/issues are not relevant or real or justified. So, ignoring my usual cynicism (I don't believe there's much that us developers can do to contribute to improving the documentation, or the fact that dragging connections is necessary, though I do submit feedback when I see a clearly-fixable issue), I think it is very valid to raise such issues and discuss them on the mailing list. thanks for a very interesting and enlightening discussion Rua HM. On May 22, 2008, at 5:30 AM, Peter Duniho wrote: On May 21, 2008, at 1:42 AM, Hamish Allan wrote: I'm getting lost as to whether your main objection is about Apple not providing anything other than Objective-C / Cocoa to develop apps on the Mac, or whether it's just that you think their documentation could be improved. Sorry, that's fair. I have a number of concerns, and I admit that I tend to hop around a little (we have one subject description but really several side-topics related to it). As far as your question goes, the answer is neither. And both. My _main_ objection is how newcomers to Mac development are treated. Please, when someone new to the current Mac development environment brings up one or more of these points, don't say well, you're too inexperienced to see why [Obj-C|Cocoa|the documentation| the tools] is/are so great. Don't say you're riff-raff, it's supposed to be hard, we _like_ that it's keeping you out. Don't say you must not have read the conceptual guides, otherwise all this would be clear. Or any of the other condescending, presumptuous things that I've seen said on a semi-regular basis. The fact is, any of those _might_ be true with respect to a specific person. But they aren't necessarily so, and whether it is true or not, it's counter-productive. Instead, say something like your complaint is a common one, you aren't alone, and [most importantly] it's legitimate to have these concerns, acknowledging that even if someone's concern is somewhat irrelevant (being regarding a fundamental design aspect of the language or framework, for example), it does color their perception and affect how they approach the development environment. And then move directly to offering specific and constructive help with specific problems. If someone has failed to state their own concerns or problems in a way that allows for this kind of specific, constructive help, just ask questions that will elicit the kind of details that would allow for that. There are in fact specific things about the development environment that I think can be improved, and I'd start with the documentation. Would making an authoritative text like Hillegaas's book available free online be welcome? Sure. But ultimately, some thought needs to be put into how to make the regular documentation better. More code samples (if not embedded itself, then at least with prominent links embedded within the relevant topic), links to relevant guides where Cocoa concepts are referenced but not defined, fleshing out of specific techniques, and most importantly: keeping the information up-to-date (don't tell me to use a tool that's not even included with the development environment any more, and make sure tool- specific documentation refers to the version of the tool that is current). But mainly treating people's own impressions and feelings with more respect would go a long way. I recognize that this isn't something most programmers are naturally good at, but inasmuch as the Mac is _supposed_ to be the more human platform, IMHO it makes sense that the developer community could stand to observe the more human aspects of interpersonal communication. And by the way, as far as the shareholder part of your reply goes: I don't hold Apple stock directly. But everyone who relies on Apple's hardware and software as part of their business, or has any vested interest in the success of the Mac, is in
Re: Cocoa et al as HCI usability problem
2 Cocoa requires you when learning to implement things by clicking and dragging, which makes learning harder for some people (this is a real annoyance to me, why can we not see/edit these connections in a text file? why is there so much other crap in the nib xml? etc). The fact that you have an XML version of the NIB is ancillary; it does not exist to support editing by hand. It's there so that version control systems which choke on binary files can handle NIBs better. You're right that Cocoa -- or, more specifically, AppKit -- requires you to click-and-drag a lot of things when developing. But why is seeing it all in a text file superior? I fail to see how it's anything but *inferior*, because you're not writing code when you're doing the clicky-draggy-line-drawy part of AppKit development. This is a very fundamental stumbling block for a lot of people who are used to developing on other platforms, but it's really one of those things you have to take on faith and just understand this is not your previous environment. But there is no clear specific conceptual reason (that I know of) why a list of these connections could not be made more user-editable. What's more, this makes documenting simple code examples much harder, as the drags all need to be documented in a necessarily less-rigourous way (and possibly compounded by IB changing over the years). On a related note, it's been said (I'm paraphrasing) that the dragging connections is doing really cool useful stuff under the hood for me; I'm guessing that after reading all the conceptual docs and some more detailed info I might understand how to do it in code... but why is there such a disconnect between the textual and graphical approaches? But have no fear, I'm loving developing using Cocoa :) - I just can't stand by and not add my agreement on the room for improvement and support different development approaches issues. I don't claim that text is superior for everyone - but for me it is of value. PS what's inferior about writing code? (I am curious as to whether dragging connections is an accessibility for blind Cocoa developers ...) All I can say about this topic is that I ran into brick wall after brick wall when learning Cocoa until one day when everything just clicked. And can you be 100% certain that there is no possible way of improving the docs or development environment that would have eased this process or you? In this I am an optimist - I think that there are ways the documentation and development system as a whole could be improved (without compromising or shortcutting important conceptual issues) to allow Cocoa development to be easier to get into and do. And I don't think that would be a bad thing for the Mac platform as a whole.. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Cocoa et al as HCI usability problem
With you 100% on all this below. Been having trouble coming up with something useful to add to all these discussions about Cocoa Apple Developer Documentation .. what you said below sums a lot of it up. These points really resonate for me: ++ explaining why _their_ API and paradigm is superior ++ but what about the kinds of things the other 98% of the programming world wants to do? I try to submit documentation feedback when I can... cheers list On May 19, 2008, at 5:03 PM, Peter Duniho wrote: From: ben syverson [EMAIL PROTECTED] This is going to sound bitchy, but it's hard for me to have any sympathy for vague complaints about the docs or the usability of Cocoa. That does sound bitchy. I mean, it's fair enough to say that people ought to be providing specific feedback and constructive complaints. But to have _no_ sympathy? That's harsh. Real people are having real problems getting into Cocoa. I don't see the kind of repeated commentary about poor documentation and difficult APIs in the C#/.NET forums or Java forums. It comes up once in a blue moon, but not with the reliability I've seen here, nor is there nearly the kind of practiced, organized defense seen here (which again suggests a certain regularity to the complaints). I had a big long reply (even longer than this one :) ) written to Julius's initial post under this subject and detailing many of my concerns and complaints about Objective-C, Cocoa, and the documentation, but decided the better of posting it. However, I'll say this: I agree that at least for me, the fundamental issue is that from a usability point of view, Objective-C, Cocoa, and the associated documentation leave something to be desired. I found Julius's comments regarding usability to be right on the mark, at least in the general sense. There's no question in my mind that Cocoa is a nice framework, and that the entire environment provides some good productivity- enhancing features. But it's also clear that those benefits are only really available to someone who has already invested a lot of effort in learning it. The rule of least surprise doesn't apply; maybe it does to the framework, but not to the documentation and definitely not to the tools. I contrast that with my experiences moving to C#/.NET and Java from the Win32 C++ world. Now, at least with .NET it is true that to some extent, I benefitted from having a fair amount of Win32 expertise. Some of the paradigms map closely, and that helped. But there's a lot in .NET that is entirely new, and that was easy and fun too. And Java was completely foreign to me when I started using it. In neither case did I find myself feeling like I'd just entered a whole new world where, until you had gone through the entire hazing process, one could never really be effective as a programmer. .NET and Java were _fun_. They are still fun. I love writing code for either platform. I ported one simple .NET application to Cocoa and haven't had any interest in writing any more Cocoa code at all. I'd love to see the Mac succeed as a platform. But frankly, I think you already have to be a pretty hard-core Mac fan, and _really_ want to see your software on the Mac, to be motivated to spend a lot of time with Cocoa. Until programming in Cocoa is fun for _everyone_, not just the few who have made it through the gauntlet, I don't see it attracting a large following. Those who love the Mac, and who love Cocoa, ignore this kind of feedback, provided to them on a regular basis, at their peril. [...] But I can't think of a single time when I've been unable to figure out where to look for guidance on a problem, or have been unable to interpret that guidance. For what it's worth, it's not (to me) a matter of not being able to figure it out at all. It's how much effort is required to figure it out. MSDN is sprinkled with code samples. Everywhere. Granted, some of them are kind of silly, and some of them are just plain wrong. But on the whole, they are pretty good. More to the point, they exist for pretty much _every_ documented API element. Class methods, properties, events, fields. All have a dedicated doc page that includes some sample code (in many cases, a single sample is shared among multiple elements...but that's just efficient doc writing). Contrast to the Cocoa docs, where a single class is documented in just one web page, with practically no sample code at all and incredibly brief descriptions of each element. Oddly enough, the same complaint can be made for Sun's docs for Java, but I haven't found that to be nearly as great a degree of a problem there. It's hard for me to put my finger on exactly what the difference is, but I'd guess that at least partly it has to do with the fact that Sun's docs include frames with navigation panes that help orient you within the API, so that
setting target and action for a NSSlider programmatically in a class that is not file's owner - how?
I'm trying to set the action for an NSSlider in a little helper class
that is not the file's owner class associated with the window in the
nib. At runtime, I get these console messages:
*** +[SliderHelper myAction:]: unrecognized selector sent to class
0xeb74380
HIToolbox: ignoring exception '*** +[SliderHelper myAction:]:
unrecognized selector sent to class 0xeb74380' that raised inside
Carbon event dispatch
This is how I'm setting this up:
- there's an NSObject subclass (call it MyDialog) containing
IBOutlets for all the controls I care about.
- there's another NSObject subclass (call it SliderHelper) which is
intended to automate some behaviour common to a few controls in the
dialog (and other dialogs in future)
- MyDialog instantiates a SliderHelper and passes it an NSSlider*
outlet referring to a slider
- SliderHelper sets up the target and action for the slider
programmatically in an +initWithSlider: method..
+(id) initTestSlider:(NSSlider*)aSlider {
SliderHelper* newOne = [[SliderHelper alloc] init];
[newOne setSlider:aSlider];
[[newOne slider] setTarget:self];
[[newOne slider] setAction:@selector(myAction:)];
return newOne;
}
- myAction: is a void returning method with no params, and it is
implemented!
How can I make this work?
Note that if I set the target and action from MyDialog (with a
MyDialog -myAction of course) it works, what am I missing here?
thanks
Rua HM.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
