<erysdren>
oops, uparrow+enter in wrong window again...
<erysdren>
lol
nhtello has joined #haiku
<Begasus[m]>
'lo erysdren :)
<Begasus[m]>
what was up with sdl3_mixer?
cassisian has quit [Ping timeout: 480 seconds]
nhtello has quit [Quit: Vision[]: i've been blurred!]
<erysdren>
Begasus: doesnt have a numbered release, yet. but i still wanna create a Haiku package for it, just so i can port some FOSS game stuff that uses it
<erysdren>
i know ~git packages are a thing but i'm always a little anxious about adding them
<erysdren>
i get the impression that Haiku maintainers prefer versioned releases?
cassisian has joined #haiku
<Begasus[m]>
you could use the commit date for now?
<erysdren>
sure
<Begasus[m]>
or check if pkg-config supplies a --version string there?
<nekobot>
[haiku/haiku] 6bb82d294230 - kernel/events: Fix incorrect sizeof in user_memcpy.
<nekobot>
[haiku/haiku] 3978032551a1 - kernel/vm: Areas without source caches need commitments for READ protections.
cassisian has quit [Ping timeout: 480 seconds]
OscarL has joined #haiku
<Skipp_OSX>
is there a way to check if a BEntry has been unlinked already?
<Skipp_OSX>
I should be more specific, in node monitoring, when you get a B_ENTRY_REMOVED message, "Note that the B_ENTRY_REMOVED message is sent as soon as the node's entry is "unlinked" from its directory. The node itself may linger for while after that"
neoncortex has quit [Ping timeout: 480 seconds]
<Skipp_OSX>
if (trashDir.GetNextEntry(&entry) == B_OK) seems like it is giving false results
<Skipp_OSX>
to check if there is an item in your Trash or not
<Skipp_OSX>
hmmmmmmmm now it's working every time
<Skipp_OSX>
ok, messed up this time, took a few times to trigger but it didn't work
<Skipp_OSX>
it works most of the time but messes up sometimes there must be a timing issue going on.
<Skipp_OSX>
hmmm ok looks like I can check if the entry Exists()
<OscarL>
I began "moving" code away from a kernel driver into a Python module that access hardware via the /dev/misc/poke driver.
<OscarL>
Intent was to minimize risk of KDLs, and ease up development/debugging of experimetal code.
<OscarL>
(I only had one KDL while writting said kernel-mode driver so far)
<OscarL>
Now I get to KDL each time I try certain ioctl operation from the Python code :-D
<Habbie>
lol
cassisian has joined #haiku
<Skipp_OSX>
ok now it works every time except after reboot....
<OscarL>
Habbie: to be fair... author of /dev/misc/poke is known to be not too bright, so I guess I just uncovered an issue with that driver now :-)
* OscarL
wishes Skipp_OSX the best of luck with those hard to track bugs.
<Skipp_OSX>
I almost got it, very close
* OscarL
crosses fingers!
<Skipp_OSX>
actually it works on reboot too... but it didn't work the very first time... I gotta keep plugging away though since it works _most_ of the time but every once in a while it messes up.
cassisian has quit [Ping timeout: 480 seconds]
neoncortex has joined #haiku
<jmairboeck>
waddlesplash: kallisti5[m]: it looks like haikuporter wasn't yet updated on the x86_gcc2 builder, hence extra_cmake_modules failed to build on it now because the doc package name doesn't match any more: https://build.haiku-os.org/buildmaster/master/x86_gcc2/logviewer.html?buildruns/8174/builds/86500.log
<waddlesplash>
updated where?
<waddlesplash>
sorry, I mean, updated to what git commit?
<jmairboeck>
kallisti5[m] made a new release recently, probably just use that
<waddlesplash>
sure, but what's the commit that actually changed behavior here?
<nekobot>
[haiku/haiku] 95c611518f68 - listarea: show area locking and protection
HaikuUser has joined #haiku
HaikuUser has quit []
<Skipp_OSX>
ok works every time except after reboot now
<Skipp_OSX>
Which means the TrashWatcher constructor is too early... I need some sort of ReadyToRun() on a BLooper
<waddlesplash>
jmairboeck: done
<waddlesplash>
Skipp_OSX: what do you mean "too early"?
<jmairboeck>
waddlesplash: thanks
<Skipp_OSX>
fTrashFull = CheckTrashDirs(); is apparently not working to set the Trash status
<Skipp_OSX>
the initial Trash status
<waddlesplash>
why doesn't it work?
<Skipp_OSX>
I assume because fTrashFull is set incorrectly, then we check to see if that has changed when you delete/restore a file and it says nope, no change and doesn't update the Trash icon.
<Skipp_OSX>
although I'm not sure, all I know is that the Trash icon doesn't update only the first time after a reboot.
<jmairboeck>
waddlesplash: does buildmaster reconnect automatically after the error?
<waddlesplash>
after that kind of error? idk
<Skipp_OSX>
thread is locked but I don't see why that should matter
<waddlesplash>
jmairboeck: looks like the builder is still going anyway
<jmairboeck>
ah yes, seems it did it
* OscarL
found a bug that makes Pe unclosable :-/ (it stopped respoding to any input)
<jmairboeck>
and for ECM it now shows that "some packages already exist" and the rest are building, so I guess only the doc package will be missing then
<OscarL>
(but now I fail to reproduce it. Sigh :-/)
<jmairboeck>
I'll let Begasus[m] decide if he wants to do a revbump for that
HaikuUser has joined #haiku
<HaikuUser>
Is there support for generating apple-style ICNS files on Haiku from multiple PNGs? e.g 1PNG 128x128 and another one 256x256
<OscarL>
HaikuUser: tried searching with "pkgman search icns", it only shows "libicns" ("A library for the Mac OS 'icns' format"), but no command lines utilities for it, it seems.
cassisian has joined #haiku
<OscarL>
there's the "Apple icon translator", but not sure if it has write support.
<HaikuUser>
OscarL: does that package contain a command called "iconutil"?
<HaikuUser>
it contains something called png2icns
<HaikuUser>
probably related
<OscarL>
ah, yes, missed the "cmd:png2icns"
<OscarL>
sorry, I need to actually find working glasses :-)
<HaikuUser>
I'll try this... Hopefully this will improve me theme a bit. I missed that rEFInd uses 128x128 on <HD and 256x256 >HD... but the only format that supports having both is ICNS
<HaikuUser>
and rEFInd doesn't support HVIF or anything similar
<Skipp_OSX>
come on... work
<HaikuUser>
I wish there was a IOM->PNG translator already... it's cumbersome to have to open IOM for this, and there is no automation in IOM for this task either as far as i can tell
<Skipp_OSX>
fail... only first time after new image... so strange
<OscarL>
HaikuUser: there used to be a BeOS/Haiku utility that used BeOS/Haiku translators for back-end support... (mediaconverter or something like that?), so you could theorically convert between any of the formats where translators have support for. But haven't used that in a LOONG time.
<HaikuUser>
Yes OscarL, but we have no translator for IOM->PNG
<OscarL>
HaikuUser: there's an hvif2png tool on Haiku's source code repo.
<HaikuUser>
only code in IOM that does the equivalent
<HaikuUser>
IOM isn't HVIF either unfortunately
<OscarL>
IOM can export to hvif (albeit only via GUI)
<HaikuUser>
exactly... only the gui means I get to re-export everything for the Icons *again*
<HaikuUser>
and i already had to patch IOM to be able to export to 128x128 in the first place :D
OscarL has quit [Remote host closed the connection]
cassisian has quit [Ping timeout: 480 seconds]
OscarL has joined #haiku
<waddlesplash>
HaikuUser: hvif2png can read IOM format too
<OscarL>
my IRC client silently disconneted.
<OscarL>
HaikuUser: "MediaConverter" is the program I was thinking about earlier... already included under Applications->MediaConverter :-D (but it fails to recognize .hvif files... even if they open alright in ShowImage)
* OscarL
is an idiot... MediaConverter is for video/audio formats, not for images.
<OscarL>
maybe I just misremember a similar app that worked for Translators :-/ (brain getting old(er))
<HaikuUser>
waddlesplash: that's good to know. Is it in working condition? It's apparently not included in beta5 per default
<waddlesplash>
it's a utility only in the source tree
<waddlesplash>
you can build it with jam
<HaikuUser>
but not install it with haiku_extras or something? Okay. Makes it a bit harder to work with my repo then for colaboration
<nekobot>
[haiku/haiku] beed129dc206 - kernel/vm: Use vm_page_num_pages() to compute heap size.
<nekobot>
[haiku/haiku] 5d6b495d6a55 - kernel/guarded_heap: Implement ctors/dtors in the fake object_cache.
<nekobot>
[haiku/haiku] 801c025d7b84 - file_systems/QueryParser: Invoke ConvertValue in CalculateScore.
<OscarL>
hvif2png sounds like a good candidate for inclusion in "haiku_extras" to me.
<waddlesplash>
we should really just work to enhance "translate" CLI to do this
<waddlesplash>
main thing missing is that vector translators can't render at arbitrary sizes
<waddlesplash>
HaikuUser: the tool can also be built for Linux too
<HaikuUser>
Well i'm not really using linux usually :)
HaikuUser is now known as nephele_mac
<OscarL>
(I guss "translate" was what I was half-remembering. Even BeOS had it :-D)
<OscarL>
s/guss/guess/
<OscarL>
(part of the sample-code, even)
<nephele_mac>
Those framework 12 laptops look really good
Aedil has quit [Quit: leaving]
<nephele_mac>
waddlesplash: does haiku Inc own any hardware itself? or does it only pay for developers hardware in that sense?
<waddlesplash>
I think there used to be some mac minis that the Inc owned
<waddlesplash>
but that was a while ago
<nephele_mac>
That framework 12 looks like a good target to get better support for Haiku, but i reckon a good way for that would be to send it to other devs for testing (in their area of expertise)
<nephele_mac>
on mastodon someone atleast said Haiku does not boot on the thing at all
<waddlesplash>
did they try a nightly or the beta?
<waddlesplash>
because there were multiple fixes to the bootloader that are relevant here since the beta
<waddlesplash>
including I think some specifically for Framework devices
<nephele_mac>
I thought the oposite was the case in some instances? that beta5 did not try initialiing some serial output but the nightlies did (in cases of like the steam deck)
<waddlesplash>
the nightlies now handle that case too
<waddlesplash>
they will properly time out serial output
<PulkoMandy>
There is some hardware formally owned by the inc. I have a via c3 motherboard here that was passed from one dev to another without anyone ever writing any drivers for it
<PulkoMandy>
I think also some old arm devices (a gumstix and maybe a beagleboard)
<OscarL>
PulkoMandy: tell me the models of the Via chips on that motherboard... I may end up adding support for the hardware monitoring function, at least :-P
<PulkoMandy>
In general we do not have a good rcord of managing to do anything useful with hardware donations. People who consider giving us (either the inc or a specific dev) some hardware should be aware of that
<PulkoMandy>
OscarL: I'd have to dig it out from wherever I stored it in my flat
<nephele_mac>
PulkoMandy: I guess the case of a dev beeing interested in the first place may work better... :(
<nephele_mac>
:)*
<PulkoMandy>
I think haiku was booting in vesa, no drivers for the via video yet, no driver for the pci serial card or gps receiver
<PulkoMandy>
nephele_mac: Even then... still haven't figured out touchpad, sound, or even completely figured out external displays on my main laptop
<OscarL>
PulkoMandy: no worries! :-) (I think I have some old mobos with via chipsets I could try on).
<PulkoMandy>
And that's after giving up on some things on the previous laptop and getting this one
<nephele_mac>
Yeah, but on the other hand some issues I had with haiku when starting are now completely fixed like media keys...
<PulkoMandy>
Hardware gets obsolete before I start working on it...
<nephele_mac>
I want to work on that framework 12 laptop. it looks like a great HW to run haiku on
<PulkoMandy>
Media keys was not a hardware problem, just some internal wiring to make them do something
<nephele_mac>
yes, true.
<nephele_mac>
still, it was driver code in the farthest sense of the word
<nephele_mac>
(for the ps2 one i had atleast)
<PulkoMandy>
Driver code that doesn't touch the hardware is just... code :)
jmairboeck has quit [Quit: Konversation terminated!]
<nephele_mac>
Well, it was lucky that i did not have to get more info out of the hardware, just interpret it better ;)
<PulkoMandy>
Assoon as hardware gets involved, you likely have to give up most debugging tools because you can't run in an emulator, and the hardware will not behave as the documentation tells you (if there is documentation)
<PulkoMandy>
It helps if you can talk with the people who designed the hardware
<nephele_mac>
There usually isn't... I have one of those "new" intel arc gpus by the way... have not found any docs for that thing, only linux drivers
<nephele_mac>
I would love to get some rudimentary support for it, so we can do atleast Displayport link training (for refresh rates..., or maybe we need DSC), brightness via the "standard" comms method to the display, and the fan curve so the thing stops whirring and stays silent like designed
<nephele_mac>
I'm not even sure how i'm supposed to start with driver development for the gpu :g
<nephele_mac>
i hope that the existing intel driver can be extended... but I'll see i guess
<PulkoMandy>
Yes, for intel we put everything in the same driver. The general idea remains similar but there are new features (the displayport link training isn't quite working yet for example) and also intel often move things from one register to another (when they need space for example because they increase the number of displays)
<nephele_mac>
PulkoMandy: seems they now have some documentation for their discrete gpu. Not sure it's for mine exactly, but probably useable
<PulkoMandy>
You can also use the ie_reg command in kdl to directly read and write videocard registers
<nephele_mac>
even with no driver attached?
<PulkoMandy>
That helped me a lot to figure out backlight control for example
<PulkoMandy>
No, it needs the driver
<PulkoMandy>
But it doesn't need the accelerant I think
<nephele_mac>
That's a bit of a chicken and egg then. If the driver needs to take over the display to get video output i can't really use that to debug?
<PulkoMandy>
Still, yes, this is easier if you have a serial port or some other way to access kdl while the display is not working
<nephele_mac>
Ah. okay that makes sense
<nephele_mac>
still don't understand how i'm supposed to get a serial output on a modern machine though....
<PulkoMandy>
I think rudolfc had a setup with two videocards at some point
<PulkoMandy>
what kind of machine is it?
<nephele_mac>
desktop efi computer with some kind of ryzen cpu
<PulkoMandy>
My desktop from 2014 still has a serial port on the motherboard (on a internal socket, I just plugged a db9 connector to it)
<PulkoMandy>
If yours doesn't have that, a pci-express serial port card should work fine
<PulkoMandy>
I have an expresscard one that I used on my previous laptop (newer one doesn't have expresscard)
Babaj has joined #haiku
<nephele_mac>
i'm not sure i can fit any additional pci-express cards while the gpu is inside
<nephele_mac>
i could use another atx board maybe for developing the driver though
<PulkoMandy>
In theory thunderbolt (or usb4 or whatever it is called now) should work too since it's just pci. But no one makes ready-made thunderbolt to serial adapters
<PulkoMandy>
other solutions are adding some support for usb serial to kdl (we already do usb keyboards so it should be possible)
<PulkoMandy>
Or maybe network kdl over some very simple protocol
<nephele_mac>
I wish we had some mDNS stuff to make setting up haiku to haiku situations like this easier...
<PulkoMandy>
It should be possible to do a simple thing to send and receive ethernet packets, then use arp packets so you don't even need an ip address or something like that
<PulkoMandy>
Why do you need mdns? Plug the two machines together with a cable, they will notice there is no dhcp server and pick a random ip
<PulkoMandy>
But that won't help for accessing the kernel debugger
<nephele_mac>
then i have two machines i can't view online docs with :)
<nephele_mac>
just simple neighbour discovery. Knowing that on $ip there is another haiku system that offers services would allow us to immidiently display this info. Like hey, there is another haiku machine here, and it would be fine with offering remote display... etc
<PulkoMandy>
For this kind of work I usually isolate the tested machine on its own network (connecting to an usb to ethernet on the other machine for example)
<nephele_mac>
In this specific case i'm not really sure why this even needs to be in the kdl?
<PulkoMandy>
We were talking about graphics drivers deâelopment
<nephele_mac>
yes. why does ie_req require the kdl to be running? Just to suspend the other functions of the driver?
<nephele_mac>
(but even in that state it would render the kdl, no?)
<PulkoMandy>
(Fun story: I had a machine where kdl would leave the ethernet port in a confused state that would bring down my entire home network)
<PulkoMandy>
ie_reg is a kdl command
<PulkoMandy>
I guess you could write an userland tool that talks to the driâer through some special ioctl to do the same. I think there is such a tool for Linux that could be ported
cassisian has joined #haiku
<nephele_mac>
if i have the equivalent from userspace i could just ssh in and use that
<PulkoMandy>
yes
<nephele_mac>
why do we need to use ioctls for this stuff? is there no better interface to talk with drivers?
<waddlesplash>
what would a "better interface" look like?
<waddlesplash>
an ioctl is basically just a syscall that talks to a driver rather than the kernel
<PulkoMandy>
Sounds like a nice project to get started on the intel driver: add an ioctl that allows an ie_reg like tool in userspace :)
<PulkoMandy>
the entry point for driâers is a file descriptor in /dev. From there you can read, write, and ioctl for all things that are not a read or write
<nephele_mac>
waddlesplash: but ioctls require opening some specific device file, and knowing the protocol in advance per node. syscalls only require you knowing the call (and even in that case we *explictly* only provide a interface throught the C api and never assume apps just know the magic number of the syscall)
<PulkoMandy>
what would your syscall(s) look like?
<PulkoMandy>
surely they will either be specific to each dvice and you need to know them in advance
<PulkoMandy>
Or they will be generic and take a command parameter, and look like ioctl
<waddlesplash>
right
<nephele_mac>
Yes, but we have the same problem here like you'd have with syscall re-enumeration. I can't "just" make the driver accept a new ioctl without potentially breaking tools that assumed a specific number before
<waddlesplash>
OscarL: by GPF do you mean a KDL?
<PulkoMandy>
knowing an ioctl number is no different from knowing a syscall number. Both have names defined somewhere to help you remember which one does what
<nephele_mac>
for syscalls we have stubs to link against, i don't think there is such a thing for ioctls?
<waddlesplash>
nephele_mac: sure you can, just add it at the end of the numbering?
<waddlesplash>
and driver ioctls are very specific and can and do change frequently
<waddlesplash>
during driver development
<waddlesplash>
so, it doesn't make sense to try and have a fully stable ABI here
<OscarL>
waddlesplash: GPE to be exact, yes. Will paste output from serial port (vmware).
<PulkoMandy>
nephele_mac: There is standardization in syscall numbers in other os, but not in beos
<PulkoMandy>
We inherited the beos way
<nephele_mac>
yes. So maybe we should have a userspace header to link against for these things too? so you don't need to know the ioctl numbers in userspace tools?
<waddlesplash>
OscarL: I see 2 problems in the poke driver, it should be checking IS_USER_ADDRESS but is not. I'll fix that
<PulkoMandy>
Should be easy to match with the path to the device node (/dev/graphics for videocards, /dev/ports for serial ports, etc)
<nephele_mac>
is the interface the same for all devices then?
<nephele_mac>
just with a supported subset?
<PulkoMandy>
The ones defined in that file, I think yes (if they make sense to implement)
<PulkoMandy>
Each driver can add whatever it wants, but ideally would assign numbers in the appropriate range
<PulkoMandy>
Or custom ones larger than 9999 as that's the space Pe reserved for standard things
<nephele_mac>
so, basically, i can implement the ioctl in the intel driver, give it a stable number added to that header (or a different one in that dir), and then use that header in the userspace tool too
<nephele_mac>
i guess just check how ie_req works in the kdl and base it off of that
<OscarL>
waddlesplash: this is the output from "dis -b 1", but no clue how to determine iframe, and such, sorry :-D https://bpa.st/EZRQ
<waddlesplash>
OscarL: I need the whole KDL output from before that too
<waddlesplash>
I suspect my change above will indeed fix this then, and the ioctl will safely return an error rather than crashing
<OscarL>
will test new poke.cpp next.
<OscarL>
waddlesplash: for future reference.. what's the meaning of "rax 0x99"?
<waddlesplash>
register name and its current value
<waddlesplash>
the faulting instruction appears to be movupsx %xmm0, -0x40(%rax)
<OscarL>
("future reference" as in... "let's hope I can remember how to read this next time :-P)
<waddlesplash>
so it's trying to write to rax
<waddlesplash>
(or rather an offset from rax)
<waddlesplash>
but rax's value is garbage, there's nothing there, and more to the point, it's a "non-canonical address"
<nephele_mac>
PulkoMandy: thanks for the pointers anyhow. I have something to start with on tuesday :)
<waddlesplash>
i.e. it's not aligned properly
<waddlesplash>
if it was aligned, or we were using an instruction that worked with unaligned data, we'd get a Page Fault
lesderid_ has quit []
lesderid has joined #haiku
<waddlesplash>
since it's not, we get a GPE instead
<OscarL>
I see. I'm surely messing up my code on how to setup the "pci_info*" field in that when trying to call POKE_GET_NTH_PCI_INFO from python code.
<PulkoMandy>
nephele_mac: For graphics driver you could put your defined value somewhere in headers/hrivate/graphics/ I think. Especially this one as it will be specific to one driver
<waddlesplash>
OscarL: yes, probably
<OscarL>
Have used "ctypes" onces or twice, but nothing this "complex" (nessted structs)
<nephele_mac>
so far Skipp reviewed but only gave a +1
<OscarL>
"warning: array subscript -1 is below array bounds of 'cpu_ent []' [-Warray-bounds=]" sounds ominous. on: ../src/system/kernel/interrupts.cpp:584:51
<nephele_mac>
waddlesplash: maybe we should do quarterly reports instead of monthly reports for now? a bit more quality vs quantity since the reports recently don't cover that much
Skipp_OSX has joined #haiku
<OscarL>
waddlesplash: fix confirmed. Getting "OSError: [Errno -2147478783] Bad address" now. Thank you :-)
<PulkoMandy>
nephele_mac: The ie in ie_reg means "intel_extreme", it's a command specific to this driver only
<nephele_mac>
and maybe move a bit away from the "developer did X" style and instead go to "X was implemented" with additional this is beneficial for, or this fixes bug X or increases support for <something> to give a bit more context for changes
<nephele_mac>
PulkoMandy: ah okay :)
<nephele_mac>
for example the next report would have "nephele implemented support for fdatasync", instead we could have this as "support for fdatasync was added for posix compatibility" or so
<nephele_mac>
maybe even with references to the spec...
<nephele_mac>
PulkoMandy: is it a command that should be specific to the driver? registers seems like a "generic" concept when dealing with gpu drivers
<Skipp_OSX>
BeOS Trash works similarly, sometimes doesn't update
<nephele_mac>
Skipp_OSX: reading what you wrote i think this is a bit backwards. I don't think the trash icon should be updated at all. I think tracker should just ignore what the icon is off the trash bin and render it based on what it itself thinks it should be
<Skipp_OSX>
huh?
<nephele_mac>
I saw you writing about setting the Icon of the Trash folder if i understood correctly, and trying to invalidate the tracker icon cache for that
<Skipp_OSX>
The way it works now is that it writes the BE:ICON attribute either empty or full icon depending on if there are files in Trash or not.
<PulkoMandy>
nephele_mac: For the typical read/write and poking around you would use hoke as oscarl is doing. The intel graphics card have some special way to address the registers, ie_reg saves you from manually computing that from pci bar addresses and their virtual memory mappings
<PulkoMandy>
So it's not really that generic
<nephele_mac>
Yes. I think it should A) never write that attribute B) hardcode (with GetSystemIcon getting the icons once) the icon displayed based on what the state is that tracker thinks it is
* OscarL
should really try look into making sure /bin/poke works OK on modern Haiku, specially on 64 bits.
<nephele_mac>
PulkoMandy: ah, good to know
<Skipp_OSX>
I'm trying to understand but I'm not
<nephele_mac>
Skipp_OSX: as an analogy, the bar how "full" the drives are is also not stored in the Icon attribute
<nephele_mac>
I think tracker should ignore the Icon for the trash dir and use one from memory, and pick the one it thinks is apropriate
<Skipp_OSX>
we draw over the icon for full meter
<nephele_mac>
yes, but you could also implement it like the trash is now, on each change write a new icon that includes a % of how filled the drive is
<nephele_mac>
and in the same vain i think the trash icon should work like the meters are
<nephele_mac>
that is rendered based on trackers internal state, and not on the icon attribute on the trash folder
<Skipp_OSX>
I mean, idk how we could do that second part because the Trash is a folder on each volume, right so you have the amount of space left on all your volumes
<nephele_mac>
what happens if your /boot/ trash is empty but you connect /haikuUSB1 with a full trash? does it now have to write a new Icon value to the trash on your Desktop?
<Skipp_OSX>
but let's ignore that part for now.
<nephele_mac>
I did not mean you should show how "full" the trash is
<nephele_mac>
Either the icon is split in two, Empty trash + Only the trash. and tracker overlays the second one. Or trackers saves both combinations and uses them when apropriate
<Skipp_OSX>
Yes, it does, we are doing node monitoring on B_DEVICE_MOUNTED and B_DEVICE_UNMOUNTED and change the BEOS:ICON attribute
<nephele_mac>
but ignoring what the icon attribute sais on the disk
<nephele_mac>
yeah, i don't think we should do that
<nephele_mac>
node monitoring is fine. But messing arround with the attributes based on that is not good
<nephele_mac>
just keep the state of trash in trackers team only i.e in RAM
<nephele_mac>
and use that state when rendering the trash icon, and not it's on-disk icon
<nephele_mac>
Removes one layer of complexity and potential race conditions...
<Skipp_OSX>
First, it looks in the node's attributes. If the attribute doesn't exist, it gets the node's preferred app (as a signature), and asks the File Type database if that signature declares an icon for this node's file type. If the node doesn't have a preferred app, or if the app doesn't designate an icon for the node's type, the function asks the File Type database for the icon based on the node's file type. If still empty-handed, the function asks the File
<Skipp_OSX>
Type database for the preferred app based on the node's file type, and then asks that app for the icon it uses to display this node's file type.
tktech283 has joined #haiku
<Skipp_OSX>
since Trash is just a folder we don't have any preferred app stuff or FIleType info, so basically all we can do is set the attribute on the node, I guess.
cassisian has joined #haiku
neoncortex has quit []
<Skipp_OSX>
Open up FileTypes Preferences and drag the Trash on you'll see
tktech28 has quit [Ping timeout: 480 seconds]
tktech283 is now known as tktech28
<nephele_mac>
Okay Skipp_OSX. I am arguing to skip all of that
<nephele_mac>
If the folder is the Trash folder: use GetSystemIcon for trash full or trash empty (and cache those)
<PulkoMandy>
Skipping this means adding one more case in front of it for "is it the trash directory?"
<Skipp_OSX>
cache those where?
<PulkoMandy>
So it makes the code more complicated
<Skipp_OSX>
well, we're already adding a special case for is this the trash dir
<nephele_mac>
Trash is an explicit edge and already refuses to work like a normal folder. So I think this shortcut would be much more straightforward PulkoMandy
<nephele_mac>
either it works normally or it works like the trash dir
<nephele_mac>
Skipp_OSX: cache them in trackers team
<PulkoMandy>
You need it in every filepanel in every app as well
<Skipp_OSX>
Desktop (folder) works the same way AFAIK, minus the empty/full distinction
<nephele_mac>
You can just show the normal (empty) trash icon there?
<nephele_mac>
in file panels
angrystar17043 has quit [Read error: Connection reset by peer]
angrystar17043 has joined #haiku
<nephele_mac>
anything else would, with the current system, already imply that such a filepanel has to have node monitoring and live updating icons
<nephele_mac>
if you want the trash icon state to be acurate to the state the trash is in
<PulkoMandy>
Not if tracker writes the icon in the trash directory. Then everyone else gets the up to date one?
<nephele_mac>
No, they'd have to node monitor for that and update the icon as soon as it changes
<nephele_mac>
otherwise you only get the icon as it was when you originally opened the panel
<nephele_mac>
(and that might be racy aswell, catching an intermediate state that would have been too slow to render in the UI otherwise...)
<PulkoMandy>
Filepanels are already monitoring the currently shown directory for any other updates, so, that will work without any extra code
<nephele_mac>
you wrote every filepanel in every app. I assume you ment some other implementation aswell besides tracker?
<nephele_mac>
because if this is the tracker filepanel it would work the same way without extra code aswell, since it is tracker
<PulkoMandy>
I mean BFilePanel from libtracker.so
<PulkoMandy>
But that code runs in each app that has a file panel. So you can't cache data in tracker's application ram
<PulkoMandy>
You suggest having extra code checking "is this the trash? Then pick a special icon" that would need to be run everywhere we display file icons
<Skipp_OSX>
The attribute is the only convenient place to store the info
<Skipp_OSX>
I mean we have that extra code checking already
<PulkoMandy>
And a special mechanism to update it live, in all apps using bfilepanel, somehow not based on node monitoring, I guess
<PulkoMandy>
Seems very complicated to just save writing an attribute to me?
<nephele_mac>
PulkoMandy: no. I suggest to do this in tracker and nowhere else. I don't see how the trash state is relevant somewhere else
<PulkoMandy>
Ok so you suggest introducing a glitch in all other apps?
<PulkoMandy>
Not sure how that is a good idea
<nephele_mac>
No. I suggest that displaying a Trash icon is fine and not an issue. and that this data is only relevant on the desktop or in tracker views
<nephele_mac>
The current way seems incredibly racy to me simply because Trash *isn't* one folder. but one folder masquerading for many folders and trying to sync a state between them
<PulkoMandy>
and in BFilePanel. Why wculd it be different in BFilePanel?
<nephele_mac>
I think the information is not relevant enough in BFilePanel, and doing it this way would make the code work reliably and be less racy
<nephele_mac>
one completely different way would be to dismiss the notion that the Desktop Trash has to represent the Trash on other disks. And only have it represent the one on the Desktop *or* make it a folder that has links to Trash for each disk
<Skipp_OSX>
yeah we're doing all the syncing too
<nephele_mac>
I think this design was probably less bad when BeOS didn't have to deal with people randomly connecting usb drives or mass storage devices (like thier phone) or network attached storage often... With the current design having a RO NFS mount with something tracker things is the trash folder would probably lead to a trash folder you can never empty :g
<Skipp_OSX>
We already have the icon stored in Tracker GetTrackerResources()->LoadResource(B_VECTOR_ICON_TYPE, resourceId, &size); where int32 resourceId = (trashFull ? R_TrashFullIcon : R_TrashIcon);
<Skipp_OSX>
but then to actually display it, we set the attribute and idk how else we could do it with all the icon caching we got going on in Tracker.
<nephele_mac>
phschafft: are you available next week to brainstorm some ideas for next-generation-boomer-tabbed-phone-OS? :)
<OscarL>
Funny that the latest activity report has "It’s been a while since we’ve seen waddlesplash — their last post was 5 months ago." at the top :-)
<Skipp_OSX>
prob bc he uses his real name instead sometimes
cassisian has quit [Remote host closed the connection]
<Skipp_OSX>
or it's messed up idk
cassisian has joined #haiku
<nephele_mac>
no, that's the forum software saying he hasen't posted recently... which isn't acurate since his last post was one week ago, and not 5 months
<nephele_mac>
waddlesplash: you've been unmasked as a time traveller
<OscarL>
nephele_mac: I suspected he was one, as on ocassions had replied to me before I finished lifting my finger from the enter key, after typing one of my silly questions.
<waddlesplash>
LOL
<waddlesplash>
what happened is that the forum post gets made with the "Haiku" account
<waddlesplash>
and then I manually edited it to be by me
<nephele_mac>
even then, the last activity report should have been last month
<waddlesplash>
but Discourse didn't remove the report
<waddlesplash>
nephele_mac: yes but that one got edited too
<waddlesplash>
so it seems Discourse just has a bug here
<nephele_mac>
so you started this 5 months ago? ;)
<waddlesplash>
no but the Haiku account last posted 5 mo ago
<waddlesplash>
not counting posts reassigned to other users
<nephele_mac>
yeah, i don't buy it. the time traveler explanation makes way more sense
<OscarL>
heh
<nephele_mac>
;)
<nephele_mac>
"Memory Mapped (I/O) includes information on" ... nothing more, intel manual. Atleast I thought so, but DocumentViewer actually is buggy here and failed to render the rest!
<nephele_mac>
I wish DocumentViewer was severely cleaned up and included by default
<nephele_mac>
it putting a toolbar into a tabview is certainly one thing one could really rethink though... and no menu bar is also not a good idea
<nephele_mac>
the control look does some wierd second-guessing in DrawLabel and changes it's behaviour based on some tracker state
<nephele_mac>
and i want that gone, and have tracker instead tell properly what it wants drawn
<nephele_mac>
but i have no clue what the check is even supposed to do, or which tracker invocations it tries to second guess
<Skipp_OSX>
if it's not virtual how are you supposed to override it?
<nephele_mac>
I guess they should keep beeing virtual, but have default implementations so they get redirected by default
<Skipp_OSX>
see BeControlLook it overrides DrawLabel and doesn't inherit from HaikuControlLook just BControlLook
<nephele_mac>
but that's not the part of the review that i am baffled about, it's the complex drawing logic in DrawLabel based on IsDesktop()
<Skipp_OSX>
The whole point of BControlLook is that it's supposed to be pure virtual for the most part
<Skipp_OSX>
pure virtual means virtual and = 0 as in you must implement the method yourself like an interface.
<Skipp_OSX>
Like traits but we don't have traits in C++ so use pure virtual instead.
<nephele_mac>
yeah. But the two DrawLabel variants the review is about are implemented in controlLooks by just calling the other interface with some added default values. I wanted to move those to BControlLook itself so implementing a controllook becomes a bit easier with less boilerplate
<nephele_mac>
but you are right that they should stay virtual so that behaviour can be overiden when wanted
<Skipp_OSX>
I mean, ok
<nephele_mac>
hmm, i guess the code here I am looking at is supposed to implement the fake text-shadow tracker uses?
<Skipp_OSX>
but no, that's not how it is supposed to work, it should be pure virtual... it's an interface.
<Skipp_OSX>
BControl is an interface... that's the whole point. It's a template, you fill in the methods. I guess it doesn't have to be but that's the idea.
<nephele_mac>
I don't understand the value in having it be that way at any cost. and it's not how it works now either
<Skipp_OSX>
bc it's an interface.
<nephele_mac>
it has default implementations for severall things right now
<Skipp_OSX>
yeah we're not perfect.
<Skipp_OSX>
but that's the point, to be an interface with no implementation.
<nephele_mac>
including one existing redirection for DrawLabel
<nephele_mac>
Yeah, makes no sense to me. Now you have to implement *everything*. And that leads to all that boilerplate redirection in BeControlLook, HaikuControlLook etc
<Skipp_OSX>
that's the idea
<nephele_mac>
It makes ControlLooks hard to implement
<Skipp_OSX>
We're only setting up what you must implement, it's up to you to do the implementation.
<nekobot>
• Begasus (0297666e): cmake, drop jsoncpp dependency in favor of internal one (#12568)
<Skipp_OSX>
yes, that's the point.
<nephele_mac>
It doesn't work that way right now either
<Skipp_OSX>
it doesn't?
<nephele_mac>
You have interfaces for rounded corners and two controllooks redirect this and ignore the values
<nephele_mac>
they have to have boilerplate because they don't actually want to implement this
<nephele_mac>
the other way to remove a lot of the boilerplate would be to remove the interface for rounded corners and knobs, but you did'nt like that. Which is okay. So my other idea here, with the goal of making controllooks easier to write, is to move some of those redirection functions to BControlLook
<nephele_mac>
so you can still implement rounded corners if you want to. Just if you do not they will become non-rounded corners in your controlLook
<Skipp_OSX>
we could probably take all the rounded corner stuff out of BControlLook
<Skipp_OSX>
I guess...
<nephele_mac>
These two calls for DrawLabel fill in default values that the caller then does not have to set, if you want to have full api purity, by that reasoning maybe they should be removed instead? but then this makes calling the controllook api a bit harder
<Skipp_OSX>
But I mean, it's in BControlLook for a reason.
<Skipp_OSX>
yeah, we prob only need a single DrawLabel in the interface.
<nephele_mac>
well, yeah, the reason is you wanted to provide the option for rounded corners to api users right?
<Skipp_OSX>
right, so we could specify rounded corners in BButton for example.
<nephele_mac>
I mean the issue of a global setting aside, that could also live in interface kit
<nephele_mac>
(if you want rounded corners by default in a ui)
<Skipp_OSX>
but that got vetoed so oh well.
<nephele_mac>
the only use right now for rounded corners seems to be keymap prefs, but that is a wierd usage as those aren't really buttons... so probably shouldn't render like them
<Skipp_OSX>
yeah that was the idea, to specify rounded corners in IK classes, but I guess we don't want that anymore.
<Skipp_OSX>
Well I was hoping all buttons would get rounded corners at one point, but that didn't happen, so, oh well.
<nephele_mac>
They still can though
<nephele_mac>
If we remove them from the controlLook *interface* but not from HaikuControlLook
<nephele_mac>
then this can be an option of the controlLook
<nephele_mac>
like, how using flatControlLook is an option
<nephele_mac>
SuperGlossyHaikuControlLook could be an option
<Skipp_OSX>
I get it yeah
<Skipp_OSX>
we need sheets, but that's a whole other tangent
<nephele_mac>
what do you mean by sheets?
<Skipp_OSX>
drawers might be a better name
B2IA has joined #haiku
duncsauce has quit [Read error: Connection reset by peer]
<nephele_mac>
can you explain the concept of what you mean? those two words don't help me in context
<nephele_mac>
like what should those do
<Skipp_OSX>
like a panel connected to window that you can pull down for extra options, I guess it could be just another window.
duncsauce has joined #haiku
<Skipp_OSX>
it's a Mac OS X concept that's why
<nephele_mac>
like a ComboBox?
<nephele_mac>
Mac OS X concept, global menu bar ;)
<Skipp_OSX>
that's a macOS concept :)
<nephele_mac>
(I reckon we could use a global menu bar for every app that uses the proper layout kit api for menus...)
<Skipp_OSX>
it could be just a different window you open, sheets are fancier because they're connected to the original window and move around with it.
<nephele_mac>
huh? like cortex?
<Skipp_OSX>
no that's MDI
<Skipp_OSX>
(Multi-document interface)
<nephele_mac>
No i mean, enable the "Pull palletest" option
<IIsi>
Like...the way some dialog boxen are replaced with a kind of slides-down-from-top-of-window panel? Where the panel becomes modal for the tab/view you're on, without blocking the rest of the UI?
<Skipp_OSX>
so the idea is you have a sheet for the setting, that way each one can be different and it is still connected to the window.
<nephele_mac>
I almost never have these in MacOS. In gnome they are frequent and often obscure the UI, so now I *have* to deal with this instead of focusing on what i actually wanted
<Skipp_OSX>
each control look gets its own settings sheet and it can layout differenly
<nephele_mac>
why?
<IIsi>
Well, the one I linked is less obstructive than a dialog box, because it's scope is limited to the view that spawned it. Like, if a page in Safari triggered one, only that page would be blocked. The rest of the pages and UI are still available,.
<Skipp_OSX>
It's a better alternative to like in Screen Saver prefs you get a tiny square of prefs and everything has to fit in that square. With Sheets you can layout how you want.
<nephele_mac>
IIsi: in gnome the whole app is blocked. so that is miles better
<nephele_mac>
Skipp_OSX: that's not how it works normally...
<nephele_mac>
because of auto update size limits if your view is bigger the other settings will just be a bit bigger aswelll
nephele_mac has quit [Quit: Vision[]: i've been blurred!]
<IIsi>
Think I wasn't on the same thought train as Skipp, who seems to mean slide-out drawers?
HaikuUser has joined #haiku
HaikuUser is now known as nephele_mac
<Skipp_OSX>
well drawers are a similar concept but those didn't survive the test of time like sheets did.
<nephele_mac>
Skipp_OSX: No, they don't have to
<Skipp_OSX>
yeah they do and there's some crazy multi-tab screensavers that pack in a bunch of settings.
<nephele_mac>
again, no. they don't have to. the preflet just becomes the size of the largest settings view
<nephele_mac>
and even then you could just have your view be scrollable
<IIsi>
The drawers I'm now thinking of just have different decorations than the sheet view I linked. (:
<Skipp_OSX>
well, yeah ok nowadays that might be true but back in the good old BeOS days it wasn't.
<nephele_mac>
Well, hate to say it... but we aren't BeOS :g
<Skipp_OSX>
we are when you run BeOS screen savers
<Skipp_OSX>
but the real point is the design is fundamentally flawed. We should open a settings window for each screen saver and then you can do whatever you want.
<nephele_mac>
Skipp_OSX: check out for example preferences/Appearence. All tabs are the same size, but they are the size they are because of the "Fonts" tab
<nephele_mac>
If you remove the fonts tab the preferences window will actually shrink
<Skipp_OSX>
instead of being constrained to the box we give you and scrolling or adding tabs or whatever.
<nephele_mac>
No, again. that's not the way it works. you aren't constrained. You just use the proper layout with minimum sizes for controls and whatever, and the settings window will pick the apropriate size
<Skipp_OSX>
yeah we shrink and grow, it's still not idea if you have a lot of settings. It's not a big deal, but how are you going to implement Control Look sttings?
<Skipp_OSX>
I guess, I mean, that's not as flexible as sheets if we had sheets.
<nephele_mac>
BCardView?
<Skipp_OSX>
sure you can use layout kit but it has to adjust to the size and that can look strange.
<Skipp_OSX>
Imagine a really big settings view and then you change tabs on Appearance it will look silly.
<nephele_mac>
See, the ScreenSaverWindow has some sort of minimum width, and then B_AUTO_UPDATE_SIZE_LIMITS
<nephele_mac>
and then every view uses the layout kit
<nephele_mac>
Skipp_OSX: again, if you have way too many settings a) use a scroll view and b) you are probably doing something wrong
<nephele_mac>
my settings window for $component is way too large to fit in a preflet and would make it look wierd is a problem that should not be happening if you follow the haiku "way" of not adding options for stuff where it isn't neccesary
<nephele_mac>
besides. You can stack any small preferences view to a window with a larger minimum size and it adjusts just fine, it's a valid state to be in to have more "free" space
<nephele_mac>
You can stack appearence to locale preferences, it uses a bit more space then but it's still okay
<Skipp_OSX>
everything you're saying is right and valid, just sheets are a more flexible way to acheive the desired results.
<nephele_mac>
(except for the damn color picker)
<Skipp_OSX>
screen saver design comes from After Dark of course which had similar limitations
<nephele_mac>
the only real problem i see right now with screensaver is that the list view sometimes expands or contracts to the right. it should always be the same width
<Skipp_OSX>
you get a little box for your settings and they have to fit inside the box
<nephele_mac>
yeah, but that constraint just doesn't exist here
<nephele_mac>
assuming you can get the views before layouting. which is always the case for the settings preflets
<Skipp_OSX>
well assuming you use a layout that's true.
<nephele_mac>
Haiku apps should always use a layout if they use the be api
<Skipp_OSX>
Still the design is flawed if you really want to have a lot of settings for your screen saver.
<Skipp_OSX>
There is a specific example where this falls down but I would have to dig it up.
<nephele_mac>
if you want to have a
<andreasdr[m]>
Hi there?
<nephele_mac>
*lot* then open a new window, no?
<Skipp_OSX>
right, that's the idea
<nephele_mac>
seems to make more sense to me than having a dimissable modal view
<Skipp_OSX>
yeah basically that's the idea
<nephele_mac>
but this still seems like a "just do that then" problem, and not something requireing a new api or anything more specific
<Skipp_OSX>
well sheets make modals nicer, that's all.
<Skipp_OSX>
bc they are connected to the original window and move with it.
<nephele_mac>
I think modal views should be avoided whenever possible
<Skipp_OSX>
right but a control look with a lot of settings would be the exception
<nephele_mac>
some things should be improved still, like error popups blocking the functionality sometimes get lost behind windows. those should share focus for example
<nephele_mac>
(and have an entry in the deskbar)
<Skipp_OSX>
I implemented the half measure of always popping alerts on top of the window they are connected to.
<nephele_mac>
I think the cortex way of moving with the window is nice. That it removes the windows because you de-focus it seems jarring though
<nephele_mac>
Skipp_OSX: nevertheless i manage to often loose them :(
<Skipp_OSX>
I was only going to implement that on StyledEdit but Axel was like, no if you're going to do that, you should do that everywhere.
<Skipp_OSX>
yes, which is why sheets are better.
<nephele_mac>
especially when apps do stupid stuff, like Koder switching virtual desktops because i pressed alt-f
<Skipp_OSX>
right, with sheets you can't lose them bc they're connected to the window they operate on.
<nephele_mac>
Skipp_OSX: the problem with sheets, as they are used in gnome, is that they block the entire app, and often ask pointless questions
duncsauce has quit [Ping timeout: 480 seconds]
<Skipp_OSX>
well ok should only block the window, idk about Gnome's implementation
<nephele_mac>
No, should only block the view
<nephele_mac>
like, anything still accesible should be accesible
<Skipp_OSX>
uh yeah I guess so if you want to tab off
<nephele_mac>
so if you want to improve our "fatal" errors or questions to behave a bit more like sheets that's probably fine, i just don't want to have a UI pattern like gnome...
<Skipp_OSX>
I mean I like the shortcut hints gnome gives you
<Skipp_OSX>
that's kinda cool
<nephele_mac>
wdym? we have those in the menu?
<Skipp_OSX>
yeah but it gives you a nice help screen that lists them
<nephele_mac>
also since alert popups currently do *NOT* block the view, they should also not do that after your changes. I think if the continued operation of the app requires a critical question to be answered the app should disable all controls, and potentially a new api, or option for BAlert, that it should now always share focus with the specific window (both tabs are yellow, and share the same "depth")
<nephele_mac>
Seems like a thing that would be cool to have a generic layout class for so apps can easily implement something like that... maybe another constructor for the BMenu item that gives more explanations, and allow to construct a layout item from that
<nephele_mac>
and then shove it in a window with a default shortcut for this
<nephele_mac>
but yes, good idea to steal
<Skipp_OSX>
arg Trash so close yet so far
<nephele_mac>
maybe we could use my idea to make Trash only represent Trash on the disk it is on... :)
<nephele_mac>
and maybe make Trash on the Desktop just a folder with the Trashes and name them "<disk> Trash"
<Skipp_OSX>
I mean, I only have one disk in this example
<Skipp_OSX>
no no no the Trash design is definitely that way on purpose so that each volume has it's own Trash but they get combined onto the Desktop
<Skipp_OSX>
so if you trash something on a USB stick, unplug it goes with it.
<Skipp_OSX>
replug, it goes back in the Trash
<nephele_mac>
for the text clipping drag patch by the way, it's now -2 from pulko barring discussion... but i really don't know what to discuss about it :(
<Skipp_OSX>
well needs to be flushed out
<Skipp_OSX>
rest of the labels need same treatment, plus they just don't get it.
<Skipp_OSX>
plus single left-click is hated by more than just me, as I expected
<nephele_mac>
Skipp_OSX: yeah i know it's on purpose, but i don't really like that. I am often confused because of this, because there is no visual cue whatsoever on which drive Trash resides. Maybe this is a UI problem and should be adressed by a better View. i.e implement a proper view for Trash only and not use the generic tracker one
<nephele_mac>
single left click review is abandoned
<Skipp_OSX>
well ok but it shouldn't be
cassisian has quit [Remote host closed the connection]
<Skipp_OSX>
I get it you got mad bc they -2'ed it to death but it's still nice to be able to go directly to clipboard
<nephele_mac>
I think it's OK. because this can't work for checkboxes, and users can't neccesarily easily tell why
<Skipp_OSX>
I thought about that
<Skipp_OSX>
All controls can be activated on click, even the ones that are just regular labels.
<Skipp_OSX>
So we just don't worry about that
<nephele_mac>
I think it would be fine if we used right click to copy to clipboard in that case
<Skipp_OSX>
like menu fields labels always activated on click too but that's ok
<nephele_mac>
it would be consistent and would work always
<nephele_mac>
or we use middle click
<Skipp_OSX>
I hate middle click but fine
<nephele_mac>
it would even match up with the wierd "middle click is paste" unix way in textfields
<Skipp_OSX>
middle click should never be used is my opinion on that
<nephele_mac>
the only thing right click to copy would interfere with is if you actually want to add a menu. But then a) the mouseover tooltip is gone and b) the menu could still allow you to do that, just harder
<Skipp_OSX>
but idk I guess it's fine for this type of thing.
<nephele_mac>
yeah that's fine. middle mouse is often very annoying
<Skipp_OSX>
replicants have a right-click menu
<Skipp_OSX>
the little hand icon
<nephele_mac>
i just got used to it because it's the only way to use a modern webrowser, because the default way is "delete my tab and open the link here"
<Skipp_OSX>
to remove it
<nephele_mac>
but you can't copy the hand? so i don't see a conflict
<Skipp_OSX>
I see, yeah I don't do that
<Skipp_OSX>
you can't copy the hand?
<nephele_mac>
of the replicants
<nephele_mac>
it's not a text label? so it shouldn't conflict with right click to copy text
<Skipp_OSX>
oh I just meant, we're using the right click with single menu option elsewhere
<IIsi>
Did you mean s/tab and open/tab" and "open
<Skipp_OSX>
as a UI paradigm it has precedence is what I was trying to say.
<Skipp_OSX>
I do Cmd+click to open new tab *shrug*
<nephele_mac>
IIsi: no
<nephele_mac>
the standard "left click" on links in webrowsers just deletes my tab and overwrites it with whatever the link points to
<Skipp_OSX>
and I never do replace tab
<nephele_mac>
and this is almost never what i want
<IIsi>
Ok, then I didn't understand you. For browsers, I'm used to middle-clicking to close a tab, or middle-clicking a link to open in a new tab.
<Skipp_OSX>
well it doesn't delete the tab, it adds a history item
<nephele_mac>
Skipp_OSX: i didn't know cmd click could do that. but it's a bit cumbersume because the default case here is inverted, and websites can meddle with it
<nephele_mac>
it definetely deletes the tab. a history item is not the same thing to me. Only safari actually keeps the previous instance, and even safari sometimes deletes it
<Skipp_OSX>
middle click on Mac does nothing on links.
<Skipp_OSX>
which actually is somewhat surprising
<nephele_mac>
in safari i don't worry about it because i just swipe back, or use right click open in new tab...
<Skipp_OSX>
like not default, nothing, no action
<nephele_mac>
don't actually have a middle mouse button on my mac
<nephele_mac>
i guess mostly on mac i use right click open in new tab yeah
<Skipp_OSX>
maybe my middle mouse button doesn't work...
<Skipp_OSX>
Cmd+click FTW
<nephele_mac>
Skipp_OSX: i mean we can implement right click to copy on all text controls
<Skipp_OSX>
waddle still doesn't get it.
<Skipp_OSX>
but that's ok
<nephele_mac>
Yeah but if it's -2 unless we implement it my way we will never get anywhere....
cassisian has joined #haiku
<Skipp_OSX>
he'll come around
<nephele_mac>
it's very frustrating. On the one hand, as a paid developer it provides great value to the project, but on the other hand this behaviour makes other devs much less productive...
<nephele_mac>
Skipp_OSX: i was thinking a bit more on the copy button by the way
<nephele_mac>
i thought it's not so great before and kinda generic. but it does adress a critizism well that humdinger made that he doesn't want the cursor to change shapes often when moving over the ui
<nephele_mac>
so maybe for this specific case it's not that bad. and gives a "small" hint that something is copyable, but doesn't make the cursor significantly different
<nephele_mac>
though the small plus is maybe still not a great design to show it can be dragged and copied
<Skipp_OSX>
I like it, it shows you the shortcut options in a nice window
<Skipp_OSX>
I like menu bars too though but I get why they'd get rid of them for mobile centric design
<nephele_mac>
it's bad practice because gnome is bad is also a leap of logic that escapes me
<Skipp_OSX>
it's a cheat sheet
<x512[m]>
GNOME 3+ changes are terrible in nearly every aspect. So yes, it GNOME 3+ do something, it is nearly always a good thing to avoid.
<x512[m]>
I do not want Haiku to become GNOME 3+/
<nephele_mac>
I don't care. If they do something good we should copy it
<IIsi>
That shortcut viewer is fine for a documentation page. Having it as a window in addition to menubars seems harmless, and easily screenshotable for adding to documentation pages.
<Skipp_OSX>
yeah it's a cheat sheet
<x512[m]>
Text is better than screenshot for documentation.
<x512[m]>
Maybe adding some shortcut dumping command is useful for making documentation easier to write.
<nephele_mac>
IIsi: I kind of want automated tooling to turn Windows, or their BPicture representation into screenshots. Would be cool to automatically generate the screenshots for the userguide... could even do auto dark mode that way without extra effort
<nephele_mac>
or do some funky before/after tests based on render state or final render like webkit does
<Skipp_OSX>
commando hehe
<IIsi>
Yeah, x512. One common technique in documentation is to build a visual array of keyboard shortcuts and their descriptions, while a screenshot would work well for print, searchable is otherwise better.
<Skipp_OSX>
(A/UX app turns command line into GUI options)