[Qgis-developer] Polishing QGIS

Mon Sep 26 04:56:50 EDT 2011

Hi All

On Mon, Sep 26, 2011 at 10:39 AM, Ramon Andiñach <custard at westnet.com.au> wrote:
> I also would be concerned about a purely 1 window approach.
> Taking an example from my routine work, it is extremely useful to be able to
> retain the georeferencer window open as it allows me to visually confirm my
> control points are where I'm expecting them to be.
> -ramon.

Just to clarify, I was *not* suggesting a purely one window approach,
I was suggesting that should only be one *Main Window*.  That is only
one menu should exist in the application. Try this as an experiement:
open the georeferencer, enable dock mode in its settings and then dock
it into the main window. Now you get a dock with menus and the main
window with more windows. This is just plain wierd UI wise. My
suggestion was rather than we adopt an activity based view where the
main window menus update according to the context of what you are
doing. Just try opening openoffice and switching between normal view
and print preview to see what I had in mind - the toolbars adjust
themselves and menu items grey out based on your context. I would
expect that we will adopt a tabbed interface to QGIS (with possiblity
to tear of tabs as floating windows) and that based on the kind of tab
you have open, we would adjust the menus and toolbars and other
contextual information accordingly.

@Nathan and @Alister thanks for your comments - I'll formulate a more
detailed reply to your points tonight!

Regards

Tim

> ______
> The rest of this is some examples from a closed source program[1] that
> reflects some of what I think Nathan is suggesting. I'm not remotely saying
> it should look like or work like this - it's just an example.
> On the left of a set of dialogue boxes that can be nested. As default the
> top half has three nested dialogues that show forms (approx saved styles),
> Properties (what the info tools creates), and Sections (approx map
> bookmarks).
> Below that is a Display dialogue that shows windows that are open. These can
> also be reached and reordered by tabs across the top, just below the menus.
> I can't pull the main windows out onto a different screen, but I can pull
> the dialogue boxes out around the place, so top right shows the properties
> box being pulled around. If I drag onto one of the little arrow-like things,
> it docks against the edge of the window, e.g. Bottom right. Otherwise you
> can let it go somewhere, including a different screen and it stays there.
>
>
> 1. I *think* this is the last piece of propietary software I have to use. If
> anyone can think of an OSS/FOSS equivalent, I'm curious to know.
> On 26/09/2011, at 12:33, Nathan Woodrow <madmanwoo at gmail.com> wrote:
>
> 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
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>

-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==============================================