When I use iBooks on Mac, and highlight a word with a mouse, English Thesaurus is shown:
I'd like my program to do similar thing - to appear like this Thesaurus in iBooks. How can it be reached?
The simplest idea is recognizing that some text is selected, but maybe iBooks has some API (nothing useful at https://developer.apple.com/ibooks/). Or maybe Mac OS has event "single word selected", and I can subscribe for it.
What kind of app is best suited for that: Cocoa App or some extension/plugin?
I'm not interested in "long way" (context menu):
Any advices will be highly appreciated, because I don't know anything about that.:)
What I think you are looking for is NSView's showDefinitionForAttributedString:atPoint: method or one of its siblings. HTH
Related
I suppose everyone has used these, but I don't know how they are called, so I couldn't really search for them. Their behaviour is as follows: one can click on "first" or "last" or anything in between to navigate to a certain page.
Does anyone know if there exists some kind of QWidget which does that? Maybe similar to a combo-box where one can select something and a signal with the selected index is emitted?
Any hints would be much appreciated.
Thank you for your time david
The short answer is no, QT does not provide a widget with the capabilities you are looking for. It should be relatively simple to recreate using QButtonGroup and a styled set ofQPushButtons or re-implemented QABstractPushButtons.
Title pretty much says it all. I'd have thought it would be a pretty simple matter, but searching the web for AppleScript and Automator-based solutions has come up empty. Does anyone know how to achieve this?
Thanks!
I want to know how to do something like Adium does, where when you type more text than the field can handle it expands into a new line. Like this:
Either how can I do this, or where in the Adium source code can I find this?
The view in Adium is AIMessageEntryTextView, plus its superclasses AISendingTextView and AITextViewWithPlaceholder, and the actual resizing (as opposed to figuring out the right size as a hypothetical ideal) is done by AIMessageViewController in response to AIViewDesiredSizeDidChangeNotification.
Do note that Adium is licensed under GPLv2, so unless you intend to use the same license when releasing your own project, you can't lift any of Adium's code for this purpose.
I am not exactly sure what Adium itself does there.
But I am pretty sure that you could just use NSTextView.
You can find it at the Apple Developer website.
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSTextView_Class/Reference/Reference.html
Furthermore this Tech note for using NSTextField, if anyone wants to do the extra work. ;-)
http://developer.apple.com/library/mac/#qa/qa1454/_index.html
Let's say you're creating a game for Mac OS X. In fact, let's say you're creating Quake, only it's 2011 and you'd prefer to only use modern, non-deprecated frameworks.
You want your game to be notified when the user presses (or releases) a key, any key, on the keyboard. This includes modifer keys, like shift and control. Edited to add: Also, you want to know if the left or right version of a modifier key was pressed.
You also want your game to have a config screen, where the user can inspect and modify the keyboard config. It should contain things like:
Move forward: W
Jump: SPACE
Fire: LCTRL
What do you do? I've been trying to find a good answer to this for a day or so now, but haven't succeeded.
This is what I've came up with:
Subclass NSResponder, implement keyUp: and keyDown:, like in this answer. A problem with this approach, is that keyUp: and keyDown: won't get called when the user presses only a modifier key. To work around that, you can implement flagsChanged:, but that feels like a hack.
Use a Quartz Event Tap. This only works if the app runs as root, or the user has enabled access for assistive devices. Also, modifier key events still do not count as regular key events.
Use the HIToolbox. There is virtually no mention at all of it in the 10.6 developer docs. It appears to be very, very deprecated.
So, what's the proper way to do this? This really feels like a problem that should have a well-known, well-documented solution. It's not like games are incredibly niche.
As others have said, there’s nothing wrong with using -flagsChanged:. There is another option: use the IOKit HID API. You should be using this anyway for joystick/gamepad input, and arguably mouse input; it may or may not be convenient for keyboard input too, depending on what you’re doing.
This looks promising:
+[ NSEvent addLocalMonitorForEventsMatchingMask:handler: ]
Seems to be new in 10.6 and sounds just like what you're looking for. More here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/Reference/Reference.html%23//apple_ref/occ/clm/NSEvent/addLocalMonitorForEventsMatchingMask:handler:
I'm new to Objective-C, Cocoa, Xcode and Interface Builder. I've got some C background in the past, as well as a fair amount of RealBASIC experience.
I'm working through Mark and LaMarche's iPhone 3 Dev book and I'm really just sort of stunned about how tedious some things are. Maybe someone can shed some light on this for me. My question really is, why does the process for seemingly simple actions involve such a complicated number of steps? Is there a benefit to the complexity which I'll come to love later? Or is it just a brute fact that is unavoidable?
For example, in RealBASIC, if I want a slider's value displayed in a text box, I simply add:
myTextBox.text = mySlider.value
to the slider's Changed event. I can program this in well under 1 minute.
In Xcode/Interface Builder, I have to physically type a declaration for both the text box and the slider, then type a property/outlet declaration for each as well, then create a method declaration and implementation for the ValueChanged even, then set up a (relatively) complicated typecast of the slider's integer value into an NSString using initWithFormat. I then have to return to Interface Builder to link up the controls with the control and method outlets I typed in. I don't see how this can be done in much less than 10 minutes. Maybe 5.
So, what's the benefit of this? Why doesn't Interface Builder automatically create, or at least suggest, control declarations and #property statements, as well as method declarations and implementations? Why can't double-clicking a slider in IB offer you a list of events and offer to automatically insert a skeleton method into your .h and .m file? And why does IB even have to be a separate application?
I'm willing to accept that some of this is my unfamiliarity with all things Xcode, but is this really as efficient as the development environment can be?
My apologies if this is a dead-horse, flame-bait topic with opposing sides on full aggro. If so, please just say "yes, that it is" and move on.
Thanks,
-Rob
A lot of the reasons behind the way IB works will become more clear as you get used to the MVC paradigm.
Once you start using Cocoa Bindings, which update your model when the UI changes and vice versa, you should see an enormous productivity improvement.
I too used to think that Xcode and Interface Builder were unnecessarily complicated, until I worked through a book on both (specifically, Beginning iPhone Development: Exploring the iPhone SDK).
If you're serious about working with Xcode and Interface Builder and are as confused as I was when I started, I highly recommend picking up a book like the one I used. Granted, that was for iPhone development, but I think there is another book by the same publisher (or author) that is straight Mac programming.
Once you work through it and understand what is going on behind the scenes it starts to make a lot more sense. In some ways I prefer IB to things like Expression Blend or XAML for WPF programming in .NET.
Give a book a try and see if it helps :-)
Good luck!