Big Ede!!
;-)
2013/3/7 <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: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
