- User Since
- Sep 27 2013, 1:37 AM (255 w, 3 d)
Fri, Aug 17
looks good to me, thanks for landing @stefan_schmidt
Thu, Aug 16
Sorry, pressed the wrong button
The first half was fine but there's some questions about the latter part
Tue, Aug 14
Sun, Aug 5
This is too complex and the provided patch seems to work fine. Can be revisited later if required
Wed, Aug 1
I kinda wonder why this fixes it really. Part of me wonders if we've got an issue in the "elm" setup in elm_code_widget...
Tue, Jul 31
As per the email chain recently please be aware that moving code into Eina is also changing it's license. Be careful!
Fri, Jul 27
Tue, Jul 24
That's merged into efl master now
Sun, Jul 22
Quite right, that check is needed
The move issue is no longer visible - perhaps that was due to be basing it off the 1.20 branch?
Other than the one comment inline this looks good.
Looks good to me :)
Jul 20 2018
You're right the freeze is fixed, just the black rectangle remains
@zmike pointed to a workaround in src/lib/ecore_cocoa/ecore_cocoa_window.m (line 121) whereby an additional timer makes direct calls to ecore_main_loop_iterate due to the NSRunLoop having blocked.
Jul 19 2018
I get the same behaviour if I call ecore_main_loop_iterate_may_block(EINA_FALSE) which is even stranger...
It's very close :)
As for a single method it looks like the geom_get, resize, move and show are almost identically grouped in widget_fill_cursor.
I'd say it should be possible to factor that and this patch into a single method.
Sorry, this is not quite there.
The cursor does not move to the correct location.
It seems to size correctly - but if you are not on the top line of the file it will hover in the wrong place (where the topleft was before).
Very close! Thank you for that.
Jul 18 2018
Works nicely here :)
Jul 17 2018
This also occurs on the current stable release.
Of particular note is that if you try again after seeing the black rectangle E can freeze :(
Jul 16 2018
I have not looked into the details but I think this must have created a little duplicate code.
Can we use the same code for when it's set up in the first place and when it's resized through this method?
Jul 6 2018
Cool, setting it to 5 or 10 works well, thanks. I tried 3 and it did the same deadlock
Happy to debug further but I don’t know what would be useful
Yes a good point. I switched to master and have the same issue.
In addition to not being able to switch away I noticed that cpu goes high and fans start spinning - I wonder if that is useful too?
Jul 5 2018
There are no errors on the command line when I force the application to exit remotely.
These lines refer to efl 1.20 not master
The relevant threads appear to be:
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
_outbuf_fb_wait (ob=ob@entry=0xd589c0) at modules/evas/engines/drm/evas_outbuf.c:213
Jul 4 2018
Ah I misunderstood sorry.
I had thought it was something else from the description.
If it's not visible then I agree it's not a 1.21 problem.
Jul 3 2018
I actually can't replicate this here - is there a small code snippet that I can use?
Jun 30 2018
Testing on my end suggests that D6483 does fix this issue.
Jun 29 2018
Apologies, it would appear this is now resolved.
Jun 28 2018
It appears to still be the case with that patch applied
Hi @netstar if you're not succeeding I will look - this should really get fixed for 1.21
Jun 26 2018
As an update this does not appear when ECORE_DRM2_ATOMIC_DISABLE is set.
There is a deadlock situation that also does not occur when this is set - may or may not be related.
Oops, sorry - the error is:
Jun 22 2018
Could someone see if this patch fixes it? I cannot currently test master...
I can't see the cause of the second issue - the null seems to be within layout code somehow...
Pretty sure it's not - perhaps @zmike can verify?
Jun 21 2018
The black line changes size in Edi using efl 1.20.9 - is this a regression or is it specific to Ecrire?
I can't imagine how it does not change as it's all part of the underlying text grid.
Jun 20 2018
Jun 19 2018
I mentioned before but not on this ticket, so I'll add it for the record.
I'm not sure I agree with not moving the cursor but pasting somewhere that the cursor is not...
The cursor remains where the input is occurring and I'd like to maintain that.
I cannot replicate this in Edi.
Is there a particular font that has been set? Does it happen with all fonts in Ecrire?
This should get fixed
Setting this to normal priority and removing goal as we can't fix this without a major refactor of the widget layout.
May 30 2018
May 16 2018
May 11 2018
I'm not sure the cause but the result is that there is documentation outside of the normal guards that hold back those beta APIs.
Can we please change the documentation then? Evas_Object_Vg Is public documentation marked as @since 1.14...
Apr 22 2018
Mar 30 2018
With the current widget setup I cannot find a way to make this work.
The mouse move event is not triggered on the text as the mouse is somehow tied to the background where the drag started.
Mar 29 2018
Mar 22 2018
Looking at some editors (on OS X):
When you right click the cursor jumps to the location so that the operation will happen where expected.
If you are outside the area and there is a long line of text on the last line it does not make sense to paste at the end of it - the content will not appear in the expected position.
Where in the last line? The pointer position may not be after the end of the last line...
I had thought that would be the correct behaviour... Given that there is no context at that location what do you imagine the menu should contain?
Feb 10 2018
Feb 4 2018
Jan 29 2018
Jan 25 2018
Jan 19 2018
I disagree with the combining of toolbar and tab bar. Whilst they may be similar from a ui (and also external api) point of view the function differently.
Jan 18 2018
p.s. would this not be better described as "navigation" rather than "accessibility" issues
Its all linked from the menu in any Contribute page - https://www.enlightenment.org/contrib/start
I don't think this can be closed once elm_interface*.eo is done - there are other relationships still using the Elm namespace, vis:
Jan 15 2018
This is progressing but hit a wall.
The current work in progress is at efl.git/devs/ajwillia-ms/elm_code_wrap.
Unfortunately when you make the window smaller so it wraps I get a corruption in evas_textgrid that I cannot figure out.
Jan 14 2018
Jan 5 2018
Done, at least a first pass https://www.enlightenment.org/contrib/devs/enlightenment-regression.md
Editors remain in phab for now. All docs in phab that have been replaced should link out to the new website pages.