The recommended way to set up SlickEdit to manage LibreOffice is as follows.

Set up an empty workspace

Go to Project – New… and click on the Workspace tab. Select Blank Workspace, set a good workspace name (such as libreoffice-master), then set the path to the workspace to be the root of the libreoffice source tree + /slickedit. For instance, if your source tree is located in /home/foo/libo/master, then set the path to the workspace to be /home/foo/libo/master/slickedit. When the editor asks you to create a new directory because it doesn’t exist yet, select yes to create the directory. This will create a new workspace file (.vpw) under that directory.

Add projects to the workspace

Once you have an empty workspace set up, it’s time to add projects to this workspace. It’s best to use a single project to manage a single module i.e. have a project for sc, another project for svx, and another for sal, and so on.

To add a new project, have that empty workspace you’ve just created open, and go to Project – New…, check Add to current workspace check box on, type in the name of the module (sc, sal, sw etc) into the Project name box. In the Project Type window , select Other C/C++ as the project type. Make sure that you leave the “Create project directory from project name” check box unchecked, and that the location points to the same directory as your workspace. Then click OK to proceed.

It now asks you to add files to the project. To do it, click Add Tree to launch the “Add Tree” dialog. Set the path to the base project directory (for sc, it should be <root dir>/sc, and so on), specify the file types to include all used file extensions (*.c;*.cc;*.cpp;*.cp;*.cxx;*.h;*.hh;*.hpp;*.hxx;*.inl;*.xpm;*.hrc;*.src;*.xcu;*.xcs;*.hdl is a good one to use), make sure the Recursive check box is checked, then click OK. You will have to manually add several extensions that this project uses, such as *.hrc, *.src, *.hdl and so on which the default option doesn’t include.

Repeat the above process for all the modules you want to manage.

What projects to add to workspace

First off, you shouldn’t add all modules in the libreoffice source tree to the workspace, since that would overwhelm SlickEdit’s tag database, and will slow down the editor. Instead, we recommend that you only add modules that are relevant to the work you are doing.

For instance, if you are working on the Calc part of the code base, it’s sufficient to only add sc, formula, and sal. The sal module includes definitions to the rtl::OUString and rtl::OUStringBuffer classes as well as rtl::math functions, so it’s good to add that project to the workspace no matter which area you work in.

If you use UNO API’s a lot, then it’s a good idea to add solver as a project, but only add files that are under solver/<inpath>/inc/offapi and solver/<inpath>/inc/udkapi to enable auto completions of UNO structs, enums, constants and so on. Make sure you add *.hdl files as well as *.hpp files under these directories.

If you work on a wide range of areas, then it’s recommended that you set up multiple workspaces for different areas of focus. Switching between workspaces is very fast in SlickEdit, so this set up should not cause any loss of workflow efficiency.

How to update the workspace tag database

SlickEdit uses one tag database per workspace to allow context-sensitive source code navigation. The tag database file is named after the workspace name, located in the same directory where the worksapce file is, and it has a .vtg extension. It so happens that, when you update your git tree, the source code is updated, but your tag database isn’t. To update your tag database,

1. Close the editor
2. Remove the .vtg file under the workspace directory
3. Re-open the editor

Once the editor sees the the tag file is missing for the workspace, it will re-tag the entire workspace.

 

This post was written by Kohei Yoshida and was reposted here with his permission. The original may be updated and/or extended and can be found here.

One of our excellent community members who is new to SlickEdit took the time to make a great keyboard guide: Philip’s Keyboard Guide to SlickEdit (with Vim emulation).

He shared it with our community here. Check it out and share any comments you have to help him expand it for both beginners and experts!

 

SlickEdit has exhibited at the Game Developers Conference (GDC) for the past several years. Despite the many benefits of social media, there’s no real substitute for being able to meet your current and future customers in person. So each year we shuffle off to San Francisco to show the flag for three days. It’s a great opportunity for us to show off our latest features and introduce our products to those who are new to software development. And we also enjoy the quick “thanks for a great tool” visits from current customers. The most satisfying thing to a software tools company is knowing that your customers are using your products to make really cool stuff. And the Game Developers Conference is packed to the rafters with really cool stuff.

But if all we accomplished was in-person advertising, we probably wouldn’t invest the time, money, and effort required to set up a 10′x10′ booth for three days on the other side of the country. What really makes exhibiting worthwhile is the ability to keep our fingers on the pulse of the industry. We find out firsthand what languages, tools, and platforms are trending. And we can gauge what types of features and functionality prospective customers are looking for, and what they like (and don’t like) about the current tools they’re using.

Some observations from this year’s show…

Unity buzz

Mobile gaming platforms have exploded in the past few years, and the tools to support creating games for those devices are riding a wave of popularity. Unity had a very large presence this year, and they generated a considerable amount of excitement at the show. Fortunately for us, the built-in source code editing tools for Unity, while free, leave quite a bit to be desired. (I will not name said editor out of respect to the feature-challenged.) It’s no exaggeration to say that 1/4 of the folks that wanted to demo SlickEdit were looking for a decent code editor for their Unity projects.

Teach your children well

Many of the attendees at the show are university students, taking courses in software development and in some cases game development specific curricula. Note that these are not your typical four-year college Comp-Sci majors, taking courses in compilers and data structures. Rather, these students are mostly in two-year degree or career oriented certificate programs. A few years ago it seemed that the vast majority of these two-year students were learning Java, and primarily using free tools like Eclipse. This year I was pleasantly surprised to find that students are not being fed a diet of 100% Java, but are also being exposed to C/C++, delving into scripting and utility languages like Python, Perl, and Bash, and are being introduced to version control systems as part of their coursework. I’m hoping some of these real-work-world skills are finding their way back into the four-year programs.

Why aren’t you people using version control?

One of our features that really resonates with SlickEdit first-timers is our Backup History, which keeps an incremental versioning history of your source files each time you save. We like to think of this facility as a safety net between version control check-ins. When demoing this feature I usually ask what version control system folks are using, and I am met with far too many blanks stares. For every chin-high steady-of-voice declaration of “I use Subversion”, or “We use Perforce at the office, and I use Git at home”, there are an equal number of sheepish shoulder shrugs, admitting that nothing is in place. Well, good luck to you…

Flash is alive and well

Despite Apple’s decision to banish Flash from iPhones and iPads, plenty of Flash-based games are being written. And that means plenty of developers need to edit and navigate ActionScript source. When we first added proper ActionScript support to SlickEdit a few years ago (again, due to demand we witnessed at GDC), we assumed that demand and usage would taper off and die in a couple years. That assumption was wrong.

The art of trade show swag is suffering

The past few years we’ve been bringing USB flash drives to the show, with all the installers for our products pre-loaded. But our “fun” giveaway hasn’t changed for the past 5 years. It’s what I refer to as the “bouncy spider”, or “octopus yo-yo”. It looks like a multi-colored sea anemone suspended from a bungee cord, and you bounce it up and down. It has no useful function (besides attracting folks to our booth), but it’s always the hit of the show amongst the giveaway goodie cognoscenti. Usually someone else at the show has an equally cool giveaway. But not this year. The monotony of an endless sea of t-shirts, notebooks, knit caps, logo-ed plastic bags, and ballpoint pens was disheartening.

Overall we had a great, successful trip and will definitely be venturing back to San Francisco at the end of March 2013 for the next GDC! What was your experience at GDC this year? Leave a comment below to share!