[Qgis-developer] Polishing QGIS

Alister Hood alister.hood at synergine.com
Mon Sep 26 04:18:36 EDT 2011


Hi again,
Some more comments.  In case anyone gets bored by the first lot (further
discussion of single/multiple windows), the second lot are regarding
Nathan's tree widget suggestion.

> -----Original Message-----
> From: Nathan Woodrow [mailto:madmanwoo at gmail.com]
> Sent: Monday, 26 September 2011 5:33 p.m.
> To: Alister Hood
> Cc: qgis-developer at lists.osgeo.org
> Subject: Re: [Qgis-developer] Polishing QGIS
> 
> I have to echo Alisters concerns with moving to a single window
system.
> MapInfo (and Arc as far as I know)  currently use a single window
system and
> it's a pain if you do have multiple monitors and want to use them.
> 
> In my ideal QGIS world we could have a single window system (using
tabs to
> separate the windows) but have the ability to tear each tab off into
it's own
> main window for a different monitor.  

Maybe a little off-topic, but with QT, when you tear off two things, is
it _ever_ possible to dock them to each other, like it is with .NET?  It
isn't currently possible with the dockable panes in QGIS... but it would
be very handy.

Back on topic, if you can tear off a composer layout or an attribute
table, it will really need to take any relevant part of the menu with it
(if applicable - currently there is no menu for the attribute table).
Even if it was _possible_ to control it from a menu in the main window
(which might be hidden or on a different virtual desktop), it would be
confusing.  Likewise, the main window will need to show menus relevant
to whatever is displayed in it, not the menus relevant to the torn-off
window (even if that has focus).
And the torn-off window will need its own taskbar and alt-tab entries to
be really useful.  In which case it must be a separate main window after
all, surely?  This would be similar to opening a web site in Firefox in
a new window vs a new tab.

I like to e.g. edit features in an attribute table on one screen and
switch between looking at the main QGIS window, and something else
(Excel, firefox...) on the other screen.  If the attribute table isn't a
separate top-level window, I don't think this is possible* because when
the attribute table is focused, the main QGIS window will automatically
be raised above the other program.
Perhaps someone could enlighten me: _why_ should the application have a
"single main window and set of menus".  Is it simply to conform with HIG
guidelines for something like KDE?  Are those guidelines really
appropriate for a desktop GIS?  The components of a desktop GIS (map,
print composer, attribute table editor...) perform quite distinct tasks,
and the way I personally use them it is sort of like they are separate
applications.  Like you say, Nathan, this is one of the great advantages
of QGIS.  But it is more than simply being able to use several different
components at the same time, some on different screens.  It is good to
be able to manage them along with any other window, putting some on
different virtual desktops and having them at different places in the
stacking order, etc.

* unless using a window manager's "always on top" feature.

> This model could then be adopted for 1+N
> map windows and 1+N composers.   I don't think this would be overly
hard to
> achieve but would just require some thinking with how the UI behaviors
in each
> situation.
> 
> Here is a idea using Visual Studio 2010 as an example
>
http://blogs.msdn.com/blogfiles/zainnab/windowslivewriter/thebestofvisua
lstudio
> 2010freeyourdocumen_761d/image_thumb.png
> 
> The window that is highlighted is normally docked in the main VS
window however
> you can break it out into its own window if you need in order to use
multiple
> monitors (very handy!).
> 
> This is a concept that I can up with the other day for handling the
composer
> list thing and tab interface http://imgur.com/8aA1W The idea is we
just have
> one list with the tabs (or windows) to handle the map canvas/es and
composers.
> In the case of the tree view when clicking on a item header (eg Map
Window or
> Composer 1 etc) the tab would switch focus to that window/tab and set
up the
> controls for the tab/window.  Using this model would allow you to also
drag
> layers from a map window into a composer map frame as technically the
composer
> map frame and map window are not 1:1 always with layers sets. Being
able to see
> what layers are in what frame would also be handy IMO.

That's a fantastic concept.
Here are some thoughts (I guess you are already thinking them):
- Does there really need to be any difference between a "Map Window" and
a "Map Frame"?  They could be exactly the same.  You could click on a
"Map Frame" and choose to view it (which would behave like a "Map
Window" e.g. for zooming and panning), or you could click on the
composer which contains it, and choose to view that (which would behave
like a sheet of paper).
- You could add a map frame to a composer as a "link" (with a little
icon shown), so if you add or remove layers in the source map they would
be updated automatically.  You could choose to "unlink" the frame so
that they do not update.
- You could add a layer to a map frame as a "link", so that if the
symbology is changed in the source map it is updated automatically.  You
could choose to "unlink" the layer so that it does not update.

This would provide a sensible UI for what Mapinfo tries to achieve with
its ridiculous system of composer windows tied to map windows,
essentially:
(1) multiple map windows (which some people request for QGIS);
(2) different layers in different composer layouts / composer map
frames;
But with the improvements:
(3) you don't need to have every map window open all the time (in
Mapinfo if you close a map window you lose all the layouts connected to
it);
(4) zooming/panning in a map window would not ruin your composer; and
(5) layering and symbology in one map could be linked to another map.

I guess the other issue is that you might want to link map contents
(layers) to one map and link map extents to another map.  One way to
implement this would be to have in the tree a "map extents" entry for
each map frame.
And rather than using an icon to indicate linking I guess it would
probably make more sense simply to gray out the linked item.

Regards,
Alister


More information about the Qgis-developer mailing list