I made visual aid type of widget (user needs to see through it) with Dashcode, now I want to port it to Windows XP & 7.
I heard that StarDock DesktopX Pro can export standalone widgets as .exe but I don't know if those are native Windows widgets.
Is there a Dashcode equivalent for Windows? (I happen not to know JavaScript !)
There is no Dashcode equivalent for Windows, the Windows "widgets" that exist currently are just packages of HTML/JS/CSS and as far as I have seen do not have a widespread adoption rate.
If you are looking to do something like an overlay then a "widget" in the Windows environment is probably not the correct route. You would be better off writing a native application.
An exported .exe from DesktopX is not a native Windows gadget. It's either a self contained application, or it require DesktopX client to be installed. ( Depending of which variant you export. )
You can however export a .gadget which will act as a Windows gadget. Here's a quick tutorial article: http://www.wincustomize.com/article/155475
Related
I have added desktop extension to my UWP app that gives some extra functionality if it runs on Windows 10 desktop platforms. But for other platforms it won't be used. Hence I want to make sure that the desktop extension isn't installed on other platforms thereby saving users some disk space. I have looked into app extension but it won't be viable for my use cases since the UWP app and desktop component communicate via named pipes and memory mapped files. Is there any other way I can control the installation of desktop component depending upon the platform it is being installed??
Update 1
From researching further I have found that this should be possible with optional packages/related sets, to be accurate related sets for my scenario. The examples provided in docs only show scenarios for packaging uwp apps as related sets and no example for packaging win32 apps as related sets was given. Is there any way to package a win32 application as related sets??
I have a Xamarin app that runs on Android, IOS and Windows 8.? It is essentially a “player” to display a proprietary document format. Formatting the documents so they look good on a small screen is a trial and error process. Essentially: Edit; Compile; Transfer to mobile; View; repeat;
To speed up this process, I am trying to build an emulator. I am using the Windows version of the app as a base for the emulator (because if I stay in Xamarin, I don’t have to rewrite all the code for Windows Forms)
The compiler is a Windows app. After compiling I know exactly where the file is located. When I run the emulator, it does not give me access to the Windows file system. I tried using PCLStorage Library. It stored the file here:
C:\Program Files\OpenSSH\home\30011765\AppData\Local\Packages\85930d70-750c-41a6-9b95-03faaed4159c_nh7s0b45jarrj\LocalState\ZDO\dev
I specified this part \ZDO\dev but have no idea how it selected the rest. Like why OpenSSH?
Question: Given this app is only going to run on Windows, is there a way to load a file as C:... ?
If not, is there another way for a Windows Forms App to share a file with a Xamarin Windows App?
I’ve spent several hours searching for a working example solution and have yet to find one.
Installed Windows on my Galileo board and that works fine.
I developed a small application i Delphi7 (32 bit exe) that
I have deployed to the Galileo and configured it to start
at boot by configuration in the autorun.cmd file.
start C:\applications\GalileoApp1.exe
The application is formless and contains a TCPserver that echoes back incoming data.
Works fine under windows 7 on my PC.
Does not start automatically or manually on my Galileo.
Has anyone tried something similar and succeeded in executing the application on Galileo?
Are there any limitations on what types of 32bit exe´s that can be executed on the Galileo?
Stock Delphi RTL will not work on that version of Windows. The primary reason is that the Galileo versions of Windows' DLLs are different from the desktop version. This will require a rebuild of the RTL in order to import APis from their new locations. Some APis aren't even supported (such as most of the ones in GDI32 and USER32).
That being said, here at Embarcadero, as a research project I have a version of the Delphi RTL that does run on the Galileo board (I'm looking at the board right now :). I also have a stripped down Delphi conversion of some of the Wiring/Arduino Sketch API. When or even if we release such a thing is purely dependent upon the demand and our intended product direction.
The bottom line is that, yes, it is possible to get a Delphi-built command-line application (no visual VCL is supported, or anything that assumes the presence of a GUI). No, it's not a straight-forward, simple process as it requires some significant modifications to the RTL. I would also not recommend using Delphi 7, since the Galileo board doesn't support most of the Ansi versions of the Windows APIs. You will need a Unicode capable version of Delphi to start with.
For a new desktop app project I'm researching if it's feasible to create a cross-platform implementation instead of native Windows and OS X apps. Chrome Apps seemed promising, but after browsing through the Chrome APIs there are some things I didn't see that I'll need in my app:
Notifications on changes to files in the local filesystem. (File System Events API on OS X, FileSystemWatcher on Windows.) At first I thought the syncFileSystem API might help with this, but it's apparently only for syncing with Google Drive, which is not what I need. I guess I could workaround this by scanning the directories I'm watching on a timer, but that won't perform well if there are a lot of directories and/or files.
Ability to add context menus in Windows shell and OS X Finder, as I would be able to with a Windows shell extension or OS X Finder plugin.
Ideally (although probably not a hard requirement) get the app into the Windows System Tray / OS X Menu Bar (NSStatusItem).
Can anyone confirm whether it's possible to access this functionality with a Chrome App? If not, can you recommend an alternative cross-platform tool for building an app with these features?
All of the listed features have bugs logged, but no real progress at the moment:
Watch: https://code.google.com/p/chromium/issues/detail?id=148873
File manager integration: https://code.google.com/p/chromium/issues/detail?id=130455
Sys tray: https://code.google.com/p/chromium/issues/detail?id=142450
The first of these to be made available will probably be file manager integration, which is being worked on now.
We'd love to improve watching but it is a significant task to support this on all operating systems and we don't have anyone working on it now.
Sys tray support is something we have no plans to release soon as we're not sure how we want to support this on ChromeOS.
I could not find anything close to the items you have mentioned. I did however find this product: node-webkit that likely would get you onto both your target platforms, use the same basic code-base (HTML5/CSS/JS) and allow some possible per-OS customization. There is even a 'watch' project under NPM that covers your first bullet point. Check node-webkit/wiki for notes on how to add C/C++ extensions to their node build (under using-node-modules.) Project seems active and appears to be backed by Intel (they re-built their XDK product on it to do cross platform.)
Regarding my earlier question about the Point of Mono on Windows, let's say that I develop an app against the windows mono runtime so that it will also run on Linux, OSX, etc.. and to make it more complicated, I use GTK# so that I don't have to deal with WinForms. Is there then an easy way to bundle the Windows Mono runtimes with my Windows version of the application so that it can all be installed at once? Or, is there no point to this? Once I develop against the Windows Mono runtime, would it still run fine against the MS .NET runtime? (I assume I would still need GTK# installed though).
The short answer is Yes.
The things you should take care about while programming are
Not to use platform API
Don't hardcode directory & file name separators, i.e. don't hardcode file paths, but use appropraite class to obtain path separator then concat the names.
Keep in mind that file names on *nx are case sensitve and on Windows are not. While programming don't refer to the same file as log.txt and Log.txt but keep it all small.
Other then that, if you created GTK# application on *nx system, you will be able to run it on Windows if you installed GTK# assembly, and vice-versa.
I did this myself, and it worked like expected. I had a problem to find specific assembly dll version of GTK# on Windows and that took me few hours.
In general, you probably would just use the .Net runtime on Windows. The installer for GTK# for .Net is available from Mono's download page. Your users would need this installed, and then could run you app using the regular .Net runtime.