I wish to write a utility to auto-hide the menu bar, much like the dock. This would
replicate the a OS X 10.4-only application "Menufela", but for Snow Leopard.
[[NSApplication sharedApplication]
setPresentationOptions: NSApplicationPresentationAutoHideMenuBar
| NSApplicationPresentationAutoHideDock];
This code auto-hides the menu bar (and dock), but only in when the application is the frontmost window. How would I go about applying this behaviour system wide, regardless of what application is open?
The only thing I can think of is an InputManager, but I haven't written one before, thus I'm unsure if this is the correct way to go about it..
Also it seems InputManagers are limited as of Leopard/Snow Leopard - from this SO question:
it won't run them in a process owned by root or whell, nor in a process which has modified its uid. Most significantly, 10.5 won't load an Input Manager into a 64 bit process and has indicated that even 32 bit use is unsupported and will be removed in a future release.
I'm not concerned about the "will be removed in a future release" (it just has to work on Snow Leopard), and I don't think root-owned processes are an issue (all GUI applications should be running as the current), but presumably the code would have to be injected into many 64-bit applications (Finder/Safari/etc)
(I originally asked this on SuperUser, here, but as there was seemingly no existing utility to achieve this, it's more relevant to StackOverflow)
The kiosk API is probably your best bet for this, though I haven't used it in years and don't know if it's even supported anymore.
http://developer.apple.com/mac/library/technotes/tn2002/tn2062.html
I hacked together a small SIMBL plugin to hide the Menu Bar: http://github.com/Crazor/MenuBarHider
It uses the SetSystemUIMode() Carbon call, which is not limited to 32bit apps.
I haven't used it on Snow Leopard myself, but the only way of injecting systemwide that even has a chance as far as I know is mach_star, and even that will be a bit tricky. Apple isn't making this easy these days, which is why a lot of the old hacks are failing to be updated either in a timely manner or at all.
This recent Cocoa With Love article has information on how to hide the menubar:
http://cocoawithlove.com/2009/08/animating-window-to-fullscreen-on-mac.html
However, using the CarbonAPI (SetSystemUIMode()) requires the app to be 32-bit and does not work outside the scope of the application.
Edit: and reading a bit further, it seems that this API doesn't do anything that -[NSApplication setPresentationOptions] can't do.
Related
I am programming using C++ /CLI with wxWidgets on Windows 11.
I'm Also Using .NET threads
When I create a wxMessageDialog in a secondary thread and run ->ShowModal() , it works.
But when I create a custom dialog in a secondary thread, running ->ShowModal() pops up a wxWidgets debug alert window :
I tried searching on the wxWidgets forum for the same issue but couldn't find one. I found similar issues but none of them addresses my problem.
I also tried to surround MyCustomDialog->ShowModal() with calls to wxMutexGuiEnter(); and wxMutexGuiLeave(); , but that also didn't work.
I also learned about wxThread while scrolling through the forum but if wxMessageDialog works without me having to create a wxThread, I shouldn't have to create a wxThread myself.
I know I shouldn't be calling GUI methods from a secondary thread, but somehow wxMessageDialog's ShowModal() doesnt have a problem with that.
I would like to know how wxMessageDialog works, and if I can implement the same thing with my custom dialog.
Thank you.
In a few words, no there's no way to use a custom dialog from a secondary thread with current implementation and in the foreseeable future.
Even though your current code works today using wxMessageDialog, there's no guarantee that it will continue to work tomorrow, or on different Windows version or on other OS.
Some more details:
wxMessageDialog and a custom dialog are significantly different internally, even though they represent similar UI features.
wxMessageDialog has native implementation, and you can find its wxMessageDialog::ShowModal() implementation in src/msw/msgdlg.cpp.
A custom dialog will be assembled an run by wxWidgets code, even though the dialog itself and other components are native widgets. You can find wxDialog::ShowModal() in src/msw/dialog.cpp.
If you really want to pursue some experimental development (because it would still not be suited for anything else), and being on Win 11, you could try wxRichMessageDialog. It provides more features than wxMessageDialog and on Vista and later versions it has native implementation, which might go along with your "hack".
But again, using UI from secondary threads will lead to a dead end sooner or later.
I've got a big ask here, but I am hoping someone might be able to help me. If there's another site you think this should be posted on, please let me know.
I'm the developer of the free app Amphetamine for macOS and I'm hoping to add a new feature to the app - keeping a Mac awake while in closed-display (clamshell) mode while not having a keyboard/mouse/power adapter/display connected to the Mac. I get requests to add this feature on an almost daily basis.
I've been working on a solution (and it's mostly ready) which uses a non-App Store helper app that must be download and installed separately. I could still go with that solution, but I want to explore one more option before pushing the separate app solution out to the world.
An Amphetamine user tipped me off that another app, AntiSleep can keep a Mac awake while in closed-display mode, while not meeting Apple's requirements. I've tested this claim, and it's true. After doing a bit of digging into how AntiSleep might be accomplishing this, I've come up with 2 possible theories so far (though there may be more to it):
In addition to the standard power assertion types, it looks like AntiSleep is using (a) private framework(s) to apply non-standard power assertions. The following non-standard power assertion types are active when AntiSleep is keeping a Mac awake: DenySystemSleep, UserIsActive, RequiresDisplayAudio, & InternalPreventDisplaySleep. I haven't been able to find much information on these power assertion types beyond what appears in IOPMLibPrivate.h. I'm not familiar at all with using private frameworks, but I assume I could theoretically add the IOPMLibPrivate header file to a project and then create these power assertion types. I understand that would likely result in an App Store review rejection for Amphetamine, of course. What about non-App Store apps? Would Apple notarize an app using this? Beyond that, could someone help me confirm that the only way to apply these non-standard power assertions is to use a private framework?
I suspect that AntiSleep may also be creating a virtual keyboard and mouse. Certainly, the idea of creating a virtual keyboard and mouse to get around Apple's requirement of having a keyboard and mouse connected to the Mac when using closed-display mode is an intriguing idea. After doing some searching, I found foohid. However, I ran into all kinds of errors trying to add and use the foohid files in a test project. Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app? I'm not asking for code help with that (yet). I'd just like some help determining whether it might be possible to do.
Thank you in advance for taking a look.
Would Apple notarize an app using this?
I haven't seen any issues with notarising code that uses private APIs. Currently, Apple only seems to use notarisation for scanning for inclusion of known malware.
Would someone be willing to take a look at the foohid project and help me understand whether it is theoretically possible to include this functionality in an App Store compatible app?
Taking a quick glance at the code of that project, it's clear it implements a kernel extension (kext). Those are not allowed on the App Store.
However, since macOS 10.15 Catalina, there's a new way to write HID drivers, using DriverKit. The idea is that the APIs are very similar to the kernel APIs, although I suspect it'll be a rewrite of the kext as a DriverKit driver, rather than a simple port.
DriverKit drivers are permitted to be included in App Store apps.
I don't know if a DriverKit based HID driver will solve your specific power management issue.
If you go with a DriverKit solution, this will only work on 10.15+.
I suspect that AntiSleep may also be creating a virtual keyboard and mouse.
I haven't looked at AntiSleep, but I do know that in addition to writing an outright HID driver, it's possible to generate HID events using user space APIs such as IOHIDPostEvent(). I don't know if those are allowed on the App Store, but as far as I'm aware, IOKitLib is generally fine.
It's possible you might be able to implement your virtual input device using those.
I'd like to add a find bar (just like the one that appears in Safari, Skim, etc) in the NSTextView of my app.
I'd like to use NSTextView's setUsesFindBar method, but it's a Lion only API at the moment (according to its documentation). It uses the NSTextFinder class, which is also available only in Lion.
My question is how I may be able to replicate this in my app that needs to run on both Snow Leopard and Lion. I could of course use the find panel on SL, but it would be nice to have a consistent look across the two versions.
Are apps like Safari, Skim and so on coding it from scratch in their SL versions?
Any explanations or pointers would be much appreciated.
Unfortunately, you'd need to implement the find bar from scratch for Snow Leopard, there's no API support for it. Safari may use a private implementation of this API in Snow Leopard (I don't know if it does or not) but the developer of Skim has most likely re-implemented it from scratch.
I think that letting Lion users make use of the new functionality while SL users get the old find panel is an appropriate way of dealing with the situation. I don't personally think it's worth going to the effort of re-implementing it for a legacy OS.
Updated: I just did a search for Skim and it appears to be open source. If that is the Skim app you're referring to, then just check out the source and have a look for yourself.
I need to build a fairly simple app but it needs to work on both PC and Mac.
It also needs to be redistributable on a disc or usb drive as a standalone desktop app.
Initially I thought AIR would be perfect for this (it ticks all the API requirements), but the difficulty is making it distributable, as the app would require the AIR runtime to be installed to run.
I came across Shu Player as an option as it seems to be able to package the AIR runtime with the app and do a (silent?) install.
However this seems to break the T&C from Adobe (as outlined here) so I'm not sure about the legality.
Another option could be Zinc but I haven't tested it so I'm not sure how well it'll fit the bill.
What would you recommend or suggest I check out?
Any suggestion much appreciated
EDIT:
There's a few more discussions on mono usage (though no real conclusion):
Here and Here
EDIT2:
Titanium could also fit the bill maybe, will check it out.
Any more comments from anyone?
EDIT3 (one year on): It's actually been almost a year since I posted that question but it seems some people still come across it every now and then, and even contribute an answer, even a year later.
Thought I'd update the question a bit. I did not get around to try the tcl/tk option at the end, time constraint and the uncertainty of the compatibility to different os versions led me to discard that as an option.
I did try Titanium for a bit but though the first impressions were ok, they really are pushing the mobile platform more than anything, and imho, the desktop implementation suffers a bit from that lack of attention. There are also some report of problems with some visual studio runtime on some OSs (can't remember the details now though).. So discarded that too.
I ended up going with XULRunner. The two major appeals were:
Firefox seems to work out of the box on most OS version, so I took it as good faith that a XULRunner app would likely be compatible with most system. Saved me a lot of testing and it turned out that it did run really well on all platforms, there hasn't been a single report of not being able to start the app
It's Javascript baby! Language learning curve was minimal. The main thing to work out is what the additional xpcom interfaces are and how to query them.
On the down side:
I thought troubleshooting errors was a sometimes difficult task, the venkman debugger is kinda clunky, ended up using the console more than anything.
The sqlite interface is a great asset for a desktop app but I often struggled to find relevant error infos when something didn't work - maybe i was doing it wrong.
It took a little while to work out how to package the app as a standalone app for both PC and Mac. The final approach was to have a "shell" mac app and a shell pc app and a couple of "compile" script that would copy the shells and add the custom source code onto it in the correct location.
One last potential issue for some, due to the nature of xulrunner apps, your source code will be deployed with the app, you can use obfuscation if you want but that's something to keep in mind if you want to protect your intellectual property
All in all, great platform for a cross-platform app. I'd highly recommend it.
Tcl/Tk has one of the best packaging solutions out there. You can easily wrap a cross-platform application (implemented in a fully working virtual filesystem) with a platform-specific binary to get a single file executable for just about any modern desktop system. Search google for the terms starkit, starpack and tclkit. Such wrapped binaries are tiny in comparison to many executables these days.
Many deride Tk as being "old" or "immature" but it's one of the oldest, most stable toolkits out there. It uses native widgets when such widgets exist.
One significant drawback of Tcl/Tk, however, is that it lacks any sort of printing support. If your application needs to print you'll have to be a bit creative. There are platform-specific solutions, and the ability to generate postscript documents, and libraries to create pdfs, but it takes a little extra effort.
Java is probably your best bet, although not all Windows PCs will necessarily have Java (most should). JavaFX is new enough you can't count on it - you'll probably find a lot of machines running Java 1.5 or (shudder) 1.4. I believe recent Mac OS still ships with 1.5 (latest version may have changed to 1.6).
Consider JavaFX
It would run everywhere with a modern JRE ..!
AIR could be an option, but only if you don't mind distributing two different files (the offline runtime installer and your app), and expecting the user to run one and then the other. You do have to submit an online form at Adobe's site saying you agree to distribute the offline installer as-is, rather than digging out individual DLLs or whatever, before they give you the installer.
Unfortunately there's currently no way to get both an AIR app and the runtime to install from one file though. I'm not sure what the deal with Shu is, or whether it's doing anything that isn't kosher.
i would recommended zink. it has all the functionalities you require for desktop. however, the las time i used it it was a bit glitchy.
i was hung up by trying to write a 6M file to the disk. thought it trough and changed the code to write 512K chunks at a time (3min work, fast).
probably it still has some little annoying glitches like making you think on root lvl but the ease of use and the features are just way too sweet to ignore.
I'm looking at rewriting an eMbedded Visual Basic app I wrote years ago. I'm unsatisified with it because of various problems clients keep having with it now and then over the years, mostly along the lines of the app not loading anymore because a required dll/activex control has gone missing! This is so frustrating and naturally difficult to debug when a client is using it far away. In alot of cases reinstalling the app doesn't fix the problem.
My preference would be to rewrite it in C# since I'm comfortable with C# and DotNet, but I'm also open to other platforms like blackberry or iTouch/iPhone so long as the platform can support maps and GPS. I'd start rewriting it in C# now but I can't be sure that I won't have the same problems in .net.
Has anyone else had similar problems with eVB apps which have gone away/persisted when moving to CF DotNet? Or would you suggest a different platform again?
Edit: Note that I wish to move away from eVB anyway, but if I move to CF DotNet I want to make sure I won't have the same missing dll/control problems.
I recommend .NET CF strongly, especially if you already know C# and .NET. Mono has been ported to the iPhone, so it is possible to write apps that will run on Windows Mobile and the iPhone. No Mono for Blackberry (yet, if ever), so that's a definite limitation. I personally can't stand Blackberries (I have both a Blackberry and a WM smartphone and the Blackberry makes me want to hang myself), but they do have a huge user base.
You should have migrated away from eVB years ago, but that's water under the bridge. If you want to continue targeting Windows CE/ Windows Mobile I'd recommend going to the CF - language is irrelevant, use what you're comfortable with.
There's no way to guarantee that whatever your "missing DLL" problem is won't happen again, since we have no idea what DLL went missing. If it was a 3rd party control, then you're at the mercy of the market. If the provider survives, it's likely their control will.
If you want to target iPhone/Blackberry then Java is more likely to be your language of choice - the tools I'm not as familiar with. Eclipse for Blackberry - iPhone may have their own tool.
As for Silverlight, you might look at it, but so far it's just way too slow to be a viable platform, at least on any WinMo device I've ever seen. We've delevered many, many CF apps for all sorts of verticals and have never had any usability problems (though we've been doing it a long time and know every limitation and what we should and should not be trying).
I suggest you take it one step further and look at Silverlight. One of the premises is that it's a more long-term-stable, portable, lightweight download and install, and it hasn't gotten krufty yet.
I think it has the potential to be the next VB for embedded. One of the difficulties with CF is that I've found it to be an insufficient subset of the real thing.
Another option is NS Basic/CE. It's highly compatible with eVB, so you will be able to keep most if not all of your code. The product has been continually updated so it runs on current devices.
The installer that NS Basic/CE creates includes all the dll files your program requires, so they will be included on installation.