Carsten Haitzler | 1 May 01:01 2007

Re: [E-devel] WWW!

On Mon, 30 Apr 2007 15:33:55 -0500 Brian Mattern <brian.mattern <at> gmail.com>
babbled:

> On Mon, Apr 30, 2007 at 10:27:45PM +0300, Luchezar Petkov wrote:
> > Jaime Thomas wrote:
> > > I've written them for Eclair, Elicit, Exhibit, Estickies.  Can write for
> > > others.
> > > 
> > > jethomas
> > > 
> > 
> > Ok, send me what you have about Exhibit and Estickies. I'll check those
> > out. Eclair is officially dead, Elicit, iirc isnt maintained anymore.
> 
> Incorrect. Elicit is alive and working well. (13 commit emails in march
> and 5 in may). Please check before spreading misinformation. :)

actually eclair might not be active - BUT, unlike a lot of apps, it works
fairly well.

> Brian
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> enlightenment-devel mailing list
(Continue reading)

Nick Hughart | 1 May 03:28 2007
Picon

Re: [E-devel] Patch for disabling confirmation dialogs

I actually was speaking to a few people about this.  If each dialog has
its own disable checkbox then you can disable per dialog.  Then all you
need to do is add a button somewhere in the config panel to re-enable
all dialogs.  Of course this is a bit more complicated then a global
enable/disable, but might not be too bad.  I don't know how the dialog
code is setup though so not sure if this can be added in a generic way
or not.

On Mon, 30 Apr 2007 12:34:28 -0400
Michael Jennings <e-devel <at> kainx.org> wrote:

> On Monday, 30 April 2007, at 12:21:02 (+0200),
> Brian 'morlenxus' Miculcy wrote:
> 
> > > Why don't you just add "Don't show this dialog again" checkboxes
> > > to those confirm. dialogs? I don't think a conf dialog is needed
> > > here.
> > 
> > Because people wanted to disable all dialogs at once.
> 
> There is wisdom in not allowing them to do that.
> 
> > Thats' why i added this option. Also if you allow to disable each
> > dialog, you need to be able to enable it again. I think this option
> > is more simplier.
> 
> "Simple" isn't the goal, so those should not be the terms in which we
> are thinking.  Many apps have a confirmation dialog, though, so I
> don't see it as a problem as long as each confirmation is
> independently enableable or disableable.
(Continue reading)

jose_ogp@juno.com | 1 May 04:53 2007
Picon

Re: [E-devel] [RFC] SDL Engine


	Simon wrote:

> Actually, what I really want is a GL engine that is not aware
> of the rendering-target, i.e. an engine that can render
> indifferently to the backbuffer, to the fronbuffer, to a texture,
> to a pbuffer... and independently of the windowing system used.
> Here would be the different schemes to do these things with this
> generic GL engine:
> 
> .....
> .....
> .....

	I'm not certain wether or not you'll be able to do this,
in that kind of generality, with respect to the windowing system.

	However, starting with OpenGL 1.5 there is available
the "framebuffer object" extension which seems to allow for much
of this. Here's a link to the spec:

http://www.opengl.org/registry/specs/EXT/framebuffer_object.txt

	Maybe you could use this approach to construct a fairly
generic gl engine, and presumably support fast 'render-to-texture'
functionality.

   jose.

-------------------------------------------------------------------------
(Continue reading)

Daniel Stonier | 1 May 14:12 2007
Picon

Re: [E-devel] DR17 Korean Locale and Theme (0.16.999.037)

Did some testing with this - managed to work out how to get additional
fonts recognised as "Sans" style fallbacks by fontconfig and then set
up E17 to use "Sans" across the board, but its a bit of a fiddle.

I remember once getting fallbacks going with the fallback setting in
the E17 font configuration menu, which effectively did the same thing
- but this seems to be no longer functional? I really liked this setup
- was quick, easy to understand and no hassle. And allowed you some
flexibility. At least, in comparison to the fontconfig "sans" way.

Thanks for the fonts too Michael - I hadn't known about them, and they
seem to be better than the Baekmuk ones.

On 30/04/07, The Rasterman Carsten Haitzler <raster <at> rasterman.com> wrote:
> On Mon, 30 Apr 2007 00:43:58 +0900 "Michael Kim" <lavnrose <at> gmail.com> babbled:
>
> > Full Korean Localization. (tested on 0.16.999.037.)
> > Not only messages, but also theme supported.
> > but, korean font does not included.
> >
> >
> > 1. Downloading Korean Font in following site.
> >     UnFont (GPL) - http://kldp.net/projects/unfonts/
> >
> > 2. including following item.
> >     Korean system message.
> >     Korean menu.
> >     Korean theme. (default theme; BLING BLING )
>
> actually if your system is set up with fontconfig and can do korean via
(Continue reading)

Andreas Volz | 1 May 17:02 2007
Picon

[E-devel] ecore_dispatcher

Hello,

I had to change my edje GUI from a thread. After some help here I found
a way to do that with pipes. I've created some helper functions to easy
dispatch an GUI update from a thread. Perhaps it's usefull for anyone.
Maybe this functions or anything similar could be inserted in ecore for
easier use in threads.

ecore_dispatcher.c:

#include "ecore_dispatcher.h"

void dispatcher_init (Dispatcher *dp, int (dispatcher_async_handler) (void *data, Ecore_Fd_Handler *fdh))
{
  int fd[2];
  Ecore_Fd_Handler *fd_handler;

   /* Create the file descriptors */
  if (pipe(fd) == 0) 
  {
    dp->fd_read = fd[0];
    dp->fd_write = fd[1];
    fcntl(dp->fd_read, F_SETFL, O_NONBLOCK);
    fd_handler = ecore_main_fd_handler_add (dp->fd_read,
                                               ECORE_FD_READ,
                                               dispatcher_async_handler,
                                               dp,
                                               NULL, NULL);
    ecore_main_fd_handler_active_set(fd_handler, ECORE_FD_READ);
  }
(Continue reading)

Andreas Volz | 1 May 17:59 2007
Picon

Re: [E-devel] WWW: button problem with Firefox version?

Am Mon, 30 Apr 2007 13:40:47 +0900 schrieb Carsten Haitzler (The
Rasterman):

> On Sun, 29 Apr 2007 12:17:10 +0200 Andreas Volz <lists <at> brachttal.net>
> babbled:
> 
> > Hello,
> > 
> > I've FireFox 2.0.0.3 on my main computer (Gentoo) installed. The
> > buttons on the website look good. See here:
> > 
> > http://tux-style.de/tmp/e_website_ok.jpg
> > 
> > On my laptop is Firefox 1.5.0.11 (Ubuntu) installed. The buttons
> > doesn't look so good:
> > 
> > http://tux-style.de/tmp/e_website_nok.jpg
> > 
> > Perhaps this is more a font problem than a Firefox problem. Any
> > ideas how to solve this?
> 
> unsure - maybe its your minimum font size preferences - we explicitly
> set a PIXEL size for those fonts to try and keep them small so they

Yes, this was the reason. With 11 px minimum it looks good.

Andreas

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
(Continue reading)

Gustavo Sverzut Barbieri | 1 May 20:41 2007
Picon

Re: [E-devel] ecore_dispatcher

On 5/1/07, Andreas Volz <lists <at> brachttal.net> wrote:
> Hello,
>
> I had to change my edje GUI from a thread. After some help here I found
> a way to do that with pipes. I've created some helper functions to easy
> dispatch an GUI update from a thread. Perhaps it's usefull for anyone.
> Maybe this functions or anything similar could be inserted in ecore for
> easier use in threads.

I'm just started with EFL, being used to GLib, maybe this could be
also done by adding some timeout or idle function to be executed by
ecore, and since ecore processes these queues from the thread
ecore_main_loop_begin() (also considered "main" or "graphical"
thread), these would run from this.

However, Ecore is not thread safe and this may bring some problems
using "as is", but providing a patch to use mutexes around critical
areas seems to be easy. Would it be accepted? If so I can provide
them.... since in few weeks I'll have to integrate GMainLoop with
ecore, this can help with the job, replacing GMainLoop primitives with
Ecore using LD_PRELOAD instead of the other way around (as I was
planing to do).

--

-- 
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: barbieri <at> gmail.com
   MSN: barbieri <at> gmail.com
  ICQ#: 17249123
 Skype: gsbarbieri
(Continue reading)

Essien Ita Essien | 3 May 14:38 2007

[E-devel] Look who's back

Heya ppls,

Just kinda wanted to ping all ma ppls and fellows of the raster harem 
(yup... we're all beyatchiiiiis!). I'd gotten pretty tied up on a lot of 
fronts and lots of changes have happened in a short while - I got 
friggin married!!! :)

Anyways... things are beginning to slow down again, and I'll be able to 
get back to some keyboard punching and head banging...err... code design 
and development :P - on entrance and entrance_edit_gui

I noticed that while I was away... we got the brand new spanking server 
we'd always wanted (yay!) and the new website effort is underway (double 
yay!). I wanted to find out what's the current status (if there is 
anyway) of a plan for a bug tracker for enlightenment, or a central 
bugtracking system which the various different projects can use.

I'm asking because I wanted to request for all that have sent bugs to 
the mailing list concerning entrance/entrance_edit_gui to submit them to 
a central place, for easier management.

If i remember well, there's been some hints and suggestions of bug 
tracking before, though i can't remember the conclusion(s) of those 
discoursions. I do think though that now we have a server, we *may* want 
to look seriously into it. I personally have to particular preference, 
so anyone will do, just the fact that we're using it is more important 
(i think).

Anyways... so much bandwidth used up just to say... wassup peeps.

(Continue reading)

Massimiliano Calamelli | 3 May 17:23 2007
Picon

[E-devel] [PATCH] exhibit had a make problem


hi all, compiling exhibit on my host (FreeBSD 6.2 using easy_e17
preview), i've got a message for undefined vars (edj_file, h and w) in
exhibit_image.c
The attached patch works for me.

Byez

Massimiliano
-- 
Massimiliano Calamelli
http://mcalamelli.netsons.org
mcalamelli <at> gmail.com
Index: exhibit_image.c
===================================================================
RCS file: /var/cvs/e/e17/apps/exhibit/src/bin/exhibit_image.c,v
retrieving revision 1.46
diff -u -r1.46 exhibit_image.c
--- exhibit_image.c	3 May 2007 10:30:41 -0000	1.46
+++ exhibit_image.c	3 May 2007 14:56:44 -0000
 <at>  <at>  -1052,6 +1052,8  <at>  <at> 
    char *esetroot;
    char esetroot_opt[] = "-s";
 #if HAVE_ENGRAVE   
+   char *edj_file;
+   int w, h;
    Engrave_File *edj;
    Engrave_Image *image;
(Continue reading)

Massimiliano Calamelli | 3 May 17:38 2007
Picon

Re: [E-devel] [PATCH] easy_e17.sh - FreeBSD support


On Mon, 30 Apr 2007 01:39:47 +0200
Brian 'morlenxus' Miculcy <morlenxus <at> gmx.net> wrote:

> Hi,
> 
> thanks for the patch. I changed a bit of it and applied it.
> Please test it: https://omicron.homeip.net/files/easy_e17_preview.sh
> Maybe you also know what "DA COMPLETARE, E' SOLO UN PLACEHOLDER" in the
> patch mean... ;)
> 
> Greets,
> Brian 'morlenxus' Miculcy

Good!
I've just finished to try the preview on my FreeBSD host, and it works
(for me). It would be better if other people try it, but it's ok for
me.
For PLACEHOLDER comment, i'm studying that do $e17ldcfg, but i see
that also on Solaris isn't used... 

Massimiliano
--

-- 
Massimiliano Calamelli
http://mcalamelli.netsons.org
mcalamelli <at> gmail.com

Gmane