[E-devel] libast from current CVS failed to build!
OK. Did I miss out something? Libast has been working fine till today. (Log attached) -- With kind regards, Didier. Yum/apt repository for DR17/EFL: http://sps.nus.edu.sg/~didierbe ([EMAIL PROTECTED]:libast-0.7.1)$ ./autogen.sh Generating configuration files for libast, please wait + libtoolize -c -f You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'. + aclocal -I . configure.in:50: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from... configure.in:50: the top level configure.in:55: warning: AC_CANONICAL_HOST invoked multiple times autoconf/specific.m4:363: AC_CYGWIN is expanded from... libast.m4:286: AST_STD_CHECKS is expanded from... configure.in:55: the top level configure.in:55: warning: AC_ARG_PROGRAM invoked multiple times + autoconf configure.in:50: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from... configure.in:50: the top level configure.in:55: warning: AC_CANONICAL_HOST invoked multiple times autoconf/specific.m4:363: AC_CYGWIN is expanded from... libast.m4:286: AST_STD_CHECKS is expanded from... configure.in:55: the top level configure.in:55: warning: AC_ARG_PROGRAM invoked multiple times + autoheader configure.in:50: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from... configure.in:50: the top level configure.in:55: warning: AC_CANONICAL_HOST invoked multiple times autoconf/specific.m4:363: AC_CYGWIN is expanded from... libast.m4:286: AST_STD_CHECKS is expanded from... configure.in:55: the top level configure.in:55: warning: AC_ARG_PROGRAM invoked multiple times + automake -a -c configure.in:50: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET autoconf/general.m4:1657: AC_CANONICAL_TARGET is expanded from... configure.in:50: the top level configure.in:55: warning: AC_CANONICAL_HOST invoked multiple times autoconf/specific.m4:363: AC_CYGWIN is expanded from... libast.m4:286: AST_STD_CHECKS is expanded from... configure.in:55: the top level configure.in:55: warning: AC_ARG_PROGRAM invoked multiple times configure.in: installing `./install-sh' configure.in: installing `./missing' src/Makefile.am: installing `./depcomp' + ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for preferred libtoolize... libtoolize checking for preferred aclocal... aclocal checking for preferred autoconf... autoconf checking for preferred autoheader... autoheader checking for preferred automake... automake checking build system type... i686-redhat-linux-gnu checking host system type... i686-redhat-linux-gnu checking target system type... i686-redhat-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for a sed that does not truncate output... /bin/sed checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... g77 checking whether we are using the GNU Fortran 77 compiler... yes checking whether g77 accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works...
Re: [E-devel] E CVS: libs/imlib2 sebastid
Ok, so now we have (in imlib2) EAPI for public functions and __hidden for private functions. Unless I'm missing something one of those should go. Why shouldn't both stay? I compiled with -fvisibility=hidden, and then a public identifier is required. Without a private identifier is needed. Sebastian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas premul changes
Jason writes: Much ado about gradients, but hopefully all this will make it easier to work with grads in current edje and otherwise. Forgive me for chiming in when I haven't read the full thread nor grokked the context, but does any of your work allow being able to set gradients as clipping objects? The ability to clip a text object with a gradient to allow fading text out is something I've wanted to be able to do for a long time. :) Cheers, Jason. The short anwser is no. Only rectangle objs work as clip objs in evas at this time. The longer anwser is that yes, there is a way you can do this right now - if you use a buffer evas for your text output. You would setup your buffer evas (make sure it's set to have-alpha). Then add your text obj and add a suitable grad obj on top of that -- AND set the grad obj's render-op to EVAS_RENDER_MUL. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Continuing the website saga
On Wed, 13 Sep 2006 10:32:00 +0100 Andrew Williams [EMAIL PROTECTED] babbled: OK - I have been waiting for the dust to settle (too much email to handle!) :) I will summarise what I think the WEBSITE needs (regular builds with errors are orthogonal to the WEBSITE - they can output web pages to be linked to though...). The list of what we have and what handles it currently, do they need user auth. 1. news posting - summaries on front page (XSM, auth) 2. content creation and editing (XSM, auth) 3. forums (drupal, auth) 4. bug db/reporting (mantis - i think, auth) 5. on-disk file repo for download (custom PHP) 6. documentation (XSM, auth) 7. webcvs (kevb/webcvs) 8. user uploads of themes etc. (XSM - done by hand, auth) we, as dan pointed out, need to unify authentication/user info - we can't go and have all the systems separate. they need to be unified - 1 login. frankly - i think we need to either look at making XSM do all of the above, or we need to canvas for a solution that does all of the above for us already. we do not need to go write our own cms/wiki/whatever we are not in the business of building websites. we are in the business of writing code. the website is a means to an end. xsm has served well - and i am happy to keep using it - if we can accomodate what we need easily. the bits not needing auth can be put in with XSM - those not using XSM and needing auth are the problem. so - we 1. bring xsm up to speed and merge everything in and do all that work 2. we look for an alternative (if one exists) 3. we write our own (oh bloody hell i hope not!) 4. we keep depating this until we all get bored and find something better to do. so our 2 real possibilities are 1 2. so - let's look at this in parallel. what are our chances of 1. and gettign xsm to manage things so we can have forums, bug tracker, etc. etc. cleanly (and our list of issues with xsm) and what are our alternatives - wiki's with bug trackers (trac?)? trac is very limiting in the page content land - if u want simple things its fine, but otherwise is lacking. twiki i understand is better BUT not sure about adding bug trackers etc. drupal is a monster. what about forums combined with these?... dan sinclair wrote: Hello, Ok, haven't got a lot of responses (not that I gave it a huge amount of time, I'm inpatent) but, a follow on email to what we want out of the site. How do we get it. Lets us assume, for now, XSM is our CMS of choice. It will handle the static pages for all 'normal pages'. It will handle the news page (which, will hopefully be able to be displayed on both the home page for 2-3 articles and in the news page, Handy?). sure thing. Any list based page can be summarised using simple markup which can be inserted into something like the front page using the template system. The FAQ will be XSM. If we want to hook up for the user to download the faq to their system we can grab the .xml file XSM generates and post process if needed (Handy, can we hook post processing scripts in so after a page is written out, fire script?) and stick this into specific spots in the webserver. post processing is not currently available as a hook, but you can look at mtime values on files. perhaps RSS might be useful here? The main docs pages will be in XSM. The API docs will be generated from CVS, with links from XSM. The other docs that are in CVS will also be autogen'd on commit with links from XSM. That make sense as a starting point? yup :) So, what does that leave us with to sort out. 1- User forums. The easiest is to grab something previously created and use that. There are two issues. a) do we want to migrate data from edevelop, if so, how. b) user authentication. We want this to have the same authentication as XSM. So, we'll either need to modify this in the forum software, or do some fancy footwork. (XSM writes its user db and we parse that into the forum db, or into LDAP or something?) XSM does want to use LDAP, perhaps this would be the push it needs :) 2- Wiki. Do we want a user wiki? Something for users to put their info on, put up a page for their efl apps, or their theme they're working on. If we want this, again, how do we integrate the user database with XSM. Probably a similar issue as 1. Which Wiki software do we use? Mediawiki? 3- Bug database. Basically same as above. How to integrate users, which bug software to use. We currently use Mantis. Do we stick with that? (Losing the current bug data is unacceptable so if we go to something else we _have_ to migrate.) I personally like mantis, though I have grown to love Trac ;) 4- Release directory list. It sounds like we can hook php into XSM. This page will then just be controlled by XSM. (Assuming I'm correct on the XSM php front.) Yeah, sure thing - if you want the file list
Re: [E-devel] e17 segfault
On Tue, 12 Sep 2006 17:46:47 +1200 Jochen Schroeder [EMAIL PROTECTED] babbled: Hi guys, I just experienced an e17 segfault. It happened when I was trying to save something from seamonkey. I was actually trying to save over another file, when I hit the replace button in the are you sure you want to save over file ... dialog I got the segfault dialog, however I cannot reproduce this at will. CVS as of today. Backtrace attached. Cheers this shouldn't happen any more now. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] xrender_x11 engine: identity transform workaround
On Tue, 12 Sep 2006 10:54:05 +0200 Tilman Sauerbeck [EMAIL PROTECTED] babbled: Carsten Haitzler [2006-09-12 09:01]: On Mon, 11 Sep 2006 19:55:28 +0200 Tilman Sauerbeck [EMAIL PROTECTED] babbled: I just fixed xorg-server so that setting a scaled variant of the identity is a no-op, too. That means if you pass the identity to XRenderSetPictureTransform(), the function will just exit and not use any transform at all. even if it set the identity - i would expect the xserver-side to go ooh look- identity transform! ... NOP! :) That's what it's doing now. This might expose a in the render implementation raster experienced the source-depth == 1 bug in. I'd like to remove the FIXME and that chunk of code, since it's officially pointless. Should we really work around stupid driver bugs? It also won't work in xorg 7.2+ :D if this actually has a chance of being fixed in xorg soon - yes - remove... ONCE that xorg is out and about with the fixes :) so... if it goes into xorg git - then change the fixme to added to xorg git some/date/2006 - expected in release 7.x and once we encounter that release in the wild - flip over... or make it a #ifdef broken_xrender too :) That sucks. Hiding bugs sucks. Even if they are in xorg or in NVidia's drivers. sure - but having things not work while we wait is bad too - since it's now a #ifdef - i will just turn it off - at some point. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas / svg configure issue and solution
On Thu, 14 Sep 2006 14:42:07 -0500 (CDT) D. Hageman dhageman@dracken.com babbled: in cvs :) I am going to send along this patch again because changes some changes were made to the configure.in file, but they weren't the *right* changes. This should solve the SVG issues for the Fedora/Redhat platform. On Mon, 11 Sep 2006, D. Hageman wrote: Attached is a patch that should fix this once and for all. On Wed, 30 Aug 2006, D. Hageman wrote: On Thu, 31 Aug 2006, Carsten Haitzler wrote: On Wed, 30 Aug 2006 13:27:34 -0500 (CDT) D. Hageman dhageman@dracken.com babbled: I mentioned before the weekend that I was having some issues with the SVG in evas with Fedora Core 5. I finally found the time to investigate the issue some more, but I am not sure how to fix it. Essentially this solves the problem: 944c944 PKG_CHECK_MODULES(CAIRO_SVG, cairo-svg, --- PKG_CHECK_MODULES(CAIRO_SVG, libsvg-cairo, Fedora Core calls their cairo-svg ... libsvg-cairo. I am not well versed enough in autofoo to make both of those happy. in cvs - check that it's working for you. Still not completely happy yet ... In file included from evas_image_load_svg.c:4: /usr/include/librsvg-2/librsvg/rsvg-cairo.h:28:19: error: cairo.h: No such file or directory In file included from evas_image_load_svg.c:4: /usr/include/librsvg-2/librsvg/rsvg-cairo.h:33: error: expected declaration specifiers or '...' before 'cairo_t' /usr/include/librsvg-2/librsvg/rsvg-cairo.h:36: error: expected declaration specifiers or '...' before 'cairo_t' I will try to get some time tomorrow to do more investigation if you don't have any ideas of the top of your head. I appreciate you looking into this. -- //\\ || D. Hagemandhageman@dracken.com || \\// -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Colormap issues in ecore_x_window_argb_internal_new()
On Sun, 10 Sep 2006 20:11:03 +0200 Tilman Sauerbeck [EMAIL PROTECTED] babbled: Hi, when ecore_x creates an window with an ARGB visual, it creates a colormap for that visual (ecore_x_window.c:973). This colormap is evaluated by XCreateWindow() etc. Afterwards, when the window has been set up, the colormap is freed (line 1010). So now the colormap field in the XSetWindowAttributes structure of the window points to a freed chunk of memory. aaah first. colormaps are id's not pointers. :) so they are server-side resources. this is safe BECAUSE then the window has a REFERENCE to the colormap thus it is keps alive and available due to reference count. this means we don't leak colormaps as when the window is destroyed - the reference to the colormap goes and thus the colormap is then freed :) Is this correct behaviour? When a window manager wants to take care of that window, it has to create the colormap again. There's no way it can find out whether the colormap pointer is valid, either - so it might waste resourrces by creating the color map. nooo in this case the wm does nothing. the colormap is just for making compositors and xrender happy. the wm doesn't do anything as the only thing a wm would ever do is INSTALL the colormap (for 8bpp colormapps displays only) :) I'm probably wrong about a few of these points as my xlib knowledge is pretty limited :D But shouldn't we either omit the XFreeColormap() call or also reset the colormap field? The first alternative seems better to me. GTK doesn't seem to free their colormaps, btw. they probably free later on destroy of the window as they fully wrap the window in a GdkWindow struct :) Thoughts? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eet crashes in a directory without write permission
On Mon, 28 Aug 2006 16:17:41 +0200 Peter Wehrfritz [EMAIL PROTECTED] babbled: Hi all, I'm using eet for the highscore support in elitaire, but eet crashes while writing into a file that is in a directory, for that the user hasn't got write permission, altough he has write permission for the file itself. To reproduce this: - first compile the attached test app and then make a directory called tmp - execute the the test app once or twice (or oftener) - chmod 555 tmp - then execute it again and it will crash Attached you will find the test app and the backtrace fixed :) subtle mmap and close() of the fd to the mmaped region bug :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
On Fri, 8 Sep 2006 08:15:38 -0500 [EMAIL PROTECTED] babbled: On Fri, Sep 08, 2006 at 09:40:08AM +, [EMAIL PROTECTED] wrote: Now, unfortunately, this discussion came up at a time when people are busy with e17... in particular, the 'owner' of evas is especially so. So basically, either people proceed without him (with a 'branch' or whatever), or they can wait around, or they can let things go. Or they can discuss ideas, get feedback, etc. I think this last was what Jorge was attempting to get started.. good timing or not.. and I guess he hoped that at least raster would have joined in (even if he did say that he was too busy to do so). I'd suggest maybe keep ideas in mind, let them develop, see what one might need, etc.. until things quiet down a bit on the release front. jose. This was more the point I was trying to get across. I didn't mean to sound like I was discouraging you three from working on evas. I'm all for branching evas and having ya'll work your magic :) (lack of time results in short emails that often don't properly convey the tone of voice i intended. for that, again, i apologize) take care, rephorm and here i come at the end of the tread... FINALLY! :) (i am hoping i can now mark off this entire thread in hit). ... so... the work jorge is doing is very interesting. it is basically the ability to virtualize right below the api level and punt off to somewhere else (in this case a server). this is most interesting but unfortunately touches just about every bit of api and has some really tricky parts to it. i think having this work in another branch is fine - i have no problems with that, but it will cause problems in merging later. what i think is a good idea is that this happens in a branch and jorge merges in changes from evas's head branch regularly so the merge back is as painless as possible. i think this work should happen - it has some exciting possibilities. it just needs to happen in a way that won't affect stability and correctness of the head evas branch :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Thu, 7 Sep 2006 10:38:20 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Anyway... I think it might be best to let the edc format stay as it is (non-premul colors), and have edje do the conversion, not edje_cc. If desired, a later edje can have other types and/or versions of 'design-formats', like edc, and one can do whatever.. There are possibilities for things that are very interesting with premul colors, and having evas handle premul colors, as given, would allow for that. agreed - now i have had time to mull. break the color_set - make it premul. we have anon-premul-import for convenience, and we modify all the code we can 0 edje converts at runtime before color_set when using config valued in the .edj. ;) Ok, I'll try and finish things off over the weekend and see if I can send it over Mon or Tues. I'm not satisfied with the premul vs non-premul color_set issue either.. it sucks either way for one reason or other. yup - but i think we need to bite the bullet. color_set needs to be premul as thats the api-level colorspace. :( sucky eh? :( For the eet and edb image loaders.. evas will convert to premul from what they serve and leave eet/edb themselves alone -- or do you want to change those as well? for now - evas will convert. i will move them to be premul on-disk - later. i will need to bump the version of them internally (add flags) so we will need the premul it for me code anyway. :) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas premul changes
On Thu, 14 Sep 2006 06:55:20 GMT [EMAIL PROTECTED] [EMAIL PROTECTED]
babbled:
Just a note on the evas move-to-premul stuff. Some things
are taking me a bit more time than I had thought, so it looks like
I may not finish with it til the weekend.. we'll see.
Let me give a quick recap of the api funcs that this change
will involve.
There are four utility functions for converting colors and
argb data to/fro premul:
evas_color_premul(int a, int *r, int *g, int *b)
evas_color_unpremul(int a, int *r, int *g, int *b)
evas_data_argb_premul(unsigned int *data, unsigned int len)
evas_data_argb_unpremul(unsigned int *data, unsigned int len)
good - useful routines :)
Now, as far as evas objects go, grads were the most affected
by this premul change, and there are new funcs as a result:
evas_object_gradient_alpha_add(obj, int a, int distance)
evas_object_gradient_alpha_data_set(obj, void *alpha_data,
int len)
which allow for adding separate alpha stops and setting separate
alpha data on a grad ('alpha_data' must have unsigned char values).
Note that you can have different sets of color and alpha
stops, and also color and alpha data of different lengths.
Since we're 'breaking' stuff and going over things -- I went
ahead and *removed* the current evas_object_gradient_data_unset
api function.
Why..? Well, its functionality can be obtained by setting
new data/adata, or by the colors-clear api func (which will clear
alpha stops as well), or just by adding new color/alpha stops.
nicer - yes.
The original reason for having this 'data unset' function
was to make it clear that you could not add colors to the gradient
*on-top-of* data that had been set.. but that isn't really a good
enough reason to have it, and in practice the use of this function
is cumbersome.
yup- as they both do the same. keep it to 1 :)
Also, when I get another chance, there'll be a func for
setting a 'file/key' on a grad so that one will be able to load grad
spectra, eg. gimp grads, etc. and then one would be tempted to have
a 'file-unset' func just for logical similarity... and it's just
not worth it.
or as per the image obj - just set the file to NULL to unset. :)
So unless someone really strongly feels otherwise, I'd say
let's take this 'gradient-data-unset' function out now.
agreed. :)
Ok, besides that, I wanted to fix some of the issues that
Brian had with grads in edje...
For this, I thought the best thing to do is to separate
the notions of the 'grad-angle' and the 'grad-fill-angle'.
So, I've added a new grad fill related api func:
evas_object_gradient_fill_angle_set(obj, Evas_Angle angle)
which does what the current evas_object_gradient_angle_set now
does, ie. rotate the fill region, and the grad-angle-set func will
instead do what it used to do - namely it will orient the gradient
(rel to the fill now) at that angle and make it 'cover' the fill
region. I've only implemented it for linear grads, but it's actually
intuitive for 'linear' kinds of geoms.. eg. for sinusoidal and such.
sounds ok to me.
It can also be given a reasonable interpretation for most
any geom, and in fact might be useful for images as it could be
taken to mean 'rotate the image' before using it in the fill (the
fill itself has its own rotation.. as will the object as a whole...
there's much angleness here).
not sure what you mean here (well not precisely).
I've also added two new linear grad types: linear.diag and
linear.codiag, which orient themselves rel to the fill's diagonal
and co-diagonal (when the grad-angle value is 0).
Lastly, I've added an api function to set the grad spectrum
'direction':
evas_object_gradient_range_direction_set(obj, int direction)
where 'direction' should be 1 or -1. This will reverse the gradient
spectrum if set to -1.
Much ado about gradients, but hopefully all this will make
it easier to work with grads in current edje and otherwise.
Comments...?
sounds good - one thing i did notice - gradient fills are a lot slower than
images... :) i noticed when cross-fading wallpapers @ 1600x1200 with gradient
bg's :)
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
Re: [E-devel] BUG: vanishing text in edje
On Fri, 21 Jul 2006 23:45:33 -0500 Sthithaprajna Garapaty [EMAIL PROTECTED] babbled: There seems to be a bug in evas/edje that makes text sometimes vanish when the width of the bounding box is equal to the width of the text itself. When the bounding box is larger than the text, the text is displayed properly, and when the bounding box is smaller than the text, the text is truncated and a ... appended to the end. Here's an example that demonstrates this bug. http://war.interhact.net/~iamsthitha/junk/vanishing_text.tar.gz As the button gets bigger, the text is slowly revealed.. but suddenly it vanishes in the middle. i see no text at all... ? -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas premul changes
On Thu, 14 Sep 2006 16:36:51 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Since we're 'breaking' stuff and going over things -- I went ahead and *removed* the current evas_object_gradient_data_unset api function. Why..? Well, its functionality can be obtained by setting new data/adata, or by the colors-clear api func (which will clear alpha stops as well), or just by adding new color/alpha stops. Maybe we should just name the function evas_object_gradient_clear()? (since it'll clear color/alpha stops, data or image depending on which was set, if i'm understanding properly) Yes, that's what it does. Also, if you add a color/alpha stop and there's data/alpha_data or a file set, it would remove these latter, etc. But yes, I guess a more generic 'gradient-clear' name would be better than the current 'colors-clear' (though it might be taken to mean 'clear' the type as well). However, if we're going to do that, then maybe just go ahead and rename some others.. eg. 'grad-fill-spread' instead of the current 'grad-spread', and 'grad-stop-add' instead of 'grad-color-add', and 'grad-alpha-stop-add' instead of 'grad-alpha-add' I guess a lot of these should have 'spectrum', but that's so damn long.. which is why I used 'range' instead for the offset and direction properties. I'll leave it up to you and Carsten if you wish -- you're the 'namespace' overlord.. something highly needed. :) it's a close call. in clearing the gradient type - it doesn't clear but reset to a default - so i would stick with colors-clear as it clears the set of colors as such. - that's my take on it, but there is something to be said of the simpler grad-clear so to speak :) . . This makes a lot of sense to me. It cleanly maps to edje, and gives all the functionality I can currently think one would want (without the hackish feel of my current 'solution' in edje. What you did was actually fairly ideal if one were dealing exclusively with linear grads (and evas had similar). But yes, I think the above may work fine with the generic gradientfill interfaces. ... where 'direction' should be 1 or -1. This will reverse the gradient spectrum if set to -1. Is this ignored for 'image' gradients? No, the spectrum will be reversed regardless of its source.. ie. wether it's from stops/data/file. It's done internally when the interpolating ocurrs. Much ado about gradients, but hopefully all this will make it easier to work with grads in current edje and otherwise. Comments...? Very awesome stuff. Thanks! :) Very straightforward really.. some physics stuff someone started looks like far more awesome stuff :) But it should improve things with grads a bit. Most of the actual reworking had to do with the premul change and the separate color/alpha stuff... and with various improvements I took the chance to do - more acurate spectrum generation, fix the type-params parsing so it only ocurrs when the params actually change, and some other stuff. There's still a lot left to do with grads - add the file setting, add foci params to radial and angular grads, maybe add a 'stop-mode' function for setting wether the distance used in stops should be interpreted as 'weights' or as 'dist-to-next', and many other things (eg. optimizations)... But I have to get out of gradient-land soon, I'm starting to get tired of them. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
