DesktopBootstrap: like Twitter Bootstrap, but for desktop apps | Hacker News Reader

DesktopBootstrap: like Twitter Bootstrap, but for desktop apps

github.com

65 pointsadamsmith21 comments

"The Service is a Windows service, which runs as SYSTEM, and is available to apply automatic updates, or do other things as SYSTEM."

Is it just me that doesn't like this. Services are meant for processes that need to do something in the background, not some hack to get around elevation requirements.

If I look at the list of services running on my machine it's getting like the old days with notify tray apps. All of them nibbling away at my resources.

Windows desktop apps.

I wonder how much work it would take to port to Mono, however.

Thanks Adam. There was another interesting windows project called command line ide for creating visual studio solutions. http://remi.org/2011/04/17/clide

"ClickOnce" deployment, which you get for free when you're developing a windows desktop app, does the same thing as far as I can tell. And it doesn't install a service on your system; instead you can configure it to check for updates in the background when your app is running, installing them when it's launched the next time.

So... what does this offer over the stock solution?

I've never used ClickOnce, so maybe someone with more direct experience can chime in!

My current project, and my last project (Xobni) both worked with COM components that could not use Reg-free COM for various reasons. Thus, if another app registers the same COM component, and then the user uninstalled that app, we needed to be able to re-register that COM component, which required SYSTEM level privileges in order to avoid a UAC elevation prompt.

Services can also be useful if you want to be able to run code when a user is not logged in, or if you want installs to be system-wide.

For example, in DesktopBootstrap, installs are for "all users," but if one user disables auto updates or starting up with Windows, it actually asks the service to disable those things for all users. You need a service running as SYSTEM to be able to pull that off, again unless you ask the user to elevate you.

Finally, I'm curious about ClickOnce's browser-powered install. I'm not saying it doesn't work -- it might even increase conversion rates -- I'm just curious. I'd love to learn more about what happens with users who are using a non-ClickOnce-compatible browser, and/or who don't have the .NET framework installed yet.

ClickOnce doesn't require admin privileges to install software. Each program is installed on a per-user basis under the user's profile. So it doesn't need admin rights to write to C:\Program Files. I'm pretty sure this is how Chrome works as well.

As for installing COM components, you can install COM components on a per-user basis as well. The registry keys are installed under HKCU rather than HKLM, so again you don't need admin access.

I program .NET client applications for my day job and we use ClickOnce to deploy our software. The software doesn't require admin access to install or use, and we register a COM component for integration with Excel and it all works just fine.

Wow that's really cool! I wasn't sure you could register COM classes from ClickOnce.

So yes it seems like ClickOnce is great as long as you don't need per machine installs or special powers to eg upgrade the user's .NET version, etc etc.

How have you found the .application installer? (vs exe)

Edit to add: I was surprised when MS introduced .msi installers! Someone at MSFT is cranking out the installer systems.)

I actually like the .application format. It's nice because it's just an XML file that the end-customer's computer knows what to do with it.

At my company we've actually created an ASP.NET MVC application that dynamically constructs and serves the .application file on a per-user basis. This easily allows us to do canary releasing or beta previews.

We're very happy with it, and so are our customers and stakeholders.

("if another app registers the same COM component" <- why was this happening?)

Shared components -- at Xobni in the early days we used a library called Redemption that other addins often used. My latest project includes VirtualBox, which uses COM components that are going to have ID's in common with any other use of VirtualBox. (In the VirtualBox case we could change all of the ID's are recompile, but I'm still hoping to avoid doing that.)

Doing this is like including a /usr/lib/libvirtualbox.so.1.2 in multiple Debian packages, getting irritated that other people's packages uninstall your shared library, and then deciding to write a daemon whose goal is to watch for that file being deleted so you can replace it... in essence: a mistake. ;P

AFAIK the way you are supposed to solve this on Windows (if you really aren't in the position to simply think of VirtualBox as a separate project that the user manages using its own Installer) is to use Merge Modules, which track this kind of installation corner case correctly and can be added to multiple MSI files.

Having multiple people compiling, and then sharing, the same components eventually causes you horrible problems one day when you find out that one of the users compiled it with a slightly buggy compiler, and didn't notice because they weren't using that part of the library.

The core benefit, then, of using Merge Modules, is that VirtualBox is able to distribute an official build of the library that people can submit bug reports to ("didn't work on Windows 7 Home SP2"), despite possibly not having its own Installer. Is VirtualBox simply being annoying in not providing official package manager components? :(

Reference: "Each merge module contains unique version information that is used by the Windows Installer database to determine which applications use the component, preventing premature removal of a component. For this reason, a new merge module should be created for every incremental version of your component; a merge module should never be updated after it has been included in an installer."

-- http://msdn.microsoft.com/en-us/library/6771e4ch(v=vs.80).as...

"Users love software that gets better over time, with no effort on their part."

This is still a big deal in the desktop world where I live.

Can we have a screenshot?

Sure! There's not a lot to look at! Here are two screenshots:

DbgView of an update happening: http://dl.dropbox.com/u/3/DesktopBootstrap_Updating.png

Default tray icon menu (with custom cloud icon): http://dl.dropbox.com/u/3/DesktopBootstrap_TrayIcon.png

(The idea is that you can blast away the tray icon if you don't want or need it, and either way you add your own UI and application logic on top!)

Uh, what's the relationship to Twitter Bootstrap? That's a library for GUI widgets and styling.

curious, why winforms over wpf? Are you intending for more cross-compatability that way?

Yeah -- the particular application that this is derived from needed pretty wide compatibility out of the box, so the projects are targeted to .NET 2.0.

But this is also helpful for DesktopBootstrap. If someone wants to retarget to a higher .NET version it's very easy to do. There's only one winform in there (the tray icon)!

So, uh, what does this provide over Glade, wxGlade, and QtDesigner? Why should I go with this instead of the open-source solution?

This isn't really the same thing. Those things (at least after my brief googling) are for building apps. This is an attempt at packing everything else -- mostly an installer, build system, and auto updates -- but for .NET apps rather than python apps.

(If there's such a set of things for python desktop apps, including a byte code obfuscator ideally, or someone builds it, that'd be awesome and I'd love to know about it!)

I think it's interesting that you mentioned Python instead of C or C++.

There is no such thing as bytecode obfuscation for Python. The nature of Python's bytecode is such that there is no effective way to obfuscate what the bytecode is doing without incurring massive slowdowns. Consider using legal means, rather than technical means, to protect your code from prying eyes, and remember that many proprietary companies publish Python source with their non-free software. My favorite example remains Civilization 4.

Reply on news.ycombinator.com