I am new to Adobe AIR. Please help
I want to Add status icons over file icons in Explorer, like Dropbox or SVN. I am developing anappliation like dropbox in Adobe AIR for MAC and Windows.
I think it is common for both OS Mac and Windows both OS support AIR so i have choice this tool.
I have two queries.
Add status icons over file icons in Explorer, like Dropbox or SVN.
Folder watcher you have and idea about that and any class and utility for that.
Personally, I don't think AIR is the correct solution for this. Although it would be possible to poll a directory and compare its last known structure to its current one, I imagine this would be very inefficient in both Actionscript 3 and Javascript.
Languages such a Java in their latest major release have utilities for directory monitoring 'out of the box' and have the benefit of being able to delegate these tasks to different threads.
To give another example something like TortoiseSVN which monitors directories and dynamically changes the icons is written in C++.
Related
Xcode8 now officially support editor extensions, and forbids code injection, preventing previous extensions (served by Alcatraz for example) to execute.
It may be a dumb question, but I'm totally unable to find an answer:
Where can I search for existing Xcode8 extensions?
For example, with Alcatraz there was a panel in Window > Extensions, which presented a list with all available extensions. With Xcode 8.0 (official release) there is no such option.
In WWDC video, the guy talks abound downloading them from the mac App Store. But again, I'm unable to find a category or any one of them.
(note: I'm still on El Capitain)
This is all I could find:
Awesome native Xcode extensions
Xcode-8-extensions
The Xcode extensions can be found on the App Store, for example i have been able to find this one: Text Toolset
They have to be enabled after installing by going to the system preferences > extensions.
Overall they are really hard to find, as they do not have a separate category on the App Store.
I have created a cocoa application primarily to run on OS 10.6.8. to convert certain types of proprietary legacy files. The app looks at the legacy files creator code and processes it accordingly if it is a known type. Once the file is identified, I call an external legacy app (which I have added to the project) using [NSWorkspace openFile: withApplication: ]to open the droplet and process the file conversion.
The application works just like it is supposed to until I archive it and try to run it from the application bundle. Actually, it will continue to work but it is using the converter app from the project. If I delete the converter in the project area, then the app in the app bundle can not open the external app in that location. One work around is to delete the external app from the bundle after its archived and replace it with a copy of the one in the project area.
I would appreciate any suggestions on resolving this. I'm not sure if the problem is in some Xcode build setting I can change to include an external apps resource fork when archiving, or if this is a launch services issue with apps hidden in packages, or , something I'm not even considering.
Thanks
Mike
Try setting the "Preserves HFS Data" (COPYING_PRESERVES_HFS_DATA) build setting.
I wonder if is possible to package into an executable in VA Smalltalk. Posts on this subject seem to have contradictory or old information. The README from Instantiations comments about splash screen and other resource tweaks for client installs, but is not clear about making an executable application for distribution.
In that case:
Does generating an exe file implies stripping an image?
Is the image bootstrapped, i.e. built from scratch?
so here is my attempt to give a short answer.
You do ship several components when you deploy your application as a runtime:
Your stripped down image (VA ST has a very powerful tool called Packaged Image Browser for this task)
The Virtual Machine (a .exe on Windows). You can customize this exe to display your splash screen or your window icon.
A number of additional files that are needed by the VM and/or your image. These are pictures, message catalogs, additional DLLs etc. VAST has an exhaustive list of which files you have to ship if you use some feature of the product in the VAST documentation
So there is no mechanism to bundle VM and Image together and turn them into a single .exe file, like in Dolphin Smalltalk and maybe more. What you ship is usually a Directory with a few subfolders in it.
There's no way to embed the image (.icx file) into the executable (.exe file) with VA Smalltalk. The best you can do is have an exe file for the VM and your own custom icx file for the image plus a .ini file for configuration. The "Make Executable" option in the organizer creates these files for you but you still have several files.
Here is a good resource for starting out making runtimes.
Although, as mentioned, you can "Make Executable" from the option menu, my experience is based on the runtime packaging.
I recently finished an application based on Titanium, Javascript, HTML, CSS. I have only been a web designer to date so I have little experience in distributing applications. I was accustomed to the TiDev Community deploying app, which prepared the app for download and made it available for download at a given link.
But tidev community is no longer supported, so I use TideSDK Developer to package the app, which doesnt do all the hard work the other one did so nicely.
I am obviously a complete rookie to this.
Could anyone outline the steps I would need to take to go from the bundled application folder I have now (put together by TideSDK Developer), to a link that will allow customers to download and install the app or online? I know there is an issue with packaoging the app for platforms other than your own, and that appcelerator is working on a solution to this I think. I also realise I would probably have to pay to host the download online. Any guidance would be greatly appreciated.
You must use the tidebuilder.py script. to compile a installation package. To compile a binary for a Mac, you must run the script on a Mac, to compile a binary for windows, you must be on a windows box etc.
There is some documentation on how to use it here per platform. The command is very simple and works.
Once you have your application file (DMG for OSX or a MSI for Windows) then just distribute it however you see fit, email, putting it on your web server, whatever works for you.
I have a Windows CE device that we are deploying, but we have complete control of the software installed on it.
This is not a typical Windows Mobile device, this is a headless device that the user will not interact with. I know that on PDA-style WinCE devices, the .cab file is the preferred application distribution method.
However, on a headless device, we will be writing some type of upgrade/patch server that will ping a server for updates, download them, and auto-install when they are available.
Do I still want a .cab file, or is a .zip (or even something else) better?
What are the requirements for a .cab file - what kind of restrictions / requirements might get in the way and be an annoyance? What are the benefits?
I'd stick with CAB as a package since even headless devices can use the CAB extraction tool. If you ZIP it, then you have to add a ZIP support library and app. CAB also has the ability to add registry entries and define far more disparate target locations than a zip (I want x.dll in \Windows but prog.exe in my program folder - try that with a ZIP).
One thing to keep in mind is that wceload (the CAB extractor) uses a UI by default, so you're going to want to use things like the /noui switch for it.
If you're true headless this may not be an issue (not done that in a long while) but a fairly common "headless" configuration has display support and either the display simply isn't hooked up or is something like a NOP VGAFLAT driver. This allows you to run a shell and have access to all the nice shell APIs, but adds to the challenge that GWES will render dialogs onto the non-existent display.
OpenNETCF also has a CAB Installer SDK that you can use to completely remove any UI with by creating your own installer app. This may or may not be useful depending on the how and when the install happens (through HKLM\Init or otehr for example).