Re: [Qgis-developer] Wiki page/area for 'Building QGIS from scratch'
Replies to multiple messages inline, elow. Tim Sutton <t...@kartoza.com> wrote on Tue, 21 Mar 2017 at 21:43:07 +0200: > John have you considered just running QGIS in docker - its probably > a much easier approach than the method you have embarked upon... I think your question was directed to Mark Johnson, not to me? But since you asked, I found the rational raised in this thread to be...stunningly unconvincing!: Nathan Woodrow <madman...@gmail.com> wrote Sat, 18 Mar 2017 at 22:40:21 +1000: > The wiki information got outdated very fast, The reason documentation gets outdated is typically because of a lack of maintainers (possibly related to lack of visibility), and also an overly high bar to editing it. A wiki is generally the lowest bar possible. If the problem is information getting outdated quickly, moving away from a wiki seems a step in the wrong direction, not the right one. > and was also not translatable easily. I'm not very familiar with translation issues, but my understanding is they aren't usually strictly format-dependent. (But I should acknowledge my deep biases as an English speaker.) > A decision was made a while ago for official documentation should be > done int the same workflow as the website in order to streamline > that process I'm not sure why a streamlined website process ought to have any bearing on the quality or accessibility of documentation. This seems a second-class issue. > and make sure everyone is using the same tools. I'm also not sure I understand this or why it is important for documentation; or more important than good documentatoin. Richard Duivenvoorde <rdmaili...@duif.net> Sat, 18 Mar 2017 at 15:55:34 +0100: > And can I add the constant hard fight against fake user accounts adding > wiki spam? (see osgeo wiki). Yes, this I understand; and this is the constant tension between lowering the barrier of entry far enough to make it easy for casual contributors to crowdsource information, and lowering it too far to make it too easy for spammers. Except it seems like the osgeo wiki has finally evolved a fairly effective solution (modulo the fact that it's awful hard to get a mantra and credentials!). > The workflow we have now is translatable, can be build to pdf's, is > versioned and is continuously tested/rebuild. Continuous testing is super-helpful for code. It's nice for documentation, but not really in the same way. I'd much rather have good documentation than continuously-tested documentation. Maybe that's an artificial tradeoff and we can have both. But I'm not convinced (not that I need to be; again, I'm new here and so far mostly send long emails.) --jh...@mit.edu John Hawkinson ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RE. Wiki page/area for 'Building QGIS from scratch'
I'm new here, so I'll ask the obvious question: Wikis are great because they lower the bar to collaboration. It's really easy to make edits and you don't have to worry about them getting approved and that's awesome. Really easy workflow, more so than github pull requests. New and potential contributors don't get discouraged. What's the reason for putting up barriers to documentation like this? Problems with spam or low quality edits? Can I find a robust discussion of the tradeoffs in the list archives? --jh...@mit.edu John Hawkinson ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] 3.0 Documentation and branching
Good documentation processes encourage documentation to land when features land. If the process doesn't do that, QGIS will always be falling behind. --jh...@mit.edu John Hawkinson ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS3 theme?
For what it's worth, it's apparently Adobe Illustrator's 30th anniversary, and the Ai team put together a summary of toolbar changes to the program over the years, in graphical form: https://pbs.twimg.com/media/C57NqY7VMAA2tWF.jpg:large linked from https://twitter.com/Adobe/status/837332712234987521 Personally, I remember several of these icon style changes as particularly disruptive and annoying to my use of Illustrator. But it also cuts both ways -- with 16 toolbar/icon sets over 30 years, clearly you can have a successful product with changes every few years or so. (Although, most of the changes didn't actually change individual icons; rather, many add icons or reorganize the pallette.) Hopefully that's useful to think about. --jh...@mit.edu John Hawkinson ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS3 theme?
I'd like to throw up a note of caution: Paolo Cavallini <cavall...@faunalia.it> wrote on Mon, 27 Feb 2017 at 11:28:05 +0100 in <bc885aa6-8fc5-74b8-cd42-81c449c0a...@faunalia.it>: > the first reactions from people testing QGIS 3 include a slight > disappointment from seeing no obvious change in the interface. > Maybe adding a new default theme, with different colours etc., would > help people appreciating the many hidden changes. > I know it's cosmetic, but IMHO it would be a good marketing approach. > Opinions? As a user, subtle changes to an user interface I am famiilar with for no good reason and just for the sake of change are *incredibly frustrating*. An interface I was used to using is gone, and I have to learn something new. If there is a real value-add in the interface, OK. (But even then, it can be frustrating to learn. Acceptable, but still frustrating.) One extreme way to put it is: I would rather the bad interface that I know rather than a marginally better interface that I don't know. It has to be really good to be worth the pain. I guess we're mostly talking about color changes, rather than moving around tools and redesigning critical UI elements, so some of these concerns are less strong. But I think they're still concerns? So I guess I would be more comfortable if the discussion acknowledged these tradeoffs. --jh...@mit.edu John Hawkinson ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )
> Are you aware of systems where there are more values than 8 bits for the > alpha channel (for which we should prepare)? > It wouldn't be a much bigger deal to go this road, but I think it shouldn't > be purely prophylactic without real needs in mind. I'd be speaking out of school. It appears to me that netpbm's pgm supports 16-bit alpha channels http://netpbm.sourceforge.net/doc/pgm.html and it looks to me like Photoshop supports them as well (in 16bpp file), and a cursory reading of the PDF 1.7 Reference suggests no limitation to 8 bits. But I could definitely be misreading this. --jh...@mit.edu John Hawkinson ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Transparency/Opacity (was: Outline/border -> stroke? )
> An outstanding question is what range we should allow? Behind the > scenes it's generally going to be converted to a 0-255 value, but for > users a 0-100% may be more explanatory. Opinions? The tools I use again express opacity in 0-100%, and I think that's the correct thing for the user interface. Why should users presume the internals are going to be 8-bit unsigned? Why shouldn't it be 0-65536? Or floating point? > The API is ALL OVER THE PLACE here, and should also be fixed. We have > a mix of transparency/opacity/alpha and ranges of 0-1, 0-100, 0-255. > It's confusing for developers too! So, I imagine at some point in the future someone is going to decide 8-bit alpha channels are too limiting. The API should probably be forward-looking with respect to that. I'm not sure exactly what that means, but to me it suggests not 0-255. Maybe 0-1 floating point. But I dunno. --jhawk ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Outline/border -> stroke?
I guess I should chime in here on this thread, too :), since I was invoked originally: > Following up on one of the points raised by John Hawkison (author of > the famous "my first weekend with QGIS" email), Definitely to +1 on Stroke. As for transparency vs. opacity, as I wrote in that email: * Why does QGIS use Transparency sliders instead of Opacity sliders? Isn't Opacity much more common in graphics software? To expand a little more, both Photoshop and Illustrator use Opacity sliders -- far left is 0% opacity / full transparency. (Although curiously, Illustrator's is inside the Transparency window.) Are there prominent examples of software packages (in the GIS world?) that use Transparency instead of Opacity in sliders? For the tols I use, Opacity wins hands-down. I gather that's not true for everyone, but I wonder what the tools are that use Transparency sliders (far left is 100% opacity / no transparency). I would say, also, that Opacity is a little more intuitive, because it basically translates to Brightness. If you ask a user which way they turn the knob to make a line darker, they'll usually turn it in the positive director (err, s/knob/slider/). I would say, also, that the internal API is very different from the UI. What's the justification for changing the API on this? Confusion to API developers? Is that really worth it? p.s.: I had anticipated having more time to file QGIS bugs and stuff and that hasn't really happened. Although part of it is that it took an awful long time to get an osgeo account and even longer to get a wiki account...nearly a week for the latter. Anyhow, it's still my intention. --jhawk ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
