[Qgis-developer] Questions and suggestion on build setup

Tom Elwertowski telwertowski at comcast.net
Mon Dec 4 17:53:31 EST 2006

William Kyngesburye wrote:
> I was messing around with an Xcode project for Qgis and noticed a couple 
> oddities in the build (this is with preview 2 source):
> - projection selector is built as a library, and is not in the plugins 
> or providers source folder, so it seems to be a core library for Qgis, 
> yet it is installed in the plugins folder.  Shouldn't a library be kept 
> with the rest of the libraries?  The grass provider library does.

I think it was an experiment in creating a Qt custom widget. From the 
viewpoint of Qt Designer and the development process, it's somewhat like 
a UI plugin. At runtime, however, it's essential to have the widget 
present; it's not optional but could perhaps be replaced by an alternate 

We seem to have three classes of extras: Qt widgets, QGIS providers and 
QGIS plugins. Implementations of the first are required, the third are 
optional and I'm not fully sure about the second. Some providers are 
optional but would QGIS work without the OGR provider?

Some extras are more important that others and perhaps should be sorted 
into different folders for QGIS 1.0. As a product in development, 
however, some of these distinctions are still fuzzy. Tim periodically 
lobbies for greater use of UI widgets; when we implement more, we may 
get a better feel for where they belong. For now, I have no objection to 
the projection selector being installed in either place.

> - the scalebar plugin is the only one that has 'lib' prefixed to its 
> name, and has mixed case:
> libScaleBarplugin

libwfsprovider also has the prefix but is not mixed case. My preference 
is not to include 'lib' if 'plugin' or 'provider' is part of the name.

A related oddity is that most qgis libs have version 1.0.0 while raster 
and msexport have version 0.0.0.

> Also, a suggestion for the Mac app packaging - organize it more Mac-like 
> in the package.  Something like:
> Contents
>     Frameworks
>         qgis libs
>         Qt frameworks
>         other bundled shared libs
>     Headers
>     MacOS
>         qgis
>         qgis_config
>         qgis_help.app
>     PlugIns
>         qgis plugins
>         qt plugins
>     Resources
>         all share/qgis stuff
> The plugins is an odd one, because 'plugins' is the name of the Qt 
> plugins folder, and 'PlugIns' is the standard OSX plugins folder name.  
> Qt plugins I think needs to be in the samme place relative to the qt 
> frameworks, but I don't know for sure, and there is probably some way to 
> set that at runtime.  On a normal OSX file system, the case difference 
> in the name shouldn't be a problem, but it would be on a case-sensitive 
> HFS+ or UFS disk.
> The only changes needed are the resources and plugins path functions, 
> and in the help app for locating the help data.

Personally, I like using the same paths as *nix so that changes made by 
a *nix developer are likely to work on a Mac with no extra effort.

Most, maybe all, path names are encapsulated in accessor functions in 
the QgsApplication class. You can try reorganizing the directories 
yourself to see how feasible it is. If you get it working, you can give 
us the changes.

A related issue are the helper applications. If really going the Mac 
path route, they probably should be in a 'Utilities' folder alongside 
QGIS rather then inside the bundle, especially apps like msexport, 
gridmaker and spit.

Also, Qt 4.2 is now available as a dmg file so you might want to try 
that as well. (Look in the 'previous versions' link which is actually 
the complete Qt distribution directory.)

I'm more interested in rearranging dialog boxes (Qt 4.2 does support Mac 
ordering of OK and Cancel buttons) than bundle directories but you 
should feel free to try this yourself.

> PS. Xcode project is almost done, I'll turn it loose later in the week.


More information about the Qgis-developer mailing list