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