<Skipp_OSX>
yes Linux follows the Windows convention.
<Skipp_OSX>
what did reverting my text view shortcuts accomplish?
<nephele>
I've not reverted it. What was the change trying to acomplish?
<Skipp_OSX>
waddle did
<Skipp_OSX>
It makes easier to move around text views with keyboard
<Skipp_OSX>
big jump/little jump
<Skipp_OSX>
but once again Windows/Linux thinking got in the way of understanding
<nephele>
I am quite baffled by this... I can understand that you are used to MacOS, but Haiku simply isn't macos... neither is it windows. We need to have something that is consistent in it's own right, and not something that is "opposite of windows" or "somewhat like macos but not really"
<Skipp_OSX>
BeOS used the Mac convention because it ran on Macs during its formative years by ex-Apple employees.
<Skipp_OSX>
Except when it didn't for unknown reasons.
<nephele>
BeOS isn't a religion Skipp_OSX, you can't use it to justify everything... Haiku isn't competing with BeOS
<Skipp_OSX>
So there should be no mystery, it's meant to follow the Mac convention, not the Windows/Linux ones.
mmu_man has quit [Quit: Lost terminal]
<Skipp_OSX>
That's just a way of saying you want Windows/Linux conventions mixed in.
<nephele>
nah
<nephele>
That's just me saying that it's dumb to try and justify things with "BeOS did it" if you have no other arguments
nephele has quit [Remote host closed the connection]
nephele has joined #haiku
<nephele>
The thing is, modern MacOS has also evolved. Even if BeOS wanted to follow whatever classic Mac did... we can't therefore say we have to do it like modern macos
<nephele>
funnily enough the ^ and < key also work the same way as they do on linux, on the mac keyboard layout in Haiku... and not like they do in macos
<Skipp_OSX>
yeah there's been a lot of Linuxisms and Windowsisms ported over.
<Skipp_OSX>
I mean a lot of the devs are on Linux so it makes sense they have a Linux mindset.
<nephele>
Well then, your assertion that it's supposed to work exactly like macos is wrong...
<nephele>
I'm on Haiku ;)
<nephele>
Linux is quite foreign with neeing ctrl for stuff
<Skipp_OSX>
Well it's not wrong, just BeOS died.
<nephele>
The website isn't wrong... Haiku is inspired by BeOS, no longer a reimplementation...
<Skipp_OSX>
sure that's true.
<Skipp_OSX>
It's like Cmd+Backspace to delete a file, went over like a lead balloon.
<nephele>
use the delete key?
<Skipp_OSX>
to delete a file in Tracker.
<nephele>
use the delete key :)
<Skipp_OSX>
That's Windows/Linux convention
<nephele>
That's what's written on the keycap
<Skipp_OSX>
No, because all shortcuts must use the Alt key
<nephele>
it's not a shortcut
<nephele>
the same way volume up or screenshot aren't a shortcut
<Skipp_OSX>
I mean, if you say so, it's in the menu.
<nephele>
or the calculator button
<nephele>
or the e-mail button
<Skipp_OSX>
screenshot is a shortcut on macOS
<Skipp_OSX>
media keys are separate, yes.
<nephele>
I doubt that
SArpnt[m] has joined #haiku
<SArpnt[m]>
odd question but how difficult would it be to make a wayland compositor for haiku?
<SArpnt[m]>
not for a custom desktop or to run linux programs, just the core, xdg shell, and some extra input protocols, whatever neccecary to get some wayland client application running
<SArpnt[m]>
or does that already exist
<nephele>
There is a not-compositor fake-server library like that, yes
<Skipp_OSX>
it's Cmd+Shift+3 or 4 for whole screen or selection
<nephele>
but it does not properly support the keyboard *shrug*
<nephele>
Skipp_OSX: Yes. And there is also a HID screenshot key....
<Skipp_OSX>
where?
<nephele>
On keyboards?
<Skipp_OSX>
which keyboards? mine doesn't have one.
<SArpnt[m]>
nephele: oh what's it called
<nephele>
so? does your computer not have a usb port?
<nephele>
SArpnt[m]: dunno :)
<Skipp_OSX>
it has a USB port yes
<nephele>
it's used by the gtk3 port in haikuports
<nephele>
Skipp_OSX: so then you can connect a device that has a screenshot key
<Skipp_OSX>
But I don't run Windows or Linux so that wouldn't be very helpful to me.
<nephele>
okay? I doubt macos can't support HID keys...
<Skipp_OSX>
I wouldn't know
<Skipp_OSX>
It has never needed them
<Skipp_OSX>
All I'm saying is that it's a convention that using the delete key deletes a file, not a rule. I have a delete key, but delete does not delete a file.
<nephele>
pretty suspicious considering my macos keyboard has a couple of them...
<Skipp_OSX>
you mean the ones in the F-key row?
<nephele>
it has a eject key for example
<nephele>
and screen brightness keys
<Skipp_OSX>
yeah on the F-key row with a Fn key
<nephele>
macos keyboards are a bit special, in that f-key state can be seen by the OS
<Skipp_OSX>
we could copy the F-key shortcuts I suppose
<nephele>
on most keyboards this is not the case
<nephele>
copy them.... for what?
<Skipp_OSX>
brightness, volume
<nephele>
what do you mean by copying them?
<Skipp_OSX>
play/pause, rewind, fast forward.
<Skipp_OSX>
I mean assign them to the corresponding F-keys.
<nephele>
they are not f-keys
<Skipp_OSX>
oh yeah but we make them F-keys in the same positions I mean
<nephele>
they make HID keycodes
<Skipp_OSX>
yeah I get it, there's an Fn layer.
<nephele>
kinda pointless if you don't have an Fn key, don't you think?
<Skipp_OSX>
but I'm saying we squash that layer, use the Fn keys
<Skipp_OSX>
right, use F1-12 instead I mean
<nephele>
for what?
<Skipp_OSX>
brightness up and down, reverse, play/pause, forward, volume
<nephele>
as default action for F(1-12) keys?
<Skipp_OSX>
yeah
<nephele>
I mean, aslong as alt-F(1-12) for workspaces still works... i don't see why not
<Skipp_OSX>
well obviously because of software that uses those keys
<nephele>
I don't know any
<Skipp_OSX>
yeah me neither but I'm sure some must exist out there
<nephele>
meh
<nephele>
I don't mind default shortcuts for those keys
<nephele>
you don't have to mess with the scancodes
<Skipp_OSX>
it's a losing battle
<Skipp_OSX>
like wargames, the only way to win is not to play
<nephele>
We should have a UI for when you used a key to increase/decrease volume
<nephele>
too bad i can't set brightness yet... You can set it over cec or edid or something over displayport
<nephele>
which is really cool tbh, linux can do that with my gpu and screen
<nephele>
though, of course, linux has no good UI for this :)
<Skipp_OSX>
you mean overlays?
<Skipp_OSX>
like volume and brightness key overlays that appear on screen.
<Skipp_OSX>
it's not as classy as macOS of course but I guess that works.
<nephele>
we already have a volume popup, we could just show it *shrug*
<Skipp_OSX>
yeah true
<Skipp_OSX>
hey but the Trashcan icon updates correctly now, so you know, priorities.
<nephele>
I'm only happy when it animates it getting full if you drag&drop /s
OscarL has joined #haiku
* OscarL
got a bit exausted reading up the back log... drops https://bpa.st/22YQ, and goes to bed.
<OscarL>
Have a good end of your day, everyone.
<nephele>
maybe some of the more interesting DeskBar redesigns can pick up some steam
<OscarL>
thanks for your work, in any case. always appreciated.
OscarL has quit []
<nephele>
have a good night OscarL :)
<Skipp_OSX>
One of the big reasons I made Deskbar mini-mode is for people that hate Deskbar so they can tuck it away and use an alternative.
<nephele>
wierd motivation?
<nephele>
you can just disable it if you don't want to use it
<Skipp_OSX>
You still have access to the replicants and the menu to shutdown
<Skipp_OSX>
the clock, but as an application switcher I mean.
<nephele>
the mini mode not supporting expanding apps (per default) makes it unusable to me
<nephele>
otherwise i would really like to use it on small netbooks
<Skipp_OSX>
you're meant to use something else for that
<Skipp_OSX>
I could do expanded apps though... I thought about it, it wouldn't be that hard to do.
<nephele>
wierd take. there is no technical reason this doesn't work
<nephele>
The mini deskbar fits exactly in the space left by tabs
<nephele>
perfect for really small screens
<Skipp_OSX>
yeah that's the point.
<Skipp_OSX>
so it's always accessible even if you have a full screen window open.
<nephele>
yes, and then i want to open it, and have the list expanded so i can move down and select an open window
<nephele>
i don't know how i'm supposed to use this without that funcionality
<Skipp_OSX>
well you can do that, just in a submenu.
<Skipp_OSX>
right, you're supposed to use something else for that part.
<Skipp_OSX>
the something else part hasn't really been developed yet, there are a few attempts though.
<nephele>
.... why?
<nephele>
just enable the functionality that is already in deskbar, and not disable it for no reason
<Skipp_OSX>
to use a separate application launcher
<nephele>
i don't need something else
<Skipp_OSX>
nobody disabled it.
<nephele>
it is disabled
<Skipp_OSX>
it's just tucked in a menu, not disabled.
<nephele>
the options get grayed out as soon as you enable minimode
<Skipp_OSX>
oh yeah because you can't expand windows that way, because they're in a menu
<Skipp_OSX>
that's not disabled though, that's working in a different mode.
<nephele>
?? and how does it work in the normal mode?
<Skipp_OSX>
expanding/collapsing menu
<nephele>
then do that
<Skipp_OSX>
would require some novel UI to do.
<Skipp_OSX>
I suppose you could hover the mouse over the team item to expand it.
<nephele>
Just use the code that's already there?
<nephele>
This doesn't require new UI, just do it the exact way it works now
<Skipp_OSX>
oh no because that happens on click and when you click a menu item it activates.
<Skipp_OSX>
can't well, maybe we could intercept the message and do it.
<Skipp_OSX>
but it's not disabled, it just never worked that way.
<Skipp_OSX>
and it's not intended to.
<nephele>
there is no reason why these two things use differen codepaths...
<Skipp_OSX>
they don't use different code paths.
<nephele>
then why does it behave differently?
<Skipp_OSX>
but they function differently
<Skipp_OSX>
well the menu is arranged differently, but it's the same objects underneath.
<Skipp_OSX>
team items and window items.
janking has quit [Quit: Vision[]: i've been blurred!]
<nephele>
okay. Just think this behaving differently is pointless
<nephele>
even if you think you can't do the application expander per item, it should be possible to have an all-expanded view...
<Skipp_OSX>
oh you could do it, it's just never been done.
<nephele>
"this code is bad because it came from BeOS"
<Skipp_OSX>
well ... yeah basically
<Skipp_OSX>
it did come from BeOS and the code was bad.
<nephele>
To be completely honest, I really like the idea of deskbar, but deskbar itself is kinda bad....
<nephele>
it tries to do too many things at once with all it's modes
<nephele>
and the menu is kind of bad to navigate. The suggestion on the forum to have applications one level higher already looks like such a nicer way to launch apps
zardshard has left #haiku [Disconnected: Hibernating too long]
<nephele>
also, i really dislike it beeing on the right of the screen, then opening one menu to the left, and then one to the right, and then one to the left
<nephele>
if it's on the right it should open all to the left
<Skipp_OSX>
yeah that's kinda silly
<Skipp_OSX>
it prefers to open to the right if there's room
<nephele>
there is a couple bugs where it will open to wierd locations or offscreen...
<nephele>
should be told to keep some consistency
<nephele>
the menus of the tray icons also open in random positions, instead of all aligned somewhere...
<nephele>
the calendar seems to consistently take a good position
<nephele>
but the others will open half offscreen or overlap the tray icon they are associated with
janking has joined #haiku
<nephele>
Skipp_OSX: where can i find the code for the "main" deskbar view?
<nephele>
i.e if i have it in normal mode with the leaf menu visible
nephele has quit [Remote host closed the connection]
nephele has quit [Quit: Vision[]: i've been blurred!]
julienxx has joined #haiku
janking has quit [Quit: Vision[]: i've been blurred!]
janking has joined #haiku
OscarL has joined #haiku
linuxmaster has quit [Ping timeout: 480 seconds]
linuxmaster has joined #haiku
BrunoSpr has joined #haiku
<BrunoSpr>
Hi all, a common question, If I want my application in english, I have to switch to english in preference (Locale) and then install the app with HaikuDepot?
<BrunoSpr>
How can I set the language inside the app (Krita)? Is it possible at all?
<OscarL>
BrunoSpr: you should be able to just change the language after installing the app (assuming the app *has* been localized).
<OscarL>
Ah... for ported apps, that might be different.
<OscarL>
But apps do not have separate localization packages, AFAIK, so either the app has support for different languages you can change after installing it, or it just doesn't.
<OscarL>
BrunoSpr: I don't have any kde/qt stuff installed, so can't help you, sorry. Maybe Begasus can answer when he's around.
linuxmaster has quit [Read error: Connection reset by peer]
<OscarL>
good day, Begasus[m]. when my IP-range was banned by 0x0.st... took quite a while to sort out :-( (thus why I was using ibb.co again)
<Begasus[m]>
OscarL: I can get bacon to build, but got this nasty question at the end "INFO: see full error report (y/[n])?"
<Begasus[m]>
oh right still got that one :D
<Begasus[m]>
ps, hi there OscarL :)
<Begasus[m]>
I "could" move it to GTK4, but rather not :P
<OscarL>
Begasus[m]: re: bacon: odd. if it is a script asking for user input, I think you should be able to automate a true or false "reply", no? like "yes | foobar" or "echo n | <script that ask for user input>"
<OscarL>
assuming the issue is that it "halts" while asking the user, and not that you're worried that there are errors.
<OscarL>
ah, seems that besides the asking, it just ends due to such "errors". I had to use "<foobar script that fails> || true" in Python .patchsets, to stop the builds from failing.
<OscarL>
(some tests fail, breaking the PGO build step in newer versions.... that "|| true" makes it so the rest of the makefile thinks the step resulted OK)
<OscarL>
Begasus[m]: your first paste starts with "if [[ $g_QUIET -eq 0 ]]", so maybe see if you can set that $g_QUIET var to 1 so that block asking the user doesn't runs.
<BrunoSpr>
Begasus[m], I tried to chang the language inside Krita, but it will not change!
<BrunoSpr>
Upload seems to work...
<OscarL>
you'll prolly still need to add "|| true" somewhere if the "errors" still stop the build.
<Begasus[m]>
let me try something there (adding it in Makefile.in
linuxmaster has joined #haiku
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
<OscarL>
Begasus[m]: sounds good. I had that "|| true" in a Makefile.pre.in for Python's. Good luck there!
* OscarL
is still head-scratching while reading "repo_consistency.txt"
<Begasus[m]>
yeah, noticed this morning those k* references were gone?
<OscarL>
most things seem to boild down to the missing "cmd:python", solving that one for dbus might clear things up a lot.
bbjimmy has joined #haiku
<Begasus[m]>
bleh ... /bin/sh: -c: line 2: syntax error near unexpected token `||'
<Begasus[m]>
hi bbjimmy !
<Begasus[m]>
did you get gimp issue solved?
<OscarL>
I *think* the report is trying to say... "Look, man... if you'd asked me to build ALL the recipes... these (dependency chains) wouldn't work."
<OscarL>
"as dbus is used by lots of things, and it is "missing" cmd:python (if we were about to re-build that recipe as-is), all these would fail"
<Begasus[m]>
could be, but to me some in there don't make sense
<Begasus[m]>
checked if the old one isn't used anywhere?
<OscarL>
re: some not making much sense: true... thus why I'm trying to boil down the report to try to see where the problem starts (head gots a bit dizzy already)
<bbjimmy>
no. I have to un-install gimp to update haiku, then I can re-install gimp 3.0.0.3
<Begasus[m]>
right with you there :)
<Begasus[m]>
:/
<OscarL>
re: old dbus... did last night, but will double check after coffee kicks in.
<Begasus[m]>
could have a look later again, build a new image yesterday that doesn't have anything in it
<bbjimmy>
Begasus[m] same issue
BrunoSpr has quit [Quit: Vision[]: Ich wurde eingeweicht!]
<Begasus[m]>
bbjimmy: tried a few days ago on a 64bit nighly bare metal install, worked fine there, so I'm really puzzled why it fails for you :(
BrunoSpr has joined #haiku
<BrunoSpr>
Some problems with HaikuDepot atm?
<bbjimmy>
everything else works and I have spent hours trying different "fixex" with no joy.
<bbjimmy>
*"fixes"
<OscarL>
Begasus[m]: depot only has dbus 1.22.0 available for download/install (on 64 bits at least, will check 32 bits via depot.haiku-os.org)
<Begasus[m]>
+1 OscarL
<OscarL>
both 1.10 and 1.22 dbus have the same provides, so I think someone just forgot to remove the old recipe when adding 1.22
<Begasus[m]>
bbjimmy: size was the same right? (about 30MB iirc)
<Begasus[m]>
checksum was correct
<OscarL>
looks like only dbus "1.12.20-6" is available on 32 bits too.
<Begasus[m]>
it's the only one installed on 64bit too
<Begasus[m]>
should boot the other to 32bit
Begasus has quit [Quit: Vision[]: i've been blurred!]
<OscarL>
would be nice to run "pkgman --arch x86 search foobar" or something like that instead of having to reboot into 32 bits just to check that kind of data.
BrunoSpr has quit [Quit: Vision[]: Ich wurde eingeweicht!]
<Begasus[m]>
ow, lol, I could just look into the 32bit partition also :P
<bbjimmy>
yes
<Begasus[m]>
1.12.20-6 dbus_x86
<bbjimmy>
same size as 3.0.0.3
<Begasus[m]>
for primary it's also the same version OscarL
<OscarL>
nuking old 1.10.x recipe should be safe then, right Begasus[m]? /me has a finger ready on top of the green button.
<Begasus[m]>
so nuke the old one :)
<OscarL>
we should not have x86_gcc2 dbus at all.
<Begasus[m]>
yeah, even had to set the requirement to the package name instead of the command for that
<OscarL>
"name one ported packaged that needs dbus that is build with gcc2"
<OscarL>
even in the crazy even that there *is* one... it should be moved to modern gcc anyway :-)
<OscarL>
that's what you get from trusting crazy guys.... <shakes head>
gr0egor has joined #haiku
<Begasus[m]>
the sollutions still puzzles me though
<Begasus[m]>
I had to delete the data partition to be able to boot the USB thumbdrive
<Begasus[m]>
so the bootmanager was somehow puzzled about the partitions
r6fej has joined #haiku
<OscarL>
Begasus[m]: regarding bacon... tried changing "./bacon.sh -c" to "./bacon.sh -c -q" in the Makefile.in ? (that should set to "quiet" mode, and thus not ask the user, if I'm reading things right.
<OscarL>
yeah. there's something odd lurking in the boot process, where it gets sometimes confused by existing BFS partitions, it seem :-(
<Begasus[m]>
not going to bughunt there now :P
<OscarL>
I can prepare a new zlib for you if you want! :-P
* Begasus[m]
calls for aid .... DaaT!!!
* OscarL
gets a trout-proof shield, just in case. Also some grass for the incomming sheeps.
<Begasus[m]>
ps, trying that bacon thing -q
<Begasus[m]>
if that doesn't work for bacon.sh I'm adding it to bacongui-fltk :
<OscarL>
that part seems to not use a .sh, but "bin/bacon" (haven't read the code for that)
<OscarL>
but... worth a try.
<Begasus[m]>
right, but bacon is a script holding that part/check
<Begasus[m]>
almost there ...
<OscarL>
god damn things are > 527 KB in size. I ain't reading all that! :-D
<gr0egor>
Should I use nightly image or Beta version, if I want more stable USB drive mounting/unmounting that does't cause kernel panic?
<Begasus[m]>
that didn't work
<Begasus[m]>
lol OscarL , the check is at the end of that file :P
<Begasus[m]>
beta is considered to be stable gr0egor
<Begasus[m]>
nightly "can" brake on updates
<Begasus[m]>
but has newer fixes
<OscarL>
gr0egor: "depends" (as usual). nightlies update more frequently, and can thus break, while beta5 is more "stable". If you had problems with beta5, trying a nightly makes sense.
<OscarL>
I haven't had much issues with beta5 on that regard (usb drive mount/unmount), if at all. YMMV.
<Begasus[m]>
same here, running beta5 without much issues (if any)
<Begasus[m]>
only those caused by OscarL :P
<OscarL>
Begasus[m]: using "yes | make" or "echo 'y' | make" on the bacon recipe doesn't works either?
<Begasus[m]>
will check on the next try OscarL
<Begasus[m]>
maybe I should push the new dbus version, probably will clear some stuff in that report
<OscarL>
(if you do, remember to drop the gcc2 package)
<Begasus[m]>
bah ... System error: file 'g++.bac' not found!
<Begasus[m]>
another round ....
<Begasus[m]>
echo 'n' | make (worked, thanks OscarL !)
<OscarL>
nice!
<OscarL>
Begasus[m]: for future reference... you could also use the hilarious: "yes no | make" :-D
<nekobot>
• Begasus (7a1b30c5): bacon, revbump for new fltk (#12699)…
<Begasus[m]>
OscarL: not sure I want to test that :P
tuaris has joined #haiku
Begasus_32 has joined #haiku
<Begasus[m]>
launching "hp git_x86"
<OscarL>
I *think* that triggering a rebuild of openexr-2.4.1 (so its uses newer cmake at build) could solve the reports issues related to "libhalf_2_4".
<Begasus[m]>
finaly! mv: cannot stat '/packages/dbus-1.16.2-6/.self/data/doc': No such file or directory
<Begasus[m]>
fix it? :P
<OscarL>
still juggling around the repo_consistency.txt file to see what makes more sense to try to "fix".
<OscarL>
dbus not expecting cmd:python should go a long way at clearing things up, it seems :-)
<Begasus[m]>
probably :)
<Begasus[m]>
finetuning so it install documentation in CMAKE_INSTALL_DOCDIR instead of CMAKE_INSTALL_DATADIR/doc/dbus
<OscarL>
then the openexr, then some ffmpeg stuf... and only a handfull should remain.
<Begasus[m]>
better
<OscarL>
I wouldn't spend much time in dbus docs, is hardly of any use for developers in Haiku.
<OscarL>
we only have it because of ports that do not allow to just disable that dependency, no?
<OscarL>
but... I'm not get in the way if you want to make the recipe neat anyway :-)
<Begasus[m]>
moving doc to seperate package
<OscarL>
sometimes I do "useless stuff" just for practice :-)
<Begasus[m]>
saves about 2.7MB for the _devel package :)
<Begasus[m]>
lol
<Begasus[m]>
yeah, some ports just can get around it
janking has quit [Quit: Vision[]: i've been blurred!]
Begasus_32 has quit [Quit: Vision[]: i've been blurred!]
<Begasus[m]>
k, that should do it for dbus
* OscarL
looks up why the hell we have dbuspython... *of course* it had to be calibre. sigh.
<OscarL>
that thing is a Jenga tower.
<Begasus[m]>
latest calibre versions require qtwebengine for qt6, so a nogo
<OscarL>
in any case, if new dbus gets merged, will do a rev-bump on dbuspython, and drop 3.9 while at it.
<Begasus[m]>
+1
<Begasus[m]>
have the new version installed for some time here, haven't seen a downside
<OscarL>
(not updating it, because I can't be arsed to test calibre at the moment :-P)
<Begasus[m]>
heh
<Begasus[m]>
current calibre doesn't use python3.9?
<OscarL>
minor nitpick/suggestion... the "echo 'n' | make" in the bacon .recipe could have used a comment, like "stops it from waiting for user input on about some warnings", or something like that.
<OscarL>
(saves future readers some head-scratching)
<OscarL>
now crossing fingers on that dbus change clearing things up! thanks there Begasus[m]!
<Begasus[m]>
right, could you add it? I'm out in a short while
<OscarL>
no problem.
<Begasus[m]>
on 64bit the report is cleaner already :)
<OscarL>
indeed :-)
<Begasus[m]>
yay! :D
* OscarL
removes all the dbus stuff from his re-arranged report.txt
gr0egor has quit [Quit: Page closed]
janking has joined #haiku
zardshard has left #haiku [Disconnected: Replaced by new connection]
zardshard has joined #haiku
* Begasus[m]
wonders if it would be possible to grab those reports on new PR's before merging ...
Anarchos has joined #haiku
Anarchos has quit []
HaikuUser has joined #haiku
<OscarL>
libxfont2 recipe seems to have a typo (thus why it appears in the reports), but...
HaikuUser has quit []
<OscarL>
nothing seems to use either libxfont nor libxfont2 on repo?
* OscarL
starts sharpenning the axe, just in case.
scantysnax has quit [Quit: Vision[]: i've been blurred!]
janking has joined #haiku
HaikuUser has joined #haiku
janking has quit []
janking has joined #haiku
HaikuUser is now known as nukacal
rock4u has joined #haiku
rock4u has quit []
nukacal has quit []
HaikuUser has joined #haiku
<janking>
:)
janking has left #haiku [#haiku]
HaikuUser has quit []
HaikuUser has joined #haiku
janking has joined #haiku
rock4u has joined #haiku
rock4u has quit []
dodo75 has quit [Quit: Vision[]: i've been blurred!]
dodo75 has joined #haiku
janking has quit [Remote host closed the connection]
janking has joined #haiku
janking has quit []
janking has joined #haiku
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
janking has quit [Quit: Vision[]: i've been blurred!]
dodo75 has quit [Quit: Vision[]: i've been blurred!]
dodo75 has joined #haiku
nukacal has joined #haiku
dodo75 has quit []
dodo75 has joined #haiku
janking has joined #haiku
nukacal has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<OscarL>
we need to do some cleanup around openexr. Having 5 different lib versions is a bit excessive.
* OscarL
tries to track down "who needs what".
jmairboeck has quit [Quit: Konversation terminated!]
MisthaLu has quit [Quit: Leaving]
BlueSky76 has quit [Quit: WeeChat 3.8]
BlueSky76 has joined #haiku
<OscarL>
seems only openexr25 is not actually needed by other recipes.
fancy2209 has joined #haiku
DKnoto_W has joined #haiku
DKnoto has quit [Read error: Connection reset by peer]
erysdren has joined #haiku
<nephele>
OscarL: Work in progress flag on gerrit is super not-usefull
<nephele>
it's just hiding changes for no reason.... :)
<OscarL>
nephele: that's why I asked about it.
<nephele>
I think i'll boot debian to do more zig adventures
<nephele>
zig on haiku is a bit broken atm
<OscarL>
re: gerrit wip tag... should let Anarchos about your thought on it
<nephele>
llvm19 is missing the AVR backend zig needs, and llvm20 based zig has a build issue
<OscarL>
*know about
<nephele>
I need more space for my desk OscarL :(
<nephele>
too many computers
<nephele>
i had only one, but the linux pc now is seperate...
* OscarL
remembers "complaining" to zig devs about dropping support for x86_64-baseline processors. They reverted the change once they heard people still using Phenoms down here :-)
<nephele>
oh, zig acomodated you?
<OscarL>
yup.
<nephele>
very cool
<OscarL>
indeed.
<nephele>
Do you have any vulcan capable hardware?
<OscarL>
re: space... need more racks on walls, or just hang pc parts from the ceiling! :-)
<OscarL>
nephele: have a GeForce GT 1030 2 GB GDDR5 that one of my brothers gifted me.
<nephele>
I'm going to build a game+game engine with my brother likely... and vulcan is probably going to be the baseline. So I am curious if vulcan can be used in some capacity there
<OscarL>
this netboook has vulkan support too (theorically), but is just too slow to do much other than ultra basic demos.
<nephele>
I want my game to be useable even very low-end vulcan hardware
<nephele>
maybe not with all the bells and whistles
<OscarL>
welp... guess I might be able to give you a very low-end baseline test report then :-D (Intel HD 600)
<nephele>
is that 6000? i can't find any 600
<nephele>
though the 6000 is marked as not supporting vulcan on intels website, but with direct3d12
<OscarL>
on these low end devices... "latest generation API support" is in general only nominal. Like Radeons HD 3000 being "DX10 compatible", meaning... yeah, the drivers claim support so your program doesn't immediatly fails...
<OscarL>
but actually running the stuff... totally different thing :-D
<OscarL>
the GT1030 supports DX12 for example, but good luck running anything other than DX11/OpenGL. Vulkan/DX12 stuff runs slower (if at all).
<nephele>
well, i wonder like for a game engine.... i basically want to have a *really* interactive work. And that could have nice graphical effects, but that doesn't mean you can't just turn it off for lower end hardware
<nephele>
aslong as the gameplay is really fun it probably doesn't matter much
<OscarL>
(just mentioning, so you are aware of these "compatible but not really" low end devices)
<nephele>
There is some games that were quite fun in their alpha state... then became "proper" games with much more "cool graphics" and stopped beeing fun :(
<nephele>
yeah... i can't support everything of course, if the device just doesn't support it then it won't support it
* OscarL
finds that OG Stalker is fun, even if run in DX8 level graphics :-)
janking has quit [Quit: Vision[]: i've been blurred!]
<nephele>
i often turn down graphic settings if that means that I instead can hit my refresh rate goals
<nephele>
even with a high end gpu i'd rather have responsiveness and fun than just visual "nice screenshots" :)
<OscarL>
been playing some awesome total-conversion mode for DOOM2, running on gzdoom... some "bad graphics" can be a plus.
<nephele>
I should play some blade runner on this pc
<nephele>
it can run on haiku
<nephele>
i wonder how difficult video decoding acceleration would be....
<OscarL>
would be nice to have some, for sure.
<OscarL>
with the little I know about that... it might be easiest in intel hardware (via thinks like QuickSync + some of those intel_media_something libraries that Linux has available)
<nephele>
I guess just re-using VAAPI makes sense
<OscarL>
on the newer Nvidia cards that have that more "open" driver might be more doable too, I guess. x512[m] surely knows better there.
<nephele>
they aren't more open really
<nephele>
they just run the bulk of the driver on the card...
<x512[m]>
I think that Vulkan Video API is better than VAAPI.
<OscarL>
I know, but the newer driver structure should allow for easier creation of drivers at least.
<x512[m]>
NVK also has not yet applied but working patch for Vulkan Video decoding.
<OscarL>
(meant that as reply to nephele's comment about openness)
<x512[m]>
From OS developer point of view, firmwares working on GPU are part of hardware and don't harm openness at all.
<x512[m]>
Unless you demand fully open hardware design, there are no problem in Nvidia GSP firmware.
<nephele>
Uhm... no. The entire point of open source drivers is to be able to maintain them yourself. If they are instead a closed source blob that isn't given.
<nephele>
For example nouvea can achieve proper framebuffer resolution on linux in many cases where the nvidia driver cannot
<OscarL>
While 100% open is a nice goal... we don't complain much about firmware running on SSDs/NVMEs.
<nephele>
OscarL: sure? but i also did not call them open drivers...
<x512[m]>
You do not need to care about GSP internals at all. You just send commands to it like to any other hardware.
<x512[m]>
Kernel Nvidia driver is 100% open and released under MIT license.
<OscarL>
nephele: i *did* used "scare quotation marks" around open for a reason.
<x512[m]>
I think that Nvidia drivers are actually more open than AMDGPU because AMD do not release low level documentation at all for their new GPUs. Just put source code without explain.
<x512[m]>
AMDGPU Linux kernel contributors are AMD employees that have access to internal GPU documentation.
<OscarL>
(darn SIM cards running java should be scarier than some closed firmware in a GPU used for gaming and video decoding. I'd like for things to be different, but have to choose some batlles, and pass on others)
<OscarL>
today it seems I choose to battle some haikuporter's repo consistency reports :-)
janking has joined #haiku
janking has quit []
sai_the_lass has quit [Remote host closed the connection]
<nephele>
I need to get framebuffer support first OscarL
<nephele>
and when i got that i will probably do displayport link training
<nephele>
and then displayport audio
<nephele>
and then displayport brightness controls
<nephele>
and then probably the media decoding ;)
<OscarL>
sounds like a plan!
<PulkoMandy>
Brightness control shoulo still be ddc/ci even for displayport (same as it has been for vga and hdmi)
<nephele>
yes, but i don't think we have this implemented?
<PulkoMandy>
This uses the same communication as edid info, and is well documented, so that part should be easy to do
<PulkoMandy>
No low level hardware things, just adding new commands and responses on the ddc bus
<nephele>
PulkoMandy: I see you removed your -2 for Drag&Drop for the string labels, are you now satisfied with the discussion? To me it seems like the same arguments will probably still be in the review... and not much is resolved :/
frkazoid333 has joined #haiku
<PulkoMandy>
There is a discussion on the mailing list which works much better and several more people took the opportunity to participate
<nephele>
well, if the dcc bus is available sure. maybe it is easier than i think. Currently there is no specific support for my gpu generation in our driver (have one of those intel arc gpus), so would need to get that supported first
<PulkoMandy>
So I have no reason to -2 it now
Halian| has joined #haiku
Halian has quit [Ping timeout: 480 seconds]
<nephele>
I don't think the dicussion resolved anything really... I did write down why i think a systemic aproach is a good idea, but apart from your response that has not really gotten any engagement either
chilledfrogs has quit [Quit: connection reset by purr]
<nephele>
so before I got a wierd objection to drag&drop, and now after that discussion that same objection will be brought again... but still no arguments of why it would be a bad idea
frkzoid has quit [Ping timeout: 480 seconds]
dodo75 has quit [Quit: Vision[]: i've been blurred!]
<PulkoMandy>
I have no objection about it, but I would put it behind a flag and enable it only for some views. Maybe just in case an app wants to use drag for its own purposes, it would be annoying if that interferes
figment has quit [Ping timeout: 480 seconds]
<nephele>
Well, yes? but a flag to turn it off (or well, an api call) was already in the idea of the original design...
<PulkoMandy>
So I have no objections, and I removed my -2. Everything is good for me
<nephele>
is there some abi consideration if we use a flag? I assume those are passed as some integer, can i check how much room would still be available?
<PulkoMandy>
If other people have complaints tou can point them to the mailing list thread showing that no one offered a better idea
OscarL has quit [Quit: bbl]
<PulkoMandy>
View flags are a 32 bit integer where we could add that, or maybe a separate flag field just for ostringview makes sense
<PulkoMandy>
I think it already has one flag to enable multiline strings? But I'm not sure
fancy2209 has joined #haiku
<nephele>
The entire "edit war" was only because of the suggestion that drag&drop is bad and it should instead be selecting text and then drag&drop...
<nephele>
BStringView? Well there are also other "Text" labels that were considered. I guess then it makes sense to pick a higher flag
<nephele>
Atleast BBox i think is important to also be draggable.... though i think it is already draggable
<PulkoMandy>
I don't see where it would be useful in other cases (checkboxes, ...) and there is a higher risk of interfering with other mouse actions
<nephele>
Well, if it is systemic and always-on it's easier to learn and grasp... if there is nothing interfering it would be nicer to let users decide what they think is interesting to drag or not
<PulkoMandy>
And al o the question of visual feedback for this is unanswered I think (drag hand cursor? Background color highlight? Something else?)
<nephele>
though i can understand for interactable controls that this may be a bit annoying
<nephele>
visual feedback for what? We already can show the dragged object
<PulkoMandy>
You can "cancel" a click on a control if you move the mouse out of it before releasing it in some cases
<nephele>
that is enough to show you are dragging it
<PulkoMandy>
so starting a drag may not be a good idea there
<nephele>
In some cases is not nice. this should be in all cases. But yes, that exact thing (beeing able to cancel) makes it not interfere *if* this is implemented properly
<nephele>
though i can see how a user may be confused about that, and it may be harder to learn
<nephele>
the copy cursor looks like the normal cursor plus a small plus below it
<PulkoMandy>
The dragged object is after you start dragging. My ouestion is, how do I know that there is something to drag and whichtext exactly will be selected (esoecially if this is not enabled for all types of texts)
<nephele>
that would be enough indication to show this is possible
<nephele>
hmm, if you want to know what text, maybe an underline?
<PulkoMandy>
Just like we have an i-beam cursor when there is selectable text
<nephele>
we do have an about-to-grab cursor aswell
<nephele>
I think only WonderBrush uses it?
<PulkoMandy>
Yes, so we could use that, it may be enough
<PulkoMandy>
Time to sleep here, good night :)
<nephele>
I'll try to hammer these two patches together... I really hope we can get this UI improvement in :/
<nephele>
Have a good night PulkoMandy
chilledfrogs has joined #haiku
janking has quit [Quit: Vision[]: i've been blurred!]
mmu_man has joined #haiku
mmu_man has quit []
figment has joined #haiku
xet7 has quit [Remote host closed the connection]
janking has joined #haiku
janking has quit []
Halian| has quit []
dalme has quit []
mmu_man has joined #haiku
nephele has quit [Quit: Vision[]: i've been blurred!]
janking has joined #haiku
janking has quit []
B2IA has quit [Quit: Vision[]: i've been blurred!]
B2IA has joined #haiku
janking has joined #haiku
fancy2209 has left #haiku [#haiku]
<janking>
:)
Halian has joined #haiku
fancy2209 has joined #haiku
janking has quit [Quit: Vision[]: i've been blurred!]