should be fixed in 3304.. please check. ede On 07.03.2013 19:43, edgar.sol...@web.de wrote: > actually i am quite short.. about 1,65 meters ;P ..ede > > On 07.03.2013 19:05, Giuseppe Aruta wrote: >> Big Ede!! >> ;-) >> >> 2013/3/7 <edgar.sol...@web.de <mailto:edgar.sol...@web.de>> >> >> 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 <tel:07.03.2013%2016>: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> >> <mailto:edgar.sol...@web.de <mailto:edgar.sol...@web.de>>> >> > >> > On 06.03.2013 23 <tel:06.03.2013%2023> <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 >> <mailto: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 >> > > ------------------------------------------------------------------------------ > 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
