'Re: Review Request: load table:table as part of a draw:frame in the'

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

List:       koffice-devel
Subject:    Re: Review Request: load table:table as part of a draw:frame in the
From:       "Thomas Zander" <zander () kde ! org>
Date:       2010-04-26 8:02:46
Message-ID: 20100426080246.11892.44356 () localhost
[Download RAW message or body]

> On 2010-04-25 09:44:54, Thomas Zander wrote:
> > Thanks for working on this :)
> > I'm just giving this a general overview, I don't know the odf loading all that \
> > well. The QPair looks very complicated to me so I gave it some thought how to \
> > make it simpler.  Hope it makes sense.
> 
> Thorsten Zachmann wrote:
> I don't think the QPair is in any way complicated but that might be a personal \
> opinion. As a QPair can be used so a QHash can be used. However for the place where \
> it is used a hash which provides a fast lookup is not needed. I would say the list \
> should be faster here as the adding and iterating over the list are faster than for \
> a hash and these are the only used operations.

Inserting into a hash is indeed slightly more expensive. This is why I suggested to \
use a pointer as the key. This makes calculating the hash-key very cheap. But I see \
your point; you can also use a QMap if the speed of insertion is relevant. I \
personally doubt we'll add more than 2 keys into that (has)map so I don't think it \
matters all that much.

Using a QPair is a couple more lines of code for every insert or lookup, I don't \
really see the need for that when you can avoid it using just a different container \
that already has two values. Does that make sense?

> On 2010-04-25 09:44:54, Thomas Zander wrote:
> > trunk/koffice/plugins/textshape/TextShape.cpp, line 375
> > <http://reviewboard.kde.org/r/3805/diff/2/?file=24510#file24510line375>
> > 
> > I don't understand that '!' (not) there. That doesn't make sense to be there IMO.
> > Can you add a comment perhaps?
> 
> Thorsten Zachmann wrote:
> If the loadOdfFrame from the base class fails it uses the one below. Can you \
> explain what is not understandable here so I can formulate a comment that makes it \
> clear.

Well, that what you just wrote is fine to put in a comment there :)
Maybe also explain why it would avoid running the one in the textshape if the one in \
the base class does load fine.

> On 2010-04-25 09:44:54, Thomas Zander wrote:
> > trunk/koffice/libs/flake/KoShapeFactoryBase.cpp, line 96
> > <http://reviewboard.kde.org/r/3805/diff/2/?file=24505#file24505line96>
> > 
> > Now we no longer return a odfNameSpace() as a QString I'd like to suggest that \
> > the namespace is kept as a const char *. The advantage there is that we can use \
> > the pointers from KoXmlNS and thus only do pointer comparison for namespaces.  \
> > Which means that we avoid converting to utf16 (QString native) on call to \
> > setOdfElementNames and avoid a string compare. That should make a significant \
> > impact in startup time too :) 
> > This, together with the previous suggestion, would make the elements stored like;
> > QHash<char*, QStringList>
> 
> Thorsten Zachmann wrote:
> There was always a QString used for the namespace
> 
> -QString KoShapeFactoryBase::odfNameSpace() const                                   \
>  
> so this patch doesn't change anything in this regard.
> 
> It is needed as a QString in the registry as there we have a QString we need to \
> compare it too. So it makes sense to do the conversion only once.

I completely agree it was always a QString, didn't mean to imply anything else or \
that you broke something. I'm just looking at this from the point of view that with \
the new data structure you introduced the thing may need an extra look as it does \
look rather imposing with nested templates now. In the registry we do too many \
implicit conversions which really makes things slower than they need be. So, yes, \
some extra code is needed in the registry (specifically \
KoShapeRegistry::Private::createShapeInternal) to make this use the char*, but it \
does certainly look like its worth it. To be clear; if you see a
 e.namespaceURI() == KoXmlNS::draw
the right parameter is a char*, so this causes a conversion of the char* to QString \
(utf16) and then a string compare. This is done quite often, so thats my point. It \
would be much cheaper to replace all this with simple pointer compares.

Anyway, I hope you see my point and think it makes sense to make things even better.  \
I won't insist on anything, I just wanted to give you an idea for improvement.

- Thomas

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

On 2010-04-25 06:55:45, Thorsten Zachmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3805/
> -----------------------------------------------------------
> 
> (Updated 2010-04-25 06:55:45)
> 
> 
> Review request for KOffice.
> 
> 
> Summary
> -------
> 
> Make it possible to load a table:table inside a draw:frame. To make this possible \
> it is needed to extend KoShapeFactory and KoShapeRegistry that multiple namespaces \
> -> tag's can be supported by one shape. 
> 
> This addresses bug 231680.
> https://bugs.kde.org/show_bug.cgi?id=231680
> 
> 
> Diffs
> -----
> 
> trunk/koffice/libs/flake/KoShapeFactoryBase.h 1118236 
> trunk/koffice/libs/flake/KoShapeFactoryBase.cpp 1118236 
> trunk/koffice/libs/flake/KoShapeRegistry.cpp 1118236 
> trunk/koffice/libs/flake/tests/TestKoShapeFactory.cpp 1118236 
> trunk/koffice/libs/kotext/opendocument/KoTextLoader.cpp 1118236 
> trunk/koffice/plugins/textshape/TextShape.h 1118236 
> trunk/koffice/plugins/textshape/TextShape.cpp 1118236 
> trunk/koffice/plugins/textshape/TextShapeFactory.cpp 1118236 
> 
> Diff: http://reviewboard.kde.org/r/3805/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Thorsten
> 
> 

_______________________________________________
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] 