Hacker News Reader

Comment by powerslave12r | Hacker News Reader

Awesome! Can someone comment on how probable it would be to port it to linux (and windows)?

OK, so I've been looking through the code and from what I see I suspect a big reason for the rewrite was to move huge chunks into platform-independent C++ for an ultimate Win32/Linux/Mac trifecta release (maybe for TM3). If so, this would explain why things got so bogged down.

The actual layout/folding code, for example, is in C++. When it needs to draw it calls Core Graphics C functions. A lot of the other things like commands are similarly abstracted. But the thing is, if you look in Frameworks/layout/src/layout.cc for example (the code that actually lays out the text), it looks like nice platform-independent C++ code. Ah, you think, this will be easy! Until you get to, say, CGRect layout_t::rect_for (row_tree_t::iterator rowIter). The return type is CGRect and it's calling CGRectMake. These are Mac-specific Core Graphics calls. The drawing code is similarly Mac-specific.

So the first thing you'd need to do is follow the architecture and start TRULY abstracting the core functionality into these C++ classes and, when they make a call to something platform-specific, you'll need to replace it with something platform-independent.

To do this, you'll need to:

- Make or move to an abstracted Graphics Context library. You could use something like Cairo or roll your own (which is what WebKit does).

- Further abstract the application structure away from the actual classes. So, for example, you would have platform neutral code to talk about the UI logically but then have each "MyWindow" C/C++ class hold a "PlatformWindowHandle" which, on Linux might be a GTKWindow pointer, on Win32 might be a Window HANDLE or COM object reference to a .NET Window, and on Mac be a pointer to an NSWindow. You'd obviously need similar platform-neutral library infrastructure to call into each of these with a similar API and translate to the platform actually running at the bottom. You could write this yourself, or you could maybe just use wxWidgets or some other library that's had a decade-long head start. You lose some control that way, though.

- Repeat with all other areas of the app that are still Mac-specific.

My opinion is this would be a good starting point for such a thing, and if you really wanted to make it happen you could. But you're NOT going to just go in there and replace NSWindows with GTKWindows and NSButtons with GTKButtons and call it a day. It will be MUCH more work than that.

Would it be easier to rewrite it for one single cross-platform backend, like Qt, than maintain a mix of platform-specific code?

I think one of the appeals of TM1 was that it WAS a native Mac app and felt like one. Qt apps never 'feel' completely native, so if you went down that path you'd end up with an awkward, substandard, non-native text editor and might as well be using Sublime Text.

as ugly as it may look, it seems like targeting something like GNUStep may help out with the portability issues. then you really only need to worry about the Mac-specific APIs.

Well it's all in Obj-C, so either a non-OS X Obj-C compilation tool or rewrite it out all out of Obj-C.

Doable, but I don't think many people will be queuing up for the task.

Erm, Objective-C probably isn't the problem, even NeXt used gcc for that (not sure how much of the current feature bloat isn't in copyrighted libraries).

But GNUStep isn't exactly up to par with Cocoa, never mind not exactly the default desktop environment. Porting the whole editor from Obj-C++/Cocoa to C++/KDE or C/Gtk would be a pretty huge task, where you'd better off starting from scratch anyway (as with a lot of GUI apps, it's mostly about the ideas, not the implementation).

Don't quote me on this but I don't think the later versions of Obj-C run on gcc, but llvm/clang. Whilst thats available outside the Mac realm it depends on whether it's specifically modified.

But yeah, you're right the Cocoa aspects are the bigger overhead, I should have been more clear.

Cocotron[1] attempts to be up to part with Cocoa though. I'm not sure if it would cover everything needed by TM, but it would be a pretty decent start.

[1] http://www.cocotron.org/

Considering that the only reason GNUStep isn't considered a totally failed project is the existence of Hurd, I wouldn't bet my money on creating a reasonably up-to-date cross-platform Cocoa/OpenStep clone. Try to see if the base Objective-C++ is working alright and create a GUI-independent layer, at least that way you'll get your native look-and-feel for free. But looking at the code, I think that'll excisce a lot of the core TM tech, so whether it's worth the conversion effort instead of just starting brand new is a pretty good question.

> Erm,

http://twitter.com/karlvanhoet

Context?

From casually looking through the src tree, core looks to be mostly c++, with obj-c++ glue.

Browsing through the code, Objective-C seems to be used for the UI, but the guts of the code (the Frameworks directory) is in C++.

I have mixed feelings about TextMate going open source. If QuickSilver is any indication, it will now definitely take forever for a new release. Dang! and I seriously don't like ST2.

It's better than nothing. The lack of activity means the author isn't very interested in continuing the project. But you can find another lead developer to run the project, at least. That's the merit of open-source.

I believe the TM developer is still very interested. I believe he thinks this is the best way to get TM moving again.

That's just my opinion. Time (and commits) will tell.

Actually, Quicksilver gets updates on a regular basis; it's now 64-bit and Mountain Lion compatible: http://blog.qsapp.com/post/27968374731/mountain-lion-is-upon....

I know and it's great, but from Alcor released QS as open source until it was picked up and new proper releases started to emerge, it took 2-3 years? So waiting 6 + 2 years (in the best case) for TM2 is too long even for me. RIP TM2.

Define "new release," because Quicksilver's core app and plugins are being updated rather frequently now for bugfixes. As far as adding new functionality, that might be right but what else do you need core QS to do? It would be nice to have an additional plugin or two but as far as core QS, I can't think of anything it doesn't do that I would like it to.

If TM isn't updated much, then it's because of the same reason that QS is not updated much anymore, because most people moved on to something else and are no longer interested in it.

Regarding raw text editing, Notepad++ (on Windows) is vastly better than TM.

Good thing Textmate has never set out to be "The best raw text editor" then.

And really who cares how some Windows program with a fraction of features and capabilities is compared to a Mac app

there's E the text editor, which the last time i checked was a TM1 clone

An abandoned clone.

Reply on news.ycombinator.com