Re: [E-devel] Etk - Authors' Explanation

[Nathan I. <nin...@gm...>]

Simon,

On 10/24/05, Simon TRENY <sim...@fr...> wrote:

> Your patch doesn't seem to fix anything here. Now, the situation is even
> worst, I can't close anymore the menu by clicking anywhere on the parent
> window, I always have to click on a menu item. And keyboard navigation
> is more than just making a printf each time you press the up or the down
> arrow.


It needs a handler added for off-window clicks, and I already said that
keyboard navigation wasn't hooked in. It DOES grab the keyboard and mouse s=
o
those hooks are available.

If it's possible, why don't you allow the themability of the scrollbar
> drag buttons or of the tree headers independantly of the button? If you
> don't have time to work on the theme, then just do a copy-paste of the
> button group and rename it as scrollbar_drag and tree_header. At least,
> it will allow themers to make a correct theme without having to change
> the ewl C code.


They already are able to do that, and have been able to be themed separatel=
y
for years. There was a change here recently because of the API changes made=
,
but you can theme the drag button using the /vseeker/vbutton and
/hseeker/hbutton keys. There have never been C code changes necessary for
this.

Great for the radio and check buttons alignment thing fixed, even if
> there is still the problem with the normal buttons.


Yep, my fault there, I got goaded into making the fix in code when it
belonged in the theme. The buttons are setup so the theme can control the
label alignment, this was a feature request by Simon Poole before EWL
supported setting abritrary text parts on a theme.

Here I fully disagree. I played a little bit with ewl_tree_test, and I
> replaced the ROWS constant by 3000 (it was initially to 50) and I
> removed the NEST modulo just to make sure all the rows will be directly
> children of the tree itself (no collapsed rows). Result? It takes
> approximatively 2 mins for the window to appear, scrolling is laggy as
> hell, and (I don't why) it caused the shutdown of ewl_test after 30 secs
> of use (no segv, just a shutdown). And hopefully, you've coded a
> function to know the heap size. So here is the result: "HEAP SIZE:
> 71053312 bytes". Yes, more than 70Mb for 3000 rows. And I don't see how
> you can improve the situation without limitating the type of widgets you
> can add to the tree. Even if "2950 * num_of_rows *
> num_of_evas_objects_by_widget" evas_objects are hidden, they are still
> processed by the rendering pipe of evas, and worst they still remain in
> memory.


You're right about the current tree implementation being too heavy, that's
part of the reason we've been looking at some different approaches when
changing the data model. The current tree does create evas objects for all
shown (not necessarily on-screen) widgets. Remember that object cache I've
been talking about for a while? That code eliminates all off-screen or
non-visible evas objects and a large chunk of the memory used. dan and I ra=
n
some tests and the results were very promising. That being said, we've
decided to do the tree work before pushing in the complete object cache
(some of it has already gone in). Primarily this is because the tree work
will be a bigger win overall, and we want to see the full impact pre-object
caching.

No offense intended (really, I may have explained it poorly), but you've
completely missed the point of the tree changes I've mentioned recently. Th=
e
point is not to hide the evas objects, the point is that widgets and evas
objects don't exist for objects that are not on screen whenever feasible. S=
o
while you may have 3000 rows, if only 20 fit on screen, you only have 20
widgets and their associated evas objects. When used in combination with th=
e
object cache, you should never have more evas objects than the max that hav=
e
been visible on-screen at one given time.

I'm really tired of responding to what are basically long-winded and hostil=
e
bug reports. These responses are taking far more time than fixing the actua=
l
issues. So unless you actually bring up design issues, I will be treating
any further messages like this as a bug report and will only be responding
to reported issues as they are fixed.

Nathan