Re: [Qgis-developer] Planet qgis blog aggregator
Thanks for the update, Richard. Good luck getting it back online. It is a great asset. You’re work on it, and others also, is appreciated. John On Dec 12, 2013, at 12:26 PM, Richard Duivenvoorde rdmaili...@duif.net wrote: On 12-12-13 18:52, John C. Tull wrote: I recall some discussion about planet.qgis.org no longer working a few months ago. Is this something that the community has given up on fixing? Regards, John Hi John, there is work going on for putting it back. It broke on the old server, and we are trying to set it up in a easier to maintain/share way on the new server. Regards, Richard Duivenvoorde ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Planet qgis blog aggregator
I recall some discussion about planet.qgis.org no longer working a few months ago. Is this something that the community has given up on fixing? Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] How do I compile OTB-3.18.1 in Mac OS X / Any Mac OS X binary that works with OTB plugin in QGIS 2.0.1?
Hi Noli, The homebrew package manager has an orfeo formula. I just installed it, and it seems to work for me, although I'm not a user of OTB so I didn't do much testing. It is currently version 3.18.0, but I'm not sure if that matters or not. Cheers, John On Sep 23, 2013, at 6:25 AM, Noli Sicad nsi...@gmail.com wrote: Hi, How do I compile OTB-3.18.1 in Mac OS X? Any Mac OS X binary that works with the OTB QGIS 2.0.1 Plugin? I think we still need the OTB binary for OTB plugin in QGIS 2.0.1. Thanks, Noli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Saga and sextante on OSX
Hi everyone, I'm running trunk on OS X 10.8 with qgis dependencies built from source (most using the homebrew package manager). I also have a functional saga_cmd binary that I can use in my terminal to produce valid outputs. Unfortunately, sextante complains when I try to run a function: Missing dependency.This algorithm cannot be run :-( This algorithm requires SAGA to be run.Unfortunately, it seems that SAGA is not installed in your system, or it is not correctly configured to be used from QGIS This perplexes me. The appropriate path, /usr/local/bin shows in my qgis preferences. Sextante was also working at least several months ago in trunk. Can anyone provide any suggestions on what may be causing this to not work? Thanks, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] manageR update for 2.0
Hi Filipe, On Jun 7, 2013, at 3:37 AM, Filipe Dias filipesd...@gmail.com wrote: Using R via Sextante is also a good alternative. Shapefiles and Rasters are exported into R and it's possible to apply all sorts of R tools to them. There are a few good examples already in the algorithms tree. I will have to test this. The value of manageR is the familiar R console and the simple import/export of raster and vector layers into the workspace. Although manageR is marked as incompatible with 2.0, I have gotten it to run after a fresh installation in QGIS, but the import function is broken, so it is of little use. I'll look into the example R scripts and see how that works out. Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] manageR update for 2.0
Hi all, The manageR plugin developed by Carson Farmer is an excellent tool and brings incredible integration between QGIS and the R statistical analyses package in a native R environment. I was wanting to ask the developer community if there is any chance of seeing it updated for 2.0 compatibility? I don't know if it needs work for the new sip API or if it has more complex needs to make it work in 2.0, but I'm holding out hope that others would like to see this plugin make it through the 2.0 transition. Carson? Are you still out there and able to take a peek at the code needs? Am I the only user that recognizes and will miss the value of this plugin in QGIS? Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] manageR update for 2.0
Hi all, On Jun 6, 2013, at 12:43 PM, Alex Mandel tech_...@wildintellect.com wrote: On 06/06/2013 10:20 AM, Paolo Cavallini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 06/06/2013 19:12, John C. Tull ha scritto: Hi all, The manageR plugin developed by Carson Farmer is an excellent tool and brings incredible integration between QGIS and the R statistical analyses package in a native R environment. I was wanting to ask the developer community if there is any chance of seeing it updated for 2.0 compatibility? I don't know if it needs work for the new sip API or if it has more complex needs to make it work in 2.0, but I'm holding out hope that others would like to see this plugin make it through the 2.0 transition. Carson? Are you still out there and able to take a peek at the code needs? Am I the only user that recognizes and will miss the value of this plugin in QGIS? I also miss it. AFAIK there are additional problems in Windows, because of rpy2, right? All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Yes, rpy2 binaries are not regularly built for Windows. That's the only issue I'm aware of. I too love the power of this plugin. Thanks, Alex I am glad I am not alone. I only wish I possessed the skills to bring it up to date. Here's to hoping someone else does and can. Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] many SVG symbols disappeared
Hi everyone, On May 7, 2013, at 1:42 AM, Duarte Carreira dcarre...@edia.pt wrote: If we can get hold of the old symbology lib than that's fine by me. But please don't make us and others rebuild their entire organization's cartography just because you don't like the symbols. Thanks, Duarte An option to get the old symbols should suffice, right? Instructions on what needs to be done with these symbols for each platform might also be helpful. -Mensagem original- De: Tim Sutton [mailto:li...@linfiniti.com] Enviada: segunda-feira, 6 de Maio de 2013 21:56 Para: Olivier Dalang Cc: Nathan Woodrow; qgis-developer; Giovanni Manghi; Duarte Carreira Assunto: Re: [Qgis-developer] many SVG symbols disappeared Hi On Mon, May 6, 2013 at 2:31 PM, Olivier Dalang olivier.dal...@gmail.com wrote: I was asking that question on this thread : http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-t d5040508.html#a5046486 Maybe I didn't emphasize enough on the deletion of symbols... IMO, the most elegant solution is to keep only the good-looking symbols so we provide a simple and consistent library, and then to provide a link on the website to download the unmodified 1.8 symbol library in case one needs to keep full backwards compatibility (it's quite easy to install : you just have to replace the SVG folder in your installation folder). The whole pull request already breaks backwards compatibility with all other symbols, since by removing their background, the may become unreadable on most of the maps... So if the priority is the keep old projects looking the same rather than having a clean and consistent library, the best is not to change the svg library at all. (just as an illustration, do you really think it's pertinent to keep this in the library ? : https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_laye rs.png ) I use that symbol all the time! /sarcasm Yeah that ain't pretty... Personally I like Oliver's patch and I think we should clean up house for 2.0. Keeping compatibility is useful but most of my project files from 1.8 are already broken to some degree and I would prefer we do all the big changes in 2.0 and then become more conservative in subsequent 2.x releases. +1 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] composer export fails for maps with label shadows
Hi Régis, On May 7, 2013, at 12:40 AM, Régis Haubourg regis.haubo...@eau-adour-garonne.fr wrote: Hi, This morning I tried to export in pdf some multimaps composers. I encounter an error - not crashing qgis, but leaving composer blank - on maps using new dropshadows for labels. %Maybe it's related to blending or only shadows. I switched back to buffer, and it works OK, even A0. Anyone confirms? I've been producing pdf output maps from Composer using labels with drop shadows during the past week. Can you share the specific blend settings or, better, create a simple example qgs file you can share? Thanks, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GRASS shell
Hi Paolo, On Apr 30, 2013, at 3:08 AM, Paolo Cavallini cavall...@faunalia.it wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. On master, the GRASS shell embedded in the plugin seems to suffer from a minor, yet annoying, bug on Debian: the cursor is not displayed where the text is actually typed, bu one tab on the right: anyone confirms? Thanks. - -- Paolo Cavallini - Faunalia This is true on OSX also. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Hi Nathan, Here are both of your example programs on OS X. You will see that the menu observes the OS X HIGs with a File and Edit menu item in the main menubar of the OS for both of these applications. http://imgur.com/NaxyYMi Adding changes to Edit to the list of desired updates to the GUI takes this even further afield from standard interface design for OS X. I think you will be disenfranchising one of the supported operating systems with these changes and that it will make more sense to keep the File and Edit layout, in addition to cleaning up some of the other OS X gui issues, like having the Analysis menu item from plugins showing up between the Window and Help menu items. Regards, John On Apr 24, 2013, at 8:24 AM, Nathan Woodrow madman...@gmail.com wrote: William, I can understand the concern, it was the same thing that went though my mind when I change the composer menu. In the end most people didn't care, or adapted. There are a lot of applications that don't use a file menu and work quite well, I would say better in fact. http://i.imgur.com/t0QZeJK.png Chrome and Firefox http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg AutoCAD Regarding the Edit menu, you will notice that the tools in there are not related to text or documents they only refer to the current feature, or selection of features. If you have a dialog open you can't use that menu, unless the dialog is non model and in that case still doesn't help you as there are no tools to use on text. If the Edit menu is to stay, that is fine however I would suggest a new menu called Feature/s which houses all the current tools in the edit menu minus the Undo/Redo and Copy/Paste Feature. Regards, Nathan On Thu, Apr 25, 2013 at 12:17 AM, William Kyngesburye wokl...@kyngchaos.com wrote: Well, my original reaction when I saw the File-Project change was that it's very non-standard, and may cause more cofusion than it's worth. Certainly on OS X, maybe on other systems. People know what the File menu means, even if the main object of an application is a project, or video or email or whatever. Same goes for the Edit menu. And it's standard position is right next to the File menu. Undo, Redo, Cut, Copy and Paste are the basics for the edit menu, and should work in dialog text boxes for copying and pasting text, as well as whatever document editing they may do. Do not move Undo/Redo, more confusion. I realize that this may be Mac-centric, but the OS X HI Guidelines seem to be generally followed or adapted on other systems, and these File and Edit menu changes are a bit radical. On Apr 24, 2013, at 6:07 AM, Nathan Woodrow wrote: Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.au wrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour
Re: [Qgis-developer] 'File' versus 'Project'
Hi Antonio, I think it is more about having consistency for the platform than anything else. We want the user to find the application familiar. The death-knell of many an OS X application on review sites is how non-Mac-like the application feels. Users expect the menubar to exist and to provide a means of navigating standard application operations. Developers will provide their own customization in different formats. Microsoft Office has their ribbon interface that provides organized drop-downs and formatting elements outside of the menubar, but you are able to do most of the same stuff by navigating the menus and options therein. http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png I think we can achieve the customization desired while maintaining the HIG for OSX. Cheers, John On Apr 24, 2013, at 9:10 AM, Antonio Locandro antoniolocan...@hotmail.com wrote: I am having a second look at the menus and can I ask why would you want to crowd the menus with the same actions you already have icons for in toolbars? e.g. Edit menu has all the same tools as the Advanced Editing Toolbar (I highly doubt users doing serious editing would use menus instead of icons) Layer menu has all this add layer types the same as Manage Layer Toolbar (would look better with just an icon that opens a file dialog to whatever data you need, an universal add data button type) IMHO it seems a waste of space and makes things crowded Ing. Antonio Locandro Tegucigalpa, Honduras +504 9503 5747 Need a GPS map for Central America, Asia or South America / Necesitas un mapa GPS para Centro America, Asia o Sur America From: madman...@gmail.com Date: Wed, 24 Apr 2013 21:07:58 +1000 To: cust...@westnet.com.au CC: qgis-developer@lists.osgeo.org Subject: Re: [Qgis-developer] 'File' versus 'Project' Ramon, I would agree with those points. In fact I think the menu structure as is doesn't make much sense and the Edit menu should be renamed to Feature/s. What does Edit mean: - Edit Layer - Edit Feature - Edit Project If you look at all the tools in the Edit menu they are all related to the current feature or features. The undo and redo actions should be moved to the layer menu. Here are my thoughts on the Layer menu: http://i.imgur.com/oYO55Qz.png Moving the Add xxx Layer to the project menu would mean you follow these actions when creating a new project: Project - New Project - Add xxx Layer Change the style Layer - Properties That is a more logical flow IMO then currently what is there. Thoughts? - Nathan On Wed, Apr 24, 2013 at 8:21 PM, Ramon Andiñach cust...@westnet.com.au wrote: On 24/04/2013, at 05:55 , Ramon Andiñach wrote: On 24/04/2013, at 04:28 , John C. Tull wrote: Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John Interesting. I'd say this is going to look as odd at home on my mac as at work on their windows box. No file menu - that's going to look very unfamiliar. That said, it's a good name. It does describe what's in there - those commands work on the project-file not a layer-file. -ramon. Ok. I've been standing at the bottom of a large-ish hole today, so if this sounds like a dumb idea that's my excuse. Could we move Layer across next to Project? Some reasoning. 1. If we're abandoning File in favour of Project, then there's possibly no reason to retain Edit next to it either. Other than historical ones. 2. Project and Layer are largely about opening, closing, saving (and other similar things) files. Project files in one menu and Layers (vectors, rasters, DB, etc) in the other. 3. Then you have a more logical progression from left to right about how to use QGIS. (Open stuff, change stuff) -ramon. (OK, 1. is not so good, but it does open the door to ask questions!) ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Hi Larry, On Apr 24, 2013, at 9:46 AM, Larry Shaffer lar...@dakotacarto.com wrote: As a separate suggestion: if we wanted to minimize our menus better and prepare for unknown future functionality grouping and expansion, we could create a Tools main menu, which could have Vector, Raster, Database and Analysis submenus. This would make room for a Feature main menu, for example, and allow future growth within Tools without forcing yet more horizontal growth of the menubar. Downside is that it adds an extra layer of submenu mousing to get to commonly used actions. +1 This would help with the problem of the Analysis menu item showing up between the Window and Help menu items. I've often felt that a more consolidated approach like you describe would be much better. And we have the ability to customize all menu item functionality with custom shortcuts, so those that don't like the extra clicks can work around that by creating shortcuts. Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 'File' versus 'Project'
Hi Larry, On Apr 24, 2013, at 10:09 AM, Larry Shaffer lar...@dakotacarto.com wrote: Hi, On Wed, Apr 24, 2013 at 10:51 AM, John C. Tull jct...@gmail.com wrote: Hi Antonio, I think it is more about having consistency for the platform than anything else. We want the user to find the application familiar. The death-knell of many an OS X application on review sites is how non-Mac-like the application feels. Users expect the menubar to exist and to provide a means of navigating standard application operations. Developers will provide their own customization in different formats. Microsoft Office has their ribbon interface that provides organized drop-downs and formatting elements outside of the menubar, but you are able to do most of the same stuff by navigating the menus and options therein. http://www.geek.com/wp-content/uploads/2010/02/Office-for-Mac-ribbon-default-1024x614.png I think we can achieve the customization desired while maintaining the HIG for OSX. Ignoring the other suggestions for a moment, changing the File menu name to Project (or Composer) does not go against the HIG for OS X (the initial discussion of this thread). This has be established. It does affect user expectations, however. I think this is debatable. Per our irc conversation yesterday, there are semantics to what constitutes a document-basis for a program versus a non-document basis. My understanding of the exception in the HIG is that a program that does not have a document that the program operates on can consider removing or renaming the File menu item. From the HIG [0]: In general, each command in the File menu applies to a single file (most commonly, a user-created document). If your app is not document-based, you can rename the File menu to something more appropriate or eliminate it. I consider a map project to be a document, whether it is based off of a physical file, *.qgs, as it currently does or whether it is a record in a db, a possible feature for the future of QGIS. I don't see the wiggle room on the HIG for QGIS consequently. Regards, John [0] https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Menus/Menus.html#//apple_ref/doc/uid/TP3356-TP6___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] 'File' versus 'Project'
Hi all, I was having some discussion on IRC today with Tim and Larry about the recent change to the menu in trunk. Before, the menu used File and that was changed to Project. My position is that it does not seem Mac-like, whether or not a QGIS document resides in the filesystem as a .qgs file or if your Project is fed from a database, something apparently planned for the future of QGIS. I'd be interested in feedback from other Mac users on this. I'm flexible to the change, but wanted to vet this and see if anyone else had a strong opinion one way or the other. Please make it clear if you are a Mac OS X user or not. Thanks, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Possible memory leak in rendering code
On Apr 22, 2013, at 2:12 PM, Nyall Dawson nyall.daw...@gmail.com wrote: By the way, it would be a good thing to remove render caching completely before 2.0. In any case it will need to be reworked when moving to multi-threaded rendering... it has only a limited functionality of storing previously rendered map in each layer and reusing it in case the extent has not changed. Unfortunately the rendered image is stored directly within QgsMapLayer class - in order to work properly, the cache should be kept internally within each QgsMapRenderer instance. -1 from me -- please don't do this! I realise that it has some limitations, but render caching makes a huge difference in speed with my workflow. I frequently use layers based off complex PostGIS views which take a long time to generate. With render caching I'm able to selectively toggle layers on/off or rearrange them for comparison without having to wait for QGIS to request a new version of the view from the PostGIS server. If I switch off render caching then every change to layer visibility or ordering triggers a refresh of the view and a painful wait in QGIS. Obviously an ideal solution would be to cache the PostGIS layer locally, but until that's possible render caching helps a lot... Nyall Unfortunately, the render caching feature has never worked on OSX. It is a greyed out option in the settings because the code was never stable on this platform. If it is meant to be a program feature, it would ideally be one that is available on all platforms. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster saturation issue
On Apr 18, 2013, at 6:33 PM, Nyall Dawson nyall.daw...@gmail.com wrote: On testing saturation today, I did notice a potential bug with that setting. For my test raster, I set the saturation to 1 and the difference between that setting and 0 was quite large. If I move to 2, 3, 4, and so on, the differences are very small and incremental. I'm wondering why the leap in saturation from 0 to 1? Is something incorrect in the algorithm calculating saturation? It seems as the values between 0 and 1 need to be handled to make the 0 to 1 change as incrementally small as the 1 to 2. Can you create a bug report about this and attach your raster to it (if possible)? I'll take a look at this and see what's happening... Actually - I can replicate it here. Don't worry about attaching a raster. Nyall Hi Nyall, I'm just getting back to this, so I don't know if a bug report is still required or if you worked on it already. I'm building trunk now and will followup with a bug report if the issue persists. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Raster saturation issue
Hi all, I really appreciate the great new raster settings. These enhancements to QGIS are very nice. On testing saturation today, I did notice a potential bug with that setting. For my test raster, I set the saturation to 1 and the difference between that setting and 0 was quite large. If I move to 2, 3, 4, and so on, the differences are very small and incremental. I'm wondering why the leap in saturation from 0 to 1? Is something incorrect in the algorithm calculating saturation? It seems as the values between 0 and 1 need to be handled to make the 0 to 1 change as incrementally small as the 1 to 2. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] [Qgis-psc] Logo
I like the http://99designs.com/logo-design/contests/qgis-needs-logo-210397/entries/50 entry, but I would like to see it with the GIS slightly smaller so that it is not on the same line as the top of the Q. This would make the Q element of the logo/name more prevalent and would make the Q as a standalone icon for the application more identifiable, in my opinion. Regards, John On Apr 16, 2013, at 4:01 AM, Anita Graser anitagra...@gmx.at wrote: I could imagine that something following the idea of http://99designs.com/logo-design/contests/qgis-needs-logo-210397/entries/126 would work too. From all the submitted ones so far, I'd still go with http://99designs.com/logo-design/contests/qgis-needs-logo-210397/entries/50 I don't see any bird in http://99designs.co.uk/logo-design/contests/qgis-needs-logo-210397/entries/118 and I don't think it would work well as an application icon. QGIS has no animal. Do we want one? Or stick to the Q? In my opinion, so far, the consensus seemed to be that we want to stick with the Q at least. Best wishes, Anita On Tue, Apr 16, 2013 at 12:12 PM, Saber Razmjooei saber.razmjo...@lutraconsulting.co.uk wrote: I go for this: http://99designs.co.uk/logo-design/contests/qgis-needs-logo-210397/entries/118 It is an open source project, hence there should!! be some sort of animal (Q looks like a bird to me!) presence there in the logo! Cheers Saber From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Nathan Woodrow Sent: 16 April 2013 10:57 To: Larry Shaffer Cc: qgis-developer Subject: Re: [Qgis-developer] [Qgis-user] [Qgis-psc] Logo Could everyone have a look over the latest entries and provide some feedback. Regards, Nathan On Tue, Apr 16, 2013 at 9:13 AM, Nathan Woodrow madman...@gmail.com wrote: Hey Larry, Thanks for the feedback. I had the same feelings but kind of like the design, maybe just not for QGIS :) - Nathan On Tue, Apr 16, 2013 at 1:52 AM, Larry Shaffer lar...@dakotacarto.com wrote: Hi Nathan, On Sun, Apr 14, 2013 at 11:43 PM, Nathan Woodrow madman...@gmail.com wrote: What do people think of http://99designs.com.au/logo-design/contests/qgis-needs-logo-210397/entries/115 and http://99designs.com.au/logo-design/contests/qgis-needs-logo-210397/entries/117 Well, I don't like it. First off, I don't get it. At a glance, I have no idea what it's trying to convey or why there is so much text. Secondly, I think it is imperative for a logo design to offer a shortened square aspect, e.g. for an icon. The Q in QGIS obviously lends itself to this, and IMO works well for it; so I think a design that leverages that single character will be more versatile, than say one that only works well for a web site header. Regards, Larry On Mon, Apr 15, 2013 at 3:32 PM, Paolo Cavallini cavall...@faunalia.it wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 15/04/2013 03:14, Nathan Woodrow ha scritto: Hey All, http://99designs.com.au/logo-design/contests/qgis-needs-logo-210397/entries/64 In this case the logo as we use it now would be the Q, that is a black circle with the green arrow, right? Thanks Nathan for managing this. All the best. - -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlFrkP4ACgkQ/NedwLUzIr5+wgCePXM1yyku1L6tiV58VMljNQpH jnUAnjee/MUuExfhmbo2U11nhrbzRwfG =QeyB -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viru ses is
Re: [Qgis-developer] [Qgis-user] [Qgis-psc] Logo
Hi Alexander, On Apr 16, 2013, at 9:34 AM, Alexandre Neto senhor.n...@gmail.com wrote: If I can give my opinion, I don't dislike #50, but I think that that isolated Q won't be strong enough as an Icon. I believe that #91 and #88 (short and long version of the same design) would look quite distinct and sophisticate, would give a great program icon and looks very good printed too. http://99designs.com/logo-design/contests/qgis-needs-logo-210397/entries/91 http://99designs.com/logo-design/contests/qgis-needs-logo-210397/entries/88 Actually, I think I prefer this #88 entry upon second review. I agree with your point that the Q icon is more distinct. This also has the GIS portion of the logo reduced and offset from the top horizontal line of the Q as I was suggesting for #50. I also like the flow of uantum off the tail of the Q. Lastly, it looks like a Q. I believe that 2.0 deserves a brand new logo, so any of the old logo revamped styles (like #166, #49, #42) don't seam to be a good option. +1 Alexandre Neto On Tue, Apr 16, 2013 at 5:09 PM, Régis Haubourg regis.haubo...@eau-adour-garonne.fr wrote: John C. Tull-2 wrote I like the http://99designs.com/logo-design/contests/qgis-needs-logo-210397/entries/50 entry, but I would +1 for #50. I like also #57, the same but with a background. Both can be used in different contexts. régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-Qgis-psc-Logo-tp5046799p5047346.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] [Qgis-psc] Logo
On Apr 16, 2013, at 10:34 AM, Barry Rowlingson b.rowling...@lancaster.ac.uk wrote: If I could draw cartoons, we'd have Quentin the Qgis Quokka: http://a-z-animals.com/animals/quokka/ The quokka is qute. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New case study from Missouri, USA
Hi all, This is a great case example. I wonder if the custom plugin development is heavily based off of the Atlas plugin or is uniquely derived. Having the plugin available as a code example might be useful for others. Regards, John On Feb 19, 2013, at 7:05 AM, Otto Dassau das...@gbd-consult.de wrote: Dear Community, we have a new case study written by Brian Edmond. He is a Senior Systems Analyst in Computer Services at Missouri State University and has spent his career in the intergrade zone between biology and technology. The case study is about using QGIS to create maps of Historic Herpetofaunal Records in Missouri, USA. You can read it here: http://www.qgis.org/en/community/qgis-case-studies/missouri-usa.html Thank you very much Brian for your contribution! Kind Regards Otto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] new_vector_api merged
Hi Martin, Congratulations on getting this work done and the merge into trunk! I was able to build and things do appear as normal from my perspective on my OSX system. I look forward to the additional progress you've laid out. Cheers, John On Jan 26, 2013, at 10:48 AM, Martin Dobias wonder...@gmail.com wrote: Hi everyone I'm pleased to announce that new_vector_api branch has been merged to master. From user's point of view there should be ideally no change - everything should work as before, except for various plugins that will need update to support new API. With such extent of refactoring of vector layer code it is possible that some new bugs have been introduced - I hope there won't be any serious problems. I would like to ask people to test master branch with various data providers and report any regressions related to vector handling (e.g. access to data, editing or joins). I have also created a tag Before-merge-new_vector_api that points to the last commit on master before the merge - in case someone would like to stick with pre-merge code for some reason. What's next? osm, mssql and sqlanywhere providers are currently disabled - but they should be adapted to new API and re-enabled soon by their respective authors. QgsVectorLayer still has old API methods (select(), nextFeature() and featureAtId()). There are more than a hundred of these call just in QGIS code base. I have marked them as deprecated now - we should slowly get rid of them and finally remove them before 2.0. Of course the most awaited feature is the threaded rendering - experimental support should be coming in the following months, so please stay tuned. One of the next steps will be already mentioned move to newer sip/PyQt APIs for common classes like QString and QVariant that will simplify plugins' code and make them more ready for python3 (where the new APIs will be default). I would also like to look into support of python3, so that ideally QGIS 2.0 could be built either with python2 or python3. I expect that QGIS 2.0 will stick to python2 and QGIS 3.0 will use python3. Looking forward to the feedback from testing! Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Vector API
On Dec 28, 2012, at 11:27 AM, Alexander Bruy alexander.b...@gmail.com wrote: Hi Martin, just tried to build new_vector_api branch under 32bit Slackware 14.0: GCC 4.7.1 glibs 2.15 Qt 4.8.2 GDAL 1.9.2 SpatiaLite 4.0.0 Python 2.7.3 And get next error: /home/alex/devel/cpp/qgis/src/providers/spatialite/qgsspatialiteprovider.cpp: In member function 'void QgsSpatiaLiteProvider::loadFieldsAbstractInterface(gaiaVectorLayerPtr)': /home/alex/devel/cpp/qgis/src/providers/spatialite/qgsspatialiteprovider.cpp:619:23: error: 'class QgsFields' has no member named 'insert' make[2]: *** [src/providers/spatialite/CMakeFiles/spatialiteprovider.dir/qgsspatialiteprovider.cpp.o] Error 1 make[1]: *** [src/providers/spatialite/CMakeFiles/spatialiteprovider.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs -- Alexander Bruy Hi all, I ran into the same compile issue on my OS X system. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [saga-gis-developer] GNU/Linux build system 2.1.0
This forum thread has information on build commands for those OSX users that are interested in testing Saga: http://goo.gl/CIQkB Unfortunately, Sextante is not working with Saga at the moment. I get this dialog upon trying to test a command: It seems that SAGA is not correctly installed in your system. Please install it before running SAGA algorithms. For my system, 'which saga_cmd' shows '/usr/local/bin/saga_cmd'. Regards, John On Dec 18, 2012, at 1:00 AM, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. SAGA seems available for OSX also, so no tech problem in integrating it. All the best. Messaggio originale Oggetto: Re: [saga-gis-developer] GNU/Linux build system 2.1.0 Data: Tue, 18 Dec 2012 09:54:46 +0100 Mittente: Johan Van de Wauw johan.vandew...@gmail.com A:saga-gis-developer saga-gis-develo...@lists.sourceforge.net For Qgis I don't see many issues: the command-line version of saga works on mac os x. ___ saga-gis-developer mailing list saga-gis-develo...@lists.sourceforge.net mailto:saga-gis-develo...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/saga-gis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA modules (version 2.1.0) through SEXTANTE on Mac OSX
On Dec 19, 2012, at 2:49 AM, Victor Olaya vola...@gmail.com wrote: Olav, Thanks for your contribution! There is no option SAGA folder in the SEXTANTE configuration like you have when installing on Windows. I haven't checked on Linux, but I guess the Unixes don't need this, as long as saga_cmd is in the path, right? Right, Mac and Linux should work in the same way. Let me check, because maybe in Mac it is performing the same check as in windows (that is, checking that the SAGA folder is set...) Looks like an easy to solve problem...i hope Will keep you posted Thanks again! Victor It looks like I'm a little late to the party on this. I confirm the same. I look forward to a solution on this for OS X. We can work on grass, perhaps, once that is resolved. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA modules (version 2.1.0) through SEXTANTE on Mac OSX
Hi Victor, Below are the outputs from my terminal. The error:library is a non-issue according to comments on the dev forum for saga. Regards, John which saga_cmd /usr/local/bin/saga_cmd saga_cmd _ # ## ### ### ### ## ### ### # ## ## # ## ### # ### # # # ## # # ## _ error: library library search path: /usr/local/lib/saga 58 available module libraries: - climate_tools - contrib_a_perego - docs_html - docs_pdf - geostatistics_grid - geostatistics_points - geostatistics_regression - grid_analysis - grid_calculus - grid_calculus_bsl - grid_filter - grid_gridding - grid_spline - grid_tools - grid_visualisation - ihacres - imagery_classification - imagery_rga - imagery_segmentation - imagery_svm - imagery_tools - io_esri_e00 - io_gdal - io_gps - io_grid - io_grid_grib2 - io_grid_image - io_odbc - io_shapes - io_shapes_dxf - io_table - lectures_introduction - pj_georeference - pj_proj4 - pointcloud_tools - recreations_fractals - recreations_games - shapes_grid - shapes_lines - shapes_points - shapes_polygons - shapes_tools - sim_cellular_automata - sim_ecosystems_hugget - sim_erosion - sim_fire_spreading - sim_hydrology - ta_channels - ta_compound - ta_hydrology - ta_lighting - ta_morphometry - ta_preprocessor - ta_profiles - table_calculus - table_tools - tin_tools - transect type -h or --help for further information On Dec 20, 2012, at 2:09 PM, Victor Olaya vola...@gmail.com wrote: There is actually the following check in the case of mac and linux: command = [saga_cmd] proc = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE, stdin=subprocess.PIPE,stderr=subprocess.STDOUT, universal_newlines=True).stdout for line in iter(proc.readline, ): if in line: settings.setValue(SAGA_INSTALLED, True) return return It seems that SAGA is not correctly installed in your system.\nPlease install it before running SAGA algorithms. basically, it is a naive check to see if executing saga_cmd in a console returns something that looks like the SAGA CMD header. It works fin in linux, but it seems it is not working in Mac. Are you sure saga is in your path? if so, what do you see when you execute saga_cmd? maybe the header is different for some reason? Thanks in advance! 2012/12/20 John C. Tull jct...@gmail.com: On Dec 19, 2012, at 2:49 AM, Victor Olaya vola...@gmail.com wrote: Olav, Thanks for your contribution! There is no option SAGA folder in the SEXTANTE configuration like you have when installing on Windows. I haven't checked on Linux, but I guess the Unixes don't need this, as long as saga_cmd is in the path, right? Right, Mac and Linux should work in the same way. Let me check, because maybe in Mac it is performing the same check as in windows (that is, checking that the SAGA folder is set...) Looks like an easy to solve problem...i hope Will keep you posted Thanks again! Victor It looks like I'm a little late to the party on this. I confirm the same. I look forward to a solution on this for OS X. We can work on grass, perhaps, once that is resolved. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New FAKE_LIB_GRASS_GIS fails to compile on Mac OS X
On Dec 8, 2012, at 11:03 AM, Radim Blazek radim.bla...@gmail.com wrote: The output should be standard shared library. I have probably copy-pasted wrong (provider) block. I have no idea what is the difference on OS X. Sorry for the problems, i dont have access to source code at this moment, could you try to change CMakeLists.txt to build simple shared library. Radim On Dec 8, 2012 6:25 PM, Larry Shaffer lar...@dakotacarto.com wrote: Hi, With recent commit: https://github.com/qgis/Quantum-GIS/commit/4dc84995ee4dec8fe4b927a650b900e7edddaad4 Build of FAKE_LIB_GRASS_GIS fails on Mac OS X with: Linking CXX shared module ../../../PlugIns/qgis/libgrass_gis.6.4.2.so clang: error: invalid argument '-compatibility_version 1.9.0' only allowed with '-dynamiclib' make[2]: *** [PlugIns/qgis/libgrass_gis.6.4.2.1.9.0.so] Error 1 make[1]: *** [src/providers/grass/CMakeFiles/grass_gis.6.4.2.dir/all] Error 2 In src/providers/grass/CMakeLists.txt it seems a MODULE, and not SHARED library is generated (which I think is needed if a framework is being built), but I do not know enough about this aspect of CMake, or the build process, to fix it. Any help would be appreciated. Regards, Larry Did anyone come up with a workaround for this? I am still getting the error on my build attempts for trunk: … Scanning dependencies of target grass_gis.6.4.2 [ 44%] Building CXX object src/providers/grass/CMakeFiles/grass_gis.6.4.2.dir/qgsgrassgislib.cpp.o [ 45%] Building CXX object src/providers/grass/CMakeFiles/grass_gis.6.4.2.dir/qgsgrassgislibfunctions.cpp.o Linking CXX shared module ../../../PlugIns/qgis/libgrass_gis.6.4.2.so clang: error: invalid argument '-compatibility_version 1.9.0' only allowed with '-dynamiclib' make[2]: *** [PlugIns/qgis/libgrass_gis.6.4.2.1.9.0.so] Error 1 make[1]: *** [src/providers/grass/CMakeFiles/grass_gis.6.4.2.dir/all] Error 2 make: *** [all] Error 2 Regards, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New FAKE_LIB_GRASS_GIS fails to compile on Mac OS X
On Dec 10, 2012, at 11:59 AM, Radim Blazek radim.bla...@gmail.com wrote: On Mon, Dec 10, 2012 at 8:43 PM, Larry Shaffer lar...@dakotacarto.com wrote: On Mon, Dec 10, 2012 at 12:14 PM, John C. Tull jct...@gmail.com wrote: On Dec 8, 2012, at 11:03 AM, Radim Blazek radim.bla...@gmail.com wrote: The output should be standard shared library. I have probably copy-pasted wrong (provider) block. I have no idea what is the difference on OS X. Sorry for the problems, i dont have access to source code at this moment, could you try to change CMakeLists.txt to build simple shared library. Radim On Dec 8, 2012 6:25 PM, Larry Shaffer lar...@dakotacarto.com wrote: Hi, With recent commit: https://github.com/qgis/Quantum-GIS/commit/4dc84995ee4dec8fe4b927a650b900e7edddaad4 Build of FAKE_LIB_GRASS_GIS fails on Mac OS X with: Linking CXX shared module ../../../PlugIns/qgis/libgrass_gis.6.4.2.so clang: error: invalid argument '-compatibility_version 1.9.0' only allowed with '-dynamiclib' make[2]: *** [PlugIns/qgis/libgrass_gis.6.4.2.1.9.0.so] Error 1 make[1]: *** [src/providers/grass/CMakeFiles/grass_gis.6.4.2.dir/all] Error 2 In src/providers/grass/CMakeLists.txt it seems a MODULE, and not SHARED library is generated (which I think is needed if a framework is being built), but I do not know enough about this aspect of CMake, or the build process, to fix it. Any help would be appreciated. Regards, Larry Did anyone come up with a workaround for this? I am still getting the error on my build attempts for trunk: Hi John, I have a new pull request in for fixing this on Mac, but am not entirely sure I did it correctly (or what the new FAKE_LIB_GRASS_GIS does or how to test it): https://github.com/qgis/Quantum-GIS/pull/349 https://github.com/qgis/Quantum-GIS/pull/349.patch Thanks Larry, I have pushed that to the master. The library should make it possible to run GRASS modules without mapset and data data import. You can try to run a GRASS module in this mode from GRASS Tools ( which is now always enabled), if no mapset is open. Most probably it will need more fixes on Mac and Win. It is work in progress, currently there are only few modules and you can find problems. I'll write more about in another thread soon. Radim Hi Radim, I just tested one of the available modules on a local DEM file, and here is there error message that appeared when I ran it: Cannot start module r.slope.aspect command: /usr/local/Cellar/grass/6.4.2/grass-6.4.2/bin/r.slope.aspect --interface-description ERROR: GISRC - variable not set Note that I am running a version of grass installed locally, not from the application that William makes available. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GRASS Direct
Hi Larry, Thanks for weighing in. Comments below... On Dec 10, 2012, at 1:08 PM, Larry Shaffer lar...@dakotacarto.com wrote: Hi John and Radim, On Mon, Dec 10, 2012 at 1:53 PM, John C. Tull jct...@gmail.com wrote: On Dec 10, 2012, at 12:44 PM, Radim Blazek radim.bla...@gmail.com wrote: The GRASS Direct is an environment developed within QGIS GRASS plugin/provider which makes it possible to run GRASS raster modules without GRASS mapset and without data conversion to GRASS format. Basically it is a library implementing GRASS data read/write function which is using QGIS providers to read/write data. In direct mode, the GRASS modules are run with this library instead of the standard GRASS gis library. The GRASS modules may be run in direct mode from GRASS Tools (which are now always enabled) if no mapset is opened. The interface is similar to the standard GRASS Tools apart that the region is selected in combo box in top of options (to be discussed) and the output is a GeoTIFF file. It is also possible to run GRASS modules in direct mode from a shell if some environment variables are set. You can see those variables printed in top of the output tab. This is work in progress, so I was reluctant to announce that but because it had caused some compilation problems, it was necessary to explain a bit how it works. Currently there are only few modules enabled and you can find various problems. Especially it was only tested on Linux and most probably more fixes will be necessary on Mac and Windows. I believe that GRASS Direct could also be used in SEXTANTE with a little work. It would be necessary however to distinguish modules which may be run in direct mode from those which may not (mostly vector modules). Sorry for the problems I caused on Mac and Windows and many thanks to Jürgen and Larry for fixes. Radim Hi Radim, This is a great new addition to QGIS, so thank you for you work on it. I wanted to bring my comment I made elsewhere on my Mac testing into this, more appropriate thread: I just tested one of the available modules on a local DEM file, and here is there error message that appeared when I ran it: Cannot start module r.slope.aspect command: /usr/local/Cellar/grass/6.4.2/grass-6.4.2/bin/r.slope.aspect --interface-description ERROR: GISRC - variable not set Note that I am running a version of grass installed locally, not from the application that William makes available. Radim, awesome stuff! Thanks for the introduction on it. Looking forward to using this inside of SEXTANTE. Getting the same thing as John here, but with Kyngchaos.com GRASS. When using the Kyngchaos.com GRASS, the app starts via an internal shell script that configures most of those GRASS env variables [0]. John, again we Mac users are up against shell environment not being transferred into QGIS. I really think having a spot in the app preferences to allow manually added/augmented env variables (like PATH, etc.) would be very handy indeed. +1 It could be kinda like setting up a build environment inside of QtCreator [1]. The nice thing about having such an env variable editor (besides setting up custom variables) is that it would allow both C++ and Python components to inherit the env settings. Example: thereby giving SEXTANTE access to any custom external install location on the filesystem. I don't know if you have tested sextante grass tools, but I cannot get anything to work, likely because of the same environment problems that we are seeing with GRASS Direct. If we could cut through this problem with a solution as you propose, that would be great. Note how slim the default passed environment is for Mac GUI apps in [1] (nothing like my .bash_profile, etc.). I really think this needs addressed (especially for Mac users), and could benefit all platforms with further start up environment customization. Again, +1 from me. Regards, Larry [0] http://grass.osgeo.org/grass64/manuals/variables.html [1] https://dl.dropbox.com/u/4058089/qgis/env-vars_like-in-qtcreator.pn Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GRASS Direct
On Dec 10, 2012, at 1:32 PM, Radim Blazek radim.bla...@gmail.com wrote: On Mon, Dec 10, 2012 at 10:08 PM, Larry Shaffer lar...@dakotacarto.com wrote: On Mon, Dec 10, 2012 at 1:53 PM, John C. Tull jct...@gmail.com wrote: I wanted to bring my comment I made elsewhere on my Mac testing into this, more appropriate thread: I just tested one of the available modules on a local DEM file, and here is there error message that appeared when I ran it: Cannot start module r.slope.aspect command: /usr/local/Cellar/grass/6.4.2/grass-6.4.2/bin/r.slope.aspect --interface-description ERROR: GISRC - variable not set Note that I am running a version of grass installed locally, not from the application that William makes available. Getting the same thing as John here, but with Kyngchaos.com GRASS. When using the Kyngchaos.com GRASS, the app starts via an internal shell script that configures most of those GRASS env variables [0]. What is the 'app' in this context? GRASS, QGIS or a single GRASS module? Which variables are set by the script? As I wrote, there was missing DYLD_LIBRARY_PATH on Mac, please try also with current master. Radim The 'app' for Larry is GRASS-6.4.2.app, as packaged by William. My version is installed by a package installer called homebrew. Although not an application bundle, it also runs from a shell script rather than from a binary directly, i.e., : file /usr/local/bin/grass64 /usr/local/bin/grass64: POSIX shell script text executable less /usr/local/bin/grass64 #! /bin/sh # # # MODULE: GRASS Initialization # AUTHOR(S):Justin Hickey - Thailand - jhic...@hpcc.nectec.or.th # PURPOSE: The source file for this shell script is in # lib/init/grass.src and is the grass startup script. It # requires a source file because the definition of GISBASE # is not known until compile time and is substituted from the # Makefile. Any command line options are passed to Init.sh. # COPYRIGHT:(C) 2000-2005 by the GRASS Development Team # # This program is free software under the GNU General Public # License (=v2). Read the file COPYING that comes with GRASS # for details. # # trap echo 'User break!' ; exit 2 3 9 15 # Set the GISBASE variable GISBASE=/usr/local/Cellar/grass/6.4.2/grass-6.4.2 export GISBASE exec $GISBASE/etc/Init.sh $@ /usr/local/bin/grass64 (END) Regarding the trunk fix, I now have a different compile error: ... Scanning dependencies of target grassplugin [ 81%] Building CXX object src/plugins/grass/CMakeFiles/grassplugin.dir/qgsgrassplugin.cpp.o /Users/jctull/sources/Quantum-GIS/src/plugins/grass/qgsgrassplugin.cpp:930:20: warning: 'name' has C-linkage specified, but returns user-defined type 'QString' which is incompatible with C [-Wreturn-type-c-linkage] QGISEXTERN QString name() ^ /Users/jctull/sources/Quantum-GIS/src/plugins/grass/qgsgrassplugin.cpp:936:20: warning: 'description' has C-linkage specified, but returns user-defined type 'QString' which is incompatible with C [-Wreturn-type-c-linkage] QGISEXTERN QString description() ^ /Users/jctull/sources/Quantum-GIS/src/plugins/grass/qgsgrassplugin.cpp:942:20: warning: 'category' has C-linkage specified, but returns user-defined type 'QString' which is incompatible with C [-Wreturn-type-c-linkage] QGISEXTERN QString category() ^ /Users/jctull/sources/Quantum-GIS/src/plugins/grass/qgsgrassplugin.cpp:954:20: warning: 'version' has C-linkage specified, but returns user-defined type 'QString' which is incompatible with C [-Wreturn-type-c-linkage] QGISEXTERN QString version() ^ /Users/jctull/sources/Quantum-GIS/src/plugins/grass/qgsgrassplugin.cpp:959:20: warning: 'icon' has C-linkage specified, but returns user-defined type 'QString' which is incompatible with C [-Wreturn-type-c-linkage] QGISEXTERN QString icon() ^ 5 warnings generated. [ 81%] Building CXX object src/plugins/grass/CMakeFiles/grassplugin.dir/qgsgrassselect.cpp.o [ 81%] Building CXX object src/plugins/grass/CMakeFiles/grassplugin.dir/qgsgrassbrowser.cpp.o [ 81%] Building CXX object src/plugins/grass/CMakeFiles/grassplugin.dir/qgsgrassedit.cpp.o [ 81%] Building CXX object src/plugins/grass/CMakeFiles/grassplugin.dir/qgsgrassedittools.cpp.o [ 82%] Building CXX object src/plugins/grass/CMakeFiles/grassplugin.dir/qgsgrasstools.cpp.o [ 82%] Building CXX object src/plugins/grass/CMakeFiles/grassplugin.dir/qgsgrassmodel.cpp.o [ 82%] Building CXX object src/plugins/grass/CMakeFiles/grassplugin.dir/qgsgrassmapcalc.cpp.o In file
Re: [Qgis-developer] GRASS Direct
On Dec 10, 2012, at 2:12 PM, Larry Shaffer lar...@dakotacarto.com wrote: As I wrote, there was missing DYLD_LIBRARY_PATH on Mac, please try also with current master. Getting compile errors. I think you need to use (works for me): #elif defined(Q_OS_MAC) instead of: #elif Q_OS_MAC I think because Q_OS_MAC is a macro. Again, since DYLD_LIBRARY_PATH is not passed to QGIS.app a launch from terminal session is needed to test. Larry I confirm that this adjustment fixes my trunk build also. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] ESRI FileGDB support on Mac OS X using Homebrew
On Nov 18, 2012, at 4:39 PM, Noli Sicad nsi...@gmail.com wrote: Hi John, Did it work for you? I tried this a few weeks back and it did not work for me on OS X Mountain Lion. Instead, I had to revert to my hacked gdal.rb hombrew install script. I placed the script online: http://pastebin.com/uK6LQpUH Also, see this for where I got my patches from: https://gist.github.com/2005158 No. I have not tried doing this thing yet. I don't have a need for FileGDB at the moment. Thanks for these links. Regards, Noli If you manage it, please report back. My workaround is clunky, but it works for me. A usable, more elegant approach would be nice to have. If the simple method works for you or others, then I probably have something else wrong with my system that I would need to sort out. Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] ESRI FileGDB support on Mac OS X using Homebrew
Hi William, On Nov 19, 2012, at 4:53 PM, William Kyngesburye wokl...@kyngchaos.com wrote: On Nov 19, 2012, at 11:43 AM, John C. Tull wrote: If you manage it, please report back. My workaround is clunky, but it works for me. A usable, more elegant approach would be nice to have. If the simple method works for you or others, then I probably have something else wrong with my system that I would need to sort out. If it's just a question of FGDB support for GDAL (and QGIS), I've been sitting on a FGDB plugin for my GDAL framework. 2 problems have been holding me back: the license is unclear if the DLLs can be distributed with open source software (or any software at all), and even if that was allowed, all Esri software has an export limitation that I am not capable of enforcing in my downloads. The only option I can think of is to have users download and install the FGDB API themselves and my plugin will use that (I did that long ago with the OCI plugin). I could craft my installer to make that painless. Other open source software does a similar thing with incompatible licenses. The latter approach sounds like a good and acceptable means of making this available to all the framework users out there, which is probably 99% of all QGIS mac users. I think you have to create a free ESRI account to download the api, so you are most likely in safe territory having users that require FileGDB signing on and agreeing to ESRI's license on their own. Thanks for chiming in on this and proposing a good solution! Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] ESRI FileGDB support on Mac OS X using Homebrew
Did it work for you? I tried this a few weeks back and it did not work for me on OS X Mountain Lion. Instead, I had to revert to my hacked gdal.rb hombrew install script. I placed the script online: http://pastebin.com/uK6LQpUH Also, see this for where I got my patches from: https://gist.github.com/2005158 Cheers, John On Nov 17, 2012, at 1:05 AM, Noli Sicad nsi...@gmail.com wrote: Hi, FYI Installing GDAL/OGR with FileGDB support on OSX with Homebrew http://blog.burhum.com/post/34851795066/installing-gdal-ogr-with-filegdb-support-on-osx-with Noli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Webpage
Given what the prior website looked like, it is a vast improvement. Nonetheless, I think Tim's points are spot on, especially regarding balancing white space, use of green, and the drop-down/tab disconnect (the tabs themselves look disconnected to me, and the grey shade for the active tab makes it look inactive from expected gui practices). Nonetheless, I congratulate the GRASS team for greatly improving from what they had. I don't think QGIS should strive to replicate this look, though. Cheers, John On Nov 13, 2012, at 2:54 PM, G. Allegri gioha...@gmail.com wrote: Sadly, I must agree with Tim. Sadly because I know the effort made by the GRASS team to have the new site out, but I cannot object Tim's points... giovanni PS: @Tim, I wasn't aware of the ongoing work to switch to a boostrap based sphinx theme. What are you using for it? 2012/11/13 Tim Sutton li...@linfiniti.com Hi Yes I have seen it. With no disrespect to the GRASS folks I think it has enough problems that I would not like to copy it on our site. My (hopefully) constructive criticisms: * its very busy * it doesnt have good whitespace balance e.g. module of the day box with screenshots box floating to the right * I love jquery but jquery css is looking old already * there are too many underlines [ ] and other characters that distract attention and make it look not so friendly * the panels on the left (search, latest news, map) should have been put to the right * there is too much white space in the heading area * the logo really needs a refresh * the heavy green bars distract your eye away from the content * there are too many different font sizes and font styles * the drop down menus feel visually disconnected from the tabs the spring from and menus from tabs just feels kinda wierd In short it could really use a designer to introduce balance, correct emphasis and remove distractions As such I would not be supportive of using it for our site I suggest to wait for the sphinx theme based on bootstrap to come out and then start moving our web content into that. We will do some customisations for the QGIS front page and Richard has been making awesome progress in getting a well put together bootstrap based sphinx theme in place for us when we can then skin using any bootstrap theme (e.g. checkout some of the themes at http://bootswatch.com/). So -1 from me Regards Tim On Wed, Nov 14, 2012 at 12:14 AM, Werner Macho werner.ma...@gmail.com wrote: Hi there! Anyone seen the new GRASS Webpage? I really like the clean and intuitive style with lots of information presented clearly on the top page .. Probably we can adapt it to our new webpage? It even looks good on mobile phones .. Opinions on that? kind regards Werner ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Hackfest in Americas? was Re: HF: final remarks
Davis would have the added benefit of being a reasonably short drive for me. :-) In addition, it is accessible by BART and train from SFO. Portland and Seattle are also great venues, so it might depend on the costs for Gary and others that would be needed to really pull off something useful. I don't have coding skills, but can happily test, debug and provide opinions, assuming timing and locale permit attendance. On Oct 12, 2012, at 11:03 AM, Alex Mandel tech_...@wildintellect.com wrote: Gary and I have chatted about this. The west coast is somewhat ideal and the further north the better (in terms of shorter/cheaper flights, especially for the Alaska crew). The main characters that I know of to involve would be: Larry - Dakotas Aaron Racicot - Oregon Gary Sherman - Alaska (+ a couple of people Gary works with) Alex Mandel (me) - Davis, CA Bob M.(cgsbob) - Sacramento, CA Jctull - Reno, Nv Seattle or Portland seem like good candidates with CUGOS and PDX-OSGeo chapters. OSGeo Sprint was outside Seattle last year. Also there is the OSGeo North America in Minnesota this April. Of course I'm willing to host at UC Davis if it helps, since I can get rooms relatively easily but we need help organizing donations to keep us fed. Thanks, Alex On 10/12/2012 10:55 AM, Larry Shaffer wrote: Hi On Sun, Oct 7, 2012 at 10:36 AM, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. This HF is over - only three Italians stranded in Essen, waiting for their flights back. I personally want to deeply thank Horst, Otto, and all those who helped organize this very successful event. The location is simply ideal, no waste of time, maximum concentration on coding and discussing (OK, apart from the bad influence of IT Crowd, damned), a beautiful and quiet place, a friendly atmosphere, and efficient infrastructure. In my personal opinion, Villa Vogelsang is the best place we've ever had, and I would suggest coming back here more or less regularly (e.g. we could have one itinerant HF per year, and another one here). Another thing I'd like is to make it easier for people from other continents to participate (we are too Eurocentric at the moment), without incurring in too high flight costs. Perhaps we could have simultaneous HFs in each continent, and be constantly connected in audio and video? Thanks for bringing this up Paolo. I would like to go to a QGIS hackfest, but the European venues are not financially feasible for me (and probably not for others as well). The hackfests seem to generate very positive momentum for the project, as well as code. I am definitely in favor of attending one here (in the US). If it could coincide with another going on in another part of the world, that would be very cool. If one were to be in the US, obviously having it in a locale with an international airport seems logical. How were accommodations for FOSS4G in Denver (2011)? How many are interested in a sister hackfest in the US, ideally one video- or audio-linked to another in Europe (or elsewhere)? Regards, Larry Thanks again to all for contributing to this success, that marks another step in the history of QGIS. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qt at digia
Hi, On Sep 19, 2012, at 6:30 AM, Tim Sutton li...@linfiniti.com wrote: Hi On Wed, Sep 19, 2012 at 2:54 PM, Werner Macho werner.ma...@gmail.com wrote: hi! What about working on a as is release 1.9 where most of the bugs (overview ;) ) are (tried to be) fixed .. and then immediately start for 2.0 with Qt5 ? The next release must be 2.0 since we have really broken the api. See [1] to understand the rationale for this. Beside some smaller issues the current state of master seems useable and stable to me .. [1] http://semver.org/ Presumably, Qt5 would lead to some new broken api's relative to what has been done in trunk towards the 2.0 release, but confirm if that is a valid assumption or not. If it is, maybe a qgis 2.2 or higher release is a more sensible target for the switch. If not, then it is more a matter of how long transitioning and testing would take. My non-dev thoughts, John Regards Tim regards Werner On Wed, Sep 19, 2012 at 2:49 PM, Tim Sutton li...@linfiniti.com wrote: Hi On Wed, Sep 19, 2012 at 3:32 AM, Marco Bernasocchi ma...@bernawebdesign.ch wrote: interesting reading... http://blog.qt.digia.com/2012/09/18/the-journey-starts-today/#more-33799 Interesting they are copying QGIS and moving to using jenkins-ci...hopefully that will mean nice additions to improve CI with Qt projects and Jenkins. Also the timing of Qt5 makes me wonder if we should complete skip over to Qt5 for QGIS 2.0. I'm just throwing the idea up in the air, I know most will probably shoot it down due to packaging issues etc. Regards Tim Marco Bernasocchi (mobile) http://opengis.ch ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Building QGIS in Mac OS X (Mountain Lion i.e. 10.8) with QtSQL support
On Aug 5, 2012, at 11:43 AM, Larry Shaffer lar...@dakotacarto.com wrote: Hi John, On Sun, Aug 5, 2012 at 10:03 AM, John C. Tull jct...@gmail.com wrote: On Aug 4, 2012, at 8:11 PM, Larry Shaffer lar...@dakotacarto.com wrote: Note: Xcode.app now contains all dev directory structure, and you can use xcrun to work with it, but I preferred to install the command line tools. You will probably want to uninstall any previous XCode version first. I used the .dmg installers downloaded from my Apple developer account, instead of Mac App Store. Not sure if the command line tools (115 MB dl) can be installed, and work, without installing Xcode.app (1.8 GB dl), since I installed Xcode.app first. You can install the command line tools from the app store version of Xcode. Open Xcode, then open Preferences and click on the 'Downloads' section at the top. You will see Command Line Tools as an install option from there. Yes, I believe that was in the stackoverflow link I mentioned. I did further tests to see if the CL Tools could be used independent from Xcode.app (like it says on Apple's web site). However, there is no SDK for 10.7 or 10.8 with the Tools, only embedded in Xcode.app (3.3 GB installed on disk), and the Tools use those. I think Apple has really made a mess of things, by requiring Xcode.app and moving all dev structure inside of the app bundle - probably all in the name of 'convenience' for new devs. So, for now, the QGIS build notes for Mac should continue to recommend full install of Xcode.app, IMHO. I agree, full Xcode install is required. I only wanted to point out that you can do an App Store install of Xcode, then install the command line tools from the preferences of the Xcode app. I think that is more streamlined than opening a Dev account, etc. Of course, if you're building qgis from source, you should be more advanced than the average user, so either way works fine. Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New adv labeling freeze-thaw tools
Hi Larry, On Aug 6, 2012, at 1:28 PM, Larry Shaffer lar...@dakotacarto.com wrote: * Improve Change Label dialog: - Temporarily add (colored) PAL solution x, y, rot info to specific If I understand you correctly on this improvement idea, a hearty +1 from me. My read on this is that layers without x, y, and rotation fields will store frozen label information and allow them to be placed despite lacking those fields. Ideally, upon committing the changes (i.e., taking the layer out of editing mode), a prompt to save the information and assign to existing or create the appropriate fields would be given to the user. Is this right, or am I day-dreaming? My test last week on a handy layer did not allow me to move labels because I did not have said fields identified or available. Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Building QGIS in Mac OS X (Mountain Lion i.e. 10.8) with QtSQL support
On Aug 4, 2012, at 8:11 PM, Larry Shaffer lar...@dakotacarto.com wrote: Note: Xcode.app now contains all dev directory structure, and you can use xcrun to work with it, but I preferred to install the command line tools. You will probably want to uninstall any previous XCode version first. I used the .dmg installers downloaded from my Apple developer account, instead of Mac App Store. Not sure if the command line tools (115 MB dl) can be installed, and work, without installing Xcode.app (1.8 GB dl), since I installed Xcode.app first. You can install the command line tools from the app store version of Xcode. Open Xcode, then open Preferences and click on the 'Downloads' section at the top. You will see Command Line Tools as an install option from there. Regards, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Plugin - Edit Any Layer
On Aug 1, 2012, at 8:42 AM, Paolo Cavallini cavall...@faunalia.it wrote: Il 01/08/2012 17:39, Rob Nickerson ha scritto: In part of my work looking at adapting fTools / SEXTANTE to write to memory layer / any ogr format, I have created a standalone plugin that converts any vector layer to a memory layer (and therefore allows you to edit the layer). This plugin is hosted at [1], if you like I will move it to a more permanent location. thanks for this. of course the right place for it is http://plugins.qgis.org/ from there, everybody can install and check it. looking forward to see it there. all the best. +1 Do you think you can host in through the qgis plugins repo referenced by Paolo? Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New adv labeling freeze-thaw tools
I look forward to seeing this in trunk. Thanks for the great contribution. John On Jul 17, 2012, at 2:28 PM, Larry Shaffer wrote: I've updated and extensively tested this new tool (not all platforms) and it works very well. I have sent in a pull request: https://github.com/qgis/Quantum-GIS/pull/193 Again, here's the intro video: http://vimeo.com/dakotacarto/freezethawlabels (Note: I haven't had much sleep, so the video is a bit rough.) As an unexpected added bonus (well, unexpected to me), the tool helps greatly with slow label rendering options, like a polygon layer's 'free' and 'horizontal' modes. After the PAL labeling engine finishes with those modes during a canvas refresh (sometimes taking several minutes), just use the freeze label tool on the result. The subsequent canvas refreshes are magnitudes faster. Marco H., thank you for your help on this, and thanks to sourcepole and Martin for doing such a great job of coding the advanced labeling engine. I would have never been able to produce this tool had it not been for the excellent existing and flexible code. Regards, Larry Shaffer Dakota Cartography Black Hills, South Dakota On Mon, Jul 16, 2012 at 9:45 AM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: Hi Larry If you have the time to look at the constructor for QgsMapToolFreezeLabels (the FIXME), you'll notice I could not find a way to make the signal/slot connections from there. Currently they are in qgisapp.cpp, but I would prefer to not pollute that core file with any more of my tool's code than necessary. What's the simplest way to create the connections from inside my QObject-inherited tool instead? The slot methods need to be declared as slots in the header file, like this: public slots: //! Update frozen label highlights on canvas render finished void updateFrozenLabels(); //! Render rectangles around frozen labels void highlightFrozenLabels(); Currently, they are just normal public methods. Regards, Marco Am 16.07.2012 11:35, schrieb Larry Shaffer: On Mon, Jul 16, 2012 at 2:18 AM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: Hi Larry Excellent work, thank you! The freeze/thaw tool will be a great addition to the label tool bar. I wonder if the tool could also be active if x/y is data defined and rotation not (currently, x/y/rotation need to be data defined to use the tool). Yes, that is an unnecessary restriction. I'll make the rotation field optional. On a detail level, in QgsMapToolFreezeLabels::highlightLabel you could probably use QgsMapRenderer::mapToLayerCoordinates to transform the rectangle (instead of mCoordTransform ). Will make the change. Thanks. If you have the time to look at the constructor for QgsMapToolFreezeLabels (the FIXME), you'll notice I could not find a way to make the signal/slot connections from there. Currently they are in qgisapp.cpp, but I would prefer to not pollute that core file with any more of my tool's code than necessary. What's the simplest way to create the connections from inside my QObject-inherited tool instead? Regards, Larry Am 16.07.2012 05:31, schrieb Larry Shaffer: Hi, The current large-format project I'm working on requires me to layout, for print, thousands of labels. So I spent the last couple of days making two new tools for the advanced labeling toolbar that allow the user to interactively 'freeze' (write coords and rotation info to attribute table) and 'thaw' (revert from data-defined to dynamic) any rendered labels. *Show Frozen Labels* This tool highlights frozen labels for all visible layers. Blue highlighted labels are frozen, green are frozen and editable (parent layer's in edit mode). *Freeze/Thaw Labels* This tool allows the user to interactively choose, by single or marquee selection, labels to freeze or thaw. The in-memory attribute table is immediately updated and results shown to user. This tool allows the user to interactively manipulate the PAL labeling engine to find the best solutions for their frozen labels. Since the topic and how the tool interacts with the labeling engine is more complicated, I made an intro video. (Note: I haven't had much sleep recently, so it's a bit rough.) http://vimeo.com/dakotacarto/freezethawlabels This is my first C++ project, so I'd be really happy if someone audited the code before I squash the commits and send a pull request: https://github.com/dakcarto/Quantum-GIS/tree/feature_freeze-thaw-labels Only tested on Mac, as of now. Nothing platform-specific about it though. Regards, Larry Shaffer Dakota Cartography Black Hills, South Dakota ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions
Re: [Qgis-developer] Remember to look at dash after committing
Speaking of tests, ignore the last post from hawkeye. I'll send an update later that will include the latest code improvements and a working test run. On Jul 16, 2012, at 2:15 PM, Tim Sutton wrote: Just a friendly reminder to those pushing into the master branch - please remember to run the tests and also check on the dash that they pass on all platforms. Doing this help can prevent regressions early in the process. http://dash.orfeo-toolbox.org/index.php?project=QGISdate=2012-07-15 Thanks! Regards -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Overview frame in composer
Hi Marco, I don't know if this is a bug or a lack of understanding on this new feature. On a map composer item, I want to add the overview frame. I can select an overview style, but the Overview frame drop-down menu only has the none option. Is there something I need to do to provide an overview choice in that drop-down, or is it possible that the list is not being populated on my OS X system and it is a bug? Let me know what I can do to help debug if it is the latter. Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Overview frame in composer
Thanks, Marco. Do you want a bug filed? On Jul 13, 2012, at 8:46 AM, Marco Hugentobler wrote: Hi John It is a bug (the feature is still fresh). The list does not get updated when you add new composer maps. But it already works if you add the overview map second, since the list gets populated with the composer maps that are already there. Regards, Marco Am 13.07.2012 17:33, schrieb John C. Tull: Hi Marco, I don't know if this is a bug or a lack of understanding on this new feature. On a map composer item, I want to add the overview frame. I can select an overview style, but the Overview frame drop-down menu only has the none option. Is there something I need to do to provide an overview choice in that drop-down, or is it possible that the list is not being populated on my OS X system and it is a bug? Let me know what I can do to help debug if it is the latter. Cheers, John -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Overview frame in composer
Thanks. I am playing with it now. It took me a couple of tries to see that it required more than one map item. This is a great addition to the composer! On Jul 13, 2012, at 8:58 AM, Nathan Woodrow wrote: You have to have two map frames on your composer. On the the second one you select it to be a overview map of the first one. The UI might need some better naming to explain this better. - Nathan Sent from some fancy phone looking thingo From: John C. Tull Sent: 14/07/2012 1:33 AM To: qgis-developer Subject: [Qgis-developer] Overview frame in composer Hi Marco, I don't know if this is a bug or a lack of understanding on this new feature. On a map composer item, I want to add the overview frame. I can select an overview style, but the Overview frame drop-down menu only has the none option. Is there something I need to do to provide an overview choice in that drop-down, or is it possible that the list is not being populated on my OS X system and it is a bug? Let me know what I can do to help debug if it is the latter. Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New test run
Hi Tim, Looping this into the dev list, your updates seem to have gotten all the non-expression tests in order on OSX. Perhaps someone else will pick up the mantle on the expression test. Cheers, John On Jul 12, 2012, at 5:05 AM, Tim Sutton wrote: On Thu, Jul 12, 2012 at 1:12 AM, John C. Tull jct...@gmail.com wrote: Hi Tim, I just posted another make Experimental run if that's helpful. I'm on IRC or mail if you prefer. If I'm around, I'll do what I can. Cheers, John I think the only test left failing on your system after my last commit will be the expression builder one - an I have no clue what the error is :-P Just posting your Experimental builds there regularly is great we can get most all the diagnostics we need from that. Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] What will be in QGIS 2.0
I think all the points brought up have been quite good. Obviously, there is much in the bug queue that needs to be considered for a 2.0 release. Also, a general +1 on Tim's suggestion for meritocracy with the inclusion of both active developers and funders. Further support on a couple things that Nathan brought up: On Jul 11, 2012, at 4:41 AM, Nathan Woodrow wrote: - Python support in labels and attribute table +1, will allow more powerful automation of cartographic map outputs, i.e., selectable labels based on various criteria. - So kind of query language (Martin and I have been talking about something in Python but it's only a dream at the moment) +1, will open up possibilities like showing only a single attribute from a layer when looping layers, e.g., Atlas printing of only the active feature rather than all features from the coverage layer. Cheers, John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] porting the composer QPaintEngine hack to Python?
I can confirm success on my OSX system also with the patch you supplied, Giovanni. Cheers, John On Jul 9, 2012, at 8:13 AM, G. Allegri wrote: The hack is working perfectly! Tha Atlas plugin seems to be working now ;) giovanni 2012/7/5 G. Allegri gioha...@gmail.com Thanks to Jef, the hacked engine is exposed throug sip now ;) I will try it ASAP. giovanni 2012/7/5 G. Allegri gioha...@gmail.com I fear it isn't possible (at least with common programming skills!) to reproduce it. My approach was too naive. The paintEngine instance is a pointer to a subclass implementation, and AFACS there's no method to change the flags (render features) of an instanciated engine... giovanni 2012/7/5 G. Allegri gioha...@gmail.com 2012/7/5 Marco Hugentobler marco.hugentob...@sourcepole.ch made by Marco made by Jürgen (it fixes the pdf shift on windows). ops, sorry :) Marco Am 05.07.2012 16:11, schrieb G. Allegri: Vincent highlighted a hack in the composer PDF rendering (made by Marco) [1]. I was trying to reproduce it in Python, to test if it can solve some problems in the Atlas plugin. I thought I could use the QPrinter.setEngines() method [2], to set an instance of a derived QPaintEngine intitated with the flags provided in the hack, but this method makes QGis crash. I was doing something like this (excerpt): paintE = self.getHackedPaintEngine printE = printer.printEngine() printer.setEngines(printE,paintE) def getHackedPaintEngine(self): class HackEngine(QPaintEngine): def __init__(self): QPaintEngine.__init__(self, QPaintEngine.PrimitiveTransform | QPaintEngine.PixmapTransform | QPaintEngine.PatternBrush | QPaintEngine.AlphaBlend | QPaintEngine.PainterPaths | QPaintEngine.Antialiasing | QPaintEngine.BrushStroke | QPaintEngine.ConstantOpacity | QPaintEngine.MaskedBrush | QPaintEngine.BlendModes | QPaintEngine.RasterOpModes ) return HackEngine() What alternative way would you suggest to reproduce the hack? giovanni [1] https://github.com/qgis/Quantum-GIS/blob/master/src/app/composer/qgscomposer.cpp#L588 [2] http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qprinter.html#setEngines ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Redmine - Create a new version 1.9.0 ?
I don't know if you have heard from any others, but 2.0.0 is the current target for the master branch. This is a useful patch that will hopefully be applied soon. Cheers, John On Jun 25, 2012, at 1:41 AM, kimaidou wrote: Hi devs I would like to change the target version of my small patch http://hub.qgis.org/issues/5561 I have seen there is no 1.9.0 version nor a master branch version. Is Version 2.0.0 considered as the master branch in redmine ? Thanks in advance Michael ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: Mac app bundling - all-in-one
Thanks William, It sounds like you have some good checks in place with the installer. With that worked out, I agree that there is not a lot of value in creating another build for you to manage and host. Regards, John On Feb 10, 2012, at 5:24 PM, William Kyngesburye wrote: I didn't check back on this after I saw it added to MacUpdate, and strangely I don't recall seeing updates listed (I check daily). For all the complaints about the requirements missing from the readme - bogus, they are there. And starting with 1.7.1, an installer is used that will not install without the frameworks. But, for the all-in-one, a bug affecting this was only recently fixed, and I've been too busy to work out the packaging details. I got a start, but it's a complex thing to do. And you lose GRASS support in the all-in-one. Once you need GRASS support (when the GRASS provider bug is finally fixed), you're back to installing the frameworks. On Feb 10, 2012, at 11:07 AM, John C. Tull wrote: Hi William, I was looking at comments on QGIS at macupdate: http://www.macupdate.com/app/mac/25428/quantum-gis Unfortunately, there are some negative reviews that seem to be tied to inexperienced users not following install directions. Considering that the installation of frameworks is likely unfamiliar for most casual users of OSX, I wondered if it would be possible to provide the all-in-one bundled application like you used to do? Having a unified application with frameworks bundled, although quite massive, would alleviate the most likely cause for failure on new installs being reported in the comments. Cheers, John - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Mac app bundling - all-in-one
Hi William, I was looking at comments on QGIS at macupdate: http://www.macupdate.com/app/mac/25428/quantum-gis Unfortunately, there are some negative reviews that seem to be tied to inexperienced users not following install directions. Considering that the installation of frameworks is likely unfamiliar for most casual users of OSX, I wondered if it would be possible to provide the all-in-one bundled application like you used to do? Having a unified application with frameworks bundled, although quite massive, would alleviate the most likely cause for failure on new installs being reported in the comments. Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] CMake cleanup and OS X frameworks
I had this issue also, worked around it by copying that directory over. I don't know if this is related, but trying to access the preferences now brings up the shortcut dialog. Settings -- Options gets to preferences, though. Personally, I'd love to see the menus get cleaned up so that qgis looks/feels/acts more like a mac application on mac platforms. This is a problem that arose sometime after 1.4 or 1.5, but it is now becoming more than a distraction. Multiple, redundant (you like that irony?) menu items, disorganized menu structures, Help menu not last in the menu bar, etc. I wish I knew how to poke around in the ui files to try and fix this, but I do not. So no solutions provided here, only complaints. Sorry about that. Cheers, John On Jul 5, 2011, at 3:50 PM, Tom Elwertowski wrote: Hi William, I encountered the following error using your update: CMake Error at images/icons/CMakeLists.txt:12 (ADD_SUBDIRECTORY): add_subdirectory given source mac which is not an existing directory. It looks like icon files weren't moved from src/mac to images/icons/mac. Tom William Kyngesburye wrote: I did some CMake cleanup, along with changing the qgis libraries to frameworks for OS X. Some notes: - removed a lot of unnecessary conditionals for target configuration for platform-specific options. Cmake is designed so that platform-specific options are only used for the platform, so they can all be specified in a single configuration command. ie for an application: ADD_EXECUTABLE ([exename] MACOSX_BUNDLE WIN32 [sources...]) - header installation is an automatic part of targets. Though some headers may still need a separate install command (ui headers don't exist when cmake runs). I also put all global header installation (qgsconfig.h, qgisplugin.h, qgsrendererplugin.h) in qgis_core, since in the OS X framework setup there is no place for random headers. - core, gui, analysis, grass and sqlanywhere libs are now frameworks on OS X. I couldn't make qgispython a framework because it's loaded dynamically and the Qt dyld functions expect standard file extensions, and a framework has none (the binary inside the framework, that is). Really, grass and sqlanywhere don't need to be frameworks, maybe I got carried away there ;) There is also an option to install core, gui and analysis as developer frameworks. This gets around the potential problem of the internal relative path linking, and makes the libraries more accessible. The cmake option is QGIS_MACAPP_INSTALL_DEV (bool). They are installed by default in /Library/Frameworks, but this can be changed with QGIS_MACAPP_DEV_PREFIX. Note that the headers are not updated to make proper frameworks, so -I flags to each framework's Headers folder are still needed. (A proper framework header references other framework headers prefixed by the framework name, ie #includeqgis_core/qgis.h. Needs some discussion about reorganizing the headers in QGIS, if there is interest.) - William Kyngesburyekyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GIT open for pull requests on master
Hi Tim, Thanks for the update and all the hard work you and others have put in to get the transition to git completed. I look forward to the migration guide. Regards, John On May 8, 2011, at 6:57 AM, Tim Sutton wrote: Hi Folks Well we have been poking around with the qgis/Quantum-GIS github repo for the last week and I think it looks ok for us to continue to work against it. So unless there are any objections I would like to make it the 'official' code repository and update the docs etc. I will be adding some documentation on how to carry out your basic workflow with the new repo. One thing we briefly discussed on the IRC channel is not reinstating every committer from the svn committer list. Since we now work with a distributed model, it is simple for *anyone* interested in working against our code base to do so and contribute their changes back with very little effort. Also, external contributors get fully acknowledged as their name email are propogated into the code history when we pull from their repository or apply their patches (if they were created using the git patch preparation tool). As such it makes little sense for use to have tens of committers into the core repository, Instead I would like to suggest that we provide the most active committers with direct access to the repostory and let them apply pull requests from others as needed. The ability to work on QGIS is truly democratised with GIT and the purpose of committers to the core repo should (in my eyes) be just to perform a final screening for code quality etc before it makes its way into the repository. If you are an existing svn committer and feel strongly about wanting to have direct commit access to the master repo, please speak up now. With regards to the migration to redmine, I am waiting on osgeo to provide a backup and then we will attempt the migration - Alex Mandel has kindly offered to help with this - hopefully we will look at it later tonight. As such the release of 1.7 is still on hiatus until we get all our infrastructure updates done - small patches to fix issues in the release branch (no string changes please) are welcome in the mean time. Packagers are also encouraged to build test packages and submit any needed changes to support their packaging work. Best regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] Summary of hackfest activities
Hi Tim, Thanks for the summary of the meeting. These are always super helpful, especially as I was away and unable to lurk this time around. Cheers, John On Apr 19, 2011, at 1:54 AM, Tim Sutton wrote: Hi All If anyone is interested, I have posted some notes and thoughts following our Lisbon hackfest onto my blog. You can read more here: http://linfiniti.com/2011/04/wrapping-up-the-qgis-meeting-in-lisbon-april-2011/ Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qt contributor summit in Berlin
Hi Andreas, This sounds like a good idea. Perhaps someone is not too far away, maybe even someone who is quite familiar with the various bugs and qt-related issues. That person might even have the initials jef. ;-) Cheers, John On Apr 19, 2011, at 3:04 AM, Andreas Neumann wrote: Hi, I came across an info that there will be a qt contributors summit in Berlin, from June 16-18: http://labs.qt.nokia.com/2011/03/16/save-the-date-–-qt-contributors-summit/ It is about opening up qt and coordinating potential contributors. The event is invitation only, but one can request invitation if one has a reason to participate. I am wondering if QGIS should send a representative in order to speed up some open issues/bugs we have with the qt library (e.g. all the SVG issues we have, the PDF printing issues, other rendering/clipping issues, etc. etc.). What do the QGIS devs think? Would it be worth the effort to get in better touch with the qt community? Do we have something we can contribute to or benefit from such a summit? Andreas -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] r15685 Project properties on Mac
Hi Martin, Your update has added a non-standard menu item to the Mac platform. Now, a Settings menu item is present, but the items contained therein are found in other, more standard places. E.g., there is a Preferences... item under a QGIS menu item, typical of all mac applications. Perhaps a platform check is in order to exclude this change on macs. Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: QGIS hangs when trying to add stops in color ramp
This is addressed in trunk, although it requires the font and color dialogs to use qt widgets rather than native dialogs. I believe this is a qt bug, ultimately. John On Mar 31, 2011, at 4:15 PM, jabraham wrote: Cline, Royce L. wrote: It fails with any color or offset selection. The fact that it hangs whether I click OK or Cancel in the offset dialog would indicate a problem exiting this dialog in the GUI. I am having this problem with QGIS 1.6.0 on Mac Snow Leopard 10.6.7. Has a ticket been opened? Cline, Royce L. wrote: On May 28, 2010, at 9:10 AM, Martin Dobias wrote: On Sun, May 23, 2010 at 10:50 PM, Cline, Royce L. lt;rcl...@nd.govlt;mailto:rcl...@nd.govgt; wrote: Using the Style Manager, I an trying to create a stop in a gradient color ramp. With Multiple stops selected, i click the Add stop button and the color dialog appears where I then select the color and click OK. The Offset of the stop dialog appears. Whether I click Cancel or OK, QGIS no longer responds when the dialog closes. At this point I must kill QGIS. I'm unable to replicate the problem here (linux). Does it happen always, with any color and any offset? Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/QGIS-hangs-when-trying-to-add-stops-in-color-ramp-tp5091804p6228946.html Sent from the qgis-developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] String freeze for 1.7.0 in effect
On Mar 23, 2011, at 12:39 AM, Tim Sutton wrote: It would be actually nice to have on the front page the same project loaded on each platform and the three screenshots superimposed to give the user an immediate impression of 'this thing runs everywhere'. Hi all, I would recommend building something with the spearfish6 dataset, available with GRASS or from their website, I believe. You can create something fairly complex in appearance there. Just make sure everyone is working from the same projection now that raster OTF is implemented. Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] rendering behavior options not available
Hi William, I believe this all can be traced back to this: http://trac.osgeo.org/qgis/changeset/8421 Although I am not sure if that is true of the option to turn the on/off when loaded. I manually turned on the 'qgis.new_layers_visible' in the plist file and it seems to work fine. Ah, it appears that the fix for Mac rendering redraw problems was to disable the entire groupBox_5 in the qgsoptions.cpp file for Mac systems. John On Mar 20, 2011, at 6:12 PM, William Kyngesburye wrote: I wanted to test the recent [spatialite] loading speed issue by turning layers off before saving a project. There is a QGIS render preference to turn on/off layers by default when adding them to a project, but it is greyed out (and checked on), along with the other render behavior options, # features to draw and render cache (unchecked). I think it's always been greyed out as far back as I can remember. Why are these options present if they can't be changed? Do I need to enable something in compilation? Is it dependent on another option? If they can't be changed at all, they shouldn't be shown in the application preferences. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] rendering behavior options not available
Here is a patch to allow that option to be set on OS X systems. It does not get at the root concern about unavailable items being present in the gui. And speaking of gui issues on OS X, can you confirm if the Help menu item is not showing up as the third item from the right in the menubar? That is so for me, but it should be the rightmost item. John On Mar 20, 2011, at 8:31 PM, John C. Tull wrote: Hi William, I believe this all can be traced back to this: http://trac.osgeo.org/qgis/changeset/8421 Although I am not sure if that is true of the option to turn the on/off when loaded. I manually turned on the 'qgis.new_layers_visible' in the plist file and it seems to work fine. Ah, it appears that the fix for Mac rendering redraw problems was to disable the entire groupBox_5 in the qgsoptions.cpp file for Mac systems. John On Mar 20, 2011, at 6:12 PM, William Kyngesburye wrote: I wanted to test the recent [spatialite] loading speed issue by turning layers off before saving a project. There is a QGIS render preference to turn on/off layers by default when adding them to a project, but it is greyed out (and checked on), along with the other render behavior options, # features to draw and render cache (unchecked). I think it's always been greyed out as far back as I can remember. Why are these options present if they can't be changed? Do I need to enable something in compilation? Is it dependent on another option? If they can't be changed at all, they shouldn't be shown in the application preferences. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer qgsoptions_mac2.diff Description: Binary data ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: Composer issue
Thanks for the rapid fix, Marco! My test dataset worked properly. Cheers, John On Mar 16, 2011, at 12:50 PM, Radim Blazek wrote: Registered. Radim On Wed, Mar 16, 2011 at 6:43 PM, John C. Tull john.t...@wildnevada.org wrote: I added a bug to the queue that has been confirmed on linux and osx: https://trac.osgeo.org/qgis/ticket/3622 This one is a real problem for carto output in QGIS. I'm not sure if this is a result of a change in the raster handling or something in the composer itself, but it appears to be the former. I was able to get a successful map produced with rev 15382, but nothing beyond that (there were separate crash issues for OSX not resolved on my platform until rev 15412, so it may have cropped up anywhere in that span of code updates). Thanks for helping get this resolved. John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Composer issue
I added a bug to the queue that has been confirmed on linux and osx: https://trac.osgeo.org/qgis/ticket/3622 This one is a real problem for carto output in QGIS. I'm not sure if this is a result of a change in the raster handling or something in the composer itself, but it appears to be the former. I was able to get a successful map produced with rev 15382, but nothing beyond that (there were separate crash issues for OSX not resolved on my platform until rev 15412, so it may have cropped up anywhere in that span of code updates). Thanks for helping get this resolved. John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Visibility Analysis in QGIS
I wondered if you noticed this email exchange on the QGIS list last fall. I just revisited this issue and it persists. If you have any chance to resolve this, it would be useful for the QGIS community. http://lists.osgeo.org/pipermail/qgis-developer/2010-October/011326.html Thanks, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: Testing 1.7 unstable: Loading project made with qgis1.6 with trunk 15429 and previous crash with segfault
I opened a ticket. Thanks for finding the solution Marco: http://trac.osgeo.org/qgis/ticket/3594 Cheers, John On Mar 11, 2011, at 3:45 AM, Borys Jurgiel wrote: Dnia piątek 11 marca 2011 o 11:03:04 marco bra napisał(a): ok solved i replaced all occurences of provider/provider with providergdal/provider Now old 1.6 project with raster are opened with success. Thank you Not a solution for regular users :) Could you please open a ticket and set MustFix to 'yes'? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 1 Mac section was skipped in r15383
Ok, so removing lines 13-15 in qgisapp.ui worked. I had to run make clean to get it to stick. Cheers, John Can someone post a diff for this or patch the source. I'm not sure what the line edits are that need to occur. Thanks, John On Mar 8, 2011, at 8:42 AM, Martin Dobias wrote: On Tue, Mar 8, 2011 at 5:29 PM, Tom Elwertowski telwertow...@comcast.net wrote: The following workaround may shed some light on the source of the problem: Comment out the first line of retranslateUI in ui_ggisapp.h (MainWindow-setWindowTitle) This suggests to me that something needed by setWindowTitle for this object may not be initialized yet. Hmm... would it help to completely remove windowTitle property from main window in qgisapp.ui file? Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster on the fly
I am running into problems with some existing project files. Here's a crash dump: Warning: QgsRasterLayer::setDataProvider: Data provider is invalid. ERROR 10: Pointer 'hDS' is NULL in 'GDALGetRasterCount'. QGIS(71351,0x7fff70df5ca0) malloc: *** mmap(size=18446744069414588416) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Warning: Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. Abort trap Cheers, John On Mar 9, 2011, at 12:49 AM, Radim Blazek wrote: Does it crash if you open an old qgs project or if you start qgis and add new layers manualy? Radim On Wed, Mar 9, 2011 at 2:55 AM, custard cust...@westnet.com.au wrote: I can confirm this with this data. It is further than I get with my datasets. I usually only get to step 2, and the datum is unimportant. It's quite annoying because it means that any dataset I have with a raster, and on the fly selected causes qgis-dev to crash. -ramon. - Original Message - From: Luiz Motta motta.l...@gmail.com To: qgis-dev qgis-developer@lists.osgeo.org Sent: Wednesday, 9 March, 2011 9:26:09 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi Subject: [Qgis-developer] Raster on the fly Devs, I had problem with image to set on the fly. The example of image is: http://www.engesat.com.br/cddemo/ikonos/11bits/composicao/psm/geotiff/guaxupe_psm11.zip I am testing with: 1) Windows XP 2) QGIS 1.7 r15395 The QGIS crash with steps below: 1) Open image 2) Enable on the fly with CRS WG84/Geographic (EPSG 4326) 3) Zoom to layer extent * Crash Regards, Luiz Motta ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster on the fly
A more detailed, debug report, is available here: http://paste.ubuntu.com/578043/ Cheers, John On Mar 9, 2011, at 12:22 PM, John C. Tull wrote: I am running into problems with some existing project files. Here's a crash dump: Warning: QgsRasterLayer::setDataProvider: Data provider is invalid. ERROR 10: Pointer 'hDS' is NULL in 'GDALGetRasterCount'. QGIS(71351,0x7fff70df5ca0) malloc: *** mmap(size=18446744069414588416) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Warning: Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there. Abort trap Cheers, John On Mar 9, 2011, at 12:49 AM, Radim Blazek wrote: Does it crash if you open an old qgs project or if you start qgis and add new layers manualy? Radim On Wed, Mar 9, 2011 at 2:55 AM, custard cust...@westnet.com.au wrote: I can confirm this with this data. It is further than I get with my datasets. I usually only get to step 2, and the datum is unimportant. It's quite annoying because it means that any dataset I have with a raster, and on the fly selected causes qgis-dev to crash. -ramon. - Original Message - From: Luiz Motta motta.l...@gmail.com To: qgis-dev qgis-developer@lists.osgeo.org Sent: Wednesday, 9 March, 2011 9:26:09 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi Subject: [Qgis-developer] Raster on the fly Devs, I had problem with image to set on the fly. The example of image is: http://www.engesat.com.br/cddemo/ikonos/11bits/composicao/psm/geotiff/guaxupe_psm11.zip I am testing with: 1) Windows XP 2) QGIS 1.7 r15395 The QGIS crash with steps below: 1) Open image 2) Enable on the fly with CRS WG84/Geographic (EPSG 4326) 3) Zoom to layer extent * Crash Regards, Luiz Motta ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
I tested your updates in the raster branch today. Things look real good from my examination of the WMS capabilities. I did have a problem with the extents occasionally jumping to some very different location, but I would not consider this a show stopper. Again, this was with a WMS layer being reprojected, but no other rasters. Cheers, John On Mar 6, 2011, at 12:18 PM, Radim Blazek wrote: Hi, I am ready to merge raster-providers branch to trunk. Are you ready too? Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Thanks for the update on this, Radim. I see that there will be some challenges to work out with wms and reprojection. Thanks for you hard work and great dev efforts, John On Mar 5, 2011, at 2:21 AM, Radim Blazek wrote: Hi, WMS reprojection should be fixed in sense that you get it rendered in the right place, but quality and even content is not the same like for not project on the same scale. Of course. To find the best resolution coefficient is one thing which has to be done. Higher resolution in WMS request can give you (really gives?) slightly better image but the content becomes inappropriate. Currently th QgsRasterReprojector is using just nearest neighbour, another resampling methods should be considered. Another issue is, that WMS driver does not automatically switches to projection requested by QGIS even if it is supported by WMS server. You have to manually select the right projection when layer is added. Preferably, the WMS driver should not only to switch to the right projection, but also automatically select the most similar projection offered by server if no one exactly matches. Anybody is aware of an algorithm or ready for use method doing that? Raster rendering appeared to be infinite entertainment. Radim On Mon, Feb 28, 2011 at 1:12 AM, John C. Tull jct...@gmail.com wrote: Hi, I was testing a little today. It appears that WMS layers are not being projected. I would imagine that needs to be corrected before a merge. Also, openlayers are not correctly projecting based on some quick tests on my end. I'm not sure if this is a problem with the branch or the plugin. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] macosx dialog issues
Hi Carson, On Mar 5, 2011, at 11:28 AM, Carson Farmer wrote: Hi John, I believ José had problems with: - Geoprocessing tools available as Intersect two layers Works for me. - Data management tools as Export to projection Also works fine for me. The only problem I had was with Merge Shapefiles. If I tick the 'Select by layers in the folder', I cannot choose a folder in the dialog. The Ok button never becomes available when trying to select a folder. I can select a shapefile and the OK button is available. I might be misunderstanding what this option is intended to do. When turning it off, I can select a folder, but the tool crashed qgis. This was because my folder had mixed geometry types. See output below. I suppose this crash should be avoided somehow. Hmm, ok I'll look into this one, thanks for the update. I hope it is easily solved. One random thought arose as I tested the tools. Why is the random select tool limited to 30 features? What? It shouldn't be? Unless your layer only has 30 features? Ok, tested again and it worked fine. I must have been working on a layer with only 30 features and did not make the connection there. It works as it should. Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Raster providers
Hi, I was testing a little today. It appears that WMS layers are not being projected. I would imagine that needs to be corrected before a merge. Also, openlayers are not correctly projecting based on some quick tests on my end. I'm not sure if this is a problem with the branch or the plugin. Cheers, John On Feb 27, 2011, at 12:54 PM, Tim Sutton wrote: Hi 8-snip- - it would be nice if the 'collar' - the part outside the image data area in rotated images was made transparent by default. Isn't it? The data outside source data extent are null. That is the source of all the troubles with null values handling and types remapping. The grey border around the tif you posted is part of the image. Is not? Sorry you are right - the issue lies with my data. Do you have anything else left on your todo list before you can merge to trunk? +1 from me to merge when you are ready I would like to make some cleanups to the raster properties dialog after you are done...hopefully I can do the ui clean upsin time for 1.7 Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: Raster providers
Hi Radim, I tried building today on OS X. The build failed with the following output: ... [ 20%] Building CXX object src/analysis/CMakeFiles/qgis_analysis.dir/qgsrastercalcparser.cpp.o Linking CXX shared library libqgis_analysis.dylib [ 20%] Built target qgis_analysis [ 20%] Generating analysis/sipanalysispart0.cpp, analysis/sipanalysispart1.cpp, analysis/sipanalysispart2.cpp, analysis/sipanalysispart3.cpp sip: /Users/jctull/sources/qgis/raster-providers/python/core/conversions.sip:326: %MappedType template for this type has already been defined make[2]: *** [python/analysis/sipanalysispart0.cpp] Error 1 make[1]: *** [python/CMakeFiles/python_module_qgis_analysis.dir/all] Error 2 make: *** [all] Error 2 I have no such problem building from a fresh copy of qgis trunk. Regards, John On Jan 8, 2011, at 11:26 AM, Radim Blazek wrote: Hi all, new raster providers are ready for testing. The work is not yet finished but all the old functionality should be available. Current status: - GDAL: on-the-fly reprojection via gdal warp, quite slow, I have not yet implemented the trick used in Mapserver Marco pointed me to. Please let me know, if you consider the speed at least acceptable for real work. The speed depends especially on output display size. - GRASS: all the old functionality is back, the data are provided instead of just a picture so that it is possible to assign a style in QGIS like it was possible with GRASS via GDAL, reprojection is not yet implemented - WMS: should work like before, the requested SRS does not yet follow current project projection Please test the raster providers branch and let me know about problems: svn co https://svn.osgeo.org/qgis/branches/raster-providers I would like to merge the branch to trunk and continue the work in trunk. Radim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] New composer option
Hi Marco, I was wondering what the new draw map canvas items option does in the composer. I am at a loss to figure it out with some quick testing. Thanks, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] gdal and zip archives
Hi all, GDAL has support for reading raster files that are either zip or gzip archived. I've got many 24k topo maps that I would like to leave in their zip format to save hard drive space. GDAL on my system is capable of working on them, e.g., 'gdalinfo /vsizip/o35114a1.zip/o35114a1.tif' provides a summary of the raster properties. Unfortunately, qgis does not know how to handle these files, at least on my system. As you can see in the gdal trac report ( http://trac.osgeo.org/gdal/ticket/1369 ), you have to prepend, in the example above, '/vsizip/ to the file name and append the actual file name that is inside the zip archive, unless it is the only file in the archive. This is probably not very practical for qgis to try and guess the file inside the archive, nor does it make sense to ask the user every time one of these files is loaded. But, it is relatively trivial for the user to create a vrt for one or more source files within zip archives, e.g., 'gdal_translate -of vrt /vsizip/o35114a1.zip/o35114a1.tif o35114a1.vrt'. Although I would hope this file would work in qgis, it does not. I tested in GRASS by running r.in.gdal on the vrt file as well as on /vsizip/o35114a1.zip/o35114a1.tif and it imported successfully both times. Could others test this on non-OSX systems to see if qgis handles this correctly for them? The file, about 1.5mb, that I used is available here: ftp://anonym...@dataworks.library.unr.edu/keck/DRG%26Topos/24k/clipped/o37117f4.zip Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Label movement tools
Hi Marco, The new label placement tools are an excellent addition to qgis. I tried to test these on OSX, but they seem to be non-functional. For my test case, I added a polygon shapefile, used the advanced labeling plugin to label the layer with default settings and a valid text field, then clicked the move tool. I get a plus symbol cursor, but clicking on a label does not do anything. This is true for the other tools also. I look forward to using this. Let me know if I can provide any details that might help you get to the underlying problem on OS X. Thanks, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] OS X trunk build issues
Hi William, Have you attempted to build off of the current trunk source? I'd be interested in your verification of the issue that I presented in this ticket: http://trac.osgeo.org/qgis/ticket/3215 Thanks, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] OS X trunk build issues
Things are still not working for me, and I have been behind a firewall unable to get on irc to chat with Jüergen. Perhaps I can assist in testing some code ideas he may have later in the week. On Nov 16, 2010, at 3:54 PM, William Kyngesburye wrote: I think I saw something pass thru the tracker with some isnan updates, after r14601. But I haven't tried anything in svn yet. On Nov 16, 2010, at 5:39 PM, John C. Tull wrote: Hi William, Have you attempted to build off of the current trunk source? I'd be interested in your verification of the issue that I presented in this ticket: http://trac.osgeo.org/qgis/ticket/3215 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life. - Marvin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] OS X trunk build issues
I took out all of the ifdef's setting math.h for OS X on these and other header files that used that. Additionally, I had to append std:: to the isnan and isinf in the two if statements, e.g.: if ( std::isnan( inX[i2] ) || std::isnan( inY[i2] ) || std::isinf( inX[i2] ) || std::isinf( inY[i2] ) || std::isnan( inX[i1] ) || std::isnan( inY[i1] ) || std::isinf( inX[i1] ) || std::isinf( inY[i1] ) ) in the qgsclipper.h file. Likely, there might need to be an ifdef for Q_OS_MACX in this file for this. I got a successful build afterwards. John On Nov 16, 2010, at 5:10 PM, William Kyngesburye wrote: ... Well, the problem is not isnan, that's just what r14601 mentioned. The problem is abs(), and this has come up before for OS X - I think it had something to do with the order of includes. There are a lot of places in Qgis that use abs() (more than just the 2 interpolator sources changed in r14601), and they generally include cmath/math.h after most other includes. Strange, there is a lot of inconsistent use of the includes and function calls: some always include cmath and use std::abs() some conditionally include math.h for OS X and cmath for all other systems, and use abs() (without the std C++ namespace) ... so, cmath seems to work on OS X in those other parts of Qgis (maybe there were problems with cmath on older OS X systems?), so just always include cmath. Worked for me on 10.6, but should be checked on older systems (at least 10.5). I might be able to try that this week (I do need to build the 1.6 PPC package still). On Nov 16, 2010, at 5:56 PM, John C. Tull wrote: Things are still not working for me, and I have been behind a firewall unable to get on irc to chat with Jüergen. Perhaps I can assist in testing some code ideas he may have later in the week. On Nov 16, 2010, at 3:54 PM, William Kyngesburye wrote: I think I saw something pass thru the tracker with some isnan updates, after r14601. But I haven't tried anything in svn yet. On Nov 16, 2010, at 5:39 PM, John C. Tull wrote: Hi William, Have you attempted to build off of the current trunk source? I'd be interested in your verification of the issue that I presented in this ticket: http://trac.osgeo.org/qgis/ticket/3215 - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life. - Marvin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Errors in OS X script
Hi William, It appears that some script components in, at least, the MinSizeRel build are not working. They seem to be expecting a directory in the application bundle that is not present. The following is at the end of the 'make install' command: -- Updating QGIS library paths... install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) My cmake command is this: cmake -D CMAKE_INSTALL_PREFIX=/Applications -D CMAKE_BUILD_TYPE=Release -D CMAKE_BUILD_TYPE=MinSizeRel -D WITH_INTERNAL_SPATIALITE=FALSE .. Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Errors in OS X script
Yes, -D WITH_MAPSERVER=TRUE works and no complaints from the script. Cheers, John On Nov 15, 2010, at 8:07 AM, William Kyngesburye wrote: ... looks like the mapserver component was recently made optional, off by default. The error is harmless, but I'll fix it to check first. If you want to test the mapserver, add to configuration: -D WITH_MAPSERVER On Nov 15, 2010, at 9:57 AM, John C. Tull wrote: Hi William, It appears that some script components in, at least, the MinSizeRel build are not working. They seem to be expecting a directory in the application bundle that is not present. The following is at the end of the 'make install' command: -- Updating QGIS library paths... install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) install_name_tool: can't open file: /Applications/QGIS.app/Contents/MacOS/fcgi-bin/qgis_mapserv.fcgi (No such file or directory) My cmake command is this: cmake -D CMAKE_INSTALL_PREFIX=/Applications -D CMAKE_BUILD_TYPE=Release -D CMAKE_BUILD_TYPE=MinSizeRel -D WITH_INTERNAL_SPATIALITE=FALSE .. Cheers, John___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Those people who most want to rule people are, ipso-facto, those least suited to do it. - A rule of the universe, from the HitchHiker's Guide to the Galaxy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Time to retire OS X Xcode project
+1 to change the qwt build instructions to better conform with other systems. On Nov 11, 2010, at 11:12 AM, William Kyngesburye wrote: ... ah, the cmake check tests /usr/local/lib, but the qwt build uses an isolated versioned subfolder. It's not just the local copy in the pyqwt source, but the way the main qwt source is distributed, so the qwt detection needs some tweaking, though that could get messy. Or I could change the Mac instructions to remove the versioned subfolder from the qwt install location (probably matches better how binaries in linux distros are done). On Nov 11, 2010, at 12:53 PM, John C. Tull wrote: Hi William, I am trying to follow your instructions and new cmake build procedure. Upon running the basic cmake command: cmake -D CMAKE_INSTALL_PREFIX=~/Applications -D CMAKE_BUILD_TYPE=Release \ -D CMAKE_BUILD_TYPE=MinSizeRel -D WITH_INTERNAL_SPATIALITE=FALSE \ .. I run into an error in finding qwt: CMake Error at cmake/FindQWT.cmake:41 (MESSAGE): Could not find QWT Call Stack (most recent call first): CMakeLists.txt:143 (FIND_PACKAGE) I had to add the paths to qwt lib and include with the appropriate flags or using ccmake. Thanks, John On Nov 10, 2010, at 1:17 PM, William Kyngesburye wrote: It's all pretty much done now in SVN, and should be in the 1.6 release. See the INSTALL document in SVN for build details. For Qwt, I have the install_name_tool step there. All that's left is the final bundling step for the standalone, but that will have to wait for a gdaltools issue. On Nov 10, 2010, at 2:52 PM, John C. Tull wrote: I've not been monitoring the list lately. Feel free to contact me offline if you want to compare notes on cmake builds, although you are probably all caught up with my level of knowledge already. FWIW, this is the cmake command I run when building with your frameworks. cmake -D BINDINGS_GLOBAL_INSTALL=on\ -D QWT_INCLUDE_DIR=/usr/local/qwt-5.2.1-svn/include\ -D QWT_LIBRARY=/usr/local/qwt-5.2.1-svn/lib/libqwt.5.dylib\ -D CMAKE_INSTALL_PREFIX=/Applications\ -D CMAKE_BUILD_TYPE=Release -D SIP_BINARY_PATH=/usr/local/bin/sip\ -D CMAKE_OSX_ARCHITECTURES=x86_64\ -D GRASS_PREFIX=/Applications/GRASS-6.4.app/Contents/MacOS\ -D GRASS_INCLUDE_DIR=/Applications/GRASS-6.4.app/Contents/MacOS/include .. You may have run into the quirky issues with qwt by now. That, of course, is not a qgis issue but qwt. I still have not managed to build qwt in a manner that does not require the install_name_tool command. I'm glad to know you will be continuing to help out with qgis. I started to panic when I first started reading your email. Regards, John On Oct 28, 2010, at 3:57 PM, William Kyngesburye wrote: It's been a bit (lot?) of work maintaining sync with the cmake build. Other problems with it (both new and from day 1): Not to fear! I've taken the plunge into cmake and have been working on a cmake overhaul for the OS X build. I was going to wait for after the sudden 1.6 release, but since I'm not having luck with yacc/lex in Xcode I should have at least the core changes done for 1.6 (up to bundling Qt frameworks is done now, but not in SVN yet). Part of the cmake overhaul is to make sure library linking is all fixed up (it's been a problem in the past). Another improvement is cleaner (and automatic) detection of my frameworks (needed for bundling to work). The main improvement is making the bundling steps part of the install. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ I ache, therefore I am. Or in my case - I am, therefore I ache. - Marvin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life. - Marvin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Time to retire OS X Xcode project
I've not been monitoring the list lately. Feel free to contact me offline if you want to compare notes on cmake builds, although you are probably all caught up with my level of knowledge already. FWIW, this is the cmake command I run when building with your frameworks. cmake -D BINDINGS_GLOBAL_INSTALL=on\ -D QWT_INCLUDE_DIR=/usr/local/qwt-5.2.1-svn/include\ -D QWT_LIBRARY=/usr/local/qwt-5.2.1-svn/lib/libqwt.5.dylib\ -D CMAKE_INSTALL_PREFIX=/Applications\ -D CMAKE_BUILD_TYPE=Release -D SIP_BINARY_PATH=/usr/local/bin/sip\ -D CMAKE_OSX_ARCHITECTURES=x86_64\ -D GRASS_PREFIX=/Applications/GRASS-6.4.app/Contents/MacOS\ -D GRASS_INCLUDE_DIR=/Applications/GRASS-6.4.app/Contents/MacOS/include .. You may have run into the quirky issues with qwt by now. That, of course, is not a qgis issue but qwt. I still have not managed to build qwt in a manner that does not require the install_name_tool command. I'm glad to know you will be continuing to help out with qgis. I started to panic when I first started reading your email. Regards, John On Oct 28, 2010, at 3:57 PM, William Kyngesburye wrote: It's been a bit (lot?) of work maintaining sync with the cmake build. Other problems with it (both new and from day 1): - non-user-friendly configuration (hand-edit a file!), though I had an idea to patch in configuration from cmake - no automatic optional target compilation - if you didn't want or didn't have the support for an optional plugin or feature, you had to build individual targets - the dependency tracking of Xcode never worked right for custom compile rules (moc, rcc,...) so recompiling a partially-compiled source or after changes to sources always recompiled those with custom rules, even if they didn't change - the builtin yacc/lex rules don't work right, and custom rules are cranky, which leads to the final straw today when trying to add a new yacc/lex pair for the raster calculator change - failure Not to fear! I've taken the plunge into cmake and have been working on a cmake overhaul for the OS X build. I was going to wait for after the sudden 1.6 release, but since I'm not having luck with yacc/lex in Xcode I should have at least the core changes done for 1.6 (up to bundling Qt frameworks is done now, but not in SVN yet). Part of the cmake overhaul is to make sure library linking is all fixed up (it's been a problem in the past). Another improvement is cleaner (and automatic) detection of my frameworks (needed for bundling to work). The main improvement is making the bundling steps part of the install. There may be a small delay for my binary packages for the 1.6 release while I finish the bundling scripts (or I figure out a hack in Xcode for the yacc/lex problem). Things I will miss from Xcode: - debugging in the Xcode GUI, though I haven't needed to set that up so far - nothing else really, Xcode/Cmake doesn't matter to me as long as it compiles QGIS and bundles everything needed for release - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Visibility analysis
This is also a problem for me. Is the dev on this list? Cheers, John On Oct 22, 2010, at 1:12 PM, Tim Sutton wrote: Hi I also couldnt work out any number that was valid to put in there... Regards Tim On Thu, Oct 21, 2010 at 8:34 PM, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. I keep on getting this error: Please enter a positive or zero height for observer even if I entered 100 or othe numbers. Any hint? All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: cmake error on OS X 10.6
Matthew, Is there a specific reason to use python.org? Generally speaking, it seems to prove best on OS X to avoid overriding system provided bins and libs when possible. Cheers, John On Sep 17, 2010, at 1:39 PM, William Kyngesburye wrote: I think it will default to 32bit. On Sep 17, 2010, at 1:47 PM, Matthew Denno wrote: Using python configure.py takes care of the architecture (I.e. 32 vs 64 bit) too? On Sep 17, 2010 1:56 PM, William Kyngesburye wokl...@kyngchaos.com wrote: With the python.org python, you just use the first form: python configure.py That defaults to putting everything in the python framework. That said, I haven't tried it in a long time, since I don't use the python.org python. You may get deployment target complaints from python. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ All generalizations are dangerous, even this one. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: cmake error on OS X 10.6
As far as I can tell, I do not have any remnant gsl laying around. I upgraded my hardware in the past 6 months and started afresh with additional unix libs, binaries, etc. I did not install any gsl other than your framework to my knowledge. I believe some updates occurred in the past 6-10 months with egis where your frameworks are automagically picked up by cmake. Here is my commandline output from running the cmake command I posted: -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Checking whether C compiler has -isysroot -- Checking whether C compiler has -isysroot - no -- Checking whether C compiler supports OSX deployment target flag -- Checking whether C compiler supports OSX deployment target flag - no -- Check for working C compiler: /usr/local/bin/ccache -- Check for working C compiler: /usr/local/bin/ccache -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Checking whether CXX compiler has -isysroot -- Checking whether CXX compiler has -isysroot - no -- Checking whether CXX compiler supports OSX deployment target flag -- Checking whether CXX compiler supports OSX deployment target flag - no -- Check for working CXX compiler: /usr/local/bin/ccache -- Check for working CXX compiler: /usr/local/bin/ccache -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Quantum GIS version: 1.6.0 Trunk (10600) -- Found GRASS: /Applications/GRASS-6.4.app/Contents/MacOS (6.4.0) -- Found Iconv: /usr/lib/libiconv.dylib -- Looking for openpty -- Looking for openpty - found -- Found Proj: /Library/Frameworks/proj.framework -- Found Expat: /usr/lib/libexpat.dylib -- Using GSL from /Library/Frameworks/GSL.framework/Versions/1/unix -- Found GEOS: /Library/Frameworks/GEOS.framework/Versions/3/unix/lib/libgeos_c.dylib -- Found GDAL: /Library/Frameworks/GDAL.framework/Versions/1.7/unix/lib/libgdal.dylib -- Found PostgreSQL: /usr/local/pgsql/lib/libpq.dylib -- Found QWT: /usr/local/qwt-5.2.1-svn/lib/libqwt.5.dylib -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - not found. -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found. -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found. -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - found -- Looking for QT_MAC_USE_COCOA -- Looking for QT_MAC_USE_COCOA - found -- Found Qt-Version 4.7.0 (using /usr/bin/qmake) -- Found PythonInterp: /System/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 -- Found Python executable: /System/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 -- Found Python version: 2.6.1 -- Found Python library: -framework Python -- Found SIP version: 4.10.5 -- Found PyQt4 version: 4.7.4 -- Found FCGI: /usr/lib/libfcgi.dylib -- Configuring done -- Generating done -- Build files have been written to: /Users/jctull/sources/qgis/trunk/build You can see that gsl, proj and others were discovered just fine. Cheers, John On Sep 16, 2010, at 7:57 AM, William Kyngesburye wrote: Interesting. You don't have problems with GSL or PROJ frameworks? Maybe you have an old /usr/local GSL from before my framework? I suppose I should give it a whirl to make sure it's all working... On Sep 16, 2010, at 9:50 AM, John C. Tull wrote: I use cmake regularly, and William's frameworks otherwise. I have an alias in my bash profile setup with the following command: cmake -D BINDINGS_GLOBAL_INSTALL=on -D QWT_INCLUDE_DIR=/usr/local/qwt-5.2.1-svn/include -D QWT_LIBRARY=/usr/local/qwt-5.2.1-svn/lib/libqwt.5.dylib -D CMAKE_INSTALL_PREFIX=/Applications -D CMAKE_BUILD_TYPE=Release -D SIP_BINARY_PATH=/usr/local/bin/sip -D CMAKE_OSX_ARCHITECTURES=x86_64 -D GRASS_PREFIX=/Applications/GRASS-6.4.app/Contents/MacOS -D GRASS_INCLUDE_DIR=/Applications/GRASS-6.4.app/Contents/MacOS/include .. Hope that helps. John On Sep 15, 2010, at 8:21 PM, William Kyngesburye wrote: I confess that since setting up the Xcode project, I use it exclusively and haven't tried a cmake build in a while, though others have with success. The Qgis cmake configure should automatically find known frameworks. GDAL and GEOS are known, but GSL is fairly recent as a framework and the cmake stuff wasn't updated. Odd, I see that the cmake test for PROJ doesn't check for a framework. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] Qgis plugin and typeid issues
Hi Emmanuel, You probably want to send this to the dev list (cc'd in this email). Good luck with your work, John On Aug 23, 2010, at 2:08 AM, Emmanuel Christophe wrote: Hi all, I'm working on the OTB (www.orfeo-toolbox.org) Qgis plugins: the objective is to provide more raster processing capabilities to Qgis. I run into a tricky C++ issue. In one particular case, one typeid resolution does not seems to work. I believe that it is linked with the issue mentioned here: http://gcc.gnu.org/faq.html#dso dynamic_cast, throw, typeid don't work with shared libraries (I'm currently working with gcc and trying to make it work with shared libraries). What make me think that this is linked to this issue is that: - the plugin is loaded using dlopen by qgis - the typeid is created by some code compiled in the plugin (OTB uses templates extensively, so this particular piece of OTB code is compiled during the plugin compilation) and the resulting type_info is passed to another dynamic library that was compiled before (during OTB compilation). So it seems that we are in the third case mentioned by the FAQ. In this situation, the FAQ recommend to First, export global symbols from the executable by linking it with the -E flag. You must also make the external symbols in the loaded library available for subsequent libraries by providing the RTLD_GLOBAL flag to dlopen. The symbol resolution can be immediate or lazy. The RTLD_GLOBAL flag seems to be provided (src/app/qgspluginmanager.cpp:256), but I'm not sure about the -E flag while linking. Can anybody with more experience in Qgis compilation confirm? Is there any other plugin I should look at for inspiration? Emmanuel ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qgis plugin and typeid issues
Hi Emmanuel, Looks like my chronological review of email caused me to miss this. Good luck, John On Aug 23, 2010, at 2:33 AM, Emmanuel Christophe wrote: Hi all, (sorry for double posting, the developer list seems more appropriate) I'm working on the OTB (www.orfeo-toolbox.org) Qgis plugins: the objective is to provide more raster processing capabilities to Qgis. I run into a tricky C++ issue. In one particular case, one typeid resolution does not seems to work. I believe that it is linked with the issue mentioned here: http://gcc.gnu.org/faq.html#dso dynamic_cast, throw, typeid don't work with shared libraries (I'm currently working with gcc and trying to make it work with shared libraries). What make me think that this is linked to this issue is that: - the plugin is loaded using dlopen by qgis - the typeid is created by some code compiled in the plugin (OTB uses templates extensively, so this particular piece of OTB code is compiled during the plugin compilation) and the resulting type_info is passed to another dynamic library that was compiled before (during OTB compilation). So it seems that we are in the third case mentioned by the FAQ. In this situation, the FAQ recommend to First, export global symbols from the executable by linking it with the -E flag. You must also make the external symbols in the loaded library available for subsequent libraries by providing the RTLD_GLOBAL flag to dlopen. The symbol resolution can be immediate or lazy. The RTLD_GLOBAL flag seems to be provided (src/app/qgspluginmanager.cpp:256), but I'm not sure about the -E flag while linking. Can anybody with more experience in Qgis compilation confirm? Is there any other plugin I should look at for inspiration? Emmanuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] advanced selection tools (r14071)
On Aug 13, 2010, at 7:39 AM, Andreas Neumann wrote: All in all I am a little concerned that the selection tools take up too much screen space - which brings us back to the discussion - why don't we introduce drop-down buttons for selection mode? +1 John ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] advanced selection tools (r14071)
On Aug 13, 2010, at 7:39 AM, Andreas Neumann wrote: All in all I am a little concerned that the selection tools take up too much screen space - which brings us back to the discussion - why don't we introduce drop-down buttons for selection mode? +1 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
