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


  • Community Member
  • Posts: 61
  • Hero Points: 1
Another vote for Qt support.

Consider a component of the Netbeans UI (not a Qt UI, bear with me here). The Project view is fully functional for organizing your files in the project structure and doesn't require that you go to the shell or file explorer to manage your files only to have to return to the ide and open an entirely separate dialog to remove and add the *same* file just because it changed locations on disk. Likewise checking out a file from source control (or doing any kind of project global update for that matter) will automatically add the file to the project by virtue of it existing within the project structure (and yep, you can right click on the project and run update to do an update rather than leave the ide). And speaking of source control, if source control is enabled for a project: moving, adding, or deleting files in the project view seamlessly translates to the associated source control command. Not only, that, but right clicking on a selection of files will let you specifically operate on that group of files.
I present this as a use case because I feel like using a library such as Qt, at first might be an adjustment, but overall will free you from the shackles of platform specifics in the UI and let you concentrate on making a UI that services us better... on every platform that we have a license for. The project view alone is something that really impacts me as a developer who works in visual effects on really spread out code bases (with multiple build methodologies... thanks to slick-c is trivial to handle btw) that get updated incredibly frequently, and are branched per-film requiring us to frequently manage the same project in multiple locations with slightly different requirements determined by the status of the repo when the show started (It's chaos! What would I do without you Slickedit?). I need the UI components to be as agile and functional as the editor.

I'm fairly new to SlickEdit but I have license on Linux, windows, and Mac out of my own pocket so that I can work efficiently either at a studio or independently from home if need be. It's important to me that my money is not just going into keeping a 20 year old code tree afloat but also going into improvements in the overall workflow of the program and I think Qt (which I use professionally almost every day... it's really nice!) is a good step towards that goal. Even Motif/Win32 stalwarts which were born on Irix are now being converted to Qt (Maya).

So yeah, love you guys and love your work, not trying to sound like I think you're doing a bad job or trivialize the effort required to magically jump to a new UI, this was just an impassioned plea for a UI upgrade (I don't care if it's two versions away, I'll be here haha).


  • Senior Community Member
  • Posts: 100
  • Hero Points: 5
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.


I'm not surprised that the SlickEdit codebase would be a bit crufty after so long, so many versions, platforms and so on. Maybe its time to look at a next generation :
1) to move towards open sourcing the macros (but not the core)
2) to move to a more modern script language than SlickC eg. Javascript for better 3rd party tools & libraries, more availability of engineers, and to involve the community more in development of the macros
3) to better support the current UI platforms
4) to reinvigorate the product and community
5) to create a new architecture knowing all that you do now, but didn't 20 years ago eg. one that supports unit testing of the macros
6) to support plugins, like TextMates "bundles"

SlickEdit is an undervalued alternative to the other slow, bloated, Java based IDEs, and represents an alternative vision for IDEs that is more editor-and-command-line-centric, rather than endless mouse driven UI bling. The trouble is, its not a good implementation of that vision. It seems to get slower and more bug-ridden with each release, and is ignoring (or only giving half-hearted support to) modern trends in development, like open source, unit testing, git, and dynamic languages.

Of course the issue is expense of development, but you have a lot to begin with - engineers experienced with building an editor, heaps of existing source code to draw from etc, so its not like starting from scratch.

I'm afraid that the alternative could be a long slow death of the product, unless something else appears with the same vision that blows SlickEdit away more quickly.


  • Senior Community Member
  • Posts: 162
  • Hero Points: 27
  • Synergex
2) to move to a more modern script language than SlickC eg. Javascript for better 3rd party tools & libraries, more availability of engineers, and to involve the community more in development of the macros

While it would be nice to have support for a more common scripting language, you have to consider that there are OEM's with Slick-C code bases that rely on much of the editor elements remaining reasonably unchanged. There is a great deal of time investment that ties those customers to the product. Trying to maintain those customers while reinvisioning the editor could present the Slick team with a sticky problem. Would you risk existing customers and satisfaction for some unquantifiable amount of potential customers that may be attracted to a slightly more modernized version? It's hard to say.

Really, Slick-C is not a difficult language to learn. There are some quirks and APIs that certainly take some getting used to, but it's fairly easy to just sit down and start coding. Reading through existing source reveals most of the tricks that you could ever need to know. As far as scripting languages go, Slick-C is surprisingly fast, robust and mature.


  • Senior Community Member
  • Posts: 100
  • Hero Points: 5
Ease of learning doesn't address the lack of modern features like objects that promote good software engineering practices such as abstraction, encapsulation, Do not Repeat Yourself (DRY) etc., and some of these are required to be able to unit test production code.
There are good reasons why people use slower languages like Java for new projects over C.

Also it would greatly narrow the field of software engineers interested in working for SlickEdit, and even more greatly reduce the community involvement in developing SlickEdit or extensions to it.

I realise it would be a major challenge, but seriously something needs to be done for the future of SlickEdit.


  • Guest
Thank you for your interest in SlickEdit offering a native Mac version. We are excited to announce that native Mac support will be offered in 2012. View the announcement here: