Re: [E-devel] E17 in Debian Sid
2006/11/25, Falko Schmidt <[EMAIL PROTECTED]>:- Masquer le texte des messages précédents - > On Fri, Nov 24, 2006 at 10:43:03PM +, Lut!n wrote: > > 2006/11/24, Falko Schmidt <[EMAIL PROTECTED]>: > > > > > > Hi all, > > > > > > Hi Falko , > > > > as some of you might have noticed, I'm trying to help out by adding and > > > fixing Debian packaging information in CVS since about eight months. > > > Meanwhile I took over Blake's Debian repository on edevelop.org which > > > now supports i386, AMD64, alpha and Sparc. > > > > Some days ago Jan Christoph Nordholz < [EMAIL PROTECTED] > > > > offered me to have E17 uploaded to Debian Sid via his sponsor who > could > > > sign the packages for us. > > > > As there's still time before Etch will be released he will help me to > > > make the packages compliant to the Debian policy. > > > > > > Are there any objections from the E17 Team? > > > > > > I am the maintainer of the ubuntu repo hosted on edevelop, and with > Maxence > > Dunnewind (Sp4rKy), Daniele Favara (nomed) and Blake, we've created a > team > > on alitoh whose goal is to build up a debian tree for e17 that matches > the > > debian policy. > > We are not listed on the debian packaging staff on enlightenment.org(the > > page seems outdated btw), but we've been working quite hard to make a > clean > > debian tree. Usually, integration of such projects are made through > teams, > > and teams are usually on alioth. > > There were many people packaging e17 for debian finally, and it makes > sense > > to merge our energies. Please have a look at > > http://alioth.debian.org/projects/pkg-e/ . We'd be happy if you want to > join > > us in the team, and on #pkg- [EMAIL PROTECTED], so we can make > something > > good all together :) > > > Oh, I didn't know about that. Do you eventually plan on commiting all > your efforts to CVS? Do you maintain your own e17 tree on alioth? I'm not sure it'd be a good idea to commit all the stuff to cvs as the goal of a clean debian tree (ie for integration) is fairly different from the debian tree provided in cvs (easily allow users to make their own pkges at home). Anyway, all that can be discussed ;). We have been working on our debian tree for the ubuntu repo, and I've benn maintaining it for 4months, but it's not on alioth yet (still on the serv I use for the builds). Feel free to join us on #pkg-e for any info Glad to see you with us Albin Tonnerre & the pkg-e team Well, anyways, count me in :) > > Any further infos would be appreciated. > > > Falko > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net 's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Pager patch
On Thu, 23 Nov 2006 00:24:02 +0200 Виктор Кожухаров <[EMAIL PROTECTED]> babbled: > В нд, 2006-11-19 в 17:44 +0900, Carsten Haitzler написа: > > On Thu, 16 Nov 2006 20:41:41 +0100 lok <[EMAIL PROTECTED]> babbled: > > > > > On Thu, 16 Nov 2006 19:40:58 +0100 > > > lok <[EMAIL PROTECTED]> wrote: > > > > > > > Hi, > > > > > > > > I've made some changement on the pager config. > > > > The first one let the user choose the mouse button he wants for the two > > > > type of drag. > > > > And the second disable the wheel callback on the pager. The wheel > > > > callback on the pager works only if the pager is in a shelf "above > > > > everything". By default it's disabled because scrolling above the pager > > > > in this case make you switch by a step of 2 desktops (one is done by > > > > the pager's callback and the other by the E's default mousebinding). > > can we revert this part, about removing the wheel callback. With the > default mouse bindings NOT having the mouse wheel bound to desktop > change, there's really no other way to _just_ change the desks with the > wheel. and since that's the default, there are a lot more people who > can't use the wheel for desk change, than there are people who can. the default is NOT to use the wheel on the desktop to change - that WAS the default at some stage. the patch is ok - except for a bug where you can't properly set the button for drag modes. > > > > > > > > The pager is probably the most used module, so I prefere to not commit > > > > this patch directly. (just to be sure to not be hunt down if I've made > > > > a mistake). And the patch also fix a small warning. > > > > > > > > Lok > > > > > > ok sorry about the double posting. > > > I forgot to change two values before making the patch. > > > This one is the good one. (No need to apply the previous) > > > > sounds good - note though - the default removed the wheel bindings for the > > desktop so if you started from fresh config it wouldnt jump 2 desks. > > > -- > Виктор Кожухаров /Viktor Kojouharov/ > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Solaris edje troubles
On Fri, 24 Nov 2006 23:57:26 +0100 Falko Schmidt
<[EMAIL PROTECTED]> babbled:
> [...]
> > > > Now that I've got E17 running, I noticed that it recieves no
> > > > keyboard input at all (e.g. in the 'run command' dialog or and other
> > > > widget) although input works for applications run inside E17 (e.g.
> > > > xterm). I'll investigate a bit more, but maybe someone out there
> > > > already knows how to deal with it.
> > >
> > > weird again. never seen this problem before.
> > >
> > I've used xnest to investigate the error some more. It seems that the
> > segfault is caused by _grab_key_down_cb (bt follows).
> >
> > One thing to note is that modifier keys as well as backspace and cursor
> > keys work in the input widgets - but pressing any other character
> > doesn't have any effect.
> >
> > Next is that if I specify a key binding with "enlightenment_remote
> > -binding-key-add" it works.
> >
> > Producing a backtrace with gdb wasn't very successful because after
> > adding debugging symbols to E17, gdb complained about the stack being
> > corrupted. However using mdb I've got the following results:
> >
> > ESTART: 29.85751 [6.89135] - SLEEP
> > mdb: stop on SIGSEGV
> > mdb: target stopped at:
> > libc.so.1`strlen+0x50: ld[%o2], %o1
> > mdb: You've got symbols!
> > Loading modules: [ ld.so.1 libc.so.1 libuutil.so.1 ]
> > > $c
> > libc.so.1`strlen+0x50(1835c5, ffbcd6d4, 57c3d9, 0, 0, 0)
> > libc.so.1`printf+0xf4(1835b8, 1a4608, 0, 1a4626, fe8e8284, 2ff770)
> > _grab_key_down_cb+0x148(296438, a, 2ff770, 1db038, 1db038, 588b48)
> > libecore.so.1.0.0`_ecore_event_call+0x36c(0, 2000, 2f08c, ff3ee0f8,
> > 0,
> > ff06a248)
> > libecore.so.1.0.0`_ecore_main_loop_iterate_internal+0x82c(0, 6,
> > ffd1, 1,
> > fe8f0527, ff06a248)
> > libecore.so.1.0.0`ecore_main_loop_begin+0x54(2f, 1a4608, 0, 1a4626,
> > fe8e8284,
> > 1a2b68)
> > main+0x54d8(1, ffbff204, ffbff20c, 1a4a9c, fecf0140, fecf0180)
> > _start+0x5c(0, 0, 0, 0, 0, 0)
> > > ::status
> > debugging PID 13681 (32-bit)
> > file: /usr/local/bin/enlightenment
> > threading model: multi-threaded
> > status: stopped on SIGSEGV (Segmentation Fault)
> > event: stop on SIGSEGV
> >
> >
> > Just for convenience, here's the bt output from gdb:
> >
> > ESTART: 1.86219 [0.11480] - SLEEP
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xfe830c90 in strlen () from /lib/libc.so.1
> > (gdb) bt
> > #0 0xfe830c90 in strlen () from /lib/libc.so.1
> > #1 0xfe896258 in _ndoprnt () from /lib/libc.so.1
> > #2 0xfe898404 in printf () from /lib/libc.so.1
> > #3 0x00100c30 in ?? ()
> > #4 0x00100c30 in ?? ()
> > Previous frame identical to this frame (corrupt stack?)
> >
> >
> > And another one with gdb, just without symbols:
> >
> > #0 0xfe830c90 in strlen () from /lib/libc.so.1
> > #1 0xfe896258 in _ndoprnt () from /lib/libc.so.1
> > #2 0xfe898404 in printf () from /lib/libc.so.1
> > #3 0x00100c30 in _grab_key_down_cb ()
> > #4 0xff046e60 in _ecore_event_call () from /usr/local/lib/libecore.so.1
> > #5 0xff052004 in _ecore_main_loop_iterate_internal ()
> >from /usr/local/lib/libecore.so.1
> > #6 0xff0506d8 in ecore_main_loop_begin () from
> >/usr/local/lib/libecore.so.1
> > #7 0x0002f094 in main ()
> >
> > Please tell me if you need more details or another kind of bt.
> >
> > Falko
>
> I've investigated some more. The segfault is caused by ev->key_compose
> in the printf statement in the function _grab_key_down_cb. If I remove
> only that part and make the line look like:
>
> printf("'%s' '%s'\n", ev->keyname, ev->keysymbol );
looks like solaris's printf doesnt handle null strings ala glibc - easy to fix.
> E17 won't segfault while grabbing the key. That doesn't solve the
> problem though. Still, I can't get any text entry widget to reflect any
> kind of keypresses except cursor keys, backspace and delete, at least it
> doesn't segfault there (never did).
>
> Is there a way to find out the reason for this problem?
well my guess is you need to put some debugging in e_entry.c in the
_e_entry_key_down_windows() and _e_entry_key_down_emacs() at the end where they
handle generic key down events and look at the event string - see what it is
(event->string) and why that logic may be failing.
> I'm not really understand too much about X internals, but it might be a
> Xsun issue or the way Xsun handles key events. Maybe adding some extra
> treatment to XLookupKeysym.
>
> I'll come back if I find out more.
>
> Falko
>
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.
Re: [E-devel] Benchmark: Brute force copy from GL pbuffer to image as data
On Thu, 23 Nov 2006 23:53:16 +0100 (CET) [EMAIL PROTECTED] babbled:
> Sorry for lack of response. Illness and loss of internet connection. This
> conversation is modem powered.
>
> As I mentioned a little while ago, I wanted to benchmark the speed at
> which an OpenGL rendering into a buffer can be moved out of video memory,
> into the system memory and then back into an Evas Image and rendered to
> the screen.
>
> Would anybody be surprised if I said that it really isn't fast... ahem.
> Just had to try. Pseudo code of a main loop:
I'd tell you "why did you even try? I could have told you that!" :) It's not a
sane path to go down. reading pixels back from the video card is simply death-
asking for pain. the rule to follow here is "DON'T DO IT" :)
> 1) Render frame to a PBuffer
> 2) Get the data using glReadPixels
> 3) Put the frame back into an image using evas_object_image_data_set
>
> Compile as a C++ program:
>
> gcc bench_gl_evas.cpp -o bench_gl_evas `ecore-config --libs --cflags`
> `evas-config --libs --cflags` -lGL -lGLU -lstdc++
>
> Regards Rene Jensen
>
>
>
> -- bench_gl_evas.cpp ---
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
> #include
> #include
>
> static const intPBUFFER_WIDTH = 512;
> static const intPBUFFER_HEIGHT = 512;
> struct Vertex
> {
> float tu, tv;
> float x, y, z;
> };
> Vertex g_cubeVertices[] =
> {
> { 0.0f,0.0f, -1.0f,-1.0f, 1.0f },
> { 1.0f,0.0f, 1.0f,-1.0f, 1.0f },
> { 1.0f,1.0f, 1.0f, 1.0f, 1.0f },
> { 0.0f,1.0f, -1.0f, 1.0f, 1.0f },
> { 1.0f,0.0f, -1.0f,-1.0f,-1.0f },
> { 1.0f,1.0f, -1.0f, 1.0f,-1.0f },
> { 0.0f,1.0f, 1.0f, 1.0f,-1.0f },
> { 0.0f,0.0f, 1.0f,-1.0f,-1.0f },
> { 0.0f,1.0f, -1.0f, 1.0f,-1.0f },
> { 0.0f,0.0f, -1.0f, 1.0f, 1.0f },
> { 1.0f,0.0f, 1.0f, 1.0f, 1.0f },
> { 1.0f,1.0f, 1.0f, 1.0f,-1.0f },
> { 1.0f,1.0f, -1.0f,-1.0f,-1.0f },
> { 0.0f,1.0f, 1.0f,-1.0f,-1.0f },
> { 0.0f,0.0f, 1.0f,-1.0f, 1.0f },
> { 1.0f,0.0f, -1.0f,-1.0f, 1.0f },
> { 1.0f,0.0f, 1.0f,-1.0f,-1.0f },
> { 1.0f,1.0f, 1.0f, 1.0f,-1.0f },
> { 0.0f,1.0f, 1.0f, 1.0f, 1.0f },
> { 0.0f,0.0f, 1.0f,-1.0f, 1.0f },
> { 0.0f,0.0f, -1.0f,-1.0f,-1.0f },
> { 1.0f,0.0f, -1.0f,-1.0f, 1.0f },
> { 1.0f,1.0f, -1.0f, 1.0f, 1.0f },
> { 0.0f,1.0f, -1.0f, 1.0f,-1.0f }
> };
>
> // This class is simply a fancy way of rendering a scene and getting it
> // as an ARGB array of integers
> //
> class RenderNode
> {
> public:
> unsigned long*data;
> Display*display;
> GLXPbufferpbuffer;
> GLXContextpbufferContext;
>
> void init ()
> {
> // Open the X display
> display = XOpenDisplay(0);
> if (! display)
> throw "Can't open X display";
>
> int nItems;
> int attrib[] =
> {
> GLX_DOUBLEBUFFER, False,
> GLX_RED_SIZE, 1,
> GLX_GREEN_SIZE,1,
> GLX_BLUE_SIZE, 1,
> GLX_DEPTH_SIZE,1,
> GLX_RENDER_TYPE, GLX_RGBA_BIT,
> GLX_DRAWABLE_TYPE, GLX_PBUFFER_BIT | GLX_WINDOW_BIT,
> None
> };
>
> int pbufAttrib[] =
> {
> GLX_PBUFFER_WIDTH, PBUFFER_WIDTH,
> GLX_PBUFFER_HEIGHT, PBUFFER_HEIGHT,
> GLX_LARGEST_PBUFFER, False,
> None
> };
>
> GLXFBConfig *fbconfig = glXChooseFBConfig (
> display, DefaultScreen(display),
> attrib, &nItems);
>
> if (fbconfig == 0)
> throw "Can't choose fbconfig";
>
> pbuffer = glXCreatePbuffer (
> display, fbconfig[0], pbufAttrib);
> XVisualInfo* visinfo = glXGetVisualFromFBConfig(
> display, fbconfig[0] );
> if (! visinfo)
> throw "Error: init - Couldn't get wanted visual";
>
> pbufferContext = glXCreateNewContext(display, fbconfig[0],
> GLX_RGBA_TYPE, NULL, GL_TRUE);
> if (! pbufferContext)
> throw "Can't make pbuffer context";
>
> XFree( fbconfig );
> XFree( visinfo );
>
> data = new unsigned long[PBUFFER_WIDTH*PBUFFER_HEIGHT];
> }
>
> void render ()
> {
> if (! glXMakeContextCurrent(
> display, pbuffer, pbuffer, pbufferContext))
> throw "Can't make context current";
> static float time = 20.0;
> time += 0.1;
>
> glClearColor( 0,0,0, 1.0f );
> glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
>
> glMatrixMode( GL_PROJECTION );
> glLoadIdentity();
> gluPerspective( 45.0f,
> PBUFFER_WIDTH / PBUFFER_HEIGHT, 0.1f, 10.0f );
>
> glMatrixMode( GL_MODELVIEW );
> glLoadIdentity();
> glTranslatef( 0.0f, 0.0f, -5.0f );
> glRotatef( time, 1.0f, 0.0f, 0.0f )
Re: [E-devel] bad drawnig - invisible shelf
On Thu, 23 Nov 2006 09:45:13 +0100 Wiesiek <[EMAIL PROTECTED]> babbled: > Why invisible shelf draw the outline so bad? > > If I draw elements(text,image...) on white RECT it is good. > If I draw elements(text,image...) in invisible shelf, on white > backround(wallpaper,xterm...) it is bad. > > If you want to see a difference - I give you an test > efontclock.edj(theme/modules/clock): > Mouse left click on a clock - change the RECT visible/invisible. because when the shelf is invisible it loses its background object. this basically makes it invisible - and the shelf uses a shaped window (and a shaped window has no alpha channel - it is either there or not). thus its not smooth. this is a limitation of X. if you want alpha channel smoothing you can set the shelf to be below everything then it is drawn in the desktop canvas - and thus you get alpha blending (as x is not involved in drawing the canvas contents). In theory xcomposite, a composite manager etc. can solve this - but that is an advanced and still "Buggy" thing where your mileage might vary. so basically - unless you LIKE the look- DONT make a shelf invisible WITHOUT setting it below everything. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 in Debian Sid
On Fri, 24 Nov 2006 22:43:03 + Lut!n <[EMAIL PROTECTED]> babbled: > 2006/11/24, Falko Schmidt <[EMAIL PROTECTED]>: > > > > Hi all, ok- some summary. 1. e.org pages have not been updated or maintained because we anticipated a while back moving to a new webserver, website and a need to redo ALL the website. no need to go create content we just need to redo again. this has unfortunately been delayed an taken a lot longer that thought. we are still waiting. 2. packages of e17. e17 is unreleased. we do not encourage you to go put packages in debian or ubuntu - why? you will piss us off as users will just come back to use complaining about bugs or missing features when we are not done. it doesn't matter what policies you have or how many lines of documentation say not to bother us - they will. they will waste our time and patience. we do NOT want e in official debian repositories. it just will mean a tonne of support we already don't have time for. if you want e development to halt - then go ahead. but likely it will mean just that. users are a burden if you are not prepared for them - and we sure as hell are not. they will not be god users and contact debian support mechanisms - they will come back to us. if you want to do packages - put them in a separate apt repository - make it harder to get to. this will minimise the impact. as for working together - i absolutely think you should - ubunutu and debian basically are the same (from an e perspective anyway) and there is little use it duplicating most of the packaging work :) > > Hi Falko , > > as some of you might have noticed, I'm trying to help out by adding and > > fixing Debian packaging information in CVS since about eight months. > > Meanwhile I took over Blake's Debian repository on edevelop.org which > > now supports i386, AMD64, alpha and Sparc. > > Some days ago Jan Christoph Nordholz < [EMAIL PROTECTED]> > > offered me to have E17 uploaded to Debian Sid via his sponsor who could > > sign the packages for us. > > As there's still time before Etch will be released he will help me to > > make the packages compliant to the Debian policy. > > > > Are there any objections from the E17 Team? > > > I am the maintainer of the ubuntu repo hosted on edevelop, and with Maxence > Dunnewind (Sp4rKy), Daniele Favara (nomed) and Blake, we've created a team > on alitoh whose goal is to build up a debian tree for e17 that matches the > debian policy. > We are not listed on the debian packaging staff on enlightenment.org (the > page seems outdated btw), but we've been working quite hard to make a clean > debian tree. Usually, integration of such projects are made through teams, > and teams are usually on alioth. > There were many people packaging e17 for debian finally, and it makes sense > to merge our energies. Please have a look at > http://alioth.debian.org/projects/pkg-e/ . We'd be happy if you want to join > us in the team, and on #pkg- [EMAIL PROTECTED], so we can make something > good all together :) > > Furthermore I'd like to know if people mentioned in the 'Porting and > > Package Team' section on enlightenment.org are still active in regards > > of Debian packages. > > I don't want to step on anyone's toes, so it'd be nice if people tell me > > if they don't like me messing around in their debian/ directories :) > > > > Falko > > > Greets, > Albin Tonnerre (Lutin), in behalf of the pkg-e team. > > - > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > 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 (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http
Re: [E-devel] [epeg] _epeg_scale() not called from epeg_pixels_get()
On Wed, 22 Nov 2006 18:16:36 +0100 Johannes Hofmann <[EMAIL PROTECTED]> babbled: > Hi, > > I am using the epeg lib to generate thumbnails in memory (for > display in an X11 application). Therefore I use the > epeg_pixels_get() function. This works fine, but the resulting > images are a bit too large. > If I call epeg_encode() before epeg_pixels_get() however, > _epeg_scale() gets called and everything is fine. > Shouldn't _epeg_scale() be called from epeg_pixels_get()? Or how can > I ensure that the image is scaled correctly without actually > encoding it? changed now (in cvs) :) > Thanks, > Johannes > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > 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 (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 in Debian Sid
On Sat, 25 Nov 2006 10:39:49 +0100 Lut!n <[EMAIL PROTECTED]> babbled: > 2006/11/25, Falko Schmidt <[EMAIL PROTECTED]>:- Masquer letexte > des messages précédents - > > On Fri, Nov 24, 2006 at 10:43:03PM +, Lut!n wrote:> > 2006/11/24, Falko > > Schmidt <[EMAIL PROTECTED]>:> > >> > > Hi all,> >> >> > Hi > > Falko ,> >> > as some of you might have noticed, I'm trying to help out by > > adding and> > > fixing Debian packaging information in CVS since about > > eight months.> > > Meanwhile I took over Blake's Debian repository on > > edevelop.org which> > > now supports i386, AMD64, alpha and Sparc.> >> > > > Some days ago Jan Christoph Nordholz < [EMAIL PROTECTED] >> > > > > offered me to have E17 uploaded to Debian Sid via his sponsor who> could> > > > > sign the packages for us.> >> > As there's still time before Etch will be > > > released he will help me to> > > make the packages compliant to the > > > Debian policy.> > >> > > Are there any objections from the E17 Team?> >> > > > >> > I am the maintainer of the ubuntu repo hosted on edevelop, and with> > > > >> > Maxence> > Dunnewind (Sp4rKy), Daniele Favara (nomed) and Blake, > > > >> > Maxence> > we've created a> team> > on alitoh whose goal is to build > > > >> > Maxence> > up a debian tree for e17 that matches> the> > debian > > > >> > Maxence> > policy.> > We are not listed on the debian packaging > > > >> > Maxence> > staff on enlightenment.org(the> > page seems outdated > > > >> > Maxence> > btw), but we've been working quite hard to make a> clean> > > > >> > Maxence> > > debian tree. Usually, integration of such projects are > > > >> > Maxence> > > made through> teams,> > and teams are usually on > > > >> > Maxence> > > alioth.> > There were many people packaging e17 for > > > >> > Maxence> > > debian finally, and it makes> sense> > to merge our > > > >> > Maxence> > > energies. Please have a look at> > > > > >> > Maxence> > > http://alioth.debian.org/projects/pkg-e/ . We'd be > > > >> > Maxence> > > happy if you want to> join> > us in the team, and on > > > >> > Maxence> > > #pkg- [EMAIL PROTECTED], so we can make> something> > > > > >> > Maxence> > > #good all together :)> >> Oh, I didn't know about that. > > > >> > Maxence> > > #Do you eventually plan on commiting all> your efforts > > > >> > Maxence> > > #to CVS? Do you maintain your own e17 tree on alioth? you might want to commit any SHARED things to cvs - ie file lists and everything you have in common - then only keep small patch files (or scripts to auto-patch the stuff from cvs or use sed/awk/grep/whatever to modify whatever you share to produce the changes you need). then you cave work by sharing most of it :) > I'm not sure it'd be a good idea to commit all the stuff to cvs as the goalof > a clean debian tree (ie for integration) is fairly different from thedebian > tree provided in cvs (easily allow users to make their own pkges athome). > Anyway, all that can be discussed ;).We have been working on our debian tree > for the ubuntu repo, and I've bennmaintaining it for 4months, but it's not on > alioth yet (still on the serv Iuse for the builds).Feel free to join us on > #pkg-e for any info Glad to see you with usAlbin Tonnerre & the pkg-e team > #Well, anyways, count me in :)>> Any further infos would be appreciated.>>> > #Falko>> -> > #Falko>> Take Surveys. Earn Cash. Influence the Future of IT> Join > #Falko>> SourceForge.net 's Techsay panel and you'll get the chance to share> > #Falko>> your> opinions on IT & business topics through brief surveys - and > #Falko>> your> earn cash> > #Falko>> your> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV> > #Falko>> your> ___> > #Falko>> your> enlightenment-devel mailing list> > #Falko>> your> enlightenment-devel@lists.sourceforge.net> > #Falko>> your> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel-Take > #Falko>> your> Surveys. Earn Cash. Influence the Future of ITJoin > #Falko>> your> SourceForge.net's Techsay panel and you'll get the chance to > #Falko>> your> share youropinions on IT & business topics through brief > #Falko>> your> surveys - and earn > #Falko>> your> > cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___enlightenment-devel > #Falko>> your> mailing > #Falko>> your> [EMAIL > PROTECTED]://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinion
Re: [E-devel] bad drawnig - invisible shelf
2006/11/25, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>: > > On Thu, 23 Nov 2006 09:45:13 +0100 Wiesiek <[EMAIL PROTECTED]> babbled: > > > Why invisible shelf draw the outline so bad? > > > > If I draw elements(text,image...) on white RECT it is good. > > If I draw elements(text,image...) in invisible shelf, on white > > backround(wallpaper,xterm...) it is bad. > > > > If you want to see a difference - I give you an test > > efontclock.edj(theme/modules/clock): > > Mouse left click on a clock - change the RECT visible/invisible. > > because when the shelf is invisible it loses its background object. this > basically makes it invisible - and the shelf uses a shaped window (and a > shaped > window has no alpha channel - it is either there or not). thus its not > smooth. > this is a limitation of X. if you want alpha channel smoothing you can set > the > shelf to be below everything then it is drawn in the desktop canvas - and > thus > you get alpha blending (as x is not involved in drawing the canvas > contents). > In theory xcomposite, a composite manager etc. can solve this - but that > is an > advanced and still "Buggy" thing where your mileage might vary. so > basically - > unless you LIKE the look- DONT make a shelf invisible WITHOUT setting it > below > everything. > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] > 裸好多 > Tokyo, Japan (東京 日本) 1. Thx for explanation. Where can I find the "shaped window" the shelf use in e17 source ? 2. I try xcomposite for now. Transparency and shadow work fine but my clock theme in invisible shelf "Above Everything" not: a) The X even do not refresh. After 1 minute I have 60 hands :) b) "Antialias" do not work. Hands are not smooth. I still do not have(don't found) : #enlightenment_remote -use-composite-set 1 Wiesiek - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] bad drawnig - invisible shelf
On Sat, 25 Nov 2006 20:08:33 +0100 Wiesiek <[EMAIL PROTECTED]> babbled: > 2006/11/25, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>:>> On Thu, > 23 Nov 2006 09:45:13 +0100 Wiesiek <[EMAIL PROTECTED]> babbled:>> > Why > invisible shelf draw the outline so bad?> >> > If I draw elements > (text,image...) on white RECT it is good.> > If I draw elements > (text,image...) in invisible shelf, on white> > backround(wallpaper,xterm...) > it is bad.> >> > If you want to see a difference - I give you an test> > > efontclock.edj(theme/modules/clock):> > Mouse left click on a clock - change > the RECT visible/invisible.>> because when the shelf is invisible it loses > its background object. this> basically makes it invisible - and the shelf > uses a shaped window (and a> shaped> window has no alpha channel - it is > either there or not). thus its not> smooth.> this is a limitation of X. if > you want alpha channel smoothing you can set> the> shelf to be below > everything then it is drawn in the desktop canvas - and> thus> you get alpha > blending (as x is not involved in drawing the canvas> contents).> In theory > xcomposite, a composite manager etc. can solve this - but that> is an> > advanced and still "Buggy" thing where your mileage might vary. so> basically > -> unless you LIKE the look- DONT make a shelf invisible WITHOUT setting it> > below> everything.>> --> - Codito, ergo sum - "I code, therefore > below> I am" --> The Rasterman (Carsten Haitzler) > below> [EMAIL PROTECTED]> 裸好多> Tokyo, Japan (東京 日本) > > 1. Thx for explanation. Where can I find the "shaped window" the shelf usein > e17 source ? > 2. I try xcomposite for now.Transparency and shadow work fine but my clock > theme in invisible shelf"Above Everything" not:a) The X even do not refresh. > After 1 minute I have 60 hands :)b) "Antialias" do not work. Hands are not > smooth. I still do not have(don't found) :#enlightenment_remote > -use-composite-set 1 1. shaped windows are handled by ecore_evas and evas generates the mask. masks are made by cutting off alpha at 128 (> 128 == solid, < 128 == transparent). i am not sure why you want to look at the code though? 2. problems are probably because your e is old and doesnt support argb dest rendering - if enlightenment_remote doesn't support that command - the window is still shaped and you are seeing bugs in the composite manager with handling shaped windows (well known with xcompmgr and bling). > Wiesiek-Take > Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay > panel and you'll get the chance to share youropinions on IT & business topics > through brief surveys - and earn > cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___enlightenment-devel > mailing > [EMAIL PROTECTED]://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
