<botifico-c849d97b>
[haikuports/haikuports] Begasus 5c83dd4 - musescore, revbump for libsndfile (#8422)
<win8linux[m]>
Begasus, are there any directories that are both read-writable and removed automatically when a package is uninstalled?
<Begasus>
Don't think so, mostly settings etc are being left behind
<win8linux[m]>
BetterSpades source code can load data and configs from an external dir (used for Android), but they have to all be in one dir.
<Begasus>
got 172 items (directories and files) in ~/config/settings from things installed/checked already ;)
<Begasus>
should clean some things up there some time ...
<win8linux[m]>
Prolly not ideal to leave behind game data in a settings folder, but at this point it's possibly the only way to get the game launching via Deskbar.
<win8linux[m]>
Well, barring more extensive changes to the code.
<Begasus>
Can't you package all in $appsDir?
<Begasus>
or data in $dataDir?
<win8linux[m]>
Is that read-writable?
<Begasus>
nope
<win8linux[m]>
The game typically loads data and config from the same dir as the executable.
<win8linux[m]>
For the config, it needs R/W to save settings.
mmu_man has joined #haiku
<Begasus>
k, then put game and data in $appsDir, config in $settingsDir?
<win8linux[m]>
That's the current state of the recipe:
<botifico-c849d97b>
[haikuports/haikuports] Begasus 4ca3293 - audacity, revbump for libsndfile (#8425)
<trungnt2910[m]>
Which part of app_server is currently responsible for forwarding commands to a remote client? Is it technically reasonable to move that part to forwarding Layers instead with app_server's current design?
<x512[m]>
*HWInterface objects represents app_server display output interface. It can be local hardware screen (AccelerantHWInterface), nested window inside another app_server (ViewHWInterface) or remote desktop (RemoteHWInterface).
<x512[m]>
All of them currently assume an output of whole screen.
<x512[m]>
Haiku app_server use classical non-compositing region-based drawing model. Each pixel on screen is belong to some single window or screen background and if app_server need to get contents of some pixels region, it send invalidate requests to windows that own pixels containing requested region. Region of pixels is represented by BRegion object. Each window have visible region so all drawing is clipped with it. Multiple windows are drawn in
<x512[m]>
parallel, there are client-server thread pair for each window. Visible regions of each window never overlap so it safe to draw each window independently of each other in parallel.
<x512[m]>
For per-window desktop it is needed to detach windows from Desktop visible region calculation and provide separate window object in remote desktop protocol.
Anarchos has joined #haiku
<mbrumbelow[m]>
<shaka444[m]> "Whoa, is this intentional..." <- Only what is on the desktop should be displayed. system, config and RAM FS should not be on the desktop.
<shaka444[m]>
mbrumbelow[m]: That what I thought.
<mbrumbelow[m]>
A bug report might be in order? 🙂
<x512[m]>
trungnt2910: ^
<shaka444[m]>
Will do
<Anarchos>
hello
<trungnt2910[m]>
<x512[m]> "For per-window desktop it is..." <- Can we make the windows always visible in this case?
<x512[m]>
Yes. But it also need to be connected with remote desktop windows.
<x512[m]>
It will need app_server refactor and I am not sure how will it be difficult.
<trungnt2910[m]>
Instead of forwarding the low-level hardware interface might it be possible to go up a level to the thing that draws the layers?
<x512[m]>
This object is rarely used, mostly for WebPositive.
<trungnt2910[m]>
Yeah that thing.
<x512[m]>
Used to implement BView::BeginLayer, BView::EndLayer.
<trungnt2910[m]>
x512[m]: So most of the time we only use the ServerWindow object?
<x512[m]>
ServerWindow and View.
<x512[m]>
ServerWindow represents single top-level window running in its own thread and View is server-side counterpart of BView that is used for actual drawing and input. All BView are running with window thread.
<waddlesplash>
shaka444[m]: there's already a ticket about that
<Anarchos>
waddlesplash i am a victim of the 'mutex not owned' in realtekwifi _callout_stop :)
<shaka444[m]>
<waddlesplash> "shaka444: there's already a..." <- Oh sorry I just posted a ticket.. I'll remove
<waddlesplash>
Anarchos: yes I need to look at that today
illwieckz has quit [Ping timeout: 480 seconds]
Begasus_32 has quit [Ping timeout: 480 seconds]
illwieckz has joined #haiku
<Anarchos>
waddlesplash thanks :)
<shaka444[m]>
waddlesplash I guess you need access permissions to close/remove a ticket? The one in question is #18367
Begasus_32 has joined #haiku
nosycat has joined #haiku
ClaudioM has joined #haiku
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<trungnt2910[m]>
<x512[m]> "ServerWindow accept IPC..." <- So in terms of design we can create a class `RemoteWindow` and use that when dealing with remote desktop connections?
<x512[m]>
The complex part will be how to connect it to Window class without breaking existing hardware screen app_server.
<trungnt2910[m]>
Window seems a bit too high-level.
<trungnt2910[m]>
Who's responsible for drawing the background?
<trungnt2910[m]>
If we can just tell that part not to draw the blue Haiku background, and then convert all rectangular regions into a host window, then it might somewhat work.
<x512[m]>
<trungnt2910[m]> "If we can just tell that part..." <- T
<trungnt2910[m]>
After more thought, it won't work.
<x512[m]>
> <@trungnt2910:matrix.org> If we can just tell that part not to draw the blue Haiku background, and then convert all rectangular regions into a host window, then it might somewhat work.
<x512[m]>
* In this case all Haiku windows will become above all host windows on activation.
<trungnt2910[m]>
The client still doesn't really know what is a window and what is not.
<trungnt2910[m]>
x512[m]: I was thinking of creating a host window whenever a "region" is rendered.
<trungnt2910[m]>
And then use the host's API to move it around or destroy it.
<x512[m]>
Single host window for all Haiku windows?
<trungnt2910[m]>
No, I mean one host window for every rectangle.
<x512[m]>
What is "rectangle"?
<trungnt2910[m]>
The bounds of a region that the server requests the client to draw.
<trungnt2910[m]>
But that won't work.
<x512[m]>
It should be possible to put a pointer to RemoteWindow to each Window object and turn off Desktop visible region clipping.
<x512[m]>
So remote desktop client will know to which window drawing commands belong and will be able to get whole unclipped window contents.
<x512[m]>
Maybe create HWInterface for each window.
<trungnt2910[m]>
What I think is we can subclass RemoteDesktop from Desktop and keep all the current rendering interface.
<trungnt2910[m]>
RemoteDesktop should do whatever Desktop does but also notifies the client about the windows' statuses.
<trungnt2910[m]>
(Size, position, z-index, is visible or not,...)
<trungnt2910[m]>
The client renderer can then just ignore anything that does not fit in a window reported by the "RemoteDesktop".
<trungnt2910[m]>
We don't even need to turn off the visible region clipping (unless you want the windows to work well with content preview features like Windows's Alt - Tab)
<trungnt2910[m]>
This strategy is quite similar to what VMware Unity mode seems to use.
<x512[m]>
Do you mean annotate existing whole screen with window information (visible regions etc.)?
<x512[m]>
So host OS will use guest OS windows visible region as shape region.
<trungnt2910[m]>
x512[m]: Not visible regions but active windows.
<x512[m]>
It should be easy to disable title bar, it is fully handled on server side.
<x512[m]>
But is is subtracted from windows visible region under it.
<trungnt2910[m]>
<x512[m]> "How do you plan to make client?" <- If this goes well I can make two clients: One for Haiku and one for Windows.
<trungnt2910[m]>
x512[m]: What do you mean?
<x512[m]>
Window title bar affect visible region calculation. So it can't be just ignored. It should be turned off on server side.
<x512[m]>
Title bar is called window decorator in Haiku.
<trungnt2910[m]>
Seems like we can ignore the decorator settings and just return an empty BRect in that mode then.
<x512[m]>
Remote desktop protocol also need to have better multiplexing support. Currently whole windows may stall if some window will draw some large bitmap.
<x512[m]>
Also it should be possible to do some wizardly with virtual memory to avoid sending unchanged bitmap data.
<trungnt2910[m]>
wizardry with virtual memory?
<trungnt2910[m]>
That's only possible when you have kernel access.
<trungnt2910[m]>
Like the folks at WSL2.
<x512[m]>
For example protect pages read only and make pages writable in signal handler with recording dirty pages needed to be sent.
<trungnt2910[m]>
x512[m]: Well that would make things much harder and potentially requires some redesign...
<trungnt2910[m]>
My proposal above tries to avoid creating new protocols as much as possible.
<PulkoMandy>
there is not really any reason to keep the existing protocol, if we need to change it we can change it
<PulkoMandy>
otherwise we add useless legacy complexity
<x512[m]>
I also considered solution with splitting large bitmap so smaller rectangles so it can be better multiplexed with other commands.
<x512[m]>
But it maybe better to have additional virtual multiplexing byte stream channels layer so each drawing thread use its own channel.
<x512[m]>
So is some thread will draw large bitmap, channel can be preempted by other thread.
mmu_man has joined #haiku
<trungnt2910[m]>
Maybe create threads in the client itself, so one thread is responsible for receiving the commands and others for drawing?
<x512[m]>
Commands need to be properly multiplexed when sending over network. Otherwise very big command will cause big delay of sending many small commands.
<x512[m]>
Big command need to be cut into smaller commands.
<x512[m]>
Primary source of too big commands is bitmap drawing.
<trungnt2910[m]>
Any plans for doing that in the foreseeable future?
freddietilley has quit [Quit: WeeChat 3.8]
jess has quit []
vdamewood has joined #haiku
<x512[m]>
Plans are quite vague.
jess has joined #haiku
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #haiku
tqh has joined #haiku
<x512[m]>
trungnt2910: What is left for `haikuporter` support?
tqh has quit [Quit: Leaving]
tuaris has joined #haiku
Anarchos has joined #haiku
mmu_man has quit [Ping timeout: 480 seconds]
nephele has joined #haiku
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #haiku
mmu_man has joined #haiku
nephele has quit [Quit: Vision[]: i've been blurred!]
BrunoSpr has joined #haiku
vdamewood has quit [Remote host closed the connection]
vdamewood has joined #haiku
<Habbie>
i can't shrink a BFS filesystem, right?
<win8linux[m]>
Begasus, is the SDL dev lib location on x86 the same as on x86_64?
<win8linux[m]>
Currently editing a Makefile to add the Haiku-specific locations of the SDL dev libs.
<BrunoSpr>
Habbie, no you cannot atm
<BrunoSpr>
you have to plan in d
<BrunoSpr>
Habbie, you need to plan in advance your hard disk space at the moment
<Habbie>
got it
<Habbie>
i'll just nuke it, in this case :)
<Habbie>
thanks
<BrunoSpr>
yes sorry
smalltalkman has quit []
eroux has joined #haiku
tqh has joined #haiku
Anarchos has quit [Quit: Vision[]: i've been blurred!]
HaikuUser has joined #haiku
HaikuUser has quit []
HaikuUser has joined #haiku
HaikuUser has quit []
nosycat has quit [Quit: Leaving]
mmu_man has quit [Ping timeout: 480 seconds]
jmairboeck has joined #haiku
xikufran has joined #haiku
BrunoSpr has quit [Quit: Vision[]: Ich wurde verwaschen!]
xiku has quit [Ping timeout: 480 seconds]
Begasus_32 has quit [Quit: Vision[]: Gone to the dogs!]
Begas_VM has quit [Quit: Vision[]: i've been blurred!]
<nekobot>
[haiku/haiku] 81d3bc02bf43 - BMenuItem: use unicode character for B_SPACE shortcut
mmu_man has joined #haiku
ClaudioM has quit [Quit: leaving]
mattlacey has joined #haiku
<trungnt2910[m]>
<x512[m]> "trungnt2910: What is left for `..." <- Nodes and volumes watching.
jmairboeck has quit [Quit: Konversation terminated!]
<trungnt2910[m]>
Also I am looking at re-building PackageFS to be something that is extracted lazily and probably to a shmfs mount so that quick mounting and cleaning would be possible.
<trungnt2910[m]>
* re-building PackageFS emulation to be
Diver has quit [Quit: Leaving.]
bbjimmy has quit [Remote host closed the connection]
bbjimmy has joined #haiku
<bbjimmy>
waddlesplash why are we stuck at hrev56921?
<waddlesplash>
we are?
<waddlesplash>
oh, buildbot off
<bbjimmy>
ok
<waddlesplash>
will ping kallisti5
<trungnt2910[m]>
Ohh so that's why pkgman full-sync is not doing anything the last few days...
kallisti5[m] has joined #haiku
<kallisti5[m]>
Afk. I'll be home in an hour or so and can kick it