This is a lot of updates. I'll give it a try asap.

Thanks raster for still upgrade E.
--
Felipe Magno de Almeida
Owner @ Expertise Solutions
www: https://expertise.dev
phone: +55 48 996810157
LinkedIn: in/felipealmeida


On Thu, Feb 6, 2020, 17:39 Carsten Haitzler <[email protected]> wrote:

> I actually should start doing this more... and write proper new items for
> www
> and so on, but right now I'm feeling lazy so I'm just going to squirt this
> out
> in email.
>
> Here are some hilights from recent e development in git master. I encourage
> people to try these things out and see how they work for you.
>
>
>
>
>
>
> DDC backlight support for desktop monitors
> ------------------------------------------
>
> I've done a bunch of revamping of the backlight control code. The API was
> decent, but... the implementation was dumb. It assumes a laptop world of a
> single screen only having a backlight control. No longer! Now every screen
> gets
> backlight controls. Your desktop monitors too. The idle fade stuff will
> work on
> desktop AND your internal laptop screen now. Put a backlight control
> gadget on
> a shelf on each screen and it will control THAT specific screen.
>
> How does this work? First E checks to see if X's randr system supports a
> backlight control for that screen. If it doesn't, it looks around at
> /sys/...
> fs nodes and if it finds something that looks backlight-like it will assume
> that controls the "lid screen". It will also now use libddcutil (from
> ddcutil)
> if you have it installed and dlopen that lob at runtime (no compile time
> dependency needed) and use libddcutil to control your monitor via i2c ...
> this
> requires the revamp i did of the setuid root tools and merging them all
> into
> one root service daemon e spawns to do these things. There are many good
> reasons why this needs to be this way, but it means E can not just now dim
> and
> brighten the backlight on your desktop monitors, but it can fade smoothly
> etc.
> and save power when you're not busy there... just like your laptop screen/.
> This should work with or without X just as the /sys fs support works
> without X
> too. This revamp makes e's backlight code a lot smarter and nicer. The ddc
> infra work opens up the door to providing on-screen OS driven controls for
> everything your monitor's on-screen menu has when you press the buttons on
> your
> screen. This allows E to even query the rotation of your monitor, set the
> color
> temperature and other color correcting controls, sharpness, contrast, the
> speaker volume on the monitor itself and much more. the plumbing is there
> and
> for now the ddc controller filters to ONLY allow the backlight property
> (0x10)
> to be queried and controlled. This can expand in future, but for now
> everything
> is plumbed through from back end to the backlight gadget gui and all the
> idle
> fade handling and so on works... :)
>
> Setuid helper rewrite
> ---------------------
>
> I merged all the functionality of the various setuid root tools e uses for
> things like /sys/ fs backlight control etc. into a single daemon that hangs
> about and e talks to via stdin/out. This reduces the number of these and
> has a
> single access point now. This has replaced everything except the eeze mount
> helper stuff in EFM, the new tool can replace the mounting/unmounting needs
> and the code is there, but the way eeze works means I can't slot it in
> easily.
> I have to rewrite the way EFM works to do this, but this is a nice
> "invisible
> cleanup" that should provide a single gateway for permissions on who can
> run
> this tool etc. and was necessary for the DDC stuff to not be glacially
> slow.
>
> Wallpaper generation now handles multiple resolutions
> -----------------------------------------------------
>
> Before when we imported an image into our wallpaper collection
> (~/.e/e/backgrounds) we would run edje_cc and generate an edj file with the
> wallpaper encoded in it at the quality requested with the sizing info
> there too
> letting edje handle it. This way E farmed that sizing/tiling/centering or
> even
> panning off to the file itself and didn't need to store it itself - just
> which
> one you want. You can delete the original image since the import made a
> copy so
> it's a bit more reliable. The problem was, if you import some 8k photo...
> it
> will encode that full resolution image in the edj file and E will have to
> load
> all of it then upload all of it to a texture and so on at runtime... Now I
> fixed this to have an import tool (bonus - you can run the tool by hand
> too to
> import/generate wallpaper edj files for your collection), and it will
> generate
> multiple resolution versions of the wallpaper (smaller resolution ones, not
> higher), so if you mindlessly import that 8k photo.. E will generate 6k,
> 5k,
> 4k, 3k, 2k, and so on resolutions for a bunch of common resolutions and it
> will
> encode them all in the edj file so now it will use edje to choose the
> resolution that is most appropriate (closest to what you want - same res
> or a
> a little higher) and then at runtime E will not load the 8k one all the
> time.
> it'll load the one that best fits, thus speedup up startup time etc.
>
> Screenshot revamp with built in mini-inkscape-like diagram editor and
> cropper
>
> -----------------------------------------------------------------------------
>
> I have totally redone the shot module in almost every way. It now supports
> explicit actions to delay by a given amount (e.g 500ms or 8000ms). It
> interactively allows you to click "delay" to delay by an amount (slider the
> slider up and down) to take another shot in that amount of time later...
> so you
> can shot menus and similar things. It still supports saving and sharing via
> e.org's screenshot service, but now E won't hang when it saves - it uses a
> slave process to do this so E keeps working smoothly. Saving of shots has
> moved
> to ~/.e/e/shots and always places shots there as files. if you choose to
> save
> it will automatically show that dir in efm after it's saved so you can
> immediately dnd it out to some target app (e.g. that mail you are writing).
>
> But best of all ... when it shoots it shows you a zoomable/scrollable
> preview
> which by default you can just click on any screen or window and cycle
> through
> which window, screen or window with padding around it you want cropped,
> showing
> you the crop area. You can also free-draw the crop rect just witch
> click-and-drag ... and you can modify the crop region by clicking the
> handles
> in the corners and dragging them around.
>
> Not only this... You can now draw text boxes and type in notes./text on the
> screenshot. You can draw arrows and lines, little e logos, square
> "surround"
> boxes or ellipses, even speech bubbles with text (the only legitimate use
> of
> comic sans font... which is what is used here :) ), thought clouds with
> text,
> and even some comic "KABOOOOOM" labels, some pointy fingers to point at
> things,
> a Monty Python foot to stomp on bits of your screenshot ... and even Malloc
> makes an appearance with 2 Malloc tools to draw cute cats on your
> screenshot
> for good measure (as a kind-fo easter egg). Malloc is awesome. You shall
> accept
> his new found fluffiness in your WM! :) Not only can you draw these things
> and
> size them as you like, you can alter the sizing later (unlike Gimp - more
> like
> Inkscape) and alter their 2 colors (fg/bg) and choose from a palette of
> colors
> provided or use the HSVA sliders. You can delete these doodle objects if
> you
> don't like them and just click on them in move/modify mode to raise them to
> the front, and you can also rotate them freely if you click on their center
> multiple times to toggle between move/resize mode and rotate mode. When
> you hit
> save or share exactly what you see and selected to crop is saved or
> uploaded
> with all your doodles there. The crop is done at save time so the crop
> region
> can be modified at any time and will be applied then.
>
> Jus about the only things shot doesn't do now is offer you the ability to
> print
> (who the hell prints screenshots these days?) and it won't make you a
> sandwich.
> Sorry.
>
> E's shot module/tool is now full "batteries included" awesome++. Enjoy it.
>
> Crash alert dialog improvement
> -----------------------------
>
> The crash alert dialog now is a blast from the past. It's an Amiga-like
> guru
> meditation along with the same Amiga bitmap font and blinking red outline
> at
> the top of your screen. For those of you with fond memories of your
> Amigas...
> I give you some nostalgia. I also made this crash work for Wayland mode
> now too
> (it didn't before due to e holding KMS hostage while it was hung in crash
> mode). In the process of this I made E's restart handling require
> enlightenment_start to make it work as now e_start uses E's exit codes to
> know
> what to do (restart, exit cleanly etc.). This also reduces fd leaks from
> one e
> execution to another since before for restarts E just exec()'d itself.
>
> Music control
> -------------
>
> This will now actually run your selected music program if you click on it
> and
> it's not there. :)
>
> Polkit support
> --------------
>
> E now has a polkit helper to ask for your password should any tool ask
> polkit
> to authenticate... So E will pop up the password dialog for you etc. - no
> extra
> polkit helper daemon needs to hang around and no external modules needed.
> It's
> built in to e (well it's a module that comes with E).
>
> Startup smoothening and pre-caching
> ----------------------------------
>
> E now pre-caches data it thinks it'll need (has a background thread go
> page in
> data from disk like your theme and wallpaper). This is done in the
> background
> in a thread while the rest of E keeps running along starting up. This will
> also
> smooth out the initial startup fade in as data will already be precached
> thus
> not causing stalls. I've seen this visibly improve E's smoothness on start
> on
> my Rpi's.
>
> Fixes / workarounds
> -------------------
>
> So many to mention, I won't mention them all, but one is a workaround X's
> bad
> habit of allowing the pointer to exit the screen area with multiple
> screens of
> different resolution. I added some code to ecore_x to support setting
> pointer
> barriers and make E enforce them now to disallow the pointer leaving the
> screen
> area.
>
> Lots of other fixes for little things here and there too which I'm not
> going to
> get into due to the sheer volume of them.
>
>
>
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> Carsten Haitzler - [email protected]
>
>
>
> _______________________________________________
> enlightenment-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to