On 06.03.2013 23:06, Rahkonen Jukka wrote: > Hi, > > Michaël wrote: > >> Hi, > >> I try to follow interesting Jukka's input, but I don't use editing tools >> as much... >>> I list some quick notes about digitizing with OpenJUMP and some other >>> programs. >> >>> 1) - Before Ede implemented the new keyboard shortcuts the only way to >>> cancel digitizing was to reselect the same digitizing tool or some other >>> tool from the toolbox or Select features or Fence tool from the main menu. >>> - With the new keyboard shortcuts we have now, selecting another tool >>> does not cancel drawing but the only way to cancel digitizing is to press >>> Esc when the same tool that was used to start drawing is active. >>> - Behaviour is clearly different. I do not say if it better or worse. >> so far the others tend to autocancelling as before.. i have no opinion, so i >> will do so if nobody objects in time. > >> I think using escape to cancel editing is good. > Me too. But if it is the only way to cancel editing and you have touch screen > computer or just a cup of coffee or a phone in the other hand you would like > to be able to do that with just mouse.
ok, i get the touchscreen. the other user should simply put the coffee cup away ;) how about a stop button, similar to what browsers have? on the other hand. it was never requested before. so why hurry now? >In addition, right now changing tools on-the-fly, like from draw polygon into >draw line, leaves phantom lines on the screen and for new users it may be hard >to understand why it happens. for edit toolbar: they'll disappear as soon as switching cursortools cancels drawing again for quasimode (shortcuts): it's either that or cancelling. keeping it there as a visual representation of the geometry in the works sound reasonable to me as the opposite to make it invisible while in a different quasimode. >> I don' understand if the change between previous and current versions >> when you reselect the digitizing tool to cancel editing (which is no >> more possible) was motivated by the new framework (which makes it >> difficult/impossible/hackish to cancel like that) or by your personnal >> feeling that it is better like that. I have no strong opinion about it >> except that it makes cancellation keyboard dependant. >> Would double-click on the editing tool be an alternative ? i'd suggest to change the icon in the edit toolbox to the same with a "red x" to visualize users can stop digitizing by clicking on it again. kind of like a more elegant stop button. don't feel the urgency to implement though. > > We may think why user selects another tool. Probably he thinks that the > current tool was wrong and he wants to use another. If that is the situation > then why to force user to do Cancel - Select another tool if plain Select > another tool and automatic cancelling would do the same with less clicks? It > is another story if we want to offer a possibility to leave features open for > future edits. > >> there is still the option of cancel/keep to allow users to use other tools >> as you mention below. >> >>> 2) - It is essential to be able to pan and zoom and continue to draw a long >>> linestring or big polygon after that. In OpenJUMP this is possible by using >>> the keyboard shortcuts. Actually, it is the only way. User cannot use for >>> example Pan or Zoom tools from the main menu because selecting another tool >>> cancels drawing. > >> Do not understand. Isn't it just the other way ? Selecting zoom/pan tool >> from the main tool menu does not interrupt drawing, >> you just have to select the editing tool again to go on. Or did I miss >> something ? > > Yes, you missed that I was using the release version of OJ with the > traditional behaviour while writing that. It is not a wonder because I did > not tell that. I am sorry. i vote for assuming our users have a keyboard for now. if the age of desktop gis really moves on to the tablet gis we will talk about that soon enough. >>> - Digitizing with Pan/Zoom keyboard shortcuts is nice and efficient but >>> user needs to know how to use the shortcuts. It is probably not evident for >>> new users. >>> - Panning and zooming during drawing is not possible without keyboard. >>> - QGis does not have at all as nice shortcuts for digitizing. It does have >>> configurable shortcuts but they are not as nice to use (my opinion). >>> - QGis does not cancel drawing if another tool is selected. Actually the >>> default way to digitize seems to be to draw as long it is possible, select >>> Pan tool, pan, select drawing tool, continue drawing, select Pan tool etc. >>> I wouldn' t like to work that way but it is easy for the beginners and user >>> do not need to touch the keyboard while drawing. i like the approach, but that probably need more love, if we want to have that in OJ. >>> - uDig cancels drawing when another tool is selected. >>> - QGis and uDig are not totally comparable with OpenJUMP because they allow >>> only one geometry type per layer and only one layer at a time can be >>> editable. >>> >>> 3) - I do not see a reason for keeping not ready digitized feature open if >>> it is not compulsory like it is with the QGis way to do use panning. >>> Except one use case which I will tell later. For me it is OK to cancel >>> drawing without asking if user selects another tool. > >> You mean there is no reason for keeping not ready digitized feature "except >> during zooming / panning operation". >> I agree this is not esssential. I do not see disadvantage though (maybe it >> is unusual and the user can feel the UI is buggy if it does not understand >> how it works).d > > I would say that it is not essential in every day digitizing. It might be > useful for some special cases, like when digitising with GPS, but has any > user so far asked to implement such feature? Well, probably yes because they > have not found the keyboard shortcuts and they would have liked to pan. As > usual, things are not just black or white. > speaking of black and white http://en.wikipedia.org/wiki/Black_Cat,_White_Cat great movie > >>> 4) - However, if OpenJUMP should be used for digitizing with GPS a >>> possibility to keep feature open for digitizing would be very good thing. >>> It may take 5 minutes to walk to the next vertex when you are out in the >>> field and if you see something else that should be recorded on another >>> layer you would like to interrupt, save point or vertex of another feature >>> and continue gathering points to your first feature. However, for efficient >>> work user should be able to keep however many features open and user >>> interface should be made to support selecting which not ready feature to >>> continue. It is not so simple but I know one old PDA software (SOLO Field) >>> where this was implemented well. >> sounds complicated to implement. when users can keep one geometry >> unfinished, they will ask why not another one as well? >> for such use case i suggest to collect point on a layer per feature an merge >> them when finished >> or >> simply add point to a multipoint/linestring via add vertex >> >>> 5) - We should perhaps think a bit more about making it somehow possible to >>> digitize without keyboard because It may be that Windows 8 computers with >>> touchscreen and keyboard will come more common. There was discussion about >>> a related thing last year, read "SuperZoom and other zoom/pan tools" from >>> http://blog.gmane.org/gmane.comp.gis.jump.devel/month=20120201. Perhaps >>> improved SuperZoom tool could be a good solution. Let's hope Matthias hears >>> and buys a laptop with touchscreen and does some testing :) >> another bridge i'd like to cross when we get there.. although javabased we >> do not even run on Android.. ;P >> >>> That's all for today. >>> >> tl;dr >> http://en.wikipedia.org/wiki/Wikipedia:Too_long;_didn%27t_read >> >> just joking.. thanks for all your input!... ede >> tl;dr++ ..ede ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
