Today marks a big achievement in the development of Scribus 1.3.5. As of now, we no longer use Qt3 or its support classes. YAY. A big job – one that started out as very simple but right at the end took awhile to get finalised. Its a nice feeling to have that sorted and now we can get on with stabilising the other changes and heading towards a release (not imminent, but approaching at least).

Well, we said CMake rocks, but after the time we have used it, we have generally come to like it. So far it has provided our escape we wanted, and given us more flexibility and ease of build system modification. A generally good experience all round you could say.

Well thats all very nice, technically, but this post is just a big thank you to the CMake team that have helped me with the migration task, and in more recent times, quick fixes into CMake, and fixes into our CMake setup. I had made some mistakes initially and it wasn’t until this week that I had time to track it down as discrepancies between building here and on other devs’ machines didn’t make sense. You know… clean checkout, clean build of CMake and Scribus… builds fine here. Same clean versions on another box… splat. In the end, it was a mistake in my code and the CMake guys spent the time to find it… simply outstanding support. Another vote from me goes their way.

It is not uncommon that when a program like Scribus grows so quickly and gets so many features added in such a short amount of time that some cleaning is necessary now and then. Throughout the 1.3.x series we have cleaned a lot of code up, fixed a lot of bugs uncovered by the cleaning, as well as continuing to improve the whole internal view of things.

So far in the 1.3.4cvs timeframe I have not had a lot of spare time as I started a new job (yay!) so the major rewrites of the 1.3.0->1.3.2 that I was able to do before were put on the backburner. In this time Andreas has been going nuts with the text system rewrite.. amazing stuff is happening there. So, in my spare time I’ve been testing, discussing etc but that gets a little boring after awhile, so this week I decided to remove one of the bugbears I’ve been hanging to do for a long time. That is, remove the global extern ScribusMainWindow* ScMW and then fix up all the resulting mess. This was used for easy access to the main window and its code in a previous lifetime where a lot of the main document code was held within the main window itself as well as a general easy (read nasty) way of finding your way back to the main application.

So, having just committed updates to about 90% of the Scribus files in 1.3.4cvs :), what does this aim to achieve? Primarily, moving the bulk of access down a layer into the document. Theres still a lot of leftover code that now just goes doc->scMW() however once this is eliminated we can start to run more operations without a GUI (read command line) or with multiple GUIs (read SDI mode). Hopefully I removed all the uninitiated pointers around and added ones where necessary :). Still works ok here, but we never said the changes in 1.3.4cvs were not going to get a little bumpy at times :). Heres to a big change, that took a week of spare hours at nights. On ya guys.. 1.3.4 will be a major step forward with all the cool transparency stuff and text and the to-come style manager from Riku and.. and.. and…

Finally, loading of 0.x, 1.x, 1.2.x and 1.3.x=>1.3.3 file formats is now coded with the FileLoader plugin. Work can begin fairly quickly on the file format code for 1.3.4, OR at least which was my main urge to get this code done: massive format changes for Andreas and Riku to support inherited text styles, Unicode reading and writing instead of control characters, etc etc. This will mean that we will no longer need to safely change 1.3.3 loading code.. its handled separately now. To do: File saving of 1.3 docs via the plugins, and.. if anyone got adventurous, saving back to 1.2 format.

Update: Saving of docs to 1.3.x format is done.
Update: Created a new 1.3.4 plugin for loading and saving. This is now the default plugin used.

After much wailing, gnashing of teeth and general procrastination by many.. today’s show is brought to you by the letters w, o, r, k, i, n and g! The aging (read, since 1.3.1) FileLoader plugin system can finally load a Scribus 1.2.x document without the AGES old scribusXml.cpp anymore. All very technical for those that just want to do publishing, however what it does mean is that once the work is complete, we can bring you a cleaner loading and saving system. Fewer, or preferably no modifications into old loader code for old format docs when adding new features to the new formats. Most importantly, this means that finally we can begin the 1.3.4+ format to handle the new text features. I think that can start next week.

Yeah, seeing MrDocs’s first blog leads me to add a note about CMake as well. Honestly, the autotools system that we inherited was utter crap given its complexity, however it did probably serve its purpose well in its intended environment (building part of KOffice/KDE). It was overly large and for the autotools newbies, a real barrier against making changes to Scribus. Ok, adding a single file was generally ok, but we saw issues with moc running, uic running, and most of all tree-based file locations and adding new checks for dependencies.

Our CMake system is not finished, but its doing a good job so far. It took me about a week from CMake newbie status to at least generally understanding how it works and having Scribus building. Running the very latest CVS was a major help as the KDE guys have switched and enhancements they required helped me out. Once CMake 2.4.2 flows into the distros out there, we will more than likely dump autotools completely, so whens that? Well.. Maybe after 1.3.4 is released.. but you never know…

Finally we made it online with a blog. Well, everyone else is doing it. Time to have our say to all the people who might bother to read it.