The new e_go

Hi Everyone!

I was briefly introduced to you by the owner of this blog a few posts ago. My name is Yossi, I’m on EFL team and I’m assigned to E. In the last  couple of month I was entering the world of Enlightenment by fixing bugs to learn the whole thing, just like in those old Kong-Foo movies. Last week, Michael (e-realeasemanager) kindly made me a co-author of this blog so I’ll be posting (duh.. ranting) regularly.  I even almost got my commit rights, but fate stood in my way.  (sorry zmike, I had to :)) )

My latest patches were in the somewhat dusty corner of e – the file manager (e_fm) . A small bug revealed that the whole selection mechanism in e_fm is faulty and neglected and It had to be changed (both functionally and code-efficient) to fit the common standard for file managers (Such as nautilus for example). The desktop navigation between the icons with direction keys is changed also since its(Desktop) just e_fm in custom mode. Now movement between the icons is straightforward – moving to the closest in that direction in a 90 degree arc.

 

 

 

 

 

 

 

Advertisements

PORKCHOP SANDWICHES

It’s been a while, I know, but I’ve been busy and there’s lots to show for it.

 

EFL Developer Day:

Yes it’s happening, yes you can come, no you don’t have to attend LinuxCon EU in order to come (though you should if you can, because it’s going to be awesome and I’m presenting again). Register now!

 

Shaped window mouse input:

Yes it works, even for poorly-written desktop records.

 

Desk flips:

No, they don’t break edge bindings anymore.

 

Window input:

No, borderless windows no longer sometimes drop mouse input through to the window below.

 

Other things:

Yes more changes have happened in the past couple weeks, no I’m not going to list all of them.

 

 

I’m off traveling for the next couple weeks, so it’s unlikely that there will be any updates until Octoberish. I don’t know what I would blog/rant about until then anyway, so it’s probably just as well.

 

For anyone who craves more E updates in the meanwhile, I suggest following our tumblr.

Infos

Work continues. I fixed a couple large stacking issues today, and I have some fun announcements:

 

EFL Developer Day:

We weren’t sure whether this was going to happen, but it’s now moving swiftly through the paperwork phase and into reality. It will be held on 20 October 2013, in Edinburgh, Scotland just before LinuxCon. More information is available here, and I’ll blog about it more as details emerge.

 

Enlightenment.org Gets SSL Certificate Donation:

As many people know, we’ve had a certificate which wasn’t recognized by the main authorities, prompting most browsers to throw warning dialogs upon visiting any of our SSL pages. This has now been resolved thanks to a most generous certificate donation by Gandi SAS. We’re very grateful to them!

Bugs

I came out of my coding fugue long enough to remember that I should write a post here. So let’s see, recent E18 changes:

 

  • “raise on focus” now works as expected. If you’re using pointer/sloppy focus, you probably want to disable this option to return to your previous behavior
  • Bindings (and the rest of your configs) now upgrade smoothly from E17 without crashing or erasing things
  • GTK apps with their stupid NETWM resize grips work again
  • Mouse in events get passed to already-focused windows, which should trigger autoraise in a more reliable manner
  • Window stacking should be much more reliable
  • Iconified/shaded windows no longer grab focus on an E restart
  • Shaded windows now maintain their positions across restarts
  • Iconified windows now gain focus as expected when selected with winlist

What Really Grinds My Gears

As many of you loyal readers are aware, gadgets have always been a bit of a sore spot with me. The reasons for this are many and varied, which is great since I need something to rant about this week. If you’re a normal citizen of the internet who claims to have ADD but really just doesn’t like to read past an introductory level, skip to the bottom for the executive summary.

 

“Gadgets” in E are insanely complex, and there is no real reason that I can determine as the sole cause (aside from gradual feature creep). Part of this complexity stems from the fact that we have three different types of gadget containers, also known as gadcons: shelves, toolbars (only used in EFM windows), and my eternal nemesis, gadman (desktop/overlay gadgets). Gadcon has a number of interfaces which allow it to theoretically work fine across all three of these, but what really happens is that it turns into a giant kludgefest–everything is propped up by toothpicks to create the illusion that it actually works.

While this awfulness may be transparent to the user, aside from the random crashes here and there and the inability to accurately move gadgets on a shelf (hint: this isn’t going to be fixed), the big downside is that it makes everything gadget-related a huge pain in the ass. Fixing gadget-related bugs is terrible because a tiny change that fixes a bug in one container, such as gadman, could cause a huge change in functionality somewhere else. As an example, I recently did some tweaking to iBar and gadman to make them play more nicely together because iBar didn’t really do that whole “resizing” thing as a desktop gadget, where “resizing” is defined in this case as the ability to make a gadget smaller. The process for fixing this was as follows:

  • Test current iBar-gadman functionality
  • Determine that iBar doesn’t correctly update its size unless it’s in a shelf
  • Try making it update its size normally (min size)
  • Desktop iBar fixed, shelf iBar covers my entire screen
  • Try alternate method for updating size (aspect)
  • Shelf iBar works normally, desktop iBar resizes spastically
  • Try adding evas size hints to base gadcon sizing methods
  • Shelf iBar works normally, desktop iBar doesn’t appear at all (wtf.)
  • I don’t remember the next hour because I blacked out in a coding rage, but the end result is that I had to add max size values to gadget objects which only get set/used by iBar and gadman

So now, to fix a pretty trivial/innocent bug, yet another hack has been added, another toothpick to hold up the tower. Great. I’m sure it will make total sense to anyone else who wants to work on gadgets why iBar is special and uses a max size like this.

 

 

Sadly, this isn’t even the worst part of the current gadget debacle. No, the worst part is actually trying to write a gadget using the current system. What may have started out as a cohesive and logical API has had so many bullshit features tacked on that it’s a total nightmare.

Want to get your gadget to size a certain way? Don’t worry, we’ve got 35 different gadget-specific methods and struct members you can try in various combinations, along with all the normal evas object functions, until you get that magical sequence which lets it show up how you want it. On the desktop. Oh, you want it to work on a shelf, too? Better budget out another week of your life if it’s not a simple, non-resizable image!

Cool, you’re going to add menus to your gadget. Remember to feed a mouse up to the evas in your button callback so you don’t break every other mouse click callback and have to restart E! Also have fun with figuring out how to get your gadget menus to have the hierarchy you want.

 

 

Remember that time you tried to drag a gadget around? Did it work? If yes, a miracle occurred and the weeks of time that I’ve spent on gadget DND over the past year have paid off. If no, I can’t really say that I’m surprised. Whereas more sane uses of DND in E (see border/iBar/EFM) have single handlers for each of the DND callbacks, gadgets have a DND interface which relies on the gadcon to apply as many hacks as necessary to wrangle the dragged gadget into the position/size that you may or may not expect. In shelf, this majestic failure results in the long-lasting (and not-going-to-be-fixed-any-time-soon) bugs where you lose gadget position when dragging gadgets around. In gadman, you’ll probably get random crashes/flickering if you drag a gadget back and forth to the desktop, because we have to completely delete and then re-create the gadget every time it leaves/enters a gadcon, not to mention the luck involved with anything related to the hover layer (AKA ‘the bane of my existence’). Toolbar seems to not be widely used, or maybe people are just not trying to put anything other than the EFM toolbar into it; these are the most likely answers to why I don’t have a constant stream of bug reports about it.

 

In closing, as of the year 2013, systray is the worst piece of specification garbage in existence for free desktops. I imagine the meeting where it was invented went something like this:

Year 1905, a cold, deserted shipyard. A small cluster of figures huddle around a typewriter.

Nefarious Supervillain: Let’s make all the desktop environments put an XWindow into a gadget! GTK already uses XWindows for every widget, so it’ll be easy for everyone else, too!

Incompetent Developer: This is a great idea, and I support it. We’ll ship with this as a standard in all applications by next year.

Semi-competent Developer: Won’t this cause problems with input?

Incompetent Developer: Balderdash! GTKWidget has separate event handlers for everything, so we’re sure to get all those events.

Semi-competent Developer: But what if we weren’t using XWindows for every widget, or if we had a different display server which didn’t work in the same way as X?

Nefarious Supervillain picks up the typewriter and smashes Semi-competent Developer over the head with it. Semi-competent Developer falls to the ground.

Nefarious Supervillain: Anyone else want to question my evil genius?

The remaining developers cower in fear. Some poke nervously at their Palm Pilots.

Nefarious Supervillain: Excellent.

 

 

Executive summary of current E gadgets and systray:

Presentation & Polish

It’s probably been pretty obvious to anyone here, but I am no longer in “full time” development mode for E18. Much of my time lately has been focused on the new hotness and various presentation preparations. Miraculously, some E18 bugs do managed to get fixed  here and there, whether because someone finally submitted a worthwhile bug report (“my clikcz dont work somtimes” does not qualify.) for me to look at, or because they’ve been getting fixed by either Carsten Haitzler or my up-and-coming E disciple, Yossi Kantor. For those of you unfamiliar with the second name, he’s been quietly fixing a number of bugs behind the scenes over the past couple months, particularly in relation to iBar.

 

If anyone has any suggestions for some worthwhile topics for me to discuss here, feel free to leave comments; I guarantee nothing, but it’s always good to have ideas.

 

If you have bugs, you should have already submitted them to phab.

On Enlightening

I’ve been hearing a lot of grumbling and complaining from users over the past few weeks about how “E18 release is taking so long!” and “E18 doesn’t have all the features that it should” and “E18 burned my coffee!”.

There was a comment (not-so-)recently which asked what the motivation and main features of E18 were supposed to be, which brought it to my attention that we had no public roadmap or timeline, and my blog is basically the only interaction that exists between the general public and E18. I’m going to take some time to break this down:

Core Features:

This is a list of the core features which, just as WINE does, were/are the criteria necessary for the release of E18 as well as the motivation behind it.

  • Compositor integration, improvement, and usage.

In E17, a compositor module existed. It was written a few years ago as a basically a proof of concept and a demo of a composited E desktop. There were lots of bugs, and it did basically nothing aside from 1) composite your windows, 2) draw shadows, 3) add some subtle effects. E18’s primary goal was to make the compositor not only better in every way, but mandatory.

“Why should compositing be required?” is a frequently-asked question here, and one that I’ll be answering on the E19 blog in a future post, since that will focus almost exclusively on the topic of compositors. The really short and simple answer is “Because it looks nicer”. Anyone not satisfied with this answer has the choice between two alternative answers: “Because it makes things faster in some cases” or “Because it makes development much, much, much easier”.

“In making compositing a requirement, what’s been done here to make it worthwhile?” is another common question. The answer is as follows:

Canvas merging. This was the biggest and most time-consuming part of E18 development, and it took nearly three months to effectively execute. In E17, everything drawn by the window manager, excluding shelves which were set to “Below everything” had X windows and separate canvases backing them. This meant that every time you opened the menu, saw a popup, or made the gadget overlay visible, you were waiting for and using additional X resources, not to mention the resources required to create and render to a new canvas. In E18, the only visuals which have X windows backing them are the compositor itself and any internal settings windows you may open. Everything else, from popups, to shelves, to gadgets, to menus, to overlays, is drawn directly onto the compositor canvas.

Bugfixing. Lots, and lots, and lots, and lots, and even more than lots, of bug fixing. The E18 compositor runs faster, more smoothly, and using fewer resources than the E17 compositor. It’s also more accurate, which is easy to see if you scroll back and forth over a GTK application’s menu bar quickly.

Eye candy. We went from having choppy, limited desktop transitions, which actually required display server protocol interaction, to having around twice as many silky smooth animations which only rely on the speed and resources of the canvas that we’re drawing on. Additionally, it has become trivial to write and configure custom animations for this, as I outlined in a previous post. More things like this are on the way, and it will be a big part of E19.

Features. Useful features such as the new iBar menu and Teamwork would be much more difficult without compositing.

Wayland support. A non-composited desktop does not exist in Wayland, so this was a fundamental incompatibility which had to be fixed because, as everyone knows, Wayland and HTML5 are the future.

The downside of such a huge, fundamental change in a window manager (which still has code in it that’s 10 years old) is that it was all done as carefully as possible with as few changes to the surrounding architecture as necessary. This means that there is still a huge amount of code duplication and unnecessary latency in many areas. Is it noticeable to the user? No, since so many other things have been so heavily optimized. But to put it in perspective, E19 currently, before optimization has begun, starts over 25% faster than E18.

  • UDisks2 support.

I caught a lot of flak from users for not integrating this before the E17 release, and that’s not unexpected; E17 release was difficult and painful, and really we just wanted to get a release out there so we could have a starting point to add features. It was always intended, though it took a bit longer than expected because I am only one man, for E18 to support UDisks2 and stop requiring the now-very-old UDisks1. There’s not really a lot to say here since it’s a pretty self-explanatory feature.

  • Eye candy.

In the XComposite protocol specification, there is a special thank-you note for Carsten “Rasterman” Haitzler, for “Enlightenment, the original eye-candy window manager”. We hadn’t done anything truly groundbreaking in a while with E17, so it was always going to be the case that E18 should start to get us off the bench and back into the game here. We’ve got a long way to go in terms of [what we’re doing] vs. [what we’re capable of doing], but some of the intended changes are going to take time, since they require architectural changes to the underlying subsystems to better accommodate them.

One user, who remarked recently that “parts of [E18] still look like they’re from 2006” has no idea how accurate the statement is; checking code history will reveal that a staggering amount of code is at least that old. This isn’t necessarily a bad thing, since the design and implementation were sound at the time, but EFL and OSS have come a long way since then, and there are different and better ways to implement some things now. These changes, however, are going to take time, because we are, surprisingly enough, striving to make releases a fairly regular thing. My ideal timeframe for some releases could be as much as a full year, and other times as little as six months, but these scales will depend heavily on what features are slated for the release. A release with fewer or smaller features takes much less time to implement and stabilize than one like E18, which has (what I would say is) lots of new, complex features.

And that’s it. It’s not a huge list of features, but it resulted in a pretty large amount of code churn for one person to manage.

Releases:

I think this sums things up effectively. We were planning on doing EFL 1.8 around the start of July. E18 depends on the EFL 1.8 release. Since the 1.8 release was delayed, this means that the E18 release is still pending. I have no dates to give out now, but I’ll point readers to this event and suggest that there is a history of announcing releases of E-related things at LinuxCons.

Another factor in the lack of releases is that I’m required by EFL policy to delay the release by a week every time someone asks me when the release date is. I’ll also quote a great author by saying that “[E18] is not your bitch.”

 

EDIT: Just to make things clear, E18 will not be Wayland-only. There will be Wayland support.