I have a xul app that I think would be useful, and I want to deploy it. The target platform is Linux; I believe it will work on Windows/OSX as well but haven't tested. What is the best way to deploy this app?
Is using xpi packages and requiring the user to install xulrunner separately the way to go?
If I bundle xulrunner, should I keep it local in my program's directory or should I install it in /usr/bin or wherever?
I realize this is two questions, but I think they're related...
Thanks,
Nathan
I deployed an XULRunner based application during the 1.8 to 1.9 transition on Windows. It used XUL, and had some DLL based XPCOM components. The best way for making sure that you have something which will work 'out the box' is to bundle everything - the runtime and the application - into one install. There might be some duplication, but it's probably not worth the effort of sorting it out given the number of people who will already have XULRunner installed on their machine. It certainly wasn't for us (we were the first XULRunner app on BOWMAN kit). But you can also provide the xpi as a courtesy for advanced users, if you feel like it.
Bundle it - that's the recommended method from Mozilla (for now) - and you can make it more user-friendly.
Perhaps someday there will be a great tie with Firefox's xulrunner executable, and you can piggy back off of it. But that day is not today.
Related
Firstly, I saw some topics about these two but weren't my answer.
I'm looking for a good FPC(Free Pascal Compiler) IDE on GNU/Linux.
There are some IDE's like Lazarus and CodeTyphon. I need suggestion to choose one of those.
I've tried Lazarus once but all windows was separated. It looks messy and not interesting.
I would like to know what are the distinguishes between these two ?
I would like to know advantages / disadvantages each of those. Thank you
CodeTyphon is a distro of Lazarus, like Ubuntu and Debian are distros of Linux.
CodeTyphon comes with a large package of components and plugins, that otherwise you would have to google and download and install.
CodeTyphon have their own idea what are stable versions and what are not stable yet for both of FPC (compiler) and Lazarus(IDE). Whether their assessment is better or worse than upstream's Lazarus Team's, I don't know.
What about one-single-window plugin, it is work-in-progress and it doesn't seems to me it is ready for production use, no matter would you get it as part of CT or download and add it to vanilla Lazarus. However maybe it better works on Linux than on Windows, I don't know.
There were however issues with code legality in CT grande bundle. It is widely believed that Orca (if I remember the name) violates copyrights of glScene/vgScene, which also happened in early Delphi FMX releases but was fixed by EMBA later. There also were disputes in FPC forums/wiki about CodeTyphon pirating some open-source components. See answer by Peter Dunne below.
Your question is akin to asking the difference between Linux and Ubuntu. Lazarus is an IDE/component library, based on FreePascal (FPC). And CodeTyphon is a distribution of Lazarus and FPC. So CodeTyphon is just one way to install a functioning installation of Lazarus.
Lazarus uses the same floating window design as older versions of Delphi. Installing from CodeTyphon won't change that.
Myself and several friends highlighted several licensing issues with codetyphon
most of which could have been corrected by sourcing the included files from known good source and ensuring the correct license headers were included
PirateLogic refused to correct the issues which means they are using code in direct violation of the original license terms
The fact its open source code does not change the fact they are pirating the code by not including the correct license even after the issue was highlighted
I also found several instances of copyright code included which appears to be proprietary and not FOSS at all
They also changed the path & file names on some libraries so that source is no longer compatible with standard lazarus/component installs
This in my view is totally illogical
These 2 factors heavily undermine what was potentially the best FPC/Lazarus distro
Hardly professional
Lazarus can be a daunting installation process due to it's nature as a cross compiling environment. You don't just download an installer and click ok. A typical "installation" is actually a bootstrap FPC compiler doing a three-pass compilation of an "install". There are plenty of good installation scripts/methods from the official Lazarus/FPC team and in the community for a . But, understandably, the installation process is a skill in itself.
CodeTyphon is a a different/separate branch of an installer system, which is more of a utility suite/tools/third party code compilation library. If you want the simplest installation experience go with CodeTyphon. It has the nice graphical front end for managing the compiler. You can conveniently do the fancy stuff like build "cross-compilers" for almost every "target" operating system out there. It also is jam packed with hundreds of the best components/libraries pre-installed. It is a very actively maintained project and very professional. A whole lot of work is done for you.
Even if you want to be learn the low level compiler capabilities, CodeTyphon is a good place to start. It is written in FCP/Lazarus and is open source. Simply study it as "working demo app" and the other info on the compiler details. If you crash it, at least you don't have to learn to climb the hill. You get to get to start from the top and lose control on the way down. Start from scratch (and a three hour reinstallation) Hahaha
Lazarus also has a package "AnchorDock" which allows you to dock all the windows into one. Either install the anchor dock design package after installing Lazarus, or install Lazarus using the script at getlazarus.org which will do it for you.
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.
Here is my situation. I am on a Mac using Brew as my package manager. I had mono installed on my machine and I was doing all sorts of development in C#. I was doing web development, gui development, ect. When I tried to update my machine using Brew, I got an error. Uninstalling Mono solved the issue.
So, what I did is I toyed around and I created a 2nd user on my machine. Now, this user doesn't need anything to work. I just need Mono and Mono Develop to work on this user without installing anything globally. Everything needs to be installed locally.
So to be specific, I am the only on who uses my machine. My /Users directory looks like this.
/Users/dillon
/Users/dummy
So if I could install mono, in let's say:
/Users/dummy/.mono
Then in my .profile:
export MONO_PATH=/Users/dummy/.mono
Obviously this isn't a perfect world but I was wondering if anyone is an expert on this subject?
(Also, I use this dummy user for other stuff, I use it for Wine and I have a collection of software from school on this user.)
You need to build Mono from source to install it into a custom location (in which case you can install it anywhere you like).
You can install MonoDevelop.app anywhere, but getting it to use your custom Mono is a bit trickier. You might be able to make it work by mucking around with the relevant environment variables though.
How to install Mono in a custom location and the relevant environment variables is all covered here: http://mono-project.com/Parallel_Mono_Environments
Trying to figure out the best way to use Nuget in a development environment to manage our own libraries.
We want to standardize on Nuget way of doing things for our 3rd party libs, but would also like to use Nuget to manage our internal utility libraries, for developers consuming the in house libs this is great and everyones happy. However, for devs actively working on the Utility lib it seems to be more problematic, their previous process of build lib , build main app , F5 and go is now slowed down with publishing, and updating and potentially lots of packages, not to mention the moaning about additional process!
We use TDD on the internal libs but everyone needs to be able to debug and modify libs along with main app, have seen Phil Haacks demo on debug packages in 1.3 and read David Ebbos blog, but that fits different scenario.
So what is the best process for dev/debug cycles? if to use Nuget then we need to accept the existing constraints, or is there a hybrid practice people are using and maybe 1.3 gets closer to automating all this, or do we just avoid Nuget for internal packages which would be a real shame.
Loving Nuget, maybe wanting way to much from the little guy, feedback appreciated.
Thanks
I'd suggest you use separate network shares or feeds (similar to what myget.org supports in the cloud) for different scenarios.
You could imagine creating a CI share, a QA share, a Releases share, ...
Make people working on the referenced library do CI builds that drop CI packages on the CI repository for instance, and have them picked up by other projects (who just need to do a simple update, could be automated through PowerShell in pre-build: check for new version, if so, update).
Just make sure that when products release their milestones, they also release with released dependencies (could be as simple as switching feeds, releases will always have a higher version number than CI builds).
Hope that helps!
Cheers,
Xavier
If you're working on the source code for the lib and the main app at the same time, I'd say NuGet is probably not a good solution. I think it'll only work in situations where you work with a "stable" version of the library that don't need to change frequently during the development of your main app.
That said - is it possible the development on your library could be done in isolation? You already mention you're doing TDD on the lib, so why can't that work be done, then built, deployed, then the main app work done?
I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.