User Details
- User Since
- Sep 27 2013, 1:37 AM (488 w, 4 d)
- Roles
- Administrator
- Availability
- Available
Sep 10 2018
Sep 9 2018
Sep 7 2018
As long as this works for the windows build (I cannot test here)
I cannot find documentation of this mimetype - and I cannot replicate.
What system has set this?
Sep 6 2018
Not invalid
Not invalid
The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.
The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.
The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.
First pass is done, we can revisit to see what needs to be added for 0.8 if anything
Sep 5 2018
Aug 31 2018
Aug 28 2018
Looking at this again I think @netstar is right - an elm_code should not close the file if there is an active instance... By destroying the container you close the file correctly.
Aug 17 2018
looks good to me, thanks for landing @stefan_schmidt
Aug 16 2018
Sorry, pressed the wrong button
The first half was fine but there's some questions about the latter part
Aug 14 2018
Aug 5 2018
This is too complex and the provided patch seems to work fine. Can be revisited later if required
Aug 1 2018
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...
Jul 31 2018
As per the email chain recently please be aware that moving code into Eina is also changing it's license. Be careful!
Jul 27 2018
Jul 24 2018
That's merged into efl master now
Jul 22 2018
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
No
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
Yeah, @zmike is right about that. @segfaultxavi I thought I had a simple example but it turned out the compiler flag had been turned on by an unrelated piece of code that later turned it off...
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...