Yes, your referenced link WAS a general comment regarding mobi and epub, which has evolved a lot in the last two years.
I imagine this book, since it's from CUP, will be available as a Kindle purchase if not now then very soon. I've been purchasing textbooks for the Kindle for awhile now. My only complaint is typically the equations are included as images, so they can be very small.
How I wish MathML were a standard for academic publishing.
I suggested that link because it discusses what may work for the parent to get what he needs right now, instead of speculating a 'kindle version might be coming soon.'
The formats may have evolved, but I don't see a mobi or an epub version today. If you have a link, kindly post it.
I used Sublime Text 2 on all my machines for over a month for Python and C. It was great for about 90% of the things. But I ended up going back to jedit because of:
- The way split views are handled for:
a. The same file in multiple views.
b. Non-global scope on 'Ctrl+P' in multiple views.
- Better Highlighter plugin. (The existing ones for ST2 don't provide the same features)
- The Hypersearch (and the overall search/replace dialog) in jedit is awesome.
On a quick search I didn't find the options to get these preferences, but I'm sure they will come to be, if they haven't already. (Please feel free to suggest the options if I'm overlooking anything.)
That said, the reason I switched back to jedit is because I was much faster in it even though I had got a good hang of ST2.
Aside: I never see jEdit being discussed in these editor discussions. Personally, I feel it's the best editor out there today despite being dependent on the jre.
Same file in multiple views is actually possible but difficult to find: Under file you have to say 'duplicate in other view' (or something like that, I use Vim now).
I know how to achieve it, (File > New view into file), it's just not as natural as jedit (You just open different views and the current open file defaults to opening in the new view too).
If there's a way to set this up in ST2, please feel free to comment!
Oh sorry. I thought you didn't know how to achieve it, because I knew that I struggled a bit since I think the implementation is really cumbersome and I didn't expect it to be that way. My fault, sorry.
the last time i tried jedit (admittedly, years ago) i found the font rendering on mac os x to be ugly. since it's on your checklist, i assume it's improved since then?
I always genuinely care and end up looking like a smug asshole most of the time but there are a few times when someone does seem to feel really good that I care.
You should see how much meat they pack on my subs at the local sub place. ;)
It will be awesome when Spotify (or others) starts signing up bands as a "record label" itself, similar to Netflix produced shows. (Maybe they already do this?)
Maybe that will attract more bands to directly do business with them.
If they have invested in Spotify, then they are just securing their place in case Spotify (or Spotify-like services) displace the old model. It doesn't mean that is going to make any difference in the change of business model when it happens.
If they have too much control in Spotify, someone else will start a new service/label. OR bands will just self produce.
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.
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.
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.
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.
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.
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.
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 think Diaspora was crushed under its own weight. A few things I think that worked against them.
* Too much hype meant they had big shoes to fill before even writing a single line of code.
* Inexperienced team. I think they were all new college grads.
* Chicken and egg problem.
That being said, we're building federation (via OStatus) into OpenPhoto (it's already distributed). We're working with Mozilla and other yet to be announced partners. I don't think we have the chicken and egg problem.
I think the current gmail search is a lot better than what it was a few months ago.
I still wish they did page numbers for search results or something like that. (I'm aware of the manually editing the url hack, but it's not the same experience.)
