I think I just had a "Eye-opener" moment. While I have been thinking about
reducing the modal dialogs and decoupling things, I think somewhere along
the line I forgot almost entirely about the usability. After reading the
above feedback, I realize, Symbology suite will have to provide tools that
wo
to include,
>
> - Creating tree structure for managing the SVG symbols
> - Creating a non-modal widget type editor to change symbols on the fly or
> adding that capability to the Layers legend.
>
>
> --
> Regards
> Arunmozhi
> Twitter: @tecoholic
> Website: http://arunmozhi.in
> IRC Nick: teco
>
&
On Sun, Apr 1, 2012 at 6:08 AM, arunthe...@gmail.com
wrote:
> So the idea is to create such a decoupled designer, which is something
> like a "Style Manager ++ (decoupled)". I am writing the possible solution
> and a couple of ideas as a proposal which might contain some over sighted
> goals. Kind
Hi All
Rlease observe the feature freeze on the 1_8 branch which is now in
effect. Next thing on our timeline is:
* string freeze will take effect from 7 April 23h59 GMT2012 after
which point only bug fixes
will be accepted in the 1.8 branch.
* I will put out the RC 8 April 23h59 GMT2012p, and w
On Sun, Apr 1, 2012 at 2:11 AM, Anita Graser wrote:
>
> I don't know how other people approach this but I experiment a lot with
> different renderers and symbols, tiny changes and how the affect. If I have
> to change between layer properties and a separate symbol designer all the
> time, I think
Hi
On Sat, Mar 31, 2012 at 10:08 PM, arunthe...@gmail.com
wrote:
> Hello,
>
> After working with the Symbology as a user for the past couple of days and
> trying to accomplish various things, here is my idea of simplifying things:
>
> Decouple Style management and Style application (renderer) log
On 03/31/2012 01:41 PM, Anita Graser wrote:
> On Sat, Mar 31, 2012 at 10:08 PM, arunthe...@gmail.com > wrote:
>>
>> + Create a new symbol designer, that can be summoned up from Menu rather
>> than from the properties
>>
>
> I don't know how other people approach this but I experiment a lot with
>
Hi,
I think improving the symbology system would be very rewarding and
beneficial for many - but be sure to discuss the technical issues with
Martin and Marco. They probably know the system best.
Work on the SVG symbol repository and better management of the SVG
symbols (categories, metadata (als
On Sat, Mar 31, 2012 at 10:08 PM, arunthe...@gmail.com wrote:
>
> + Create a new symbol designer, that can be summoned up from Menu rather
> than from the properties
>
I don't know how other people approach this but I experiment a lot with
different renderers and symbols, tiny changes and how the
> + The designer to perform following functions
> - Create new symbols/styles
> - Grouping and management of styles through a tree structure
> - Create and manage virtual groups (or themes) that would pull symbols
> from various groups and a combination of renders to create a overall
>
Hello,
After working with the Symbology as a user for the past couple of days and
trying to accomplish various things, here is my idea of simplifying things:
Decouple Style management and Style application (renderer) logic at the GUI
level itself.
First let us start where it all begins, simplifi
Hi
On Sat, Mar 31, 2012 at 4:49 PM, Markus Honegger
wrote:
> Hi all
>
>
>
> I've just created my own toolbar and want to add some of QGIS default
> commands (e.g. the FILE-OPEN command) to it.
>
> At the moment it looks like this: toolbar.addAction(FILEOPEN) - What is
> the correct QAction stri
Hi all
I've just created my own toolbar and want to add some of QGIS default
commands (e.g. the FILE-OPEN command) to it.
At the moment it looks like this: toolbar.addAction(FILEOPEN) - What is
the correct QAction string?
Can anybody help me with the code? Looking for something like a list
I am happy to do this if we can get a handle on which specific commits
break api (or just add thin wrappers around api breakages if possible)
- though I dont know how simple it will be to do that
Regards
Tim
Sounds like work for a special task force at the hackfest .. :)
It seems I should w
Hi
On Sat, Mar 31, 2012 at 12:19 PM, Nathan Woodrow wrote:
> My major concern with the 1.8 release is getting all the non api breaking
> features from master into the 1.8 branch and keeping track of which ones are
> in there. master is so fast moving that it's hard to keep track, especially
> wh
My major concern with the 1.8 release is getting all the non api breaking
features from master into the 1.8 branch and keeping track of which ones
are in there. master is so fast moving that it's hard to keep
track, especially when the order of commits (and some of the ids) are
different to the ma
16 matches
Mail list logo
