Quick answer to the guy who used yesterday's Form Experiment to ask what's happening with SdiDesk ...
Here's the status report :
1) In the last couple of weeks I quit my job and moved back to the UK ... which has been taking up quite a lot of my time and energy.
2) Once we've settled in, I hope I can get some time to focus on my projects ... including SdiDesk (and GeekWeaver, MTC etc.) The good thing, no more distractions from my previous demanding day-job. The bad thing, after a brief holiday I need to find work in the UK. (Offers, tips and suggestions are, of course, welcome)
3) SdiDesk was converted to VB.NET this year. And the source-code in progress is available on Google Code.
4) I am NOT a VB.NET programmer, and frankly, from the little I've played with it so far, I'm not very excited about getting more involved. I admired VB exactly because the combined language + IDE made Windows programming mindlessly easy. Throw away that virtue (as VB.NET seems to have done, and I'm blaming the new, incredibly sluggish and cluttered VS2008 as much as changes to the language) and it has little to recommend it against other languages.
5) On the hand, I'm a pragmatist and often able to find something interesting pretty much anywhere. I also know that in a recession I may not be able to be too fussy when it comes to getting a job. So I will be spending a bit more time over the next month or so tidying up the VB.NET codebase, fixing some egregious issues, and making an installer. It's going to be useful to me to be able to say that I can operate in the VB.NET world, and produce working products.
6) Longer term, my preference and commitment is still to a Python SdiDesk-like thing. And most-likely a Python server with UI in the browser (javascript etc.) I've cooled towards the idea of Flex (mainly because my trial copy expired and I remembered all the problems of depending on proprietory software)
The attraction of anything other than the browser has always been the vector drawing in the network diagramming part of the software. But I'm sure that if I just wait a little bit longer, the browser will eventually be able to handle this too.
7) As always, I'm not unaffected by user feedback and other things going on in my life :-) ... if there's suddenly a surge in interest or demand for a VB.NET SdiDesk then I may reconsider.
8) Joe Question asks : "how risky is it to commit myself to SdiDesk.NET then? What about all my pages?" Answer : SdiDesk.NET reads your existing PageStore files. There may be some issues with the size of the diagrams, but everything works. If it doesn't, tell me.
However, you can't even try SdiDesk.NET currently unless you're a VB programmer because it's only available in source form. There will certainly be a build for end-users this year and it will read your existing PageStore. The main reason you want this is if you're an existing SdiDesk user who has moved (or will move soon) to Vista where the old VB6 version won't run.
I'm always committed to upgrade compatibility. You'll be able to move your existing SdiDesk pages to SdiDesk.NET, and you'll be able to import them into a future Python version.
3 comments:
My choice would be a browserclient (javascript) and a php/mysql (widely available on cheap hostingaccounts)serverside scripts to handle the ajax calls. The serverside could be easily ported to another platform.
It could also be interesting to take a look at adobe aire and to make the app run localy.
I did use sdi-desk for sometime and did like the loose wiki-way of 'structuring' data.
The calendar and schema modules make it really powerfull.
Maybe combining outlining with sdi-desk could create a whole new kind of application. I.e. a split screen where on the left a tree displays the outline and on the right the page is displayed. If you added tags to a page then would even have a third way to access the same data (switch between wiki, tree and tag view).
Just some ideas.
Hi Pieter,
thanks for the comments.
Yeah, and thanks for corroborating the browser-as-interface position.
Most of the time I think it's *got* to be that. And then I see some kind of slick UI written in something else and think "maybe I'm wrong". But most of the time I reckon that this is right.
And yes, the mixture of types of data+input (plain text, tables, diagrams) is part of it. If I can find my way towards an outliner in the browser, then that too (I asked here ... http://stackoverflow.com/questions/257188/library-for-browser-based-outliner without much success ... but actually the most impressive thing I found, and did some very interesting experiments with a couple of years ago, was Sproutliner http://sproutliner.com/ )
Server-side, my obvious preference is for Python. And that's certainly easier (IMHO) for a stand-alone desktop system than PHP. Naturally, I think it's good for a hosted solution too. But I agree PHP is more widely available.
I've been reluctant to take SdiDesk in a "hosted" direction because there are a lot of wikis out there. :-) If SdiDesk becomes to much like A.N.Other wiki, it's not quite clear what the point of it is.
SdiDesk was very much focused on creating a "personal" tool for individuals NOT a shared tool for communities. Of course, today, I think the distinction has to break down. We'd like our personal tool to allow some pages to be published or flagged as "collaborative". And we can expect that our computers are nearly always connected to the web.
So at some point SdiDesk will have to have a public server component. In which case, maybe PHP has a role. But expect to see Python first.
cheers
phil
I agree that the stand-alone is the key-feature of sdi-desk. Solutions like google app-engine and amazone s3 are nice but i don't believe you should store private data in the cloud. But the option to publish (parts of) your data online should be there (that could be your business-model, a free standalone app for the desktop with an optional hostingplan to publish and exchange your data with other users).
Publishing should be important i think, its great as an application for loose-structuring your data, but it should also offer ways of exporting this data to html, pdf, txt, doc etc.
I don't know about an outline library but i do have some experience with writing an outline-app for the browser (www.opmlmanager.com) so maybe i can help you on that part.
I worked with flex sometime ago and you can build a very good looking user interface very fast, but it does have some big disadvantages when you want to work with html, flash's html engine is very poor. There are some very good looking javascript UI libraries (ie http://extjs.com/products/extjs/), but there is always a risk in using third party software that you do not fully can control.
Post a Comment