KOffice 1.6 string/feature freeze

Hello everybody,

KOffice branch/1.6 is now frozen for new feature and for string changes. And 
is therefor opened only for bug fix.

The three release dates are planned as followed (tags happen a week before the 
release date):
beta1 September 8, only source code, no translation
rc1 September 26, source code + translation
final October 10, source code + translation

So tagging of the beta is starting really soon.

Update on the release dates can be found here  in the future : 
http://developer.kde.org/development-versions/koffice-1.6-release-plan.html

Note for translators, after the final release, kexi (and only kexi) will 
benefit from a feature freeze lift, and string freeze lift, it will probably 
follow a similar pattern as what is done for kde/branch/3.5.

Have a nice day.
--

-- 
--- Cyrille Berger ---

Re: RFD: loading/pasting/DnD in Flake?

On Thursday 24 August 2006 17:16, Benjamin K. Stuhl wrote:
> On Thu, 24 Aug 2006 10:21:39 +0200, Thomas Zander inscribed:
> > Morning :)
> > Long emails, but progress is being made! Thanks for taking this on.
>
> Indeed. And it's a complex problem, so I, at least, don't mind the
> verbiage. ^_^

Sorry for long delay in replying. I was otherwise occupied.
But I very much enjoyed my long weekend in London :P

Some general feedback on Tools.

> > I'm not into XML loading very much in KOffice, but should that source
> > not be a xml element ?  Since the loading will be cascaded and
> > loading of a small part of the XML tree is just delegated. No need to
> > recreate an xml.
>
> The vague motivation for a mime-type was to let the shape declare
> support for all the mime types that can somehow be filtered into what
> it can handle, but the filter-chain hunts can just as easily be done
> outside the shape )in the KoDropTool or the like... perhaps there
> should be a KoSaveTool and a KoLoadTool to encapsulate that logic?

A KoTool is a class that is the 'controller' bit of MVC, but its heavily 
specialized to only do the user-interaction part.
So, it will basically translate all user input to the specific shapes it 
can operate on.
For this reason inventing a load or save tool is not really appropriate as 
they are just helper classes.

better tool switching

On Thursday 24 August 2006 17:16, Benjamin K. Stuhl wrote:
> Also, I would suggest that KoTool::activate() should get a QPoint(F?)
> (I'm not really sure when to use which version...) argument so that you
> can, say, simply click a text shape twice (or double-click) to get the
> cursor where you clicked? It's really rather irritating to always have
> to mouse over to the toolbox to be able to enter text in a word
> processor... ^_^

I've had the horrible experience of having to use Scribus for the last 
week. The way that focus is switched between items is truly horrible and, 
well, .. just leave it at that.

So, after figuring out how _not_ to do it here are some ideas on what is 
easier and better.

* Tools are sticky.  With this I mean that having a text tool in use and 
clicking on another text shape should keep that tool. No (auto) 
unselecting and reselecting is allowed :)
* Double click to start using the shapes tool should work.
* single click on the empty canvas should deselect all shapes. Combined 
with point 1 the default tool should become usable (to select another 
shape) but if the current tool is usable on the newly selected shape 
there it should be switched to immediately.  In other words; switching 
shape by unselecting and reselecting should not forget the tool.

--

-- 
Thomas Zander

_______________________________________________

krita flakes or qimage

On Thursday 24 August 2006 17:16, Benjamin K. Stuhl wrote:
> That also brings up a side question: is the plan to use the krita shape
> for _all_ embedded images? It seems to me that that might be a bit of
> overkill? (Not to mention slow, since it has to convert PNG and JPEG
> images to .kra on loading and then back again on saving, since .kra is
> not one of the image formats ODF supports... :-/) Perhaps it might be
> work making just a KoPictureShape that supports anything QImage does
> and just has trivial resize and "Open in Krita" actions? (Even MSOffice
> pops open a Paint window to edit raster images.)

For simple RGB (A) images a QImage will likely be enough, but its not as 
simple as that.
When we want to print an image we need to have color profiles support. 
Importing non-rgb images needs the krita shape anyway. And above all, 
having one common interface to all images is important.

So, I'm not sure if there is much gain in having two, but if there are 
then we should make the transition as smooth as possible.

For now; I'd like to see where things lead with just having a Krita shape.
--

-- 
Thomas Zander

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

Re: RFD: loading/pasting/DnD in Flake?

On Sunday 27 August 2006 10:26, Thorsten Zachmann wrote:
> To load shapes in odf first the styles for the shapes have to been
> loaded so that when the shape is loaded the style for the shape can be
> found.

While true, we are using DOM and there is no need for the 'first'. We just 
need to make sure that the styles loaded are properly cached.

> In koffice 1.6 kword and kpresenter uses KoOasisStyles and 
> KoOasisContext. The KoOasisContext is then passed to the load method of
> the shape.

Looks good, yes.
But for the designing phase (which we are in now) its a bit of overkill to 
want to have everything perfect on the first go :)
So, to BKS I'd say this part can be ignored for now.

> Form this I think we should have a instance which should do the loading
> of the shapes. I call it shapeloader form now on.

The idea is a bit similar to mine, I just put it in the 
KoCreateShapesTool.  Its fine to put it in another class and let it load 
stuff.
There are some differences, but please read my original emails to see what 
they are ;)

> > +    virtual void load(const QDomElement &rootElement, KoStore
> > *store, KoCreateShapesTool *createShapes) = 0; +
>
> As pointed out above we should not pass a KoCreateShapeTool to the

Re: krita flakes or qimage

> For simple RGB (A) images a QImage will likely be enough, but its not as
> simple as that.
> When we want to print an image we need to have color profiles support.
> Importing non-rgb images needs the krita shape anyway. And above all,
> having one common interface to all images is important.
>
> So, I'm not sure if there is much gain in having two, but if there are
> then we should make the transition as smooth as possible.
>
> For now; I'd like to see where things lead with just having a Krita shape.

stupid question: having only krita's image shape, wouldn't that make kword 
somehow depend on krita ? I mean, adding an image to a document is a very 
important feature, so lets say that krita isn't installed, the user can't add 
images ? or won't see images in the document he opened ? If I am correct, I 
think that a qimage shape might be usefull as a backup solution if krita is 
not available.

--

-- 
--- Cyrille Berger ---

Re: krita flakes or qimage

On Friday 1 September 2006 18:11, Cyrille Berger wrote:
> > For now; I'd like to see where things lead with just having a Krita
> > shape.
>
> stupid question: having only krita's image shape, wouldn't that make
> kword somehow depend on krita ? I mean, adding an image to a document
> is a very important feature, so lets say that krita isn't installed,
> the user can't add images ? or won't see images in the document he
> opened ? If I am correct, I think that a qimage shape might be usefull
> as a backup solution if krita is not available.

I think thats a good point. But at the same time I'm thinking about cases 
like not having a formula shape available with approximately the same 
issues.
Most corporate documents actually don't have images (be sure to make the 
distinction between vector and raster here!) and the vector shape are 
supplied by koffice libs.

Having the qimage fallback sounds nice, but I fear that telling the user 
we can't print (with color management anyway) while we will show the 
image on screen will not be accepted leading to a slippery slope of 
moving all features into a shape.

That said; if someone has time to create (AND MAINTAIN) such a qimage 
shape and all the problems due to it, I don't have a big problem against 
it :)

--

-- 
Thomas Zander

Re: krita flakes or qimage

On Fri, 1 Sep 2006, Thomas Zander wrote:

> For now; I'd like to see where things lead with just having a Krita shape.

Amen to that.

Boudewijn

Changelog for 1.6 Beta 1

Hi everybody,

Now that the beta 1 is tagged, we will need to start writting the changelog. 
So anyone, please make the list for your application :)

--

-- 
--- Cyrille Berger ---

Re: krita flakes or qimage

On Friday 01 September 2006 18:34, Thomas Zander wrote:
> I think thats a good point. But at the same time I'm thinking about cases
> like not having a formula shape available with approximately the same
> issues.

> Most corporate documents actually don't have images (be sure to make the
> distinction between vector and raster here!) and the vector shape are
> supplied by koffice libs.

Well, most logo's I see on corporate documents are bitmaps -- jpegs, to add 
insult to injury! But then, I usually only see the output from smaller 
companies who generally don't have competent design staff.

> Having the qimage fallback sounds nice, but I fear that telling the user
> we can't print (with color management anyway) while we will show the
> image on screen will not be accepted leading to a slippery slope of
> moving all features into a shape.

I would not mind moving the basis KisPaintDevice, being a color managed single 
layer raster image into KOffice libs, similar to the vector shapes, while 
still keeping all the fancy tools and filters in Krita. Shapes are general 
building blocks, while applications are the specialized user interfaces for a 
specific task.

> That said; if someone has time to create (AND MAINTAIN) such a qimage
> shape and all the problems due to it, I don't have a big problem against
> it :)

--

-- 
Boudewijn Rempt