[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: "Jan Hambrecht" <jaham () gmx ! net>
Date: 2009-04-19 21:17:36
Message-ID: 20090419211736.30890.11359 () 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.
>
> Cyrille Berger wrote:
> 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.
I agree about the different needs of different applications. I think it would work \
having locked shapes not to be selectable in karbon. The only issue i see with that \
is consistency between applications. Do you think it would be confusing for the user \
that these states are handled differently in different applications? Other than that \
i think that locked does not only prevent from moving the shape around, but also \
changing the size of probably or the transformation. So positionLocked would be \
misleading. But i agree that isLocked() does not say much about the meaning, \
especially with regard to the contentProtected function.
- Jan
-----------------------------------------------------------
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic