[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Review Request: Add new properties for KoShape size and position
From: "Carlos Licea" <carlos_licea () hotmail ! com>
Date: 2010-09-07 23:08:07
Message-ID: 20100907230807.10207.7410 () vidsolbach ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On 2010-08-03 20:10:50, Thomas Zander wrote:
> > Geometry protected (the current property) does indeed represent both size and \
> > position; we have not in the past needed them split up and as such they are the \
> > same property. I don't think we should have all 3 properties as that will be \
> > confusing; it can cause weird combinations. So, choose one :)
> > I'm curious what the reason is for the splitting; in the commits I saw made last \
> > week there was a usage because the shape should never resize. The problem with \
> > the commit I saw last week (since reverted) is that the setters on KoShape will \
> > be presented as checkable options for the user. So a geometry protected or size \
> > protected boolean on KoShape will be changable by the user in an appropriate GUI. \
> > if this is unwanted I suggest that the shape that should not be resized \
> > reimplements the virtual KoShape::setSize() and makes it do nothing. This has the \
> > same effect but is not user changable.
>
> Carlos Licea wrote:
> > Geometry protected (the current property) does indeed represent both size and \
> > position; we have not in the past needed them split up and as such they are the \
> > same property. I don't think we should have all 3 properties as that will be \
> > confusing; it can cause weird combinations. So, choose one :)
> Fine, I'd chose granularity. So I'd split them up.
>
> > I'm curious what the reason is for the splitting; in the commits I saw made last \
> > week there was a usage because the shape should never resize. The problem with \
> > the commit I saw last week (since reverted) is that the setters on KoShape will \
> > be presented as checkable options for the user. So a geometry protected or size \
> > protected boolean on KoShape will be changable by the user in an appropriate GUI. \
> > if this is unwanted I suggest that the shape that should not be resized \
> > re-implements the virtual KoShape::setSize() and makes it do nothing. This has \
> > the same effect but is not user changable.
> That's correct, I'm introducing the difference because I need the shape not to be \
> re-sizable at all. Originally I tried your approach (reimplementing setSize so that \
> it would ignore the change) but it has a flaw: the user can still flip the shape \
> which is no desirable at all, so I need a way for resizeStrategy to let it know not \
> to change the shape no matter what. Regarding showing the property to the user, I \
> think we should not present all the properties automatically to the user, we should \
> be able to set it as a "private" property not meant for the User to tinker with.
> Thomas Zander wrote:
> you write; "the user can still flip the shape which is no desirable at all".
> Can you explain why? The reason you gave before was that the content would not show \
> well, but this is not an issue if the scaling is done using a matrix instead of as \
> using a size. I'd argue that if the user wants to show some content mirrored, then \
> let her. If it makes no sense, then she'll press undo and problem solved. Its not \
> like resizing to mirroring is a really easy thing to trigger and protecting the \
> user from herself should only go so far.
> you write; "I need a way for resizeStrategy to let it know not to change the shape \
> no matter what." As explained before, the approach you chose is not helping. You \
> are providing public API to control this and any plugin writer as well as any \
> KOffice application can toggle that bit to make it resizable again. So this sounds \
> like a bad way of getting to your goal.
Because the shape represents a concept for which rotation has no value. Would you let \
the user rotate the buttons? no, there's no value on that, equally, why should we \
allow the user to flip a button which displays the text they are after. I just don't \
want to allow that interaction.
"As explained before, the approach you chose is not helping. You are providing public \
API to control this and any plugin writer as well as any KOffice application can \
toggle that bit to make it resizable again. So this sounds like a bad way of getting \
to your goal." Yes, that's true, but if a plug-in misbehaves and changes the shape's \
settings without taking into account the expected behavior, well, it's the writer's \
fault.
No matter what we end up doing in this particular case, you have to make your mind in \
something: do you want developers to be able to control their shapes as they see fit \
or not? I thought that the whole point of Flake was to allow anybody to come up with \
any behavior or design they need. Right now I can't create the interaction I want \
because the properties are mixed together. I see no gain in keeping both properties \
mixed, are there any I'm missing?
- Carlos
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/4883/#review6779
-----------------------------------------------------------
On 2010-08-03 19:44:55, Carlos Licea wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/4883/
> -----------------------------------------------------------
>
> (Updated 2010-08-03 19:44:55)
>
>
> Review request for KOffice and Thorsten Zachmann.
>
>
> Summary
> -------
>
> Add two new properties for KoShape: setSizeProtected() and setPositionProtected(). \
> They do what they imply. The reason I didn't replace setGeometryProtected is \
> because I 1)Wanted to still support that property; and 2)Think that it might be \
> different, originally I was of the idea that Geometryprotected = sizeProtected && \
> positionProtected, but now I'm not so sure, I think it depends on how strict you \
> want it to be.
>
> Diffs
> -----
>
> trunk/koffice/libs/flake/KoShape.h 1158763
> trunk/koffice/libs/flake/KoShape.cpp 1158763
> trunk/koffice/libs/flake/KoShape_p.h 1158763
>
> Diff: http://svn.reviewboard.kde.org/r/4883/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Carlos
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://svn.reviewboard.kde.org/r/4883/">http://svn.reviewboard.kde.org/r/4883/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On August 3rd, 2010, 8:10 p.m., <b>Thomas \
Zander</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Geometry protected (the current property) does indeed represent both \
size and position; we have not in the past needed them split up and as such they are \
the same property. I don't think we should have all 3 properties as that will be \
confusing; it can cause weird combinations. So, choose one :)
I'm curious what the reason is for the splitting; in the commits I saw made last \
week there was a usage because the shape should never resize. The problem with the \
commit I saw last week (since reverted) is that the setters on KoShape will be \
presented as checkable options for the user. So a geometry protected or size \
protected boolean on KoShape will be changable by the user in an appropriate GUI. if \
this is unwanted I suggest that the shape that should not be resized reimplements the \
virtual KoShape::setSize() and makes it do nothing. This has the same effect but is \
not user changable.</pre> </blockquote>
<p>On September 7th, 2010, 9:22 p.m., <b>Carlos Licea</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> Geometry protected \
(the current property) does indeed represent both size and position; we have not in \
the past needed them split up and as such they are the same property. > I \
don't think we should have all 3 properties as that will be confusing; it can \
cause weird combinations. So, choose one :) Fine, I'd chose granularity. So \
I'd split them up.
> I'm curious what the reason is for the splitting; in the commits I saw made \
last week there was a usage because the shape should never resize. The problem with \
the commit I saw last week (since reverted) is that the setters on KoShape will be \
presented as checkable options for the user. So a geometry protected or size \
protected boolean on KoShape will be changable by the user in an appropriate GUI. \
> if this is unwanted I suggest that the shape that should not be resized \
re-implements the virtual KoShape::setSize() and makes it do nothing. This has the \
same effect but is not user changable. That's correct, I'm introducing the \
difference because I need the shape not to be re-sizable at all. Originally I tried \
your approach (reimplementing setSize so that it would ignore the change) but it has \
a flaw: the user can still flip the shape which is no desirable at all, so I need a \
way for resizeStrategy to let it know not to change the shape no matter what. \
Regarding showing the property to the user, I think we should not present all the \
properties automatically to the user, we should be able to set it as a \
"private" property not meant for the User to tinker with.</pre> \
</blockquote>
<p>On September 7th, 2010, 10:12 p.m., <b>Thomas Zander</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">you write; "the \
user can still flip the shape which is no desirable at all". Can you explain \
why? The reason you gave before was that the content would not show well, but this is \
not an issue if the scaling is done using a matrix instead of as using a size. \
I'd argue that if the user wants to show some content mirrored, then let her. If \
it makes no sense, then she'll press undo and problem solved. Its not like \
resizing to mirroring is a really easy thing to trigger and protecting the user from \
herself should only go so far.
you write; "I need a way for resizeStrategy to let it know not to change the \
shape no matter what." As explained before, the approach you chose is not \
helping. You are providing public API to control this and any plugin writer as well \
as any KOffice application can toggle that bit to make it resizable again. So this \
sounds like a bad way of getting to your goal.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Because the shape \
represents a concept for which rotation has no value. Would you let the user rotate \
the buttons? no, there's no value on that, equally, why should we allow the user \
to flip a button which displays the text they are after. I just don't want to \
allow that interaction.
"As explained before, the approach you chose is not helping. You are providing \
public API to control this and any plugin writer as well as any KOffice application \
can toggle that bit to make it resizable again. So this sounds like a bad way of \
getting to your goal." Yes, that's true, but if a plug-in misbehaves and \
changes the shape's settings without taking into account the expected behavior, \
well, it's the writer's fault.
No matter what we end up doing in this particular case, you have to make your mind in \
something: do you want developers to be able to control their shapes as they see fit \
or not? I thought that the whole point of Flake was to allow anybody to come up with \
any behavior or design they need. Right now I can't create the interaction I want \
because the properties are mixed together. I see no gain in keeping both properties \
mixed, are there any I'm missing?</pre> <br />
<p>- Carlos</p>
<br />
<p>On August 3rd, 2010, 7:44 p.m., Carlos Licea wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('http://svn.reviewboard.kde.orgrb/images/review_request_box_top_bg.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for KOffice and Thorsten Zachmann.</div>
<div>By Carlos Licea.</div>
<p style="color: grey;"><i>Updated 2010-08-03 19:44:55</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Add two new properties for KoShape: setSizeProtected() and \
setPositionProtected(). They do what they imply. The reason I didn't replace \
setGeometryProtected is because I 1)Wanted to still support that property; and \
2)Think that it might be different, originally I was of the idea that \
Geometryprotected = sizeProtected && positionProtected, but now I'm not \
so sure, I think it depends on how strict you want it to be.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>trunk/koffice/libs/flake/KoShape.h <span style="color: \
grey">(1158763)</span></li>
<li>trunk/koffice/libs/flake/KoShape.cpp <span style="color: \
grey">(1158763)</span></li>
<li>trunk/koffice/libs/flake/KoShape_p.h <span style="color: \
grey">(1158763)</span></li>
</ul>
<p><a href="http://svn.reviewboard.kde.org/r/4883/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
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