Page MenuHomePhabricator

tasn (Tom Hacohen)Administrator
User

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

User Since
Jan 23 2013, 8:14 AM (343 w, 3 d)
Roles
Administrator
Availability
Available

Recent Activity

Today

tasn added a comment to T8151: RFC: Text interfaces design proposal.

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.

Sat, Aug 24, 7:16 AM · efl: api

Thu, Aug 22

tasn added a comment to T8151: RFC: Text interfaces design proposal.

Actually, I also added my initial thoughts regarding the elm_entry layer because there really not that much to it. So on a high level this is the complete proposal of how things are going to look. There are still a lot of comments here, and even more comments I have for myself, so a lot of things can and will still change, though conceptually they will stay the same (or at least follow some of the notes in the comments). I'll keep on translating my notes to something readable and update this document. :)

Thu, Aug 22, 10:54 AM · efl: api
tasn updated the task description for T8151: RFC: Text interfaces design proposal.
Thu, Aug 22, 10:53 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.
  1. I do not know how all those objects are connected with each other, however: When benchmarking lately, you could observe that we very often spent a lot of time in emitting events, due to the fact that the event callback list is getting giantly long. And the emitting of a single event might walk this whole list. So maybe its better to connect them via API instead of events (just as a comment)
Thu, Aug 22, 10:34 AM · efl: api
tasn updated the task description for T8151: RFC: Text interfaces design proposal.
Thu, Aug 22, 10:17 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I change a few things based on the discussions of the last few days. I added a very rough sketch of the Raw_Editable object. It needs much more work, but I suspect this one will only be finalised after it's at least partially implemented. I suspect it'll probably be very similar to what efl_ui_text.eo has (when it comes to the context menu/imf stuff like autocaptial), just probably cleaned up and trimmed down.

Thu, Aug 22, 10:17 AM · efl: api
tasn updated the task description for T8151: RFC: Text interfaces design proposal.
Thu, Aug 22, 10:12 AM · efl: api
tasn added a comment to T8161: RFC: Eolian support for lightweight classes.

I'm still jumping back and forth on this one. It's just so useful for text cursors.

Thu, Aug 22, 10:04 AM
tasn added a comment to T8151: RFC: Text interfaces design proposal.
Font f = new Font("Arial",25);
TextBlock t;
Button b;
Label c;

t.font = b.font = c.font = f;// this is shared for all objects
Thu, Aug 22, 4:21 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I'm not that crash hot on Efl.Text.Annotation.Factory. Certainly as a name... Wouldn't Efl.Text.Range be better and as part of the constructor/construction of the range you have to pass 2 cursors? the question now would be - does the range keep tracking the cursors or is it fixed and the cursors are just used as markers for begin/end when u construct or set/change them later? so more:

r = Efl.Text.Range()
r.color_set("red");
r.range_set(cursor_start, cursor_end);
r.weight_set(BOLD);

Once you set the range the range attaches it to the Efl.Canvas.Text object the 2 cursors are attached to implicitly? The range object becomes a child obj of the text obj and thus is destroyed along with the text obj? Now should range_set just USE the cursor values at the time so you can now re-use the same cursors to rang_set() on another range obj with different positions (you moved the cursors around).? What you have seems to be a range factory we can re-use but once you've inserted a range into the text obj.. then what? how do i manipulate it later?

Thu, Aug 22, 2:31 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I think we want to search another name for *font* in general, font does sound like it is representing a font itself, but it is not. I would go for *fontable*, since it expresses that this receives font-properties, but is not a font. (I am bad at naming, happy to have something besser fitting here)

Thu, Aug 22, 1:51 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

Thanks for the suggestion, but I think that would make it harder for me rather than easier. The concepts are very much connected (e.g. Font on its own means nothing, how is it used?) and often there's overlap.

Thu, Aug 22, 1:24 AM · efl: api

Wed, Aug 21

tasn added a comment to T8151: RFC: Text interfaces design proposal.

This is clear things up, to know that we are based on current existing stuff

So how about break this @property font
Into :
@property fontfamily
@property fontSize
To make it more clear what does it mean.

Wed, Aug 21, 10:56 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

@tasn
Again Font should not be interface, Are there font-able objects other than font object?
If my class use font object then he composite inside, not adopt new interface, do you have any example from other platforms ?

Wed, Aug 21, 10:17 AM · efl: api
tasn closed T8161: RFC: Eolian support for lightweight classes as Invalid.

Even though I sat on this for a few days before posting it here, I'm now not sure if we want to encourage this "out of eo" behaviour. So I'm closing it for now, but at least we have it for posterity.

Wed, Aug 21, 9:51 AM
tasn added a comment to T8161: RFC: Eolian support for lightweight classes.

One more comment actually: it's problematic when it comes to sharing interfaces. So you can no longer have shared interfaces when you use this (same problem as @static), which kinda sucks. That's what's nice about the factory pattern.

Wed, Aug 21, 9:40 AM
tasn created T8161: RFC: Eolian support for lightweight classes.
Wed, Aug 21, 9:35 AM
tasn added a comment to T8151: RFC: Text interfaces design proposal.

Lets discuss this one first :

interface Efl.Text.Font
Can also be applied to annotations
functions and properties:
@property font

can you please help me understand what is this @property font?
Is it string ? why it has same name as interface ?

Wed, Aug 21, 8:26 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

It's already explained with examples in the original post.

What post ?

Wed, Aug 21, 7:11 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I think it is best to discuss other parts too, current discussion could be discussed in better way.

Second Part:
Font
1- Why Font is interface rather than class?

Wed, Aug 21, 6:57 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

Thank you. This is what I thought I understood. As discussed on Z169, I don't see the value in this and I debunked all of the specific potential benefits you raised there.

Wed, Aug 21, 6:14 AM · efl: api

Tue, Aug 20

tasn added a comment to D9628: elm_entry: handle cursor delete/backspace with clusters consist of one or multible glyphs.
In D9628#178653, @tasn wrote:

I haven't looked at the actual code, but I do plan on making textblock2 work on grapheme clusters too, so this is inline with that change.
Though maybe I'd wait with this until TB2 is in, hopefully in a few weeks?

@tasn
This one is for application bugs with legacy APIs, so - I'm wondering whether your plan with TB2 will effect legacy applications or not.
If not, I think this kinds of patch is necessary.

Tue, Aug 20, 11:49 PM · efl
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I mean why we need to attach this funcinality (Create and manipulate markups ) to be part of canvas, why cannot to expose it, and everyone can use it canvas and other objects and users (everyone), Why do we need to hide it in TextBlock

Tue, Aug 20, 8:58 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

+GTK
https://developer.gnome.org/gtk3/stable/GtkTextBuffer.html
(Iterators and Markup are implemented on Markup Object(GtkTextBuffer) level )

In pango case as I see it (I am not expert in it, and it is hard to compare with efl, because it expose lot of things).
https://developer.gnome.org/pango/stable/pango-Markup.html
https://developer.gnome.org/pango/stable/pango-Text-Attributes.html
Parsing Markup text is not done on Text Layout, there are specific part responsible for parsing and building markups(Text + TextAttributes)

Tue, Aug 20, 8:53 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I think either I'm misunderstanding you, or not explaining myself well enough because your messages seem to support my point, I'll try to explain what I mean again.

Tue, Aug 20, 6:43 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

So each user want to create Markuptext should create his own Markup builder ?! I do not think this is good for user

Tue, Aug 20, 6:27 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

Not sure what's the real definition of usecase, but when I say it, I mean a case of what a real user *wants* to do, not just can potentially do.

Tue, Aug 20, 6:10 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

This is not a usecase, this is what you are trying to do. Why are you trying to do? Could you explain? If you got input from the user, then it was entered in a textblock, so you already have a textblock involved, so this usecase doesn't apply. Caching them: you can cache the markup with the current code, what we are talking about is modifying the markup directly, so this is also not a usecase.

Tue, Aug 20, 5:37 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

Now things are more clear.

My Idea is having Markup Object, were you can :
1- Assign cursors
2- Create and manipulate Markup text, away from TextBlock.

Tue, Aug 20, 4:26 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I do not get the difference between Annotations and Markup Object.
Why do not we make annoations work on Markup Object, instead of working on TextBlock.

Annoation only manipulate Markup, So why do not we make it work on Markup text.

Tue, Aug 20, 3:53 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

Some questions while checking the description of this task.

Efl.Text.Item.Factory
Almost identical to Annotation but used to insert items rather than annotations.

This one would have the same way with "Anntation Factory" to be inserted in text object. Am I right?

Tue, Aug 20, 2:17 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I said "the same interfaces (so functions)", in the markup text it would look something like:

an_factory = Efl.Text.Markup.Annotation.Factory()
an_factory->weight_set(BOLD)
an_factory->insert(eina_str_buf, 5, 10)
Tue, Aug 20, 2:08 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

@tasn
You are so fast ! You added reply just after I deleted my comment !! HAHA. (I needed more time to arrange my idea)
Anyway thanks for the reply.

Tue, Aug 20, 1:50 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

First lets forget about Documnet and Manager, I think it will complicate things on this stage.

For cursors:
I think this is dependant on style of coding :), (this is just my thoughts)

From exposed API view, enum is much easy, you add one line only containing name of enum.
From user perspective, using one function, and read documentation from enum is much simpler.
Tue, Aug 20, 1:45 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I'm wondering two things -

  1. whether cursor is necessary
  2. how about supporting annotation_set from text object

    For exmaple,

    ` an_fatctory = Efl.Text.Annotation.Factory() an_factory->weight_set(BOLD) tb1.annotation_set(an_factory, 1, 4); tb2.annotation_set(an_factory, 3, 5); // if want to share the same annotation

    `

    Many developers have not understood well why cursor_object was needed.
Tue, Aug 20, 1:42 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

(Bare with me, i was never in touch with text)

  1. There is T1049 (and in entrance the password mode is implemented without elm_entry) What do you think of not having the password at the canvas layer, and only have it in the efl.ui. object ? and only have it there in one field, so its never passed to the theme etc.
Tue, Aug 20, 12:48 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

I think I understand our misalignment here. It's just about terminology (and therefore location of things). I'm not against Efl.Document and Layout manager, but I think having them in textblock is out of scope. Your examples also seem to imply the same, look below:

Tue, Aug 20, 12:44 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

OK, let's try the quoting context thing. :)

Tue, Aug 20, 12:34 AM · efl: api

Mon, Aug 19

tasn added a comment to T8151: RFC: Text interfaces design proposal.

Another note: I can already see how it's going to be very difficult to keep track of comments and discussion if we do it here in phab. The discussion has already diverged (@cedric and @ali.alzyod asked about different things), should me move it to edevelop? Or do you fellas prefer keeping it here?

Mon, Aug 19, 1:55 PM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

Thanks @zmike! Rest of you: I'll answer tomorrow. :)

Mon, Aug 19, 1:51 PM · efl: api
tasn added a comment to D9628: elm_entry: handle cursor delete/backspace with clusters consist of one or multible glyphs.

I haven't looked at the actual code, but I do plan on making textblock2 work on grapheme clusters too, so this is inline with that change.
Though maybe I'd wait with this until TB2 is in, hopefully in a few weeks?

Mon, Aug 19, 1:50 PM · efl
tasn added a comment to T8151: RFC: Text interfaces design proposal.

Thanks for your comments, my reply is inline:

Mon, Aug 19, 10:57 AM · efl: api
tasn renamed T8151: RFC: Text interfaces design proposal from Text interfaces design proposal to RFC: Text interfaces design proposal.
Mon, Aug 19, 9:01 AM · efl: api
tasn added a comment to T8151: RFC: Text interfaces design proposal.

As it says, this is my current proposal. I'll update it in the next few days with more interfaces, but this is the base textblock part.
I included my own personal notes so you can comment on them too. Please let me know your thoughts about the general design, specific functions or anything else you have in mind.

Mon, Aug 19, 8:57 AM · efl: api
tasn created T8151: RFC: Text interfaces design proposal.
Mon, Aug 19, 8:55 AM · efl: api
tasn added a comment to T8093: Name conflict between class and property.

@woohyun, I'm going to reshuffle things in the text space so I wouldn't worry about making a decision/change yet. I'll take a look at the WPF naming scheme when changing though.

Mon, Aug 19, 1:23 AM · efl: api, efl (efl-1.23), efl: language bindings

Fri, Aug 16

tasn added a comment to T8118: RFC: Eolian support for standalone (non-class) functions.

Mostly done in rEFL8a8a833837f7217aea0a33f4f7afbb6edfb103c4 (thanks @q66!), still missing the stuff from the previous comment though.

Fri, Aug 16, 9:39 AM
tasn added a comment to T7675: Do not allow static-function polymorphism.

Thanks @q66, fixed in rEFL8a8a833837f7217aea0a33f4f7afbb6edfb103c4

Fri, Aug 16, 9:38 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T8118: RFC: Eolian support for standalone (non-class) functions.

It looks like it was agreed in T7675 to call this @static. @q66 is doing the rename, but just a few things that are missing and should be implemented (copied from the other ticket):

Fri, Aug 16, 7:28 AM

Thu, Aug 15

tasn accepted D9565: efl_canvas_text: remove unused Text_Style eo struct.

If it's indeed unused and was never released, it seems fine to me to remove it. It looks like it was just a copy-paste from the old object that wasn't removed.

Thu, Aug 15, 2:58 AM · efl

Fri, Aug 9

tasn removed a member for committers: tasn.
Fri, Aug 9, 11:48 AM
tasn removed a member for efl: canvas: tasn.
Fri, Aug 9, 10:17 AM
tasn added a member for efl: canvas: tasn.
Fri, Aug 9, 10:17 AM
This is a test notification, sent at Fri, Aug 9, 6:07 PM.
Fri, Aug 9, 10:07 AM
tasn added a comment to T7675: Do not allow static-function polymorphism.

That's one of the suggestions I made above. I'm fine with that too, though that's a different discussion.

Fri, Aug 9, 10:06 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

It's adding back @class and then adding @static that is just like what @class is now. OK, thanks for the feedback!

Fri, Aug 9, 9:21 AM · BBQ, efl: data types, Restricted Project
tasn updated subscribers of T7675: Do not allow static-function polymorphism.

Gotcha, good to know. Then @static is maybe the best option for T8118. @q66, anything to contribute regarding the syntax suggestions?

Fri, Aug 9, 8:42 AM · BBQ, efl: data types, Restricted Project
tasn updated subscribers of T8118: RFC: Eolian support for standalone (non-class) functions.

The idea of replacing one by the other won't solve what I described because like all global functions of such sort, you can have only one. Again, what happens when you have libefl-markdown.so that wants to offer markdown and libefll-html.so that wants to offer html? They can't both replace the textblock object globally.

Fri, Aug 9, 12:50 AM
tasn added a comment to T7675: Do not allow static-function polymorphism.

Do you mean the Text_Factory classes? I'm wondering what would be the case for them to have actual @class dynamicity.

Fri, Aug 9, 12:44 AM · BBQ, efl: data types, Restricted Project

Thu, Aug 8

tasn updated subscribers of T8118: RFC: Eolian support for standalone (non-class) functions.

I updated the example to use an interface instead of a class to make it more clear.
I'll also elaborate on my markdown example so it's even more clear (though I thought I was).

Thu, Aug 8, 2:57 PM
tasn updated the task description for T8118: RFC: Eolian support for standalone (non-class) functions.
Thu, Aug 8, 2:50 PM
tasn added a comment to T7675: Do not allow static-function polymorphism.

@lauromoura: I think I already addressed your comment too in my reply to @felipealmeida , please let me know if that's not the case.

Thu, Aug 8, 2:50 PM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

By size I mean typing more. I'm not against it per se, but for static use it doesn't look like a good tradeoff to me. This is going to uglify bindings and I don't really see much of a difference in change the name of the method or pass a different type. It actually creates one more point for error, where people can pass wrong classes, they can't when the class is embed in the function name.

Thu, Aug 8, 2:42 PM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

Do we have a use case? Features are nice, but I think they must be justifiable.

Thu, Aug 8, 1:42 PM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

The problem is with singletons/factories + inheritance, as implied from the context of this discussion.

Thu, Aug 8, 7:48 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

Marcel, I keep in repeating myself. I already addressed what you just wrote numerous times like at the last paragraph of: https://phab.enlightenment.org/T7675#139789
Even with non-class functions, C functions can't access overridden functions in C# (or if they can there, not in all bindings), and if there's a way to make it work, then there will also be a way to make it work with overrides not just overwrites.

Thu, Aug 8, 7:03 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

Yeah, I understand that new means override (now that we have discussed it further), but as I said, in my last comment and previous ones, it doesn't matter, because this logic is handled by C anyway. The same scenario you just described would break even with non-class functions because the C code will not call your C# code. So I don't see why the obsession with this specific case of class functions when the same functionality is overall broken.

Thu, Aug 8, 6:34 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

Thanks for adding the clarifications, though this is something I already addressed at the bottom of: https://phab.enlightenment.org/T7675#139789

Thu, Aug 8, 6:12 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

And also you haven't addressed the other point, which is even if you were right about this point, these shouldn't live in the class but rather in a related namespace.

Thu, Aug 8, 5:22 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

Read what I said at the bottom of the last post. It doesn't matter because everything is done in C anyway. You don't get the behaviour you're describing in normal non-class functions either. It always behaves like overloading because it calls C directly under the hood, doesn't actually use the language's object system.

Thu, Aug 8, 5:21 AM · BBQ, efl: data types, Restricted Project
tasn updated subscribers of T7675: Do not allow static-function polymorphism.
Thu, Aug 8, 5:04 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

Actually, now I'm really pissed off you are wasting my times and spreading false information, here's a fucking C# example:

using System;
					
public class Program
{
	public class A {
		public static void foo() {
			Console.WriteLine("A");
		}
	}
	
	public class B : A {
		public new static void foo() {
			Console.WriteLine("B");
		}
	}
Thu, Aug 8, 5:01 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

Stop trying to twist my words and start reading them. I never fucking said ask Tom for changes in eo. I said, when you fundamentally change existing code, ask the people who wrote it why it was the way it was. Not just me, not just Eo. I talked to raster a lot when I redid the text system way back when, I talked to everyone a lot when I did the object system, I talked to cedric when I touched the relevant edje parts. It's just common sense to ask people who actually know the code why things that you find weird are done the way they were. I don't understand why you keep on trying to ridicule this statement. It's obvious and should be the basis to everything you do.

Thu, Aug 8, 4:58 AM · BBQ, efl: data types, Restricted Project
tasn added a comment to T7675: Do not allow static-function polymorphism.

I didn't say you have social problems, I was complaining exactly like the above. I said the big issue with this change is the broken process (which is a social aspect, not technical) that lead to you changing a massive piece of code without asking *anyone* that's been involved in it's creation and design when I'm on IRC, mail and read the ML. The only one of the "reviewers" that actually maybe was involved is q66, but he said he wasn't asked to review any proposals (as evident by this ticket and lack of participation) but rather to review the code. It's not about me, I just don't understand why you'd make such a big change without first gathering information.

Thu, Aug 8, 3:35 AM · BBQ, efl: data types, Restricted Project

Wed, Aug 7

tasn added a comment to T7675: Do not allow static-function polymorphism.

I just finished a big damn rant on IRC about this. Honestly, did it not occur to you to ASK why things were done this way? I'm on IRC every day. I still have my email address. No one asked. This was talked about so many times. Argued back and forth. It was set the way it was set for a reason.
No, C# not supporting class function overrides is not an excuse. It's something we discussed, anticipated and had solutions for already in 2014.
As I said on IRC: C doesn't have classes, should we just drop classes then? Python doesn't have types, why not drop types?
This is absolutely mental that you went on with this without at least asking! I'm not saying you made the wrong decision here (though I believe you are), I just find it crazy that you'd change something so fundamental without asking the people who worked on it for literally years. I didn't get a single email or a single text. Never mind the lack of respect for other's people work. It's just stupid and wasteful to keep on rewriting other people's work without first asking.

Wed, Aug 7, 11:23 AM · BBQ, efl: data types, Restricted Project
tasn triaged T8118: RFC: Eolian support for standalone (non-class) functions as Wishlist priority.
Wed, Aug 7, 10:34 AM

May 9 2017

tasn added a comment to T5411: Extending Ecrire.

Sorry for not replying earlier, I completely missed this one, as I'm not very active on phab.

May 9 2017, 2:40 AM · Restricted Project

Dec 8 2016

tasn edited the content of Hosting / SSH.
Dec 8 2016, 6:29 AM

Nov 16 2016

tasn added a comment to V27: Where should we hold the Enlightenment Developer Days 2017?.

Just a couple of thoughts:
We already did Edinburgh and Paris recently.
Edinburgh and London are fairly expensive (even with the recent currency devaluation).

Nov 16 2016, 12:44 AM

Oct 19 2016

tasn closed T4740: evas objects leaking in some cases as Resolved by committing rEFL5a659fafd22d: Eo: Fix reference leak when failing to resolve function..
Oct 19 2016, 8:33 AM · enlightenment-git, efl

Sep 30 2016

tasn edited the content of Promise.
Sep 30 2016, 9:56 AM
tasn edited the content of Eolian.
Sep 30 2016, 7:06 AM

Sep 29 2016

tasn edited the content of Promise.
Sep 29 2016, 10:13 AM
tasn edited the content of Promise.
Sep 29 2016, 9:51 AM
tasn edited the content of Promise.
Sep 29 2016, 1:20 AM

Sep 28 2016

tasn edited the content of Promise.
Sep 28 2016, 10:22 AM
tasn edited the content of Promise.
Sep 28 2016, 10:17 AM
tasn edited the content of Promise.
Sep 28 2016, 10:16 AM
tasn edited the content of Promise.
Sep 28 2016, 9:08 AM
tasn edited the content of Promise.
Sep 28 2016, 7:34 AM
tasn edited the content of Promise.
Sep 28 2016, 7:27 AM
tasn edited the content of Promise.
Sep 28 2016, 7:26 AM
tasn created Promise.
Sep 28 2016, 7:19 AM

Sep 19 2016

tasn accepted D4298: eo: fix callback cmp.

Nice catch. :)

Sep 19 2016, 3:34 AM

Sep 12 2016

tasn added a comment to T4227: EFL memory usage - dirty pages from SO files.

There have been a few fixes, we are now at:
00007f661ecea000 116K r---- libelementary.so.1.18.99
00007f661ed07000 32K rw--- libelementary.so.1.18.99

Sep 12 2016, 1:11 AM · Restricted Project

Sep 9 2016

tasn added a comment to T4418: eo incorrectly missing methods present in interface hierarchy.

This should be OK now. Is it?

Sep 9 2016, 1:49 AM · efl

Sep 2 2016

tasn added a comment to T4385: Font weight styles don't affect a output of string when there aren't font faces according to the styles. .

Yes, I think we should go with the second option. Option 1 feels wrong. It's not the poor app's fault that the system is broken. We need to help it.

Sep 2 2016, 7:34 AM · efl: rendering
tasn added a comment to T4418: eo incorrectly missing methods present in interface hierarchy.

Thanks, your second (redacted) log and analysis is very helpful. I'll only be able to take a look next week (hopefully), but this would really help, and more so, it's probably very simple to fix.

Sep 2 2016, 7:33 AM · efl

Aug 23 2016

tasn added a comment to T4385: Font weight styles don't affect a output of string when there aren't font faces according to the styles. .

On the phone/desktop you don't see terminal output when you run an application, you will never see this error as a user of an application. Furthermore, in some cases it can't be done at all (font embedded in the theme, or a specific file). There is no nice graceful way of printing an error from our side. Applications could potentially check and report the lack of fonts, but that's out of scope for us as the GUI toolkit. If you want absolute correct results as an app, deal with it an error, otherwise, we owe it to applications to do the right thing. There is no spec anywhere saying that fonts should come with bold variants, so "runtime embolden" should be considered as a reasonable alternative. More so, it actually is. I doubt fonts will be too screwed.

Aug 23 2016, 3:19 AM · efl: rendering
tasn added a comment to T4385: Font weight styles don't affect a output of string when there aren't font faces according to the styles. .

Yes, using a good font that was designed this way is best. However, such a font is not always available so we try to do our best in accommodating the programmer's request, so we make fonts bold on runtime. It's a fallback to a missing font.

Aug 23 2016, 1:05 AM · efl: rendering