Re: [E-devel] Announcing EWL 0.5.3
Am Sun, 4 Jan 2009 18:03:03 -0600 schrieb Nathan Ingersoll: Great work! I couldn't read it from below. Does EWL now support Ecore_Evas? Or is composite support now directly included? Are there any plans for it? regards Andreas I'm pleased to announce the release of EWL version 0.5.3. This release has some extensive changes, including the following highlights: * Version 0.5.3: - Fixed compile warnings on 64-bit systems - Improved entry selection and cursor handling - A variety of bug fixes and type corrections - Formatting improvements - Normalized widget realize/unrealize and show/hide - Cleaned out private headers to reduce build times - Rewrite of paned widget - Addition of constructor unit tests - 'Create Directory' button added to filepicker - Kinetic scrolling added to the scrollpane - Stop building unneeded static libraries to reduce build time - The ewl_password widget is now part of ewl_entry to reduce code duplication - Various feature additions to the filepicker family of widgets - Better robustness of ewl_progressbar widget - Split flags into attributes of the ewl_object and ewl_widget objects - Internal XDND support - Improved MVC selection handling - Addition of a SHRINKABLE fill policy - Improved container behaviour - Keybinding support for the ewl_text widget - Addition of an ewl_icondialog widget - Improvement of model terminology - Add an UNMANAGED flag to improve container behaviour - EWL is now Evilized! - Addition of a alpha channel slider to the ewl_colorpicker widget - Autofoo improvements - Expanded support for config key removal - General window management hint improvements - Improved robustness of the ewl_grid widget - Improved widget signal handling - Use merged software X11 engine - Various code cleanups thanks to LLVM static analysis - Removal of original ewl_tree, rename ewl_tree2 to ewl_tree - Moved tutorials from the test files to seperate directory - Creation of coverage report with gcov and lcov is now supported - Addition of ewl_freebox_mvc widget - ewl_embed now inherits from ewl_cell instead of ewl_overlay - Expanding of the ewl_tree widget API - Various fixes and feature additions for the ewl_text widget - Allow the ewl_label widget to be trunctated with '...' - Improved the cosmetics of the debugging macros - Revamped ewl_combo MVC API and implementation - Split widget tests into GUI and unit test cases - Fixed widget reparenting Thank you to the following contributors for making this release possible: Peter Wehrfritz Jaime Thomas Teodor Petrov Dan Sinclair Vincent Torri Stephen Houston This release can be checked out from: http://svn.enlightenment.org/svn/e/tags/ewl/ewl-0.5.3/ -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Thu, Jan 1, 2009 at 2:26 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: ok. i just added some of the things discussed in the efm thoughts thread a few weeks ago: http://trac.enlightenment.org/e/wiki/Release does anyone have anything to add? i'd like focus to pretty much revolve around what's on that list. there are other things being done that are parallel to that list (things some of us are paid to do or are on other project timelines), but otherwise for e17 that list is pretty much the core of what's to be done. some of them are broad items that can encompass a lot of work (make dialogs even if big, work on small screens). i may have missed a few things along the way - again. if you have anything - add it to that page (then mail about it - we can remove it or modify it). but this is what needs doing. if you want to see an e17 release - lets get this stuff done! I did basic categorization of enlightenment items and also remove the idea to drop 16bpp engines as we'll use it in our projects. most showstopper atm is file manager items, I think we can do without them so would flag them (all, or at least most of them) as optional. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Can't install e17 due to Eina.h: No such file or directory
I've been trying for about 3 days to install the latest e17 but without success. At first I was trying to follow the instructions from http://wiki.enlightenment.org/index.php/E17_User_Guide/Installing_from_Source_Repository and after many failed attempts at compiling I ended up downloading and using easy_e17.sh in hopes that it would have all the dir structure and paths in place. But the same error keeps cropping up. Eina install with no issue, but the make for Eet keeps returning the error: eet_data.c:29:18: error: Eina.h: No such file or directory This is getting very frustrating as I would love to try e17 out! Sincerely, Andrew -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 on Cygwin/X platform?
Hi booleanla...@gmail.com, Sorry, I couldn't write to you sooner. (I'm not good at English.) Me, neither :) Regarding winsock2.h AC_CHECK_HEADERS([winsock2.h]) #if !defined(__CYGWIN__) // - wrapped by __CYGWIN__ macro #ifdef HAVE_WINSOCK2_H // - using header specific macro #include winsock2.h #endif #endif /* !defined(__CYGWIN__) */ I would rather handle all the stuff by config.h file and force AC_DEFINE(HAVE_WINSOCK2_H, 0) in cygwin section if needed. Additionally it would be nice to unify the directives among all the components. I think, the current status of #include winsock2.h is not very nice. Eet #if defined(_WIN32) ! defined(__CEGCC__) Ecore (inecore_ipc.c, ecore_ipc) #ifdef HAVE_WINSOCK2_H (but never configured ???) Ecore (ecore_main.c) #ifdef _WIN32 3) Handing OS specific defines such like _POSIX_PATH_MAX e.g. /* embryo_cc_osdefs.h */ #if defined(__CYGWIN__) // wrapped by __CYGWIN__ // because cygwin-patches should not // affect compilation on other platforms #if !defined(_POSIX_PATH_MAX) #define _POSIX_PATH_MAX 255 #endif /* !defined(_POSIX_PATH_MAX) */ #endif /* defined(__CYGWIN__) */ FYI: _POSIX_PATH_MAX has already supported from the initial release by /usr/include/limits.h http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/limits.h?rev=1.1content-type=text/x-cvsweb-markupcvsroot=src I am sorry, _POSIX_PATH_MAX is fine (embryo_cc_osdefs.h includes limits.h), but _POSIX_HOST_NAME_MAX does not exist on Cygwin at all. Therefore I suggest to use #ifdef(__CYGWIN__) // fixing missing define in limints.h #ifndef _POSIX_HOST_NAME_MAX // which could be supported later #define _POSIX_HOST_NAME_MAX 255 #endif #endif close to the beginning of both the e_fm.c and efreet_uri.c files. 4) Unix-like signal handling on windows (siginfo_t supported by cygwin but not by mingw) I think it isn't so serious problem because cygwin supports most of Unix-like signal handling feature to compile Unix-based source files. Or do you want to compile e17 even on mingw? No, I am only interested in Cygwin/X now. I remember I did a lot of dirty patches in E17/043 (severa l#ifndef _WIN32 replacements in Ecore.h, ecore_exe.c, ecore_sginal.c, etc.) in order to use siginfo_t type and Unix-based signal handling. With these changes, the process termination worked much more better. Especially when running E17 for several days, there were no zombie tasks (such like many sh.exe, bash.exe) visible in MS Task Manager. Now I would rather prefer to configure it e.g. by HAVE_SIGNAL_H (disabled on mingw an cegcc because of the missing siginfo_t) rather then using pure #if defined _WIN32 || defined __CYGWIN__ directive. but this is just a religion, it depends on dev conventions :) Best regards, Pavel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] compiling e17 without dbus
Hello list, I'm trying to compile e17 (freshly checked out from public svn repository) without dbus. I have been using e17 from sources for years and am very happy with it. I'm currently using enlightenment 0.16.999.050 (27 oct 2008) on FreeBSD. I don't use, have or need dbus, hal and the like. When I try to compile e with current sources, the configure script complains that I don't have the edbus and ehal packages. And I don't see configure options to disable dbus and hal in e or e_dbus. Are there any ? Or, at last, an option to disable e_fm ? % cd trunk/e % ./autogen.sh --prefix=/usr/local/enlightenment [...] checking for E_REMOTE... yes checking for E_IMC... yes checking for E_THUMB... yes checking for E_FM... configure: error: Package requirements ( ecore ecore-file ecore-ipc eet = 1.0.1 efreet edbus ehal eina-0 ) were not met: gnome-config: not found No package 'edbus' found gnome-config: not found No package 'ehal' found Cheers, Olivier -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/eina/src/lib
Hi, Michael.
thank you, advice.
I move -fno-strict-aliasing flag to configure.ac.
Best Regards.
-=-=-=-=-=-=-=-=-
Naruto TAKAHASHI
tnar...@gmail.com
From: Michael Jennings e-de...@kainx.org
Subject: Re: [E-devel] E SVN: raster trunk/eina/src/lib
Date: Sun, 4 Jan 2009 22:10:11 -0800
On Wednesday, 31 December 2008, at 19:09:48 (-0800),
Enlightenment SVN wrote:
-...@eina_cflags@
+...@eina_cflags@ \
+-fno-strict-aliasing
This breaks portability. If this flag is needed, there must be a
configure.ac test for the acceptability of this flag.
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ m...@kainx.org
Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org)
---
...in order to secure the safety of the public while traveling on
public roads...it shall be unlawful for any person to drive, propel,
or run any vehicle in, upon, and along any of the public roads in
this county. -- Montgomery County, Mississippi, statute
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Index: src/lib/Makefile.am
===
--- src/lib/Makefile.am (revision 38463)
+++ src/lib/Makefile.am (working copy)
@@ -6,8 +6,7 @@
-DPACKAGE_BIN_DIR=\$(bindir)\ \
-DPACKAGE_LIB_DIR=\$(libdir)\ \
-DPACKAGE_DATA_DIR=\$(datadir)/$(PACKAGE)\ \
-...@eina_cflags@ \
--fno-strict-aliasing
+...@eina_cflags@
lib_LTLIBRARIES = libeina.la
Index: configure.ac
===
--- configure.ac (revision 38463)
+++ configure.ac (working copy)
@@ -283,6 +283,12 @@
EINA_CFLAGS=${EINA_CFLAGS} -Wall -W -Wextra # -Werror
fi
+GCC_MAJOR_VERSION=`$CC -dumpversion | sed s/\..*//`
+
+if test $GCC_MAJOR_VERSION = 3 ; then
+ EINA_CFLAGS=${EINA_CFLAGS} -fno-strict-aliasing
+fi
+
AC_SUBST(EINA_CFLAGS)
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Desktop icons
On Mon, Jan 05, 2009 at 09:55:02AM +0100, Andreas Volz wrote: Am Tue, 30 Dec 2008 09:50:39 +0100 schrieb Andreas Volz: Hello again, seems nobody has an answer to my question. Could you at least tell me where this is implemented? Should I search in efreet or the fileman module or in E17 itself? Maybe a short answer from someone who knows it may same me much time. regards Andreas Hello, As default E17 creates two icons Root and Home on my desktop. In Are you completely sure about this? E17 they work well, but if I start e.g. Gnome they don't work good. home.desktop: URL=file:$HOME Icon=fileman/home For some reasons $HOME isn't respected in Gnome. And fileman/home isn't displayed. Similar for root.desktop: URL=file:/ Icon=fileman/root Here the link works, but also the icon isn't displayed. I think if we install files in a well known and shared folder they should work also in other environments. I don't know the freedesktop spec at this point. Are you sure that variable substitutions like $HOME are allowed in .desktop files? Don't you think there's a better way to point to uncommon icon resources? Maybe something like X-Enlightenment-Icon? A fallback Icon could be created automatic by the .desktop creator dialog. Then I've some partitions that I don't like to show on my desktop (raid mirrors). Is it possible to hide some stuff from the desktop? Maybe a .hidden file or a check box in the icon properties to set hidden for each icon? This is really a HAL issue. I have a file /etc/hal/fdi/policy/IgnoreRecovery.fdi to ignore recovery partition. The contents are: ?xml version=1.0 encoding=UTF-8? !-- -*- SGML -*- -- deviceinfo version=0.2 device match key=volume.label string=WinRE merge key=volume.ignore type=booltrue/merge /match /device /deviceinfo regards Andreas -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Announcing EWL 0.5.3
We don't use ecore_evas, but making composite work should be very similar. Peter fixed a bug in the shaped window support which would have also affected composite windows. We do plan to support it, but I'm not sure if anyone has it at the top of their pet project list. On Mon, Jan 5, 2009 at 3:00 AM, Andreas Volz li...@brachttal.net wrote: Am Sun, 4 Jan 2009 18:03:03 -0600 schrieb Nathan Ingersoll: Great work! I couldn't read it from below. Does EWL now support Ecore_Evas? Or is composite support now directly included? Are there any plans for it? regards Andreas I'm pleased to announce the release of EWL version 0.5.3. This release has some extensive changes, including the following highlights: * Version 0.5.3: - Fixed compile warnings on 64-bit systems - Improved entry selection and cursor handling - A variety of bug fixes and type corrections - Formatting improvements - Normalized widget realize/unrealize and show/hide - Cleaned out private headers to reduce build times - Rewrite of paned widget - Addition of constructor unit tests - 'Create Directory' button added to filepicker - Kinetic scrolling added to the scrollpane - Stop building unneeded static libraries to reduce build time - The ewl_password widget is now part of ewl_entry to reduce code duplication - Various feature additions to the filepicker family of widgets - Better robustness of ewl_progressbar widget - Split flags into attributes of the ewl_object and ewl_widget objects - Internal XDND support - Improved MVC selection handling - Addition of a SHRINKABLE fill policy - Improved container behaviour - Keybinding support for the ewl_text widget - Addition of an ewl_icondialog widget - Improvement of model terminology - Add an UNMANAGED flag to improve container behaviour - EWL is now Evilized! - Addition of a alpha channel slider to the ewl_colorpicker widget - Autofoo improvements - Expanded support for config key removal - General window management hint improvements - Improved robustness of the ewl_grid widget - Improved widget signal handling - Use merged software X11 engine - Various code cleanups thanks to LLVM static analysis - Removal of original ewl_tree, rename ewl_tree2 to ewl_tree - Moved tutorials from the test files to seperate directory - Creation of coverage report with gcov and lcov is now supported - Addition of ewl_freebox_mvc widget - ewl_embed now inherits from ewl_cell instead of ewl_overlay - Expanding of the ewl_tree widget API - Various fixes and feature additions for the ewl_text widget - Allow the ewl_label widget to be trunctated with '...' - Improved the cosmetics of the debugging macros - Revamped ewl_combo MVC API and implementation - Split widget tests into GUI and unit test cases - Fixed widget reparenting Thank you to the following contributors for making this release possible: Peter Wehrfritz Jaime Thomas Teodor Petrov Dan Sinclair Vincent Torri Stephen Houston This release can be checked out from: http://svn.enlightenment.org/svn/e/tags/ewl/ewl-0.5.3/ -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] compiling e17 without dbus
Olivier SMEDTS, il 04/01/2009 19:48, scrisse: Hello list, I'm trying to compile e17 (freshly checked out from public svn repository) without dbus. I have been using e17 from sources for years and am very happy with it. I'm currently using enlightenment 0.16.999.050 (27 oct 2008) on FreeBSD. I don't use, have or need dbus, hal and the like. dbus is now needed for e17. I'm on a slack box wich didn't have dbus or hal, I've simply downloaded and built dbus and now I'm able to build and run e17, even if e17 itself is the only app on my system that is actually using dbus. -- Massimo Maiurana massimoatragusa.linux.it http://massimo.solira.org GPG keyID #7044D601 Articolo 33 - [...]Enti e privati hanno il diritto di istituire scuole ed istituti di educazione, senza oneri per lo Stato.[...] -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Desktop icons
Am Mon, 5 Jan 2009 14:54:22 +0300 schrieb Fedor Gusev: On Mon, Jan 05, 2009 at 09:55:02AM +0100, Andreas Volz wrote: Am Tue, 30 Dec 2008 09:50:39 +0100 schrieb Andreas Volz: Hello again, seems nobody has an answer to my question. Could you at least tell me where this is implemented? Should I search in efreet or the fileman module or in E17 itself? Maybe a short answer from someone who knows it may same me much time. regards Andreas Hello, As default E17 creates two icons Root and Home on my desktop. In Are you completely sure about this? I didn't create them by hand. And the icon name fileman/home is a edje resource. Who else than E17 should create it. But not sure since when they are there. I had deactivated desktop icons in E17 for a long time. Maybe a very old configuration of E17 created these files? I've to test it with a new user. E17 they work well, but if I start e.g. Gnome they don't work good. home.desktop: URL=file:$HOME Icon=fileman/home For some reasons $HOME isn't respected in Gnome. And fileman/home isn't displayed. Similar for root.desktop: URL=file:/ Icon=fileman/root Here the link works, but also the icon isn't displayed. I think if we install files in a well known and shared folder they should work also in other environments. I don't know the freedesktop spec at this point. Are you sure that variable substitutions like $HOME are allowed in .desktop files? Don't you think there's a better way to point to uncommon icon resources? Maybe something like X-Enlightenment-Icon? A fallback Icon could be created automatic by the .desktop creator dialog. Then I've some partitions that I don't like to show on my desktop (raid mirrors). Is it possible to hide some stuff from the desktop? Maybe a .hidden file or a check box in the icon properties to set hidden for each icon? This is really a HAL issue. I have a file /etc/hal/fdi/policy/IgnoreRecovery.fdi to ignore recovery partition. The contents are: ?xml version=1.0 encoding=UTF-8? !-- -*- SGML -*- -- deviceinfo version=0.2 device match key=volume.label string=WinRE merge key=volume.ignore type=booltrue/merge /match /device /deviceinfo This helped. Much thanks! regards Andreas -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove the
idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do without
them so would flag them (all, or at least most of them) as optional.
I'd disagree with you here. A nice fm is really important to the end users.
Using external file browser is just an ugly way (imo) and would 1) make less
experienced users ask lots of questions about how to deal with files when
using E (and why (and how) should they bother installing external fm) and 2)
probably distro packagers are going to pack E with Thunar or something and I
don't like that.
I'm aware that the fm is probably one of the hardest things to do in E17,
but it is too important to just... not finish it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, 5 Jan 2009 23:24:46 -0200 Gustavo Sverzut Barbieri
barbi...@profusion.mobi babbled:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove the
idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do without
them so would flag them (all, or at least most of them) as optional.
I'd disagree with you here. A nice fm is really important to the end users.
Using external file browser is just an ugly way (imo) and would 1) make less
experienced users ask lots of questions about how to deal with files when
using E (and why (and how) should they bother installing external fm) and 2)
probably distro packagers are going to pack E with Thunar or something and I
don't like that.
I'm aware that the fm is probably one of the hardest things to do in E17,
but it is too important to just... not finish it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
but these are rather trivial to add - the point is not how many things on the
list but time vs value after implementation. a lot of things are just small do
it right things - others are big fat time-sinks.
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove the
idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do without
them so would flag them (all, or at least most of them) as optional.
I'd disagree with you here. A nice fm is really important to the end users.
Using external file browser is just an ugly way (imo) and would 1) make less
experienced users ask lots of questions about how to deal with files when
using E (and why (and how) should they bother installing external fm) and 2)
probably distro packagers are going to pack E with Thunar or something and I
don't like that.
I'm aware that the fm is probably one of the hardest things to do in E17,
but it is too important to just... not finish it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
--
Hisham Mardam-Bey
http://hisham.cc/
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EWL evas_fb_la_LIBADD patch
2008/12/24 Peter Wehrfritz peter.wehrfr...@web.de: Peter Wehrfritz schrieb: 4 pixels sound like inset or padding pixels. Since the size request happens before the realization some pixels for the inset will be added later, when the theme data is loaded. I think for the framebuffer, unlike to the x11 engine, the engine should take care of resizing evas and not the window. Unfortunately I have not much time before Christmas to look on it. Maybe I'll find the time after the holidays. In order that you report keeps in mind I put it into bugzilla: http://bugs.enlightenment.org/show_bug.cgi?id=553 I changed some days ago the inset and padding functions to keep the outer size invariant, and not the inner size as it was before. This could fix your problem as well. It is not a perfect solution for the fb engine because it is still possible that a window grow to bigger size and set the view to a bigger size then the maximum size allowed by the engine. Peter This does indeed fix the bug. Thanks! -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, 5 Jan 2009 23:40:42 -0500 Hisham Mardam Bey
hisham.mardam...@gmail.com babbled:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove the
idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do without
them so would flag them (all, or at least most of them) as optional.
I'd disagree with you here. A nice fm is really important to the end users.
Using external file browser is just an ugly way (imo) and would 1) make
less experienced users ask lots of questions about how to deal with files
when using E (and why (and how) should they bother installing external fm)
and 2) probably distro packagers are going to pack E with Thunar or
something and I don't like that.
I'm aware that the fm is probably one of the hardest things to do in E17,
but it is too important to just... not finish it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
agreed. and the fm needs to be functional and useful. small things are easy but
core improvements need to be done.
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
On Mon, 5 Jan 2009 23:40:42 -0500
Hisham Mardam Bey hisham.mardam...@gmail.com wrote:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove
the idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do
without them so would flag them (all, or at least most of them)
as optional.
I'd disagree with you here. A nice fm is really important to the
end users. Using external file browser is just an ugly way (imo)
and would 1) make less experienced users ask lots of questions
about how to deal with files when using E (and why (and how)
should they bother installing external fm) and 2) probably distro
packagers are going to pack E with Thunar or something and I don't
like that. I'm aware that the fm is probably one of the hardest
things to do in E17, but it is too important to just... not finish
it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
This is true, but it's also a misconception of the public that all this
time was spent just working on E17. This is hardly the case and many
people are already using the EFL and are mostly awaiting a release so
they have a stable target to develop against. E17 has been a long time
coming for sure, but I think people discount the amount of code that
has been written and the small number of dedicated developers we have.
And the use of the term vaporware is crap as well. Vaporware doesn't
exist at all. E17 and the EFL both exist in a very real way and the
lack of a stable release doesn't change that. If all the code was
closed up and no one could use it, I could see people coming to this
conclusion. Fact is people can use E17 because we have released it via
CVS/SVN. Anyone who calls it vaporware is a moron.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
This is true. People may have been more willing to accept bugs and
such, but it would have also put us in a position of offering a lot
more documentation and support for users who couldn't debug to save
their life, let alone explain their issue clear enough. By releasing
a development version via a source repository you attempt to attract
more developers then users so you can free yourself from answering user
questions 24/7. Of course a lot of users have started using E17 and
that's fine, but they hopefully realize that what they are using is not
finished. People packaging doesn't help that, but we can at least
focus more on development then support.
Now with that said, an initial release will be good as soon as most of
the bugs are ironed out. Feature wise I think we can sacrifice some of
the more advanced and difficult to implement features for the initial
release. For the release, we will need more documentation, tutorials,
etc. It will also require some form of support, but the long time
CVS/SVN users can help with that hopefully.
In any case, I think the biggest thing a release will do is generate a
bit of PR for E and hopefully bring a new rush of developers/users who
are willing and able to help out wherever they can. If anything we will
have a release that can be packaged and users can easily install. This
will lower the amount of build questions that seem to consume so much
of our support time now. So this could be very good for everyone, but
like you said, we need to make sure it's pretty damn good or the
backlash could be brutal. Even if we do make a quality release, I
expect a lot of crap flinging from all angles just because people like
to hate beautiful things :)
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 release stuff
Spot on Mekius. If we had a 6 month roadmap and an alpha release, we'd
have quite a bit of PR and certainly a bit of personal drive. Even
with ewl having releases it gives me drive to try to get the new theme
into the next major version. Im sure other devs would be energised by
a roadmap and release.
Toma.
On 1/6/09, Nick Hughart mek...@mekius.net wrote:
On Mon, 5 Jan 2009 23:40:42 -0500
Hisham Mardam Bey hisham.mardam...@gmail.com wrote:
On Mon, Jan 5, 2009 at 8:24 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
On Mon, Jan 5, 2009 at 8:00 PM, Luchezar Petkov
luchezar.pet...@gmail.com wrote:
On Mon, Jan 5, 2009 at 12:07 PM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I did basic categorization of enlightenment items and also remove
the idea to drop 16bpp engines as we'll use it in our projects.
most showstopper atm is file manager items, I think we can do
without them so would flag them (all, or at least most of them)
as optional.
I'd disagree with you here. A nice fm is really important to the
end users. Using external file browser is just an ugly way (imo)
and would 1) make less experienced users ask lots of questions
about how to deal with files when using E (and why (and how)
should they bother installing external fm) and 2) probably distro
packagers are going to pack E with Thunar or something and I don't
like that. I'm aware that the fm is probably one of the hardest
things to do in E17, but it is too important to just... not finish
it.
But it's mostly working for joe-the-user. Sure, having things like
Ctrl-{x,c,v} is good, but not hard or blocking.
I would just like to point something out quickly here. We (the EFL /
E17 team) have waited so long before doing a release that anything
that is not perfect and done is going to prove exactly what a lot of
the public thinks of EFL / E17; namely that its vapor ware that will
never be completed. We can't afford to release anything that is half
done after this extremely long time period of working on E17.
This is true, but it's also a misconception of the public that all this
time was spent just working on E17. This is hardly the case and many
people are already using the EFL and are mostly awaiting a release so
they have a stable target to develop against. E17 has been a long time
coming for sure, but I think people discount the amount of code that
has been written and the small number of dedicated developers we have.
And the use of the term vaporware is crap as well. Vaporware doesn't
exist at all. E17 and the EFL both exist in a very real way and the
lack of a stable release doesn't change that. If all the code was
closed up and no one could use it, I could see people coming to this
conclusion. Fact is people can use E17 because we have released it via
CVS/SVN. Anyone who calls it vaporware is a moron.
Had we done smaller incremental releases we could have afforded to
introduce incomplete features every now and then, right now, I
personally think we should take that bit of extra time to really
finish and polish anything that is incomplete or simply exclude it
from the release plan and release it afterward as an E17.1 or E17.2.
This is true. People may have been more willing to accept bugs and
such, but it would have also put us in a position of offering a lot
more documentation and support for users who couldn't debug to save
their life, let alone explain their issue clear enough. By releasing
a development version via a source repository you attempt to attract
more developers then users so you can free yourself from answering user
questions 24/7. Of course a lot of users have started using E17 and
that's fine, but they hopefully realize that what they are using is not
finished. People packaging doesn't help that, but we can at least
focus more on development then support.
Now with that said, an initial release will be good as soon as most of
the bugs are ironed out. Feature wise I think we can sacrifice some of
the more advanced and difficult to implement features for the initial
release. For the release, we will need more documentation, tutorials,
etc. It will also require some form of support, but the long time
CVS/SVN users can help with that hopefully.
In any case, I think the biggest thing a release will do is generate a
bit of PR for E and hopefully bring a new rush of developers/users who
are willing and able to help out wherever they can. If anything we will
have a release that can be packaged and users can easily install. This
will lower the amount of build questions that seem to consume so much
of our support time now. So this could be very good for everyone, but
like you said, we need to make sure it's pretty damn good or the
backlash could be brutal. Even if we do make a quality release, I
expect a lot of crap flinging from all angles just because people like
to hate beautiful things :)
