[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Review Request: Lock shape shouldn't be selectable
From:       "Cyrille Berger" <cberger () cberger ! net>
Date:       2009-04-19 9:08:02
Message-ID: 20090419090802.17190.64891 () localhost
[Download RAW message or body]



> On 2009-04-18 08:07:21, Jan Hambrecht wrote:
> > Well to be honest I think we have too many shape states which influence editing \
> >                 of shapes. These are
> > - visible
> > - locked
> > - selectable
> > - contentProtected
> > 
> > And then there is a function isEditable which does check only the visible and \
> > locked state. If we want to keep all these states (contentProtected is only used \
> > in kword atm) then imho isEditable should be the central function used in tools. \
> > This function then should also check the contentProtected flag and probably also \
> > the selectable flag. Then all tools should be fixed to honor these states by \
> > calling isEditable for shapes they are going to change.

I have been thinking about this. And I think different applications have different \
need. In kword/kpresenter it kind of make sense to lock the position of a text box \
and still be able to edit the text, hence the need of locked and contentProtected \
(that said, does it really make sense to protect the content of text ?), and one \
usually manipulate less shapes in kword/kpresenter (doesn't mean that you can't have \
a vector illustration with a lot of shapes, but the main use case will be moving it \
around) than karbon, where you end up with a lot of shapes and once you are done with \
some part of the drawing, you are interested in locking it so that it doesn't move, \
and don't get selected so that you can easily select the part you are working on, and \
you don't really want to clutter the UI by giving the possibility to lock the postion \
or the content or selectability (well at least, it's based on my analysis on the use \
of those applications ;) ).

If we agree on this, then we indeed needs the four states... But I would suggest to \
rename locked to positionLocked (positionProtected ?). About isEditable(), if we have \
two levels of "editability", positionLocked and contentProtected, it's kind of \
difficult to return an interesting value.


- Cyrille


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/606/#review962
-----------------------------------------------------------


On 2009-04-18 05:58:08, Cyrille Berger wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/606/
> -----------------------------------------------------------
> 
> (Updated 2009-04-18 05:58:08)
> 
> 
> Review request for KOffice.
> 
> 
> Summary
> -------
> 
> One thing that annoys me in karbon is that locked shapes are still selectable. If \
> it's locked, there is no point in selecting it (except to cooy it ? (but one might \
> note that most docker don't care if a shape is editable or not, but then that would \
> be a bug) ). I am not sure what's the correct solution (probably not my patch, but \
> for now it solves my annoyance :) and to start the debate ), would the correct fix \
> be: 1) to make lock/unlock in karbon's layer box call setSelectable ?
> 2) add an icon to that layerbox to prevent selection ?
> 
> The second option gives more power... and more clutter...
> 
> 
> Diffs
> -----
> 
> trunk/koffice/libs/flake/KoShape.cpp 955671 
> 
> Diff: http://reviewboard.kde.org/r/606/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Cyrille
> 
> 

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]