Re: [Qgis-developer] CMake cleanup and OS X frameworks

[Noli Sicad]

> 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.

John, probably you can make a mock up on the menu structure for QGIS
Mac OS X and post the URL link so everybody can see. Then, we can
customise QGIS for Mac OS X to our linking.

Tim has good info how to use the qtcreator with qgis which make UI
easier to manupulate.

http://linfiniti.com/2011/06/using-qtcreator-with-qgis/

I for one would like to resurrect my nkids icon set for QGIS and I
think QGIS for Mac OS X needs bit of crystal icons i.e. glossy icon
sets.

Noli
___
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

[William Kyngesburye]

D'oh! Sorry about that.  shoulda cherry-picked.  Try it now.

On Jul 5, 2011, at 6:52 PM, John C. Tull wrote:

> 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 
http://www.kyngchaos.com/

The equator is so long, it could encircle the earth completely once.

___
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

[John C. Tull]

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 #include.  Needs some discussion about 
>> reorganizing the headers in QGIS, if there is interest.)
>> 
>> -
>> William Kyngesburye
>> 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] CMake cleanup and OS X frameworks

[Tom Elwertowski]

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 #include.  Needs 
some discussion about reorganizing the headers in QGIS, if there is interest.)

-
William Kyngesburye
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] Qt Error (1.6)

[uk52rob]

Dear All,

 

I have uninstalled a few old programs from my PC (can't remember what they
were, as I never really used them), and now I get the error as shown at the
following URL:

 

http://www.danceselection.co.uk/upload/Untitled.png

 

I've had these Qt*.dll issues before, and normally when I copy the dll's
from the QGIS\Bin directory to Windows\System32, it sorts the problem.
However, it has not worked in this case.

 

Obviously I have attempted to uninstall and reinstall QGIS, but this never
sorts the Qt issues.

 

Any advise would be grateful.

 

Cheers,

 

Rob

 

 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Re: [SoC] QGIS mobile weekly report #5

[a . furieri]

On Tue, 05 Jul 2011 13:22:46 +0200, Andreas Neumann wrote
>  I think as a data source it would be very nice to have SpatiaLite 
>  support in Android 
>

Just FYI:
for sure SpatiaLite has already been successfully ported 
to Android (and to iOS/iPhone/iPad as well).

At least, this is what I guess reading the spatialite's
own ML: several developers claim their successes on
this field, and all them seems to be fully satisfied.

bye Sandro

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Re: [SoC] QGIS mobile weekly report #5

[Noli Sicad]

+100 for Spatialite.

I am telling the developer of this project -Android Spatialite that
Marco manage to compile GEOS 3.2,2.

Android Spatialite without GEOS
https://github.com/mrenouf/android-spatialite

For offline BaseMap - Mapbox MbTiles (SQLite) is already done for Android.
https://github.com/djcoin/MBTilesDroidSpitter

Noli


On 7/5/11, Andreas Neumann  wrote:
>  Hi,
>
>  I think as a data source it would be very nice to have SpatiaLite
>  support in Android (as others on the list have already pointed out).
>  Having to go through ESRI Shapefiles is very clumsy. Using SpatiaLite
>  one could convert a Postgis based QGIS project to SpatiaLite through the
>  offline editing plugin. One could preserve column names and everything
>  would be in one file.
>
>  For me QGIS Android would be much more compelling and easier to use
>  with SpatiaLite.
>
>  But I understand that qgis-core and a basic GUI would be the first work
>  items during the porting.
>
>  Andreas
>
>  On Tue, 5 Jul 2011 11:55:50 +0200, Martin Dobias wrote:
>> Hi Marco
>>
>> thanks for the update.
>>
>> When trying to compile QGIS on android I think you only need to aim
>> for compilation of qgis_core library and few providers. I would
>> suggest completely disabling compilation of qgis_gui, the application
>> itself, plugins, mapserver, python support and other components. Once
>> qgis_core library compiles you have everything necessary in order to
>> start developing a new QML-based GUI optimized for mobile phones /
>> tablets.
>>
>> Good luck!
>>
>> Martin
>>
>> On Tue, Jul 5, 2011 at 11:39 AM, Marco Bernasocchi
>>  wrote:
>>> Here [0] my last week report. Sorry for the delay, I wasn't home.
>>> I've everything ready for trying cross compiling QGIS to android
>>> this week.
>>>
>>> http://www.bernawebdesign.ch/byteblog/2011/07/05/gsoc-2011-weekly-report-5/
>>> ___
>>> SoC mailing list
>>> s...@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/soc
>>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
>  --
>  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

Re: [Qgis-developer] Re: [SoC] QGIS mobile weekly report #5

[Marco Bernasocchi]

Hi andreas

Marco
www.bernawebdesign.ch
(sent from my mobile)
On 5 Jul 2011 13:23, "Andreas Neumann"  wrote:
>
> Hi,
>
> I think as a data source it would be very nice to have SpatiaLite support
in Android (as others on the list have already pointed out). Having to go
through ESRI Shapefiles is very clumsy. Using SpatiaLite one could convert a
Postgis based QGIS project to SpatiaLite through the offline editing plugin.
One could preserve column names and everything would be in one file.
>
The spatiaLite lib shouldnt be problematic to crosscompile. It has been
partially done already.
I ll quickly try tonight.

> For me QGIS Android would be much more compelling and easier to use with
SpatiaLite.
>
I agree
> But I understand that qgis-core and a basic GUI would be the first work
items during the porting.
>
Definetly! And gps integration.
> Andreas
>
>
> On Tue, 5 Jul 2011 11:55:50 +0200, Martin Dobias wrote:
>>
>> Hi Marco
>>
>> thanks for the update.
>>
>> When trying to compile QGIS on android I think you only need to aim
>> for compilation of qgis_core library and few providers. I would
>> suggest completely disabling compilation of qgis_gui, the application
>> itself, plugins, mapserver, python support and other components. Once
>> qgis_core library compiles you have everything necessary in order to
>> start developing a new QML-based GUI optimized for mobile phones /
>> tablets.
>>
>> Good luck!
>>
>> Martin
>>
>> On Tue, Jul 5, 2011 at 11:39 AM, Marco Bernasocchi
>>  wrote:
>>>
>>> Here [0] my last week report. Sorry for the delay, I wasn't home.
>>> I've everything ready for trying cross compiling QGIS to android this
week.
>>>
>>>
http://www.bernawebdesign.ch/byteblog/2011/07/05/gsoc-2011-weekly-report-5/
>>> ___
>>> SoC mailing list
>>> s...@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/soc
>>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> --
> --
> 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

Re: [Qgis-developer] Re: [SoC] QGIS mobile weekly report #5

[Andreas Neumann]

Hi,

I think as a data source it would be very nice to have SpatiaLite 
support in Android (as others on the list have already pointed out). 
Having to go through ESRI Shapefiles is very clumsy. Using SpatiaLite 
one could convert a Postgis based QGIS project to SpatiaLite through the 
offline editing plugin. One could preserve column names and everything 
would be in one file.


For me QGIS Android would be much more compelling and easier to use 
with SpatiaLite.


But I understand that qgis-core and a basic GUI would be the first work 
items during the porting.


Andreas

On Tue, 5 Jul 2011 11:55:50 +0200, Martin Dobias wrote:

Hi Marco

thanks for the update.

When trying to compile QGIS on android I think you only need to aim
for compilation of qgis_core library and few providers. I would
suggest completely disabling compilation of qgis_gui, the application
itself, plugins, mapserver, python support and other components. Once
qgis_core library compiles you have everything necessary in order to
start developing a new QML-based GUI optimized for mobile phones /
tablets.

Good luck!

Martin

On Tue, Jul 5, 2011 at 11:39 AM, Marco Bernasocchi
 wrote:

Here [0] my last week report. Sorry for the delay, I wasn't home.
I've everything ready for trying cross compiling QGIS to android 
this week.


http://www.bernawebdesign.ch/byteblog/2011/07/05/gsoc-2011-weekly-report-5/
___
SoC mailing list
s...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/soc


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


--
--
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

Re: [Qgis-developer] Re: forum.qgis.org

[Anita Graser]

Is this something that should be decided by the PSC or rather by the
community? I guess only Gary can shut the forum down or turn it read-only.

Regards,
Anita


On Tue, Jul 5, 2011 at 11:55 AM, Paolo Cavallini wrote:

> Il 05/07/2011 11:26, Pirmin Kalberer ha scritto:
>
> > I've played a bit with gis.stackexchange and think it's really a good
> idea to
> > use it.
> > Instead of forum.qgis.org we could use
> > http://gis.stackexchange.com/questions/tagged/qgis
> > as starting point.
> +1 for me.
>
> > IMHO there is no realistic solution with *one* login. Migrating forum and
> wiki
> > would reduce logins by one or two (depending whether the user has an
> OpenID
> > login). According to the docs, Joomla also supports LDAP logins
> > (http://docs.joomla.org/LDAP), so OSGEO logins could used there, too.
>
> Anything simpler is better.
> Thanks.
> --
> Paolo Cavallini: http://www.faunalia.it/pc
> ___
> 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: [SoC] QGIS mobile weekly report #5

[Marco Bernasocchi]

On 07/05/2011 11:55 AM, Martin Dobias wrote:

Hi Marco

Hi Martin

thanks for the update.

:)

When trying to compile QGIS on android I think you only need to aim
for compilation of qgis_core library and few providers. I would
suggest completely disabling compilation of qgis_gui, the application
itself, plugins, mapserver, python support and other components. Once
qgis_core library compiles you have everything necessary in order to
start developing a new QML-based GUI optimized for mobile phones /
tablets.
In the afternoon I'll meet Marco H and Pirmin and I want to discuss that 
as main subject. We already had some discussion and we agreed that first 
I'll try to get a very basic qgis to run and then we'll build on top of 
than. maybe onlz starting with core libs would be an idea as well.

I'll upadate soon.

Good luck!


:)

ciao Marco

Martin

On Tue, Jul 5, 2011 at 11:39 AM, Marco Bernasocchi
  wrote:

Here [0] my last week report. Sorry for the delay, I wasn't home.
I've everything ready for trying cross compiling QGIS to android this week.
http://www.bernawebdesign.ch/byteblog/2011/07/05/gsoc-2011-weekly-report-5/
___
SoC mailing list
s...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/soc



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: Fwd: Re: [SoC] QGIS mobile weekly report #5

[Marco Bernasocchi]

On 07/05/2011 12:15 PM, Marco Bernasocchi wrote:

forwarding Paolo's mail that went to the other list.

 Original Message 
Subject:Re: [SoC] QGIS mobile weekly report #5
Date:   Tue, 05 Jul 2011 12:12:13 +0200
From:   Paolo Cavallini 
Reply-To:   cavall...@faunalia.it
Organization:   Faunalia
To: s...@lists.osgeo.org



Il 05/07/2011 11:55, Martin Dobias ha scritto:
>  suggest completely disabling compilation of qgis_gui, the application
>  itself, plugins, mapserver, python support and other components. Once

Why not having py plugins?
Seems a major limitation to me.

It is a not YET :)

--
Paolo Cavallini:http://www.faunalia.it/pc
___
SoC mailing list
s...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/soc


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Fwd: Re: [SoC] QGIS mobile weekly report #5

[Marco Bernasocchi]

forwarding Paolo's mail that went to the other list.

 Original Message 
Subject:Re: [SoC] QGIS mobile weekly report #5
Date:   Tue, 05 Jul 2011 12:12:13 +0200
From:   Paolo Cavallini 
Reply-To:   cavall...@faunalia.it
Organization:   Faunalia
To: s...@lists.osgeo.org



Il 05/07/2011 11:55, Martin Dobias ha scritto:

 suggest completely disabling compilation of qgis_gui, the application
 itself, plugins, mapserver, python support and other components. Once


Why not having py plugins?
Seems a major limitation to me.
--
Paolo Cavallini: http://www.faunalia.it/pc
___
SoC mailing list
s...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/soc

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Re: [SoC] QGIS mobile weekly report #5

[Nathan Woodrow]

Maybe something like this could be considered when designing the GUI:

 http://en.wikipedia.org/wiki/Pie_menu
 
http://www.istartedsomething.com/20110628/radial-menu-love-for-bing-visual-search-prototype/

-
Nathan

On Tue, Jul 5, 2011 at 7:55 PM, Martin Dobias  wrote:

> Hi Marco
>
> thanks for the update.
>
> When trying to compile QGIS on android I think you only need to aim
> for compilation of qgis_core library and few providers. I would
> suggest completely disabling compilation of qgis_gui, the application
> itself, plugins, mapserver, python support and other components. Once
> qgis_core library compiles you have everything necessary in order to
> start developing a new QML-based GUI optimized for mobile phones /
> tablets.
>
> Good luck!
>
> Martin
>
> On Tue, Jul 5, 2011 at 11:39 AM, Marco Bernasocchi
>  wrote:
> > Here [0] my last week report. Sorry for the delay, I wasn't home.
> > I've everything ready for trying cross compiling QGIS to android this
> week.
> >
> http://www.bernawebdesign.ch/byteblog/2011/07/05/gsoc-2011-weekly-report-5/
> > ___
> > SoC mailing list
> > s...@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/soc
> >
> ___
> 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: [SoC] QGIS mobile weekly report #5

[Martin Dobias]

Hi Marco

thanks for the update.

When trying to compile QGIS on android I think you only need to aim
for compilation of qgis_core library and few providers. I would
suggest completely disabling compilation of qgis_gui, the application
itself, plugins, mapserver, python support and other components. Once
qgis_core library compiles you have everything necessary in order to
start developing a new QML-based GUI optimized for mobile phones /
tablets.

Good luck!

Martin

On Tue, Jul 5, 2011 at 11:39 AM, Marco Bernasocchi
 wrote:
> Here [0] my last week report. Sorry for the delay, I wasn't home.
> I've everything ready for trying cross compiling QGIS to android this week.
> http://www.bernawebdesign.ch/byteblog/2011/07/05/gsoc-2011-weekly-report-5/
> ___
> SoC mailing list
> s...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/soc
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Re: forum.qgis.org

[Paolo Cavallini]

Il 05/07/2011 11:26, Pirmin Kalberer ha scritto:

> I've played a bit with gis.stackexchange and think it's really a good idea to 
> use it.
> Instead of forum.qgis.org we could use 
> http://gis.stackexchange.com/questions/tagged/qgis
> as starting point.
+1 for me.

> IMHO there is no realistic solution with *one* login. Migrating forum and 
> wiki 
> would reduce logins by one or two (depending whether the user has an OpenID 
> login). According to the docs, Joomla also supports LDAP logins 
> (http://docs.joomla.org/LDAP), so OSGEO logins could used there, too.

Anything simpler is better.
Thanks.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS mobile weekly report #5

[Marco Bernasocchi]

Hi Werner,
this week I'll try to get a standard qgis running on Android, then the plan
is to optimize the GUI. we are first targeting tablets and not phones yet.
Thanks for the testing offer, I'll let you know soon.
ciao
Marco

On Tue, Jul 5, 2011 at 11:43 AM, Werner Macho wrote:

> hi marco!
>
> good to hear!
> did you think about refactoring the GUI? I think it would be much better to
> have a decent "mobile" interface on that ..
> Or is it to early to say something about that?
>
> If there is something to test - just tell me .. ;) my android is ready
>
> regards
> Werner
>
> Am 05.07.2011 11:39, schrieb Marco Bernasocchi:
>
>> Here [0] my last week report. Sorry for the delay, I wasn't home.
>> I've everything ready for trying cross compiling QGIS to android this
>> week.
>> http://www.bernawebdesign.ch/**byteblog/2011/07/05/gsoc-2011-**
>> weekly-report-5/
>> __**_
>> 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 mobile weekly report #5

[Werner Macho]

hi marco!

good to hear!
did you think about refactoring the GUI? I think it would be much better 
to have a decent "mobile" interface on that ..

Or is it to early to say something about that?

If there is something to test - just tell me .. ;) my android is ready

regards
Werner

Am 05.07.2011 11:39, schrieb Marco Bernasocchi:

Here [0] my last week report. Sorry for the delay, I wasn't home.
I've everything ready for trying cross compiling QGIS to android this week.
http://www.bernawebdesign.ch/byteblog/2011/07/05/gsoc-2011-weekly-report-5/
___
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] QGIS mobile weekly report #5

[Marco Bernasocchi]

Here [0] my last week report. Sorry for the delay, I wasn't home.
I've everything ready for trying cross compiling QGIS to android this week.
http://www.bernawebdesign.ch/byteblog/2011/07/05/gsoc-2011-weekly-report-5/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Re: forum.qgis.org

[Pirmin Kalberer]

Am Dienstag, 28. Juni 2011, um 09.38:22 schrieb Paolo Cavallini:
> Il giorno mar, 28/06/2011 alle 00.20 -0700, Pirmin Kalberer ha scritto:
> > gis.stackechange at least adds some quality to an old-school forum. I
> > like especially that you don't have to create another account and can
> > login with OpenID instead.

I've played a bit with gis.stackexchange and think it's really a good idea to 
use it.
Instead of forum.qgis.org we could use 
http://gis.stackexchange.com/questions/tagged/qgis
as starting point.

> 
> Good point. I do not like (nobody likes it, I guess) having I do not
> know how many IDs to access the various parts of QGIS infrastructure
> (wiki, redmine, git, joomla, ...).
> Anybody interested in helping to develop a simpler solution?

IMHO there is no realistic solution with *one* login. Migrating forum and wiki 
would reduce logins by one or two (depending whether the user has an OpenID 
login). According to the docs, Joomla also supports LDAP logins 
(http://docs.joomla.org/LDAP), so OSGEO logins could used there, too.

Regards
Pirmin

-- 
Pirmin Kalberer
Sourcepole  -  Linux & Open Source Solutions
http://www.sourcepole.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Ellipse renderer

[Marco Hugentobler]

Hi Martin

Welcome back :-)

Thank you for reviewing the ellipse renderer changes.

> However would not it be better to add data defined fields to the
> simple marker symbol layer instead of creating a new one? The ellipse
> symbol layer seem to duplicate a lot of code, the only difference I
> see is that ellipse marker supports unequal width and height).

Yes, it is width<->height, outlinewith option and data defined fields which are 
new (whereas it lacks x-/y-shift). The idea of the ellipse renderer was to 
have minimal impact on existing classes. But yes, bringing the additions into 
the simple marker class is also my preferred solution.

> I am merely a fan of "Advanced" buttons that show
> this functionality (maybe in a separate dialog or by adding further
> widgets). I guess this way the regular users do not get overwhelmed
> with complexity and power users are happy.

I don't have a strong opinion here. A dialog with an "Advanced" extension 
sounds good to me. Do we already have examples of such dialogs in QGIS? Tim, 
what do the HIG say?

> One more technical issue: in the ellipse symbol layer you store
> indexes together with the field names. This is suboptimal and the
> field indexes should be resolved in startRender() method.

I agree, storing only the name would be more robust towards attribute changes 
(e.g. storing projects, inserting fields into the db with external programs, 
then reopen again). 
Is there a way to resolve the indexes from within the symbol layer? Maybe it's 
something obvious that I just don't see. The symbollayer needs to know 
attribute name and index (name to say which attributes it needs, index in 
renderPoint). However, it does not know the vectorlayer to get the relation 
between name and index.

Regards,
Marco


Am Montag, 4. Juli 2011, 15.53:18 schrieb Martin Dobias:
> Hi Marco
> 
> finally I'm back :-)
> 
> On Tue, Jun 14, 2011 at 3:48 PM, Marco Hugentobler
> 
>  wrote:
> > - A pointer to the rendered QgsFeature* has been added to
> > QgsSymbolV2RenderContext (such that the symbollayer has the possibility
> > to check the data defined attribute values)
> > 
> > - A symbollayer has the possibility to specify which attribute fields it
> > needs for rendering (by default, QgsSymbolLayerV2::usedAttributes
> > returns an empty set).
> > 
> > - The symbollayer widgets receive a pointer to their vector layer. Normal
> > symbol layer widgets don't use it, the widgets of  data defined symbol
> > layers get the available fields through that pointer.
> 
> I have looked at the code and these changes look OK to me.
> 
> However would not it be better to add data defined fields to the
> simple marker symbol layer instead of creating a new one? The ellipse
> symbol layer seem to duplicate a lot of code, the only difference I
> see is that ellipse marker supports unequal width and height).
> Additionally it will probably make sense to add such data defined
> rendering also e.g. for simple line and simple fill.
> 
> Regarding the widget for symbol layer properties - I do not really
> like the tabbed approach (the second tab with lots of combo boxes
> looks scary :-), though I am not sure what would be the most user
> friendly approach. I am merely a fan of "Advanced" buttons that show
> this functionality (maybe in a separate dialog or by adding further
> widgets). I guess this way the regular users do not get overwhelmed
> with complexity and power users are happy.
> 
> One more technical issue: in the ellipse symbol layer you store
> indexes together with the field names. This is suboptimal and the
> field indexes should be resolved in startRender() method.
> 
> This is going to be another nice addition to the new symbology!
> 
> Regards
> Martin


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Churerstrasse 22, CH-8808 Pfäffikon SZ, 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