On Wed, May 25, 2011 at 3:43 PM, Martin Dobias wrote:
> Hi all
>
> just a quick reaction from my side (sorry for being so brief):
> - it is quite unfair with Guiseppe if you people start proposing how
> things should be done _now_ - IMO there was plenty of time to do such
> decisions before
Yes i
On Wed, May 25, 2011 at 2:11 PM, Giuseppe Sucameli
wrote:
> Again, I would develop in python the GUI only, not the base functions ;)
Yes, but I hoped that a real query builder could be developed within
this project for example. I mean a robust, user friendly tool, which
does not allow user to bui
Hi all
just a quick reaction from my side (sorry for being so brief):
- it is quite unfair with Guiseppe if you people start proposing how
things should be done _now_ - IMO there was plenty of time to do such
decisions before
- I think it is quite irrelevant whether the implementation is in C++
or
On Wed, May 25, 2011 at 1:21 PM, Radim Blazek wrote:
> On Wed, May 25, 2011 at 10:39 AM, Giuseppe Sucameli
> wrote:
>
> > However we should consider to integrate useful python plugins in qgis
> code, porting
> > their base functions to C++ if necessary.
>
> So why to write another important plugi
On Tue, May 24, 2011 at 8:50 PM, Giuseppe Sucameli
wrote:
> Allowing to run queries on database requires a lot of code in the provider
> and also
> out of them, I should export methods to call the query, to get results, a
> class to
> map results, exceptions. Furthermore IMHO it's not good to im
Hi Giuseppe
> I agree, just one GUI to manage everything.
> But QBrowser doesn't refactor GUIs to have a more integrated interface, it
> just
> re-uses the QGis GUIs. So the surplus value is only the QgsBrowserModel.
Reuse existing gui components sounds good to me.
> I'm talking about GUI, not c
HI Marco,
On Wed, May 25, 2011 at 9:49 AM, Marco Hugentobler <
marco.hugentob...@sourcepole.ch> wrote:
> Why not integrate the gui into QBrowser? From a user point of view, it is
> easier to manage the datasources with one application instead having one
> for
> files, one for databases, one for w
Hi Giuseppe
> What I don't like it's to create DBManager as a C++ plugin or just as a
> QBrowser
> extension
Why not integrate the gui into QBrowser? From a user point of view, it is
easier to manage the datasources with one application instead having one for
files, one for databases, one for w
Hi all,
thanks to Jef for remembering the following discussion [1].
On Tue, May 24, 2011 at 8:50 PM, Giuseppe Sucameli wrote:
> I should export methods to call the query, to get results, a class to
>
map results, exceptions.
>
Jef also suggested we could use a memory layer with features without
Hi Radim and devs,
On Tue, May 24, 2011 at 4:44 PM, Radim Blazek wrote:
> QBrowser is just one use of QgsBrowserModel which was developed
> also as model for possible substitution of various "select layer" dialogs.
I can use the QgsBrowserModel, no problem about this.
Create/edit/drop tables an
I am wondering about maintenance and in my opinion if the source is C++ , it
will be easier to maintain if the dbmanager is also c++.
Giuseppe Sucameli wrote:
>Hi Marco,
>
>On Tue, May 24, 2011 at 5:05 PM, Marco Hugentobler <
>marco.hugentob...@sourcepole.ch> wrote:
>
>> Similar to Radim, I'd
Hi Marco,
On Tue, May 24, 2011 at 5:05 PM, Marco Hugentobler <
marco.hugentob...@sourcepole.ch> wrote:
> Similar to Radim, I'd prefer to have an integration with QBrowser and its
> model.
>
as I wrote, it's ok for me to use the QgsBrowserModel and QgsDataItem to
create the tree,
in fact I added
Hi Giuseppe
> I think all the qgis-devs should say their opinion about this question
> raised by Radim.
Similar to Radim, I'd prefer to have an integration with QBrowser and its
model.
Since the browser classes are in the source tree, they are easy to distribute
also as C++ code.
Regards,
Marc
On Tue, May 24, 2011 at 9:07 AM, Giuseppe Sucameli
wrote:
>> We have to add support for other providers to
>> QBrowser anyway. It does not make sense to have another similar UI
>> just for databases, implemented in a different way. Currently QBrowser
>> is a stand alone application but it will be
Hi All,
This is the vision I have for QGIS when it comes to layer handling: One
unified tree that can handle both files (vector and raster) and database
connections (to any database). It should be built into QGIS and live in the
dock just like the layers widget. IMO the QBrowser would end up li
Hi Radim,
On Tue, May 24, 2011 at 7:46 AM, Radim Blazek wrote:
> First of all, IMO, the DBManager has to be implemented in QGIS core,
> not as a plugin for two main reasons:
1) it is core functionality
>
I not agree, it's a GUI functionality. We can implement all the core stuff
in the
qgis core
Hi.
First of all, IMO, the DBManager has to be implemented in QGIS core,
not as a plugin for two main reasons:
1) it is core functionality
2) connection factories MUST go to providers, otherwise you start to
create a set of plugins for each DB, parallel to providers.
>From UI point of view, I wou
Hi all,
I'm starting to work on DBManager plugin for QuantumGIS.
I've just created the repository on GitHub [1] and here's [2] a page on the
QGis wiki
containing ideas I wrote in the past few days. I will add weekly reports to
that wiki page.
Any comments and reviews are very welcome.
Regards.
[
18 matches
Mail list logo
