Carbon vs. Cocoa

Hey all,
This question has been asked over and over again but I still couldn't come to any reasonable conclusion with it.
I guess the decision should be based on that is it exactly I need.
Well, the main idea is to create several "heavy lifting" class libraries (not related to UI of the application) that will be reused in the application(s). And it is important that these libraries will be easily portable to other planform later on.
What would be a suggestion in this case?
Another question: is there any good documentation and/or examples for ow to create class libraries?
Thanks.

ShurikA wrote:
May be I didn't ask the right thing.
The intention is to create libraries that won't use Cocoa or Carbon at all. And these will be shared and potentially ported to other platforms.
Then just write them in C. There are some good libraries written in C.
But, I will need to create at least minimal UI for testing; and, here Cocoa or Carbon will come into the play.
Really? You can write some nice unit test driver and run them from the command line.
But still, the question is, what is easier and faster to learn ?
I guess I don't understand the question. If you are going to write portables libraries you won't need either. If you just want to write some unit test drivers, those should be done using the command line because they can be easily automated. If you still want to write a user interface, Cocoa will be much easier.

Similar Messages

  • Carbon and Cocoa Integration

    I have read the Cocoa-Carbon Integration Guide several times, but still have one unanswered question. The guide explains how to call Carbon Functions in a Cocoa Objective-C Class File. However, does this also apply to data types? I made the logical connection that it would be hard to call carbon functions without carbon data types, but i don't know if they have to be called in a special way of if a prefix needs to be added to the data types before they can be used. Could someone explain or elaborate on how to use Carbon in Cocoa Classes?
    thx

    Orangekay is right. You can learn it, but don't be in a hurry. If you are familiar with object-oriented Javascript, you should be able to figure it out. Cocoa is a pure object-oriented library where you send messages to receivers.
    [receiver message: argument]
    Carbon is also an object-oriented library, but it is written in C. In Carbon, you would do the above as:
    message(receiver, argument)
    Javascript looks closer to Java or C++ syntax-wise than either Cocoa or Carbon. For an example, compare the interfaces of CFString with NSString. They do the same things and are, in fact, the same objects using Carbon and Cocoa interfaces, respectively.
    There are only a few objects that exist in both Carbon and Cocoa. Most things are either one or the other. Still, all Cocoa objects and methods will look similar. The same is true for Carbon.
    Unfortunately, there are some low level details, like memory management, that you don't have to deal with in Javascript. You may have to step back and work on some simple C or Cocoa projects just to learn before you can apply that to something real.

  • Carbon in Cocoa Crashing: EXC_BAD_ACCESS after NSAutoreleasePool is released

    I'm developing a Cocoa user interface for a Photoshop CS3 plugin using Bindings. (Carbon in Cocoa, since PS is a Carbon app) I'm getting a EXC_BAD_ACCESS error when I close my modal NSWindowand the NSAutoreleasePool releases.
    I've spent hours now with Instruments trying to figure out which object might be getting released early (or double released) and cannot find it.
    Now my thoughts are that maybe there is something I'm missing about running a modal window within an NSAutoreleasePool while using Cocoa Bindings. Like maybe there is something I'm supposed to do before closing the window to "finalize" all the bindings to prevent them from sending messages to released objects.
    Here is a basic code example of what I'm doing:
    NSAutoreleasePool *localPool = [[NSAutoreleasePool alloc] init];   
    NSApplicationLoad();
    ExportWindowController *controller = [[ExportWindowController alloc] initWithWindowNibName:EXPORT_CONTROLLER_NIB_NAME];
    [controller showWindow:nil];
    [NSApp runModalForWindow:[controller window]];
    [controller close];
    [controller release];
    [localPool release];
    The modal window is closed by a call to:
    [NSApp stopModal];
    Here is a stack trace:
    #0  0x97793869 in _cache_getMethod
    #1  0x9779c6da in lookUpMethod
    #2  0x97793da7 in _class_lookupMethodAndLoadCache
    #3  0x97793953 in objc_msgSend
    #4  0x96501151 in -[NSBinder releaseConnectionWithSynchronizePeerBinders:]
    #5  0x96a10390 in -[NSValueBinder releaseConnectionWithSynchronizePeerBinders:]
    #6  0x963ac895 in -[NSObject(_NSBindingAdaptorAccess) _releaseBindingAdaptor]
    #7  0x964062f5 in -[NSView _releaseBindingAdaptor]
    #8  0x96405784 in -[NSView _finalizeWithReferenceCounting]
    #9  0x96404e2f in -[NSView dealloc]
    #10 0x964ef163 in -[NSControl dealloc]
    #11 0x9099a9d8 in CFRelease
    #12 0x909c75bd in _CFAutoreleasePoolPop
    .... more
    Turning on NSZombieEnabled did not turn up any double-released objects (although there was 1 from Photoshop itself)
    Any ideas?

    not using bindings seems to have fixed it, but if any of you have insights as to why this would be crashing with Bindings, I'd appreciate it.
    Thanks

  • Eclipse, carbon or cocoa (and 32 or 64 bit)

    So I am getting back into programming. My schooling was in programming (C mostly), but obviously it's been some time since I've really had my hands in it. I wanted to use Eclipse, since I have that on my laptop (Linux) and would like to keep things as universal between my Mac and that. Anyway, was going to go download the stuff I needed for the Mac, and I see the options include Carbon, and 32 or 64 bit Cocoa. I'm thinking the way to go is 32 bit Cocoa, is there any reason I'd want carbon or 64 bit cocoa?

    jpeery wrote:
    I wanted to use Eclipse, since I have that on my laptop (Linux) and would like to keep things as universal between my Mac and that.
    You are free to use what you want, but you would have to be a masochist to choose Eclipse over Xcode.
    Anyway, was going to go download the stuff I needed for the Mac, and I see the options include Carbon, and 32 or 64 bit Cocoa. I'm thinking the way to go is 32 bit Cocoa, is there any reason I'd want carbon or 64 bit cocoa?
    All you need is Xcode. You don't have to download it as it comes on the Snow Leopard DVD. Do not mess with any of those options. Install all of it. You aren't on Linux anymore.
    Carbon is dead. There is no need to worry about flame wars. The war is over. That being said, you still need it. Install all of Xcode. You need both 32 and 64 bit Cocoa. 64-bit is the native architecture for all current systems. 32-bit is still required for a few things and for compatibility's sake.

  • Adobe CC Illustrator is still Carbon, not Cocoa Native?

    Is this really true?
    And what effect is this having on performance?

    Yes, it's still Carbon, even in CC 2014. You can verify this with the application "UI Browser," it reports Illustrator versions up to and including CC2014 as "A carbon application package."
    It can't see any UI elements to address through UI scripting except for the menu bar. Which is a shame, since scripting and action support in Illustrator is terrible. Making it Carbon would at least allow UI scripting as a work around.
    Photoshop is the same, even CC 2014 still reports as a Carbon application, and the UI elements except for the menu bar are invisible to UI scripting. However, with Photoshop, most things you can do are addressable either directly by scripting the DOM, or if not, at least by targeting the Action Manager.
    Why very expensive professional apps do not use OSX's native API 15 years after it came out is a puzzler. I know there was a problem at first that Apple claimed that Carbon would be maintained beside Cocoa as a first-class API, then they unexpectedly jerked the rug out from under Adobe and deprecated Carbon. Still, that was 2007... Even MS Office Suite has been Cocoa for a good while. Carbon is officially deprecated, Adobe has to move off of it eventually.

  • Compiling a Carbon app w/library that supports Cocoa as well

    We are linking to a library that supports video rendering in both Cocoa and Carbon/AGL environments. I can compile and link with a Cocoa application. That works fine. I just had to include the Carbon and AGL frameworks. No problem.
    Where I am running into trouble is with our Carbon application. I have included the frameworks that are necessary for Cocoa to run (cocoa, foundataion, appkit, etc...). Here is where the trouble starts:
    The compiler is, of course, confused by the objective-c directives. Okay, so I go into the build settings and add "-x\ objective-c++" to the cflags. I compile again and it no longer complains about objective-c++, the compilation finishes fine. Now the linker complains:
    "File not found: /Developer/....path...../Debug/...projectName.build..../Objects-normal/i386/mai n.o"
    Sure enough there is no file, main.o, but there is a file, projName.LinkFileList.
    Why (even though the compiler output says that main.o exists) isn't main.o sticking around? Is there anything obvious that I am doing wrong?
    Excuse me if this is hazy. I'll clarify anything you ask.
    NOTE: I cannot change this static lib to use only Carbon OR Cocoa. It (only) supports both and (I think) must be linked to both frameworks.
    Thanks for reading.

    Why would the compiler be looking at Objective-C directives? It is one thing to link with a library that supports different languages. It is something else to #include headers from that other language. Do the Carbon headers have Cocoa in them? Are they not surrounded by macro guards?

  • Porting a cocoa app to carbon?

    I have a few cocoa apps that i would like to port to carbon because cocoa views are just not widely supported enough yet for that I am doing. I know this question is vague, but is this a "do it in a weekend" feat, or am I just going to end up beating my head against a wall? I just want general responses/tips/warning from anyone who has been in this same predicament. Also... if by some feat of magic there is a plugin or some way to automate or simplify this process... I am ALL ears!
    Thank you.

    etresoft wrote:
    You are worrying about serving an existing customer base that already has a set of legacy tools and is reluctant to change. Are they really your market?
    How long is it going to take you to develop your software? When your software is ready (using Carbon or Cocoa), what is your market going to look like then?
    It seems to me that the Carbon market is already established and reluctant to change. It is currently the largest market in this industry, but it is still the market of the past. It is only going to get smaller. All those tools aren't even sold anymore. You need to work on a product targeted at what the market is going to look like in the future.
    I understand. Thank you for listening to my ramblings and offering advice. I am not producing any product at the moment... just getting a feel for the market and the current and possible future stumbling blocks. I am trying to allow for backward compatibility without having to code everything twice (but it looks like that is unavoidable), like back in the pre OSX days of the 90's where you had to code a carbonized plugin, a legacy plugin and a 68k plugin because studios clung tenatiously to the $10,000 Mac Quadras they had purchased just a few years before (understandably so at that price). Apple sees things this way as well as is evidenced by Rosetta (currently) and the 68k emulator back in the MacOS days.
    As of right now, the way the market looks is that it is a carbon market since none of the major players like MOTU, Digidesign, Steinberg support/adequately-support cocoa views, and Digidesign's Pro Tools (which holds the lion's share of the market) is not even ported to Leopard yet... and I anticipate from experience issues and bugs with their cocoa implementation when it does happen, so i don't expect bug-free compliance immediately or even for a period after they are forced into cocoa when they all eventually go 64-bit native... which is likely a period of a year or more.
    That sort of compatibility would sidestep stigma as well. Many users don't care about cocoa/carbon, SSE/SSE3, or Aqua from their left foot. They just know that if they attempt to load up a plug in their DAW and the UI does nothing that obviously tour product is "broken".... and will slag you off online as such. I have seen it repeatedly in comments on various press releases: "don't buy this, I loaded it up and it didn't do anything". I lament the slow change in this particular nitch, but that is the way of it. I would love if overnight I could optimize for Intel/Leopard/64-bit/Cocoa, but as it is, we are in 10.5.2 and plugins have to be built against older SDKs and optimized for 10.3 deployment, PowerPC and Carbon to be completely compatible across the board.
    So maybe I am barking up the wrong tree. Instead of backporting my tools, maybe I should be focusing on a compatibility translator of sorts... maybe a carbon wrapper or something like that.
    Thank you for your help.

  • Carbon programming books? Should i bother?

    Hi all.
    Ive been developing in C++ for 3 years (non-mac platform) I have justed invested some cash into some Apple gear (for music and video production).
    I wish to port over and create C++ based applications for the Mac. Now, I've had a look at Cocoa, bought a basic guide to the programming language and to be honest, the syntax is very foreign to C++ (please don't get me wrong, Cocoa has excellent librarys, structures and visual interface) but i feel that im learning a new complete language, in which i dont have much time.
    Now, ive had a look at Carbon programming interface, i feel more at home using the Carbon syntax therefore have decieded to move to Carbon instead of Cocoa.
    Ive done a few search's but to be honest i cant find basic reading material. So therefore can anyone advise me on books, tutorials (online)?
    And one more thing, I keep my code up-to-date with the latest standards, meaning INTEL?
    As a i have a PowerMac (IBM), will the code have to be re-written to the Intel platform?
    Any advice would be great.
    Thanks in advance.

    Now, ive had a look at Carbon programming interface,
    i feel more at home using the Carbon syntax therefore
    have decieded to move to Carbon instead of Cocoa.
    Ive done a few search's but to be honest i cant find
    basic reading material. So therefore can anyone
    advise me on books, tutorials (online)?
    And one more thing, I keep my code up-to-date with
    the latest standards, meaning INTEL?
    As a i have a PowerMac (IBM), will the code have to
    be re-written to the Intel platform?
    Sadly, there have been no Carbon programming books published since 2002. Your best bet is to go to Mac Tech magazine's site (www.mactech.com). It has an electronic version of a Carbon programming book. The book is about 5 years old, and Carbon has undergone many changes since then, but there's not much else available.
    I think you'd be better off going with Cocoa. You can write the user interface in Cocoa and the rest of your code in C++. Learning Objective C takes less time than learning Carbon by wading through Apple's documentation and reading the Carbon header files.
    Carbon and Cocoa will run on both Intel and PowerPC Macs if you use Xcode 2.1 and above and build your program with the Universal SDK, which comes with the Xcode Tools. Reading data from files is the main area of your code you'll have to worry about due to the endian differences between Intel and PowerPC processors.
      Mac OS X (10.4)  

  • Pages is Carbon according to otool!

    Hi,
    I've heard much about iWork, being the Carbon-AppleWorks replacement. However, I tried it out recently, and it really felt like Cocoa, smooth and nice. Just for fun, I tried "otool -L path-to-pages" and discovered that it is indeed a Carbon application. Surprise. Does this mean that Carbon and Cocoa is as good as equal in these days? Becase I really can't tell from its interface!
    Any thoughts?

    Hi,
    I've heard much about iWork, being the
    Carbon-AppleWorks replacement. However, I tried it
    out recently, and it really felt like Cocoa, smooth
    and nice. Just for fun, I tried "otool -L
    path-to-pages" and discovered that it is indeed a
    Carbon application. Surprise. Does this mean that
    Carbon and Cocoa is as good as equal in these days?
    Becase I really can't tell from its interface!
    I can't see how you came to this conclusion.
    When I run otool against the Pages executable inside the bundle it tells me that it links against AppKit, a Cocoa only framework.
    Yes, it does link against the Carbon framework. But that doesn't mean much. Every Cocoa app uses Carbon. Cocoa uses the Carbon framework internally for things like menus. And there are still significant lower level features missing from Cocoa that are available in Carbon, causing Cocoa developers to use Carbon in their apps. Apple even have documentation explaining how developers can integrate Cocoa stuff into Carbon apps, and versa vica.
    Don't believe the myth that Cocoa apps are inherently better than Carbon apps. A Carbon app can be just as good as a Cocoa app. iTunes and the Finder are both good example of slick Carbon apps (even if you don't like the Finder's features). Cocoa apps are just easier to develop because the API and Objective-C are so much more productive than using plain C with the Carbon API.
    Dale

  • Frustrating lack of support for Mission Control / Spaces on Mac OS

    I'm posting this on the InDesign board, but this question applies equally to all apps in the Creative Suite.
    Is there any way to make InDesign/Creative Suite work properly with Spaces (a feature that has been around for years now)? It is incredibly frustrating to not be able to use this excellent organisational aid with any of the Adobe apps. There seems to be a whole mishmash of problems with it, from pallettes disappearing and moving to a different space to the document you are working on, to entire apps not being visible in Mission Control. Not to mention problems when trying to hide/unhide apps.
    When I'm working with any other apps on my system, I can take advantage of Mission Control, but have forego these advantages when using the Creative Suite. Isn't it really about time that Adobe put some effort into supporting these OS-level features. Whether you favour Mac OS or Windows, you should be able to take advantages of the system you prefer to work on.
    Is there any word on whether CS6 will support these features? (I'm not exactly holding my breath).
    Thanks.

    When I'm working with any other apps on my system, I can take advantage of Mission Control, but have forego these advantages when using the Creative Suite. Isn't it really about time that Adobe put some effort into supporting these OS-level features. Whether you favour Mac OS or Windows, you should be able to take advantages of the system you prefer to work on.
    Is there any word on whether CS6 will support these features? (I'm not exactly holding my breath).
    There is no word on anything about InDesign CS6 yet. (Those who know can't say, and I'm not aware of any substantive leaked information.)
    I think that Spaces/Mission Control support is probably predicated on the Carbon to Cocoa conversion. So until InDesign is a Cocoa app, this is unlikely to improve. Personally I manage to avoid using Spaces to any significant degree, so I don't really notice these things. Have you tried Photoshop, which is a Cocoa app? Does it behave better?
    I don't know to what extent these issues are specific to the app, or all tied up in libraries that are common to all the Adobe apps.

  • New SAVE AS Dialog Box "Feature"

    What's up with the new feature that changes the name of the file you're saving... or exporting... to the name of the file you click on in the Save or Export dialog box?
    It's a terrible feature that causes more problems.
    One mis-click and you're saving over a file that you accidently clicked on while moving to a folder to save that file.
    This feature doesn't make sense. How is it useful?
    Anyway to turn that feature off?

    " That's been available for years. It's in every OS I can remember using for around 10 years (including Windows)."
    I'm pretty sure that for Mac people, this renaming behaviour was introduced in 10.3, and I agree - it is idiotic because of its potential to be destructive. You do get presented with a dialogue asking if you really want to overwrite the existing file, but the default in many apps is to "Replace". What's worse is that, at least in "Panther", the trend was that the default was different depending on whether you were using a Carbon or Cocoa app so sometimes, hitting "Return" cancelled, while other times, it overwrote the file. So you had to be sure to read every dialogue carefully because of the absence of consistency, thereby reducing productivity.
    Even without overwriting the file, the "feature" is destructive in the sense that the filename that a user may have manually typed will be irrevocably wiped out by a single mouse click, and have to be retyped. The only app I have come across for which an "undo" is available is "SimpleText.app" (compiled from the source in XCode tools).
    Thanks to this new "feature", it takes more time and concentration to navigate the "Save" dialogue because there is no easy way to switch focus from the "Name" field to the browser field - it requires either multiple tabs, or various function keys, and using the mouse, one must be careful to aim for a folder, or whitespace if the file only contains a small number of items. You can't even click on the scroll bar or column headers - elements that are a part of the file browser portion - to switch the focus there.
    This is clearly an example of a feature being added without thinking things through. The reason the feature works in Windows or Linux, etc. is that they sort their file lists with folders always at the top of the list - if you always aim for the top item in the list, odds are you will hit a folder and won't accidentally rename the item. Since the Mac has always sorted files and folders together alphabetically (making keyboard selection easier), applying the click and rename behaviour is obviously going to cause problems, any time you have a large number of files sorting to the top of the list such that the first folder isn't immediately visible.
    All they had to do was introduce the feature where renaming happens with a modifier-click, and I would be thinking "wow, great feature". I think it's sad that we had to sacrifice the elegance of Mac OS in the transition to the stability and power of OS X, when with a little direction and enforcement of GUI guidelines, we could have had it all...
    Edit: Feedback here - they didn't listen in the Panther to Tiger transition, but one can always hope for Leopard...
    http://www.apple.com/macosx/feedback/

  • Creating .app folders in other operating systems?

    I'm working on a cross-platform game and am hoping to create an OS X port of it. I don't have access to a mac, and so am unable to use the xcode tool for creating .app folders. Are there any tools for creating .app folders on other operating systems? I'd prefer Linux, but can also use windows if required.
    Thanks
    Nathaniel

    Well, .app bundles are specific to Cocoa and Carbon applications... The closest way to make such applications is to use GNUStep (which is an open Cocoa) but it means to rebuild the whole app to make it work with Cocoa/GNUStep...
    However, application that are compatible with Mac OS X are not necessarily in .app bundles. Bundles are used for a specific purpose which gather files that the app should have really close, like its interface files (nib) that is used only with Cocoa or Carbon. If your app is neither Carbon nor Cocoa, there's no use in creating a .app bundle it doesn't even exist. And moreover, Xcode (or Project Builder on GNUStep) is the only app that creates .app bundles.

  • Where can I find a patch for Indesign and Acrobat cs6 for mac retina display?

    I have found the patch for screen resolution for photoshop, but the illustrator patch says it is not compatible and I cannot locate one for in-design (my primary program) or Acrobat. There must be a patch, right? Or else whats the point of it?

    The patch is upgrading to InDesign CC, which requires an Adobe Creative Cloud subscription. Sorry.
    There is no Acrobat CS6. The last version is Acrobat XI which was created too late to include support for Retina Display. It will probably be in the next version of Acrobat.
    Creating "patches" for Retina Display are much more engineering intensive than you would expect. In the case of InDesign, it had to be completed in the context of moving to becoming a 64 bit application and moving application development from Carbon to Cocoa (a required move on the Mac accomplished finally in InDesign CC).

  • PDPageDrawContentsToWindowEx takes too much time

    We are using an Acrobat plugin that renders the PDF file to a bitmap in memory.
    We are using Acrobat Professional X. But same problems also appear on Acrobat 9.
    We have received several problematic PDF files from our customers that is causing the call that renders the image -
    PDPageDrawContentsToWindowEx() to take unreasonably long time.
    My target resolutions is 600 dpi but I couldn't wait for the call to return, after more than 6 minutes I kill the process.
    The same PDFs render in Acrobat with slight delay (flickering and repainting) but in reasonable time.
    I have written for this problem on previous occasions (Aug 5 2010). Since then further problematic samples
    show that is linked somehow with transparency being present, but not on all PDFs with transparency.
    We have a fast computer so the problem is somewhere in the PDF analysis.
    Trying to optimize the file didn't help.
    Checking with Preflight for PDF syntax issues also didn't find anything.

    I'll have to check the headers, but I KNOW that we exposed it to plugins in A9 – it was necessary since we pulled the DrawToWindow call on the Mac (carbon vs. cocoa).
    What you are asking the SDK to do is going to be painful on large complex images.  Drawing into an HDC/Window adds SIGNIFICANT overhead to our rendering process, since we have to do all the work in our own "bit buffer" and then copy that buffer into the OS's provided HDC.  OUCH!  This is why  DrawToMemory is better.
    Additionally, if you have files with complex transparency AND you want OverprintPreview, that's also going to be VERY complex rendering pipeline – made WORSE by the need to end up in an HDC.   Forgetting separations for the moment, consider that we have to convert everything to CMYK (since you can only compute OP in CMYK), blend colors, then convert all of that to RGB.   And that's assuming SIMPLE transparency.  If you have multiple blending groups, soft masks, etc. then you just raised the bar even more!
    How long does it take Acrobat to open up the PDF and render it completely to screen?   For separations, how long does it take to do a "Flatten Transparency" operation?
    UpdateRect won't help because of the OP and then transparency flattening
    From: Adobe Forums <[email protected]<mailto:[email protected]>>
    Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
    Date: Mon, 5 Dec 2011 06:45:46 -0800
    To: Leonard Rosenthol <[email protected]<mailto:[email protected]>>
    Subject: PDPageDrawContentsToWindowEx takes too much time
    Re: PDPageDrawContentsToWindowEx takes too much time
    created by Nikolay Tasev<http://forums.adobe.com/people/Nikolay+Tasev> in Acrobat SDK - View the full discussion<http://forums.adobe.com/message/4064198#4064198

  • Create a keyboard like the japanese one?

    hi everybody!
    I am a linguist and I am working with a quite odd system of writing, I have created a special font and now I would need a keyboard to write it.
    The input method should be similar to the method to write hiragana/kanji, that is one write the phonetic spelling, and the computer offer a series of ideographic (taken from a dictionary, I think) match among which the user can choose the right form.
    Ok, I have already created such an application with realbasic, but it would be nice if it were possible to put it in the top in the form of a standard keyboard..
    is it possible to do somethink like that?
    that is, it is possible to create a new keyboard with a japanese-like input method? and if yes, how can I do?
    Thank in advance!

    Hi,
    Somehow, almost understand what you want to achieve, mostly, I think. But you really need to explain more.
    Forgive me, but it sounds like you do not really know exactly what you want. (in term of programming)
    What do you want to say by :
    "Ok, I have already created such an application with realbasic, but it would be nice if it were possible to put it in the top in the form of a standard keyboard.."
    (This is the part I did not understand)
    Did you mean an input methode, like kotoeri for japanese under MAC OS X ?
    Have you ever programmed for mac OS X (carbon or cocoa) before ? If yes, then this should be very close to what you want : take a look on the side of the accessibility API. There are already applications available that can substitute user's text input with other text. For instance, replacing :
    YUME by 夢 (Hint : you need to make your application trusted)
    Is is what you were looking for ?

  • Print dialog freezes randomly with HP driver

    Using the HP LaserJet 3330 MFP - Gutenprint v5.1.3 driver.
    Occasionally when I, or my colleagues with Macs, try to print from any application, Carbon or Cocoa to this particular printer, the print dialog freezes. By freezes, I mean that the dialog comes up, and you cannot click any button or change any text. The only solution is to kill the app then logout and log back in to get it to function again.
    Any ideas how to solve this? It is repeatable on different computers, although we can't find a specific pattern to the occurrence.
    Message was edited by: feverishaaron

    Hi, altruist77
    To narrow down the list of possible issues, it may be a good idea to boot the system into Safe Mode and try the same steps as before and see if the issue still occurs. The printers will not load in safe mode, so you would not be able to print to them anyway. But I am curious to see if the print dialog will still make the computer hang.
    To boot into safe mode, either restart your computer or start from a cold boot. Begin tapping F8 at the splash screen and continue to tap the button until a menu appears. One of the options on this menu should be Safe Mode with Networking. Select this option and the computer will boot. Some features are removed from Safe Mode, so the display will likely look very different, but it is normal. Run the steps in this mode and see what happens.
    Best of luck, and let me know how it goes
    Adam
    Did someone help you today? Press the star on the left to thank them with a Kudo!
    If you find a post helpful and it answers your question, please mark it as an "Accepted Solution!" This will help the rest of the community with similar issues identify the verified solution and benefit from it.

Maybe you are looking for