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
