On 10/24/05, Simon TRENY <[EMAIL PROTECTED]> wrote:
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 so those hooks are available.
They already are able to do that, and have been able to be themed separately 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.
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.
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 ran 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. The 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. So 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 the object cache, you should never have more evas objects than the max that have been visible on-screen at one given time.
I'm really tired of responding to what are basically long-winded and hostile bug reports. These responses are taking far more time than fixing the actual 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.
NathanYour 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 so 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 separately 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 ran 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. The 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. So 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 the object cache, you should never have more evas objects than the max that have been visible on-screen at one given time.
I'm really tired of responding to what are basically long-winded and hostile bug reports. These responses are taking far more time than fixing the actual 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.
