Re: [E-devel] Epsilon problems
Nathan wrote: > 1. Split thumbnail generation into pluggable processes. If we can > specify external commands for generating thumbnails, we reduce the > amount of code necessary to support new formats. This also gives us > robustness when a dependency mis-behaves and crashes the thumbnailing > process. > > 2. Switch to dbus for client to server IPC. Many of the issues > currently with the epsilon daemon stem from some initial problems > with ecore_ipc, and the hacky conversion to ecore_con. Dbus is also > targeted at remote method invocation, which is essentially the goal > of the epsilon daemon communications. > > 3. Develop a dbus standard communication protocol with FDO. Ideally, > we could get a protocol adopted by the major desktops which would > allow for a single thumbnailing process to be present regardless of > your application mix. For instance, if you are running nautilus under > E and it handles thumbnailing requests, then we don't need to start a > background epsilon process. I think these are all reasonable ideas. I especially like the idea of having pluggable thumbnail generation that can be used by different desktop/handheld environments. It's absurd that right now there's really just: everything has to be some 'standard' image format or everyone does their own thing and no one else can use it but them. I don't think there's a need to require that 'thumbnailing' must involve a specific means for storing some standard image format somewhere.. one may not want or need to store anything really. There's really very little difference between 'thumbnailing', 'iconifying', 'pre-viewing', ... or 'full-viewing'. If "web-browsers" have a notion of interfaces for plugings that can display stuff as varied as they do, there shouldn't be any reason why "desktops" can't be as flexible, or maybe do even better. jose. _ Looking for insurance? Click to compare and save big. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m275pfSc0Kmxy2ouBR0YuLqtPmFmIrPpMwHwci7k448XSWU/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
I wrote: > For jpgs you don't have to worry about it since we only > deal with rgb images then, hence there's no difference (and no > premul or un-premul takes place). It does matter for pngs with > alpha though, and then it's fastest to deal with pngs embedded > in eet. But I think the cost of disk access is likely a far > greater factor than any premul/un-premul operations anyway. I forget that the system you're dealing with is flash-drive based, not disk-drive.. so maybe it might have some impact to have to do the premul/un-premul conversions - if saving images with alpha to png. Both premul and un-premul conversions use only ints though, no floats. _ Free information on hiring a Business Consulting Service. Click here. http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3m0mYEcDI9G4NoYxgzY3bLAGgAk35H8Jh0LfBtPMnL14vCQo/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Wiki] add a page about the build of the EFL on Win32
On Tuesday 04 December 2007, Vincent Torri wrote: > On Tue, 4 Dec 2007, Mike Frysinger wrote: > > On Monday 03 December 2007, Vincent Torri wrote: > >> On Sun, 2 Dec 2007, Mike Frysinger wrote: > >>> On Saturday 01 December 2007, Vincent Torri wrote: > I have added a document in the Wiki that details how to build the EFL > on Windows. You can find it here: > > http://wiki.enlightenment.org/index.php/Category:EFL_Windows > > There's also a link in the main page of the Wiki. > > Currently, only the build with MSYS/MinGW is described. Also, I only > wrote the build of eet. I'll add the other EFL later (mainly, how to > install the dependencies) > >>> > >>> forcing -L/-I paths to /usr/local sounds like a lie ... sane compilers > >>> should search those paths automatically ... > >> > >> I recall that it's on Windows :D > >> > >> Well, I'm sure that gcc 3.4.5 which is shipped with MinGW does not > >> search header files in /usr/local/include. So I have concluded that it > >> does not search the static libs in /usr/local/lib, but I'm not sure > >> about that. I'll try to see if I can remove LDFLAGS. > > > > just look at the output of `gcc -print-search-dirs` > > -mike > > I don't know if I can rely on that it. For example, on Ubuntu, with gcc > 4.1.2, /usr/local/lib is not in the paths that are searched for the > libraries. that isnt gcc doing the extra /usr/local/lib search. that's the linker using the list of paths in /etc/ld.so.conf for additional search paths. > Also, the path for headers is not displayed hrm, i thought it was. this will indirectly show the include paths: echo "" | gcc -v -E - -mike signature.asc Description: This is a digitally signed message part. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Nightly build log for E17 on 2007-12-04 10:19:54 -0800
Build log for Enlightenment DR 0.17 on 2007-12-04 10:19:54 -0800 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: edvi http://download.enlightenment.org/tests/logs/edvi.log engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Epsilon problems
On 12/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I don't think there's a need to require that 'thumbnailing' > must involve a specific means for storing some standard image format > somewhere.. one may not want or need to store anything really. There's > really very little difference between 'thumbnailing', 'iconifying', > 'pre-viewing', ... or 'full-viewing'. At the very least, it should be a negotiable process where clients can specify the result formats they can support and the thumbnailer can select from those supported formats. A fallback requirement of png or some other standard format would be reasonable. This would allow us to support jpg, mpeg, edje, or whatever format we choose, and any clients that also support those formats could benefit. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
