The module sends messages which the theme displays. Thus, the
module requires a theme with an implemented edj script to be
useful.
Currently EFL 1.26 includes a basic text label for this...
Usage is recursive...everything under the window is included.
Rudimentary, as usual...please do something pretty...
RFC. Hopefully I didn't break the universe...again!
rememebr zone randr id where clients were if forced off a zone. if a
zone is added check clients with that zone id - if they have it then
restore them there. thbis will get loat if you move those clients
between zones after they are dumped on the other zone or you change
their virtual desktop etc.
many steam games don't provide much in properites - not enough to
match to a desktop file. the only thing that actually consistently
works is to use the STEAM_GAME property and match thyat to the uri
provided to the steam command in the exec of the desktop file. this
actually can work. nothing else works reliably across the board.
and man can games be horrible and playing nice with desktops and
having poor properties. even steam itself is not good. i had to add a
workaround for that too to match steam-runtime explicitly. :(
in any case where client needs to be rescaled to use new screen geometry
certain things must happen, such as handling shaded state and forcing the
new geometry to be applied
there's too many properties to create flags/events for all of them, so just use this
if it's one of the many misc props
currently only used for skip_{pager,taskbar,winlist}
this indicates that saved geometry has been set and should not be
updated during maximize
currently only used to handle transition from fullscreen -> maximize
UNIGNORE is the hook to watch for wl clients as they are added; the
ignore mechanism prevents most of the compositor from processing
clients. this is a stupid method from an api perspective since it's
different in x11 and wl, so it should probably be improved on in the future
This reverts commit e1c3120689.
this commit revealed a number of issues with the xdg6 implementation related
to unconfigured buffer management: see subsequent patches for a less
sledgehammer-y solution
ref 5497fadce4
let's say you sue tiling or some module and it wants a window by
default to maximize or fill the screen or be size XxY ... this stops
the client first having a buffer smaller (or larger) and then sizing
down rendering 2 times (one of the renders is pointless). this makes
initial buffer render/show seamless as it should be in wayland.
this makes tasks behave like you'd expect with a stack - only show the
top one and track properly. tasks was simple and easiest to do first
as it has little fluff other than the tasks logic itself. other
elements of e next...
this adds core basic handling for window stacks where windows behave
correctly as a single unified stack something like what naviframe does
but out-of-window so you can including multiple processes. only on x11
right now as it's being supported/worked on.
as we dont plan to kepe naviframe in future, this is the way to go.
naviframe "pages" will be windows in a stack. the wm should do the
nice thing. in e this will be very nice. for now elsewhere we use
transient_for so a wm would treat this like a bunch of dialogs with a
single parent window. i guess in a desktop thats probably what you
might expect. e will be a little more "finesse" filled.
need to make ibar, tasks,m win menu and winlist (alt-tab) respect this
and only show the top member of a stack.
need to send messages to clients when they are "top" or "middle" or
"bottom" or "alone" in the stack or something so decorations can change.
should add soem new border signals in theme (for both SSD and CSD) to
make this look nice. will need some config additions for that and
ability for e comp to do the right thing
but this is a solid start
This api give the possibility to add sink to an E_Client and control the volume
or the mute state of the sinks associated with this E_Client.
@features
if csd exists in only one of (before || after) a maximize/fullscreen,
this provides info so that the right size can be used when restoring
geometry
...again
so i was profiling today .. leak hunting .. and i noticed. if you have
enough appss open - eg terminology, e uses a huge amount of memory...
for icons. terminology is 128x128 ... thats 64k per icon. open up a
lot of terminology windows and we duplicate that 64k per every window
on the wm sside because we get the data. it would apply for any app
that sets a netwm icon. this can be come rather silly if you have like
100 terminals. it's worse with larger icons (eg 256x256 - 256k per
icon).
this puts in a simply list for shared icons and a lookup on fetch to
de-duplicate and share icon data. this should drop memory usage
nicely.
@improvement
this came in a patch that I take full responsibility for not adequately reviewing at the time.
the names are confusing and counterintuitive, and it does not properly include the client namespace.
Alastair Poole
Carsten Haitzler
Elyes HAOUAS
Mike Blumenkrantz
Michaël Bouchaud (yoz)
Derek Foreman
Yomi
Chris Michael