<Begasus[m]>
first real attempt at building something against it, pretty pleased :D
cassisian has joined #haiku
cassisian has quit [Ping timeout: 480 seconds]
freddietilley has joined #haiku
cassisian has joined #haiku
cassisian has quit [Ping timeout: 480 seconds]
mmu_man has joined #haiku
AlaskanEmily3 has joined #haiku
bunkermatty has quit [Remote host closed the connection]
bunkermatty has joined #haiku
bunkermatty has quit [Remote host closed the connection]
bunkermatty has joined #haiku
cassisian has joined #haiku
cassisian has quit [Ping timeout: 480 seconds]
OscarL has joined #haiku
cassisian has joined #haiku
fancy2209 has joined #haiku
<Begasus[m]>
bah ... feature `edition2024` is required
<Begasus[m]>
hi OscarL ! :)
<Begasus[m]>
didn't see you sneak in :P
<OscarL>
Hola Begasus[m] :-)
<Begasus[m]>
doggies in a bit ...
<OscarL>
(here for just a few minutes today)
<Begasus[m]>
how is it going there?
<OscarL>
good generally, but sleep schedule, and hours where I can access the internet with less restrictions... have not matched lately :-D
<OscarL>
Been writting a new simple driver.
<OscarL>
for Winbond W83627DHG LPC Super I/O chips... in particular, for the hardware monitoring part.
<OscarL>
got voltages, temps, and fan speed working.
cassisian has quit [Ping timeout: 480 seconds]
<Habbie>
nice
<OscarL>
Seems about the level of complexity I can handle :-D
<Begasus[m]>
no idea about those chips, but nice that you're still keeping the brain alive :)
<OscarL>
(already have one for ITE87xx chips, and also have the "amd_temp" driver :-D)
<OscarL>
My hopes is that with a bit of more practice... I *may* move up to a bit more complex drivers.
<Begasus[m]>
HDMI? so I can hook up the external monitor :D
dqk_ has quit [Ping timeout: 480 seconds]
<OscarL>
I wish :-)
<Begasus[m]>
bugger :)
<OscarL>
I may try to at least *read* about HDMI audio... but I really doubt I'll make any progress there either :-D
<OscarL>
Habbie:
<Habbie>
nice
<OscarL>
ups.. wrong keyboard.
<OscarL>
in any case... hello there Habbie, always nice to read you.
<Habbie>
hello!
<Begasus[m]>
heh
<Begasus[m]>
k, where did I saw this "gjs" again ...
<Begasus[m]>
whoops: Javascript Bindings for GNOME
<OscarL>
If I'm reading a similar driver (from netbsd) right... I may be able to make my mine also support the older National Semi LM78 and the like. (was *big* back in the days, so many older mobos might use it)
<Begasus[m]>
bah: Dependency libadwaita-1 found: NO. Found 1.6.0 but need: '>= 1.7'
<Begasus[m]>
it's not playing nice here today :P
<Begasus[m]>
and missing gtksourceview-5 now ...
<Begasus[m]>
biab, first doggies :)
<OscarL>
enjoy.
* OscarL
wonders... should these drivers be under "/dev/sensor/" or under "/dev/hwmon/"?
<OscarL>
currently usingthe former, but I kinda like the latter more, as we may add fan control to the supported features, making them more than just "sensors".
<Habbie>
do different features of the driver need to live in the same part of /dev ?
<OscarL>
(Haiku has some "thermal" drivers under "/dev/power" :-D)
<OscarL>
Habbie: nah, AFAIK, you're free to do whatever you want... I'd just like to keep things as easy to read as possible while "browsing" /dev.
<OscarL>
so leaving parts of it under "/dev/sensor/", and say, "/dev/fan_control" would be possible, but maybe a bit too much.
dqk has joined #haiku
<OscarL>
for simplicity (for now at least), I'm sticking with having only one "char" interface you can read ("cat /dev/sensor/wbhm"), and an ioctl interface to get raw data (and possibly allow fan control, for example).
<OscarL>
(motherboards differ wildly on the scaling they do to get proper voltage readings, so it be better to leave that for user-space apps to handle, I think)
<OscarL>
Oops, internet time is up for me. See you around folks. Have a great day!
<Habbie>
modest proposal to rename /dev to /devices
<nephele>
Habbie: hot take. but i don't think the /dev + ioctl interface is that good :P
<nephele>
but i wouldn't mind renaming it...
<Habbie>
no wait
<Habbie>
let's team up
<Habbie>
we'll do the newer, better interface in /devices
<nephele>
heh :)
<nephele>
Habbie: can you design a better api than ioctls? :)
<Habbie>
i assumed you already did that
<Habbie>
:)
<Habbie>
also. probably :D
<nephele>
I did not. I can basically write down what i think the shortcomings are of ioctls, but i have not designed a new api xD
<Habbie>
is netlink better?
<nephele>
also because i'm not really a C developer that much
<Habbie>
or, more generally, is there something better out there? because there is plenty out there
<nephele>
there is probably something better? but i've not investigated
<Habbie>
ack
<Habbie>
ok, i need to stop being distracted by this :D
<nephele>
i just wanted to do a quick git pull but i have severall changes i first need to commit in my webkit xD
cassisian has joined #haiku
<phschafft>
Any problem about having files like /dev/ptmx that require a special sequence of open calls and ioctls to signal the kernel that you want to create new devices in a way that sounds like a magic spell?
<phschafft>
with an interface that passes data between the kernel and userland which not even know the size of what you pass around?
<phschafft>
;)
<nephele>
phschafft: that just sounds like more ioctls!
<phschafft>
;)
<phschafft>
if you want something better than ioctl()s... I suggest...
<nephele>
rl;dr is basically clone from our instance because you need the tags; install the git hook which makes the commit-ids; then you can push to gerrit (if you have an account there...)
<nephele>
Habbie: I think BMessage is not nicely accesible in C
<Habbie>
ah, C
<Habbie>
so?
<nephele>
I think we should have an equivalent api for BMessage to work with the data type. not that it has to have all concenienve methods, but so you can use any programming langauge that "just speaks C" and pass BMessages around to other parts of the OS, or understand them
<phschafft>
(mind: I'm not in office right now so I have very limited access, even to a browser)
<phschafft>
better support for BMessage will surely be good. but there are some design flaws in the BMessage (which have been discussed before) which might make it not the best option as of now for some tasks.
<nephele>
which design flaws? I think you only mentioned the on-disk format... but that actually is stable acorss architectures afaik
<phschafft>
the code I have seen doesn't support that claim. it would need to be rechecked.
<phschafft>
but we also discussed that it is hard to understand the messages out-of-context.
<phschafft>
which is a key feature when you push them around between different parts of the system or between systems. and actually one of the major flaws of ioctl().
<phschafft>
so it would be nice to just not repeat the same errors.
<nephele>
BMessage in that sense is a transport. It would have to go along with an api description you can use to interact with it (i.e something that lists the possible message types for this specific interface)
<nephele>
I guess the classic header file with enums in it :?
mmu_man has quit [Ping timeout: 480 seconds]
<phschafft>
and exactly that is the biggest flaw in ioctl().
<nephele>
Okay. So Webkit uses *make* instead of ninja
<nephele>
because it also uses which instead of command -v implicitly
<nephele>
and doesn't check if which even exists
cassisian has joined #haiku
cassisian has quit [Ping timeout: 480 seconds]
cassisian has joined #haiku
cassisia_ has joined #haiku
cassisi__ has joined #haiku
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
<phschafft>
I... actually corrected my typo before posting.
<Begasus[m]>
there is probably a typo in there* :P
<nephele>
phschafft: yes, that would be an option
<nephele>
if which doesn't exist use command -v... but at that point one could just use command -v
<phschafft>
at this point people could stop using echo ;)
<phschafft>
but they don't.
<nephele>
echo?
<phschafft>
so just conider this: every time you want someone use command -v you kill one use of echo.
<phschafft>
echo in shell scripts is deprecated for... a long time.
<nephele>
how so? it's specified in posix
<phschafft>
and it is broken and non-portable and has many problems. all of them are solved by printf.
<nephele>
it's specified in posix, therefore it is portable .-.
<phschafft>
just because it is in POSIX doesn't mean it's not deprecated... in POSIX or other standards.
<phschafft>
no, it is portable between POSIX conforming shells. not between 'looks a bit like a POSIX shell'-shells.
<nephele>
so?
<nephele>
don't use non-posix shells if you want to write a posix shell script
<phschafft>
so shellscripts break at times.
<phschafft>
people do.
<nephele>
not a shell script problem imo
<phschafft>
like. they use bash and don't declare their scripts as requiring specifically bash.
<phschafft>
so if you use echo you MUST tell *exactly* which shell you want to use.
<phschafft>
as there is no perfectly safe subset.
<Hanicef[m]>
Echo has a ton of implementation-defined behavior in it that makes it behave very differently depending on the shell
<Hanicef[m]>
Or use printf :)
<phschafft>
or you can use printf and be happy what that it works in any posix-alike shell the same way.
<nephele>
unless it doesn't, because your shell doesn't follow the posix standard... not posix confirming is just that, not conforming... all bets are off at that point
<phschafft>
my shell?
<nephele>
the shell you as a user would use. the ones you specified above
cassisia_ has joined #haiku
<Hanicef[m]>
Posix compliance is universal enough for that not to be a problem - i don't know a single system that doesn't use a posix-compatible shell as sh
<nephele>
If your shell is posix conformant you can use echo, if it isn't then it doesn't matter either, because you don't have a posix shell interpreter anymore
<phschafft>
nephele: I have never seen a shell and/or system combination that remotely claims to be posix-alike and didn't have a printf that was way more portable than echo.
<phschafft>
echo IS broken in reality. printf IS NOT broken in reality.
<nephele>
doesn't matter. You are arguing on the basis of heuristics. If you want somethign portable you need something like POSIX
<Hanicef[m]>
And then you run into issues even if both are compliant, since echo is very implementation-defined by spec
<phschafft>
nephele: and POSIX tells you to use printf.
<Hanicef[m]>
Let me link ogbs instead
<phschafft>
but, let's face it. by your definition POSIX is useless paper because nobody actually implements it.
<nephele>
It doesn't. It only sais printf *can* emulate echo, not that you have to use it
<phschafft>
I really don't see why you try to be boolean here. printf is recommended and works. echo is deprecated because it does not work.
<phschafft>
so why discuss?
<nephele>
there is no deprecation
<nephele>
and there is no point in changing scripts that use echo now and work fine
<Hanicef[m]>
No, but it warns about portability issues
<nephele>
(that is, working within the confines of where echo is portable)
<Hanicef[m]>
"It is not possible to use echo portably across all POSIX systems unless escape sequences are omitted"
<Hanicef[m]>
Quoted straight from spec
<phschafft>
nephele: unless they break randomly....
<nephele>
I have read the same page Hanicef[m]
<nephele>
the "unless" part is important
<phschafft>
wo why not keep using which. works fine for me. never not worked for me! no need for scripts to be changed.
<nephele>
which isn't posix, echo is :P
<phschafft>
doesn't matter. works fine for me. so why should I update stuff?
<nephele>
You shouldn't?
<Hanicef[m]>
Ah yes, let's all keep using dos
<phschafft>
I remind you the next time you discuss about which.
<nephele>
If you have DOS software running on a DOS enviroment, then you can just keep using that. It has no bearing to posix shell scripts
<phschafft>
and never ever consider to move to anything than this one gcc 2.95 binary that is around!
cassisian has quit [Ping timeout: 480 seconds]
<nephele>
you have a bad case of whataboutism phschafft :)
<phschafft>
I just don't understand why you are always so fixed on the standard when it's about keeping bad code bad.
<phschafft>
as long as any standard has any kind of tiny hole that maybe keeps some bad pattern remotly valid you seem to be very strongly on keeping it bad.
<nephele>
You argue that one should displace old echo invocations, I argue that it doesn't make sense to do. If you want your code to be portable and you do use escape sequences, then yes you should use printf. But if your code *only* prints diagnostic messages with echo like "Enabled FeatureX" then there is no reason to go back and "fix" this, even if it can be done another way
<x512[m]>
> we shouldn't have a libx11 at all
<phschafft>
I really don't get you at times.
<x512[m]>
Why? It may be useful to run real X11 server sometimes.
<x512[m]>
Xlibe have compatibility problems.
<nephele>
x512[m]: add "enabled in haikuports" to that sentence, which was the context in which that sentence was spoken...
<x512[m]>
Disable recipe in HaikuPorts means that no libx11 will be built, no?
<Begasus[m]>
argh .. glib2 < 2.80 is blocking me ...
<nephele>
Yes. it does. If you have a XServer you want to test with you can just enable and test it then. The libx11 as it is now is worthless because it does not give users a working application, and that is primarily what haikuports is for
cassisia_ has quit [Remote host closed the connection]
<Begasus[m]>
libx11/xlibe is used for more then just a x-server?
<nephele>
Begasus[m]: those two are different libraries
<Begasus[m]>
so, it serves it's purpose for what it is around atm*
<Begasus[m]>
libX11 is disabled in favor of xlibe afaik
<Begasus[m]>
lol kallisti5 another one? :)
vdamewood has joined #haiku
<kallisti5[m]>
Begasus: oh... the jsoncpp one?
<kallisti5[m]>
yeah lol... at least haikuporter is detecting it now... except a lot of stuff depends on ninja / cmake / meson so a lot of stuff fails to build because of it :-)
<Begasus[m]>
emm ... cmake/ninja have no related dependency?
<nephele>
oh noes, i just fixed my webkit build to use ninja again xD
<Begasus[m]>
raptor doesn't use cmake/ninja?
<nephele>
why is there no macro for cmake in haikuports that it can decide on it's own to use ninja, unless it isn't available and then fall back to cmake
<Begasus[m]>
kallisti5: why does meson require ninja?
<Begasus[m]>
cmake -G Ninja?
<kallisti5[m]>
hm.. unsure. looking
<Begasus[m]>
it defaults to GNU Makefiles (cmake)
<kallisti5[m]>
0b1ec74715 dev-util/meson/meson-0.44.0.recipe (Alexander von Gluck IV 2018-02-05 18:39:11 -0600 27) cmd:ninja >= 1.6
<kallisti5[m]>
LOL
<kallisti5[m]>
what an idiot
<Begasus[m]>
rofl
<kallisti5[m]>
I think back on 0.44.0 it was a requirement
<Begasus[m]>
also in ninja: haiku${secondaryArchSuffix}_devel >= r1~alpha4_pm_hrev51418-1 :P
<kallisti5[m]>
we're at 1.8.2 now... so yeah
<Begasus[m]>
at least not in the build kallisti5 no mention there
<kallisti5[m]>
good call on ninja in meson
<Habbie>
14:37:46 Begasus[m] | kallisti5: why does meson require ninja?
<Habbie>
because that's the backend meson writes files for
<kallisti5[m]>
right.. but does meson need ninja at compile?
<Habbie>
at compile of what?
<kallisti5[m]>
or is it only at runtime?
<kallisti5[m]>
does meson need ninja while meson is being compiled
<Habbie>
meson is python
<Habbie>
it is not compiled
<Begasus[m]>
ohwell, jsoncpp could be updated
<Begasus[m]>
ninja only runtime dep for meson
<Habbie>
(and test dep)
<Begasus[m]>
ah, well it could go to TEST_REQUIRES then
cassisian has joined #haiku
<Habbie>
it's in both
<Habbie>
which seems right to me
<Habbie>
well, unless you want to replace ninja with something like samurai
<Habbie>
but that's not common
<Begasus[m]>
right, my bad there
<Habbie>
(you can also replace meson with muon, etc., but in general I would stick to meson+ninja for such projects)
<Begasus[m]>
I know they go hand in hand
<Begasus[m]>
but like with cmake, we don't make a runtime dependency for make or ninja
<Habbie>
cmake gives you choice, right?
<Habbie>
i can understand not having the runtime dep, just the test dep
<Begasus[m]>
yeah
<Habbie>
but 99% of users will do it anyway
<Begasus[m]>
projects using meson should already have ninja in BUILD_PREREQUIRES atm
<Habbie>
i was just about to say
<Habbie>
that's what you then get
<Habbie>
everywhere you type meson you also need to type ninja
<Begasus[m]>
right, so makes having it in the meson REQURES a bit obsolete
<Begasus[m]>
even if it's the default backend
<Habbie>
yes. or, indeed, the other way around - meson requires ninja, and you don't need to type both everywhere
<Begasus[m]>
as it is now, it is required for meson
<Habbie>
ack
<Habbie>
probably simplest
<Begasus[m]>
leaves me to think if we can just leave it out in other projects using meson?
<Habbie>
would be my choice
* Begasus[m]
needs some quicky to check :)
<Begasus[m]>
yep, serd build without it in BUILD_PREREQUIRES
cassisian has quit [Ping timeout: 480 seconds]
<Begasus[m]>
now*
<Begasus[m]>
doesn't solve the mentioned issue though, I guess, as it is still a indirect dependency
<zard>
Ok, so, when I enter the URL and press Go, it doesn't seem to do anything
<zard>
If I then click on the blank page, it starts loading the page
<zard>
Actually, if anything causes any region of the window to update, it loads the page, so even moving the window onto/off of the edge of the screen works
mmu_man has quit [Ping timeout: 480 seconds]
<nephele>
hmm, that still seems a bit wrong then ?
<nephele>
zard: by the way, do you know if there is another mechniam that has to be implemented? I got webkeyboard event webwheelevent and webmousevent implemented, but i still can't type into text fields... in webkitlegacy there is a "input" event in jascript space with a "inserttext" field set to the letter i pressed on the keyboard, but that is not there in webkit2
<zard>
Yeah, that behaviour is still not entirely correct
* zard
is looking for anything obvious related to keyboard events
<nephele>
i'm looking at handleEditingKeyboardEvent right now zard
<nephele>
maybe that is related
<nephele>
it's implemented in wk1 but not wk2
<zard>
I wonder if its related to the window not being focused? (I don't have your patches yet. Did you fix that?)
<nephele>
Yes, i did fix that
<nephele>
I now have the view focused and the in-webview textfiel also shows it is focused
<zard>
Ok, gotta get your patches then :-)
<nephele>
I have not uploaded that one yet
<nephele>
I can try this git binary patch theBuck mentioned
<nephele>
codeberg seems to not be ready with their size limit stuff yet...
<zard>
I see your code implements WebEventFactory::createWebKeyboardEvent
<zard>
That's what I was looking for when you mentioned the keyboard not working
<zard>
Certainly, IIRC, to get the mouse working I just had to implement WebEventFactory::createMouseEvent and the related code around that
<zard>
Actually, let me find the commit...
<nephele>
no need zard
<nephele>
i used your commit as a pointer to figure out how to implement the keyboard :)
<nephele>
and the keyboard events arrive in javascript land, so that part seems entirely correct
<nephele>
i now believe that this editing stuff is required, so am working on that next
<zard>
Ah, well if it reaches JavaScript, then you're entirely outside my area of expertise
<zard>
`Repository lacks these prerequisite commits:` My fork is already out of date!
<nephele>
sorry, i git pulled today since PulkoMandy updated the upstream webkit2 branch :D
<zard>
Aaaand, I did a `git reset --hard` without stashing my changes first :/
<nephele>
ouch :(
<zard>
let's look in the reflog...
<zard>
because I have stashed it before
<PulkoMandy>
I hope the fix I pushed today works (pushed it from my linux work machine so I can test it at home)
<nephele>
PulkoMandy: build fix you mean? well it build fine for me, so i would reckon it works
<PulkoMandy>
nephele: I think the standard forms/textarea don't use javascript keyboard events. So you may need to look at EditorClientHaiku.cpp instead and make sure that is used in the webkit2 port
<nephele>
PulkoMandy: excelent, that is what i am looking at. There is a WebPage::handleEditngKeyboardEvent function that is unimplemented but is implemented in webkitlegacy
<PulkoMandy>
nephele: The old code was building fine too, but the implementation wasn't correct. It's just for detecting when we're low on memory and clearing some things, so it shouldn't make a huge difference
<nephele>
I am trying to suplant the implementation. Curiously enough it deals with the windows virtual keycode instead of "just" using ours... wierd...
<PulkoMandy>
maybe internet explorer implemeted this first and now every browser has to se windows keycodes?
<nephele>
Well, the thing is the WebKeyboardEvent carries severall "views" of these keycodes. but this function is a native function in our code, and it does decisions based on the windows keycode, but it would probably be clearer if we were dealing with our keycodes instead
<nephele>
i.e it does things like "case VK_DOWN" dealing with the windows keycode, where it probably could have used the haiku code instead
<nephele>
but regardless, the previous code works in wkl, so now trying to figure out how to suplant it... some classes are named differently and members of classes so this needs some adjustments
<PulkoMandy>
This code went through many years of me rebasing things and doing the minimum work to get them building again
<PulkoMandy>
Cleanups are welcome :)
deneel has joined #haiku
<nephele>
PulkoMandy: I'm quite happy that i can work on doing this properly right now :)
<zardshard>
Yeah, make our code less messy! :-D
<nephele>
the only thing annoying is the compiler with it's questions like "did you forget the '()'"? yes i did forget! but don't remind me xD
zard has quit [Read error: Connection reset by peer]
<zardshard>
Well, going to have to recover my uncommited changes later
<zardshard>
Until later!
<nephele>
PulkoMandy: okay. Got it :)
<nephele>
i can now write into text fields
<nephele>
I should probably clean this up regardless. It would give me the huge advantage, of understanding this code :D
scantysnax has joined #haiku
<scantysnax>
good morning, good afternoon, good evening, and good night :-)
mmu_man has joined #haiku
<nephele>
hi scantysnax
<scantysnax>
hello there nephele. what's new and exciting?
<scantysnax>
i was thinking i would like to try to add a "home" button for tracker windows.
<scantysnax>
(in single window mode)
<nephele>
i fixed text input in webkit2 scantysnax
<scantysnax>
oh cool, i remember you were having some problems with it recently.
<nephele>
That one problem is now fixed :)
<scantysnax>
how far are we away from webkit2?
<nephele>
depends on how much time i have for it :P
<scantysnax>
i see...
<nephele>
there is still a couple things to fix before i consider "basic" functionality to be done, that ought to take a couple more weeks atleast
<nephele>
like websettings, zooming into the page, context menu etc
<scantysnax>
so it's a big undertakingi presume?
<scantysnax>
undertaking*
<nephele>
let's say that it simply requires some more work
<scantysnax>
gotcha. well, good luck! I hope you make some real good progress.
janking has quit [Quit: Vision[]: i've been blurred!]
<Begasus[m]>
hi scanty
<scantysnax>
hi Begasus[m], how are you today?
<Begasus[m]>
can't complain, you?
<scantysnax>
eh, same
<Begasus[m]>
glib2 is giving me a headache :)
janking has joined #haiku
<scantysnax>
i think GNUBG uses glib
<scantysnax>
something i would love to have on haiku
<scantysnax>
if there are resources for compiling GTK apps for Haiku, that would be helpful.
<Begasus[m]>
glib is used in many places :)
<Begasus[m]>
GTK3 is there
<scantysnax>
yes, but I think the one in the depot is 2.78, which is too old to build gnubg
<scantysnax>
(glib)
<Begasus[m]>
right, my pain also atm, can't even bump to lowest 2.80
<scantysnax>
i see.... to compile gnubg i need at least 2.80
<scantysnax>
afair
<Begasus[m]>
2.85 is way off in the patchsett
<Begasus[m]>
yeah, 2.80 seems pretty common there
<scantysnax>
well, if you succeed with glib, definitely let me know.
<scantysnax>
gnubg is the only thing i am missing on haiku. everything else i need, i have.
<Begasus[m]>
heh
mmu_man is now known as Guest21571
mmu_man has joined #haiku
<nephele>
PulkoMandy: do we have some documentation on the rules we use for shortcuts in TextFields? for example in the webkit code now holding control jumps back a word. but it doesn't seem to do so in haiku apps...
<erysdren>
probably just need to disable tests or something
<PulkoMandy>
nephele: Probably haiku was changed and webkit wasn't updated to match? I think there is no doc but you can check btextview sourcecode
<Begasus[m]>
or sed out the static library in that file if it doesn't exist?
<Begasus[m]>
erysdren: path is wrong there "lib/x86/x86/"
<erysdren>
ah
<erysdren>
i have no idea why. is that a problem with sdl3 itself?
<Begasus[m]>
yeah, in the libsdl3 recipe, probably needs a change in that sed magic there
<scantysnax>
eh, if you're using SDL, you're cheating ^_^
dqk_ has joined #haiku
<erysdren>
:P
<phschafft>
SDL seems popular today.
<erysdren>
i like SDL. i use it for most of my projects
<erysdren>
SDL3, that is
<scantysnax>
as you wish :-)
<nephele>
is "inline bool" a gurantee that the compiler will inline stuff?
<nephele>
i'm using this to try and simplify stuff of the sort of platformEvent->shiftKey() ? FrameSelection::Alteration::Extend : FrameSelection::Alteration::Move so i don't have to constantly retype this, and am sure each check is really the same...
<erysdren>
"inline" is never a guarantee, but it's a strong hint
janking has quit [Quit: Vision[]: i've been blurred!]
<phschafft>
gcc has a flag to force it IIRC.
janking has joined #haiku
<phschafft>
but generally speaking, if the compiler will not inline it with inline than it has a good reason.
dqk has quit [Ping timeout: 480 seconds]
<phschafft>
you may also want to set static to avoid a non-inlined copy.
AndrevS has joined #haiku
<Begasus[m]>
scanty: not doing much SDL for a long time, now playing a bit with this :) https://0x0.st/8GEU.png
<scantysnax>
looks nice :-)
<Begasus[m]>
anyway, closing time here
<Begasus[m]>
cu peeps!
<erysdren>
cya Begasus
<erysdren>
have a good day
<scantysnax>
seeya Begasus[m]
<scantysnax>
have a pleasant day, and say hi to the doggies!
r6fej has quit [Remote host closed the connection]
scantysnax has quit [Ping timeout: 480 seconds]
scantysnax has joined #haiku
<PulkoMandy>
nephele: Let the compiler decide. Mark the function static if it doesn't need to be exported outside of that file, other than that, the compiler knows better if it's a good idea to inline or not
r6fej has joined #haiku
* phschafft
nods.
Sid127 has quit [Read error: Connection reset by peer]
<phschafft>
I would generally say: 0) make as much stuff const as possible, 1) make as much stuff static as possible, 2) put things in the smallest possible scope. 3) refactor if things need change. 4) use rule of thumbs as rule of thumbs, don't use it as a holy sword to smite readability ;)
<nephele>
phschafft: in this case I want to do these "inline" functions to improve readability, cus webkit has these huge enums that are just deciding for 1 character or 1 word jumps and stuff like that
<nephele>
and everywhere the check is the same like "is ald held down?" so if i put that in a new function i also have the gurantee that i didn't screw up the check anywhere :)
* phschafft
nods.
Sid127 has joined #haiku
<phschafft>
the compiler will then figure out if it wants to inline them based on all it's wisdom.
<scantysnax>
inlines are weird. sometimes the compiler decides, even if you explicitly state it.
<phschafft>
the point is that sometimes it is e.g. smaller to not inline.
<phschafft>
or it might be faster
jmairboeck has joined #haiku
<nephele>
what is a .idl file?
<jmairboeck>
in Windows context this is for interface definition language, to define COM interfaces, IIRC
<nephele>
could be, yeah
janking has quit [Quit: Vision[]: i've been blurred!]
<nephele>
this is some files in WebKit/WebProcess/Extensions/Interfaces/ the linker complains about that it doesn't know what they are
<nephele>
(i would like to turn it off that it tries to link them so i don't have my stdout flooded with these...)
<scantysnax>
i hate linker errors.
<scantysnax>
sometimes they are hard to find.
<nephele>
In this case I am not even sure what the things are linked for... because the build suceeds regardless
<scantysnax>
that's interesting.
<scantysnax>
usually when there are linker errors, all bets are off, so i'm surprised that it compiles
<nephele>
do we have some apps that can do undo *and* redo?
<nephele>
I know Koder can
<nephele>
StyledEdit swiches on alt-z between undo and redoing one thing it seems
<nephele>
and Koder does alt-z for undo and alt-y for redor
<nephele>
and webpositive apparently used to do ctrl-z and ctrl-y for undo? and ctrl shift z and ctrl shift y for redo
<nephele>
or maybe these are supposed to be cmd there...
cassisian has joined #haiku
dalme has joined #haiku
<scantysnax>
i just use Pe and set my own shortcuts.
cassisi__ has quit [Ping timeout: 480 seconds]
<scantysnax>
i don't really bother with StyledEdit except for plain text notes.
<nephele>
I'm asking for shortcuts to implement in webkit :P
<scantysnax>
oh, my bad.
<scantysnax>
sorry!
<nephele>
zardshard: Any hints on how the threaded compositor thing has to be implemented?
<scantysnax>
we are getting a compositor?
neoncortex has joined #haiku
<nephele>
No
<nephele>
This is still webkit development scantysnax