Vanilla 1.1.1 is a product of Lussumo. More Information: Documentation, Community Support.
Frederick
and I don’t quite like the way the tabs look
You’re the man. :)
Hmm. Another thing. I’d really like it to be a preference whether to open a new tab for new files or just to open in the same Intype process (same tab), by default, since I’d like to be more in control of tab creation (as it opens a new process for every tab – lots of memory waste)... That would be super-ultra-awesome ;)
Oh, come on, i’m not a magician :)
This is almost impossible.
Can’t it just automatically send opened files to the same process every time (if that’s the preference)? And then if you hold Ctrl or something and open a file, it could create a new process… But if you say it’s impossible, then okay. Sorry I’m so greedy.
Oh… i’m afraid i missunderstood you :). I thought about patching Intype’s WndProc and integrating tabs directly into intype process :)
You can drag & drop file to existing Intype instance… but i’ll do such option in next version
Ah, oh. Wooo. Great. :)
Edit: A bug report – I’m noticing some serious redrawing issues that won’t go away. They seem to be caused by hiding hidden/CVS/SVN files and then opening subfolders of the project. Or just clicking where a hidden folder/file should be… It’s behaving really weird, not selecting anything, or selecting/opening the wrong file etc…
que – brilliant. I need to change my jeans.
I can’t believe I stay away from the forum like a day, and this happens.
Stand up work.
Could you just edit your first post and change the download link there?
And hey, I used Ashen!
Oh my… You’re like a squirrel in a wheel… I can’t stop speeding the wheel up to see how fast you can run before you drop dead :D
que: * Added option to reuse active Intype window for new file (Ctrl + double click)
Could this behavior be inverted with a setting in the preferences, please oh please? :) So double click opens in the same window and Ctrl + double click opens a new tab.
And maybe middle click to close a tab?
I didn’t notice this before when I was checking today, so… que, you’ve been featured on the Intype blog. Congratulations! :)
Bug reports:
Alt+Tab is buggy, I guess because of there being two processes and just one window… also, clicking in the Intype editor area doesn’t switch focus to that window. And there’s a black line below the Intype menu.
Frederick
It is impossible to fix black line and i can not reproduce alt+tab and focus issues
Have another window open above IntypePM, then click in the editor area to switch focus. And it doesn’t bring IntypePM to the foreground. Is this impossible to catch because Intype and the PM are different processes?
Alt+Tab switches to the PM when you’ve got focus on the editor. Edit some text, press Alt+Tab.
que: Your PM is really cool, the only thing that bothers me a little is that I can’t switch the files opened in tabs with keyboard (like Ctrl+TAB or Ctrl+PageDown/Up). Is there a way to switch them with keyboard? Or even better, is it possible to add this feature to the PM itself? :-)
Frederick
Ok… now i see and will try to find the suitable solution…
centi
Yes, it’s possible… and i’m working on it right now
que
Great!
this is great, the dev team can really lern from this, from the comunity’s requsts!
Que: Are you shore about the donation? You already saved me amounts of time (and money)...
btw, I have a problem when opening a second file, the painting of the window gets scruded up. Please see:
However when I drag the treepanel (to increase or decrease it) everything looks OK again. Is it possible to repaint the application after opening the file? Would be really nice!
Also, at a certain offset, inside the editor area, the cursor shifts to a normal cursor from the text cursor. And it seems like the scrollbar is activated when clicking there… Does this have something to do with putting Intype’s window inside another? I’d actually be really happy with just a separate window, like it was at first… (but with separate focus as well) because I need the project files available for other tasks as well, not just Intype editing, so that might actually be handy, as a separate “mode”. Could it be made into a preference?
I don’t know if this has been mentioned, but the tree on the left resets for no apparant reason. I initially thought it was because the files were getting updated, but it happened even without that. I tried minimizing/maximizing immediately after, but this didn’t work
Good shit though.
Shak: I was a little afraid to use Intype since I would need a new instance for every file I edited, but with this, I guess I can go ahead and start using it :)
Great work Que!
Just remember that it technically still IS a new instance for every file you open. GDI resources and memory usage shoot up quite quick. I like to keep just three or four tabs open at most at any given time.
It would be great if there was a button to hide the project manager pane, so that only the resize bar was visible, or perhaps just allow it to be resized so it’s very thin?
This would help get more on screen when editing files, especially as InType currently doesn’t have horizontal scrolling or word wrap.
Thanks again to Que for an really sweet piece of software :)
I don’t think requests for Search & Replace functionality belong here, wouldn’t that be a bit too much? I see this as a helpful tool to ease the transition to Intype’s own feature additions in the future. And it will very soon get S&R, and tabs. I don’t know when the first basic PM will be added to Intype, but I hope there will be something happening in that department before 1.0, even if it’s very very basic…
Few things:
baael: I think that’s a pretty poor idea. I want a project manager integrated into the core of Intype—it’s a pretty resource-hungry program, and having 8 tabs open in IntypePM means 8 instances of Intype. From purely that standpoint, it’s a poor argument—and it’s also not the only one.
que: any headway on what I wrote?
[edit] typo
Yeah, this is a temporary solution that que has accomplished, and the separation of PM and editor isn’t a model that should be followed in the future.
When Intype gets its own PM, only one instance of Intype will have to be open, and no other processes. The PM should be readily and quickly available when editing a file (I don’t want to have to restart Intype), and it should be possible to hide the PM drawer/sidebar/tool window completely, so it won’t be in the way.
Also… “editor as light and handy tool to fast and easy use” – um, that should be the case even if it gets a PM built-in. :) I don’t think the developers will ever let Intype get slow or bloated.
The idea of separate PM and Editor is already in use in various other projects and it works. Last time I encountered this was in PIDA, which integrates Vim as the editing component in order to create an IDE like application. Instead of building something new, the developers thought of reusing powerful existing solutions.
So, I think that I might agree to the PM being a separate application. The “bloatedness” of the current state would go away as Intype supports multiple files internally.
I just wanted to express my immediate thoughts on the subject.
Cheers,
Nick
A PM and some additional features will probably not add that much to the loading time… if that’s what you’re concerned about. I get your point about the different use cases, but I don’t REALLY see the point in actually separating the two “modes” entirely (when it won’t add much overhead at all (I think) to have just one executable for it all), it’s just going to cause problems and annoyances (I suspect). (In general I have to limit myself to just thinking and suspecting since I’m not an Intype developer…)
A more smooth solution perhaps would be to allow the user to have different settings when launching Intype with commandline parameters (files or folders), from any kind of file explorer that would do that, or from the commandline. You could set it to automatically hide the PM, if you wanted. But I think it should ALWAYS be accessible at the press of a button.
There’s nothing wrong with a huge powerful machine when it’s got a smart, unobtrusive design and only adds a split second to the loading time.
avinashv – I’m experiencing the same problem with the File listing resetting, and it’s driving me nuts. I know this is a temporary solution, and I really appreciate the effort, as I can now almost use Intype in development. But the fact that the file tree keeps resetting is preventing me from using it.
Also, I think I narrowed it down. Any time I commit changes via subversion or navigate around my site in development (when webrick makes a call) the file tree will reset.
Do you think this would be difficult to fix? I would love to use Intype. Thanks.
I got the problem to replicate — I have a command prompt open, and when I give it focus, the file list resets. Very strange.
rpheath—to fix the problem, I put the executable in the directory root where I want to work. Eg. in my c:/htdocs/project folder. That way the reset will at the very most take me down to the root of my project.
avinashv – I suppose that might work, but I’m currently building a system that involves 4 other systems (specified as their own projects) because it’s an aggregate of services, which can be stand-alone or act as one application. So I currently had the .exe in my projects folder, where I have all four project folders listed out. That allows me to access the random API files that I need when I need to add a new method.
Anyway, I may just wait until the Intype team releases the project manager view. I’m ok to use another editor until then. Thanks for the response!
Project freezed until new Intype build with native tabs support is released.
Small update: build 47
Download: intype_pm_1.0.0.47.rar
Great as ever – thanks Que. The improvements to the treeview are really nice!
slapukasss – Yep, you right. We need to focus to the editor area to get it active again, PM always focus to the tree when we switched back from another application. Hope some improvements will come soon.
