Hi, Agree with Ede : - no v2.0, no branch - heavy tests before 1.6 release (thanks to Jukka and Peppe for all their tests) - ghost shapes : agree that it is not necessary and may confuse users. If it is possible to cancel unfinished shapes when the user select again a "editing" tool (without damage to other improvements), it is probably the best option for 1.6 release.
Michaël > hmm.. actually i modified a lot of code, and something might be broken.. but > i tried to keep interfaces as they were, so i don't see no reason to change > the major version. i guess the first major version change should be an > additional plugin interface with appropriate plugin manager.. if it'll happen > at all. > > also, let's not talk about branches again. too much work, also "release > early, release often" as we do it with the snapshots. > > the shortcut changes really need a broader audience to test them, so let's > finish it up neatly and release it with 1.6 . we'll probably do one to two > bugfix releases pretty fast then for bugs that slipped through the cracks, > but that is to be expected anyway. > > regarding the "ghost shapes": that's really no big issue, i'll just restore > the old behavior, and we're done. all the talk about it is a mere spitballing > about "what could the future bring". > > .. so far, so nice.. ede > > > On 07.03.2013 16:42, Giuseppe Aruta wrote: >>> 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. >> There are also Advanced measure tools which are affected by this "phantom" >> problem, and maybe other ones too. I don't feel that an x would be a "final" >> solution but probably it opens other "methodological" problems. >> I say methological because I feel that Ede, Jukka and Michaels reflect >> different point of view the way they use OJ. >> I also don't like these phantoms and I know that this belongs to the way I >> use OpenJUMP (heavily work of digitalizing and less analysis) and the also >> the matter I use OJ with beginners (students at my small lessons at >> University): I am just thinking about many screens full of phantoms, ghosts >> and shadows crossing each other. I also feel that it is difficult to change >> a habit without making lots of mistakes (and lots of phantoms on the screen) >> On the other hand i don't want to loose the great job made by Ede and I >> consider also the time he spends around shortcuts >> I think that there could be two solutions: >> 1) we leave Ede's work as it is, but we have to accept for the next future >> that users will mail our list (included bug list) about phantoms, asking o >> solve it. This means that the "problem" will come and come again >> 2) we should consider to open a branch of developing on SourceForge where it >> is possible to go on working on shortcuts and related new problems, in this >> case we must give our availability to go on testing. While new OJ 1.6 should >> start from OpenJUMP-20130224-r3272, the last before Ede's modification. By >> the time that we feel sure that everything is working fine with shortcuts, >> there we can have a new OJ realize version, 2.X, in this case, reflecting >> what is written in our "Version polycy" >> (http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_Roadmap#Version_policy) >> >> * First number change is for a new major version. It can break >> compatibility in OpenJUMP core (refactoring) and add important new features. >> >> Ede's shortcuts and all possible modification on how to draw will "break >> compatibility", in my point of view. >> >> >> my 2 cents >> >> Peppe >> >> 2013/3/7 <edgar.sol...@web.de <mailto:edgar.sol...@web.de>> >> >> On 06.03.2013 23 <tel:06.03.2013%2023>: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 > > ------------------------------------------------------------------------------ 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
