Page MenuHomePhabricator

efm: directory hover preview sizing issue.
Closed, ResolvedPublic

netstar created this task.Aug 16 2017, 5:34 AM
zmike added a comment.Aug 16 2017, 8:02 AM

It should be sizing based on the min size of the text in the 3 entries though...

Yeah, I just spend some time with it. Does this have something to do with the scroller region in elm_entry.c ???

Dunno, pretty sure it used to be fine before efl changes at some point

Yeh, I can't really give this more time. I'm pretty sure it's not the e_widget stuff the same issue occurred when using my own implementation of the WIDROW macro and even without...

Something strange with elm_entry. If you use a different widget to display the values like a label instead of the entry, the widget resizes appropriately. Sorry I've not been able to fix that more.

Sorry D5095 NOT 5093.

zmike added a subscriber: jpeg.Aug 17 2017, 9:39 AM

This is actually unfixable with current efl. The info entry must be scrolled for appearances, but using a scrolled entry prevents min size setting. Normally this could be worked around by using elm_scroller's content_min_limit functionality, but elm_entry doesn't implement this so there's nothing that can be done.

This broke as of efl-1.20.1 for me. Was OK with 1.19.1. Would that not be the place to fix it? I'm no coder but both patches I've tried have been for enlightenment not efl. I hope this doesn't come across as arrogant. Just trying to understand.

This broke as of efl-1.20.1 for me. Was OK with 1.19.1. Would that not be the place to fix it? I'm no coder but both patches I've tried have been for enlightenment not efl. I hope this doesn't come across as arrogant. Just trying to understand.

You're correct in that it's definitely an efl regression of some kind, and this is not too surprising given how much work is being done there.

I guess there are a large number of diff's between those versions? If not too many, I could try them all out and narrow down which one broke the directory preview maybe?

Yes, it's been about 4 months with over 1500 patches. You can try bisecting if you want, though I imagine it would take considerable time to track down.

Haha. OK, I had no idea what I could be getting myself in to there. I might back out that idea then :-)

the fact it worked at all before was pure luck. you CANNOT go set min size hints on an entry and expect them to override what the entry sets itself. it's pure luck as to who gets in "last". this is not an efl bug. the minimum WIDTH of a SCROLLED entry is in fact very very very small because it can scroll. if you want that column wider, the place something in that column that has a LARGER minimum width (like 100* scale or something). the WIDROW macro doesn't even try and set a minimum width at all... it makes no use of the entw variable AT ALL and doing the "set min size hint on entry using entw as width" is just going to fight with entry's own setting of min width. trust me - it's NOT an efl issue. just look at the code. the entries are packed into the table and since everything is set to shrink the LARGES min size of a column (or row) is going to force the table to be bigger and there is NOTHING there to force it. the entry will not do that for you - ever. not elm entry. use ANOTHER object. e.g. an invisible rectangle, pack it into that cell (or column) in addition to the entry AND set min size hint on it to force that column (or row or cell) to expand to at LEAST that size. if the entry has a larger min size in that dimension then it'll force it to expand... the code there in filepreview is just broken in this regard. read it carefully.

i can fix it for you trivially with a few lines FYI ... i just am busy with other things pending in my local git repo and i have no desire to mess with shuffling things around branches so i can just push a single patch now. (oh and the 2nd WIDROW macro is wrong setting min size to 100 ON the entry - see my previous comment. not an efl regression. just broken code here in file preview as i explained)

ok. in the last minute i fixed it locally. i have a patch queued in my git repo. will be pushed as soon as i get some other things more cleaned up to push. this should auto-close with the commit log when i push.

I hate to come off sounding stupid but, why in the world is this even a scroll-able entry and not just a information dialog of some kind?
I mean It's a popup that you can't even interact with, maybe something other than an entry window would be more appropriate.

if the text in that field is silly long then the popup doens't become silly big - it gets trucated by the scroller...