Daily test for 2008-01-01

94% tests passed, 12 tests failed out of 186

The following tests FAILED:
          1 - libs-store-storage_test (Failed)
         50 - kspread-Formula (Failed)
         60 - kspread-FinancialFunctions (Failed)
         61 - kspread-InformationFunctions (Failed)
         64 - kspread-StatisticalFunctions (Failed)
         65 - kspread-TextFunctions (Failed)
         70 - kformula-Load (Failed)
         71 - kformula-LoadAndSave (Failed)
        169 - krita-ui-kis_files_test (Failed)
        171 - krita-colorspaces-KisRgbFloatHDRColorSpaceTest (Failed)
        174 - krTest environment:

OpenSUSE 10.3, 64 bits 
g++ (GCC) 4.2.1 (SUSE Linux)
kernel: 2.6.22.13-0.3-default
kdelibs: revision 753912
koffice: revision 755026ita-plugins-KisKSColorSpaceTest (Failed)
        175 - krita-plugins-MixingTest (Failed)

--

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

Shape Container

Hello,

For the chart shape we decided to have an independent legend. That is, a
shape that can be moved and resized, but that the chart shape has
ownership of. I think the best solution for this is a KoShapeContainer.
I already tried it out, and it works pretty well. But as it is now,
every child of a shape container is moved when the container itself is
moved, because the children's positions are relative to the parent.

Now, I sometimes need the legend shape not to be bound to the chart
shape, so that it is not moved when the chart shape is. So here's my
proposal to have something like
KoShape::setPositionRelativeToParent( bool ), with the patch attached to
this email. You're welcome to give it a better name if you can think of
one :)

- Joh

_______________________________________________
koffice-devel mailing list
koffice-devel <at> kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

Re: Shape Container

Johannes Simon wrote:
> Hello,
> 
> For the chart shape we decided to have an independent legend. That is, a
> shape that can be moved and resized, but that the chart shape has
> ownership of. I think the best solution for this is a KoShapeContainer.
> I already tried it out, and it works pretty well. But as it is now,
> every child of a shape container is moved when the container itself is
> moved, because the children's positions are relative to the parent.

So you want to make the chart shape a shape container?

> 
> Now, I sometimes need the legend shape not to be bound to the chart
> shape, so that it is not moved when the chart shape is. So here's my
> proposal to have something like
> KoShape::setPositionRelativeToParent( bool ), with the patch attached to
> this email. You're welcome to give it a better name if you can think of
> one :)

I thought a little about it and think this is not needed. Why don't you 
just have a shape container which does own the chart related shapes. One 
of them would be your actual chart displaying shape, one would be your 
legend, etc.
So you end up with the following structure:

-----------------------------------------------------------
| ChartCompoundShape (or something like that )          |
|                                                          |
|   ---------------------------   --------------------     |

Re: Shape Container

Am Donnerstag, den 03.01.2008, 10:42 +0100 schrieb Jan Hambrecht:
> So you want to make the chart shape a shape container?
That's my idea, yes.

> I thought a little about it and think this is not needed. Why don't you 
> just have a shape container which does own the chart related shapes. One 
> of them would be your actual chart displaying shape, one would be your 
> legend, etc.
> So you end up with the following structure:
> 
> -----------------------------------------------------------
> | ChartCompoundShape (or something like that )          |
> |                                                          |
> |   ---------------------------   --------------------     |
> |   | ChartShape              |   | ChartLegendShape |     |
> |   |                         |   |                  |     |
> |   |                         |   --------------------     |
> |   |                         |                            |
> |   |                         |                            |
> |   |                         |                            |
> |   --------------------------|                            |
> |                                                          |
> |                                                          |
> ------------------------------------------------------------
> 
> You can even add some text shapes for descriptive texts.
> And if you want to move the whole shebang, just move the container 
> shape. If you want to move the chart or the legend separately, you can.
This is exactly what I first had in mind, too :) But I can't think of a
good way to draw the compound shape so that you know where it is and you

cleaning guiutils

Hi all,
there are a number of classes in guiutils that are not used anymore:

KoTabChooser:
there is not much documentation in there so I don't exactly know where it was 
used but atm according to lxr.kde.org it is not used anywhere.

KoLineWidthAction:
This functionality is propably already implemented in some of the dockers and 
the class itsself is not used anywhere.

KoTabBar:
This class is only used by KSpread, probably this should be moved to kspread 
dir and renamed something like SheetTabBar or so.

KoPictureFilePreview:
This seems to be quite old. It is not used anywhere and I would bet that 
KFileDialog is able to show previews of pictures and clipart.

KoTemplateChooseDia:
This is only used in a some playground app named kalculus. Don't we use 
KoOpenPane in newer KOffice versions?

KoInsertLink:
Provides a dialog for inserting all kind of links. Not used anymore. Still 
needed?

KoShapeGeometry:
A widget that does the same as the geometry docker. Not used anymore.
Removal? 

Re: cleaning guiutils

On Fri, 4 Jan 2008, Martin Pfeiffer wrote:

> Let's do some winter cleaning...

Good idea!

Re: cleaning guiutils

> KoTabBar:
> This class is only used by KSpread, probably this should be moved to kspread
> dir and renamed something like SheetTabBar or so.

Pre 2.0 both Krita and Kivio also used it. Do they still need any tab
bar at all now?

Regards,

Ariya

Re: cleaning guiutils

2008/1/4, Ariya Hidayat <ariya <at> kde.org>:
> > KoTabBar:
> > This class is only used by KSpread, probably this should be moved to kspread
> > dir and renamed something like SheetTabBar or so.
>
> Pre 2.0 both Krita and Kivio also used it. Do they still need any tab
> bar at all now?

Kivio doesn't have a need for it anymore at least

--

-- 
LLaP
Peter Simonsson

Re: cleaning guiutils

On Fri, 4 Jan 2008, Peter Simonsson wrote:

> 2008/1/4, Ariya Hidayat <ariya <at> kde.org>:
> > > KoTabBar:
> > > This class is only used by KSpread, probably this should be moved to kspread
> > > dir and renamed something like SheetTabBar or so.
> >
> > Pre 2.0 both Krita and Kivio also used it. Do they still need any tab
> > bar at all now?
> 
> Kivio doesn't have a need for it anymore at least
> 

Nor Krita: we used to use it when a single document could still contain multiple 
images, but we removed that functionality for 1.5.

Boudewijn

Re: cleaning guiutils

2008/1/4, Martin Pfeiffer <hubipete <at> gmx.net>:
> KoTabulator:
> Only in KoText, shouldn't this be moved there?
This was used in KoRuler before... not sure if it's still needed there
to implement the same functionality.

--

-- 
LLaP
Peter Simonsson