<Not-34b6>
[haikuports/haikuports] Begasus 071344e - zimg, new recipe (#7053)
x10z has joined #haiku
* humdinger
waves
humdinger has quit [Quit: Vision[]: Oi with the poodles already!!]
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
MajorBiscuit has quit [Ping timeout: 480 seconds]
tuaris has joined #haiku
x10z has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
AD_MOS has quit [Ping timeout: 480 seconds]
gouchi has joined #haiku
<zdykstra>
It's pretty amazing where Haiku is these days. I appreciate the work that every single person does on the OS/ports/documentation/infrastructure/everything.
tuaris has quit [Read error: Connection reset by peer]
<PulkoMandy>
(it's not in interface kit but in a separate lib)
<PulkoMandy>
we don't use it because it's not documented in the API guide so no one knows about it, and because most of the apps were already layouted using other methods and there wasn't really a need to redo it all
<nephele>
So, just like how nothing uses the menu layout because it is not documented? :(
<waddlesplash>
there are other reasons not to use it, I think
<waddlesplash>
but I can't remember what they are precisely. I think a big one of them is that this method can't even theoretically handle right-to-left layouts
<waddlesplash>
we don't support that yet, but the existing layout model does at least theoretically support it
<PulkoMandy>
I have one app using the menu layout but it's a closed source one
<nephele>
StyledEdit uses the menu layout also, I added that
<nephele>
why would ALM not handle RTL?
<PulkoMandy>
but without docs, all the nice APIs are kind of reserved to people who dig into the header files to find help, which is not everyone
augiedoggie has quit [Ping timeout: 480 seconds]
<nephele>
>error: static assertion failed: comparison object must be invocable as const
<nephele>
Heh, no idea what gcc wants here xD
<waddlesplash>
the message is generally from the programmer who wrote the static assertion
<PulkoMandy>
a "const" somewhere
<waddlesplash>
nephele: because it's constraint-based, it doesn't actually know how things are supposed to be layed out
<waddlesplash>
it just "scales" them according to the constraints
<nephele>
???
<waddlesplash>
whereas "traditional" grid layouts are easily reversible according to RTL rules
<waddlesplash>
i.e. label on the left can be automatically moved to the right based on how the grid is layed out
<nephele>
That doesn't make any sense to me
<PulkoMandy>
that makes no sense, ALM has constraints about how things are supposed to be laid out, like "this object must be to the left of this other one"
<nephele>
if you have a layout in ALM you could just reverse the order
<PulkoMandy>
and of course they can be reversed by flipping what's "left" and "right"
<PulkoMandy>
also iOS uses a very similar system so... I doubt they have a problem with that?
<waddlesplash>
hmm I seem to recall thinking this wasn't easily solved
<waddlesplash>
iOS layouts are radically simpler than ours
<waddlesplash>
also on iOS, form fields generally are a single control and not 2 (label+control)
<PulkoMandy>
we can use our form fields as a single control if we want to
<PulkoMandy>
then it's impossible to align them
<PulkoMandy>
which iOS probably has a way to handle already, so they must be doing some separate layouting on the label/field
<waddlesplash>
yes, iOS obviously does things very differently
<nephele>
honestly, from what I am reading in the paper i don't see why ALM would have any issue with RTL
<waddlesplash>
nephele: anyway we do use libalm for Stack & Tile
<waddlesplash>
so, that's it's one major use at present
<nephele>
This is musiccollection, already fixed that it expected ctype.h to be included
<waddlesplash>
there's some comparison that must be invocable as const
<waddlesplash>
probably an operator<
<nephele>
Now, if i knew what that meant... :D
<extrowerk>
I was looking at ARM SBCs but everything is expensive. Therefore i bought this: https://i.ebayimg.com/images/g/nUEAAOSwAw9hXWrZ/s-l1600.jpg This is an LTE modem, but basically it is a full computer, it got 4x1Ghz ARM core, 512 MbB ram, 3,3 GB flash, WLAN and Bluetooth. You can install debian and openwrt onto it. So you plug it into a powerbank, it joins to your wlan, you connect to it through ssh and you get a debian aarch64 system.
<extrowerk>
You can even add an SD card or switch the USB to host mode.
<nephele>
That works, I wish gcc was more helpfull sometimes, i am really confused why it complains about something in gcc headers if the error is here :/
<waddlesplash>
because the error is generated by an assertion in std::map
<waddlesplash>
it really should display the method std::map is trying to invoke, I agree
Gaspare has quit [Read error: Connection reset by peer]
<andreasdr[m]>
C++ error messages are a real pain for beginners, If could add my opinion here :D
* phschafft
removes 'for beginners', then ', If could add my opinion here :D', and then even replaces 'error messages are' with 'is'.
augiedoggie has quit [Ping timeout: 480 seconds]
<nephele>
Do you all have a shortcut for the git push refs for something command?
<PulkoMandy>
I think there is a thing called "git review" that sets up a git alias but I have never used it
<nephele>
PulkoMandy: by the way, if i understood you correctly for the interfacekit the function should be there in BPrivate, and the two arrays inaccesible
<nephele>
I'll work on that next, then
<PulkoMandy>
I don't know if it should be in BPrivate then, probably yes
<PulkoMandy>
(that's annoying because when we move it out of BPrivate, it will break the ABI then)
<PulkoMandy>
but maybe this should just stay in BPrivate forever
<nephele>
Well, I don't think any userspace app should normally ever call this
<nephele>
Maybe there should be a seperate namespace like BNeverUseThis :P
tuaris has joined #haiku
<PulkoMandy>
yes, seems fine, then it can stay in BPrivate
<PulkoMandy>
well we should use the anonymous namespace as well as symbol visibility to make a lot more things completely unreachable from outside the libs, but that's for another time
<nephele>
Well, in this case webkit does need to reach the function though
<nephele>
and probably prefs/appearence
<PulkoMandy>
yes
<PulkoMandy>
and ThemeManager, and...
<nephele>
I guess if i change this then prefs/appearence can't be used on older haiku versions... but is that a goal?
<PulkoMandy>
no
<PulkoMandy>
we used to have builds of preference panels for BeOS, but we stopped doing that a very long time ago (even before alpha1 I think)
Gaspare has joined #haiku
<PulkoMandy>
the first few "releases" of Haiku were actually just that, updates to a few components to install in a BeOS system
<nephele>
>app_server: Basic scaling for window borders.
<nephele>
Cool
<nephele>
Waddlesplash: regarding the resize know I think there might still be some apps left that use the wrong scrollbar width and thus have a layout where the scaled know would look a bit wrong on
<waddlesplash>
yes, there are, and we should fix 'em,
<nephele>
I think, i fixed severall.. like webpositive stylededit and pulkomandy fixed showimage
<waddlesplash>
I've been meaning to mark B_*_SCROLL_BAR_* as deprecated
<nephele>
I would have to check which ones are still missing
<waddlesplash>
Terminal's one of the ones that need to be fixed
<waddlesplash>
nephele: anyway, the window borders look as usual on 1x res, but at any more than that and they don't really look quite right, they look a bit "heavy"
<waddlesplash>
but all this code is just really gnarly IMO, it needs a major overhaul
<waddlesplash>
TabDecorator, Decorator, DefaultDecorator, SATDecorator ... that's at least 2 too many classes
<waddlesplash>
well, really Decorator should be a pure virtual, then SATDecorator and TabDecorator should be merged
<nephele>
IIrc the windows and mac decorators still need to updated to do stack and tile, after that SATDecorator should be the normal one
<waddlesplash>
the problem is that all the decorator APIs are just ... weird
<waddlesplash>
it deserves a major refactor
<waddlesplash>
all the stuff about how it draws borders and decides to size them is split across multiple classes
<waddlesplash>
as you can see from that commit. not really fun
<nephele>
I changed the Scrollbar arrows to use control highlight in my decorator and i think this looks a lot better on dark and light mode
<PulkoMandy>
well, there was an API for decorators and a separate one for Stack&Tile and then they were merged together
<nephele>
should I submit this to HaikuDecorator?
<PulkoMandy>
but it would be nice if SATDecorator was merged with the base Decorator, rather than with TabDecorator
<PulkoMandy>
so that every decorator does Stack&Tile
<nephele>
Yeah
<PulkoMandy>
and TabDecorator is really there just to avoid code duplication between DefaultDecorator and BeDecorator
<waddlesplash>
... which doesn't really work
<PulkoMandy>
yes
<waddlesplash>
as there's still tons of code duplication
<waddlesplash>
and, a ton of leaky abstractions
<nephele>
Uhh, what's the difference between those two? It looks like they just render slightly differently?
<PulkoMandy>
there are no abstractions in these things, it's just "I need a place to put this common code in"
<waddlesplash>
that's most of the difference, yes
<waddlesplash>
PulkoMandy: right, that's the problem
<PulkoMandy>
yes, Be decorator is a pixel perfect replica of what BeOS did
<waddlesplash>
so, someone needs to patiently refactor all this code to have actual abstractions
<nephele>
So why doesn't BeDecorator overide HaikuDecorator and just change the drawing methods? :)
<PulkoMandy>
it's different, it isn't high dpi compatible I think
<waddlesplash>
honestly there's another reason to change things here
<waddlesplash>
it's probably a good idea to move decorator rendering to a separate server
<nephele>
for?
<waddlesplash>
as they're addons, and they're one of the major reasons appserver has crashed before
<nephele>
Ah, yes that does make sense. But the same should be for controllooks then
<waddlesplash>
err, they already are outside of appserver
<waddlesplash>
controllooks are loaded by libbe
<PulkoMandy>
yes, controllook will jsut crash every app instead of crashing app_server :D
augiedoggie_ has joined #haiku
<nephele>
developing a controllook is really annoying. a lot of apps crash immidiently once it live reloads because they can't deal with a function now beeing somewhere else
<waddlesplash>
what?
<waddlesplash>
oh you mean live reloading the binary?
<waddlesplash>
this actually should work so long as you delete, NOT overwrite, the target file
<waddlesplash>
i.e. rm && cp not just cp
<nephele>
Ugh. Why is this a difference?
<PulkoMandy>
I'm not sure I would go with a separate server, wouldn't it be more interesting to catch the crashes/segfaults and have some failsafe in app_server generally?
<PulkoMandy>
nephele, because the file is mmapped
<waddlesplash>
because libraries are mmap'ed by runtime_loader, so when you overwrite the file it changes the mapped data
<PulkoMandy>
so if you overwrite it, the content of memory instantly gets replaced with the new file
<waddlesplash>
whereas rm unlinks the file, so the kernel doesn't change its contents
<waddlesplash>
yeah
<waddlesplash>
there is actually a TODO in the kernel about this, Linux and other OSes have a flag you can pass to mmap to "lock" the contents and prevent such crashes from happening
<waddlesplash>
we don't implement that yet
<nephele>
Yes. but. live reloading happens because of the file beeing watched no? could the watcher not reload explicitly if the file is touched? or is this file just not watched at all?
<PulkoMandy>
(also you can use "install" instead of rm+cp, it was designed to avoid this exact problem that also exists on other unix)
<PulkoMandy>
live reloading will work fine
<waddlesplash>
nephele: no, it's nothing to do with watching
<PulkoMandy>
but it really cleanly unloads the old one and then loads the new one
<waddlesplash>
yeah. the problem is for libraries that stay loaded, if the file inode remains the same but contents change
<PulkoMandy>
very different from "hey I just moved all functions around without warning, sorry"
<waddlesplash>
yup
<nephele>
I would expect that on deleting the controllook that the system immidiently stops using it
<waddlesplash>
can't do that
<waddlesplash>
I mean you could but it'd be expensive
<waddlesplash>
if you send a "control look changed" to the BApplication, then it should immediately stop using it yes
<nephele>
Well, so. If i do this right. delete the control look and then place a new copy
<nephele>
do apps then load the new version?
<nephele>
or do i have to restart them, or send a message using hey?
<PulkoMandy>
also "deleting" is more complicated than you think
<PulkoMandy>
if you delete a file, but it is open and/or mmapped somewhere, the file is unreachable from the filesystem, but it is still there and the apps that already had it open can keep using it as long as they need
<PulkoMandy>
so that works fine and safely
<nephele>
(seems to be no live reloading for decorators with choosing a new one in appearence prefs anyhow)
<waddlesplash>
restart or hey, yes
<waddlesplash>
oh, right, we may not actually do "live reload" of decorators yet
<waddlesplash>
there's a message sent around I think but I'm not sure BApplications do anything with it
<nephele>
PulkoMandy: Yeah, my mental disconnect was with me expecting that the "reloading" comes from the file beeing watched
<PulkoMandy>
so then it's up to some code (in app_server or in libbe) to watch the file, notice that it is "gone" from the filesystem, and decide which decorator to use now, tell all apps to load that one, and then invalidate everything
<nephele>
but it just beeing mmaped makes much more sense
<PulkoMandy>
but then it's still tricky because if someone did a BControlLook* myOwnPointer = be_control_look; and then you delete be_control_look and create a new one, things will still crash there
<nephele>
Deleting the file unloading the decorator and putting a new version and then telling apps to use it would be slightly annoying too
<waddlesplash>
yeah, not easy
<PulkoMandy>
and even if an app only uses be_control_look, strange things can happen if it's replaced while an app is using it, so locking would be needed around all uses of be_control_look then?
<nephele>
i don't suppose app_server could also watch it and if it is touched explicitly reload it? ... i guess that is harder too since app_server can't block you writing the file
<PulkoMandy>
I'd say it's not worth the effort. Restart your apps
augiedoggie_ has quit [Ping timeout: 480 seconds]
<PulkoMandy>
maybe we can make it work live but only for appearance preferences
<waddlesplash>
we should definitely work on B_FONTS_CHANGED handling tho
<waddlesplash>
PulkoMandy: yeah, I like that idea
<nephele>
I was thinking of the fonts changing actually... I am wondering, if you scale gui controls with the font right
<nephele>
you can't really do live updating *and* have a slider
<PulkoMandy>
and send the message and let other apps deal with it if they want to (as we do for B_LOCALE_CHANGED)
<nephele>
if you do it normally, because this slider would otherwise be resized while you are using it
<nephele>
having a "scale this" slider in the firstbootprompt to change the font size might be nice. I'd expect a dark mode to be there too.
<waddlesplash>
yes, I intend to get the absolute basics of this in before the next beta
<PulkoMandy>
please, no thousands of options in FirstBootPrompt :(
<waddlesplash>
basically implementing what was discussed last fall
<waddlesplash>
PulkoMandy: maybe a button for Appearance settings in FBP or something, just in case
<waddlesplash>
but, app_server should detect HiDPI displays and guess a scale factor if there's no settings anyway
<nephele>
Anyhow: I changed the Scrollbar arrows to use control highlight in my decorator and i think this looks a lot better on dark and light mode, should I submit this change to haikudecorator?
<PulkoMandy>
I'm pretty sure you can find your way to "boot to desktop" and open appearance from there?
<waddlesplash>
yeah, or that
<nephele>
(only problem is webkit refuses to use the proper method and just does something else, but I will fix that :D)
<waddlesplash>
well anyway I need to work on the scaling changes
<waddlesplash>
basically, introduce PixelDensity to BScreen properties
<nephele>
PulkoMandy: depends. If the text and controls is too small that may be problematic
<waddlesplash>
round 0 can have PixelDensity get "baked in" to font size, I suppose, and slowly we make fonts PixelDensity-aware
<nephele>
for me atleast light mode is problemtic in itself though *shrug*
<nephele>
waddlesplash: what about your idea to have some more "sizes" of the ui controlled by the controllook?
<PulkoMandy>
I still don't understand the need for a separate pixel density but I guess I never will so there is no need to discuss it again
<waddlesplash>
yes, I did some poking around
<nephele>
font sizes still force sizes for many controls, and many depend on this indirectly. I don't think we should change this
<nephele>
PulkoMandy: iirc the only reason for a pixel density is to make font sizes be predictable "in the real world" that it has the same physical size for the same font size
<waddlesplash>
the other major argument is: multiple displays
<nephele>
Honestly with how badly monitors report DPI i think this is a terrible idea
<nephele>
I don't see how multiple displays affect this at all honestly
<waddlesplash>
nephele: read the mailing list thread if you've forgotten the arguments
<PulkoMandy>
I think my displays don't have enough DPI difference to justify the need for this
<PulkoMandy>
and I do want smaller fonts on smaller displays usually anyway
<waddlesplash>
well, if you have a HiDPI display and a non-HiDPI display connected to the same machine...
<PulkoMandy>
yes, I don't, everything here is 1080p now
<waddlesplash>
well, I do :)
<nephele>
waddlesplash: I am unconvinced still, i don't see the point of making it go from "font size" to "font size + specific setting" since... you still base everything on the font size
<waddlesplash>
1366x768 laptop, 4K monitor
<nephele>
but now its two variables
<PulkoMandy>
nephele, it makes sense to handle the screen density in multiple displays case still
<nephele>
this changes nothing about the fact that you have to have one font size per display
<waddlesplash>
PulkoMandy: actually you already pointed out a case where you don't want the font size coupled to the UI size: you use < 12 pt fonts, but you don't want < 1x UI
<PulkoMandy>
yes, but we already do that and it works great as it is
<nephele>
The font size is not ment as an absolute "scale factor" for the UI
<waddlesplash>
PulkoMandy: okay, but you can't imagine the opposite case?
<waddlesplash>
or, maybe someone uses < 12pt fonts and does want a smaller UI?
<nephele>
It's just by it's very nature of most stuff beeing test forcing the layout of many things
<nephele>
waddlesplash: no
<nephele>
if they want that they need to write a new decorator
<nephele>
HaikuControlLook can't support this
<PulkoMandy>
waddlesplash, yes, but my problem is having two settings, I now have a 2D space of possible settings values
<PulkoMandy>
which is a lot more complicated to get right for me as a user
<waddlesplash>
no, it isn't
<PulkoMandy>
and a lot more complicated to test for me as an app developer
<waddlesplash>
basically: don't touch font size unless you really Want To
<waddlesplash>
change Density values instead
<waddlesplash>
PulkoMandy: it's already possible for people to use fonts or languages with radically different metrics
<nephele>
So, you are telling me to not change the font size, but rather change the font size size...?
<waddlesplash>
you can't test every font or every possible metric
<PulkoMandy>
so there's a setting I'm not supposed to touchM
<PulkoMandy>
so basically there is still only one settingM
<PulkoMandy>
?
<waddlesplash>
here's the simple fact: 1. there's lots of places where we have factors related to scaling which are only loosely connected to the font size
<nephele>
I don't get this either, what is the point of making it a new setting if it isn't a new setting and behaves like the old one
<waddlesplash>
just search for all the places we do ...Size()/12
<nephele>
waddlesplash: we went over this, there are a miniscule ammount
<waddlesplash>
there's now more than there were before
<nephele>
it's like 8 places where this is done, and most of those are irrelevant and can be replaces
<waddlesplash>
because I just added one in that commit
<waddlesplash>
there's also the matter of ported toolkits which ONLY take a scaling value, so we are simply always going to have /12 somewhere
<nephele>
Yes. why? the right solution would have been to let the decorator decide this
<waddlesplash>
the decorator does decide...
<waddlesplash>
it decides by doing /12
<nephele>
Then there is no problem
<nephele>
it's just an implementation specific value of the decorator or controllook then
<nephele>
if you need a different scaling you can adjust the decorator or controllook
<waddlesplash>
okay, but say I want to use a font that doesn't look so good at 12 pt, it looks much better at 13pt
<nephele>
So... use it at 13pt
<waddlesplash>
well, now my whole UI is rounded off oddly
augiedoggie has joined #haiku
<nephele>
No, it shouldn't be
<waddlesplash>
well, it's going to use a scaling factor of 13/12, that's a little odd yes?
<nephele>
If you produce an ugly rendering then fix it.
<waddlesplash>
okay, so how can I fix it?
<nephele>
This doesn't change if you use a scaling factor for the scaling factor
<waddlesplash>
1. decide that 13pt is close enough to 12pt that we don't scale at all
<waddlesplash>
2. round 13pt up to the next multiple of 25% because it's bigger than 12pt
<nephele>
Yes, for example. like we decide not that <12pt is close enough to 12pt
<nephele>
now*
<waddlesplash>
3. have a separate setting and use that instead
<nephele>
the seperate setting would have the exact same problem, you have gained nothing
<waddlesplash>
nephele: so why can't I have 8pt-sized UIs? someone doesn't like it, but I do, so why can't I use that?
<waddlesplash>
no?
<nephele>
the rendering needs to be controlled precisely
<waddlesplash>
yes, exactly
tuaris has quit [Read error: Connection reset by peer]
<waddlesplash>
so I can use a 13pt font but have the same spacing metrics and the like as if it was the 12pt default font
<nephele>
we can't "just" scale it without thought, irregardless of whether this is based on the font size or some other metric
<nephele>
Which you get now. already.
<waddlesplash>
no?
<nephele>
the spacing remains the same, it is not scaled
<waddlesplash>
it will use 13/12 scaling
<waddlesplash>
no, spacing is already scaled
<nephele>
No, it's hardcoded values?
<waddlesplash>
at least ControlLook spacing is scaled, etc.
<waddlesplash>
some controls still have hardcoded values, yeah, but this is decreasing
AlienSoldier has joined #haiku
tuaris has joined #haiku
<nephele>
No, i mean the spacing values in the layout kit are hardcoded values
<waddlesplash>
this is what Windows has for per-display settings
<waddlesplash>
macOS has something very similar
<waddlesplash>
so does Linux. Users are used to this, and it's a single setting, easy to change
<nephele>
Yes, that is a *factor* it has nothing to do with pixel density
tuaris has quit [Read error: Connection reset by peer]
<waddlesplash>
okay, ScalingFactor, call it what you like
<nephele>
Our font setting currently is much easier to grasp and much more precise
<waddlesplash>
I still think "pixel density" is an acceptable term
<nephele>
Again, pixel density is a physical property
tuaris has joined #haiku
<nephele>
your "hidpi" is only "hidpi" because it *has* a high pixel density
<nephele>
i cant scale up my ui and claim "thus my screen is hidpi"
<phschafft>
may I interrupt with a question?
<waddlesplash>
okay. "UI Density"
<nephele>
that would be an acceptable term
<nephele>
sure
<waddlesplash>
well, either way, I don't think users want to change font sizes 4 times for every new screen they add
<waddlesplash>
phschafft: don't ask to ask
<waddlesplash>
nephele: so unless you want to make users change font sizes 4+ times(as we currently have 4 font size settings) for every screen, we need 1 per-screen setting
<nephele>
anyhow the control rendering does *the right thing* for font sizes now. I think this is the right way because font size is already what controls 90% of the rendering anyway. and we don't want to scale font sizes fractionally. so your ui scaling factor would then need to ... round to a font size for the font
<waddlesplash>
if we "bake" that into the font size, that's one possible solution, yes
<waddlesplash>
again. we really need to present only 1 option per screen
<nephele>
So what is the problem of simply having a scaling slider in the settings that changes the font size settings?
<waddlesplash>
we currently have 4
<nephele>
you are trying to justify an API decision based on a UI problem
<waddlesplash>
do you want to reduce that to 1?
<nephele>
No
<waddlesplash>
okay. so then how are we going to handle 2 displays that need 2 different font sizes.
<waddlesplash>
either 1) we have a single setting, 2) we have multiple settings
<waddlesplash>
and since this is about screens ... doesn't it make sense to handle in Screen / Workspace preferences?
<nephele>
Add a slider in the UI for font size "scaling"
<waddlesplash>
okay ... and what does that do in API terms
<waddlesplash>
it's a property of BScreen, yes?
<phschafft>
waddlesplash: asked to interrupt. ;) Just for my personal understanding. the pt-scale is about physical size (as in 1pt is so and so much of a meter). and I'm used from Debian that when I show documents in the '100%' zoom level everything in that document is correctly scaled on my screen. so NNNpt is always the same no matter what display I use. Same for things like if you actually have an object set to for example 10cm it is actually 10cm on t
<nephele>
that is, a slider that picks correct font sizes, round it to the sizes. and for the API just continue what we do now, with our 4 font sizes
<nephele>
have a way to have those per screen
<phschafft>
is that also true for Haiku, at least with defaults?
<waddlesplash>
phschafft: this only works if the monitor correctly reports its exact physical size
<waddlesplash>
not all do, or at least, not all we get that information from at present
<PulkoMandy>
most of them report a wrong size, really
<PulkoMandy>
(it goes from slightly off to completely unrealistic values)
<nephele>
phschafft: Well haiku does not respect this at all, which is why we don't refer to it as pt size in the UI i think. It's really difficult to figure out the pixel density without asking users to measure their screen with a ruler
<waddlesplash>
nephele: so, it's a property of BScreen, right?
<waddlesplash>
BScreen.UIDensity or BScreen.FontSize or something
<nephele>
We have 4 font sizes, how could it be a single property?
* phschafft
nods to nephele as that answers his question completly.
<PulkoMandy>
there is one BScreen instalce per display
<waddlesplash>
nephele: because there's only one slider
<PulkoMandy>
well, there should be at least
<waddlesplash>
1 property in the UI should be 1 property in the API
<nephele>
waddlesplash: yes and? this should never leave the appearence settings
<PulkoMandy>
and you can already query the DPI from EDID there
<waddlesplash>
nephele: that's where we strongly disagree
<nephele>
it should *actually* set the correct font size
<waddlesplash>
there are LOTS of applications that really want that factor
<nephele>
that way users can properly set them
<waddlesplash>
one way or another we have to give those applications SOMETHING
<waddlesplash>
so, why not give them *the exact value the users set*?
<phschafft>
waddlesplash: yes. that is required. and if no value or a wrong value is reported you need to override it. also the value might not be perfect (-> calibration). But all that said I never had a monitor reporting something that was worse than 1% off. maybe just luck.
<PulkoMandy>
maybe I just buy cheap and broken things then :)
<nephele>
I don't care about ported apps, you can expose them some magic value if you want. but we should not do this for our UI but do it properly, we don't really do fractional scaling...
<waddlesplash>
we absolutely do fractional scaling
<waddlesplash>
18pt font size = 150%
<waddlesplash>
that's fractional scaling, it works, and I use it all the time
<PulkoMandy>
we do fractional scaling but round it to pixels so it doesn't look all blurry
<waddlesplash>
it's highly annoying how most applications from other OSes barely support it
<nephele>
No, we don't. 18pt font is not guranteed to be 18pt, as mentioned before
<waddlesplash>
what?
<nephele>
the font can have different metrics
<PulkoMandy>
you don't use the words "fractional scaling" for the same meaning
<waddlesplash>
18pt font is really 18pt...
<PulkoMandy>
please agree on what it is before continuing the discussion :)
<nephele>
18pt noto might be a different height if you retrieve it as the baseling and height, which we use a lot in UI calculations for layouting
<waddlesplash>
yes
<waddlesplash>
not sure what your point is
<nephele>
18pt noto and 18pt unifont will *NOT* produce the same layout most likely
<waddlesplash>
sure, that's expected
<waddlesplash>
but the point is, "points" is a value NOT corresponding directly to pixels
<nephele>
yes, so it's not really scaling
* ermo[m]
notes quietly that although it is the standard metric, the "point" is not an exact metric, because different fonts can have different physical sizes even when they are asked to render at a given, fixed point size -- all else being equal.
<waddlesplash>
hence the big argument I made last fall is, points are points and pixels are pixels
<nephele>
indeed, points refers to a physical size. which we completely ignore
<waddlesplash>
and phschafft points out, we shouldn't maybe ignore that
<waddlesplash>
and in fact, I agree, because I made this same argument before
<PulkoMandy>
with the current code, the font will use whatever size it uses, and then the borders/margin/padding around that will be exactly the same for any font that says it's 18pt
<waddlesplash>
we shouldn't ignore that, we should in fact respect it, but we need to allow users some leeway in respecting it
<waddlesplash>
ermo[m]: yes, but the point size is a "base metric" the font does compute everything else from
<nephele>
I don't really agree. I quite like that 18pt rendering gives the same rendering on any haiku
<nephele>
we don't work with paper here
<waddlesplash>
we are rendering to a physical medium
<PulkoMandy>
we do, you can use BView for printing too
<waddlesplash>
and that too
<PulkoMandy>
(and there you'd rather not ignore the DPI or your 12pt font will look absurdly tiny)
<nephele>
(reminds me that the printer test page is kind of broken for rendering...)
<PulkoMandy>
yes, that's somewhat intentional, it shows all the bugs in BPicture archiving/unarchiving
<nephele>
Okay. But printing to a paper would not take the "UI" font size into account, ever?
<nephele>
PulkoMandy: it also randomly uses system colors... but nobody noticed because standard document color is white :P
<ermo[m]>
can I interject something that may or may not be relevant? I have vision issue that requires me to more or less double the point size to get fonts which are of a readable physical size for me. My problem with Haiku specifically, is that this also makes GUI elements (way) larger than they need to be for me to be able to distinguish and use them. It'd be cool if there was a way to adjust GUI elements separately from font (point) size.
<PulkoMandy>
no, that's why the UI scaling is a BScreen property and probably each BPrintJob should provide its own DPI as well, and things should be scaled according to that too
<nephele>
Yes. that makes sense
<nephele>
ermo: the problem with that is a bit that *most* ui elements are directly related to the font size, for example buttons directly inherit their size etc
<waddlesplash>
nephele: see ^^ Another user requesting "ui element scaling" separate from font size
<waddlesplash>
nephele: but we don't actually NEED to scale the padding/spacing from that
<waddlesplash>
we do, at present, but it's not a requirement and would be trivial to decouple
<nephele>
but for this problem specifically we put all of this stuff where we *can* into the decorator or controllook
<nephele>
waddlesplash: yes so? I agree we should provide a way for this. But i don't agree with your api
<waddlesplash>
given the number of people who request it AND the need to put things in BScreen AND the fact that "pts" is a physical size AND ... it only makes the most sense to decouple the two
<PulkoMandy>
well, I'm still confused because clearly we are going to have two settings (font size and "ui density" or whatever), but earlier you said we wouldn't
<nephele>
No, we don't ever treat it as pts for our UIs, and we realistically can't with how shoddy monitors fo this
<waddlesplash>
PulkoMandy: ?? sorry, I guess I was confusing then, because I've always advocated 2 settings
<waddlesplash>
nephele: we can ... as long as we don't use the monitor's reported value
<PulkoMandy>
yes, you said two settings, one of which I'm not supposed to change
<PulkoMandy>
so I'm confused :)
<waddlesplash>
no, you can change it?
<nephele>
Which means we don't have any info whatsoever waddlesplash
<waddlesplash>
you don't touch it first
<ermo[m]>
waddlesplash: To be clear, if I had a way to set the DPI and then set the normal font size (12pt or w/e is the default), then I'd like to be able to scale that up to 300% independently of the GUI elements, such that e.g. GUI elements could be, say, 150% (1.5x * the size they would have at 12 pt with the current font) while the fonts are 200% (2x the 12pt size)
<waddlesplash>
nephele: that's not true.
<ermo[m]>
Just to write it out as a suggestion.
<ermo[m]>
but I get that there are probably bigger fish to fry.
<waddlesplash>
ermo[m]: yes, that's something I agree we should support
<waddlesplash>
and indeed would be supported by my proposed API/UI for this
<PulkoMandy>
yes, so we're back to what I was saying earlier, I have a 2D space of possible settings, which is annoying to configure (at least if both settings are free sliders) and annoying to test all cases
<nephele>
PulkoMandy: one way to solve this would be, in my mind, a slider that provides the magic value waddlesplash wants, and have this change the 4 font sizes directly below it, so you drag this and it simply scales the values directly. instead of stuffing this in an api and making the values confusing
<PulkoMandy>
I guess I would go with font size, and a compact/normal/extra spacing toggle, or something like that
<waddlesplash>
nephele: did you read my proposals on the maling lists? what I suggested was
<waddlesplash>
PulkoMandy: that won't support the case ermo[m] (and many others on the forum) ask for, where things are more than just "compact" or otherwise
<waddlesplash>
nephele: look, when you create a FreeType font object, you provide both a point size, and a DPI, and get out pixels
<waddlesplash>
right now, we specify pt size and we hardcode DPI
<waddlesplash>
I am proposing we don't hardcode DPI and somehow expose that in BFont, but with values auto-populated from BScreen in most cases
<nephele>
ermo: as a i said, most gui elements simply can't be scaled independently. It probably makes sense as pulkomandy suggested to have a specific option to adjust the margins we can adjust
<nephele>
but this wouldn't help for example if you still perceive buttons as too big
<waddlesplash>
nephele: ermo[m] is specifically asking for metrics like spacing not to be scaled along with the font size
<nephele>
waddlesplash: yes, and I don't agree. you are trying to throw two issues together
<waddlesplash>
this is perfectly doable, all other OSes can do it, so can we
<waddlesplash>
nephele: the two issues are solvable with the same solution, and other OSes do
<nephele>
No, it works *horrible* on those other OSes
<nephele>
implemented exactly like that
<waddlesplash>
no
<waddlesplash>
it works *GREAT* on Windows
<nephele>
our UI works because we control the rendering precisely
<nephele>
No it doesn't
<waddlesplash>
... with *native Windows applications*
<waddlesplash>
it doesn't work great with Qt apps on Windows but that's Qt's fault
<nephele>
it continously destroys *native* windows applications that can't be used anymore because it scales them randomly
<waddlesplash>
Windows-native applications, especially UXP applications, work almost perfectly with this model
<nephele>
for example fullscreen apps only show the upper left corner
<waddlesplash>
nephele: it doesn't scale them "randomly"
<nephele>
It does from the users perspective
<waddlesplash>
yes. Windows is a giant mess of obsolete APIs. however, the simple fact is, they got the newest APIs related to fontsize+DPI correct
<nephele>
and the values windows provides for scaling are horrible too, they are always too big or too small
<PulkoMandy>
Windows also does strange things if you have an app in-between two screens
<waddlesplash>
you can't judge Windows' features here based on the older applications that don't use the new APIs
<nephele>
if you have it inbetween two screens it will fractionally upscale one side to match the DPI
<waddlesplash>
no, you mean it will do a bitmap scale
<waddlesplash>
that's not a "fractional scale", that's a bitmap scale
<PulkoMandy>
well, it's both
<waddlesplash>
in fact this is really the only reasonable thing you can do besides drawing everything twice
<nephele>
Those two terms are interchangeable for all other toolkits that do this
tuaris has quit [Read error: Connection reset by peer]
<PulkoMandy>
it is not at all a reasonable thing to do
<waddlesplash>
PulkoMandy: well, "Fractional scaling" in this space generally means anything not an integer
<PulkoMandy>
yes
tuaris has joined #haiku
<waddlesplash>
ie. Retina really only works with integer multiples
<PulkoMandy>
and integer bitmap scaling works fine, but fractional bitmap scaling is a blurry mess
<waddlesplash>
whereas 4K monitors generally fall into the 1.5x region, doesn't work great with macOS' model
<waddlesplash>
ah. indeed yes
<PulkoMandy>
fractional scaling on vector will be ok (possibly a bit tricky)
<waddlesplash>
nephele: anyway please do reread that mailing list thread, because I intend to work on that next week
<nephele>
scaling vectors is fine.
<waddlesplash>
and based on all conversations since then, this one included, I'm inclined to still go with my final proposal there
<nephele>
waddlesplash: why? I don't see how the result will be any different to now
<nephele>
We still don't agree and pulkomandy is still not happy with your proposed UI
<waddlesplash>
then that's fine if you see it that way, it means nothing will be lost :)
<PulkoMandy>
nephele, I can't say if I'm happy or not until I've tried it
<waddlesplash>
but for ermo[m], myself, plenty of people on the forum, etc. it will enable a bunch of things that we very much want
<PulkoMandy>
for now I just don't really understand all of it
<waddlesplash>
well, you're not entirely wrong it will be a "2D space", but it won't be that "2d"
<waddlesplash>
since fontsize will be derived from the DPI factor
<nephele>
waddlesplash: "it means nothing will be lost :)" I'm sorry, maybe I am misunderstanding you but i read this sentence in the context you posted it as "Your input is irrelevant"
<PulkoMandy>
it really depends what and how is exposed in the UI and what can reliably be derived from EDID
<waddlesplash>
no?
<waddlesplash>
nephele: no, it means, "good, your use-cases will be handled in the new code and the old"
<ermo[m]>
<waddlesplash> "nephele: the point is this: we..." <- This would work for me. Particularly if I could _also_ 3. use the "pixel density" to "scale" the UI elements per-screen (just like I can scale the font sizes per-screen).
<waddlesplash>
nothing is getting lost
augiedoggie has quit [Ping timeout: 480 seconds]
<nephele>
Well, i said i still don't argree with you, and I don't think it will work properly and introduce needless complexiy
<waddlesplash>
not sure how it will
<nephele>
and your response to that is "so nothing will be lost"
<waddlesplash>
because 90% of code will not be any more complicated
<waddlesplash>
and in fact lots will be less complicated
<waddlesplash>
but, it's true that a lot of what I'm talking about here will introduce some complexity ... because of multi-screen varying-DPI support
<waddlesplash>
(which I note, I don't think X11 handles at all)
<nephele>
* You want to use DPI scaling based on the monitor: yet have no way to obtain this scale
<nephele>
Okay. from the top
<nephele>
* Additionally you want a user scaling value
<nephele>
* AND the font size
<nephele>
that is simply too much indirection and complexity
tuaris has quit [Read error: Connection reset by peer]
<waddlesplash>
no
<waddlesplash>
1 & 2 in your list will be one value in Screen preferences
<ermo[m]>
nephele: I would be fine with being able to manually set DPI per screen
<waddlesplash>
we might fetch it from the monitor by default but users can change it, if the monitor reports it wrong
<nephele>
So, in other words you still don't care about PT size beeing acurate
tuaris has joined #haiku
<nephele>
you said before you want to respect it
<waddlesplash>
I do care. but the monitor doesn't report things automatically
<nephele>
this is not possible if it's a user setting
<ermo[m]>
(particularly if some lazy manufacturer sets the wrong physical size, which means the DPI will also be wrong)
<waddlesplash>
nephele: I assume users know more about their screen size than their monitor
<waddlesplash>
for instance what if they are using some huge projector?
<nephele>
ermo: dpi is a physical property of the screen though, if it is exposed users *will* treat it as a "scale" factor
<nephele>
and this will *always* destroy the PT scale again
<waddlesplash>
... that's why I mean to call this "pixel density"
<nephele>
so if we go this way we still don't respect pt values, so we shouldn't pretend to
<waddlesplash>
which AFAICT is not a term excusively meaning "screen DPI"
<PulkoMandy>
"pixel density" is not a great name, I would go with "ui density" or something like that
<PulkoMandy>
since in the end this has nothing to do with pixels, except we use the DPI initially to set it
<nephele>
I agree
<waddlesplash>
well, it's being used to compute pixel values most of the time hence the name
<waddlesplash>
what do you suggest?
<ermo[m]>
I honestly think it's as simple as having a paragraph and a widget on the website that can compute a correct DPI if the autodetected one is faulty
<waddlesplash>
"UIDensity" is a bit of a mouthful
<waddlesplash>
"InterfaceDensity" sounds a bit nicer?
<ermo[m]>
PPI is the standard name AFAIK?
<nephele>
ermo: the only way to calculate the DPI is taking out a ruler
<waddlesplash>
PulkoMandy: I don't know what would sound good here really, "Pixel density" in Screen preferences sounds obvious as to what it means
<nephele>
waddlesplash: BWindow.Density sounds fine
<waddlesplash>
at least to me. "Scaling factor" I guess works too
<waddlesplash>
nephele: this isn't a property of BWindow but BScreen
<waddlesplash>
just "Density"? ok
<nephele>
Pixel density is not at all what this is, so please don't call it that
<PulkoMandy>
yes I guess just Density in the appearance preferences will be self-explaining enough
<waddlesplash>
except it is
<ermo[m]>
What's the unit?
<nephele>
because we don't care about pixels
<ermo[m]>
for this hypothetical input box
<waddlesplash>
ermo[m]: it's a float multiplier, no unit
<nephele>
o..1
<nephele>
0..1
<waddlesplash>
no
<waddlesplash>
0.25...unlimited (but why would you set it over 4?)
<PulkoMandy>
I agree with nephele, there is a clear definition for pixel density: how many pixels by inch/cm you have
<nephele>
That's what our sliders return though
<PulkoMandy>
and that's a propery of the display that you can't change
<waddlesplash>
nephele: it's not a slider but a spin box, like the font size selectors
<ermo[m]>
waddlesplash: Sorry, did I misunderstand the question? What is this knob supposed to scale?
<nephele>
why?
<nephele>
that UI is horrible for font sizes already
<waddlesplash>
no, it's not
<nephele>
Yes it is
<waddlesplash>
font sizes USED to be drop downs, this was changed to spin boxes by popular demand
augiedoggie has joined #haiku
<waddlesplash>
and indeed I do like them better this way IMHO
<PulkoMandy>
I hate them
<nephele>
I strongly dislike them, why do i have to use my keyboard or press buttons to change a numerical value
<nephele>
I agree that drop downs are even worse though
<waddlesplash>
nephele: add support for the scroll wheel then
<nephele>
please just use sliders
<waddlesplash>
PulkoMandy: why, because you have to use keyboard/mouse clicks?
* ermo[m]
thinks that if this is a scaling thing (that takes PPI and pt size of fonts and scales UI based on those metrics) I would personally much prefer a slider that controls a box value.
<nephele>
they already support the scroll wheel
<waddlesplash>
nephele: I want to be able to type a value
<nephele>
So? add a box next to it
<waddlesplash>
so long as there's some way to reasonably do that, or at least know *WHAT* value I picked
<waddlesplash>
that sounds ... gnarly
<PulkoMandy>
waddlesplash, yes, because it has buttons that are either ridiculously small and hard to click, or are large and just wasting space for no reason
<nephele>
I think normal sliders provide the value by hover?
<ermo[m]>
so that if I type 187%, the box slider will lock to the nearest increment value we support
<nephele>
but then we basically don't use tooltips, ever. maybe we should remove them
<waddlesplash>
PulkoMandy: oh, well, that sounds like a problem with the spin boxes in general
<PulkoMandy>
yes
<waddlesplash>
so, we should fix that :)
<PulkoMandy>
yes, by using sliders instead :D
<waddlesplash>
they're easier to use than Windows spin boxes :)
<waddlesplash>
but I like spinboxes...
<PulkoMandy>
yes, on my request
<waddlesplash>
:(
<PulkoMandy>
initially they had super small buttons like Windows, I asked John to change that
<ermo[m]>
waddlesplash: Do spinboxes allow custom values?
<nephele>
ermo: there is no "nearest increment" in this case, the UI would just scale to what you want, plus some sanity by the controllook to provide a good rendering
<waddlesplash>
ermo[m]: that's what we currently use
<nephele>
lol you can enter negative values
<waddlesplash>
sounds like something worth fixing lol
<ermo[m]>
nephele: well, I was thinking you could only write whole numbers in percent
<nephele>
No, just remove them and use sliders
<PulkoMandy>
in ACE I have a crazy widget: there's a text box, when you click it you get a popup menu and in the menu there's a single item that's in fact a slider
<nephele>
ermo: uhh
<ermo[m]>
as long as the numerical value is visible
<nephele>
percent is just "/100%"
<PulkoMandy>
I don't know if that will make everyone happy, or everyone angry
<ermo[m]>
and there's a live preview
<ermo[m]>
then I'd personally be happy
<ermo[m]>
(so there's my €0.02)
<nephele>
Yes, that would be fine i think
<PulkoMandy>
I also have sliders that display their value on the knob
<nephele>
PulkoMandy: i think we have enough space to not need popup menus?
<ermo[m]>
Would displaying it above the knob in a tooltip be an option?
<nephele>
sliders that display their value on the knob could be cool
<PulkoMandy>
in Appearance, yes, in ACE definitely not
<ermo[m]>
i.e. if I mouse over the knob, the value shows up
<nephele>
ermo: I think this is a bit of a meh solution
<PulkoMandy>
ace.cpcscene.net if you want to get an idea of the GUI, but images are from the MorphOS version
<nephele>
because, while working, users on Haiku simply never expect tooltips we almost never use them
<nephele>
so this would be bad to discover
<waddlesplash>
PulkoMandy: as long as I can manually type/copy a value from the text box, I'd be happy
<ermo[m]>
when I drag the knob, I am per defintion mousing over the knob, so the value in the tooltip would be visible during adjust ment.
<ermo[m]>
s/adjust ment/adjustment/
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ermo[m]>
(just to think through the tooltip use case)
<nephele>
sticky tooltips are broken and they havent been fixed for over two years :P
<waddlesplash>
PulkoMandy: so, it gets my vote :)
<waddlesplash>
Plus it's another way we'd be "quirky" so that's another plus :D
<nephele>
but In that case I don't see the point over just displaying it normally
<ermo[m]>
waddlesplash: the reason a slider (with an input text box next to it that is live-updated) could be nice is that it shows the visual relationship between gui element and font element size as a ratio
<waddlesplash>
PulkoMandy: nephele: the other question is, in BFont, what should this property be called
<PulkoMandy>
well now I have to share my code where I put a slider in a BMenuItem and get it past Haiku code review standards? not sure that will work :p
<waddlesplash>
shouldn't it be called "PixelDensity" in that API?
<waddlesplash>
PulkoMandy: I'll review it :D
<waddlesplash>
if you can get jscipione and/or stippi to OK the UX anyway
<nephele>
Well, I like the idea of the slider thumb displaying the value
* ermo[m]
has no sacred cows when it comes to UX/UI
<nephele>
I still want to add a relative scrollbar to Haiku, heh... maybe even as an option to webkit...
<PulkoMandy>
yes I should upstream that too (optionally, because there are places where I intentionally use sliders without values, for example in screensaver settings where I have sliders that go from "few" to "many" to configure some setting of the screensaver effects)
augiedoggie has quit [Ping timeout: 480 seconds]
<nephele>
waddlesplash: for BFont? hmm, I don't think so. While you intend to pass it to freetype as a *scaling* factor I don't think it makes sense to call tihis PixelDensity because it *still* isn't based on it
<waddlesplash>
but that's what it is?
<PulkoMandy>
well I'll add this to the TODO list... after I finish messing with userlandfs and fuse I guess
<waddlesplash>
how "dense" are the "pixels"
<nephele>
No, it isn't. It's a property of the monitor, not of the font
<nephele>
and again, a physical property, not a setting
<PulkoMandy>
there are a variety of reasons to change this setting independently from the actual pixel density
<waddlesplash>
nephele: freetype literally takes DPI as one of the *required* parameters
<waddlesplash>
I am saying we expose this in BFont, somehow, probably not as "DPI" but as some value we convert to DPI when we pass it to FreeType
<nephele>
yes, and we ignored it up to now. In the future we will feed it a value that is unrelated to the pixel density. what is your point?
<waddlesplash>
so, what do we call that? Because, FreeType calls it DPI
<PulkoMandy>
eyesight, personal preference, the distance from the monitor to your eyes, maybe lenses in your VR headset
<waddlesplash>
so, why don't we call it "pixel density" because it's just "unit-less DPI"
<nephele>
Either you call it scalingFactor or you call it FreetypeDPI
<waddlesplash>
no
<PulkoMandy>
yes, we will be lying to freetype
<waddlesplash>
there's other font backends besides FreeType which do this
<waddlesplash>
we shouldn't call it DPI because it isn't that
<nephele>
Same reason we shouldn't call it pixel density
<waddlesplash>
it's, instead, an arbirary unit expressing, in fact, the "density" of "pixxels"
<PulkoMandy>
call it density or renderdensity or something like that?
<waddlesplash>
nephele: "pixel density" is the generic term for this, it doesn't refer to any specific value
<nephele>
No, it's an arbitrary unit expresisng the scale factor of the font
<waddlesplash>
it doesn't have a unit
<waddlesplash>
if it had "inches" or "millimeters" then it'd be saying something about the display
tuaris has quit [Read error: Connection reset by peer]
<nephele>
fonts don't *have* to be rendered to pixels at all
<nephele>
what about your printer example
<nephele>
how does claiming it's a pixel density make any sense?
<nephele>
It simply isn't that
<PulkoMandy>
to me "pixel density" is "how many pixels by unit of length", so, in a way, you can change the "unit" in that equation and that changes the "density", but that's not a great way to think about it
<waddlesplash>
"DensityFactor"?
tuaris has joined #haiku
<waddlesplash>
that way we can then call it the same thing in BScreen and BFont, actually
<nephele>
I agree with Pulkomandy pixel density is confusing
<nephele>
DensityFactor feels redundent to me Density would be fine. but if you feel it is needed then add it
<PulkoMandy>
we have BView.SetScale() and not BView.SetScaleFactor()
<waddlesplash>
nephele: every single float in this header is some concrete value (pixels, pints, etc.)
<ermo[m]>
is DisplayScaling an option?
<ermo[m]>
with the factor being implied?
<nephele>
Density already implies factor to me
<nephele>
DisplayScaling would not make any sense as a member of BFont
<PulkoMandy>
yes, or RenderScaling because "display" on a printer would be a bit unusual
<ermo[m]>
RenderScaling. I like that. A lot.
<nephele>
RenderScale?
<waddlesplash>
PulkoMandy: yes, because scale can only be a factor, right?
<ermo[m]>
yeah, or RenderScale
<nephele>
RenderScale or RenderScaling seems fine to me
<waddlesplash>
hmm. I guess in printing situations, Density might be real DPI?
<nephele>
it seems to acurately represent what this is about
<ermo[m]>
waddlesplash: yep
<waddlesplash>
in BFont that is
<ermo[m]>
oh
<ermo[m]>
so DisplayScaling or RenderScaling get my vote (with DisplayScale or RenderScale a viable option)
<waddlesplash>
hence, we should just call it Density, and say "when using pixel coordinates, this is a factor, when using physical coordinates, it is in device units"?
<PulkoMandy>
waddlesplash, it depends, you could print the same document on A3 and A4 paper and then you will use a different "density"/"scale"
<waddlesplash>
whatever we do, I just want the values to have the same name in BScreen and BFont
<nephele>
RenderScale is fine then, i think
<ermo[m]>
RenderScale
<waddlesplash>
so, whatever we choose has to work for both
<waddlesplash>
nephele: except BFont is also used for printing
<waddlesplash>
not just rendering.
<ermo[m]>
Because you can render both to a display and to a piece of paper
<PulkoMandy>
(don't know how that'd work in US paper size, but in europe, A3 and A4 and the other all have the same aspect ratio and size exactly divided by 2)
<nephele>
waddlesplash: i don't see how that conflicts
<nephele>
it is first rendered, then printed
* waddlesplash
prefers just Density
<waddlesplash>
no?
<nephele>
the monitor is the same, it is first rendered then displayed
<waddlesplash>
you can print to an EPS or PDF, say
<waddlesplash>
it's not "rendered" at all then but just output to a vector format
<nephele>
how is that not rendering?
<PulkoMandy>
you can send the postscript code to the printer and let it figure things out, too
<PulkoMandy>
but that's a story for another day
<nephele>
I don't think we support that?
<PulkoMandy>
the Be API does, but libprint doesn't
<ermo[m]>
The reason I like "RenderScale" is that it implies to me that it takes an input with a given size and then Renders it to whatever scale I've set.
<nephele>
anyway, if we send postscript this doesn't seem to be related to BFont at all
<PulkoMandy>
depends what you put in the postscript
<nephele>
waddlesplash: anyway, in my mind Density or RenderScale is both fine
<ermo[m]>
So if the input is physically 12pt fonts and I have a RenderScale set to 150% (or 1.5x or w/e), I'd expect the font to be rendered at an effective 18pt whether it's on a piece of paper, a PDF or a display.
<nephele>
I guess we can all have a blast bikeshedding this on gerrit
<nephele>
ermo: it won't be though :)
<ermo[m]>
just explaining why I like the word
<waddlesplash>
unless someone has some staunch objection I'm just going with Density
<nephele>
freetype won't produce the same rendering if you give it (12; 96 * scale) or (12 * scale; 96)
<waddlesplash>
works for BScreen and BFont
<ermo[m]>
what does a density of 200% mean?
<nephele>
it means 2
<ermo[m]>
is it 2x denser?
<waddlesplash>
yes
<ermo[m]>
or 2x less dense?
<waddlesplash>
no, 2x denser?
<waddlesplash>
how would it be less?
<waddlesplash>
err. why would that mean "less"?
<ermo[m]>
so if I have a 12pt font and a density of 200%, I'd get 6pt?
<nephele>
waddlesplash: i think ermo means in the way if you say, a rock is more dense there is more mass in it... so the stuff is *closer* together
<waddlesplash>
no?
<ermo[m]>
more dense, less dense
<nephele>
if i say it is "densely packed" there are more UI elements in less space
<ermo[m]>
but that's the actual definition of density?
<waddlesplash>
nephele: the density is a factor of the screen
<waddlesplash>
i.e. density ... of pixels
<ermo[m]>
higher density = more elements in a volume or area
<nephele>
this is a linquistic question waddlesplash
<nephele>
about the variable name
<nephele>
ermo expressed confusion that a higher value would make stuff further apart
<nephele>
which makes sense from an API perspective but is a bit confusing linquistically
<PulkoMandy>
yes for me "higher density" means more elements per area
<PulkoMandy>
so, smaller ui, or smaller pixels
<nephele>
because "more dense" would imply "more tighly packed together"
<ermo[m]>
nephele: when "higher density" typically means "more closely spaced"
<waddlesplash>
well I guess it's arguable that we can use "scale" in BFont to match BView
<waddlesplash>
in that case the BScreen field can be named equivalently
<PulkoMandy>
but smaller ui goes in opposition to smaller pixels usually
<waddlesplash>
BScreen::Scaling? or BScreen::Density? -> BFont::{Set}Scale
<waddlesplash>
or will that get confusing with BView::Scale and BFont::Scale meaning totally different things
<nephele>
yes
<waddlesplash>
hmm actually they aren't different things really
<nephele>
I think they are though
<nephele>
atleast for BFont
<waddlesplash>
well they're two different values
<nephele>
because there are now *two* variables that play into this now
<waddlesplash>
but they're set in two different places, so...
<nephele>
but for BView there is one
<nephele>
and a BFont in a BView is then subject to all three...
<waddlesplash>
more than that, because there's affine transforms don't forget
<nephele>
maybe RenderScale is good then
<nephele>
but, i'm not sure that resolves all the ambiquitiy
<waddlesplash>
... BView::Scale is the "rendering scale" yes?
<waddlesplash>
that doesn't resolve the ambiguity at all
<waddlesplash>
this is why "PixelDensity" makes the most sense :D
<nephele>
It atleast makes it clear that it's not precisely the same *shrug*
<nephele>
No, PixelDensity is plainly wrong
<PulkoMandy>
there isn't really an ambiguity here, they do the same thing
<PulkoMandy>
and yes, pixel density is either wrong or extremely confusing
<waddlesplash>
so, we are "measuring" pixel density" without "measuring" it
<waddlesplash>
hence the generic term without the units
<waddlesplash>
but I agree with PulkoMandy, they do the same thing hence there's not an ambiguity merely more than one place to set it
<PulkoMandy>
yes, "pixels per some fixed unit of distance"
tuaris has quit []
<PulkoMandy>
in your case you are changing the unit of distance, not the number of pixels
<waddlesplash>
hmm
<nephele>
>[22:44:28] PulkoMandy: there isn't really an ambiguity here, they do the same thing
<nephele>
Then call both of them Scale?
<nephele>
ah, a +2 on my build fix, too bad i can't submit it :D
<nephele>
(no clue what musiccollection does though... it looks like just a list with a search field)
<PulkoMandy>
I think you need mp3 files with xattrs to use it
<PulkoMandy>
it's meant to be a bit like itunes, type an artist name, get a mediaplayer playlist
<nephele>
uff. almost everything I have is opus or webm containers
<PulkoMandy>
waddlesplash, maybe call it PixelsPerPoint or something
<PulkoMandy>
nephele, well that should work too if you have xattrs set
<PulkoMandy>
there was a tool to convert id3 tags to xattrs, I think it's ArmyKnife?
<nephele>
Uhh, recompiled it with a new checkout... now it's broken again... missing symbol __ctype_b_loc... Oh, i guess I have to update my haiku fully for this :D
<waddlesplash>
PulkoMandy: if I do BView.SetScale, then BView.StringWidth, what do I get back?
<waddlesplash>
do I get back, pixels straight up? do I get back pixels multipled by whatever the scale is I set?
<waddlesplash>
PulkoMandy: cept this isn't that, because we multiply other things to get pixels per point
<nephele>
That reminds me that I should report that sound is broken on my machine... I have a 5.1 stero connected and no audio remapping, but it doesn't even give audio through the "normal" one that would go to my front left right speaker
<waddlesplash>
really pixels per point is like 1.25 or seomthing
<ermo[m]>
waddlesplash: is this quite the can of worms? 'cause it kinda sounds like it! ^^
<waddlesplash>
nephele: not fixed with last month's or the month's before's HDA changes?
<waddlesplash>
ermo[m]: oh you have no idea :)
<ermo[m]>
... clearly not!
<nephele>
lets see 56241, let me try to play something
<ermo[m]>
but cheers for taking it on
<waddlesplash>
I've worked with some aspects of unit conversion stuff before, it quickly gets VERY complicated
<nephele>
Yes, it's a can of worms. I still think multiplying the font size itself, or adjusting it with the slider would be much easier
<waddlesplash>
PulkoMandy: perhaps the distinction should be BFont::SetScaling vs. BView::SetScale
<nephele>
waddlesplash: nothing with this hrev :/
<waddlesplash>
when you set BView.SetScale, *everything* scales
<nephele>
maybe i need to update?
<waddlesplash>
nah I think that's more than new enough
<waddlesplash>
PulkoMandy: but BFont::SetScaling, all the coordinates you get back from e.g. GetHeight are according to the "Scaling"
<waddlesplash>
make sense? or is this too stuble
<waddlesplash>
subtle
<waddlesplash>
then we have BScreen::Scaling too
<nephele>
Anyway, to properly use this setup I need to have jack remapping. Which on Ubuntu linux was installing some archaic voodoo tool that changed alsa settings. so i know it works on my system, i just hope I can get a proper GUI on Haiku xD
<waddlesplash>
despite how subtle this is I think I like it best
<waddlesplash>
nephele: if you want to rewrite the HDA driver, it could use it :D