[PD-dev] 0.48.0 release status

[Alexandre Torres Porres]

Sure, I get and I agree it can be about 90% (I said I didn't care getting
to 100%). The question is wether we'd change the metrics as well so things
would look the same and consistent with Pd Extended and Purr Data too. But
I get that this needs further discussion and more people giving feedback.

cheers

2017-07-22 13:30 GMT-03:00 Dan Wilcox <danomatika at gmail.com>:

>
> On Jul 22, 2017, at 5:23 PM, Alexandre Torres Porres <porres at gmail.com>
> wrote:
>
> 2017-07-22 4:40 GMT-03:00 Dan Wilcox <danomatika at gmail.com>:
>
>> Look, I know you guys go on and on about this but it's really up to
>> Miller.
>>
>> I think the object boxes are sometimes too small with those metrics and
>> I'm not willing to put forward what might be a major change for people
>> without some actual talk.
>>
>> The font is one thing, object sizing another. Also, there are multiple
>> places where the metrics are placed and calculated so I'm not sure if
>> changing the numbers in one place but not in the source code is the right
>> idea either. I just don't know, hence need input for those that do.
>>
>
> ok, agreed, let's actually talk, and be sure what needed change and all -
> but maybe this won't be a priority right now, huh?
>
>
> Maybe not. I do want to make a branch for really testing this. We can get
> to that 90% (as I mention below).
>
> Some assumptions from extended may not hold true now, also considering the
> addition of the zoom feature in the meantime.
>
> Devils Advocate: Also, as IOhannes mentioned at one point, *exact* pixel
>> sizing between platforms is always going to be close but probably not
>> perfect and what happens when people use a different font or different
>> sizing via startup flags? Maybe simply having some space around things and
>> using sub patches is the easiest solution?
>>
>
> I can live with that, not being perfect and all, but as it is, it's just
> really hard to manage. I also, I don't see much point in not wanting to
> make things look exactly the same in all Operating Systems, so we could
> agree that is a desirable goal for everyone, at least, right?
>
>
> With cross platform software, you sometimes give up making things look &
> work*exactly* the same for the ability to run the software on different
> systems. There are always idiosyncrasies you have to deal with and, since
> we're relying on Tk to do the canvas drawing which in turns relies on the
> underlying platform APIs, we don't have total control of all aspects of
> this. If we were rendering the GUI with something like openGL then maybe,
> but even that has differences to work around between systems. But working
> with something like openGL negates the development savings of using Tk to
> being with. It's a balance between "doing everything yourself" and "doing
> things with others."
>
> Basically, I think we can get pretty *close* to things looking the same
> and, arguably, we can definitely be close with using the same font on all
> systems. We're pretty close now. But we don't have total control in how the
> fonts are rendered. Windows and macOS deal with sub pixel rendering and
> antialiasing in different ways, for example. What I'm saying is that
> spending 100% more time on that last 10% to make things "pixel perfect
> between all platforms" is perhaps not worth the effort and may not be
> completely possible without tons of fragile hacks. We can get to that 90%
> relatively easily but is the 10% more worth it? Especially for an open
> source project relying on volunteers?
>
> This is where my devil's advocate argument comes in: perhaps fixing the
> 10% by padding out your help patches is an easier solution?
>
> --------
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20170722/ea9aecab/attachment-0001.html>