[E-devel] Ecore Docs Examples
Patch to add some examples and modules to the documentation. Or rather, add specific sections for the two. Most examples pulled from pre-existing documentation, but made to work on their own. Also removes all tags that were giving warnings. Fixes up some doxygen syntax. This is not at all complete. There are more examples to extract and write, and more modules to write up. The examples directory is the examples.tar.bz2 file. It includes a Makefile.am, with the necessary modifications to the ecore Makefile.am in the diff. http://home.bigblue.net.au/quasar/ecore-more-docs.diff.bz2 http://home.bigblue.net.au/quasar/examples.tar.bz2 Regards, Nicholas --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Some thoughts on edje
Reading through e17's cvs, I found edje, and it looks cool. Here's some
thoughts and ideas I had. Sorry if any of it seems terribly n00bish, but I'm
new to E coding :)
-- Shish
~~
It seems that edje only works for single apps - are there any plans to make a
set of generic widgets, so that you can theme one widget rather than every type
of button in every app?
Similarly, having a program to set a button's new colour, and another program
to reset it, for every button in every app, will be tiring. Much better would
be to have a basic type that components can inherit from.
Thinking through a third time - there'd better be some generic widgets to
inherit from; forcing every theme to create it's own comboboxes and the like
will put a lot of people off. Creating something like a combobox using just
image, rect, text, and miniture programs will be neigh on impossible.
collection generic {
part button {}
part scrollbar {}
}
collection eplayer_specific_parts {
part musicDisplay {}
}
collection entrance_specific_parts {
part WM_choice_display {}
}
That way, most apps who only use generic parts can be themed with the same .eet
file.
~~
The formatting of entrance's readme.edje breaks for people who don't use
8-space tabs :/
Also, I don't think swallowed is the word you want...
~~
Procedural / generated textures would work nicely alongside the IMAGE class:
images {
image, background.png LOSSY 95;
texture, wood.gen wood #88 #DD;
}
will use the wood generator, with the specified colours, to create an image
on the fly (either compile or run time). Blender has a lovely selection of
procedural texture generators to learn from :)
Having a generated animated texture would be very tasty eyecandy (see the
backgrounds in the ZSNES main screen for a demo). The only use I can see is for
entrance backgrounds - it'd be annoying to have animated buttons while you're
trying to work. Flames, steam, snow, etc, would make lovely login screens.
~~
How are resizable things themed? Will the .edc need to manually place bitmaps
for N, NE, E, etc, or will a single bitmap be supplied, and edje will
automatically cut out each edge and the center? or something else entirely?
ED Is this what the border attribute of description is for?
~~
IMHO,
] part {
]name, foo;
]type, TEXT;
could be nicely shortened to
] part foo {
]type, TEXT;
~~
Making a glade-like thing that outputs .edc files would kick ass
~~
Allow variations for colour defentions as well for edc files, and allow an
ommited alpha to mean 255 -
color, 170 89 214 255;
color, 0xAA59D6FF;
color, #AA59D6;
color, #A6D;
~~
On alignment:
which effect will setting alignment to 0,0 have?
OOOXX -- pushed into the corner
OOOXX
OOOXX
X
OOO -- centered on the corner
OOOXXX
OOOXXX
X
X
I should think that pushing things to a point would be better than centering
them on it.
~~
Part grouping:
Yes, I am an object orientedness whore :P
The prefix command simply adds a prefix to all the names of components within
- it should be a quick job in the .edc parser / compiler, and not require any
changes to anything else.
prefix playbutton {
part rect {
}
part text {
}
}
prefix stopbutton {
part rect {
}
part text {
}
}
vs
part playbutton_rect {
}
part playbutton_text {
}
part stopbutton_rect {
}
part stopbutton_text {
}
~~
edje_api.xml: 122: seutp - setup:
/* If so, seutp the audio out path */
edc_tour.xml: 375: is no - are no:
there is no restrictions
edc_ref.xml: 132: line broken badly
SOFT_SHADOW, OUTLINE_SH
ADOW, OUTLINE_SOFT_SHADOW
-
SOFT_SHADOW, OUTLINE_SHADOW, OUTLINE_SOFT_SHADOW
216: visable - visible
382: 3.0 - 2.5, preformed - performed
the second argument specifies the maximum random delay which is added to the
first argument. This is useful when you want the program to wait for a random
amount of time that is at least a half a second but no more than 3 seconds,
which would be described as in, 0.5 3.0;. Delays always occur before the
action specified by the program is preformed.
the second argument specifies the maximum random delay which is added to the
first argument. This is useful when you want the program to wait for a random
amount of time that is at least a half a second but no more than 3 seconds,
which would be described as in, 0.5 2.5;. Delays always occur before the
Re: [E-devel] Some thoughts on edje
On Thu, May 06, 2004 at 12:26:00PM -0700, Shish wrote: Reading through e17's cvs, I found edje, and it looks cool. Here's some thoughts and ideas I had. Sorry if any of it seems terribly n00bish, but I'm new to E coding :) -- Shish ~~ It seems that edje only works for single apps - are there any plans to make a set of generic widgets, so that you can theme one widget rather than every type of button in every app? This is part of the idea behind EWL. It uses edje for theming and provides a generic widget set. As usual, it's still a work in progress. There is also some work being done in creating templates for standard widgets in custom apps. For instance the filedialog and entry that atmos put in esmart. If you want a consistent look and feel between apps, then EWL is the way to go. If you want to have custom themes for your app, then the edje templates are probably more what you want. Good luck! -- | Nathan Ingersoll \\ Computer Systems Network Coordinator | | [EMAIL PROTECTED] \\ http://www.ruralcenter.org| | http://ningerso.atmos.org/ \\ Rural Health Resource Center | signature.asc Description: Digital signature
[E-devel] [OT] pass by reference problems
I'm sorry about this email, it is quite off-topic, but I know a lot of
good hackers hang out here, and I'm quite stuck on this little problem.
I have been going at this problem from a multitude of angles, and I
settled on using pass-by-reference after trial and error with returning
char*
this code;
#include stdio.h
#include iostream
void test(char ***foo) {
**foo = strtok(test1,test2,,);
}
void test2(char ***foo) {
**foo = Spin the big yellow thing;
}
int main() {
char ** bar;
test2(bar);
printf(%s\n, *bar);
test(bar);
printf(%s\n, *bar);
return 0;
}
in this;
results Spin the big yellow thing
Segmentation fault
If anyone can give me a tip about why this segfaults when using strtok,
I'd be very happy :)
I have no backtrace, as my system doesn't have gdb installed, but I will
install it later on (tomorrow) if I get a chance.
Cheers,
--
Morten
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [E-devel] [OT] pass by reference problems
On Fri, 07 May 2004 01:48:29 +0200, Morten Nilsen [EMAIL PROTECTED] said: **foo = Spin the big yellow thing; results Spin the big yellow thing Segmentation fault If anyone can give me a tip about why this segfaults when using strtok, I'd be very happy :) Subtle bug. ;) First, we point **foo at a copy of the string. Then we call strtok() on that string. Two things to note: 1) strtok *modified* the string to keep track of its state between calls (so it knows where to pick up parsing on the next call). 2) gcc by default will put string constants in a non-writable memory segment so they can't be accidentally splatted. Solutions: 1) **foo = strdup(Spin the big yellow thing); This will malloc() some space, copy the string into it. Remember that for good programming practice, you will need to free() that string if/when you're done with it. 2) If using gcc, compile with -fwriteable-strings. This doesn't fix your real problem, but at least you won't crash. pgp0.pgp Description: PGP signature
