Can you try to add text_class into style, instead of add description in text section ?
Here is my comments on current design
i've tried a few combinations of the options and i can't see a new window appear. i do see an existing window that points to the base mount point go up a parent, and others that point further in disappear with error dialogs. we could handle that a bit more consistently i guess... but... no new window. :( both eject and unmount -> same story. unless you change settings efm will not even mount until you open the dir in an efm window. it'll auto unmount when you close the window. it's intended to be this way to minimize filesystem dirtying until you actually need/use it (opening the window == using it). there is an option to do the "always mount anyway" but that exposes you to making filesystems dirty... so i don't know how to see what you're seeing :)
Hm, strange, it's pretty repeatable here. I have the "automatically mount" and "open EFM upon insertion" options enabled, if that makes a difference. I'll check when I get home, but I wonder if it's actually the "eject" option that is doing it...
I have.... never seen that... ever. I am not even sure how that can happen? I unmount here and efm just goes back a dir if its in the root of the mountpoint or if its deeper it ends up closing the window(s) with these dirs with error dialogs. i dont see a NEW efm dir appear.
It looks like there aren't many (any?) high level objections to this proposal for now other than @ali.alzyod's which I believe I already addressed on a call we had.
I'm therefore thinking it may be time to take this proposal one step further. I plan on creating .eo files based on this proposal in addition to writing more detailed usage examples and descriptions (a longer version of what's currently there in the General Description section). This will exposed a lot of details that are currently opaque in the design description above (such as property types and method parameters) and include better detailed inheritance structure and will also include events.
The more detailed guides will also shed light on how I envision using the text objects will look like.
For the future, I'd like the commit message to say what is this fixing. There was a crash before this patch, for example?
Also the error message is very uninformative.
I'm not sure how to contribute here. I think it was me that suggested extra instead of end when discussing default items for lists, but I have no idea what the _efl_ui_layout_swallow_parts array does.
Fri, Aug 23
Fixing changes of others diffs.
oh the orange blinker == scan, blue == visible.
that's up to bluez. it'll stop blinking when it stops scanning :)
add blank line with all functions.
merge in changes that got lost
Blank line in all functions.
Quite some time has passed now, the situation is a little bit different now, the only cases where efl.end is still used is in efl.ui.texts theme, so i think we could resolve this single case and just drop efl.end in favor of efl.extra ?
I missed this somehow.
this issue is still present on latest git.
may someone finds a little bit time to have a look? :)
Looks pretty good
this is the active scanning indicator. Should there be a timeout?
I suppose I'm okay with a one-time config upgrade for this case. But for future cases then it should work as I described.
it looks like the toggle buttons are broken. i can click the "mode" button, but nothing happens.
Closing and open the settings again and the settings for"advanced mode" are shown.
No, that's the specific case that D9708 fixed.
This needs doc cop review. I'm okay with it.
i think there was something cut off: the changes in the test suite are needed to reflect to the new behavior of the event.
move flag setting
update commit message
more docs and different walking
- eolian-mono: Adding a blank line in all functions.
This is still needed, the possibility that a file gets announced before the backend knows that file is still there, a immediate deletion would make the deletion event not possible, which is a bug (discovered by our own test suite).
This is IMO a terrible guideline, a user does not even know where the configs are, so i guess he also does not know how to add configs manually from config 1 to another config. We completly lack this migration code for all the newly added widgets, which leaves (at least for me, and someone who sent me his config) the new widgets like Efl.Ui.Scroller [and others]. The user could delete the list content, but keep the struct, which would us also give a chance code wise to check if a config is broken, or the user disabled things.
I think I may have fixed this case with D9708?
Historically in EFL projects we've just added keybindings based on version changes, e.g., version X adds keybind Y, so add Y to the config when doing the X upgrade. This change would add back bindings which have been manually deleted by users. Instead, the bindings update function should just copy the system config (and then not destroy the system config unnecessarily) for the config version being upgraded for.
Seems good overall.
There's not actually a single change to src/tests/elementary/spec/efl_test_multi_selectable.c in this patch which has any relation to the rest of the patch despite the changes being significant. Can you break this out?
A small but significant nit: there's no specification in the doc about what happens if end is greater than the total number of items. In _range_selection_find you handle this by verifying the end marker for the range and erroring if it isn't found (without making the change). This seems like probably not what app developers expect, and it certainly is not specified in the docs.
I think the list -> array should be broken out into a separate patch (using git-phab). Also some other minor nits. Seems fine otherwise though.
Actually I created a separate patch for it . As it based on the first patch , when I did arc diff it just combined it to one phab ID :(. if you know how to create separate phab id please let me know.