[Qgis-developer] Polishing QGIS

Mon Sep 26 00:33:22 EDT 2011

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

Just my thoughts for this at the current time.

- Nathan

On Mon, Sep 26, 2011 at 1:26 PM, Alister Hood <alister.hood at synergine.com>wrote:

> Hi Tim,
> As a user who opens a lot of tickets which could be described as about
> "polishing", this is great to hear.
> I do have a comment below - I hope it isn't too long.
>
> > Date: Sat, 24 Sep 2011 13:39:57 +0200
> > From: Tim Sutton <lists at linfiniti.com>
> > Subject: Re: [Qgis-developer] Polishing QGIS
> > To: Paolo Cavallini <cavallini at faunalia.it>
> > Cc: qgis-developer <qgis-developer at lists.osgeo.org>
> > Message-ID:
> >
> <CALCNqkYpv87-OmG27ngK2fM_QwBp4oNhciP_g0FEJyzRgWJ88Q at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi Paolo
> >
> > On Sat, Sep 24, 2011 at 10:41 AM, Paolo Cavallini
> <cavallini at faunalia.it>
> > wrote:
> > > Hi all.
> > > Just finished (yet another) course, this time in Spain. Went well,
> > > people looked very positive about it. Crashes are less and less
> frequent
> > > over the course of the years, even using the dev packages.
> > > Now that many core issues are solved, cosmetic issues are more
> apparent:
> > > we suffer from duplications and inconsistencies. I have opened
> several
> > > tickets. I know it is a boring and unexciting job, but sooner or
> later
> > > we have to do it.
> > > Anyone has plans to work on this?
> >
> > In my mind this will be very much the mission of 2.0 - as well as
> > making all the internals clutter free and consistent, we must work to
> > make the ui the same. I hope to spend the upcoming hackfest working to
> > build more re-usable widgets (as we have discussed and planned in
> > Lisbon). Building a good widget library I believe will be a key step
> > towards achieving this consistency and will have the benefit on
> > centralising fixes that then propogate themselves to all parts of the
> > UI that use that widget, The projection selector widget is a really
> > good example of the mileage we can get from this approach - it is used
> > in various parts of the ui and in many plugins.
> >
> > There are some key things I think need to be done:
> >
> > - adopt an activity based interface: e.g. the print composer,
> > georeferencing tool and other parts of the app that also implement a
> > main window ui are all kinds of wrong. There should only be one main
> > window and set of menus in any application, so we need to implement
> > the appropriate changes such that the menus etc update according to
> > the context of the work (activity) you are doing. In the courses I
> > give, people generally lose the composer window and it is not uncommon
> > to see them with ten instances of composers as they lose it and create
> > new ones in succession.
>
> I'm sure you will do anyway, but I might as well say it: Please think
> carefully about this sort of major change, as the current system works
> very well as soon as you understand about working with multiple windows.
>
> It can be very useful to have a number of windows open at the same time,
> especially attribute tables and composer windows.
> 1) it is good to be able to look at several windows side by side
> 2) it provides a way to quickly switch between a few that you are
> actually working with, so you don't need to keep searching for them in a
> very large list.
>
> What will an "activity based interface" look like, and will it provide
> for these situations?  Will it work with multiple screens (and virtual
> desktops), e.g. so you can have an attribute table on one screen and the
> main window on another?
>
> Will it really be better?  It seems you could end up removing powerful
> functionality, essentially using a sledgehammer to break an egg, and not
> really improving much.
>
> Maybe you could achieve the same benefits by minor improvements to the
> existing gui, e.g.
>
> - add one or more widgets which allow the user to switch which layout or
> attribute table is shown in the current window (Menu?  List?  Spinbox).
>
> - change how features are accessed, to make them more (or less?) easy to
> find and use.  Currently the "New print composer" menu item stands out
> more than the items in the "Print composers" submenu.  It might be good
> to rename the "Print composers" submenu to "Open print composer" or
> "Show print composer", and give it an icon.  An alternative might be to
> move "New print composer" and "Composer manager" to the top of the
> "Print composers" submenu, with a separator between them and the list of
> composers.  Similarly, on the toolbar there is a button for "New print
> composer", but to access an existing composer from the toolbar you need
> to click the "composer manager" button, select a composer, click show,
> and then close the manager.  It shouldn't be this much harder to open an
> existing print composer, which is a much more common task than creating
> a new one.  But this could be fixed by a small change to how you open
> the print composer, without redesigning the way the whole thing actually
> works.
>
> > - Implementing the symbology ui better. We need some kind of tree
> > interface (we discussed this at the hackfest in Lisbon in some
> > detail). New symbology is very confusing when you have symbols
> > composed of symbols that are themselves composed of symbols. Managing
> > that causes many levels of windows to be spawned and novice users
> > (advanced users too I guess) can quickly lose track of where they are.
> >
> > - We need to look at how simple interactions work and streamline them.
> > For example, label rotation is a nice new feature but its almost
> > impossible to get the alignment you want interactively.
> >
> > - We need to identify parts of the user interface that are 'advanced'
> > and hide them away from casual users.
> >
> > - We need to apply sensible defaults and work towards the element of
> > least surprise.
> >
> > - We should start thinking about implementing a telemetry layer in
> > QGIS - with ~200 000 possible users out there, if even just 10% of
> > users allow us to collect telemetry data it will be a goldmine of
> > information (it will make a nice GSOC project). Know where users
> > click, how often, which dialogs they spend most time in, etc etc can
> > prove invaluable in targeting places that need improvement most.
> >
> > I could keep on going all day about all the other things we need to
> > do. This hackfest I was thinking it would be nice to try to do the
> > planning and meeting stuff before the time as much as possible (via
> > wiki / mailing list) so we can come prepared in small teams ready to
> > reaaly focus on working. I enjoyed Lisbon very much but I felt we
> > spent too much time meeting and discussing stuff and not enough hands
> > on time so it would be great to address that. Anybody coming who is
> > interested in forming part of a GUI overhaul team lets get the ball
> > rolling and put our plans in place here
> >
> > http://www.qgis.org/wiki/Version2GuiRevision  (just a place holder
> > page for now  - we can flesh it out in the run up to Zurich).
> >
> >
> > Regards
> >
> > Tim
>
> Thanks,
> Alister
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20110926/754601dd/attachment.html