<marzzbar>
I don't suppose there's a way to load the entire LiveUSB into RAM when booting?
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
bjorkintosh has joined #haiku
<Skipp_OSX>
it's probably the icon cache...
<waddlesplash>
Skipp_OSX: most of the icons should be duplicates...
<waddlesplash>
marzzbar: don't think so, but why would you want to?
<Skipp_OSX>
lotta files on this BeOS vm... 19M used so far, whose taking bets on when I close if it will go down or not?
<marzzbar>
Trying to install Haiku on this netbook, but it's crashing after a random period of time. Was wondering if it could be something to do with trying to read from the USB after booting so wanted to see if I could rule it out. I could very well be on the wrong track though
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
<Skipp_OSX>
25064 KB (25M) used, yep, same bug on BeOS R5
OscarL has joined #haiku
<OscarL>
I begin to wonder if using a hammer on the Atom N2600 netbook wouldn't be better than dealing with its crazy behaviour with Haiku.
<OscarL>
booting into the "live" desktop from USB drive with beta5-TC0 (BIOS mode)... all seems fine. Booting same install from HDD via Boot Manager... crazyness ensues (system starts ok, but gets progressively laggier).
<OscarL>
Haiku loader from the USB drive cannot see the HDD (in BIOS mode), so can't use that method to boot from HDD.
<marzzbar>
OscarL: Whoa that's weird, the netbook I'm trying to get working with Haiku is also an Atom N2600 netbook
<OscarL>
:-)
<OscarL>
when using UEFI... boot loader from USB drive ONLY sees the Haiku install from the HDD... booting that way... doen't seems to solve the progressive? random? lags.
<OscarL>
Now I booted that way, but with IO-APIC disabled... will see how long it lasts.
<OscarL>
Tried disabling SMP... system froze after a couple of minutes.
<OscarL>
marzzbar: this machine has given me countles issues while trying to boot Haiku on it... Yesterday, somehow started working (after "Nth" attempt while fiddling with BIOS options too).
<OscarL>
yesterday... it worked *almost* too good to be true. Today... made me grow some new gray hairs.
* marzzbar
is glad and also somewhat dismayed that someone else is having issues with the same processor
<OscarL>
To sumarize... Use beta5 TC0, from USB drive. On BIOS setup: UEFI disabled, Legacy boot enabled, Disabled SD-Card boot, enable USB BIOS support (not exact wording).
<marzzbar>
I might have a go at tweaking those settings next time I get back to hacking away at it. Thanks for that!
<OscarL>
That *should* at least boot from USB, and allow testing the "live" environment (and then to Install to HDD too, if desired, I did so yesterday)
<OscarL>
FWIW, I have an HDD in MBR/BIOS mode, but just for the heck of it... created a small ESP partition, placed the Haiku EFI loader there... of course, machine doesn't boot that way...
<OscarL>
BUT...
<OscarL>
if you use rEFInd from an USB... it *will* detect the Haiku loader, and booting that way works too :-D (after enabling UEFI on biosm of course)
<OscarL>
almost 30 minutes... netbook still working (with IO-APIC disabled)
<OscarL>
I wonder what BootManager does so differently from whatever boot method is used from the .iso in BIOS mode.
<OscarL>
Also... ActivityMonitor shows cpufreq stuck at almost 1600 MHz... while the replicant shows CPU freq changing overtime.
<OscarL>
This thing is possessed.
<Skipp_OSX>
action retro installed no problem :)
<Skipp_OSX>
magic of editing
<Skipp_OSX>
if it makes you feel any better I have a pinebook pro gathering dust waiting for the day it can even run Haiku
<OscarL>
:-)
borgnix has joined #haiku
* OscarL
monitors the screen-less netbook with htop via ssh... fancies himself one of those hackers from the movies.
<borgnix>
go super hacker with btop
<OscarL>
need to port it first :-)
<OscarL>
multi_audio eating 0.6% of CPU time... will prolly end up blacklisting media_server and Co. for this machine :-)
mmu_man has quit [Ping timeout: 480 seconds]
<OscarL>
mc via ssh... looking pretty!
HaikuUser has joined #haiku
<OscarL>
Installer most likely should't blidly copy the "~/config/settings/kernel/drivers/virtual_memory" file.
<OscarL>
noticed that mine reads "swap_volume_device /dev/disk/usb/0/0/0" :-)
<phschafft>
I think all hours are good if you have a lioness with you.
<Begasus>
k, one more to fix before going over PulkoMandy's list ... :)
<phschafft>
OscarL: I was thinking a little about your words yesterday regarding mc. disabling colour support surly will redurce the amount of data that needs to be written. but what I don't think will make much a difference is when not drawing box characters. at least on all DEC SG compatible terminals they are basically as cheap as everything else.
<oanderso[m]>
Could someone with submit rights help me land some of the changes starting at 8103? I have a big stack that could use flushing and many of them are in submittable state
<OscarL>
phschafft: tbh, I just recall the "-a" and similar options on midnight commander from reading manpages (and trying them) ages ago, and yeah, not much relevant these days.
<OscarL>
OTOH, disabling subshell has a *huge* impact on start up time for me (even more so if you happen to use heavier shells with lots of customizations).
<phschafft>
OscarL: DEC SG is from the early 80s ;)
<phschafft>
but okay. thank you.
<OscarL>
you might be underestimating the slowness, or age, of my hardware :-P
<OscarL>
(joking of course, slowest I use is an Atom N450)
<phschafft>
I'm from the 90s, yes. I might now have seen the slowness of your connections befor many years later when I was stuck in Berlin Südkreutz for the first time. ;)
<OscarL>
3-wire serial IPX was the best we could do for quite a while for "LAN"... till I soldered a 15m laplink parallel port cable. We used that in... 2001 :-( (and I still have the darn long ass cable here at home :-D)
tuaris has quit [Read error: Connection reset by peer]
<OscarL>
one machine was much slower than the other, and if we played an MP3 located on the other one... the slow one would turn almost unusable :-D
<OscarL>
cpu couldn't keep up with servising interrupts, I guess, heh.
carlomonte has joined #haiku
carlomonte has quit []
<phschafft>
hm, I had the luck of spending time (and all in the 90s) with RS-232, IrDA (which was much faster than people remember it), Dual channel ISDN, 10Base2, 10BaseT, Ethernet over SCSI, then then the jump to 100Base and 1000base (bith wire and fibre).
<phschafft>
but I must say that I enjoyed Ethernet over SCSI the most I think.
<phschafft>
that gave me around 50Mbit/s. and I guess the problem was mostly what you said: the CPU could not handle more.
<Coldfirex>
@OscarL: Is that machine stable under other OSs still? Curious if it could be failing hardware
<OscarL>
The Atom N2600 based netbook still works pretty well with Void Linux.
<OscarL>
Coldfirex: to be fair... these Atom netbooks are from the early BIOS to UEFI times... and can be problematic.
<OscarL>
oldest Atom N450 I have works almost all the time now (used to have to disable SMP). And newer ones, based on Celeron Nxxxx processors, usually give less problems too.
<Begasus>
bugger, another that needs libdbus (for qt5core)
<OscarL>
I was really looking forward to have my own "2 cores / 4 threads" low-power local HaikuPorts buildmaster, but no luck, I guess.
<Begasus>
still nogo?
<OscarL>
yeah, has lots of issues that drive me mad :-(
<OscarL>
*lots of issues >>> cpu usage goes nuts, OS turns into slow motion.
<Begasus>
:/
<OscarL>
and I can't figure out why, nor a workaround.
<Coldfirex>
Was this possibly the atom chipset that had all those failures?
<Coldfirex>
I had a pfsense box that was affected a while back
<OscarL>
AFAIK the more troublesome Atom was the SoC ones.
<Coldfirex>
ah
mmu_man has joined #haiku
<OscarL>
but yea, some of the Atoms were "do not use USB, RTC, LPC, SMBus, or SD-card too much or it will break down and die" :-D
<Coldfirex>
thats always fun
<OscarL>
the 3 I have (N450/N455/N2600) work pretty well with Windows or Linux still, and are quite older than the ones that started having more serious issues: https://en.wikipedia.org/wiki/Silvermont#Errata
<coolcoder613_beos>
Hello
<OscarL>
o/
<Begasus>
\_/
<OscarL>
Begasus finnally lost his head.
<Begasus>
my way at least :P
coolcoder613_beos has quit [Remote host closed the connection]
<OscarL>
\m/
<Begasus>
first need to fix this akregator thing on 32bit
<dovsienko>
(the host has the usual GUI running and a couple SSH sessions
<coolcoder613>
Apparently
<coolcoder613>
I really like the DOOM music on floppotron
<Coldfirex>
@OscarL: I recall someone else mentioning the vbox integration being extra flaky on the beta5 tests in the forums. Im guessing its started to rot
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<Begasus>
k, case of missing _GNU_SOURCE
<OscarL>
Coldfirex: two years ago I had started to update them to version 7.0.4, but was getting link-time errors. Patchset is really big. I should try again one of these days (now that I can handle .patchsets better than I used to :-D).
Anarchos has joined #haiku
<Begasus>
only needs a dictionary to read those patching patchsets howto :)
<Begasus>
Hi Anarchos
<Anarchos>
Begasus: hello
<Anarchos>
Begasus: i wonder how i can compile a driver for x86_gcc2 on my x86_64 server
<Begasus>
Anarchos, I don't think you can?
<Coldfirex>
Im sure others would appreciate it if you ever try again
coolcoder613_beos has quit [Ping timeout: 480 seconds]
<Anarchos>
Begasus: i tried the configure --build-cross-tools x86_gcc2 but i could'nt succeed
<Begasus>
Anarchos, I don't think much has been done in that area for a long time
<Begasus>
never tried it myself also :)
<OscarL>
Begasus: heh, at least the TL;DR part of the howto serves *me* well (using it right now :-P)
<Anarchos>
Begasus: no trouble i will compile the diver for x86_64 to solve all compiler errors, then i will compile it on the x86_gcc2 laptop
<Begasus>
at least "one" person enjoying it OscarL :P
<Begasus>
got one setup for building 32bit anyboot also Anarchos, so never bothered to check here on 64bit
<OscarL>
mmm, found another corner-case to consider for the how-to... dealing with patchsets that add new files while patch fail to apply.
<Anarchos>
Begasus: i did the errror of erasing the haiku 32 bit partition on the server :)
<Begasus>
but running 32bit on another laptop to check up on applications I mostly use (fairly new setup, so no stuff from previous builds)
<Begasus>
lol Anarchos
<Begasus>
I erased Neon on that laptop yesterday to install 32bit on there :)
<Begasus>
k, if this works out ok I need to push that patch for scummvm upstream
<OscarL>
"'NoneType' object has no attribute 'split'" :-|
<OscarL>
another case of HaikuPorter eating away exceptions (and thus the useful backtrace) it seem.
<dovsienko>
looks like some Python code without proper checks
<Begasus>
seen that one also passing by plenty of times OscarL
<Begasus>
but not lately :D
<Begasus>
grabbing scummvm-2.8.1-1-x86_64.hpkg and moving it to /Opslag/haikuports/packages/scummvm-2.8.1-1-x86_64.hpkg
<Begasus>
k that one is ok :)
<OscarL>
knowing a bit of HaikuPorter... one of those damned try/except without naming the explicit exception.
<OscarL>
then you get errors messages on other places, and you don't know where to look.
<OscarL>
23 "naked excepts" on HaikuPorter... sigh.
<OscarL>
no wonder hitting Ctrl+C cand yield quite surprising results.
<Nephele>
I like how alt->command but this old mac keyboard i have has alt AND command
* OscarL
puts on his rebel leather jacket and looks Begasus sideways.
<Nephele>
OscarL: well, since Haiku is a relatively joung OS, and we do it differently to windows and linux who are both much older, I can only say
<Nephele>
"Conform to the new world order!"
* Begasus
puts on the jeans jacket with the Scorpions stiched to it and stands tall against OscarL
<Begasus>
bugger, grown out of it :P
<Nephele>
OscarL: Nice thing, but this should be shipped with Haiku per default
<Nephele>
I have haiku installed on too many devices, i'm tied down to defaults hehe ;)
<Nephele>
yt_dlp only wants ffmpeg6_tools
<Nephele>
so it's qmplay2 itself
<Begasus>
not following ...
<Nephele>
it's media-video/ffmpeg/ but not media-libs/ffmpeg
<Nephele>
why
<Begasus>
ffmpeg = video?
<Begasus>
SUMMARY="Audio and video recording, conversion, and streaming library"
<OscarL>
that qn() to find recipes is basically the only reason why I haven't tried to move my haikuports clone to a BFS partition without query support (to see if IO times improve).
<Nephele>
Begasus: exactly, it is a library
<Nephele>
OscarL: you can make a find one-liner instead
<Nephele>
tell it where your port is and only search for folder names with a depth of 1
<OscarL>
find is extremely slow compared to query for this usage.
<OscarL>
at least on HDD.
<Begasus>
lol, already got qmplay2-24.05.23.recipe here :)
<Nephele>
OscarL: it is?
<Begasus>
nephele, it's also a cli
<Nephele>
So what?
<Nephele>
Begasus: are you updating qmplay2's version?
<Begasus>
I'm not worrieing about where Gentoo's layout :)
<Nephele>
If so I would stop investigating it's fmmpeg6 stuff and you can update it alongside
<Begasus>
nephele, already had that since june this year
<Nephele>
Well, i only upped the minimum required version of the ffmpeg libs now
<Nephele>
I can check if that works, but if you are working on a newer version I prolly don't need to bother
<Begasus>
59 -> 60 etc
<Nephele>
yes
<Begasus>
haven't looked at it in a while, been playing with plasmatube for that lately as that uses indivious :)
<Begasus>
doing a rebuild with ffmpeg6 here
<Nephele>
/sources/QMPlay2-23.10.22/src/modules/Extensions/LastFM.cpp:122:75: error: cannot convert 'QStringBuilder<QByteArray, QByteArray>' to 'QByteArrayView'
<Begasus>
not sure why I did the new version then :) probably saw some news passing by for it :)
<Nephele>
ugh, not gonna bother with that
<Begasus>
tss :P
<Begasus>
ps nephele, current version in the depot should still be OK?
<Nephele>
That's what I'm building with newer ffmpeg
<Begasus>
well the one from openSUSE has the same version as ours
<Begasus>
biab, doggies :)
<OscarL>
great... finally get a Tracker crash... just the ONE time I'm not running with LD_PRELOAD=libroot_debug.so :-(
<OscarL>
sure enough... that darn "getNumAvailable() == 0" failed accert on malloc.
<OscarL>
motherf...
yann64 has joined #haiku
<Nephele>
I'm confused why you don't modify the service entry for tracker
<OscarL>
aren't those rules in a read-only file?
<Nephele>
so what? non-packaged still applies ;)
<OscarL>
also, I had stopped using libroot_debug.so because I couldn't catch that damn bug anyway... and got tired of things being slower than usual :-)
<Nephele>
well, it would only make tracker slower
<OscarL>
agan with "Identify" not actually doing anything until I "right click" on each file, sigh.
<OscarL>
and everthing you launch from it.
<Nephele>
Not neccesarily?
<Nephele>
You don't have to transfer LD_PRELOAD to apps started after it
<OscarL>
I'm hooked to the Open Terminal addon. and then I have to remember to "export LD_PRELOAD="
<Nephele>
and since launch roster is supposed to start those that seems awful if it inherits those
<Nephele>
sounds more to me like your launch roster was also launched with it
<OscarL>
FWIW, I was not using launch roaster to start Tracker with the preload.
<Nephele>
Isn't launch roster asked by tracker to launch apps?
<Nephele>
and if you have it set in your global env thingy, it would get inherited to launch roster?
yann64 has quit [Quit: Vision[]: i've been blurred!]
yann64 has joined #haiku
yann64 has quit [Remote host closed the connection]
yann64 has joined #haiku
<Begasus>
k, where did those podofo binaries go? ....
<Begasus>
Could NOT find OpenSSL (atleast this one needs it) :)
coolcoder613_beos has quit [Quit: Baxter v0.31 -- ]
<Begasus>
ah! message(WARNING "PoDoFo tools are enabled: tools are currently untested and unsupported")
<yann64>
lol, took me way too long to realise the licence file should not have the same name as the port
<Habbie>
not even if the port has its very own special license?
HaikuUser has joined #haiku
HaikuUser has quit []
<OscarL>
I need a bot to remind cocobean to remove older recipes (or just use git mv).
<OscarL>
:-)
<jmairboeck>
they apparently use Github's web interface or something (commits are verified by Github's signature), I'm not sure if that supports the equivalent of git mv.
<jmairboeck>
but you are right of course, the older versions should be removed
<Habbie>
the equivalent of git mv, to be clear, is one file disappearing and another one with identical or similar content appearing
<Habbie>
git does not actually store a move
<Habbie>
but, those two events need to happen in one commit
<Habbie>
so indeed it might be hard in that web interface
<yann64>
Habbie : haikuporter do not detecte license files in source tarballs, you have to add them in a 'licenses' subfolder
<Habbie>
oh right, i remember now
Coldfirex has quit [Remote host closed the connection]
<OscarL>
Habbie: my point being that by using git mv, you're unlikely to forget to remove old version :-)
<OscarL>
well, you may forget, but it wont matter :-D
<jmairboeck>
when editing a file in GitHub, the filename at the top is a textbox, so it should support renames
<jmairboeck>
but I'm not sure how exactly cocobean is doing it, when uploading files, I don't think it is possible.
<Begasus>
never use "git mv" here, mostly "git rm + git add"
<Begasus>
but some of those PR's are also for packages in use in the Haiku's build?
<jmairboeck>
I mostly use git mv package_name-{oldVersion,newVersion}.recipe
mmu_man has quit [Ping timeout: 480 seconds]
<Begasus>
knowing OscarL I bet he's got an alias for that :P
<jmairboeck>
I think that is about as short as it can be :)
<jmairboeck>
using brace expansion in bash
<OscarL>
I just look at the files with a mean face... and they rename themselves! :-P
<jmairboeck>
of course you can share the common parts of the version numbers also
<jmairboeck>
so most likely it is something git mv package-3.2.{1,2}.recipe
<Begasus>
heh
mmu_man has joined #haiku
<Begasus>
little bugger : [ 7%] Built target podofo_test
<Begasus>
I disabled testing! :P
<Habbie>
OscarL, right :)
marzzbar has quit [Ping timeout: 480 seconds]
mmu_man has quit [Ping timeout: 480 seconds]
<Begasus>
99% tests passed, 1 tests failed out of 129
<nekobot>
[haiku/haiku] fc07afd4bcb1 - Create symbolic link when drag and dropping files from a virtual folder
zardshard has left #haiku [Error from remote client]
zardshard has joined #haiku
flag_ has joined #haiku
flag has quit [Ping timeout: 480 seconds]
Anarchos has joined #haiku
DigitalBox98 has joined #haiku
DigitalBox98 has quit []
Anarchos has quit [Quit: Vision[]: i've been blurred!]
Anarchos has joined #haiku
Anarchos has quit []
PetePete has quit [Ping timeout: 480 seconds]
<jhj>
waddlesplash: hey thanks again btw, I did some quite extensive reworking and now I have quite good performance in haiku :)
<waddlesplash>
:)
<jhj>
But I did notice
<jhj>
ld.lld: error: cannot open /boot/system/lib/clang/17/lib/haiku/libclang_rt.profile-x86_64.a: No such file or directory
<jhj>
:(
<jhj>
No profiling support in Clang?
<waddlesplash>
seems not, I guess
<jhj>
waddlesplash: The thread-local storage changes on Linux are only good for 2% or so. And less than 1% differece on AIX.
<jhj>
But now 70% faster on Haiku.
<jhj>
What was the full system profiler that you were using?
<jhj>
anyway, I'm working on replacing a few places where locking is used to update with atomic operations instead, which should get another few % at least.
nosycat has quit [Quit: Leaving]
Nephele has joined #haiku
<Nephele>
Begasus: nice, much less deps for qmplay2 now
<Nephele>
i like testing against it, shows how much mediaplayer playback improvement can improve
<jhj>
waddlesplash: I still get some Haiku results that confuse me with my benchmarks
<jhj>
With the threaded build, I get 7.1 MIPS, and the non-threaded build I get 7.2 MIPS.
<jhj>
But when I build with PGO, the threaded build is always slightly faster than the single threaded build. :)
<jhj>
8.2 vs 8.1
<jhj>
I guess I shouldn't complain.
<jhj>
I just find that bizarre because the single threaded build is always going to be do doing less work overall.
mmu_man has quit [Ping timeout: 480 seconds]
<jhj>
Anyway, the Clang build is still faster on Haiku than GCC is.
<jhj>
I get 9.6 MIPS with Clang - and can't even make a profiled build.
wiertelus[m] has joined #haiku
mmu_man has joined #haiku
Begasus has quit [Quit: Vision[]: i've been blurred!]
<dovsienko>
1. Make it work. 2. Make it right. 3. Make it fast.
wicknix has quit [Ping timeout: 480 seconds]
<gordonjcp>
dovsienko: !
<gordonjcp>
dovsienko: I saw your Skye pics
<dovsienko>
hopefully not too disgusting
<gordonjcp>
looks like you were mostly around the North End, Staffin, Duntulm, Uig kind of area?
<phschafft>
back. but still need to take care of food.
<phschafft>
51.16km today.
<Nephele>
I wonder sometimes why km is used so much, one could also use hecto or deka meter heh. Though even in mass the notion of Mg is often ignored apart from the industry many people here calling it a "ton" instead. And even when Gg is apropriate i've not seen it used at all
<dovsienko>
gordonjcp: the first week, yes, then a week of skirting around Cuillins
<gordonjcp>
dovsienko: ah yeah you've got the corry loch in one of your photos
<nekobot>
[haiku/haiku] e776c8dee561 - libnetwork: Only build BeOS compatibility code if _BEOS_R5_COMPATIBLE_ is set.
<gordonjcp>
dovsienko: when I was at school a group of geology and hydrology students travelled up from Exeter Uni to explore that loch, and schlepped their dinghies and diving gear all the way up the slopes of Blaven
<gordonjcp>
dovsienko: and they got there
<gordonjcp>
dovsienko: and they discovered it was knee deep at best
<phschafft>
nephele: I mean in this case it's a good unit (two digits before the point and no better matching one). but I tend to use Mm, but that seems to confuse people.
<gordonjcp>
they had intended to go up to Loch Coruisk, a hill over, which is much deeper :-)
<phschafft>
I think most don't understand what the units mean, they just learn them as special cases.
<phschafft>
generally I think most people understand the world as a collection of special cases with no connecting logic.
<dovsienko>
gordonjcp: I camped at Coruisk for a couple days
<gordonjcp>
phschafft: it's annoying being in the UK because the signs are in Old People Units
<dovsienko>
Skye is a beautiful place, but also dangerous in a number of ways
<gordonjcp>
and while I have a mental model of both miles and km, one is a damn sight easier to perform arithmetic on
<phschafft>
gordonjcp++
<gordonjcp>
dovsienko: yes, your compass doesn't work any more for a start
<phschafft>
gordonjcp: I always wondered why they talked about 'metric tons' in scifi. then I found out that there is also a british ton and a USA ton.
<dovsienko>
the old style compass I have works about alright. one thing that does not work is degree-minute-second marks on Ordnance Survey maps
<phschafft>
but hey, I mean the british and the USA inch is also different.
<gordonjcp>
phschafft: yup, and UK and US gallons are different so cars in the US seem a hell of a lot less efficient
<gordonjcp>
phschafft: when I was wee I remember my dad pointing out sheets of plasterboard labelled as 1200mm x 8'6"
<dovsienko>
that was exactly the idea of introducing litres, metres, seconds etc.
<Nephele>
phschafft: as for these units beeing special cases, I am quite happy in SI this is mostly just logical. Nice to teach, but hard at the start to teach somebody the difference between say a L and dL
<gordonjcp>
standard ceiling heights in the UK were 8'6" but appliances, kitchen cabinets etc. are multiples of 600mm
<Nephele>
I think dL is a nicer unit in some cases than a normal L
<phschafft>
gordonjcp: haha!
<gordonjcp>
phschafft: people actually use "metric foot"
<gordonjcp>
because 300mm is an awkward thing to say but a really convenient size for something
<Nephele>
the US system doesn't have the SI problem of defining it in precisely.
<Nephele>
It's already defined... in SI units xD
<phschafft>
gordonjcp: when people talk about gallons my brain auto corrects that to galleons.
<Nephele>
gordonjcp: it is? it's quite common here, not really hard to say
<phschafft>
nephele: yes, that is why the britisch inch and the USA inch is different.
<Nephele>
mm cm dm m and such are quite common, dm is less known but basically everyone I know understands atleast mm cm and m
<Nephele>
in speach and written
<Nephele>
the only thing annoying me in the SI system is time and all time derived units
<Nephele>
especially since this tends to introduce random 3,6 multiplications
<phschafft>
nephele: I just learned that most people -- for some reason I don't understand -- try to make everything a special case. if you ask them they tell you it is 'easier'.
<Nephele>
(from 3600s in one h)
<Nephele>
phschafft: maybe only learning specific things seen once, without trying to understand the underlying logic?
<Nephele>
as in "why do i need this logic, what i know works already"
<gordonjcp>
nephele: kind of unrelated but this is where 24ppqn MIDI clock comes from
PetePete has joined #haiku
<Nephele>
I don't think I know enough about the MIDI protocol, what does ppqn mean?
<gordonjcp>
nephele: if you have 24 clock pulses per crotchet, or "quarter note" in Simplified English, you can divide it by multiples of 2 or 3
<gordonjcp>
"pulse per quarter note" because that bit was designed by Americans
<Nephele>
ah okay
<gordonjcp>
so if you count a bar of 4/4 - bomp bomp bomp bomp
<gordonjcp>
each of those "bomps" is 24 clocks
<Nephele>
I guessed pp means parts per, but he :D
<phschafft>
nephele: I see that a lot in e.g. Icecast support. people are always very confused when I say something like 'just set that option'. and they go 'but you can only set that on files of that type!' 'no, it works on all' 'all of that type!'
<Nephele>
doesn't that then only make sense if you also have the bpm of the music piece?
<phschafft>
and then they have the same problem again with another file it's the same discussion again.
<gordonjcp>
nephele: yes-ish
<gordonjcp>
nephele: you emit clocks at the appropriate speed though
<gordonjcp>
since most step sequencers have 16 steps per bar then every six clocks you count along one step
<phschafft>
nephele: my problem with time is that there are way too many definitions of 'second'.
<phschafft>
e.g. UTC and GMT have different definitions of second. and both are different from SI. naturally Deutsche Bahn used to have their own definition.
<gordonjcp>
nephele: if you wanted to do a 16ths triplet that'd be three notes in the length of two, so you'd count off three notes of four clocks, and so on
<Nephele>
Well, I only use the SI one, unless you are talking about coloqualisms like "be with you in a second"?
<phschafft>
nephele: it starts with the fact that there is nothing as subjected to all kinds of physical problems as time. but, for some reason unknown to me, it is still the one thing we can messure the best.
<Nephele>
gordonjcp: defining audio in a musical framewark will give me a headache :P
<phschafft>
nephele: then go with Intel. They define musical time as +/- 5%, on good days a little better. ;)
<Nephele>
well, this pc has internal speakers and if i start a video sound comes out
<Nephele>
that's good enough right?
<phschafft>
I mean with 5% error you can basically fit any standard it in. ;)
<Nephele>
if it sounds bad maybe an equalizer can distort it :)
<Nephele>
I'm annoyed that the HDMI standard sometimes doesn't let me specify audio volume
<phschafft>
the people with distortion are the tube guys. the less it has in common with the original the better the transmission by their standard.
<Nephele>
Leads to wierd situations where a client can't specify volume, but if i stream audio to this client then i suddenly can again
<phschafft>
and naturally, the more power it consumes the better it sounds!
<Nephele>
of course
<Nephele>
does it go to 11?
<phschafft>
;)
<Nephele>
they wouldn't like programmers preffered "float between 0 and 1"
<dovsienko>
defining, measuring and maintaining time is inherently complex
<phschafft>
nephele: actually they prefer the float thing over bit correct stuff.
<Nephele>
I dislike UI showing a distinction where the software makes no distinction, I have this often with volume levels on the lower end
<phschafft>
but, just think about it. the tube guys are people who have a heater in a thermos flask and then pretent that the vacuum in it somehow makes things sound better!
<Nephele>
dovsienko: indeed
jmairboeck has quit [Quit: Konversation terminated!]
<dovsienko>
nephele: this may have to do with the difference between logarithmic and linear potentiometers
<Nephele>
dovsienko: dunno. I think if the hardware would not be capable to respect something then the UI should not allow to set this
<dovsienko>
some software seems to use a power of two instead of the logarithm, which indeed results in weird response
<Nephele>
I also think this should be side effect free. don't like how in linux turning down the backlight disables it at some point
<phschafft>
I find that semilog (log on the lower end and linear on the upper end) works best for my personal feeling.
<dovsienko>
if you use a linear potentiometer for volume control, the response feels out of proportion from a human perspective (psychoacoustics may be the correct reason)
<phschafft>
dovsienko: the ear is actually physically log, so you're right and it's also not a thing of the brain.
<dovsienko>
nephele: that could be a hardware detail, where the PWM driver does not allow the signal duty to go below a certain minimum
<phschafft>
(and most senses are more log than linear. it's a general trend)
<Nephele>
dovsienko: No it isn't
PetePete has quit [Ping timeout: 480 seconds]
<dovsienko>
ot PWM is implemented in coarse slots, e.g. 1/16 of full duty
<phschafft>
nephele: which driver do you use? never that that problem.
<Nephele>
The linux driver deliberately turns off the backlight for value 0, atleast on radeon drivers
<dovsienko>
in short, there are many ways to screw it up
<phschafft>
em, if you set it to 0 it's... off?
<Nephele>
No, it isn't phschafft
<phschafft>
I think last time I checked when you multiplay something by 0 it... is 0.
<Nephele>
0 is the lowest possible brightness, if you turn off the backlight that is a seperate state to me
<phschafft>
nephele: yes, they are seperate states. but still 0 means 0.
<phschafft>
the difference is specifically relevant to audio mixers.
<Nephele>
It does not, an enabled backlight with a brightness of logical 0 is still illuminating something
yann64 has quit [Quit: Vision[]: i've been blurred!]
<Nephele>
it's just the lowest possible value that specific hardware can go
PetePete has joined #haiku
<phschafft>
I see that it might be a different user story for backlights.
<dovsienko>
depends on the hardware spec, perhaps
<Nephele>
for OLED for example, where this is the same, it would work differently of course
<phschafft>
but specifically for audio the difference is important and something I prefer to have access to from an application.
<Nephele>
but for OLED the question of backlight brightness makes no sense in the first place
<phschafft>
(you need it to avoid strange sounds)
<dovsienko>
should have been an analogue potentiometer for the brightness, like in the old times
<Nephele>
dovsienko: we actually have the problem you mentioned with some intel driver too
<phschafft>
but, time for food. people are waiting. and I don't want a fork in my rear for not serving. ;)
<Nephele>
there at some point in the haiku driver for some displays it will cut off to black, but even before reaching 0 on the slider
<Skipp_OSX>
nephele pls turn your -2 on my clock change to a +2 so we can include in r1b5
<Nephele>
No
<phschafft>
see you all later!
<Nephele>
phschafft: see you :)
<Nephele>
Skipp_OSX: control colors are still inapropriate to use for this *especially* if you need to heavily tint them to get back towards the original rendering
<phschafft>
(and if anyone is interested. I have given talks on signal theory and DSP in the past. if there is interest I would be happy to do something again :)
<Nephele>
the original change from nipos is better
<Nephele>
basically if you so heavily tint the colors you are assuming a specific color is chosen for the control color, which isn't what it is for. If the user can't properly use them to customize this there is no point in needleslly tying it to the color
<Nephele>
I stand by with what I said, If you want to implement color drops for this control feel free but I don't want to tie this down to any UI color constants since they are inapropriate for this ui element
<Nephele>
Yes, and the previous version does that fine.
<Nephele>
There is no heavy tinting in the original, it simply uses the apropriate colors. It is not a "diff" towards the control colors, since it will always use these colors
<Skipp_OSX>
That being said I don't care too much, I'm just trying to get the colors updated based on color constants and don't care too much about the style.
<Nephele>
that could work in dark mode better if there was a circle around it indeed
<Nephele>
Okay? But updating it for no reason makes no sense, and we shouldn't do it.
<nekobot>
[haiku/haiku] 33e9a82042d4 - protocols/unix: Hold an extra reference during stream endpoint close.
<Skipp_OSX>
it's updated for the reason of adjusting the colors...
<Nephele>
If you tint the colors then the ui colors become useless for adjusting it.
<Nephele>
And we already have a much better mechanism for this, which is color drops
<Skipp_OSX>
color drops are independent of using color constants, look at DeskCalc for example, its colors adjust with color constants, but you can drop a custom color as well.
<Nephele>
yes, it does. Because deskcalc is using normal OS controls that *should* use the control colors
<Skipp_OSX>
of course it all works based on "heavy tinting" in the end.
<Nephele>
If your goal is "this should look like a skewmorphic clock" then, no, you should not do this
<Skipp_OSX>
my goal is to not destroy the aesthetic integrity of the skeuomorphic analog clock that has already been built.
<Nephele>
It does not, the color should match what the control looks like in the end with not that much tinting, in essence you can go a bit up and a bit down with the tone for a control, but you can't just pick a tone that is way above it
<Nephele>
Then implement color drops?
<Skipp_OSX>
color drops are once again orthogonal
<Nephele>
Sure, but I'm not going to agree to using inapropriate color constants.
<Skipp_OSX>
you can't say color drops because color drops or not the design is the same.
<Skipp_OSX>
why are the color constants inappropriate?
<Nephele>
Because you are trying to create a specific rendering regardless of the colors the user sets
<Skipp_OSX>
no, I'm adjusting the colors with the colors the user sets.
<Nephele>
look at it like this, right. the control color has (on a grayscale value) a range from 0 to 255, if you with your tinting multiplicate that color by a lot you make the effective range of the control much much smaller
<Nephele>
and now, to get a different rendering of a *skewmorphic* clock the user has to change a color constant that normally controls elements that are not directly skewmorphic
<Skipp_OSX>
but much larger than a single pair of colors...
<Nephele>
your video demonstrates this quite well, there is a very limited range you can only set the clock towards
<Skipp_OSX>
other than the fact that I made it a bit lighter/darker than that video what's wrong with that? The whole idea is to pick either a light or dark clock.
<Nephele>
which was what nipos changeset was doing, pretty much.
<Skipp_OSX>
right
<Nephele>
the rendering of the dark mode clock didn't really look right without shadows so instead it just made the background a bit more muted gray
<Nephele>
One can of course design a proper dark mode rendering with more effort, but that doesn't have much to do with the color constants
<Skipp_OSX>
but nipos' change made the hands black on black whereas mine are white on black to emulate analog clock style.
<Nephele>
Only after I asked that, before it did the same thing
<Skipp_OSX>
it does in that the shades are tinted based off your control constants rather than picking arbitrary values.
<Nephele>
It should pick arbitrary values instead
<Nephele>
ones that work well together
<Nephele>
or we abandon the skewmorphic design of this UI element, and make it completely control colored like your original change
<Skipp_OSX>
generally we try to avoid hardcoding colors
<Skipp_OSX>
It is not right to abandon the skeuomorphic design that the author originally intended, but to adjust said design for dark mode... that being said, what do I have to change to get this in?
<Nephele>
Generally yes, but how one de-hardcodes it is the real question. If we want to keep this skewmorphic we should simply not do this, instead keep it like it is now, maybe adjust it for the dark mode. Or we abandon the skewmorphic design for this and make it into a proper control colored element
<Skipp_OSX>
I already did option 1 essentially
<Nephele>
into beta5? atleast nipos agreed to develop further dark mode stuff with me on master, is it important that this specific dark mode change gets in?
<Skipp_OSX>
no, not essential, just trying to unblock progress here.
<Skipp_OSX>
right now you get a white clock in dark mode as well as light mode, but it looks ok.
<Nephele>
yes, i think so too. the second change muted it a bit in dark mode which imo still looked okay. Do you want to make a nice rendering for dark mode with defined colors?
<Nephele>
But really we can better discuss if we want a dark mode clock like you did now with the colors swapped, or one with just a muted background
<Nephele>
aslong as the control colors aren't used I can probably be okay with either
<Skipp_OSX>
what's wrong with control colors?
<Nephele>
This is not a control-colored control :)
wicknix has joined #haiku
<Skipp_OSX>
but it is...
<Nephele>
no, it's a specific skewmorphic rendering
<Skipp_OSX>
yeah I guess that's true
<Skipp_OSX>
skeuomorphic
<Nephele>
Still, we could make this a non-skeumorphic control collored clock instead
<Skipp_OSX>
mine is skewmorphic, but the original is skeuomorphic
<Nephele>
That would likely also make it clearer that is actually a control
<Skipp_OSX>
(lil tint joke there)
<Nephele>
:)
<Skipp_OSX>
the date and time spinners above should be control colored because they are controls....
<Nephele>
yes, now that you mention it they do look out of place
<Nephele>
but then the calendar would technically also be a control? or is the document metaphore here accurate? I'd say kinda, but then this version does not actually allow to set calendar entries
<Skipp_OSX>
it is a control you can change calendar entries
<Nephele>
there is a Calendar application, but not hooked up there
<Nephele>
you can only change the date
<Nephele>
... but it does look like a calendar, so it changing the date is a bit unexpected to me
<Skipp_OSX>
You see how their clock is even more skeuomorphic than ours with the bezel?
<Nephele>
I think the BeOS version is much clearer in the left side beeing a control for the date
<Nephele>
(but their clock looks even less like you can use it)
<Nephele>
Yes I see
<gordonjcp>
wow beos was really pixelly
<gordonjcp>
we've come so far
gouchi has joined #haiku
<Skipp_OSX>
BeOS is pixally but part of the problem is that I'm using retina display that is doing pixel doubling
<Skipp_OSX>
so my screenshot is pixel doubled and I'm too lazy to half size it back to the original for you.
<Nephele>
I don't like that :( I wish it would just do scaling on MacOS like Haiku can do, with proper layouting
<Skipp_OSX>
yeah pixel doubling would be nice to have on Haiku for a 4k display.
<Nephele>
I ment it would be nice if MacOS behaved like Haiku, not Haiku like macos :P
<Skipp_OSX>
it looks pretty silly at 4k though
<Nephele>
if you have a 4k display and use pixel doubeling you might aswell just get a HD panel and save yourself the power consumption
<Skipp_OSX>
no, because the text is twice as clear
_-Caleb-_ has left #haiku [#haiku]
<Nephele>
It... isn't... only if you properly render it at that scale
<Skipp_OSX>
which is what macOS does
<Nephele>
in which case you aren't using pixel doubeling anymore
<Skipp_OSX>
well, not when emulating BeOS...
<Nephele>
it only does this for some applications, anyhow.
<Skipp_OSX>
yeah but it makes text much easier to read
<Nephele>
also means you better select exactly 1/4 of your monitors resolution otherwise some apps look really bad
<Skipp_OSX>
correct
<Nephele>
which is a shame because 1/4th of my macbooks resolution is not that great... but native resolution makes apps too small
<Skipp_OSX>
but if you double it works well
<Nephele>
No good solution *shrug*
<Skipp_OSX>
yeah well thems the breaks
<Nephele>
on Haiku with native apps with native layouting I can get crisp rendering with fontsizes i want :)
_-Caleb-_ has joined #haiku
<Nephele>
but then, also only when using native apps so, more native apps! :D
<Skipp_OSX>
Haiku should get pixel doubling some day... but that's another story.
<Nephele>
that's stuff a compositor would do. I don't think we should, maybe some applications should do this internally
<Nephele>
for example scummvm does this on it's own
<Nephele>
I think that is a better way to go about it
<Nephele>
native apps can size properly with no help, and ports can do this doubeling or whatever
<Nephele>
i think qt already supports this too
<Skipp_OSX>
well, I think we're at an impasse because you demand we not use control colors and I demand we do.
<Nephele>
If you abandon the skeumorphic design of the clock and make it look like a proper control you are free to use control colors
<Nephele>
if you want to keep it skeumorphic than don't use them
<Nephele>
that's my take anyhow
<Skipp_OSX>
I'm free to use them now... and have and it works great
<Nephele>
*shrug
<Nephele>
*
<Skipp_OSX>
not shrug more like *sigh*
<waddlesplash>
can we at least fix the controls to use control colors?
<waddlesplash>
the date and time spinners
<Skipp_OSX>
..... no I mean yes but not simply
<waddlesplash>
also it would be nice if they used actual spinbox +/- instead of the funky up/down arrows
<waddlesplash>
why not? They're just controls aren't they?
<Nephele>
Skipp_OSX: well, I don't know what more to say to you, you are running in circles in this argument. It does not look like a control so it should not use control color constants, simple as that
<Skipp_OSX>
I tried already, there's a couple places that need to change because there is a bg layer and then text layer
<waddlesplash>
okay... sounds standard
<waddlesplash>
nephele: I think it would make sense for the calendar and the clock to both use document colors
<Nephele>
waddlesplash: I don't think they can be classified as documents really
<Skipp_OSX>
but it is a control, the problem is not that I'm running in circles, it's that I'm directly contradicting you because you're wrong.
<waddlesplash>
physical calendars sure seem like documents
<Nephele>
also the screenshot above of BeOS shows that the calendar looks much better with control colors
<Nephele>
Yes, indeed. but this does not work like a physical calendar, and instead sets the date. which I think is confusing
<Skipp_OSX>
no circle, straight line, it is a control, it uses control colors.
<waddlesplash>
Skipp_OSX: it's ... kind of a control
<Nephele>
since a normal document calendar lets you select days to check your apointments
<waddlesplash>
anyway fixing the control boxes would be easier and less controversial to start with
<nipos>
It's interesting that you're still debating so long about a very simple fix to make dark mode look better. And running in circles so many times. Document Colors was my first try, if I remember right
<Skipp_OSX>
yeah but nipos started it, I was unconcerned before.
<Nephele>
waddlesplash: the beos screenshot above https://0x0.st/Xvqj.png , I think is a great example of how we should make the calendar use control colors
<waddlesplash>
I didn't actually realize till I saw you discussing on these changes that one could drag the hands of the clock
<Skipp_OSX>
yeah, document colors would work fine too, control makes more sense to me, I don't care really about document or control, I care that the colors adjust with color constants.
<waddlesplash>
pretty neat
<Nephele>
to make it clear this is a control
<waddlesplash>
nephele: I don't agree
<waddlesplash>
I much prefer it as is
<Nephele>
> I didn't actually realize till I saw you discussing on these changes that one could drag the hands of the clock
<waddlesplash>
hm
<Nephele>
that is the main problem
<waddlesplash>
what about LIST_BACKGROUND?
<Nephele>
unless told there is no way to figure this out
<waddlesplash>
the calendar is like a list of dates
<Skipp_OSX>
well it' definitely not a list though...
<Nephele>
it simply does not look like a control
<Skipp_OSX>
it's
<waddlesplash>
Skipp_OSX: it kind of is, it's like a list but in a grid
<Skipp_OSX>
controls don't look like anything they are generic.
Coldfirex has quit [Remote host closed the connection]
<waddlesplash>
nephele: even if you use control colors it won't "look like a control"
<waddlesplash>
it will look like a clock
<Skipp_OSX>
no a list is like a list view ...
<waddlesplash>
there aren't any colors that would've helped me recognize this
<Skipp_OSX>
it looks like a clock control, which is what it is
<Nephele>
Controls look like a control among other things if they use control colors and certain rendering hints
<waddlesplash>
Skipp_OSX: yeah, BColumnListview or BListView, sure
<waddlesplash>
Skipp_OSX: I meant the calendar should use list colors.
<waddlesplash>
not the clock
<waddlesplash>
nephele: not to me, lol
<Skipp_OSX>
yeah I got what you meant but no it shouldn't
<Nephele>
waddlesplash: You think we can't make a clock that looks like a control and not a RO ui element?
<waddlesplash>
Skipp_OSX: why not?
<waddlesplash>
nephele: I don't see how you could, no.
<Skipp_OSX>
because lists have white backgrounds essentially, because it's not a list.
<waddlesplash>
the BeOS clock looks more R-O than ours
<waddlesplash>
Skipp_OSX: doesn't this have a white background?
<Nephele>
waddlesplash: indeed it does
<Skipp_OSX>
beaqcuse I tried to use menu colors for lists and got yelled at.
<Nephele>
which proves you can make it less RO looking
<waddlesplash>
Skipp_OSX: we have list colors for lists
<waddlesplash>
they have their own color constants
<Skipp_OSX>
yeah bc I got yelled at so I added them :)
<waddlesplash>
good!
<waddlesplash>
more color constants
<waddlesplash>
the calendar is basically a list in a matrix arrangement
<waddlesplash>
so, I think it should use list colors
<nipos>
What about "control clock in the preferences" color constants? :D
<Skipp_OSX>
lists don't go in matrix, menus go in matrix...
<Nephele>
This calendar is basically buttons in a matrix arangement we don't render nicely
<waddlesplash>
Skipp_OSX: lists can go in matrix :P
<Skipp_OSX>
they can? ok nvm then
<waddlesplash>
well, maybe ours can't, exactly
<waddlesplash>
but we have BColumnListView
<waddlesplash>
you can sometimes select individual cells in it
<waddlesplash>
not just rows
<waddlesplash>
so, yes
<Nephele>
anyhow, if it is a control, and you use it so change values or set a setting it should use control colors as a rule
<Nephele>
not a list color
<waddlesplash>
nephele: it even has blue focus rings, face it, this is a list lol
<Nephele>
this control supports keyboard input? well in that case it is clearly a list *sigh*
<waddlesplash>
nephele: nope, it's a list you select an item (a date) from
<waddlesplash>
?
<waddlesplash>
all controls accept keyboard input
<waddlesplash>
not sure what your point is
<Nephele>
It does not look like clicking a number will change the system date
<waddlesplash>
it does to me?
<Nephele>
the BeOS version makes that cleart
<waddlesplash>
what else would this do
<Nephele>
uhm, it's a standard looking calendar? it should show what is going on at that date with this rendertype?
<waddlesplash>
no
<Skipp_OSX>
it looks pretty clear to me on Haiku too
<waddlesplash>
this is the Time preference panel
<waddlesplash>
what else would it do but change the date and time
<Nephele>
You are arguing that the rendering is fine because it would be illogical that it wasn't...?
<Nephele>
there are some things that are simply incredibly hard to discover or can bite you UI wise because it isn't expected. The Screen preferences open the background when you click the monitor icon, that is about as discoverable...
<Skipp_OSX>
the functionality is a bit hidden, that's why the controls are up top.
<Nephele>
If you select something in the calendar there is even a delay before it is selected, so it doesn't look like you clicked anything
<Nephele>
exactly, the doubled controls even make it look like this is not the place to set it
<Skipp_OSX>
it's more like, hey, let's be fancy and make the clock work too, not the clock is how you're supposed to set the time.
<waddlesplash>
nephele: well that sounds like a bug
<Nephele>
with that big a delay?
<Skipp_OSX>
I don't think what you're saying is true, it does look like this is the place to set it, other than not using control background on the spinners...
<Nephele>
Skipp_OSX: the controls above look like the place to set it
<Nephele>
but the calendar looks like a calendar
<Skipp_OSX>
right, well that's on purpose sure
<waddlesplash>
I am quite used to clicking on alendars on other OSes and applications
<Skipp_OSX>
the controls above _ARE_ the place to set it, the calendar and clock are alternative controls that also show a nice calendar and clock.
<Nephele>
*every* other time I click on a calendar on another OS it is to inspect that day, not to set the day
<Skipp_OSX>
you are expected to use whatever is comfortable for you.
<waddlesplash>
nephele: definitely not true
<waddlesplash>
I have used plenty of apps with calendars embeded, or a date-edit that had a drop down calendar
<Nephele>
Definetely true. Or do you have a wiretap device to record my screen? *sigh*
<Skipp_OSX>
and that's literally true on Haiku as well, by right clicking on clock in Deskbar and selecting Show calendar...
<waddlesplash>
nephele: well, fine, maybe for you, but definitely not true for me
<Nephele>
Skipp_OSX: indeed
<nipos>
I just checked that on my Android phone, and there definitely is a calendar to set the date
<Nephele>
it looks *exactly* the same
<Skipp_OSX>
it's just that in the Time preferences it selects the date since that's what the Time prefs is for.
<nipos>
And for the time, there is a control that somehow looks like a clock, but not exactly a oldschool analog clock
<Skipp_OSX>
yeah, it's supposed to
<Nephele>
yes, I agree. but the rendering should indicate this difference
<Nephele>
it shouldn't look like just another calendar, here for convenience
<Nephele>
(for example to show apointments on those days)
<Skipp_OSX>
so exactly the same as what we have then
<waddlesplash>
Skipp_OSX: interesting, SetViewUIColor in DateTimeEdit did not suffice?
<Nephele>
It should use control colors here to make it clear that this is a control, and not a RO calendar view
<Nephele>
like... looking literally the same as in deskbar, but behaving differently when clicking on it. that's just bad UI reading
<waddlesplash>
it doesn't look literally the same
<waddlesplash>
it does look similar
<waddlesplash>
we can probably add more cues
<Nephele>
Fine. Technically the deskbar version is a bit expanded
<Nephele>
but yes, those cues is what I mean for example
<Nephele>
like the current day beeing repressed like in BeOS
<Nephele>
for example flat buttons (that look like buttons on hover) could be used
<Nephele>
(if you prefer not to change this rendering too much anyhow)
<Nephele>
maybe the clock hands could also render differently on Hover to show they are useable
<Nephele>
with control colors (and proper gradients) that could work to make this UI much more readable
<waddlesplash>
yes, on hover sounds good
<Nephele>
hmm, the calendar is also missing the ui drawing cue that it looks repressed into the view
SLema has quit [Quit: Vision[]: i've been blurred!]
<Nephele>
waddlesplash: which ones? of calendar?
<waddlesplash>
no
<Skipp_OSX>
https://0x0.st/XvqJ.png <= I can make the clock bg straight up black and white like this
<waddlesplash>
of the date-time spinners
SLema has joined #haiku
<Nephele>
the ones of date time spinners and of calendar don't match with the ones of the listview in the next tab
<Nephele>
Skipp_OSX: not sure if this is also caused by the bluriness of your screenshot but the black version doesn't really look good
<waddlesplash>
nephele: yes, that's what I mean
<Nephele>
also missing shadows and such
<waddlesplash>
really these should be Spinners
<waddlesplash>
but that's a bigger refactor
<waddlesplash>
maybe one Skipp_OSX will tackle in the future? :P
<Nephele>
They can't be spinners easily
<waddlesplash>
sure they can, we have BAbstractSpinner
<Nephele>
since time and dates have very special cases when they can be valid
<waddlesplash>
we can turn these classes into spinners inheriting from it
<Skipp_OSX>
right, based off BAbstractSpinner... although I got yelled at for that too
<waddlesplash>
why?
<Skipp_OSX>
told it was terrible design
<waddlesplash>
I'm not sure what other design we could use
<waddlesplash>
Qt does the same thing: QAbstractSpinBox
<Skipp_OSX>
correct, that's where I got the idea from...
<Skipp_OSX>
QAbstractButton yeah
<Nephele>
well, you can probably make them inherit from abstract spinners, but i am wondering how much code would be valid, and if reimplementing it would not be easier in the first place
<Skipp_OSX>
My idea of a BTypedControl<Type T> also got shouted down....
<waddlesplash>
that at least sounds like a bad idea,y es
<Skipp_OSX>
it's a bad idea to shoehorn a color into an int32 but that's what we do now.
<Nephele>
10bit colors hmmm
<Skipp_OSX>
well for BColorControl, and then for BSpinner I was trying to branch out a bit so you could have a double spinner or a datetime spinner, etc.
<Skipp_OSX>
anyway, I guess I get yelled at no matter what I do but I'm trying.
<Nephele>
Skipp_OSX: we already have some starting code for hsl in appearence preferences
<Skipp_OSX>
ooo good
<waddlesplash>
yes, we have hsl_color now
<waddlesplash>
used for the Appearance autocolor mode
<Skipp_OSX>
we do? Nice nice
<waddlesplash>
private API but yes
<Nephele>
well, it's not in libshared yet, you'd need to move it out
<Nephele>
but yes, starting parts for it :)
<Skipp_OSX>
Maybe I can unhide the out-of-gamut selector in Colors! someday
<Skipp_OSX>
(out-of-gamut selector selects nearest printable color based on your color profile)
<Nephele>
haha, color profiles, in this economy? /s
<Skipp_OSX>
we don't have color profile support yet, but I can dream...
<Skipp_OSX>
hehe
<Nephele>
color profiles would be neat. But so would moving to 10bit colors :P
petterhj has joined #haiku
<Nephele>
Haiku is fun, atleast you know there is still work to do
<Nephele>
Skipp_OSX: though, i wonder how many OS nowadays have a color picker for 256 colors mode :3
<Nephele>
though it is somewhat broken with my font size :/
<Nephele>
lol, found a bug with screen preferences messing around with 256colors mode
<Skipp_OSX>
I could turn 256 colors into a color picker
<Nephele>
I'm confused. Can't i just link in one of those you made from libshared or whatever?
<Nephele>
does it *have* to be a seperate window?
<Skipp_OSX>
you can link, it has to be a separate window, but it doesn't have to be a titled window, any kind of window you want.
<Nephele>
doesn't seem that usefull for most usecases then
<Nephele>
can't be used in pref/appearence to start with
<Nephele>
or in wonderbrush easily
<Skipp_OSX>
I've already got it working in Icon-O-Matic
<Skipp_OSX>
Wonderbrush would be pretty similar process.
<Skipp_OSX>
But that would be up to steppi to do, and he probably won't, oh well.
<Skipp_OSX>
stippi
<Nephele>
Yes, but. they both open a window picker from a strange place. The point is the smaller in-window color picker is also a view, and making those shared would be more relevant
<phschafft>
'Icon-O-Matic'.
<Nephele>
since that can then be shared between IOM, wonderbrush and pref/appearence already
<phschafft>
I still find the names of stuff in Haiku funny.
<phschafft>
'wonderbrush'.
<Nephele>
and then it could even be a preference in apps which one is used
<Skipp_OSX>
yeah that's the idea, well, Appearance is doing it's own thing.
<Skipp_OSX>
*its
<Nephele>
Appearence is doing the same thing as wonderbrush and IOM, implement a color picker for it's own view on it's own
<Skipp_OSX>
no, not exactly
<Nephele>
and Icon-O-Matic and wonderbrush have the same need for live color updates as appearence has
<Skipp_OSX>
if you click on the big swatch it opens a copy of Colors!
<Nephele>
I am aware
<Skipp_OSX>
ok well that's different then
<Nephele>
Well still, in my mind the smaller pickers are far more relevant to have shared, and be able to switch out
<nekobot>
[haiku/haiku] 729906049aa6 - DateTimeEdit: Use document colors.
<Nephele>
and it has a text cursor etc
<Nephele>
waddlesplash: uhhh, could you please use code review?
<Nephele>
especially if two other devs here just said it should not be done like that?
<waddlesplash>
Skipp_OSX just agreed it should be document colors
<waddlesplash>
literally ALL text input controls use document colors
<waddlesplash>
there is 0 reason for this to be an exception
<Nephele>
this is not a text input, it does not input text and does not have a text cursor
<waddlesplash>
okay, let me rephrase: all controls that accept text input and convert the text input into text that is inside the control, use document colors
<waddlesplash>
and it has a cursor. just not a "Text" cursor
<waddlesplash>
a fact which I think should be fixed anyway
<Nephele>
Exactly, it does not behave like a text field
<waddlesplash>
well, then let's make it behave like one
<Nephele>
No? this is much better than what the spinner does
<waddlesplash>
I don't agree
<Nephele>
Let's instead fix the spinner
<waddlesplash>
I think this should be a custom spinner
<waddlesplash>
nephele: I like the spinner
<Nephele>
If it only inputs numbers it should accept numbers like this control does
<waddlesplash>
I don't know what needs to be "fixed" about it
<Nephele>
not like the spinner does
<waddlesplash>
what do you mean?
<waddlesplash>
the spinner only accepts numbers
<Nephele>
I already explained the differences above
<waddlesplash>
if you try to type numbers, it won't accept that, no text appears
<waddlesplash>
in the spinner
<waddlesplash>
it does have a text input cursor though, which is great
<Skipp_OSX>
spinners spin a value, in this case a date or time, it doesn't have to be a number
<waddlesplash>
yes
<Nephele>
To recap: No text cursor, no "enter key", no correction after entry, instead *during* entry
<waddlesplash>
yes, and I think this should have all that
<waddlesplash>
aka. it should be a spinner
<Nephele>
This has this
<Nephele>
the spinner does not
<Nephele>
fix the spinner
<waddlesplash>
???
<waddlesplash>
it's just the reverse
<waddlesplash>
the spinner has all those things, this doesn't
<Skipp_OSX>
you have a point on document colors...
<waddlesplash>
spinners DO have a text cursor and correction after reeentry
<Nephele>
waddlesplash: no? the spinner has a text cursor, it *HAS* to have a enter key etc.
<waddlesplash>
yes
<waddlesplash>
this does not have a text cursor
<Nephele>
This doesn't
<waddlesplash>
and it should
<Nephele>
No
SLema has quit [Quit: Vision[]: i've been blurred!]
<waddlesplash>
well, I disagree. I think spinners having a text cursor is 100% the right mov
<waddlesplash>
would you rather retype huge values every time? no, surely not
<Nephele>
In a spinner?
<Nephele>
that goes from 0 to 31?
<waddlesplash>
in any spinner
SLema has joined #haiku
<waddlesplash>
ones that go from 0 to 10000 or whatever
<waddlesplash>
so yes, ones from 0 to 31 for consistency with the huge ones
<Nephele>
So, your argument is: this should be made worse, because you can envision a usecase where a more complex control *somewhere else* could be used?
<waddlesplash>
no
<waddlesplash>
I don't think it's worse
<Skipp_OSX>
yeah it makes sense to use text controls so you can type the values
<waddlesplash>
I like being able to highlight, select, and do whatever else with text in a spinner
<Nephele>
and you want to make this look the same as this more complex control?
<waddlesplash>
even if it's 1-31
<waddlesplash>
yes
<waddlesplash>
I want it to behave the same, too!
<Nephele>
It should not
<Skipp_OSX>
hell you could even use EvaluateTextControl to do math
<waddlesplash>
now that could be neat... hmm
<Nephele>
in a date time entry? why?
<waddlesplash>
no, just in spinners in general
<waddlesplash>
probably doesn't make sense for a date time entry
<Nephele>
... which you want to then use in date time entry
<waddlesplash>
no
<Nephele>
So, you admit they are different
<waddlesplash>
I want date time entry to use BAbstractSpinner
<Nephele>
so why the argument of "you could enter 1000000"
<waddlesplash>
because *spinners should behave consistently*
<waddlesplash>
we shouldn't have random behavioral differences
<waddlesplash>
this is a spinner, it should look and behave like the other spinners, insofar as possible
<Nephele>
Yes, all *date input* controls should behave the same
<Skipp_OSX>
ExpressionTextView that's it
<waddlesplash>
yes, and they are similar to non-date spinners
<waddlesplash>
there are up/down arrows like a spinner. they should just use BAbstractSpinner so the up/down arrows look identical to all other spinners
<Nephele>
Making the arrows be like other spinners, sure, there are good reasons for that. Making this a text control for no reason? no. not really.
<Skipp_OSX>
I thought about using ExpressionTextView so you could say 12+4 and it would give you 16 but you could also do sine and cosign so I thought twice, but still, no reason that you couldn't do simple math in a spinner text control.
<waddlesplash>
it should be a multi-segment text control, like it currently is
<Nephele>
if it doesn't deal with text don't make it a text control
<waddlesplash>
but with a proper text cursor
<Nephele>
multi-segment? that's even worse than having a single one
<waddlesplash>
I don't agree
<waddlesplash>
IP address entry boxes work like this on some OSes, seems fine
<Skipp_OSX>
it could be multi-segment still but with text boxes for each segment
<phschafft>
whatever you do please keep copy and paste in mind.
<waddlesplash>
Skipp_OSX: that too. but that's a bit more annoying
<Skipp_OSX>
yeah, that would be the advantage of a single text box
<Nephele>
why? the text cursor can *only* be used to decide if you want to delete a number from the left or the right in this case, and if there is only one digit it doesn't matter anyway
<Skipp_OSX>
I agree, 1 text box would be better if we could make that work.
<phschafft>
pasting both a full date and it's components *is* very useful. specifically as you often want to avoid typos in dates.
<waddlesplash>
nephele: really we should use 4-digit years
<Nephele>
drag and dropping dates is fine
<waddlesplash>
then there's more than 1 digit :P
<Nephele>
waddlesplash: haha funny. unix32 beeing a bug in our time preferences was iirc my first haiku ticket
<Nephele>
and that damn year 2038 is still aproaching
<waddlesplash>
is it still a bug?
<waddlesplash>
we use 64-bit time_t on everywhere but 32-bit x86
<Nephele>
I think so, atleast on 32bit
<waddlesplash>
oh, not fixable there
<waddlesplash>
it's still on 32-bit time_t and will be due to BeOS ABI
<Nephele>
sure it is, if you break compat *shrug*
<waddlesplash>
so, BeOS compatibility has a sunset date :P
<phschafft>
waddlesplash: ;)
<Nephele>
"BeOS time emulation mode: backwards (x), pretend it's 100 years less ( )"
* phschafft
thinks he should maybe print some 'best before 2038' stickers.
<Nephele>
nice
<Nephele>
waddlesplash: anyhow pretty sure timedate prefs was hardcoding some stuff for 2038, i think i fixed that? but then it does the same for 99
<phschafft>
<humor>backwards? so with 2038 the time ticks backwards? that would be fun!</humor>
<Skipp_OSX>
we need to implement an epoch before 2038
<Nephele>
why is webkit working so badly, what happened
<Nephele>
phschafft: add a second counter of "how many unix32 ends have passed"
<Nephele>
:D
<Skipp_OSX>
The Web+ package got updated I beleive.
<Nephele>
make it a 1bit number because surely we will never need more
<phschafft>
nephele: I have seen that. _many_, _many_ times in code with timestamps.
<Nephele>
yeah but Web+ package gets updated every commit, that makes no difference
<Skipp_OSX>
that's how we got in the situation in the first place...
<Skipp_OSX>
I mean the webkit package tho
<phschafft>
is GPS now 24 or 25 seconds off? ;)
<Skipp_OSX>
HaikuWebkit package
<Nephele>
yeah that's true, but i should know, i'm the other haikuwebkit dev xD
<Nephele>
i think it didn't like me switching color mode
<Skipp_OSX>
oh then idk
<Skipp_OSX>
ah you're in 256 colors still that's why
<Nephele>
well, no longer
<Skipp_OSX>
k
<Nephele>
but it was open meanwhile
<Nephele>
and i got really wierd redraw artifacts... re-opened it now it's gone
<Nephele>
waddlesplash: one difference, my ticket mentions you can't enter "20" as date
<Nephele>
but you can enter 21
<Skipp_OSX>
I was thinking about how to fix my time_t mod dates for thumbnails, we need an epoch. in 2038 epoch goes to 1 for 32-bit, 0 for 64
<Nephele>
i think entering this as one number like this makes sense though
<Nephele>
if you enter 45 as year you mean "2045" etc
<Nephele>
much easier than a text control
<Nephele>
Skipp_OSX: why did you use a 32bit number for that?
<Skipp_OSX>
the odometer rolls over for next 68 years
marzzbar has joined #haiku
<Nephele>
or is this a 32bit only problem?
<Skipp_OSX>
I didn't, I used a 64-bit number, but yes, time_t input given will be 32-bit from Tracker
<phschafft>
it's a common problem with filesystems.
<Nephele>
if it's 32bit only i'd say just ignore it, before 2038 we break the ABI and go native 32bit. Or the architecture is dead and we move shop
<phschafft>
fat fixes it by storing mtime in 2 sec steps ;)
<Skipp_OSX>
yeah only on 32-bit
<Skipp_OSX>
you think we'll have R1 out by 2038?
<Nephele>
Probably. beta5 now is huge compared to beta4, and that was huge compared to beta3
<Skipp_OSX>
We'd need to have R2 out at least by 2038 to retire 32-bit... I'm not optimistic, we should add an epoch.
<Nephele>
I disagree
<Skipp_OSX>
not really, it's only ~600MB base pretty dang small
<Nephele>
If it's native code that does not require beos compat, that you control, just use a 64bit number on 32bit haiku
<Nephele>
Skipp_OSX: i ment huge in terms of improvements, i should have been clearer
<Skipp_OSX>
right which means we'll need to be on R2 or higher by then
<phschafft>
that's about 10 years from now. shouldn't all the BISO batteries have died in 32 bit systems by then?
<Skipp_OSX>
14 years yeah
<Nephele>
phschafft: uhh, i just replaced mine >:(
<Skipp_OSX>
your thumbnails will be invalidated!
<phschafft>
nephele: böser nephele! aus! aus!
<phschafft>
;)
<phschafft>
why not solve it the same as for off_t?
<Nephele>
Skipp_OSX: why? interpreting 32bit times in a 64bit number is fine i think? It would only become a problem if the R1 release has *no* way for native code to use 64bit numbers besides time_t for time
<Skipp_OSX>
actually worse, they may never invalidate, because your odometer rolled over
<Nephele>
phschafft: kostenloser rechner, hat mich bisher nur die bios batterie und strom gekostet :3
<Nephele>
bios batterie ist auch ne art strom
<Skipp_OSX>
sure but the time_t is still a 32-but number so it will roll over, we need the epoch set so that we know to fix it up again for 64-bit.
<phschafft>
so betrachtet ist wasserstoff im all auch ne art strom. ;)
<Nephele>
unless you never use an epoch, and just write the time with a 64bit number once it'd roll over?
<Skipp_OSX>
your timestamps will go from e.g. 1858342435 to 1058 and then it's say, oh the current date is much newer I'm not going to update the thumb.
<phschafft>
Skipp_OSX: as for off_t there is this idea that you define a macro and then get a 62 bit off_t even if off_t would classically be 32 bit on your arch.
<phschafft>
similar could be done for time_t.
<Skipp_OSX>
yeah something like that would work
erysdren has joined #haiku
<Nephele>
be probably need to keep it the same for beos apps, but for haiku native apps (in theory) we can break this more easily
<phschafft>
an epoch is hell to do math with.
<phschafft>
nephele: yes and that's the point. it would become a compile time feature.
<phschafft>
so binaries you already have are compiled without it, and new ones could be compiled with it.
<Skipp_OSX>
don't you just multiply the epoch by by B_INT32_MAX and add it?
<phschafft>
so all that is around as code could just be recompiled with the update and done.
<Skipp_OSX>
so 0x B_INT32_MAX or 1x
<Skipp_OSX>
seems like pretty simple math to me
<phschafft>
Skipp_OSX: if you define the epoch as always the upper bits. but then in another 10 years someone will come up with a 'clever' idea....
<phschafft>
plus you need to write a*(int64_t)B_INT32_MAX + b when you just want to write a.
<Nephele>
I'm sure c++ can abstract that away with black magic
<phschafft>
keep in mind that you also need to pass that epoch around on *all* syscalls that use timestamps.
<Nephele>
the risk of summoning demons isn'
<Nephele>
t /that/ high
<waddlesplash>
we can break syscall ABI easily
<phschafft>
also doing it alike off_t would mean to use a solution that has already been found. ;)
<waddlesplash>
it's userland ABI that's a problem
<waddlesplash>
phschafft: off_t is already 64bit everywhere
<waddlesplash>
on Haiku
<phschafft>
waddlesplash: yes, what I really mean is stuff that provies syscall access. so standard libaries etc.
<phschafft>
*libraries
<phschafft>
waddlesplash: but not on other systems.
<Skipp_OSX>
no we have to add an epoch field to the data structure and then it will work for thousands of years
<Nephele>
openbsd has 64bit time_t on 32bit ;)
<phschafft>
waddlesplash: think about e.g. something that can set a timestamp on whatever object. you would need a setter that includes the epoch. on the syscall level that might be easy. but every use needs to correctly pass it.
<Skipp_OSX>
openbsd was thinking ahead...
<Nephele>
Skipp_OSX: honestly, i'd much prefer the simple solution of "just a bigger number"
<Skipp_OSX>
We really should be using doubles everywhere we use floats now on 64-bit...
<Skipp_OSX>
since doubles are 64-bit we'd get more precision... I blame Be.
<phschafft>
Skipp_OSX: I think using double for time_t got removed from POSIX. ;)
<phschafft>
(yes, it was valid at some point!)
<Skipp_OSX>
well not for time_t for our interface kit I mean
<erysdren>
32-bit floats are fine imo
<Nephele>
what does precision matter if you do something as vague as "drag a slider between pixel A and B to represent float 0...1"
<Skipp_OSX>
well there's no performance penalty to use double on 64-bit machines is all.
<Nephele>
yeah, but a memory penatly, to?
<Skipp_OSX>
It matters when you are printing because you have sub-pixel resolution, at least that's the idea.
<phschafft>
Skipp_OSX: I think that is also true for 32 bit intels? beside the higher transfer load.
<Nephele>
for rendering to a bigger canvas maybe. But not for the logical value of the slider
<Skipp_OSX>
no because on 32-bit Intel you have 32-bit registers.
<Skipp_OSX>
so double takes 2 registers
<Skipp_OSX>
but on 64-bit you have 64-bit registers of course.
<phschafft>
but you should store them in the FPU to begin with?
<phschafft>
I mean when they're in the CPU you can't do much with them.
<Skipp_OSX>
well sometimes you have 128-bit or even 512bit registers but that's a different story
<Skipp_OSX>
you get finer resolution on print *shrug*
<Nephele>
that reminds me
<Nephele>
the printing test page uses OS colors .-.
<Nephele>
instead of using white as a background
<Skipp_OSX>
pixel doubling algorithms get more accurate half pixels, stuff like that.
<Skipp_OSX>
anyway, it's not a big deal, but if we're going to break compat, we should switch to doubles.
* phschafft
secretly sets nephele's background colour to green.
<Nephele>
phschafft: I would not see it
<Nephele>
my background image is a "windows 10 dark mode" window xD
<phschafft>
when I look out of my 10 windows it's also dark right now.
<Nephele>
I think my windows have lead in them
<Nephele>
so i don't want to aproach them too much
<Nephele>
Still have twitter on my social blocklist
<Nephele>
pfft, that's like the first UI tip posted xD
<Nephele>
we should really make the UI easier to read for dragging them
<Nephele>
waddlesplash: is that mentioned in the userguide btw?
<waddlesplash>
no idea, didn't look
<waddlesplash>
nephele: tell me more obscure UI tips and I will get them posted to the social media then :P
<Nephele>
How do you post as Haiku? is that just a normal account with credentials or also hooked up to some git repo?
<waddlesplash>
it's a normal account with credentials
<waddlesplash>
the Inc. has them of course, and various people have access
<Nephele>
More obscure UI? You can click the Screen preferences screen to get into the background preferences
<phschafft>
the copy of the guude that is on the standard install is very helpful btw. thanks for whoever write it AND included it for offline reading.
* Nephele
only "wrote" the dark mode for it
<phschafft>
nephele: we know you're from the dark side. no need to tell it every time. ;)
<Nephele>
waddlesplash: also color dropping onto deskbar from appearence prefs could be good to show
<waddlesplash>
what's the use of that?
<Nephele>
I think that is quite hard to discover
<Nephele>
To show how it works?
<waddlesplash>
nephele: what am I dragging?
<Nephele>
err, i ment deskcalc
<waddlesplash>
I just tried it, nothign happened
<waddlesplash>
ah
<waddlesplash>
that makes more sense :P
<waddlesplash>
neat! will add that to a note
<Nephele>
you can also drag it into stylededit
<Nephele>
... it converts it to a hex color, lol
<waddlesplash>
nephele: ooh, it works for ActivityMonitor panels
<waddlesplash>
and for the graph colors
<Nephele>
that's quite cool, didn't know that one either
<Nephele>
another obscure UI tip: the keycaps in keymap are draggable to reorder keys on the fly, no layout needed
<Nephele>
apparently ctrl-g makes backspace... huh
<Nephele>
and control i is backspace, and thus ctrl i works as twitcher shortcut... uhhh
<waddlesplash>
dragging keycaps in keymap changes the keymap
<waddlesplash>
but yes, that's a good one
<Nephele>
yes
<Nephele>
but you don't need to have a predefined one for what you want
<Nephele>
you can even hold a key like ctrl, and then drag out of charactermap
<moparisthebest>
What, I wish I'd known that
<waddlesplash>
nephele: okay, that one I didn't know
<waddlesplash>
definitely going on the list
<Nephele>
lol, i just figured this out simply by trying it :D
<moparisthebest>
Can you change what it sends when shift is held independently ?
<waddlesplash>
moparisthebest: even if the Keymap GUI did not support this, our keymap format is a pretty sane text format
<waddlesplash>
(well, the human-readable version of it is)
<waddlesplash>
so you could just generate it from a spec file if you have one probably
<Nephele>
haha, now i can add emoji to my keyboard triggered with altgr/super
<Skipp_OSX>
unforunately our keymaps need work still
<moparisthebest>
Most just don't support shift swapping behavior at all
<waddlesplash>
you can get the text format back out of Keymap too, just get the "current" file and decompile it with the keymap CLI
<Nephele>
moparisthebest: what do you mean by that though? not that i misunderstand you and you mean something like differentiating lshift from rshift
<phschafft>
nephele: for systems that actually support multiple clocks I would suggest to allow to create a clock with base clock and an offset and then set that to be the default RTC. for system that don't support multiple clocks just add a per-process offset.
<waddlesplash>
nephele: Lshift and Rshift can be handled independently on Haiku
<waddlesplash>
well, I mean, the physical keys
<Nephele>
but not in the keymap
<Nephele>
it's the same level
<waddlesplash>
oh
<waddlesplash>
yes, right
<waddlesplash>
I meant the physical LShift key can be something other than LShift
<Nephele>
same problem we have with super and alt-gr right now
<Nephele>
yes, sure
<moparisthebest>
ie the \ key sends | when shift is held period. I want it to send | without shift and \ when I'm holding shift
<phschafft>
nephele: that would allow the user to have a compatibility mode as they like (e.g. -100 years or -10 years, or -82.28 years). an UI might then provide some basic values for easy selection.
<Nephele>
moparisthebest: huh? don't most OS just use mode shift for that?
<Nephele>
like send letter n when it isn't held and N when it is
<Nephele>
with both beeing fairly independent?
<Nephele>
I think X11 worked similar like that
<Nephele>
just having more modes possible than we have
<phschafft>
the cost for that should be relativly small as it's just an addition. (in contrast to condition that will interact with the CPU's pipeline in a more destructive way)
augiedoggie_ is now known as augiedoggie
<Nephele>
waddlesplash: hmm, more obscure stuff... You can restart the desktop from Team Monitor if it crashes completely, and open a terminal
<waddlesplash>
idk how obscure that is, but ok
<Nephele>
well, beeing able to restart the desktop is i think?
<erysdren>
random question for the room, but is BGLView still the intended way to make 3D applications under Haiku?
<Skipp_OSX>
nephele please +1 my analog clock change now, I've switched back to DOCUMENT colors and it's about as close to hard-coded colors you can get without hard-coding colors.
<Nephele>
erysdren: currently yes, but we really want to use EGL in the future
<erysdren>
got it
<waddlesplash>
nephele: I think Skipp_OSX's Clock change is a good one
<waddlesplash>
maybe it's not perfect, fine
<Nephele>
that is, there is some work for it, but last i heard that doesn't quite work and crashed mesa or something
<waddlesplash>
we can work more on it later
<Skipp_OSX>
it preserves the "aesthetic integrity" of the original while allowing dark mode clock
<Nephele>
waddlesplash: uhh, that is beside the point. the version nipos had before was better, tying this to random UI color constants is worse
<waddlesplash>
?
<waddlesplash>
it's not random at all
<Nephele>
It's not a document.
<waddlesplash>
seems like one to me
<waddlesplash>
Skipp_OSX: if nephele really wants hardcoded light mode vs. dark mode constants, I don't object tbh
<Skipp_OSX>
it pretty much already is.
<Nephele>
Exactly, if we want a specific rendering of the clock we should just do that, and not hook it up to color constants and then heavily limit their effective range to get the colors we wanted in the first place
<Skipp_OSX>
the clock is either black on white or white on black
<Nephele>
so use white and black
<Skipp_OSX>
I did
<Nephele>
Is the document color even pure white? I doubt it. Besides you picked a semantically wrong color that just happens to be this currently, but me setting some random document color should not mess with the clock
<Skipp_OSX>
yes it is
<Skipp_OSX>
yep
<Nephele>
and before you say "no" this is actually needed if you want for stylededit to print with a specific background ;)
<Nephele>
and colors it lets you set for the foreground
<Skipp_OSX>
whelp I tried, way to go holding up progress
<Nephele>
You asked me before what would be required, i answered, you ignored my answer. and now you acuse me of holding up progress? ... cool
<Nephele>
StyledEdit prints white on Black in dark mode, by the way
<Skipp_OSX>
yup, I took what you said, and ignored it because it was bad, so keep your -2 and I guess the clock will never get updated.
<Skipp_OSX>
yeah because you gotta change document colors individually I guess, same with clock
<Nephele>
StyledEdit prints what it sees
<erysdren>
another fight in #haiku, we love to see it*
<erysdren>
*lying
<Skipp_OSX>
huh?
<Nephele>
waddlesplash: too bad the mastadon interface has no good way to download your clock video
<Nephele>
and in webpositive it does not play :)
<Nephele>
maybe I should work on making it play
<Nephele>
Too bad there is no primer for working with the media apis
<Skipp_OSX>
see now you have an orange and cyan clock and Styled Edit document, since that's what you customized, but by default you get black or white.
<Nephele>
yep. This effect Sure seems undesireable to me.
<Skipp_OSX>
well yeah but it matches the colors you picked, I picked ugly colors
<Nephele>
and it prooves my point why those should not be hooked up, it makes no semantic sense
<waddlesplash>
?
<waddlesplash>
StyledEdit should absolutely use the document colors by default
<Nephele>
Yes?
<Skipp_OSX>
it is
erysdren has quit [Quit: Konversation terminated!]
<Skipp_OSX>
now you get an olive clock, not black or white.
<Skipp_OSX>
that's the idea.
<Nephele>
I get your point. I still disagree.
<x512[m]>
erysdren: Methods other than BGLView are currently have unstable API.
<Skipp_OSX>
ok well, there's no pleasing you then I guess.
<x512[m]>
BitmapHook will be likely changed.
<Nephele>
Well, if you really want to push that one specific point I don't want then I guess there is no "pleasing" me
<waddlesplash>
nephele: Skipp_OSX does have a point
<waddlesplash>
the clock being olive makes sense when the theme is olive
<waddlesplash>
it's what I'd expect anyway
<Nephele>
waddlesplash: Not really, we went over this before. If it is a control, it should use control colors and then it can follow them, and look like a control
<Nephele>
but if this is a skeumorphic image then it should be hardcoded, with optional color drops
<waddlesplash>
okay. so either it should use CONTROL color primary or DOCUMENT color primary
<waddlesplash>
nephele: no, I don't agree
<Nephele>
but not follow unrelated colors
<Skipp_OSX>
yes we went over it, that's not true, because we use document color for text boxes and stuff
<waddlesplash>
we can quibble about which color constant to use here, CONTROL or DOCUMENT
<waddlesplash>
but the fact is, it should use one of them for its background
<Nephele>
No, neither.
<Skipp_OSX>
right
<waddlesplash>
nephele: yeah, sorry, I don't agree, and I can't imagine other Haiku developers will agree either
<Nephele>
If this is stays a "wall clock like" rendering then it should stay hardcoded
<Nephele>
If you change this to a proper control then it can use control colors
<waddlesplash>
nah, I don't agree at all
<Skipp_OSX>
nah, it should be olive in olive theme.
<waddlesplash>
your wall clock should match your drapes
<waddlesplash>
wall clocks are plenty of colors other than white
<Skipp_OSX>
yes, hardcoding colors is bad, that was my whole point. You demand hardcoded colors, I demand not hardcoded colors.
<Nephele>
It should if it *
<Nephele>
*isn't* a skeumorphic design
<Nephele>
if the design stays like it is the colors stay
<Skipp_OSX>
it's white by default, that's what is important
Coldfirex has joined #haiku
<Nephele>
none of the OS colors match this semantically, and introducing ones for a clock only is a bit pointless
<Skipp_OSX>
ok so use document, done
<phschafft>
if it would be hardcoded as in not follow the selected system colours; how would you change the colours then? are there additional overrides? e.g. xclock has that.
<Nephele>
phschafft: yes, simply dropping colors onto it
<Skipp_OSX>
color drops I guess is his preferred method
<phschafft>
nephele: ok, the Haiku way.
<Skipp_OSX>
but you can color drop in addition to using system colors so that's not a real solution.
<phschafft>
(I like drag and drop, at least if it's done correctly.)
<phschafft>
and to be clear here: this was just a question, not an hidden argument for any side.
gouchi has quit [Remote host closed the connection]
<x512[m]>
> another fight in #haiku, we love to see it*
<x512[m]>
And even me is unrelated.
<phschafft>
what did I read somewhere else? 'the discussion was higly controversion! I was in it!'
<Nephele>
Skipp_OSX: my whole point is: hooking it up to logically *unrelated* color constants is worse than hardcoding it. Is this a document? It isn't. You can argue that it is a control, but then the control colors should be used properly and not tinted to hell to create a completely different rendering
<Nephele>
If we want this (skeumorphic) completely different rendering, then just stick to it like it is now. nothing lost
<Skipp_OSX>
and my whole point is that hardcoding is bad, and document works the way we want it to allowing you to customize, and that it is semantically correct.
<Skipp_OSX>
we use document color for white background with black text everywhere, even if not a document like on a text control, I was wrong about that.
<Nephele>
It is not semantically correct because this is not a document. And it suprises me that you want to argue this way now, where before you were quite adamant that it is a control.
<Skipp_OSX>
yeah but it turns out that's not actually how we use those color constants.
<Nephele>
If we use them incorrectly elsewhere that isn't a reason to do that more
<Skipp_OSX>
sure there is
<Nephele>
we should use the color constanst where they fit logically, and nowhere else
<Skipp_OSX>
it's just that the meaning of the color is not what you think it is.
<Skipp_OSX>
nah, we should use them everywhere we want to customize colors that way, which is what we do.
<Nephele>
if we need to add more color constants later we can revisit this, but if you start using this everywhere where you think you want "black" you end up in a situation where customizing the OS becomes really hard since there is no way to know what the sliders will do
<Skipp_OSX>
I was mistaken before, that's all, document is correct afterall.
<Skipp_OSX>
well they update live now so it's pretty easy to tell.
<Skipp_OSX>
even before it wasn't that hard.
<x512[m]>
What color constant is used for list control background? I suppose clock is thr same case.
<Nephele>
uhh, no. you'd have to open every affected application, which you can't
<Nephele>
x512[m]: lists have their own color set
<Skipp_OSX>
list controls use a special list background color
<Nephele>
also for selected item and such
<Skipp_OSX>
although they could be document I suppose, and were before introducing those constants
<x512[m]>
By this logic it should be separate clock background color...
<Skipp_OSX>
controls are for gray backgrounds, buttons essentially.
<Nephele>
controls are for mouseinteractable controls
<x512[m]>
Clock is technically a control where you can drag arrows to adjust time.
<Nephele>
x512[m]: yes, if there were constants for it (and this rendering is kept) that would be the case. Or we make this look more like a control by using control colors
<Skipp_OSX>
correct, but text control is also technically a control but it uses document color for bg
<Skipp_OSX>
we've been through all this
<Nephele>
Skipp_OSX: We might also think if there is room for a private color api for apps that works the same, for example team monitor vision etc
<Skipp_OSX>
hmmmm
<Nephele>
that is colors that register in the same way sounds register for the sound preferences
<Nephele>
maybe even with an api call for how those should be calculated in the automatic color code
<waddlesplash>
this sounds like too much
<waddlesplash>
we can just use document color
<waddlesplash>
if it is a problem we can change that later
<waddlesplash>
"Sane defaults with configuration where it makes sense"
<waddlesplash>
not sure what's the exact wording but that's one of our mottos/goals
<waddlesplash>
let's not add configuration unnecessarily
<waddlesplash>
I will +2 the change, let's see what other developers have to say
<Nephele>
we can merge patchset 5 as is
<waddlesplash>
I prefer patchset 10
<Nephele>
Anyway, we already have an easy way to configure this with the color drops
<waddlesplash>
well, I added +2. let's see what other developers say
<waddlesplash>
nephele: sure, and we can add that, but the default colors without drops should come from system colors.
<Nephele>
No need to go backwards and start using document colors for unrelated stuff
<waddlesplash>
you can keep arguing but so far you are just going in circles at this point
<Nephele>
You are bending backwards to try and justify this is somehow a document
<x512[m]>
With StyledEdit there are another problem that use can select arbitrary color for text, so having non-white background color can make text unreadable.
<waddlesplash>
nephele: well, I don't think so. and I think you've already said this. So you're still going in circles
* phschafft
makes some fresh popcorn.
<waddlesplash>
let's see what other devs say and if they +2 or what. it will be a little ridiculous if we have to do a roll call vote over a change like this
<Nephele>
Yes, it would be. I'm not sure why you are so strongly oposed to this now where you said hardcoded colors are find before *shrug*
<Skipp_OSX>
ok well, you can keep your -2 vote but it's all a big misunderstanding
<Skipp_OSX>
It was wrong before I guess, so now it's fixed, so that's good
<waddlesplash>
nephele: I am fine with patchset 5 but I think patchset 10 is better.
<Nephele>
patchset 5 and patchset 10 create inverted renderings waddlesplash
<waddlesplash>
?
<waddlesplash>
how do they create "inverted" renderings? the clock is white in default light mode colors and black in default dark mode colors
<Nephele>
in 5 the clock is still black on white in dark mode, just with a toned down background
<waddlesplash>
okay
<Nephele>
mainly because the dark mode inverted clock looks terrible without the shadows
<waddlesplash>
so, patchset 5 is an improvement on the status quo, and patchset 10 is an improvement on patchset 5
<waddlesplash>
that's how I see it
<waddlesplash>
so, I prefer patchset 10 ultimately
<Skipp_OSX>
yeah but that's on purpose
<Skipp_OSX>
black on black does not work very well,
<Nephele>
No, patchset 3 or 4 did that already. anyhow. Without the shadows it looks quite bad, which is one big reason to not simply drop in the colors from document
<Skipp_OSX>
I mean, I don't mind it that much, I could live with it.
<Nephele>
Skipp_OSX: well, it is black hands but a middle gray background
<Skipp_OSX>
it has the shadows...
<Nephele>
so it's just a bit muted compared to the light mode
<Skipp_OSX>
it should
<Skipp_OSX>
hmmm yeah I guess you're right
<Skipp_OSX>
it should be exactly inverted from light mode, that's the intent anyway
<Skipp_OSX>
maybe the colors are there they are just hard to see on black
<Nephele>
no :( inverted renderings don't look good in dark mode
<Skipp_OSX>
they don't?
<Nephele>
In generall, no. the thing is that shadows don't have the same "punch" in such a mode, and they look like they are facing the wrong way. in a pure invertion they look like an underglow for example instead of a shadow
<Nephele>
also the lighten/darken constants usually look quite bad if you just replace them 1:1 for a dark mode rendering
<Nephele>
so the patchset5 is a bit of a compromise to have a light mode clock, but muted a bit for less contrast, without having to redesign it completely now so it looks good in the dark mode
<Nephele>
the light mode version looks like a control, barring the too little saturation for the stripes which make it look disabled
<Nephele>
but the clock looks quite "lifted" from the UI in dark mode, which is not that pleasent. while it should instead "recede"
<Nephele>
but I'm not sure if the dark mode control colors are set correctly for that
<Skipp_OSX>
well this is all ok feedback, I'm not as concerned about the exact tints used, just that they are based on color constants
<Skipp_OSX>
I just did a straight up invert on the colors... so I guess that's why... if only we had functions that could give me the right light and dark mode colors...
<Nephele>
well, that was my point though. I originally wanted to keep the original rendering for light mode, but I am not open to simply dropping that one
<Nephele>
so I would be fine with the control colors variant, but without it beeing tinted so heavily that it tries to immitate the original, since I don't think that color constants should be used with such heavy modification
<Nephele>
s/not open/now open/
<Nephele>
what function are you missing? I guess a hsl based color tinting? :g
<waddlesplash>
btw, random aside: we swapped out the web analytics platform for haiku-os.org, and the new one does OS detection rather than just hit counting
<x512[m]>
waddlesplash: Do this patch change something with default color settings?
<phschafft>
Just make all green on black!
<waddlesplash>
Haiku seems to be about 5% of hits on haiku-os.org
<Nephele>
analytics? plasphemy!
<waddlesplash>
nephele: pretty sure it respects DNT, so just set that if you dpn
<waddlesplash>
don't want it
<Nephele>
waddlesplash: maybe discourse can be updated to not count webpositive as Safari on Webkit
<Nephele>
waddlesplash: do we have that in webpositive?
<waddlesplash>
no idea
<Nephele>
i'm not sure tbh
<waddlesplash>
x512[m]: no
<Nephele>
I'm wondering if OS detection would be illegal under EU law, hmmm. I know detecting an adblocker is illegal because you are extracting "information about the used terminal"
<waddlesplash>
nephele: of the Haiku users, 82% "Safari" (Web+), the rest I guess is Falkon
<Nephele>
probably os detection is fine since it is broadcast
<waddlesplash>
it's detecting it through the user agent
<Nephele>
yeah, that's what I mean
<waddlesplash>
if you don't want it to be detected, use a different user agent, or set DNT
<Nephele>
it's volunteered info xD
<Nephele>
I wonder how much would break if we used an empty UA
<waddlesplash>
anyway it's just pretty cool to see
<Nephele>
:)
<waddlesplash>
once we get Gecko/Firefox, I bet the numbers will go up as people start to use Haiku more
<waddlesplash>
Falkon is fine but the browser chrome really needs work
<Nephele>
dunno, we already have Web on gtk and that didn't help either much
<arraybolt3>
does the version of qtwebengine used by it stay up-to-date regularly?
<arraybolt3>
by Falkon I mean
<waddlesplash>
arraybolt3: unfortunately not
<Nephele>
not really
* arraybolt3
is always scared to use Falkon because of qtwebengine vulns
<arraybolt3>
ah blargh
<Nephele>
it's still stuck on old icu version
<waddlesplash>
someone got Qt6 WebEngine with a recent Chromium to compile
<arraybolt3>
double blargh
<waddlesplash>
but it crashed on startup
<waddlesplash>
nephele: no, that got fixed
<Nephele>
well, it's basically chromium what do you expect? :( it's a blackbox that's hard to update
<waddlesplash>
arraybolt3: QtWEbEngine itself is basically "Chromium ESR"
<arraybolt3>
yep, I know
<waddlesplash>
it gets patches beyond the chrome release
<waddlesplash>
nephele: ? it's not a black box
<waddlesplash>
it's just a really complex piece of software
<arraybolt3>
but unless the package is kept up-to-date it'll have vulns
<waddlesplash>
Firefox is the same way
<arraybolt3>
anyway, if I care enough I can go fix it
<Nephele>
yes, one that prefers not to use OS libraries for anything it can implement itself instead
<waddlesplash>
arraybolt3: if you manage to get Qt6 WebEngine to run without crashing we will all be happy I'm sure :)
<Nephele>
i'm still warry of firefox and it's privacy implications
<Nephele>
not sure how much we can disable per default or patch out and still be allowed to call it firefox :)
<waddlesplash>
the Firefox UI has all these little niceties that will take us years to get in WebPositive
<arraybolt3>
I can count the number of times I've fixed a web browser on zero hands...
<Nephele>
maybe it's waterfxox then?
<waddlesplash>
we should work on that, but it will take a while
<x512[m]>
nephele: WebKitGTK is now updated for a while and it is already outdated. It stopped to open GitLab for example.
<x512[m]>
not updated
<Nephele>
x512[m]: huh? but webpositive still does?
<waddlesplash>
Web+ uses a more recent WebKit than WebKitGTK now probably
<waddlesplash>
we need to update WebKitGTK, I suppose
<Nephele>
what do you mean with probably? it sure didn't before the last update :D
<Nephele>
the last previous version was from february
<Nephele>
unless the webkitgtk version is even older?
<waddlesplash>
WebKitGTK may be older than that
<x512[m]>
Note that GTK 4 can be built and run without problems if needed.
<Nephele>
x512[m]: anyway yeah, github is also quite annoying for maintinaing out webkit port since it often breaks and doesn't do feature detection properly
<Nephele>
instead it spams the web console and gets one core to 100% by doing that .-.
<waddlesplash>
the modern web is really just sad in a lot of ways
<Nephele>
Indeed :(
<Nephele>
but hey, i got webpositive to mostly use system colors for everything xD
<Nephele>
maybe I can also add the forced colors mode
<x512[m]>
GitLab is worst Git web interface.
<Nephele>
I tend to agree, it's only advantage over github is it is open source, but other than that? ehhhh
<Nephele>
Microsoft Edge on windows uses a forced colors mode if you set windows into high contrast mode
<x512[m]>
Yes. Maybe it is a reason why it is used for Freedesktop projects.
<Nephele>
basically websites get a set of colors they should be forced to use, instead of picking their own
<waddlesplash>
what would be really nice is if one of the upstream Firefox or Chromium developers took an interest in Haiku and helped us with these ports
<Nephele>
no chance of that happening
<Nephele>
chromium doesn't even care for BSD
<waddlesplash>
Chromium, probably not, Firefox, that's not impossible
<Nephele>
and firefox well, they barely care about linux