<div dir="ltr">I think the first may be a good solution.<br><br>Another problem that i see in code is that Get*Control(s) is used in this way:<br><br>InControl& control = proc.GetInControl("Some Control 1")<br>
<br>We'll have to rewrite all these case by case, watching carefully why this is done and what to do with each case.<br> Simply run grep -R * -e "GetInControl" | grep
-v svn | grep -v "Binary" to see this, in the network editor source tree<br>For example:<br>NetworkCanvas.hxx: CLAM::InControl& inControl = processing->GetInControls().GetByNumber(index);<br><br>
<br><div class="gmail_quote">On Tue, Aug 5, 2008 at 4:50 AM, Pau Arumí <span dir="ltr"><<a href="mailto:parumi@iua.upf.edu" target="_blank">parumi@iua.upf.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Of course, here we have the core of the typedcontrols problem: we want<br>
homogeneous interface (which is nice for connection).<br>
But at the same time we want services that doesn't make sense for all<br>
typedcontrols, such as bounds. And that require coupling with the Type<br>
of the control (such as GetDefault() or GetBounds() )<br>
<br>
Francisco says that maybe we could rethink how the framework handles<br>
bounds. If we want to to maintain the feature (I think we do) I see no<br>
simple solution.<br>
We could either<br>
1. taint the BaseTyped*Control interface with float-specific services<br>
(such as float GetDefautl(); or float GetInferiorBound() ) or<br>
2. use downcast.<br>
<br>
If we do 2, it is not absolutely necessary to have a Float*Control<br>
subclass. We could implement the GetDefault(), GetBounds() etc methods<br>
in the Typed*Control<Type> template class by method specialization.<br>
<br>
I'm more for 1 because it is much simpler for control clients and I<br>
don't foresee the float-specific interface grow a lot.<br>
But I'd like to hear more discussion...<br>
<font color="#888888"><br>
P<br>
</font><div><div></div><div><br>
<br>
On dl, 2008-08-04 at 19:57 -0300, Francisco Tufró wrote:<br>
> I have it, but, no real changes were made to network editor to accept<br>
> typed controls, and i think this is the moment to talk a bit about<br>
> this, maybe some effort on removing these functions can bring much<br>
> help on migrating everything in a small step. In the patch you are<br>
> talking about InControl was kept intact, only inheriting<br>
> TypedInControl<int> was modified (and connection stuff also).<br>
><br>
> On Mon, Aug 4, 2008 at 7:47 PM, Hernán Ordiales <<a href="mailto:h@ordia.com.ar" target="_blank">h@ordia.com.ar</a>><br>
> wrote:<br>
><br>
> On Mon, Aug 4, 2008 at 7:38 PM, Francisco Tufró<br>
> <<a href="mailto:nictuku@gmail.com" target="_blank">nictuku@gmail.com</a>> wrote:<br>
> > Hi, one of the topics that we didn't defined about the typed<br>
> control<br>
> > migration is what to do with the actual controls.<br>
> > The first idea (and the one i like most) was to do a simple<br>
> typedef<br>
> > Typed[In|Out]Control [In|Out]Control.<br>
> > The problem with this solution is that there are functions<br>
> implemented in<br>
> > InControl that have no sense in TypedInControl, specially<br>
> those for bounds<br>
> > and GetLastValueAs[Int|Bool].<br>
> > My question is if it possible to structure the framework<br>
> code so these<br>
> > functions can be removed. For example, NetworkEditor uses<br>
> this bounding<br>
> > stuff, should we rethink the way it works with controls to<br>
> simplify the<br>
> > migration.<br>
> > The other solution was to do InControl inherit<br>
> TypedInControl and add the<br>
> > missing functionality, but i think this solution is going to<br>
> bring problems<br>
> > when we migrate everything, and introduces some complexity<br>
> to the framework<br>
> > that i don't know if it is correct, and that's why i'm<br>
> asking for opinions.<br>
> > That's all by now!<br>
><br>
><br>
> You have a previous patch (AFAIK full working at least with<br>
> clam lib)<br>
> with this last approach, don't? why not attach it to this<br>
> thread?<br>
><br>
> cheers<br>
> --<br>
> Hernán<br>
> <a href="http://h.ordia.com.ar" target="_blank">http://h.ordia.com.ar</a><br>
> GnuPG: 0xEE8A3FE9<br>
><br>
> _______________________________________________<br>
> Clam-devel mailing list<br>
> <a href="mailto:Clam-devel@llistes.projectes.lafarga.org" target="_blank">Clam-devel@llistes.projectes.lafarga.org</a><br>
> <a href="https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel" target="_blank">https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel</a><br>
><br>
><br>
> _______________________________________________<br>
> Clam-devel mailing list<br>
> <a href="mailto:Clam-devel@llistes.projectes.lafarga.org" target="_blank">Clam-devel@llistes.projectes.lafarga.org</a><br>
> <a href="https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel" target="_blank">https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel</a><br>
<br>
<br>
_______________________________________________<br>
Clam-devel mailing list<br>
<a href="mailto:Clam-devel@llistes.projectes.lafarga.org" target="_blank">Clam-devel@llistes.projectes.lafarga.org</a><br>
<a href="https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel" target="_blank">https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel</a><br>
</div></div></blockquote></div><br></div>