<nekobot>
[haiku/haiku] 87c4aa1308ad - arm64: Remember to switch address spaces on context switch.
<nekobot>
[haiku/haiku] 087c7dd65424 - arm64: Small fixes extracted from larger MMU fixup.
erysdren has joined #haiku
<waddlesplash>
oanderso[m]: PAN is ARM's version of SMAP?
<oanderso[m]>
I wasn't aware of either of them previously, but it appears so!
<waddlesplash>
makes sense
<waddlesplash>
we do indeed support SMAP/SMEP on x86_64
<waddlesplash>
fixed a lot of bugs once we enabled them... lot of carryover code from BeOS that didn't originally use user_memcpy/memset/etc.
<oanderso[m]>
Fun times
<oanderso[m]>
Maybe we'll get there some day on arm64
<oanderso[m]>
A lot more basic stuff to do first :-)
<waddlesplash>
:)
<oanderso[m]>
I've teased out most of the "easy" bits from the MMU patch... now I have to dive in on the core of it
<waddlesplash>
certainly easier than writing it all from scratch though, I'm sure
<waddlesplash>
oanderso[m]: btw, debugging trick you may find useful: since you are so early in the boot that you probably don't have input in KDL, you can put KDL commands inside panic messages
<oanderso[m]>
KDL is the kernel debugger?
<waddlesplash>
our nickname for it, yes
<waddlesplash>
"Kernel Debugging Land"
<oanderso[m]>
I have input to it in my serial console
<waddlesplash>
from the opening message, which is a throwback to BeOS days
<waddlesplash>
ah! well, that's good then
<oanderso[m]>
So far I've gotten by with dprintf and a lot of staring at the code ;-)
<waddlesplash>
well anyway the syntax is panic("message goes here... @! page -m %p")
<waddlesplash>
or whatever else
<waddlesplash>
the KDL commands are often really useful, especially the page-related ones
<waddlesplash>
oanderso[m]: if you are in QEMU, the gdbstub does work
<oanderso[m]>
I anticipate I'll need that eventually
<waddlesplash>
I only started using it this year, but it made debugging most things SO much easier
<waddlesplash>
no need to guess, dprintf(), recompile, boot VM, etc. just attach debugger and inspect away
<waddlesplash>
if you use some of the fancier GDB commands to force it to use a specific stack frame address you can get past interrupt frames too
<waddlesplash>
of course if you are a LLVM person you may prefer LLDB here
Begasus[m] has quit [Ping timeout: 480 seconds]
win8linux[m] has quit [Ping timeout: 480 seconds]
x512[m] has quit [Ping timeout: 480 seconds]
xylobol[m] has quit [Ping timeout: 480 seconds]
<oanderso[m]>
It took me a looong time to retrain my muscle memory from GDB to LLDB, not sure I could go back now
<waddlesplash>
lol, understandable
<waddlesplash>
I use debuggers mostly with GUIs so I don't have a lot of muscle memory there
<waddlesplash>
btw, it is (or rather, it once was) more-or-less possible to build Haiku with Clang
<waddlesplash>
needed a couple hacks in the build system but IIRC I did get it to boot to desktop
<waddlesplash>
may have bitrotted since, I should try it again
<oanderso[m]>
If I get it to build on arm64 with clang then the circle will truly be complete!
<waddlesplash>
lol, well I only tested with x86_64
<waddlesplash>
part of the problem is that we don't have a fully upstreamed Clang driver
<waddlesplash>
there is some code upstreamed but it's not a full driver, it calls out to gcc to link and stuff like that
<waddlesplash>
there is some more work at HaikuPorts on this but I don't know that it fully matches our GCC specs
zayd has quit [Quit: ZNC 1.8.2+deb2+deb11u1 - https://znc.in]
<waddlesplash>
aha, looks like some of it did get upstreamed
<oanderso[m]>
I'm an LLVM committer if you need help with that
<waddlesplash>
yes, I saw, very neat
<waddlesplash>
I'm looking through our patches now to see what we have that's not upstreamed but would be a candidate
<waddlesplash>
oanderso[m]: looks like most of the remaining patches are either minor or maybe not complete enough to upstream
<waddlesplash>
biggest ones are a libunwind impl for x86_64 at least
<waddlesplash>
but it has some TODOs
<oanderso[m]>
I could look at that
<waddlesplash>
yeah looks like the libunwind code uses private headers to get the signal handler addresses... that may need rework
<waddlesplash>
though admittedly the only other way to get this information is to invoke a private syscall to get the symbol table for the commpage
<waddlesplash>
hmm. how do other OSes expose this info?
leahc has quit [Read error: No route to host]
dominicm has quit [Read error: No route to host]
zayd has joined #haiku
erysdren has quit [Quit: Konversation terminated!]
leahc has joined #haiku
<waddlesplash>
lol, looks like libunwind hardcodes this information for linux
<waddlesplash>
and I'm not even sure if this code supports the BSDs at all, I don't see any #ifdefs
<waddlesplash>
WIN32, AIX, APPLE, and LINUX, an eclectic set of platforms
zardshard has quit [Ping timeout: 480 seconds]
dominicm has joined #haiku
_-Caleb-_ has quit [Ping timeout: 480 seconds]
<waddlesplash>
oanderso[m]: looks like the signal stuff is the only part of libunwind not upstreamed, and yeah that may not be upstreamable in present form
cleo has quit [Ping timeout: 480 seconds]
<waddlesplash>
so, it actually looks like llvm/clang trunk should be able to have all that's needed for -target haiku... to work
<waddlesplash>
so I should dig out my old notes and rehabilitate the port
nipos has quit [Ping timeout: 480 seconds]
<waddlesplash>
> Jun 18, 2018
<waddlesplash>
wow, was it really that long ago that I last tried this? huh
<waddlesplash>
oanderso[m]: btw the format bot isn't infallible
<waddlesplash>
for simple stuff it's generally right but sometimes its suggestions don't make sense and should be disregarded
<waddlesplash>
it's powered by https://github.com/owenca/haiku-format/ , a fork of clang-format with a bunch of modifications and stuff added (IIRC upstream wasn't interested in a number of the things we needed/wanted)
<waddlesplash>
(and even then it's still incomplete compared to our coding guidelines)
<oanderso[m]>
<waddlesplash> "WIN32, AIX, APPLE, and LINUX, an..." <- I believe the BSDs ship their own version of libunwind, and nobody has yet cared about replacing it
<waddlesplash>
yes, that sounds right
zardshard has joined #haiku
<Skipp_OSX>
heyo
<oanderso[m]>
waddlesplash: Actually, the docs claim it works on FreeBSD and NetBSD
<waddlesplash>
x512[m]: it looks like your patch also had LTO options but this one doesn't
xylobol[m] has joined #haiku
<waddlesplash>
oanderso[m]: well, I've fixed the buildsystem and made some other tweaks to get clang builds working again, but there's some cruft and bitrot that needs fixed before clang builds work properly again on x86
<x512[m]>
waddlesplash: LTO supports seems already added in later patches.
<waddlesplash>
I'll work on it more tomorrow
<waddlesplash>
x512[m]: ah, ok
Begasus[m] has joined #haiku
<x512[m]>
waddlesplash: In theory it should be easier to build Haiku riscv64 with Clang because it do not need special things like boot loader mixed 32/64 bit code.
<waddlesplash>
possibly
<waddlesplash>
well, I'll let you try that once I push these cleanup patches
<x512[m]>
Clang already support cross compiling out of the box.
<x512[m]>
No need to build separate toolchain.
<waddlesplash>
right, yes
<waddlesplash>
but I've never gotten a Haiku build linked with LLD and the other LLVM tools to boot to desktop
<x512[m]>
I got it once, but it was several years ago.
<waddlesplash>
on RV64 or x86?
<x512[m]>
x86
<x512[m]>
It is almost purely Jamfile fixes.
<waddlesplash>
I tried this before and IIRC it just crashed or otherwise behaved oddly and I didn't dig into why
<waddlesplash>
../src/add-ons/kernel/partitioning_systems/common/PartitionMapWriter.cpp:115:17: error: static assertion failed due to requirement 'kMBRSize <= sizeof (partitionTable.code_area)': static assert failed!
<waddlesplash>
oh yeah, this one again
<waddlesplash>
IIRC the MBR assembled with Clang is just too large
* waddlesplash
hacks it out
Begasus has joined #haiku
<Begasus>
g'morning peeps
<nekobot>
[haiku/haiku] e8911390bbcf - netresolv: Move some definitions around for Clang compatibility.
<botifico>
[haikuports/haikuports] lonemadmax 7e0d7a1 - Qt5: Look for SSL library with version 3 suffix
Coldfirex has quit [Remote host closed the connection]
<Begasus>
PulkoMandy, already switched Qt6 here for openssl3, want me to push those to haikuports?
<Begasus>
just checked scummvm, still launches without changes
<PulkoMandy>
You can tick the checkboxes in uhe ticket so I know someone is already looking into it, that should be enough to not do the work twice
<PulkoMandy>
Push it when it's ready :)
<Begasus>
did a readelf on the "installed" libraries here, this was my list (prior to the changes done in the meantime here): https://bpa.st/DYHA
<PulkoMandy>
I don't have most things installed here so I checked from the recipes only. So maybe some things in my list are already doing openssl3, but I'm going to add it explicitly to the recipes, I think it' a good idea to track it this way
<Begasus>
right
<Begasus>
wen't for what I had installed here in the first place (like I did with tracking icu/boost ...)
<PulkoMandy>
I think we managed to make them share the same directories in the end?
<Begasus>
yeah, just wanted to be sure, I'm not having any problem with that here
nipos has joined #haiku
<Begasus>
only reference for ssl in the qt6 patches
<Begasus>
will do further testing first, maybe 3dEyes is already on it :)
<nipos>
Good morning. Did anything network-related change around hrev57982? I heard it should have become a lot faster, but I'm currently installing updates around 50KiB/s. The package server isn't the bottleneck, as my OpenIndiana computer connected to the same router downloads from eu.hpkg.haiku-os.org at 27.2MB/s. It must be something directly related to the Haiku computer that slows it down. I don't have anything
<nipos>
else running besides the Terminal where I run pkgman
SLema has quit [Ping timeout: 480 seconds]
<Begasus>
g'morning nipos, no one around I guess that familiar enough to answer :)
<nipos>
BTW,Renga doesn't support file uploads,right?
<Begasus>
The dark mode one looks ok to me, I prefer the original light one though
<nipos>
That's what I expected :/ It's the result of using B_COLOR constants that are customizable in the Appearance preferences, instead of hardcoded colors as the current version does
<nipos>
Alternatively I could offer two hardcoded sets of colors - The light one, unchanged, and a new set for dark mode. But then someone on the Review page will tell me not to hardcode random colors again
<Begasus>
heh, choices :)
<nipos>
If there's so few feedback here,I'll upload it to review as-is now and then we'll see what people say.Changes can still be made later.
<nipos>
nephele suggested a idea on Review that may solve both the configurability concerns and the difference in appearance. Investigating that right now :)
<Nephele>
We should really develop a HSL api before beta6 and move a lot of this code to it, mix_color and tint_color only give "aproximate" results, it pretends rgb is on a linear scale in respect to the color components when it really isn't
<Habbie>
hsl! one of us!
<Nephele>
so it gives "somewhat" okay results, but never great ones
<Nephele>
Habbie: hmm?
<Habbie>
sorry, been doing lots of HSL recently (outside of Haiku) and i like it much better than RGB
<Habbie>
my FPU-less CPU is less of a fan, but oh well
<Nephele>
Nice, maybe we can sucker you into doing this api ;)
<Nephele>
/s
* Nephele
is trying to find blu-ray players that claim HDMI CEC support, but it unsucessfull thus far
<nipos>
I agree that HSL would be the best solution in the future, but I'm not the right one to develop it, so I'm doing short-term fixes that make dark mode more usable
Anarchos has joined #haiku
<Nephele>
Yep, I'm not asking you to develop the api, which is why I suggested mix_color :)
<nipos>
By the way, can you maybe have a look at Pull Request 7943 that improves the Keymap Preferences? Has gone unnotices since 19th August
<Begasus>
meep: 2024-08-24 13:43:53 KERN: runtime_loader: Cannot open file libthai.so.0 (needed by /boot/system/lib/libQt6Core.so.6.7.2): No such file or directory
<Anarchos>
hello
<Begasus>
we don't have that :P
<Begasus>
Hi Anarchos nephele Habbie :)
<Anarchos>
Begasus wopw
<Anarchos>
wops runtime_loader :)
<Nephele>
nipos: for 7943 the keykaps are hard to read in dark mode
<Nephele>
hi Begasus
<Begasus>
doesn't lock down anything, so it's still good :)
<nipos>
That's a result of the too light button gradients which is a different issue, I think?
<Nephele>
nipos: may be a problem with the controllook gradient for buttons, perhaps that can be improved
<Nephele>
Yes, sure. But in isolation this change makes the keymap worse in dark mode right now, so we should fix the button rendering in the same change or a prior one
<nipos>
I hoped you'd do the hard one :P Okay, I'll try to look into it once Sudoku is done
<Nephele>
Sure I can do that :)
<Nephele>
Just mentioned that I won't be in favor of merging 7943 before the button gradients are fixed, but I can fix them :)
<Anarchos>
is there a driver developer around ?
<Nephele>
Technically pulkomandy gave me that title... but since I don't want to claim responsibility for your issue by saying "yes", it's better to just ask your question :)
<nipos>
At Sudoku, it's the ValueHintBackground and HintValueHintBackground that needs mix_colors, right?
<Nephele>
whatever constants currently use color to signify meaning
<Nephele>
I also wouldn't use sucess color as that pairs with error color, and doesn't mean the same thing semantically in this context
<Coldfirex>
@waddlesplash: very relevatn regarding clang! I had just started looking into that topic last night before bed. I saw it was mentioned during Beta 1's release.
<nipos>
It does, actually. It makes text green if all values are correct. I thought it's better to use the actual constant for it instead of the hardcoded one
<Nephele>
nipos: no, this color just happens to be green currently ;)
<Nephele>
that's the thing, if it doesn't mean the same semantically the underlying color can just be changed, and it would not mean the same thing anymore
<Nephele>
I can just aswell use blue for sucess and orange for failure
<Coldfirex>
How do we make jam use clang?
<Nephele>
CC=clang CXX=clang++ ?
<Nephele>
Anarchos: what do you want to have from that?
<nipos>
If you want blue for success, why should we override it? The success color means your solution is correct, that makes perfect sense to me
<Nephele>
sucess is "this operation completed sucesfully"
<Anarchos>
nephele a driver for the accelerometer in my laptop
<Nephele>
Haiku doesn't do anything with accelerometer data
<Anarchos>
nephele not yet ;)
<nipos>
success can alo mean your game was solved successfully
<Nephele>
nipos: i don't want to semantically overload those constants
<Nephele>
it's perfectly fine to pick a color for the game and stick with it
<Anarchos>
nephele a first thing is that i could learn to write driver... a second would be to shutdown hard drive when acceleration is too high (eg the laptop is falling on the floor)
<nipos>
Okay, going back to the hardcoded stuff than
_-Caleb-_ has joined #haiku
<nipos>
It's worse, but whatever, you can read green and red on both light and dark background
yann64 has joined #haiku
<Nephele>
Why? just use mix_color?
<nipos>
For those where it makes sense, yes
<Nephele>
Anarchos: Yes, but that leaves the question: what do you want this driver to do? should it just expose a device file? should it transport the events to input_server and you want to write a input filter there? in essence, what should Haiku do with the driver, to hook it up
<nipos>
red and green don't need any changes. I only used the constants here because I thought it makes sense to have them configurable. If that's not wanted, I'll simply revert that
<Nephele>
Depends on if the contrast is high enough between those constants and whatever your background is
<Begasus>
is it known that WebPositive uses a lot or ram?
<Begasus>
almost 3GB atm here
<Anarchos>
nephele no idea how sensors drivers are used on haiku. i don't know anything about input server .
<Nephele>
yeah, those are things you should figure out beforehand
<jmairboeck>
nephele: red and green can be a problem for some people to distinguish. It would be good if the colors are customizable somehow.
<PulkoMandy>
It doesn't change much about the driver
<PulkoMandy>
The driver will publish the data in a device file in some format. Then userspace can use that in any way needed
<Nephele>
that's one way PulkoMandy, another would be to let userspace talk with acpi directly to hand off this stuff
<Nephele>
or do it with system calls
<PulkoMandy>
If you want to make things extra complicated for no reason, yes, these are valid options
<PulkoMandy>
Otherwise,
<PulkoMandy>
You can just write a driver :)
<Nephele>
Hmm, well I'd assume there are severall of such acpi drivers that could be written in userspace "easily" but may not make that much sense to have in kernel space ;)
<Begasus>
k, plasmatube runs ok with qt6 6.7.2, let's see if it builds also with it :)
<Nephele>
WebPositive is eating all my RAM again, would be cool to be able to see what it allocates and why
<Nephele>
(in the sense of which website did that)
<Begasus>
same here nephele, it's running better then on beta4 (use it mostly exclusive now)
<Nephele>
Begasus: webpositive?
<Begasus>
yes
<Nephele>
I'm hoping I can get my webkit build server to behave and then implement font fallback cascades properly
<Begasus>
Falkon having some issue also (with threads peaking)
<Nephele>
ideally with teaching app_server to accept a fallback list from a client
HaikuUser has joined #haiku
HaikuUser is now known as JackDaniel
<Nephele>
jmairboeck: yes that is true, Haiku is quite lacking generally in accesibility
<JackDaniel>
Hi there! Can I run bash scripts by double click on them in Haiku? If so, how can I do that?
<Nephele>
Sure, add "#!bash" as shebang, make them executable, and then double click them
<JackDaniel>
ok, let's see if this works! Thx!
<Nephele>
you can right click in tracker click get info and then check the executable bit in the permission tab
zard has joined #haiku
<JackDaniel>
I did that but this doesnt work. Here is the bash script:
<JackDaniel>
#!bash cd /boot/home/Workbech/Documents/GAMES/NES/
<Nephele>
but usually problems with bash/shell are "user error" because it is just so darn hard to write correct shell scripts :/
<JackDaniel>
yeah, I know, but thats not the case
<JackDaniel>
I tried again and it doesnt work
<JackDaniel>
lets see what alert show
<JackDaniel>
lets see what alert shows
* zard
doesn't believes that there is "user error" regardless :P
<JackDaniel>
the alert shows the correct path
<JackDaniel>
the script also works if I run it from terminal
<JackDaniel>
so we have a little bug here
<Nephele>
Did you write "alert $?" after the cd line?
<Nephele>
it should show "0"
<zard>
oops. /me *believes* that there is "user error" regardess
<JackDaniel>
alert $ shows only a $
<Nephele>
No, "alert $?"
<Nephele>
not alert $
<JackDaniel>
?
<Nephele>
write out "alert $?" in the script, without the quotes
<Nephele>
not "alert $"
<JackDaniel>
ok
<JackDaniel>
so I put alert $ - without quotes. It shows an alert with a $ sign and thats it
<Nephele>
No, "alert $?". not "alert $"
<Nephele>
the question mark is important
<Nephele>
it's a special variable that holds the exit code from the previous process
<JackDaniel>
thats funny :)
<JackDaniel>
ok, it shows 0
<Nephele>
then the cd suceeded
HaikuUser has joined #haiku
<JackDaniel>
after the cd command
<JackDaniel>
so the problem can be mednafen?
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<Nephele>
In your simplified version you run Island.zip, but the long version has Hudson\'s\ Adventure\ Island1.zip
<Nephele>
Does it work now with just "mednaffen Island1.zip"?
<JackDaniel>
if so, why when I run the script from termina it works?
<Nephele>
mednfafen*
<JackDaniel>
if so, why when I run the script from terminal it works?
<Nephele>
... That's what we are trying to determine, no?
<JackDaniel>
I guess so
<JackDaniel>
If you have other ideas, let me know
<Nephele>
alert $(command -v mednafen)
<Nephele>
to see if it found mednafen
<Nephele>
(without the explicit path)
<JackDaniel>
hmm, it sais /bin/mednafen
<Nephele>
okay, then it found it
<JackDaniel>
I guess the correct path is different
<Nephele>
then alert $? after the mednafen line to see if it suceeded to open
<Nephele>
the exit code there would be mednafen specific
<JackDaniel>
nope, it sais 255
<Nephele>
you can also do mednafen myfile 2> logfile.txt to make it log stderr to that file, and then check if mednafen wrote any errors into that file
<Nephele>
255 means an error occured
<JackDaniel>
nice
<zard>
Woot! Progress :)
<Nephele>
what mednafen means with that is specific to mednafen
<Nephele>
0 is sucess all other numbers are "programm specific" in shell script
<Nephele>
and all mean failure
<JackDaniel>
I
<JackDaniel>
Im ok with that
<JackDaniel>
we know there is nothing wrong with executing bash scripts in general
<Nephele>
:)
yann64 has quit [Read error: Connection reset by peer]
<JackDaniel>
thank you for helping me!
yann64 has joined #haiku
JackDaniel has quit [Quit: Vision[]: i've been blurred!]
yann64 has quit [Read error: Connection reset by peer]
yann64 has joined #haiku
* Nephele
resumes on the quest to find a blu-ray player
<Nephele>
nipos: the color contrast between Red number and yellow bg is bad in dark mode. Do you have a light mode screenshot?
* Nephele
is afk for a while, but will read responses later here or on the review tracker
Nephele has quit [Quit: Vision[]: i've been blurred!]
yann64 has quit [Ping timeout: 480 seconds]
yann64 has joined #haiku
<nipos>
If I change something in the ControlLook and then compile any application from the Haiku source tree, does that use my changed ControlLook or does it use the one from system? I can see that it always recompiles HaikuControlLook.cpp when I changed the file, but I never see any visual differences.
<botifico>
[haikuports/haikuports] jmairboeck 68706a7 - r: bump version, build with openssl 3 and libpaper 2
<PulkoMandy>
nipos: You have to recompile libbe and use that recompiled version with your app
<PulkoMandy>
Either put libbe in a lib/ folder next to the app executable, or in system/non-packaged/lib for example
<nipos>
Thanks, will try that later :)
zardshard has left #haiku [Error from remote client]
zardshard has joined #haiku
<nipos>
Another question/interesting find: Tracker uses B_TOOL_TIP_BACKGROUND_COLOR and B_TOOL_TIP_TEXT_COLOR for the "Open with" window application list.That looks bad here,since the text is white in dark mode and the background stays bright yellow.Wouldn't B_LIST_BACKGROUND_COLOR and B_LIST_ITEM_TEXT_COLOR make a lot more sense for an actual list?
<PulkoMandy>
I don't know why this is yellow
<PulkoMandy>
maybe it should use the same color as query results and read-only directories
<nipos>
Checked the query view and yes,that looks good here in dark mode
<nipos>
Oh,and I found a bug in Renga: The text color of the text input field doesn't change after the application was launched.I started it in Light Mode and now I can't use it in Dark Mode because I get black text on black background then
<waddlesplash>
nipos: if tool tip backgrounds don't look good in dark mode then we should fix that
<nipos>
Previewing changes to the ControlLook works great using LD_PREVIEW, but previewing changes to Tracker seems impossible as it always immediately restarts itself when killed
<waddlesplash>
put the new libbe.so in non-packaged/lib then
<nipos>
waddlesplash: You're right, that's also something I should fix. But does it make sense to use Tool Tip Background for a list view in a window?
<waddlesplash>
but you can also tell launch_roster to not restart Tracker
<waddlesplash>
nipos: I mean, it's a backgrounds color, it should have sufficient contrast with the text color
<waddlesplash>
but this has always been yellow in light mode as long as I can recall
<nipos>
Tracker seems to ignore the libtracker.so in the non-packaged directory
gouchi has joined #haiku
<nipos>
Okay, some more research for the Tool Tip stuff...
<nipos>
It seems there is actually an automatic setting, but it depends on the window tab. So if I leave the window tabs default yellow, I get a bright yellow tool tip in dark mode. That's probably intended, but I don't like it.
<nipos>
Also, the text color stays black when tool tips are bright yellow, so I can read them just fine. In the Tracker "Open with" view, however, the text becomes white and unreadable in dark mode. The window uses B_TOOL_TIP_TEXT_COLOR for text color, but maybe something else influences it later so that it turns out white
spiro has joined #haiku
<Skipp_OSX>
A tool tip inside Open with... window becomes white and unreadable or some other text?
<nipos>
No, the whole list becomes unreadable because Tool Tip Background (bright yellow) is used with white text
<Skipp_OSX>
ok yeah that makes sense, Open with... window probably not using color constants
<nipos>
It does use B_TOOL_TIP_BACKGROUND_COLOR for the list,but it probably shouldn't
<nipos>
It's defined in OpenWithWindow.cpp at line 574
<Skipp_OSX>
I see, it sets the view color and the low color but not the hight color....
<Skipp_OSX>
*high
<Skipp_OSX>
We should probably not be using the tooltip colors there but let's see what happens if we set the high color to tooltip text color... nope no good, so something else must be setting it
<nipos>
What happens if you just delete the two lines that define the tool tip colors there?
spiro has quit [Remote host closed the connection]
<Skipp_OSX>
It looks like that sets the bg colors so I could change those but has no effect on the foreground (text) colors
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
nosycat has joined #haiku
HaikuUser has joined #haiku
<nipos>
Yes, but not overriding the background color at all would probably produce a usable result (looking like the Query results view, if we're lucky)
<Skipp_OSX>
well we want the yellow background for tradition, see a29f0661ceefc2b25f5fce46a6465ff22a596c77 for that
<nipos>
Then this is probably the right place to hardcode something rather than using Tooltip colors, and offer two versions, dark and light
<waddlesplash>
let's start by fixing the colors in question
<waddlesplash>
to not be hardcoded
<waddlesplash>
I mean, to actually use TOOL_TIP_TEXT
<Skipp_OSX>
It appears to me that we have to set the high color in Draw() method, it's ok to set the bg color on AttachedToWindow() but not the fg color for some reason
<botifico>
[haikuports/haikuports] ... and 10 more commits.
yann64 has quit [Remote host closed the connection]
yann64 has joined #haiku
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
<Skipp_OSX>
I see... it's a bit more complicated because we are using TextWidgets and so we have to set the TextColor and BackColor for selected and unselected states.
<Nephele>
Those gradients already look better nipos
<nipos>
Thanks :) I've already put it on Review
<Skipp_OSX>
I do think that the gradients are a bit much on dark mode
<nipos>
That's already half as much we had before
<Nephele>
Skipp_OSX: this new version or the current version?
<Skipp_OSX>
current version
<nipos>
Oh, then I agree
<Nephele>
Skipp_OSX: can you check the screenshot I quoted, does that look better?
<Nephele>
nipos: is that the generated control background color in the screenshot btw? it's a bit bright still
<nipos>
Yes
<Nephele>
Okay, so that could probably be adjusted to be a bit less bright too for more contrast with text and background
<Nephele>
anyway, regarding what waddlesplash said on the changeset1: Drawing in haikucontrollook can never use the constants. This is because it is sometimes asked to be drawn by different components in another context
<Nephele>
for example haikuwebkit will sometimes *deliberately* draw controls in the light mode style, while the OS is in dark mode
<nipos>
_DrawNonFlatButtonBackground uses tint_color(base, 0.7); which is probably the cause for this
<CRThaze>
Anyone else having issues refreshing HaikuPorts? I'm a new HaikuOS user, and I'm getting an error only on that repo. I'm using the eu one.
<nipos>
I already changed it to use base, and he was right
<Nephele>
CRThaze: beta4? that's currently disabled
<nipos>
Are you on Beta4? Then you can't update until Beta5 is out
<Nephele>
nipos: you can adjust the default light mode color to compensate, that's not a problem
<CRThaze>
nephele: ah yeah. r1beta4. Thanks for the link
<nielx[m]>
HaikuDepotServer is back online!
<Nephele>
anyhow, waddlesplash, nipos. I think with the imminent release of beta5 we should keep those developments on master? That gives us more room to break stuff intermitently :)
<nipos>
Maybe we don't even need to compensate for anything?I think it looks good,there's no huge difference in light mode
<Nephele>
nipos: why do the keycaps looks so different to the buttons in light mode?
<nipos>
It wasn't the 0.7 tint,by the way,but the B_LIGHTEN_1_TINT one
<Begasus>
can't I block posts at the forum when ranting is going on (again) on github? :P
HaikuUser has joined #haiku
<Nephele>
Begasus: yes, scroll down to the end of the topic and change tracking status to ignore
<Nephele>
or muted
<Begasus>
it just starts in another thread nephele :)
HaikuUser has quit []
<nipos>
I find it great that so many people care here
<nipos>
Fuck Micro$oft btw
<nipos>
I already stopped contributing patches to Serenity because of this crap. Would have been a shame to also be locked out of Haiku
<Nephele>
nipos: just fyi, I do agree with most of your points, but your forum replies to that come off as quite negative :)
<Skipp_OSX>
looks bit better yes, the top and left lines are still too bright too much contrast
<Nephele>
Skipp_OSX: you mean from the keycaps? so the "shine" on the upper left?
<Nephele>
I would agree there, those can probably be muted a bit more
<Skipp_OSX>
yes, the keycaps, well any button really. It, not the shine that's the problem it's the border color.
<Skipp_OSX>
It looks nice in light mode, but in dark it has too much contrast
<Nephele>
B_CONTROL_BORDER_COLOR might not be set correctly
<Nephele>
hmm, though this does not seem to impact rendering buttons in any way...
<nipos>
B_CONTROL_BORDER_COLOR isn't used for that
<Skipp_OSX>
it's probably just a tint that goes too far in one direction vs the other
<Skipp_OSX>
it's been that way for a long time
<nipos>
Also,for the different looks of keycaps and other buttons: If I remember right,the keycaps aren't actual buttons but only made to look like it.But in the previous version,the background was a bit darker in dark mode,I should change that again
<Nephele>
nipos: light mode keycaps have a different color for control chars and letters, that is completely missing in your light mode screenshot
<Nephele>
I think we should keep that
<Nephele>
and also have this in dark mode
<nipos>
Did you have a look at the screenshot in the Pull Request?
<nipos>
If you're talking about the thing I think you are,then you can see the different colors there
<nekobot>
[haiku/haiku] 90b84ff20914 - ArchitectureRules: Cleanup and adjustments for Clang.
<Nephele>
I looked at your screenshot above with light mode
<Nephele>
pull request?
<waddlesplash>
oanderso[m]: ^^ after yesterday's changes plus that, I can build x86 images mostly with clang+lld and (with some hacks) get them to boot to the desktop
<waddlesplash>
oanderso[m]: the hacks are about building the MBR loader and BIOS loader, so on ARM64 EFI that may not be needed at all and things may "just work"
<nipos>
nephele: The dark keys still exist in my updated version,I just checked that.They're less noticable the darker you make it,but technically I never removed them and in the light mode they're unchanged
<Nephele>
I think it is better now
<Nephele>
nipos: I guess it is strange that some keymaps don't have that though
nipos has left #haiku [Disconnected: Received SIGTERM]
<Nephele>
but anyway, it should be a bit more prevalent in the dark mode
nipos has joined #haiku
<nipos>
The keymaps have it,but some keyboards don't
<nipos>
I played around with it a bit and had it set to Apple Aluminium Extended (US)
<nipos>
The generic 104 keys keyboard has the different colors and I think that's the default setting
dby has joined #haiku
<nipos>
I pushed the improved ControlLook to Review again. If that gets accepted, I'll further improve the Keymap application. Switching between so many patches using Git isn't that comfortable
<nipos>
Are you comparing the keycaps or the actual libbe Buttons?
<Nephele>
I was looking at the keycaps. Do you have more changes loaded in that screenshot?
<nipos>
The keycaps looking different is related to another commit and will slightly change again.
<Skipp_OSX>
clearly the bottom screenshot is the one we want
<Skipp_OSX>
the top looks washed out, it's white instead of gray
<nipos>
The keycaps,yes,I thought we were talking about the libbe changes?
<nipos>
Ignore the Keycaps then,only look at the normal buttons
<Skipp_OSX>
nah, no idea on libbe.so changes
<Nephele>
It was not clear you had other changes also loaded. The buttons look fine
<Skipp_OSX>
but keycaps are normal buttons...
<nipos>
No
<Nephele>
Skipp_OSX: Kinda, but nipos has other changes loaded. The keycaps are not "just" a rendered button
<nipos>
They're only styled to look like normal buttons,but technically they're different
<Skipp_OSX>
no? because of the rounded edges I guess
<nipos>
You can even drag and drop them
<Skipp_OSX>
yep
<nipos>
And they may use different colors,so they're not suitable to vote on libbe changes
<Nephele>
what do you mean with styled? don't they use the ControlLook to render?
<nipos>
The installed Keymap application has keycaps hardcoded to light gray,my changed version makes them use B_CONTROL_*_COLOR constants but it isn't perfect yet,that makes them too white
<Begasus>
while you're at it, maybe someone could have a look to add dark mode at the buildmasters frontend? ;)
<waddlesplash>
oanderso[m]: ^^^ tried a Clang arm64 build, it got pretty far after those 2 changes but the kernel failed to link with "error: relocation R_AARCH64_ABS64 cannot be used against local symbol; recompile with -fPIC"
<nipos>
The buildmaster CSS stuff looks rather simple,I can add a dark mode if you want
<nipos>
But I won't touch M$ Github.Someone else needs to upload it then
<waddlesplash>
oanderso[m]: so it seems the Clang haiku compiler spec still differs from GCC here somehow, or there's some other misconfiguration. I also had to add a hack in CreateAsmStructOffsetsHeader1 because the assembler Clang generates has "//define" instead of "@define"
<waddlesplash>
oanderso[m]: but, it looks like it's not far off from something you could use to develop with, if you want to look into that further :)
<Nephele>
hehe, you can send the patch to begasus :P If he wants the dark mode he can probably open the PR on github
<Nephele>
jmairboeck: thanks
<Nephele>
too bad my screenshot key is not the same screenshot key as the one that opens the screenshot app (printscreen)
<Nephele>
but they just had to change this up, fun.
<nipos>
It's been a few months since I did web development the last time,but I'll look into it today or tomorrow
<Skipp_OSX>
you got me messing with Desktop colors now and it's tricky
<Nephele>
Skipp_OSX: desktop colors will look wrong no matter what if somebody adds a background image
<Skipp_OSX>
however the Desktop works is how it works, I didn't write the code and I'm afraid to touch it for fear of breaking something
<Nephele>
we should just add more pronounced text shadow for the desktop
<Skipp_OSX>
I mean but we do have a text shadow
<Nephele>
yeah, i saw afterwards that you (only) moved the code
<Skipp_OSX>
sure it ain't ever going to look good on every background
<Nephele>
it needs to be legible, not neccesarily look good
<Nephele>
Skipp_OSX: I think we have some kind of text shadow (as in i recall seeing code for that) but atleast on my desktop background this doesn't work at all
<Nephele>
It's white text, and if i place it on white background parts of the desktop image i can't see the text anymore
HaikuUser has joined #haiku
HaikuUser has quit []
<Skipp_OSX>
you have to turn on "Icon label outline" in Background
<nekobot>
[haiku/haiku] 946839b8500e - ArchitectureRules: Remove lines for -Werror for FreeBSD drivers.
<waddlesplash>
nephele: ??? where else would it be?
<waddlesplash>
it's literally just a Tracker icon view
<Nephele>
It's not *just* a tracker icon view, otherwise there would be no need for all this special casing
<waddlesplash>
okay, but lots of views in tracker have special casing
<waddlesplash>
like the file panel
<waddlesplash>
so that doesn't prove anything
<Nephele>
and among other things that you *cannot* open the Desktop folder is really confusing
<Begasus>
I'm not involved in website PR's :)
<waddlesplash>
nephele: you can under Navigator mode
<Nephele>
it proves that your assertion of "it's just a a icon view" is wrong
<waddlesplash>
and actually on R5 (or at least R5 MAX + OpenTracker) you could
<waddlesplash>
on my R5 VM, I can open the Desktop in a window in icon view. it looks funky, with the background and everything inside a window
<waddlesplash>
but it works fine
<Nephele>
add replicants to that also, which makes it much easier to crash tracker for no real gain
<Nephele>
You can add background images to other folders too if you want
<waddlesplash>
yes
<Nephele>
We should let the Desktop be opened in tracker, and not unfocus everything apart from the desktop as a "gotcha" :P
<Nephele>
in *every* mode
<waddlesplash>
well, we used to, but I think it was changed due to the "spatial" arguments
<waddlesplash>
I personally always use Navigator mode, so, I don't really care what happens in spatial mode
<waddlesplash>
that's for the rest of you to fight about :P
<Nephele>
what spatial arguments? spatial arangements keep working even if you switch to list mode and back
<Nephele>
uhhh... navigator i.e "single window mode" vs not single window mode has nothing to do with spatial ordering of items
<waddlesplash>
no, that's not what spatial means
<Begasus>
err ... samba4 enabled?
<waddlesplash>
nephele: "spatial mode" means only one window is open for one directory at a time
<Skipp_OSX>
you can't open the Desktop in spatial mode on purpose, the idea is that each window only exists in one place, so the Desktop only exists on the Desktop never in a window
<waddlesplash>
so if you double click on a directory that already has a window, it brings that window to the front
<Nephele>
No. spatial means "in a position in the view". You can do that in both modes fine
<waddlesplash>
no
<waddlesplash>
that isn't what the word means here
<Nephele>
removing the ability to jump to a directory with the input line doesn't make it any more spatial
<Begasus>
PulkoMandy, did you testdrive samba4?
<waddlesplash>
nephele: it does. the Desktop is the one view of the desktop folder in spatial mode
<waddlesplash>
"The base requirements of a spatial file manager are: 1. Each folder is represented by a single window."
<Skipp_OSX>
yeah it's how spatial file managers work since days of ye old Classic Mac OS
<PulkoMandy>
Begasus: No, just checked it builds. I figured it would be ok, you can keep samba 3 installed if you prefer that
<Nephele>
waddlesplash: and that is acomplished by removing the navigation Icons how?
<Nephele>
You can still use key up you know?
<Skipp_OSX>
Of course it is completely arbitrary we could make Desktop open in a window in spatial mode if we wanted to, but we don't.
<Begasus>
I still have an update on the 4 version (PR is up) with a bit of explanation PulkoMandy
<waddlesplash>
nephele: yes, but key up opens a new window
<Nephele>
and you can still use open "directory" in the terminal to open a specific window
<waddlesplash>
yes. but again, the windows don't change directory
<Nephele>
... so what?
<waddlesplash>
every navigation to a new directory opens a new window in spatial mode
<Nephele>
this has nothing to do with hiding the navigation bar
<Begasus>
it builds, but the debug hangs were caused by using the cmd's in UserBootScript
<waddlesplash>
it does, because the navigation bar doesn't make sense in spatial mode
<Nephele>
it makes perfect sense
<waddlesplash>
doesn't to me, idk
<Skipp_OSX>
no, Open parent does not open Desktop window in spatial mode
<Begasus>
well, with the latest version *
<Nephele>
you just remove the button which *still* has a shortcut
<Nephele>
Skipp_OSX: it erronously opens the home directory instead, which is not what the user requested
<Begasus>
bbl
<Skipp_OSX>
maybe there is a bug, how?
<Nephele>
and that is exactly the problem, the desktop is special cased like this, and it doesn't make sense
<Nephele>
and it also has nothing to do with hiding the navigation bar, which would work just aswell in spatial mode
<Skipp_OSX>
how do you open the home?
<Nephele>
Skipp_OSX: ah, nevermind. That was a symlink, and tracker resolved that fully before opening the new view
<Skipp_OSX>
I guess you're saying in Navigation mode it opens home, but that's what should happen... I guess
<Skipp_OSX>
actually, it shouldn't but that's a long story
<Nephele>
Anyhow, allowing multiple tracker views at once to a single directory has nothing to do with: using list vs icon mode, or showing the navigator bar
B2IA has quit [Quit: Vision[]: i've been blurred!]
<Nephele>
and Desktop behaving this strangely and requiring constant special casing is exactly why i don't think it belongs in tracker
<Skipp_OSX>
that is all correct, yes
<Skipp_OSX>
but the "Single window navigation" setting should switch between allowing Desktop in a folder or not regardless of the "Show navigator" setting
<nekobot>
[haiku/haiku] 9d4d102df214 - Tracker: Override Open with... pose view text color and back color
<Nephele>
I think tracker should not consider the Desktop as an "open window" in single navigation mode
B2IA has joined #haiku
<Nephele>
it's not visible to a user that this is a window in any form, or that tracker is responsible. With a desktop with no applications started it only looks like tracker is an erronous entry in Deskbar
<waddlesplash>
alternatively, opening Desktop when Tracker is in spatial mode should just minimize all open windows
<Nephele>
I think it should just open in an actual window
<Nephele>
and all the special casing should not apply in that window, and just treat it as a normal icon view folder. No replicants etc.
<Skipp_OSX>
yes, that's the alternative... what we need is the ability to easily minimize and unminimize all windows intelligently so that when you open the desktop everything gets minimized but then we put the previous windows back when you click.
<Nephele>
we already have scripts to do that
<Skipp_OSX>
yeah it's in the Show Desktop patch that some seem to not like that much for some reason
<Nephele>
but there is no way for a user to indicate to un-minimize if the action that minimized was clicking "Desktop" in tracker
<Skipp_OSX>
basically we need to "Show Desktop" when you open the Desktop in Spatial mode
<Skipp_OSX>
right, and we need that part too
<Nephele>
I disagree, since the desktop is not a window
<Skipp_OSX>
right it's not a window, but since you activated it, you want it to come to the front, which means everything else goes to the back.
<Nephele>
Skipp_OSX: that is even more special casing. Any action you do on the then visible desktop (like opening something) with just open that
<Nephele>
and should *not* unmimizie everything
<Skipp_OSX>
correct, more special casing
<Skipp_OSX>
why not?
<Nephele>
how should a user distinquish between them having minimized stuff, and tracker having done so? both look like an empty desktop with entries in deskbar
<Skipp_OSX>
the "Show Desktop" should be temporary, it's rude to minimize everything permanently.
<Nephele>
there is no visible distinction that would make it apparent that you are somehow in a different mode
<Nephele>
this is hidden state
<Skipp_OSX>
yes there should be a visual distinction
<Nephele>
So let's just open a window instead
<Nephele>
that can be closed when the user is done
<Skipp_OSX>
in macOS which you know I love, it puts a semi-transparent gray background border around the Desktop
<Nephele>
Yes, I know. But that is only for user action no? I think clicking the desktop once?
<Skipp_OSX>
nah we can't do that, it would violate the spatial paradigm
<Skipp_OSX>
clicking a blank area of the Desktop or double clicking the Desktop folder in Home or if you say downloaded a file from WebPositive to the Desktop and then click "Open containing folder"
<Nephele>
Let's just show a window with the desktop in icon mode
gouchi has joined #haiku
<Skipp_OSX>
And then you click a blank area of the Desktop or click on anything that is not a file like Deskbar or another app and everything comes back
<Skipp_OSX>
are you even listening to what we're saying?
<Nephele>
No more special casing for the desktop
<Skipp_OSX>
The one thing we cannot do is just "show a window with the desktop in icon mode"
<Nephele>
Yes we can
<Skipp_OSX>
MORE special casing for Desktop
<Nephele>
No, just remove this code from tracker and simplify it
<Skipp_OSX>
well yeah ok we can, but it would violate the spatial paradigm
<Nephele>
and then tracker can just open the Desktop folder when asked to open the Desktop folder
<Skipp_OSX>
there's a reason that we don't do that, and even though you don't understand the reason doesn't make it a bad reason.
<Nephele>
It was imported from opentracker like that, is the main reason.
<Skipp_OSX>
no
<Nephele>
But that does not say anything about the future
<Skipp_OSX>
no
<waddlesplash>
I agree with Skipp_OSX here
<waddlesplash>
there are more things inside DesktopPoseView than just the spatial awareness code
<Skipp_OSX>
Literally there is a deeper reason that has nothing to do with what you said.
<Skipp_OSX>
It's not just because we imported the code, and it's not something that is subject to change in the future.
<Skipp_OSX>
It is the spatial paradigm, for better or worse.
<Nephele>
Sure it is, we can change what we want in tracker.
<Nephele>
And we don't have to follow something wikipedia sais about technology, if we can do better, like using layouts instead of a hardcoded font size, we can do that
<Skipp_OSX>
Well yeah that's true, we can change what we want, but we don't want to change this as you say in spatial mode because it would violate the sacred contract of one window per folder
<Nephele>
But there is no place for "I know better than you, and just accept that". If you have a discussion with me that is fine though
<Nephele>
It would not violate this at all, The Desktop is not a window
<Skipp_OSX>
yeah it's just a consequence of the spatial paradigm
<Skipp_OSX>
sure it is a window
<Nephele>
No
<waddlesplash>
the desktop is a "view" under spatial paradigms
<Skipp_OSX>
yes, it is
<waddlesplash>
so, yes, it qualifies
<Nephele>
I am aware app_server considers it a window
<Nephele>
but no user would
<Skipp_OSX>
it literally is a window
<waddlesplash>
it's a view into the filesystem
<waddlesplash>
that's what matters here, not whether it's a "Window" or not
<Nephele>
so why justify it to a user that there is a *technical* reason behind it
<Skipp_OSX>
yeah but the point of the spatial paradigm is that a window can only appear in exactly one location at a time
<waddlesplash>
it's not a technical reason
<waddlesplash>
it's how the spatial paradigm works
<Skipp_OSX>
right, it's not a technical reason, we chose to make it this way on purpose.
<Nephele>
waddlesplash: i don't think that is a good way to think about it, yes it shows folders, but it also shows other stuff, like replicants, that are not present at that location in the file system
<waddlesplash>
yes, they are. at least virtually
<waddlesplash>
the replicants should show up if you open the Desktop in a window
<Skipp_OSX>
you can actually have replicants on more than just the Desktop
<waddlesplash>
yes
<Nephele>
why?
<Skipp_OSX>
nobody does this, but theoretically you could make an entire app out of replicants.
<Nephele>
making an app out of replicants is just loading shared libraries .-.
<waddlesplash>
yeah, we have the replicant shelf example in tests
<Skipp_OSX>
no it would be a dynamic app that you could change on the fly
<Skipp_OSX>
theoretically anyway...
<Nephele>
replicants are a threat to program stability, and especially for tracker, i don't think this is a good idea to run in the same process as the actuall windows you use
<Nephele>
The desktop crashing should not crash the other tracker windows you have
<waddlesplash>
that's a different consideration etirely
<waddlesplash>
whether or not the desktop runs in a separate process is a technical consideration separate from all these questions
<Nephele>
It is one aspect of the consideration of Desktop beeing special cased
<waddlesplash>
no
<Nephele>
Yes it is
<waddlesplash>
we could run a Tracker process that just had the DesktopPoseView
<waddlesplash>
and nothing else
<waddlesplash>
and it would still share all the code
<Skipp_OSX>
well, yeah replicants are unsafe that's true in general, you're injecting a view into a window
<Nephele>
Sure? why don't you?
<Nephele>
That's the main problem I see right now. But you claimed you can just put replicants in whatever folders, unless i misunderstood something there
<Skipp_OSX>
not just folder
<Skipp_OSX>
you can put them in apps too
<Nephele>
Skipp_OSX: tracker views then.
<Skipp_OSX>
not just Tracker
<Nephele>
... I am aware how the replicant api works
<Skipp_OSX>
ok so then you already know all this
<Nephele>
Does tracker load replicants in icon view in random folders?
<Nephele>
or only on the desktop?
<Skipp_OSX>
no, just on Desktop
<Nephele>
Then we should have the Desktop be in a seperate process
<Nephele>
and additionally hide Tracker from Deskbar when only the Desktop is visible
<Nephele>
or, have an entry for the Desktop you can click to minimize applications
<Nephele>
you could click it again to un-minimize
<Skipp_OSX>
I tried to do that but people didn't like it.
<Skipp_OSX>
well not the remove Tracker from Deskbar part
<Nephele>
I attempted to do that (with showing the window) but could not get it to work
<Nephele>
I think we should do either one of those
<Skipp_OSX>
Unfortunately adding and removing menu items is trickier than it should be
<Nephele>
menu items?
<Skipp_OSX>
yeah Deskbar is using a menu so Tracker and everything else is a menu item
<Nephele>
The views to the bottom are a menu? o_0?
<Begasus>
closing down for today
<Begasus>
cu peeps
Begasus has quit [Quit: Vision[]: i've been blurred!]
<Skipp_OSX>
it's menus all the way down
<Nephele>
okay. That seems a bit strange
<Nephele>
by the way Skipp_OSX, do you know of a ColumnList *without* a title?
<Nephele>
is there such an api already?
<Skipp_OSX>
you mean other than the one in Tracker? :)
<Skipp_OSX>
There is BColumnListView and then there is list view in Tracker which does have separate titles and is custom in many ways
<waddlesplash>
isn't the titleview hideable?
<Skipp_OSX>
mmmmmm I don't think so but maybe, you mean in BColumnListView?
<Nephele>
I only know of BTitledColumn?
<Nephele>
Does that let the title be hidden to only use the columns?
<Skipp_OSX>
I do not know the answer
<Skipp_OSX>
we always use the column headers
<Nephele>
I want to use this in Renga for the left view of opened chats, and BOutLineListView has some very annoying properties
<botifico>
[haikuports/haikuports] jmairboeck 845dd09 - argparse-manpage: new python recipe (#10869)
_-Caleb-_ has joined #haiku
DKnoto has quit [Quit: Leaving]
DKnoto has joined #haiku
_-Caleb-_ has left #haiku [#haiku]
_-Caleb-_ has joined #haiku
TmTFx has joined #haiku
<TmTFx>
Hi
tuaris has joined #haiku
<TmTFx>
I'm trying to write down a recipe, after some initial trouble, I realized I cannot launch the application installed withing install() {} section because it's "chrooted" and cannot find python3 executable, so I'm looking for help. this is the script: https://0x0.st/Xylf.b.recipe
dalme_ has joined #haiku
<TmTFx>
the row "HTMZ.py -d $TARGET_LAUNCHER -g" launches the just installed app but cannot be launched does the post_install_script section help in this case?
<OscarL>
Right after booting, re-starting Tracker (with LD_PRELOAD=libroot_debug.so and MALLOC_DEBUG=g), and trying to run a Find query for type "Email" (on /boot/ volume, that has no emails at all)... and boom!
Levitating[m] has left #haiku [#haiku]
OrngBomb is now known as OrangeBomb
OrangeBomb has quit [Quit: Slacking off]
TmTFx has quit [Quit: Vision[]: i've been blurred!]
OrangeBomb has joined #haiku
<OscarL>
Bah, too late to tell TmTFx that he needs to add "cmd:python3.10" to BUILD_PREREQUIRES on his recipe.
<OscarL>
(and use ARCHITECTURES="x86_64 !x86_gcc2" instead of all, unless he plans to provide "DecompressTMZ" binaries for more platforms)
gouchi has quit [Remote host closed the connection]
diver has quit [Quit: Leaving.]
diver has joined #haiku
<OscarL>
too bad we don't have something similar to hrev tags on r1betaX branches. Counting commits ain't fun.
<OscarL>
"hrev57937+nn" would be nice.
<gordonjcp>
there's got to be an easy way to do that