Vanilla 1.1.1 is a product of Lussumo. More Information: Documentation, Community Support.
Hi,
The latest unstable release is really a while back :(.
Any idea when can we expect a new one? (I’m talking here about unstable).
Thank you,
Demetrios.
i 2nd to the Q
3rd.
I see the todo has had a recent update, good to see things moving forward, but it’d still be nice to hear from the team a little more often :) .
Hi guys, we are still around. We are spending all our energy to the next unstable 0.3.5. I’ll get back to you ASAP with some dev and features details.
zzzzzz….....
martincohen: Hi guys, we are still around. We are spending all our energy to the next unstable 0.3.5. I’ll get back to you ASAP with some dev and features details.
Any news about an unstable release? It’s been quite a while since we asked :).
Demetrios.
Hi guys, intype really rocks. But I missing some feedback about next release. Hope’s it will be soon :)
Intype 0.3.1.730 Unstable has been released. The release contains some critical bug fixes, and some great improvements in speed and memory management. It is last unstable for 0.3.1, and we are actually working on 0.3.5 (codename Newcastle) for few weeks now, which is our main interest. All versions prior to Newcastle were built on widget toolkit called SmartWin which turns out to be a headache for several reasons.
It’s not that SmartWin itself is a bad toolkit, it just don’t fit Intype’s needs for the UI anymore. Due to it’s C++ template architecture, the compile time was too demanding. Compiling SW required like 1GB of RAM, and took like 10 minutes to build whole release. The new framework is based on good old school with simple dependencies, is much more powerful for building custom widgets and it cost us like 1 minute to recompile whole project.
To design a simple editing interface, with all the features that are planned, it was unbearable to continue with SmartWin. New Window’s Vista comes with UI strongly requiring support for themes, and SW is simply surprised by this (wxWidgets as I’ve seen it has the same problem). Newcastle’s framework is able to handle that even in platform-independent manner.
In the new toolkit (that is built as a platform-independent API) we have powerful layouting engine combining sticky and grid-based layouts (not seen in MFC, wxWidgets, or VCL). It’s win32 version is reflecting almost all subtleties of Windows API, has a powerful signal/slot system, the docking system, JS-awareness, and Intype’s command scoped-triggering system built right into it’s core.
You might noticed, that when you press Ctrl+P (Show Scope), the scope that is displayed contains more than a document scope names taken from the grammar. It also includes the application (app.global), the editor (app.editor) and editor’s state (app.editor.default). This is concept of thing we call Global Scoping. This will enable you to scope a JS-command not only to the editor, but also to the project manager, the console, the log, or even to the Bundle Editor’s editing component. And everything just by using scope selectors. So building a TortoiseSVN JS-based plugin is matter of proper scope and few lines of JS code to launch a TSVN’s dialog to handle the operation.
In general, one of most important steps in 0.3.5 would be a replacement of standard multi-line edit control by our own editing component. So all the editing features you love will be available also in the Bundle Editor, or Search Dialog. We also have new parsing task manager that is routing parsing requests from multiple editors and forwarding those tasks to dynamically created parser threads strongly supporting multi-core processors. Which itself is a great step forward to split-screen editing. Newcastle also includes Mozilla’s JavaScript engine – SpiderMonkey, which is used to built the JS API.
The Bundle Editor (which is actually also available in latest .730) needs much more control of the error states you may run into during the development of your own snippets, languages or JavaScript commands. That would be also reflected in 0.3.5. The plan is to finish all Bundle Editor’s main features for 0.3.5.
So enjoy the .730 and look forward to 0.3.5.
Thanks a lot for the great .730 release – it rocks! I really appreciate all the teams hard work :)
However 0.3.5 sounds completely awesome and I can’t wait!!!
My first reaction to the Bundle editor was ‘Cool’ and then ‘couldn’t this editing pane be an Intype instance?’ – I see that, as usual you’re many steps ahead and you’ve got that covered in 0.3.5. All the other Newcastle features sound brilliant and right on the money, as per usual. Proper multi-core support – something that most other editors lack and JS scripting throughout.
On a related note, now that the codebase is building quicker, I think that there might be a case to be made to release nightly or weekly builds. Given that the current ‘unstable’ builds are, in my experience, completely stable and usable for daily work – it seems silly to call these ‘unstable’. How about continuing with the current release schedule but calling the ‘unstable’ releases ‘milestones’ or ‘snapshots’ or something and also releasing truly unstable weekly builds as well.
The weeklies could probably be (semi?)automated – i.e. codebase built automatically on Friday evening and automatically FTP’d somewhere – and should come with a disclaimer that they might not even work.
I think that this would give people who want it access to newer code earlier and keep the ‘when’s the next release coming’ stuff to a minimum and help build a more active community. This is also what a lot of other companies and projects do, both open and closed source.
Opera, for example make weekly builds available most weeks during development phases of their closed source browser. These builds often have quite a lot of breakage and don’t always work on all platforms but are appreciated by the community. They also provide early feedback and crash reports to Opera. A lot of open source projects take this further with nightlies and whatnot, but I don’t think that’s necessary.
What do you think?
Thanks a lot, Martin. Plans looks very promising, serious work. Bug fixing made Intype usable for me again.
dflock: Actually, we have three branches of the releases:
We are planning to merge the Stable and Unstable branches (and remove labels of the releases) and publish the Cutting Edge releases… so I think we pretty matched your suggestion.
noobsaibot: Actually, it’s now only an acronym AF. Windows version is called AFW, GTK+ version is called AFG. But maybe it will inherit the name of the Newcastle release :) It has nothing in common with MFC’s AFX group. If you have some idea for a name, let me know.
mvm: Glad to hear that. It was really a pain to move from 0.3.5 development back to 0.3.1 to sync some bug fixes for this release. It is completely different animal. :)
Martin: Good to know – always one step ahead!
This is great, thanks! I’d stopped using Intype due to the bugs in the previous release, but this rectifies all those, so I can use it again :) .
The unstable release RSS post states that bundles are now loaded after Intype starts. That seems to be true, but there’s noticeable pause before syntax highlighting actually kicks in (for me it’s about 3 seconds). I’m suspecting that Intype loads all the bundles it finds and only after it’s done it starts applying grammar rules to the open files. If that is the case, wouldn’t it be more efficient to load only the grammars that are immediately needed by Intype, then the snippets, scripts and other bundles?
Great work with .730 release. The 0.3.5 sound’s oustanding. Can’t wait :D
Applause!!
I was really close switching back to SciTe today but figured I would give the Intype release page another view and there it was just waiting for me to download.
hurray!!
WOW, martin this time, i have got to say- I’m absolutely AMAZED and blown away!!
Great plans for the future! but what is the rough estimate on Newcastle’s (0.3.5) AirDate?
Keep on the wonderful work!!
Ingwar: Well, the grammars are included one in another. It actually is a graph of dependencies. HTML uses CSS, JS, PHP, then PHP uses SQL, and so on. At the startup, we don’t know what grammars you have, or what dependencies between grammars are, or what grammars you will need for opened files (we have to parse it before you know it). One way or another, we have to load the grammars to know the dependencies. But traversing and loading from the hard drive is 99% of the overall grammar processing time. So I see no point in smart optimization of what grammars should be loaded, or postponed.
Languages are currently loaded and applied as first, then the bundle loader continues with snippets.
So only reasonable optimization here is to lower the needs for accessing myriads of tiny files on the hard drive:
yarden: I’m not very happy to say that we cannot predict the date. There’s an option of creating a separate discussion thread where we will publish previews of the Newcastle, but I cannot promise that either.
WOW, its not dead. the developers are working on the next release. it takes a lot of time, since, they have another income source – a job, its hard to juggle between all the others issues in life.
my fingers are burning
1 to 26 of 26