<HaikuUser>
sorry guys, i need to leave, see you later
HaikuUser has quit [Quit: Vision[]: i've been blurred!]
<badkeming[m]>
o/
<badkeming[m]>
x512: Oooooh -- that looks _nice_
<badkeming[m]>
Are there any prerequisites/READMEs I need to consult before trying it?
rennj has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
Begasus has quit [Ping timeout: 480 seconds]
matt3 has left #haiku [#haiku]
rennj has joined #haiku
DKnoto has quit [Ping timeout: 480 seconds]
DKnoto has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
rennj has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
rennj has joined #haiku
rennj has quit [Ping timeout: 480 seconds]
matt3 has joined #haiku
maxace has joined #haiku
maxace has quit []
<xoblite>
waddlesplash , do you have a minute to discuss a rendering bug? (probably in app server, at least it seems like it)
<waddlesplash>
I'm not actually an app_server expert
<waddlesplash>
if you ask your question here though someone will answer at some point, though it may be a few hours
<xoblite>
ok here's how to replicate: set your bold font size to >= 15 in Appearance fonts preferences.
<xoblite>
from size 15 and above a gradually increasing non-drawn outline appears inside the window frame, as if the topView rect is not adapting properly
rennj has joined #haiku
<xoblite>
this non-drawn area gets covered in ghost pixels of various colour if you e.g. move another window back and forth over it.
<waddlesplash>
that's a known problem and there's tickets about it
<waddlesplash>
it's only a problem with non-default Decorators
<xoblite>
waddlesplash : the reason I asked you is that I think you were the main guy working on the scalable UI, correct?
<waddlesplash>
so I guess you are using the "flat" decorator or something
<xoblite>
ah ok, yes flat.
<waddlesplash>
the decorator code in app_server is spaghetti
<waddlesplash>
it was a nightmare patching it to scale the default decorator
<waddlesplash>
it really needs to be wholesale replaced
<xoblite>
why does the topView not adapt correctly though? or does the decorator set the size of the window border and hence the bounding rect of the topView?
<waddlesplash>
not that simple
<waddlesplash>
there's multiple layers of decorator classes, and one of them sets the size and another draws
<waddlesplash>
the "decorator" plugin only draws, and most of them don't check the set sizes
<waddlesplash>
like I said, it's spaghetti
<xoblite>
ok. I get the same ghost width on all sides though
<waddlesplash>
yeah, because the one class has assumed the window border will be a certain size, but then not all that area is drawn
<waddlesplash>
so there's a gap between the drawn area and the actual contents
<xoblite>
gotcha.
<waddlesplash>
someone who has a good intuitive grasp of graphics layout and abstraction should probably totally redesign the decorator interfaces
<waddlesplash>
that isn't me, I'm good with abstraction but graphics layout is one of my weaker points
<xoblite>
so the ticket is (mainly?) on the flat decorator, is that what you're saying?
<waddlesplash>
it's only the default one that works fully because it's the only one I fully patched after making initial adjustments
<xoblite>
yeah sure, I meant all decorators not being adaptive to border a la the default one?
<waddlesplash>
you can patch the other decorators the same way I changed the default one, to fix the immediate problem
<waddlesplash>
but like I said, major refactor needed
<xoblite>
mmm.
<xoblite>
btw I'm working on a major update to the Deskbar including lots of drawing fixes etc.
<waddlesplash>
if you're just doing drawing fixes that's fine
<matt3>
please, give me a feedback about tutorial ...
<xoblite>
maybe ready within a week
<waddlesplash>
but if you're making behavioral changes, expect a large bikeshed
<waddlesplash>
so, please do drawing fixes separately from any behavioral changes :)
<xoblite>
I won't push it to Gerrit this time around
<waddlesplash>
uh, why not?
<waddlesplash>
we do all review on Gerrit
<xoblite>
it needs user review first, you'll understand when you see it.
<waddlesplash>
uh, again, like PulkoMandy said, please ask before making genuine behavioral changes, because if there isn't agreement, you're just wasting time
<waddlesplash>
if you're fixing redraw problems or HiDPI miscalculations, that's fine of course
<waddlesplash>
or refactoring some of the code duplication...
<xoblite>
nah I can just release it as a separate app in that case; it can even co-exists with the regular Deskbar as is (or you could launch_roster stop the original if you so wish)
<xoblite>
both actually
<waddlesplash>
that's a very "linux" mentality
<waddlesplash>
here, we try to discuss things and come to an agreement if something should change or not, instead of just "forking" whenever someone wants something different
<x512[m]>
Decorator add-ons is difficult topic. It need ability to run as separate team and new IPC protocol.
<xoblite>
don't dismiss initiatives before you see the result, that's all I can say :)
<waddlesplash>
x512[m]: +1, and that's definitely related to abstraction
<waddlesplash>
xoblite: I'm criticizing your attitude here without seeing what you are working on, yes
<xoblite>
waddlesplash: same behaviour overall if you so wish btw.
<waddlesplash>
even if what you are working on is great and we all will like it immediately, my critique stands
matt3 has left #haiku [#haiku]
<x512[m]>
waddlesplash: It is free software mentality, not Linux. Everyone can fork, modify and publish free software.
<waddlesplash>
x512[m]: of course, I'm not denying that
<waddlesplash>
xoblite: I also don't get the mysteriousness. Why not just say what you are working on, so it can be discussed while it's still being worked on?
<xoblite>
x512[m]: exactly. that's how open source evolves. not everything can be discussed in theory, it needs to be tried out to know what works and what is implementable.
<waddlesplash>
of course not everything can be discussed in theory
<waddlesplash>
but that's no reason to unilaterally decide theory discussions are usless
<waddlesplash>
and, if you don't ask, how will you know this wasn't tried before?
<x512[m]>
Haiku review process is slow, so using private branches is essential for non trivial system development.
<waddlesplash>
yes, of course
<xoblite>
well, I understand now I should have kept the lid on until ready to present it including screenshots, description etc. Forget I mentioned it ;)
<waddlesplash>
uh, no, that's exactly the opposite?
<waddlesplash>
I'm saying, be more open, not less
<waddlesplash>
allowing feedback before something is actually completed or the like will allow people to think about it and suggest improvements, saving everyone time and making a better end result from the start
<waddlesplash>
there's been plenty of examples where developers with trunk commit access, myself included, do exactly this to "test the waters" and think in common, instead of separately
<xoblite>
what I meant is I spoke about it before I had assembled the material to show it off. I can send the code over if you so wish, but it'll be more finished in a few days.
<waddlesplash>
code matters less, review takes care of the technical side
<waddlesplash>
of more relevance is: what is the change, and why do you think it valuable? that's what's worth discussing.
<xoblite>
forgive me saying so, but there are a lot of preconceived ideas about how things should be, so sometimes you need to show another way and then have a discussion around it. or, as mentioned, allow both legacy and new behaviour and let the user decide.
<waddlesplash>
on the contrary, we actually have very few *preconceived* ideas about "how things should be"
<waddlesplash>
we have opinions about how things should be, oh yes, but they're not "preconceived"
<xoblite>
my deskbar update can have the exact same behaviour if you want it to.
<waddlesplash>
they can and are changed when new reasons come along
<waddlesplash>
well, that's great, but I want to know what the change is and why you think it's valuable
<xoblite>
note: I'm not talking about you or anyone in particular.
<waddlesplash>
not so I can "prove you wrong," but maybe because you actually do have real improvements
<waddlesplash>
jscipione a few years back totally redid "Mini Mode" and I think a lot of users wound up liking the new version a whole lot
<xoblite>
you just need to be on the forums for a while to realize there are a zillion view out there.
<waddlesplash>
so, Deskbar isn't some static thing since the 90s, it has seen real changes
<waddlesplash>
xoblite: I have been on the forums for over 10 years now, I'm quite aware lol
<waddlesplash>
but there being "a zillion views" doesn't mean a broad consensus is impossible, at all
<xoblite>
ehh, Deskbar has changed UX-wise? really?
<waddlesplash>
uh, yes!
<waddlesplash>
and so has Tracker for that matter, too
<x512[m]>
xoblite: Of course you can have forked Haiku repo on GitHub etc. with customized Deskbar.
<xoblite>
lol if you say so :)
<waddlesplash>
see? you should ask these things, there's history!
<waddlesplash>
xoblite: go try BeOS R5 in a VM sometime
HaikuUser has joined #haiku
HaikuUser has quit []
<waddlesplash>
you will rapidly see that, however reminiscent of the 90s they are, there have been significant changes to both Tracker and Deskbar
<xoblite>
I'm not at all interested in forking Haiku. if no one likes my evolved Deskbar, it could be just another app on HaikuDepot and/or my GitHub, that simple.
<xoblite>
waddlesplash : thanks, I'll read it later. Have already read through all the Glass Elevator stuff too.
bbjimmy has joined #haiku
<waddlesplash>
xoblite: oh, another big one: "zoom" (which behaves like "maximize" in many applications) respects Deskbar size unless you hold Shift
<waddlesplash>
in the BeOS days, and until about 2-3 years ago in Haiku, it covered up Deskbar, which made a Deskbar placed anywhere other than the default in the top right basically useless
<x512[m]>
xoblite: In that case you need separate Deskbar from Haiku build system.
<waddlesplash>
x512[m]: deskbar used to be separate from the build system anyway
<waddlesplash>
so extracting it isn't likely very difficult, Tracker would be the trickier extract
<x512[m]>
Really? How to build Deskbar without having whole Haiku source tree?
<xoblite>
waddlesplash : yes I'm aware of the zoom issue; I'm not sure it should pay attention to the Deskbar frame at all tbh, but haven't looked into it.
<waddlesplash>
x512[m]: well you'll need to write a Makefile, and adjust some header paths to use private system headers instead of local
<waddlesplash>
otherwise, not really hard to extract it
<waddlesplash>
xoblite: it already has an optional mode not to like I said: hold Shift while clicking Zoom button
<waddlesplash>
it will then expand all the way
Zor-Prime[m] has joined #haiku
<waddlesplash>
personally, I usually put Deskbar at the bottom of the screen due to years of Windows muscle memory, so I never use that
<waddlesplash>
well, at least on bare metal installs. I guess all my VM installs I leave Deskbar in the default positio
<xoblite>
x512[m]: of course I have the full source tree, but I have not made any changes elsewhere for this update, or (in places) have implemented locally in Deskbar to avoid system changes.
<x512[m]>
I think that it is fine if someone will extract and fork some Haiku components. It it will gain popularity, it can be integrated back to base system.
<xoblite>
(this image will self-destruct in 10 minues? ;))
<xoblite>
waddlesplash : see link above, especially for you... :)
<waddlesplash>
not so sure about the new coloring
<waddlesplash>
although maybe that's just your own system preferences?
<waddlesplash>
looks interesting though, we'll see what everyone else says. I'm skeptical of the additional borders, I don't think those will have much merit at least...
<xoblite>
nah it started out Haiku blue just as a way for me to distinguish it from the regular Deskbar :)
<xoblite>
all padding follows system metrics btw.
<xoblite>
so it scales nicely.
<xoblite>
there are some more things I can't show in a simple screenshot yet; maybe later during the week.
<xoblite>
the numbers before each window item is the workspace they're on by the way. _ is minimzed, * is on all workspaces.
<xoblite>
the one in blue rect in the title is the current workspace.
<xoblite>
of course, you can choose to have the legacy generic icons instead, or no bullet at all i.e. text only.
<xoblite>
(new drop-down menu in deskbar prefs)
BrunoSpr has joined #haiku
<xoblite>
waddlesplash : I guess all maintainers are primarily on x64 btw?
<waddlesplash>
probably, why?
<xoblite>
(may bundle up source and binary for the preview)
<xoblite>
you can compile it of course, but many can't.
<xoblite>
btw anyone in here who's knowledgeable in the GLView stuff?
BrunoSpr has quit []
<xoblite>
(I have a small ask, could maybe fix it myself but haven't looked at the backend code yet)
<xoblite>
it's simple: GLView initiate as white, when it should be black to avoid startup flash flicker.
<xoblite>
(could be it's not even drawn as the GL view will soon take over.)
<x512[m]>
> btw anyone in here who's knowledgeable in the GLView stuff?
<x512[m]>
Me.
<xoblite>
:)
<x512[m]>
I plan to drop current BGLView implementation and use wrapper over EGL instead.
<xoblite>
same API for apps though?
<x512[m]>
Current BGLView is located in Mesa.
<xoblite>
.e. backwards compatible?
<x512[m]>
Yes, new BGLView is API/ABI compatible with old one.
<xoblite>
my ask is from the GLTeapot evo perspective; it's something I want to get done but I'm not going to rework the GL stuff.
<xoblite>
perfect!
<xoblite>
so can you make it initialized as black too then? :)
<xoblite>
btw I can volunteer to test if you want
<xoblite>
:)
<x512[m]>
Default color selection is not trivial. Some OpenGL applications may use white background color.
<xoblite>
I meant for the underlying BView ?
<x512[m]>
Maybe it can be changed with BGLView::SetLowColor/SetViewColor?
<xoblite>
I think it may skip drawing currently even, as the child GLView will anyway be drawn over it once initialized.
<xoblite>
could be, I haven't digged into it yet, just something I notice every time I launch my updated app...
<x512[m]>
New BGLView implementation also currently have default white background color.
<xoblite>
(ditched DirectWindow for now too btw, seems too flaky for now (?))
<xoblite>
ok, but I can change it to black before added to window you mean?
HaikuUser has joined #haiku
<xoblite>
i.e. it would respond to SetViewColor() or similar?
<x512[m]>
BDirectWindow concept is mostly obsolete for now.
<x512[m]>
New GPUs prefer buffer flipping on screen update that will not work with BDirectWindow.
<xoblite>
yeah figured as much.
HaikuUser has quit []
<xoblite>
are you on x64 too btw?
<x512[m]>
Mostly on x86_64 but also have 32 bit install dual boot.
Begasus has joined #haiku
matt3 has joined #haiku
<Begasus>
waddlesplash, disabled X11 for now on R, build is now OK on buildmaster, I think mooes also mentioned some wip on that, at least for now it fails to build with xcairo
matt3 has left #haiku [#haiku]
<Begasus>
heading out again, cu later
<xoblite>
x512[m]: sorry, I must ask: how many alter egos do you have in the Haiku community? (or have I interpreted it wrong? there's at least a 547 iirc?)
<x512[m]>
X512 everywhere, X547 on GitHub.
<xoblite>
ah, gotcha.
<xoblite>
thanks for clarifying.
<xoblite>
oh btw, here's something I was going to put on the forums at some point: Choice of app signature prefix for ported applications.
<xoblite>
basically, we all go with x-vnd.something for our apps, but while working on the Deskbar update it occured to me it would be nice if there was a dead simple way to detect native vs ported apps.
<xoblite>
for example, use x-gtk.something for GTK ports, and x-qt.something for QT ports.
<xoblite>
whatcha think?
<xoblite>
...this way you could easily sort apps by type etc.
<xoblite>
(our use of x-vnd is non-standard and arbitrary anyway btw.)
<x512[m]>
xoblite: GTK applications have its own signatures that can be used.
<xoblite>
yes but not of uniform nature right? I wouldn't want to have a list with every app signature out there, so the idea was that by having a "standardized" prefix like x-gtk.... it would be much easier to utilize.
<x512[m]>
x-vnd is a part on MIME standard that means MIME type is vendor-specific and not registered.
<x512[m]>
x-gtk is a bad idea.
<xoblite>
well, it was afai remember, not any longer
<xoblite>
hmm explain?
<x512[m]>
"application/x-vnd." part is fixed and should be not changed.
<xoblite>
"Media types in this tree cannot be registered. According to RFC 6838 (published in January 2013), any use of types in the unregistered tree is strongly discouraged. In addition, subtypes prefixed with x- or X- are no longer considered to be members of this tree. According to obsoleted RFC 2048 (published in November 1996)—it should rarely, if ever, be necessary to use unregistered types, and as such use of any x., x- or X- prefixes
<xoblite>
is discouraged. Obsoleted RFC 1590 (published in September 1993) stated that the use of the x- or X- prefix may be used for unregistered subtypes. Media types that have been widely deployed (with a subtype prefixed with x- or X-) without being registered, should be, if possible, re-registered with a proper prefixed subtype. If this is not possible, the media type can, after an approval by both the media types reviewer and the IESG, be
<xoblite>
registered in the standards tree with its unprefixed subtype."
<xoblite>
...so our use of x-vnd.something is not in line with standards anyway as I understand it, and thereby something like application/x-gtk.something is equally "bad" (?).
<phschafft>
yes, that should als be 'x.' ...
<xoblite>
could of course make it application/x-vnd.gtk-vendor-app or similar too.
<phschafft>
e.g. 'x.vnd.bla'
<xoblite>
point is to make ported apps very easily searchable just using strcmp on signatures.
<x512[m]>
It should be done with tags or some similar method, not MIME signatures.
<xoblite>
strncmp that is, we're not going to care about the part beyond gtk- here.
<x512[m]>
It is planned to automatically assign MIME signatures for Wayland applications.
<xoblite>
hmm, tags
<xoblite>
?
<xoblite>
(I'm not yet up to speed on all things Haiku)
<OscarL>
After a quick read of the logs... people seem to have forgoten that "modified Deskbar" (and "modified Tracker", for that matter) was actually "a thing" in the "not so long ago, damn it!" past: https://github.com/HaikuArchives/DockBert
<OscarL>
augiedoggie: true, but NaviTracker always felt less alien than Seeker :-D
<OscarL>
PCManFM would be my other choice, if it wasnt for having so many dependencies... and being TRULY alien :-P
rennj has joined #haiku
DrachenMaus[m] has quit [Ping timeout: 480 seconds]
<OscarL>
Seeing Seeker mentioned... I wonder what Darkwyrm's life looks like these days... Hopefully his physical issues went away for good (he suffered from carpal tunnel syndrom back then, IIRC).
DragonMaus[m] has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
HaikuUser has joined #haiku
HaikuUser has quit []
mmu_man has joined #haiku
matt3 has joined #haiku
<OscarL>
Hey there matt3.
<OscarL>
I think that with some minor tweaks, your tuturial can become a handy guide for newer users that learn better from visual guides.
DragonMaus[m] has quit [Ping timeout: 480 seconds]
<OscarL>
As beta4 is just released, and (at least for now) has few difference with nightlies, it might be good to point to the beta4 ISO first for download (after all... that's what the buildmaster for the Haikuports are using anyway).
Begasus has joined #haiku
<matt3>
thank you very much, but very much ...
<OscarL>
matt3: the "flash your usb pen" also could use a bit more explanation (remember... intended audience is not people here in the IRC... but truly new users that might don't even know what tools to use for that).
<matt3>
you can use my tutorial as you want ...
<matt3>
free doc
<OscarL>
matt3: that might also explain why you haven't got much feedback here too :-) (we're most likely not the intended audience for such tutorial... even if it can be indeed be most welcomed by other users)
catbox has quit [Ping timeout: 480 seconds]
<OscarL>
matt3: just providing some small feedback here, so you know that you're being read at least :-)
<cocobean>
x512: New VStream build now looks for /dev/shm.... and the accelerant2/radeon_gfx.accelerant build (supplements radeonhd.accelerant or replaces?)
DragonMaus[m] has joined #haiku
<OscarL>
matt3: also... hoping you're felling well, all things considered.
<x512[m]>
Can be built with build_package RadeonGfx/radeon_gfx.accelerant.
<matt3>
my little contribution to a free world ;)
<cocobean>
Does/Can it replace radeonhd.accelerant?
<OscarL>
dunes are made of tiny grain of sand after all, matt3! :-) (at least that's how I like to see my tiny contributions :-D)
<x512[m]>
It use different API. Currently framebuffer.accelerant shuld be used for app_server.
<cocobean>
ok
<matt3>
true ... i feel very well with free software => freedom, yes a litle grain of marble ;)
Begasus has quit [Quit: Leaving]
catbox has joined #haiku
<OscarL>
And... Begasus is gone before I could write my message to him :-D
<matt3>
i live with people like you OscarL => good boy that say the true and say me bravo ...
<x512[m]>
radeon_gfx.accelerant is currently used by libdrm.so.
<OscarL>
for what it's worth matt3... I *think* I understand you... even if sometimes parsing your message requires some work :-D
<OscarL>
(I guess many feel similar regarding to my writing, so... oh well)... I'll leave the room for the grown ups to talk about programming and such :-).... be well, all Haiku folks!
OscarL has quit [Quit: "I'll be back"]
DragonMaus[m] has quit [Ping timeout: 480 seconds]
<matt3>
I'm encryptic I know... result of years alone ... tell oscar late ... please ...
DragonMaus[m] has joined #haiku
<matt3>
to heal it is enough to be understood ... but before science, feelings => it is enough to find friends and love each other
gouchi has quit [Remote host closed the connection]
<matt3>
that's why I always say peace and good
<matt3>
the worst thing is double meanings ... but then ask ...
catbox has quit [Remote host closed the connection]
<matt3>
cu later ...
matt3 has left #haiku [#haiku]
HaikuUser has joined #haiku
HaikuUser is now known as Idaho06
<Idaho06>
Hello! testing
Idaho06 has quit []
cocobean has quit [Remote host closed the connection]
matt3 has joined #haiku
tuaris has quit [Read error: Connection reset by peer]
S1Nx81 has joined #haiku
<S1Nx81>
hi all
<matt3>
hi
rennj has quit [Ping timeout: 480 seconds]
DragonMaus[m] has quit [Ping timeout: 480 seconds]
matt3 has left #haiku [#haiku]
DragonMaus[m] has joined #haiku
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rennj has joined #haiku
<S1Nx81>
sadly Web does not offer sufficant performace on Haiku to play web games
<S1Nx81>
discord browser client seems to work fine tho
x10z has joined #haiku
<S1Nx81>
qobuz web player does not work ether
<S1Nx81>
likely due to Web not haveing playback for protected content enabled/available it seems ?
S1Nx81 has quit [Quit: Vision[]: i've been blurred!]
DragonMaus[m] has quit [Ping timeout: 480 seconds]
rennj has quit [Ping timeout: 480 seconds]
DragonMaus[m] has joined #haiku
rennj has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
HaikuUser has quit []
dcatt has joined #haiku
HaikuUser has joined #haiku
HaikuUser has quit []
dby has joined #haiku
<bbjimmy>
Why would "kill pid" not kill the process with the pid?
<bbjimmy>
This may be part of the problem with Web leaking memory and processes
<bbjimmy>
The kill command returns with no error, but the process is not removed.
rennj has quit [Ping timeout: 480 seconds]
dby has quit []
x10z has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bbjimmy has quit [Quit: Vision[]: i've been blurred!]
<Zor-Prime[m]>
If I play a video on YouTube in Web things are great until I maximize the window, then there's notable frame loss. Audio stays synced, tho.
bbjimmy has joined #haiku
<bbjimmy>
I can kill the process with ProcessController or Team monitor
rennj has joined #haiku
dcatt has quit [Quit: Vision[]: i've been blurred!]
rennj has quit [Ping timeout: 480 seconds]
<bbjimmy>
~/Desktop> pidof WebKitWebProcess
<bbjimmy>
4566
<bbjimmy>
~/Desktop> kill 4566
<bbjimmy>
~/Desktop> pidof WebKitWebProcess
<bbjimmy>
4566
<bbjimmy>
~/Desktop>
rennj has joined #haiku
DragonMaus[m] has quit [Ping timeout: 480 seconds]