El 06/11/2008 04:36 AM, Pau Arumí Albó escribió:
El dt 10 de 06 de 2008 a les 20:11 +0200, en/na David García Garzón va
escriure:
El Tuesday 10 June 2008 18:23:43 Natanael Olaiz va escriure:
El 06/10/2008 01:06 PM, David García Garzón escribió:
El Tuesday 10 June 2008 17:32:40 Natanael Olaiz va escriure:
El 06/10/2008 07:31 AM, Pau Arumí Albó escribió:
El dt 10 de 06 de 2008 a les 06:53 -0300, en/na Natanael Olaiz va
escriure:
El 06/10/2008 06:03 AM, Pau Arumí Albó escribió:
Well, in the processing adapter I putted a check line to don't store
the new attributes if are not given, but any check on the load...
since it works good reading a file with or without the new attributes.
I don't think it would affect other uses (i.e. the backwards
compatibility wouldn't be affected).
The major problem as it's now is if you load a network with the
attributes, it will fill the _processingsBoxesAttributes map. So, I
send here a new patch for Network.cxx that clear it every time you do
a load, to avoid fill all the memory if you load so much times without
clear it.
Do you think it's a problem that _processingsBoxesAttributes could be
non-empty without using it?
Er yes could lead to potential problems. We don't want duplicated
information and the original info sits in the canvas, so let's use it
when loading and saving and keep it clean the rest of the time.
David: help! :)
The only solution that occurs to me is using a toggle attribute like
setPasteMode. But since this wouldn't be used only for paste but loading
files... should I add another?
I don't like it... but it's the only idea that comes to my mind to solve
that...
Sorry i lost the context, could you explain better the problem?
Hot to don't let Network::_processingsBoxesAttributes get filled
everytime you do a Network::LoadFrom, which makes that if you don't
clean with a Network::getBoxesAttributes() it's remains filled with that
values since the next LoadFrom or StoreOn.
How can I know when to fill it and when not? Since these attributes will
be used for saving and loading files too, I can't use setPasteMode....
First, I would change all those misleading Attribute wording to something like
Geometry (in qt naming a geometry is pos+size) or just Boxes. If we had some
other attribute let's think about attributes again, if not, it is an over
generalization.
Before I suggested "ProcessingAspect" but I find "Geometry" better.
Specially being Qt nomenclature.
Regarding your question, in contrast to selection, there is no special mode
here to deal with. The problem with selections is that having no selection
meant all were selected, and also that you should clear the processings.
With geometries you will always use them if they are available. Also, when
loading/cuting/storing/pasting, you just have to deal with geometries of the
involved processings.
On storing / Cuting:
network.setGeometries(nameToGeometryMap); // Will clear previous ones
XMLStorage::Dump(network,....); // StoreOn will clear geometries when done
On Loading / Pasting:
XMLStorage::Load(network,....); <- LoadFrom fills geometries
geometryMap = getAndClearGeometries(); <- This will clear them when done
So, regarding geometries, both cut/paste and load/store have to use them just
if available. If you are pasting some processings into a network you will
keep the positions of the already existing processings.
Agree.
In the next mail Natanael said
I wanted to mean: If someone uses the XMLStorage::Load without getting
and clearing ("using it") the geometries later, the map will remain
filled. Of course, in the implementation of pasting and reading a file
I'll do it, but it could happen and I didn't know if XMLStorage::Load
is used in another place right now...
Yes, Load() it is used in some other places (e.g. OfflineNetworkPlayer) where
Geometries are irrelevant.
But clearing the geometries at the beginning of Load() doesn't solve te
problem? Or I'm missing something?
I think so (that is because I sent the last Network.cxx patch), but the
map will anyways remain filled until the next Load...
P
_______________________________________________
Clam-devel mailing list
[email protected]
https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
_______________________________________________
Clam-devel mailing list
[email protected]
https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
