The next is a simple example of splitting EDC:
group { "elm/button/base/default";
parts {
rect { "base"; }
alias: "elm.text" "elm.label:elm.text";
swallow { "elm.label";
rel1 { to: "base"; offset: 10 10; }
rel2 { to: "base"; offset: -11 -11; }
}
rect { "event"; }
}
programs {
program { name: "onPressed";
signal: "mouse,down,1*";
source: "event";
action: SIGNAL_EMIT "elm,action,button,press";
target: "elm.label";
}
}
}
group { "elm/button/label/default";
parts {
text { "elm.text";
text {
... attributes for text part ...
}
}
}
}
When new button is added, it creates Elm.Layouts for customizable parts,
and swallowed in base layout. In above example, layout set by group
"elm/button/label/default" would be swallowed by "elm/button/base/default".
Swallowed label should receive signals from parent object to change its
state like "pressed", "disabled".
As others mentioned, I know that splitting EDC into several groups will
increase complexity and harm readability, but also can allow flexibility on
customizing default theme. At this moment, Elm.Button with "default" style
always expand width along with the length of its label, but there's no way
to make button not expand but have ellipsized text without writing full
button's EDC.
If this is applied, developers should have convenient macros for the next
lines.
Evas_Object *label = elm_layout_add(parent);
elm_layout_file_set(label, "xxx.edj", "custom_label");
elm_layout_content_set(parent, "elm.label", label);
=> elm_object_part_file_set(parent, "elm.label", "xxx.edj",
"custom_label");
We can allow this for Edje Externals only, or make complete "default" style
and incomplete "custom" style having customizable swallow parts for this
usage only. I don't think that this is the best or even better way than
now, but I want to listen to others' opinions about customizing widget.
With edje_edit APIs, I could change edje part's attributes dynamically,
jpeg said that they are NOT intended to be used at runtime but only for
editor application. In summary, if we want to have a way to handle our
objects dynamically, we should proceed to bob. Because many things we need
are not allowed in current design.
I searched for an information for bob, but there is only one post in our
wiki that was written more than 1000 days ago. I'm not familiar with LUA
script, but can grasp its points roughly. I hope to participate in
developing bob soon to end these continuous complains. :D
Regards,
conr2d
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
