Author Topic: Will the new SlickEdit version will use the Aqua® "Human" Interface for the mac?  (Read 19263 times)

slickEditFan

  • New Community Member
  • Posts: 1
  • Hero Points: 0
I love the mac and I love SlickEdit.  However when I loaded SlickEdit for the mac, it is just looks uglier than the SlickEdit windows version.  Will the SlickEdit development team build a SlickEdit version that uses the Aqua® "Human" Interface instead of the X11 for the Mac Os? 

-- SlickEdit Fan

ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
Currently, there is no planned release date for a version of SlickEdit that is implemented using a native interface for Mac OS X. If there are changes we can make within the framework of the existing X11 implementation, we would be happy to consider them. We have done a lot to improve the font rendering, spacing, and other issues. Though this may not compare to a native implementation, it does allow us to mitigate some of the issues.

--Scott

magpie

  • Senior Community Member
  • Posts: 100
  • Hero Points: 5
This is so bizarre. When you go to the new product overview page at http://slickedit.com/products/slickedit the first word used to describe SlickEdit is "multi-platform", yet after all the hassle they have got over this, they can't find the resources to make a Mac native version.

For what its worth, see http://www.betanews.com/joewilcox/article/Apple-has-91-of-market-for-1000-PCs-says-NPD/1248313624

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Statistics are funny things, they are so open to interpretation...

For example, when I read that Apple has 90+% of the market on $1000+ computers, the first thing that comes to mind is "Apple costs more, so um that's not even necessarily a good thing for Apple...".

magpie

  • Senior Community Member
  • Posts: 100
  • Hero Points: 5
I spend an average of over 10 hours a day on my machine, a Mac Book Pro, so I might as well have the best. I'll never have the best car on the road, but I reckon I have the best laptop. Years ago it would have cost close to A$10K but now its around A$3.5K. The Mac Book Pro is often (models change) the lightest, slimmest, fastest machine on the market with the best display and keyboard and longest battery life.
I was a Windows user for around 14 years, and didn't like MacOS before X, but after a year with a MacOSX I'm not going back.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Saying that company X has 90+% of the market on $1000+ computers does not say anything about the revenue content of that market segment -- it is a statistic detached from relevant business context.
For example:
- How big is that market segment compared to the entire market?
- How much overlap is there between that market segment and the audience for a given product such as SlickEdit?

If I were a Mac user I'd want a UI makeover for SE.
But I'm a Windows user, and I still dearly want a UI makeover for SE.
It's not just Mac -- Windows and Linux and etc are in the same boat!  :)

And yet, as much as I want a UI makeover, there are things that score higher on my wish list and benefit  many platforms at the same time:  such as improving IO performance on the vtg btree and putting background operations on background threads and other responsiveness/performance/scalability issues.  The SlickEdit Team has the challenge of balancing cost/benefit both to users and to their revenue stream.  It is certainly a complex challenge, but I think they are up to the challenge.  :)

Graeme

  • Senior Community Member
  • Posts: 2793
  • Hero Points: 347
It would be interesting to know what the technical issues and work involved with getting a nicer version for the MAC are.  I don't know much about X11 but maybe it's possible to make a new X11 for the MAC that maps to the native GUI.  You can't blame slickedit for not providing something that has no payback.  Maybe slick could have skinning for all platforms?

I see that wxWidgets has only alpha support for the cocoa API on the MAC so I wonder how many cross platform applications on the MAC use the aqua look and feel.

Edit : according to this, Apple's X11 gives x11 apps the aqua look and feel.
http://macosx.com/forums/unix-x11/287112-aqua-x11.html
What's that all about?

Graeme
« Last Edit: October 31, 2009, 02:17:55 AM by Graeme »

magpie

  • Senior Community Member
  • Posts: 100
  • Hero Points: 5
Saying that company X has 90+% of the market on $1000+ computers does not say anything about the revenue content of that market segment -- it is a statistic detached from relevant business context.

"According to NPD, in June, nine out of 10 dollars spent on computers costing $1,000 or more went to Apple"

It _is_ revenue - not the number of boxes.

For example:
- How big is that market segment compared to the entire market?
- How much overlap is there between that market segment and the audience for a given product such as SlickEdit?

US$1000 isn't all that much to spend on a computer, especially if thats what you use all day. The Mac audience is
professional users. A fair share would be audio & video creative types, but a quick look around at non-Microsoft
developer conferences would show the predominance of Mac users.

The SlickEdit audience is professional programmers - willing to spend hundreds on a licence. I would think the
audience overlap would be very significant. However that probably isn't reflected in SE sales as the Mac incarnation
of SlickEdit just doesn't look or feel right among other Mac programs, and is much more expensive than say,
TextMate, a very polished Mac only program (less powerful but very popular).

If I were a Mac user I'd want a UI makeover for SE.
But I'm a Windows user, and I still dearly want a UI makeover for SE.
It's not just Mac -- Windows and Linux and etc are in the same boat!  :)

And yet, as much as I want a UI makeover, there are things that score higher on my wish list and benefit  many platforms at the same time:  such as improving IO performance on the vtg btree and putting background operations on background threads and other responsiveness/performance/scalability issues.  The SlickEdit Team has the challenge of balancing cost/benefit both to users and to their revenue stream.  It is certainly a complex challenge, but I think they are up to the challenge.  :)

I have had a SE Windows licence since V4.0 and had no significant complaints about the UI.
At least
1) I could drag a file into the Window to open it
2) double clicking an associated file worked every time
3) When a modal dialog box appeared, clicking the program window didn't bring the program window
in front of the dialog box, causing me to hunt for the dialog before I could proceed
4) I could use the build window as a command line
5) it had a normal print dialog with marvellous settings, like which printer I want to use

I think of SE as like I think it was Luke Skywalker starting up the Millenium Falcon
"The fastest piece of shit in the universe" but with some rework could be the Ferrari of
text editors on all platforms.

chrisant

  • Senior Community Member
  • Posts: 1410
  • Hero Points: 131
Saying that company X has 90+% of the market on $1000+ computers does not say anything about the revenue content of that market segment -- it is a statistic detached from relevant business context.
"According to NPD, in June, nine out of 10 dollars spent on computers costing $1,000 or more went to Apple"
It _is_ revenue - not the number of boxes.

What matters for the SlickEdit company is not how much revenue computer manufacturers get.  What matters is the revenue content of that market segment for SlickEdit, i.e. how much of that market segment wants to buy SlickEdit.  The statistic needs to be accompanied by statistics directly related to the programmer editor market.  The two markets are different.


For example:
- How big is that market segment compared to the entire market?
- How much overlap is there between that market segment and the audience for a given product such as SlickEdit?

US$1000 isn't all that much to spend on a computer, especially if thats what you use all day. The Mac audience is
professional users. A fair share would be audio & video creative types, but a quick look around at non-Microsoft
developer conferences would show the predominance of Mac users.

The SlickEdit audience is professional programmers - willing to spend hundreds on a licence. I would think the
audience overlap would be very significant. However that probably isn't reflected in SE sales as the Mac incarnation
of SlickEdit just doesn't look or feel right among other Mac programs, and is much more expensive than say,
TextMate, a very polished Mac only program (less powerful but very popular).

For example:
What is the size (in units) of the computer market under $1000?
What is the size (in units) of the computer marker over $1000?

Saying "company X has 90% of a market of unspecified unit size" is too abstract a statistic to speculate about business decisions such as spinning up a costly porting effort.

I'm only saying that the kind of information required to make such a decision has not been presented.

I visited the article again, and it specifically stated:

Quote
Market Share 101
Microsoft and OEMs measure success in unit market share, which for combined Windows PC shipments is over 90 percent, according to Gartner and IDC. In the United States, Mac market share was a paltry 8.7 percent in second quarter, according to Gartner. The bulk of PCs sell for less than $1,000.

According to the article, there are more than 9 PCs per 1 Mac.  In order for the Mac SlickEdit market to be within 50% of the PC SlickEdit market, 50% of all Mac owners would need to buy a SlickEdit license.  While Mac users may be professional and all willing to pay hundreds of dollars for an editor, it seems a bit of a stretch to expect a huge percentage of all Mac users to buy SlickEdit.

jkwuc89

  • Senior Community Member
  • Posts: 199
  • Hero Points: 6
With no inside knowledge of the decision making process, my educated guess with regards to using X11 for the Mac version is this.  Coding to the X11 API set allows the SlickEdit dev team to get support multiple Unix style platforms with a single UI code base (HP-UX, AIX, Sun, Linux and Mac).  The only UI code base that is probably significantly different is the Windows version.

Building a new Mac version that leverages the Mac UI framework (Cocoa) would probably be a rather large undertaking and would result in three separate UI code bases to maintain.  To justify this, SlickEdit must weigh the cost of developing and supporting this versus the potential revenue stream.

Don't get me wrong.  I would LOVE to see a Mac version that leverages the Mac UI framework.  And I would gladly purchase such a version.  But, I suspect economic factors are preventing this from happening.

Matthew

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 990
  • Hero Points: 44
With no inside knowledge of the decision making process, my educated guess with regards to using X11 for the Mac version is this.  Coding to the X11 API set allows the SlickEdit dev team to get support multiple Unix style platforms with a single UI code base (HP-UX, AIX, Sun, Linux and Mac).  The only UI code base that is probably significantly different is the Windows version.

Spot on.

Building a new Mac version that leverages the Mac UI framework (Cocoa) would probably be a rather large undertaking and would result in three separate UI code bases to maintain.  To justify this, SlickEdit must weigh the cost of developing and supporting this versus the potential revenue stream.

It's not so much a revenue or cost/benefit issue as it is a time/personnel issue. It also puts us at a difficult crossroads with regards to how our UI is implemented. The "mapping" between X11 code and Win32 code is not trivial, but they do have a lot in common, esp with regard to window element hierarchy, event/message loops, etc. If Carbon were still a viable choice, it would be a much easier decision to make, as Carbon event handling (and to a lesser extent the graphics rendering primitives) are a pretty good fit with the existing Win32/X11 structure.

I would love to tell you that we've got a native Mac version in the works. But that is not (yet) the truth. But we are spending a lot of time looking at our options for re-invigorating the UI. We have looked at using 3rd party frameworks like Qt, as well as simply creating another "fork" in our existing UI code to use Cocoa.

There is also the issue of how "faithful" a native Mac implementation should be. It has to serve 2 masters: 1) Aqua guidelines and Mac user expectations, and 2) SlickEdit customer expectations.

Stu

  • Community Member
  • Posts: 59
  • Hero Points: 0
A QT port would ROCK! No more 10 year old ugly oddly behaving motif framework.

Tyrathect

  • Community Member
  • Posts: 5
  • Hero Points: 1
I too would love to see more mac support, but my issues are around functionality.

The support for obj tagging, symbol completion, and "intellisense" coding for objective c was really lacking prior to v2009 (when I stopped using slick edit).

Support for xcode projects is incomplete, and lags behind the current release.

keyboard support (which is geared for X11) conflicts with the apple platform's native keyboard layout.

X11 on the mac requires a mouse click to focus on any window.  That click isn't passed down to the interface, so a second click must be used to actually select anything.  This is a pain in the a** when windows are floating.

BTW the post above about X11 looking native on the Mac is from 2001, and isn't accurate.  X11 on the mac looks like vanilla x11 on any other platform.

Slick Edit's response to all of this has been, essentially, "wait for the next version" which 1) still lags behind since apple continues to progress, 2) still doesn't support objc well, and 3) costs $100.

I've been a long time SE user.  A REALLY long time se user, but I had to give it up when I started working on the Mac.  It just didn't work for me (sadly).

I would love to see some TLC around this issue, but I understand the decision.  The "squeeze to juice ratio" just isn't high enough.

garion911

  • Senior Community Member
  • Posts: 201
  • Hero Points: 13
As someone who's worked with Qt occasionally over the years, its a really nice crossplatform API.. It should cover most of the cases you have.. There's a few exceptions of course..

Once you get used to working in Qt, you'll be surprised how quickly things will move along.. It does take some getting used too, but its a very nice api, as opposed to some of the others I've tried.

And if you're looking for Qt devs, let me know ;)


ScottW, VP of Dev

  • Senior Community Member
  • Posts: 1471
  • Hero Points: 64
I think that if you look at my posts on this topic you will find that we have not been promising a native version in "the next release". Most have been vague but say that we don't currently have a plan to release a native Mac version. By that, I mean that it is not assigned to a specific release nor is the work scheduled.

When we first did the X11 version for the Mac, it was a very natural decision. We were already using X11 on 5 other platforms, so it didn't take a lot to get it working for the Mac. At that point, we fully expected to have a native version within a release or two later. Unfortunately, the amount of work necessary was more than we could handle and still make progress in other key areas.

We would definitely like to release a native Mac version. We are still looking into ways to make this happen. Trust me when I say that no one outside of SlickEdit can appreciate the level of work that will take. SlickEdit, the product, is over 20 years old and has a lot of custom code to optimize its performance and our ability to code on multiple platforms.

As discussed before, there are two main ways to go: 1) hand code new platform code for the Mac, or 2) use a cross-platform library. Both have advantages and disadvantages. Hand coding the new interface may (not sure) take less time but the effort only benefits the Mac platform. Using a cross-platform library will also allow us to improve our look on Linux as well as Mac. But using a cross-platform library puts us at the mercy of a third party. If we use QT, what happens if they go through another version change like they did from 3 to 4, where the whole API got overhauled? If we use QT, will we still be able to use our form editor and Slick-C API for interacting with the GUI?

As Tyrathect points out, being native is just one needed improvement. We are working to improve the Xcode support, but that is a challenge in its own right. And, yes, we need to do some work on the Objective-C support. This, too, is not simple. Objective-C is the oddball of the C family of languages and isn't broadly used on any other platform. Our language support lumps the c-like languages together, and we have to be careful that enhancements for Objective-C don't mess up our C/C++ support, which is our bread and butter (maybe we should be saying "cheeseburger and fries" by now  :)). We have similar challenges with C#.

And I will ask the revenue question: if we make all those changes, can we sell enough copies at $300 to pay for the work? When all that work is finished, we're still competing with Xcode, which is free, and some other editors that cost considerably less than $300. Lowering the price just increases the number of licenses we need to sell to reach break-even, which is a concern in a niche market.

If there was an obvious solution to all of these issues, we would already have released a native Mac version. Instead, these are hard choices that come with major costs and risks. So, we're still looking into the best course of action. I'm sorry that it has taken this long, particularly since some of our customers, like Tyrathect, have switched to other editors.

I don't know if this kind of explanation is the TLC you were looking for, Tyrathect, but it's all I've got right now. I gave you a hero point for the most concise list of functional issues in the Mac version.