The only minor thing that disturbes me are a few well-known logos (Atlassian, GitHub) beyond "Thank you". I know it is a grey area of ethics, but perhaps we should encourage to put real partners (clients, etc.). If you quickly scroll you may see it as more impressive, but in long run listing that kinds of acts seems unprofessional (e.g. listing Microsoft as major partner, when you just license their software).
I also think it's good to provide a platform.getOSType() in a cross-platform environment as long as things don't get out of hand. You could switch on this to load the platform's default fonts.
Apart from that there are examples available to checkout from the repository. (develop branch)
We are working on fixing various issues including moving to latest webkit.
I have written quite a few tools using this system (HTML5/JS, with a little help from a couple of python modules) and I was furious when I updated the Titanium build tools to find out that desktop mode had been dropped and I could no longer build cross-platform installers!
I have been editing the HTML code inside my .app folders on OS X while waiting for this to come out - I'll install it ASAP and see what I can get working again :)
And maybe in this tutorial that I didn't have time to finish yet: http://www.youtube.com/watch?v=2ikb-4tdygg
Looking forward to give it a shot.
The challenges involved in moving forward with the code base from the previous maintainer were documented in this post:
The work has been steady and ongoing. The software itself is complex and substantial progress has been made. More that 1 million line changes of code were made to end of Dec, 2012.
This kind of investment and involvement in this project has been huge for us. It is certainly deeper than the rebranding and documentation effort that we also undertook as part of the project.
TideSDK became an affiliate project of Software in the Public Interest (SPI) in October, 2012. As part of this non-profit organization, we stand together with other significant and substantial open source projects (including Postgres, Drupal, Debian, Jenkins, ArchLinux) that are under the non-profit administration of the SPI.
Tens of thousands of developers now discovering TideSDK as a result of our efforts. This number is steadily increasing. Ongoing upgrades and fundamental code changes in the sources are leading to an amazing solution.
Commercial developments involving TideSDK are also underway for many. Obviously, despite the surge in mobile use, desktop development is comparatively smaller. That said, there remains an important need to address for the desktop that TideSDK is filling.
We've put plenty of effort into establishing community around TideSDK as well and to make resources available to developers:
Source Code: https://github.com/TideSDK/TideSDK
Tutorials: Get started easily http://tidesdk.multipart.net/docs/user-dev/generated/#!/guid...
Q & A on Stack Overflow: Get help http://stackoverflow.com/questions/tagged/tidesdk
Report a Bug: Help us improve https://github.com/TideSDK/TideSDK/issues.
IRC: Chat with us on #tidesdk on freenode.net
Twitter: Follow TideSDK @tidesdk.
Blog: Read our blog at http://tidesdk.org/blog.
Knowledge Base: Read the wiki https://github.com/TideSDK/TideSDK/wiki
Google Groups: Join our mailing list https://groups.google.com/forum/#!forum/tidesdk.
In addition, more great things are coming this year as the result of our involvement with TideSDK. The core talent behind TideSDK formed http://coastalforge.com to bring services and support. We've also got an amazing new solution to reveal shortly that has been spawned from our work. More on these efforts quite soon.
TideSDK Project Lead
Can source code (ie. JS) be completely private (ie could not be reasonably accessed by a competitor?)
Does it have 'custom' jumplist support on windows (eg. media player buttons)?
Global hotkey support??
Well, for one thing, I did not find any decent script to easily package a XulRunner application, so maybe that's a plus point for each, but anything else worthwile (apart from the fact it's based on WebKit) ?
It's no slight against its makers to have gone purely native but the fact is that most companies developing a todo app do not have millions in investment or the sort of native programming capacity to throw at this kind of project.
TideKit is a solution that is going to get you on all platforms quickly and its only improving over time. As you might be aware, the new Wunderlist 2 seemed to have lost its linux support as a result of their recent shift.
We're hoping to show something quite soon that shows a speed and quality of development that will have most wundering why they transitioned to native.
Perhaps it would be better to show some actual users with a carousel type thing?
 http://stackoverflow.com/questions/13598319/questions-regard... (4th paragraph)
But it is a good start
Although mobile platforms are being added to Eto, I don't think I'll ever want to build the same UI for desktop and mobile. That's just me though.
It is responsive, so it is not the 'same' UI, but with a convergence of laptops and tablets coming from both sides (android and windows), the separations make decreasing sense (eg denying desktop users touch functionality, or android users high-res/mouse/keyboard). Yes, there have been lots of pains.. but using something like this so that you only have to target (known version of) webkit at least removes some of the issue. The jury is still out on whether it was a wise decision (I would have had to learn obj-c/java/at least one desktop UI framework, as well as develop and maintain at least 2/3 code-bases, so it likely would have been a similar nightmare), but i'm far enough down the line that the likelihood is it will stay that way (concern re: code theft is the only reason i don't say definitely).
There are quite a few apps that could be made that require not much more than a sophisticated todo-list UI though. A calendar app might be one off the top of my head that would benefit from a responsive UI.
Neither of these kits have a complete mobile story yet (I don't even think Xwt team is working on one). So, I'm not saying that any of this is useful for anyone with a same-view-code-for-mobile requirement, but I think it could be really soon. The Eto guys are working on the iOS backing and they already have some impressive demos running on each of the major target desktop platforms from a single code-base. Anyway, I just like them sorry for hijacking :)
The way i see it, a minimum expectation (for 'universal' coverage scenarios) is: windows, iOS, android. Perhaps OSX too. There are cross platform solutions for the desktop, but that would still require 2 extra versions to cover the minimum standard. Soon you might be able to do iOS with Eto, but until it gets android support that would mean you still need to implement the mobile UI twice and port the backend code at least once (a feat that i thought was harder when i started than i do now; but maintenance would still be hell).
So you might lead to the idea of doing a cross-desktop app and a webapp with phonegap etc for mobile. This allows you to support more platforms (WP7/8, FFOS, BBx, ubuntuPhone?). Tablets are going to want a more in-depth UI than a phone, so then you have 2 layouts.
By the time you have a flexible layout system, adding a third may even sound preferable to porting everything to .NET, even if you are familiar with it! Yes you want extra features such as keyboard/mouse support, and more in-depth editing etc, but you do get the nice bonus that your android app will have those too (benefiting stuff like the transformer prime), as well as keeping all touch function on the desktop where touchscreens are taking off-- that probably wouldn't seem worth adding if it were a separate desktop app (same for smaller window-sizes). It's very reassuring to know that almost any feature implemented should work across all platforms. You could even extend a basic version for PS3, wii, TVs, chromeOS etc without too much trouble.
There are definitely shortfalls; lack of code privacy, still some browser issues on the mobile side (scrolling?), the DOM sucks, localStorage is tiny, etc! Phone processing improvements are fast whittling away at performance as an issue for many types of basic app though. IMO neither method (HTML vs 'native') are there yet, and different apps will suit each approach. To me cross-mobile/desktop apps are the future, although i concede that it isn't practical (or possible) for a lot of use cases today.