Page MenuHomePhabricator

efl_ui_active_view: introduce a experimental new widget
Needs ReviewPublic

Authored by bu5hm4n on Mon, Apr 29, 9:30 AM.

Details

Summary

this widget tries to replace efl.ui.stack efl.ui.flip & efl.ui.pager
In general those widgets do the same thing, they get content. And
display them with some sort of animations. The new idea here is, that
the basic widget active_view only handles the ownership etc. of the
content that gets added to this. Then there is a view_manager object. The
view_manager object gets notified over the new contents, and requests for
displaying particular contents. The transition then handles those
things.

The version here is feature complete with Efl.Ui.Stack and Efl.Ui.Pager.
Additional features can be implemented in the corresponsing transition
classes. Examples and tests will follow

Diff Detail

Repository
rEFL core/efl
Branch
devs/bu5hm4n/work3
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 11478
bu5hm4n created this revision.Mon, Apr 29, 9:30 AM
bu5hm4n requested review of this revision.Mon, Apr 29, 9:30 AM

Hi @Jaehyun @woohyun @eunue,

I found out that efl.ui.pager, efl.ui.flip and efl.ui.stack share a great amount of code. So i tryed to generalize what those widgets do, what came out is this revision here.
Efl.Ui.Smart_Container is now a widget that takes and handles the ownership / parent stuff related to other widgets.
Then there is the transition property that can be used to specify a transition which will handle the specific placement and animation between content changes.

For now i still need to add events indicating when animation are started / stopped, this here is a early draft of the widget. You can test the elm_test smart_container tests to play more with it.

My long term goal, when this has evolved a bit more, is to remove Efl.Ui.Pager / Efl.Ui.Flip / Efl.Ui.Stack and go on with this widget + transition objects for the specific widget features / animations. This lowers our amount of maintenance code, and the number of widgets we need to test/maintain in the future. Further more, this also makes it easier to document the widgets, only one tutorial / documentation needs to be written.

What is your opinion about this plan ?

Everything builds and the Smart_Container Elementary tests seem to work as expected (except in layouts showing neighbor widgets, where new neighbor widgets are not immediately displayed after adding them).

bu5hm4n updated this revision to Diff 21814.Tue, Apr 30, 9:42 AM
bu5hm4n edited the summary of this revision. (Show Details)

More tests

A few bugfixes

General code refactoring

bu5hm4n updated this revision to Diff 21835.Wed, May 1, 3:31 AM

Here comes the final state (for now).

We now have two events with which we can track which content will be shown, and which transition has been started.

Everything in events is passed via indexes, also the current page.

bu5hm4n updated this revision to Diff 21837.Wed, May 1, 3:45 AM

fix warnings

bu5hm4n updated this revision to Diff 21838.Wed, May 1, 3:54 AM

bring back initial state of pager

bu5hm4n updated this revision to Diff 21839.Wed, May 1, 7:51 AM

fixing a faulty tcase

@bu5hm4n

Sorry I am late to give you comment about this patch.

I understood your point about this patch. But I think that Efl.Ui.Stack and Efl.Ui.Pager have been introduced based on the different purposes.

Efl.Ui.Stack is to navigate with depth. So it was designed based on stack data structure. e.g. if you push a button, then it goes to one more depth with a new content.
Efl.Ui.Pager is to show contents in a scroller with page size and transition effect (same depth). i.e. this is basically a kind of scroller but easy to set page and transition effect.

Although they look similar, but they have significant differences and purposes.
Moreover, it seems that the new class has additional features for another class to cover those two classes. e.g. indicator is only required for Efl.Ui.Pager not for Efl.Ui.Stack.

So IMHO, I don't think that integrating those two classes into one class is a good idea... I am afraid we need to think again about this patch..

bu5hm4n added a comment.EditedTue, May 7, 11:54 PM

I totally agree that the widget how they are right now have different purposes. However, the internal datastructure is still a list (undependend from if its a inlist or not a inlist) Every single operation of stack can be achived with this new widget. Pop if the removal of -1, push is pack_end. The difference of both widgets is only the presentation of the content, how it is displayed, with which animations. The rest, (organisation of keeping the children references, correct semantic etc.) is the same. And still while the two "feature-sets" pager and stack share the same basic widget. The code for the effective feature is still encapsulated in its own classes. (Efl.Ui.Smart_Container_Transition.Stack/.Scroll)

I can also understand that the indicator was in the beginning only intented for Efl.Ui.Pager. However, no one is forced to use it. And it is a nice-to-have feature. That we get here for free. And while testing it, it just works, and also steps with the animation progress.

Another argument here is. Think about how much this reduces the amount of code maintance, we get rid of almost 3K Loc, this means, way lesser tests, way lesser code adoptions when we change internal things. And way more benefit when finding / fixing bugs in the new widget.

Additionally, when someone in Tizen wants to have a new animation / transition / interaction, not a whole new widget is required, but rather only a transition object, which is way easier to write, and way lesser code. And for those transition objects, the maintainability is also way higher, you don't have to deal with widget internals or anything like this, all you need to worry about in there is the placement of your content.

@bu5hm4n

I totally understand your point.
If I understand your comment correctly, the main benefit of this patch is "reducing the maintenance efforts by integrating 2 classes into 1 class".

I still think that there are potential issue and current issue on this patch.

  1. Increase complexity in the integrated class

In contrast of the current benefit of this patch, more and more new features will be required for Efl.Ui.Stack and Efl.Ui.Pager separately based on their purposes.
If one class handles the requirements of two classes, then the number of properties and if-else clauses in the code would increase as well.
This would increase the complexity of the class and it would require more efforts to maintain the code eventually.

  1. Properties not related to original purpose

As I mentioned in the previous comment, this new class already has property which is not related to the original purpose to support two different classes. e.g. indicator and page_size for Efl.Ui.Stack
Those properties should not be added to the class. At least, I think we need to reduce those kind of properties as many as possible.
I think that it is something like "select" property is added to Efl.Ui.Stack. It is not forced to use the property but it does not look good..
The worse thing is the number of this kind of property would increase.

When there are requests for features only in pager / scroller but not both, then they can be added to the translation classes. Then they are not part of the smart_container widget. And no If's are required in the smart_container.
The reason i have choosen to do page_size and indicator in the smart_container widget, is that i think this is useful for all kind of animations.
For indicator: There is always some sort of "focus" onto one content page. The transition between this "focus" of two content pages can be expressed visually using the indicator widget, or displayed in some sort of page counter etc. I expect this to be usefull for all sorts of animation.
For page_size: And the page size is usefull, since you might want to express how big the content of something in the animation is, unrelated from its parent size.
And the only reason the indicator feature requires if(...) arround the calls, is that i do not want to call indicator API on a NULL object.

So for now i do not see / understand where this will increase the complexity of the smart_container itself in future. Your example with the select property can be perfectly implemented in the Transition_Stack class.

@bu5hm4n

You commented that transition classes will cover unique features for each container class.
IMHO, it may not be right for some cases because it looks weird if "transition" class supports "container" features.
Although you mentioned why you added "indicator" and "page_size" to smart_container, but I don't think that those properties can move to "transition" class. (they look like "container" features)
I am afraid that there would be more properties like "indicator" and "page_size" which is perfectly required for some classes but not exactly for other classes.

Furthermore, I think Efl.Ui.Stack and Efl.Ui.Pager are totally different containers so they cannot be supported by one class.
As I mentioned before, Efl.Ui.Stack is responsible for navigation with depth. (I would say the context is changed.)
In contrast, Efl.Ui.Pager is more like a list.

Efl.Ui.Pager tends to be used to generate all its pages once and shows all pages.
So Efl.Ui.Pager requires "current_page" to pick a page to be displayed on the screen. It requires pack() and current_page_set().
However, Efl.Ui.Stack tends to be used to generate a view when a new context begins and delete view when the context finishes.
So Efl.Ui.Stack does not require "indicator", "current_page" and top view is displayed on the screen. It only requires push().

Here is very similar example in qt. (StackView vs SwipeView)
https://doc.qt.io/qt-5/qtquickcontrols2-navigation.html
The required methods and properties are totally different and it would help developers understand how those classes work.

Why shouldn't it be possible to move indicator and page_size to the transition object ? The only difference to this is that it removes this feature from other smart_container users, which is a total loss in my opinion. But if it is a requirement to get features out of widgets and make them private to one transition-implementation, then i can surly move it out. The smart_container does not know anything that a transition object does not know. Every single state change is told to the transition object. Whenever you implement something in the widget class itself, you can also just implement it in the transition object. I cannot understand where the fear is coming from that this is not possible.

I understand that you think those two widgets are different, and they are when it comes to displaying/animating. But the basics of managing the children are the same, with the difference that one uses a inlist and the other uses a list. Everything else is the same.

Your usecase with Efl.Ui.Stack is perfectly possible with what is there in smart_container, you can just pack it at position 0, and set the current page to it. This will result in the same visual appearance. If this is too much work, then we can also just add a property "current_page_fixed" which will remove the automatically page adjustment, so you can perfectly build your stack, just like before.

Thank you for this link to QT. SwipeView and TabView inherit both from container (https://doc.qt.io/qt-5/qml-qtquick-controls2-container.html) which is something like the smart_container here, just without indicator. It even has currentIndex. I cannot tell you why StackView here does not have something like the current index. However, take a look at android, there you just pass a BaseAdapter to the StackView, which also has a current position, and not a fixed position to 0. In general i would claim that good tutorials + similar interfaces on similar objects would make the whole toolkit easier to understand and learn.

@bu5hm4n

I think there are some misunderstandings between us.

About moving "indicator" and "page_size" to "transition" class

  • I mentioned that "I don't think that those properties can move to "transition" class. (they look like "container" features)"
  • Based on the class name, developers assume that "transition" class handles "transition", "animation". IMHO, the properties "indicator" and "page_size" do not belong to "transition" or "animation". But they look like "container" properties so I think that those properties should not stay in Transition class but they should stay in Efl.Ui.Smart_Container if they should exist.

About SwipeView and StackView

  • I mentioned that "Here is very similar example in qt. (StackView vs SwipeView)"
  • I did not mention about TabView but I mentioned StackView because Efl.Ui.Stack is similar to StackView. And as you know, StackView does not inherit from container unlike SwipeView.

My worry is adding more and more properties/methods to Efl.Ui.Smart_Container to support features. As you mentioned "current_page_fixed", it tends to add more and more properties and methods to Efl.Ui.Smart_Container to support easier usage and to support new features.

In this case, Efl.Ui.Smart_Container should support at least more than 1 existing container usage (Efl.Ui.Stack and Efl.Ui.Pager). Therefore, unless the existing container usages are exactly the same, there would be properties and methods which are not required to other container class. This would lead Efl.Ui.Smart_Container class more complex and not well organized.

bu5hm4n added a comment.EditedThu, May 9, 2:28 AM

About moving "indicator" and "page_size" to "transition" class

  • I mentioned that "I don't think that those properties can move to "transition" class. (they look like "container" features)"
  • Based on the class name, developers assume that "transition" class handles "transition", "animation". IMHO, the properties "indicator" and "page_size" do not belong to "transition" or "animation". But they look like "container" properties so I think that those properties should not stay in Transition class but they should stay in Efl.Ui.Smart_Container if they should exist.

How about we rename the Transition class to something else, so that the developer expects this kind of stuff there ? (like VisualizationFacade)

About SwipeView and StackView

  • I mentioned that "Here is very similar example in qt. (StackView vs SwipeView)"
  • I did not mention about TabView but I mentioned StackView because Efl.Ui.Stack is similar to StackView. And as you know, StackView does not inherit from container unlike SwipeView.

    My worry is adding more and more properties/methods to Efl.Ui.Smart_Container to support features. As you mentioned "current_page_fixed", it tends to add more and more properties and methods to Efl.Ui.Smart_Container to support easier usage and to support new features.

I cannot really understand this worry, so lets say there is a widget where a lot of features are requested. Then this widget will get very complex. Yes. If a lot of features are requested for smart_container then this is the case. True. But this situation does not change based on what kind of widget it is. The difference with this widget is just, that multiple container-content bound features can be implemented at once. So the replacement Efl.Ui.Stack / Efl.Ui.Pager and maybe Efl.Ui.Flip would benefit from this. And we would safe a lot of tests / Code to write, as features will be there automatically. Additionally, for a tizen developer, its way easier to implement theire own animations, and pass this object to the smart_container.

On an additional note the smart_container features are:

  1. The transition object (and the correct calling)
  2. The indicator object (and the correct calling)
  3. Maintaining a index of the current index
  4. Handling custom page sizes

The extending of 1. and 2. should be rather easy. However, i cannot think of another case that you want to pass to those objects, basically everything is covered.
Maintaining the index here could be extended with two "sub" features,

  1. freeze the index, current index will stay, undependend from if there is new content or not.
  2. index gravity, when the current content is deleted, what do to ? Go right ? Go left? (there is actaully no other possibility)

I cannot see what else of the current features would be able to be extended. I don't have any case in mind. Additionally, i can also see that someone just wants to have the stack animation, but with page_maintaince. Think about the old slideshow widget here. I really believe that this widget here gives us a great possibility to allow new animations, without adding complete sets of widgets.

EDIT: sorry i had to edit this, i hit enter to early.

@Jaehyun_Cho

@segfaultxavi and I have been brainstomring about a new name for this. We came up with the following scheme:

Efl.Ui.Single_Display.Container -> The container itself, what Efl.Ui.Smart_Container is right now
Efl.Ui.Single_Display.ViewManager -> manages the animation / user interaction / can manage additional stuff and settings.
Efl.Ui.Single_Display.Indicator -> What Indicator is right now

What do you think ? IMO this expresses better what it does, and a page_size on a ViewManager sounds more realistic then on a transition object.

@bu5hm4n

I think the idea which attaches transition to container is great.

What do you think about inheriting Smart_Container to other containers? (not using Smart_Container itself directly)
e.g. class Efl.Ui.Stack extends Efl.Ui.Smart_Container
(we can change or add the namespaces and class names)

Then, each widget containers can contain its own container property.
e.g. Efl.Ui.Pager contains indicator property

The class hierarchies are as follows (based on the current names)

abstract Efl.Ui.Smart_Container
class Efl.Ui.Stack extends Efl.Ui.Smart_Container
class Efl.Ui.Pager extends Efl.Ui.Smart_Container
abstract Efl.Ui.Smart_Container_Transition
class Efl.Ui.Smart_Container_Transition_Stack extends Efl.Ui.Smart_Container_Transition
class Efl.Ui.Smart_Container_Transition_Scroll extends Efl.Ui.Smart_Container_Transition

What do you think?

bu5hm4n added a comment.EditedFri, May 10, 1:54 AM

Mhm, i am not so sure about adding indicator only to the pager, i would like to keep it in the smart_container. Take a look at https://git.enlightenment.org/core/efl.git/commit/?h=devs/bu5hm4n/work3&id=eb84d7dd326d51c7fb9756d16573002cddb066cb
This is a example which uses the stack animation while using a indicator and the page index. This seems to me really useful to me. Creating a slideshow was a matter of 5 min. here.

I like your idea of inheritance to some extend. However, this wakes the fear that features which are animation / visualization related might end up in the Stack/Pager implementation, while it should be in the animation itself.
What do you think of something like this:

class Efl.Ui.Smart_Container.Util:
   @class stack : Efl.Ui.Stack_Container : This functions returns you a ready configured object which can be used just like a created stack object.
   @class pager : Efl.Ui.Stack_Container : The same as above, just for pager.

(I would also put this into the new namespace I have proposed above)

With this way we could enforce separation between concerns in the code itself. Which should lead to a clearer interface and cleaner code. And we keep a easy way of testing features, since its only one widget that manages content / or only one place, where the visualization is done.

class Efl.Ui.Smart_Container.Util:
   @class stack : Efl.Ui.Stack_Container : This functions returns you a ready configured object which can be used just like a created stack object.
   @class pager : Efl.Ui.Stack_Container : The same as above, just for pager.

Do you mean Efl.Ui.Smart_Container.Util has static @class @property "stack" and "pager"?

@Jaehyun_Cho

@segfaultxavi and I have been brainstomring about a new name for this. We came up with the following scheme:

Efl.Ui.Single_Display.Container -> The container itself, what Efl.Ui.Smart_Container is right now
Efl.Ui.Single_Display.ViewManager -> manages the animation / user interaction / can manage additional stuff and settings.
Efl.Ui.Single_Display.Indicator -> What Indicator is right now

What do you think ? IMO this expresses better what it does, and a page_size on a ViewManager sounds more realistic then on a transition object.

I don't know the meaning of the namespace Single_Display here.
If there is a specific meaning or intention, then could you explain to me?

BTW, what about using namespace "Container"?
e.g. Efl.Ui.Smart_Container -> Efl.Ui.Container.Object

bu5hm4n added a comment.EditedFri, May 10, 3:21 AM

I mean something like this:

class Efl.Ui.Smart_Container.Util {
   methods {
      stack @class {
         [[ Create a ready to use stack ]]
         return : Efl.Ui.Smart_Container;
      }
      pager @class {
         [[ Create a ready to use pager ]]
         return : Efl.Ui.Smart_Container;
      }
   }
}

Where both methods just return a ready configured Smart_Container, with the already setted transition object, (and probebly the fixed page property that does not exist yet).

About the namespace: We have choosen Single_Display because the this widget has a set of widgets where at one certain point of time (outside any animation), only *one* widget has the main-view. Maybe more of them are displayed for visualisation reasons (like pager) but in general, only one element "has" the display.
We also had Container on our list, but we decided against this, because a List or Grid is also a container, but this container is different, we wanted to express this in the namespace.

I don't know the meaning of the namespace Single_Display here.
If there is a specific meaning or intention, then could you explain to me?

BTW, what about using namespace "Container"?
e.g. Efl.Ui.Smart_Container -> Efl.Ui.Container.Object

We thought that Smart_Container and Transition were confusing names so we came up with this proposal:

  • Single_Display is the namespace were the new container and the "transition" objects reside. As @bu5hm4n was explaining, this name means that this widget contains multiple sub-widgets (or pages) but only ONE is displayed at a time. This works for Pager, Stack, Flip, etc.
  • Single_Display.Container is what was called "Smart_Container" before. I don't like calling things "Smart" because it gives no information on what this thing does.
  • Single_Display.ViewManager is what was called "Transition" before, and it was confusing because it also takes care of layout and user interaction. This object is the only thing that separates a Pager from a Stack. It takes care of positioning the pages (the layout) and animating the transitions (if required).
  • Single_Display.Indicator shows an indicator of the current page. This widget has many sub-widgets and only ONE is displayed, so an indicator will always make sense. The ViewManager can use the "little dots" indicator (as the pager), or create new indicators (like text breadcrumbs, for example) or decide to hide the indicator completely.

I would like to start using these new names as soon as possible (if you like them!), because the old ones have already confused too many people.
I am afraid Efl.Ui.Container is too similar to Efl.Container.

About Single_Display, now I understand your point. However, at least I needed your explanation to understand the meaning of it.

IMHO, intuitive name and usage is very important. I think this is why the same or similar names and terms are normally used. But I don't think Single_Display is one of them.

Moreover, Pager can show 3 pages at the same time now. What if it would be required to show more pages at the same time..?

Beyond the name of Single_Display, I still think that we should separate Pager and Stack.

Each widget is implemented based on its UX which is defined by the widget's requirements.

About indicator which is defined in Smart_Container, the Stack(Naviframe) UX does not define indicator (at least I haven't seen a stacking container which supports indicator in other platforms as well).

Because Stack(Naviframe) works based on depth in/out and indicator displays all the components(pages) in the same level(depth).

If we only have Smart_Container to support both Pager and Stack usecases, then we should support indicator for Stack usecase as well (i.e. if a developer calls indicator_set() for Stack then it should work) although there is no UX defined.

The resulting widget is still defined by its UX. The Smart_Container does not really contain UX. The only reason the implementation has placement code is that otherwise the standard config of the widget would not display anything. But other than that, the UX is meant to be in the transition object. So with the smart container, the UX is implemented in the Transition object. But defined via setting the UX object onto the smart_container. Which means, the transition object is the pure UX implementation, no need for widget management code.

Let me put it this way:

  • The Transition object is defining the UX: how the user can interact with the displayed content and how the current_page content is displayed
  • The indicator object is defining the UX for displaying the overall state of the widget (current page and number of pages, for example)
  • The widget itself does not define any UX at all.

It does not really matter if Stack has a UX defined for the Indicator or not. If the API user requires a indicator UX on this widget, then he can set it. Otherwise, he does not set it. Take a look at the example I linked above. The Stack animation does make sense here, and the indicator also does. The interaction between the smart_container and the indicator is done via a API calls. The indicator does not need to have a defined UX, instead you derive a class from it and implement the UX there.

And as i said 7 times before: If a transition implementation wants to have a custom feature, then it can be simply added to this object. There is *no* harm in adding a new property for enabling this behavior on the Smart_Container.Transition_Scroll (The Pager-Style Transition) object again. For instance, if you wanted a pager with more than 3 pages, you can add a number_of_pages property to the transition object.

@Jaehyun_Cho I've taken some time to read through this, and I think a lot of confusion is due to the naming. What do you think about:

Efl.Ui.SmartContainer -> Efl.Ui.ActiveView

Then we have Efl.Ui.ActiveView.Manager which is a base class to be inherited from in order to create e.g., Efl.Ui.ActiveView.StackManager, Efl.Ui.ActiveView.PageManager, Efl.Ui.ActiveView.FlipManager. These derived classes would then implement the widget-specific behaviors for each of these. We can go over all the method names and such to be consistent with this terminology as well in order to avoid any confusion.

There would also be the indicator class which can be used by the derived manager classes (or not) to handle indications about the state of the manager. It would be up to each manager to handle implementations of this, and managers which don't implement it can just trigger error fallthroughs as is normal for unimplemented eo methods.

Overall I think this is a good effort to reduce code duplication across the widget toolkit and improve the maintainability of the codebase. We should try to find more cases where we can consolidate code from many widgets into a single widget with different visuals.

@bu5hm4n

I think you understand me that I do not want to make argument but I also want to make our widgets better than now like you :)
I asked @Hermet a piece of advice about this concept and I realized some of my assumption may not be right from other point of view.

I assumed two things.

  1. Efl.Ui.Stack is a container which changes contexts with depth in/out but Efl.Ui.Pager is not.
  2. Indicator is not suitable for Stack.

About 1,

  • Since we do not have a strong container or system controlling depth in/out like Android's activity, Efl.Ui.Stack and Efl.Ui.Pager may be more or less same.

About 2,

  • Because of the comment on "About 1", it is meaningless to distinguish Stack from Pager.

Based on the above, I agree with the concept of this patch. I am sorry that it takes much time to discuss about the concept of this patch.
Since the name "Stack" is meaningless here (we do not use push/pop), we may not need to preserve the name "Stack" to any class in this concept.
I hope we can find the best names for these classes :)

@zmike

Thank you for your opinion and suggestion.
I think there are more candidates something like Efl.Ui.ViewContainer.
Let's listen to other people's opinions :)

No problem :)

So as I see things, we have the following action items:

  • Find new names for all this, and rename it
  • The index gravity thing i was speaking about above, this should make it fairly easy for using it like the stack right now.
  • Writing tutorials about how to write those things that are called transition objects right now.

Anything else ?
I will start this work this week and try to get everything ready until friday.
Patches for adjusting the rest of the codebase, and the removal of stack and pager will follow up.

@bu5hm4n

I think we need to consider the lazy loading method or event callback.
This can be separated into the following 2 scenarios.

  1. Smart_Container should pack too many views
    • I think there are 2 solutions.
      1. Provide events when the view is ready to be displayed or starts to be displayed
        • Developer packs view when they want to show the view.
        • We may use "transition,start" for this case. But it may not be sufficient or the event name is not suitable for this case.
      2. Provide a fixed function something like genlist's content_get()
        • Developer defines a fixed function something like genlist's content_get() and that function is automatically called when the view starts to be displayed.
        • Cons : This may make Smart_Container more complex.
  2. Packed view loads heavy data (e.g. from database) or sets heavy contents (list widget with too many list items)
    1. Provide an event when the view is ready to load data not to decrease animation frame
      • Developer sets small amount of data before starting view transition and sets full amount of data in the event occur.
      • We may use "transition,finished" for this case. But it may not be sufficient or the event name is not suitable for this case.

@Jaehyun_Cho I really like this idea! JP started a concept for this a while back: https://phab.enlightenment.org/T6265 I think this does make a lot of sense. And should be applied, as this can be beneficial for other widgets as well. I will add this as a task once the main widget has hit master. We still can extend it. I want to focus on the mainfeatures for now. So we can merge this sooner than later :)

bu5hm4n updated this revision to Diff 22216.Wed, May 15, 8:15 AM
bu5hm4n retitled this revision from efl_ui_smart_container: introduce a experimental new widget to efl_ui_active_view: introduce a experimental new widget.
bu5hm4n edited the summary of this revision. (Show Details)
  • rename the widget
  • add gravity API
  • add example
  • add tests for gravity API
bu5hm4n updated this revision to Diff 22218.Wed, May 15, 9:07 AM

update docs

bu5hm4n updated this revision to Diff 22224.Wed, May 15, 12:05 PM

correctly namespace everything

bu5hm4n updated this revision to Diff 22236.Thu, May 16, 12:17 PM

add a few fixes

bu5hm4n updated this revision to Diff 22259.Sun, May 19, 4:00 AM

general update

Sooo, with this latest update, this is in the final state. Is there anything i have missed?
The following commits do replace the existing widgets with this widget. I ported over the test codes, i was not totally sure about the stack test how it is supposed to work. There is also one bug in the stack widget test that i am currently trying to hunt down, it has to do with DEL events not beeing fired.