Re: [E-devel] Debian package fixes
On Wed, Sep 06, 2006 at 07:58:10AM +0900, Carsten Haitzler wrote:
On Tue, 5 Sep 2006 23:53:54 +0200 Jens Taprogge [EMAIL PROTECTED]
babbled:
Hello.
I have recently build a more or less complete set of Debian packges of
the EFL and certain apps.
I stumbled across a few minor issues. Please find two patches attached
that fix those (one for the libs the other for the apps).
Best Regards
Jens Taprogge
this patch:
--- e/debian/rules3 Sep 2006 18:58:31 - 1.13
+++ e/debian/rules5 Sep 2006 23:08:24 -
@@ -8,7 +8,7 @@
install/enlightenment::
mkdir debian/enlightenment/etc
- mv debian/tmp/usr/etc/enlightenment debian/enlightenment/etc/
+ mv debian/tmp/etc/enlightenment debian/enlightenment/etc/
clean::
if [ -f $(CURDIR)/../../snapshot ]; then ./autogen.sh --prefix=/usr; fi
that doesn't make sense - by default the etc. dir ends up in prefix/etc -
unless you play with configure --options etc. (${sysconfdir}). why did the
first changes (whihch seem right) obey the prefix and yours don't? i suspect
somethgin weird here.
I am not sure if this is true for things going into $(sysconfidir). It
somewhat makes sense that autofoo is installing the file in /etc and not
/usr/etc. Anyway the build was from a fresh checkout.
btw - evas patch not going in. gl engine isn't being
turned on by default in the src (if gl headers found) for a good reason. not
going to turn it on in the packages. the gl engine is a 2nd class citizen at
the moment.
Perhaps the gl engine should be disabled in the control file then? Also
the EWL GL engine should not be packaged in this case. The way things
are now an empty evsas0-engine-gl-x11 package is created which causes
the packaging of EWL to fail.
Best Regards
Jens Taprogge
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
Jorge writes: I tell you what, let me look things over a bit during the weekend, and if you like you and maybe Jorge can do the same... maybe discuss it with others on the list who have some experience with evas/objects/engines and we can take it up again on Mon or Tues, and maybe Carsten can add some thoughts. i think we need to actually write what are our main goals with this, not only rewrite some internal evas stuff. what i would like to have on evas is: The issue is not to rewrite some internal evas stuff just for the heck of it.. It's to fix a large number of aspects that prevent the lib from scaling to support much more than what it now does.. and prevent it from supporting even slight additions without a large amount of effort.. and a few other things as well that need to be fixed. Unfortunately, to do this right means re-writing much of the internals.. no simple little piece-meal 'patches' are going to do it. - simplify the creation of render engines. - support font engines. freetype should be one of them. - make objects be modules too - actually make objects render by themselves to an argb buffer - split huge headers into smaller ones. - support for a mechanism to make evoak work nicely with evas (callbacks, remote engine, whatever) - (add more) Much of this cannot be done in 'isolation' without a coherent view of the final target design/capabilities that one wants the lib to have. Let me address some of the above, as I see things... -- support font engines. freetype should be one of them. I hope you realize what a pain font/text related stuff is! I would say that this is not really that important right now, but is certainly something to be kept in mind. Long ago (or so it seems), I wrote font loaders for imlib2. At the time, freetype didn't support xfonts so I had loaders for ttf fonts, xfonts, and fnlib fonts. I also had font stylers, which were also loadable modules and could 'style' any input glyphs.. I had something like three such 'stylers' I think. They could layer/composite glyphs, texture them with images or grads, bumpmap them with light sources, shadows, rotate/skew them, modify glyph advances, and other things.. xml files described what they would do. Unfortunately, I had to break the imlib2 api to do this since it wasn't adequate for the needs of such beasties... Carsten may still have the code for this somewhere as I sent it to him then. -- simplify the creation of render engines. This, per se, needs at least three things to begin with, as I mentioned earlier: get/put and composite argb buffer functions, and also a generic cache mechanism. This latter is needed for several things.. least of all to cut back on needless code duplication. I hope everyone knows that if you call the evas api function evas_image_cache_set(evas, size) you will not only be setting the cache size for that 'evas' instance, but also for every evas that uses the same engine. If some code sets the cache size to 0 for one software-x11 evas canvas, they will have flushed the image cache and set it to 0 for every software-x11 evas the program/lib deals with, and also flush the more common image cache that all buffer-evases use. If some code somewhere sets the image cache to 0 for one buffer evas instance, it will flush the image cache for all such and there will be no further image caching by any buffer evas, or ecore sub-canvases, until some other code resets the cache size for one buffer evas somewhere... I wrote a simple quick one once as well, using the current evas hash/list implementation and following the basic pattern used for image caching, etc.. It had a fairly straightforward api which Carsten and I discussed somewhat. But to stick this into evas requires a moderate amount of work, and as no one seems concerned with the above caching issues or with the internal code duplication, so I just let it go. This kind of thing is something that ecore could use as well though. Now, as to the get/put and composite funcs.. that's fairly straightforward.. although to do this at all would be best done in conjunction with the move to premul data, which together forms not- so-small an amount of work. -- make objects be modules too. Ah This is something I've been mentioning for months, but no one seemed to care about. I sent Carsten some preliminary notes on this, some data structures and design preliminaries needed, etc.. But it requires a lot of work to fully realize this - to make it work in tandem with loadable types and arbitrary engines.. and no one seemed much interested in this. Should I further pursue such a large re-write, which no one has much enthusiasm or support for, and then just throw it over...? -- split huge headers into smaller ones. Which headers? For
Re: [E-devel] .eap files for modules
On Fri, 10 Mar 2006 00:09:24 +0900 David Stevenson [EMAIL PROTECTED] babbled: anyway - in removing the ipc, we also remove all the code needing to handle if/when the modules are screwed with from elsewhere etc. making e 1. more maintainable, 2. less liable to have bugs, 3. smaller, 4. faster to develop for. i am ONLY proposing we remove the ipc handlers for stuff that *IS* fully implemented in a gui. then it acts also as a todo list of things we need to still add a gui for :) I hope other readers haven't missed this, buried deep into my tedious email - others will surely have thoughts on this. As a user I personally only use enlightenment_remote for re-setting my config after it gets wiped out (this is quite nice really, during development). Otherwise, hmmm. actually - the code is not at a stage where it almost never wipes config - just extends - so e_ipc's usefulness is becoming dubious. for code that makes up 5% of e17's code in 1 lump - thats a lot of code that has dubious use value when the same features are available via the gui. the gui should also prevent users shooting themselves in the foot - ipc doesn't. i woudln't remove it entirely, but i'd heavily trip it down to maybe issuing restarts, exit, logout etc. requests - feeding in actions from a script, and maybe later querying for data that might be useful from management scripts. Restarting on the one time you change your language is not too bad I guess... yeah - we can live with it. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] edje and event objects
On Fri, 16 Sep 2005 05:28:38 -0400 Jose O Gonzalez [EMAIL PROTECTED] babbled: On Fri, 16 Sep 2005 16:18:50 +0900 Carsten writes: On Fri, 16 Sep 2005 01:44:42 -0400 Jose O Gonzalez [EMAIL PROTECTED] babbled: Let me sharply critical here. Unfortunately for many other libs and apps, if evas is the graphics engine they use, it's important to get it more than just good enough -- as they will later find themselves stuck in the situation where what was good enough earlier is not quite good enough anymore.. What then? true. but given that i only have a few hrs a week to do this stuff. what do i work on? e is a priority. likely above evas in priority right now. I know.. But it's not just evas I'm trying to point to here. There are general patterns here, going beyond anything to do with evas in particular, that lead to such things recurring again and again... hampering the potential growth and development of e in the larger sense. a lot of them can be changed internally at this stage and hidden/wrapped by ecore_evas (ie if we move event handling to an explicit process call). so only those doing their own display target bindings are affected (very few). for smart objects i think we cna do this all internally with no api-side effects so we can do this at any time in the future :) i actually wouldnt mind getting right of the smart class creator that accepts like 10 args forall the methods, but instead use the one that accepts the smart as a struct - we can then expand that strucxt until the cows come home. it's alreayd there, just not used. Ok. Let's talk about canvas/gfx specific issues a bit. Two key elements: rendering and event-handling. But how do we deal with them and integrate them - what's the model? And what can we 'use' to do this? We need an immediate-mode rendering engine.. let's get it out of the canvas so it can be accessed itself. This needs a variety of other things.. including things like dealing with image loading, font loading, and others. It needs file-handling routines, string-handling routines, caching mechanisms, etc.. Where do they come from? We need a retained-mode canvas model.. What is it? There are many 'canvases' one can have, as I pointed out to you in some emails.. Which objects with what apis does one settle on? Why? Then, what is the event-model? And where does it come from? all of the above we already have - the only part you don't have is a broken out rendering model - notice there is an evas imaging api - that was the intended start of providing a virtualised immediate-mode api to whatever the engine provides so you can draw to a buffer object of some sort. Sure we can fix smart-objects in evas.. But, why? What is it that you really want that smart-objects gave you initially? smart objects started as we want groups ie move 1 object and they all move. that was too limited - so smart objects covered a whole range of things - including that. you define how that group moves, if moved, etc. etc. they start to become troublesome with things like edje, once they get very heavily used. for some things you want to define the drawing routine for the object and nothing else (thus the imaging api could be a set of tools for just that). If e aims to be a gui platform of some sort, say eg. a desktop shell, then it needs to take a serious look at its foundations.. its subsystems... indeed - if i had the time i'd be devoting it there. :) That is where you are needed most man! i am needed everywhere :( i have an inbox that is perpetually overflowing with things to reply to :(. i have been trying to farm off work over the past year and drop almost everything that isn't within my direct view/focus. you might not realise that by the time i get home on a weeknight, and i do my email- i might find 1hr - on a good day, to do something. often it is spent going over other peoples stuff, testing, fixing, and answering questions on irc from other devs and users. my problem is that i just do not have time. this is a personal issue where there is a project that has grown so big and it's beyond management resources - but no one will step up to fix that. the solution isn't more people - more people is more cooks. more cooks with each having some half or quarter idea of what is actually happening just ends up a mess. we need more people who have fulltime to focus and devote to it. that of course requires money. someone to either hire them to do the work, or someone to drop a lot of cash somewhere to pay rents, mortgages, buy food etc. wherever i am needed most - i have only so much time to devote. i can devote 3 minutes to all the things that need me - then what? it will be enough time to start looking at them, nothing more. nothing will ever get done :( i appreciate your concerns - i really do,
Re: [E-devel] image-scaling patch..
On Tue, 13 Jun 2006 03:43:07 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Attached is a small patch to address the 'images with borders' scaling issue mentioned earlier. and better late than never... ok - this is now in - thanks jose! :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] discussion: new features in E. try 2.
On Sat, 10 Jun 2006 20:52:44 + Aleksej Struk [EMAIL PROTECTED] babbled:
Hey raster,
H, actually, I already implemented all the things in
e_modules/language module. Now it is standalone. It is able to manage
actual input language for each window, and flip between keybord
layouts on the fly. Moreover it hooks into E and defines 2 new actions
and keybindings for them as it starts, and removes those actions and
keybindings on unload.
I want to make one more hook into E. For now there exists a config
dialog for the module. I'd like to hook it into the E main config
panel. As far as I remmember there is a FIXME for
this :)
Unfortunatelly, somehow I missed ur mail. But now, I'll review the
module once again wrt to your comments.
Of course, I'd like to move some of the module's functionality
directly to E. For
example language settings per window. Consequently, this will remove
some expensive searches and management of the running windows, since
the module will know everything as soon as it gets a pointer to a
border in callback :).
But, if I move some of its functionality to E, then it will be
dependent on E. And actually, the module will only flip the input
keyboard layout and visualize the current language icon.
So, then it cannot be standalone as now.
Ofcourse, since the module works now, at least for me :), because I
did not hear any comments about it yet, there is no need to reinvent
it, to reprogram it and to place some of its functionality into E.
Also, from my point of view, it would be nice to have it in the main E
src tree, because, when non-english people starts a WM they'd like to
have language tools immideately and without looking for the 3rd party
module. What do u think about this ?
i agree. it is definitely useful for people who need to change languages and
keymaps often and non-english speakers. the problem is goign to be making sure
the code is generic enough to handle all languages properly and that it is
clean. i will take a look at the language module at some point and see - either
the module might get sucked in - or parts of its code will be - either way -
your work becomes useful :)
sndev
On 6/6/06, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote:
On Mon, 10 Apr 2006 12:18:20 + Aleksej Struk [EMAIL PROTECTED]
babbled:
Hi all devs,
I just repost my previous mail, since I did not get any comments on it
yet :(
and here come my comments (finally!) :)
I would like to start a new discussion regarding E features.
During the past time I usually use 2 different languages for input in
my work. This languages are english and russian. So, in order to be
able to switch between them I use setxkbmap program of the X11. I wrote
a script which does language switching for me. This scrip, actually,
looks as follows:
#!/bin/sh
f=`setxkbmap -print | grep xkb_symbols | awk '{printf $4}' | cut -d '+'
-f 2`
if [ $f = us ]; then
setxkbmap -model compaqik13 -layout ru -variant basic
elif [ $f = us(basic) ]; then
setxkbmap -model compaqik13 -layout ru -variant basic
elif [ $f = ru(basic) ]; then
setxkbmap -model compaqik13 -layout us -variant basic
fi
ok - so basically u want to flip keymap on the fly and maybe have e flip
keymap for you automatically as focus changes to different windows.
definitely makes sense.
However, it is not comfortable enought. First of all, I do not have
any visual representation of my current language selection. Second,
i think something in the titlebar of windows and/or in the window menu
displaying some little flag for the keymap (the idea behind gadcon is to be
able to add module output (gadcon clients) to things like borders, menus
etc.) for example is what you want (and maybe a menu to select which keymap
to use when that window is focused (if it's not the default), set up a
default keymap, another temporary keymap to choose etc. might be what you
want - right? there will nee to be a way to remember which windows use what
keymaps (put it into the remember settings?)
such a way of switching language is global. So, if I turn, for example,
russian language, I will have it everywhere and in every application I
currently use, but it would be nice to have some local language selection
per application. Finally, I already had some troubles with non-english :)
language and desktop locking. If I turn, for example, russian language
and then lock the screen from the menu, or by using shortcut, for
example ctrl+F12, I'm not able to unlock my desktop, since the ASCII
code values of russian letters are greater that 128 and E, basically,
do not accept them. Please do not refere to locale settings in this
situation :) since I prefer to work in C locale or en_US.
I would like to propose to implement such a language switchin mechanism
in E, which is similar to the script
Re: [E-devel] Premultiply or not
On Tue, 4 Jul 2006 04:18:18 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Jose writes: correct. non-premul to premul is destructive. VISUALLY it will look the same when composited, BUT this should be an understanding - correct. Yes, that's right. It destroys the superflous information that may be contained in the overdetermined inputs - as far as the actual compositing is concerned. I should add that this is also one reason why we want to work entirely in premul color space - so we don't have to premul anything, we just assume the inputs to be so and simply use them as given. If one instead assumes the inputs to be non-premul, then one has to, at the compositing stage, premultiply them -- what you input is not really what gets used for compositing. Carsten writes: well actually i was thinking ALL engines would use premul ARGB by DEFAULT unless you tell them that you want to get/set pixel data in another colorspace (yuv, yuva (planar, interleaved etc.), non-premul argb etc. etc.). IF the engine CAN handle the format natively (eg some yuv formats if we have xvideo accel) then the engine will avoid any conversion internally and deal with it as-is. if it cannot - then it will convert as needed internally. What engine is going to handle non-premul argb natively? That's what evas' software engines do right now, and creates the inconsistency with the render engine. You can't perform transforms in non-premul color space and expect to obtain the same results as similar transforms in premul color space. You are mixing two different kinds of things here - yuv vs rgb is NOT the same thing as premul vs non-premul. i know - engine are allowed to make approximations though - it is valid :) i am talkign theory here though. *IF* the destination targets can't do rpemul the engine will have to convert to non-premul just like the xrender enigne converts to premul... :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Premultiply or not
On Tue, 4 Jul 2006 00:47:52 GMT [EMAIL PROTECTED] [EMAIL PROTECTED] babbled: Let's agree on one thing: The gfx operations, unless otherwise explicitly stated, will be done in premul argb color space, or a linear equivalent of it.. agreed - with possible FUTURE ability to use more esoteric colorspaces like YUV (though frankly yuv is handled most sanley by a convert to yuv first - BUT you can actually get speedups combining the scale and convert at the same time) Ok good, at least we're getting somewhere :) Ok, fine.. and actually premul ayuv would be ok too since when decoded yuv is linearly related to rgb (hsv eg. is not). There's already such an interface to set imported data from yuv, and moving the 'conversion' to rgb down to the engines is fine as they may simply be able to deal with it directly, etc.. That's all good, and an interface for importing yuv to image data is already there, you can extend it to cover any premul ayuv format type with no problem. sure - and i would suggest we expand it to also import non-premul ARGB - thats basically all i was really suggesting. :) That would be the best way to do it, yeah :) Let's assume that edje has been modified to pass premul colors/data to evas, and eet saves premul data, and that evas provides premul/non-premul conversion api functions for colors data.. Just where exactly in e17 would there be even minor pain caused by evas being premul only? every edje design (.edc's) that specifies a color for text or solids, clips etc. any app that sets an object color itself. there are 74 calls to evas_object_color_set in e17. e17's creation of netwm icons would need to do a premul step. 54 in edje. more in ewl, etk etc. etc. now with edje - do we force the .edc's to specify colors in premul? if so there are (evil) 666 instances of colors in e17's default theme - or do we have edje_cc convert to premul on encode - or do we have edje turn into premul runtime?... how far do you go? :) Ok I looked at the e17 ones. Nearly all of them are of two kinds: either setting a color that's already premul (usually opaque white or transp black), or for defining some smart-class' color-set callback. Neither case needs anything done (color-set smart callbacks would expect premul inputs). That leaves about 6 left I think. Anyway... I think it might be best to let the edc format stay as it is (non-premul colors), and have edje do the conversion, not edje_cc. If desired, a later edje can have other types and/or versions of 'design-formats', like edc, and one can do whatever.. There are possibilities for things that are very interesting with premul colors, and having evas handle premul colors, as given, would allow for that. agreed - now i have had time to mull. break the color_set - make it premul. we have anon-premul-import for convenience, and we modify all the code we can 0 edje converts at runtime before color_set when using config valued in the .edj. ;) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Debian package fixes
On Wed, 6 Sep 2006 09:28:11 +0200 Jens Taprogge [EMAIL PROTECTED]
babbled:
On Wed, Sep 06, 2006 at 07:58:10AM +0900, Carsten Haitzler wrote:
On Tue, 5 Sep 2006 23:53:54 +0200 Jens Taprogge [EMAIL PROTECTED]
babbled:
Hello.
I have recently build a more or less complete set of Debian packges of
the EFL and certain apps.
I stumbled across a few minor issues. Please find two patches attached
that fix those (one for the libs the other for the apps).
Best Regards
Jens Taprogge
this patch:
--- e/debian/rules 3 Sep 2006 18:58:31 - 1.13
+++ e/debian/rules 5 Sep 2006 23:08:24 -
@@ -8,7 +8,7 @@
install/enlightenment::
mkdir debian/enlightenment/etc
- mv debian/tmp/usr/etc/enlightenment debian/enlightenment/etc/
+ mv debian/tmp/etc/enlightenment debian/enlightenment/etc/
clean::
if [ -f $(CURDIR)/../../snapshot ]; then ./autogen.sh
--prefix=/usr; fi
that doesn't make sense - by default the etc. dir ends up in prefix/etc -
unless you play with configure --options etc. (${sysconfdir}). why did the
first changes (whihch seem right) obey the prefix and yours don't? i suspect
somethgin weird here.
I am not sure if this is true for things going into $(sysconfidir). It
somewhat makes sense that autofoo is installing the file in /etc and not
/usr/etc. Anyway the build was from a fresh checkout.
well by default it goes into /usr/local/etc (if the prefix is /usr/local) -
thats what it does from source if you don't patch it or do anything different.
btw - evas patch not going in. gl engine isn't being
turned on by default in the src (if gl headers found) for a good reason. not
going to turn it on in the packages. the gl engine is a 2nd class citizen at
the moment.
Perhaps the gl engine should be disabled in the control file then? Also
the EWL GL engine should not be packaged in this case. The way things
are now an empty evsas0-engine-gl-x11 package is created which causes
the packaging of EWL to fail.
the gl package should be entirely optional - but suggestion is not to create
them. remember the packaging in cvs is a guide/suggestion/base for the real
packages to build off - they should follow it closely, imho, but they can make
small adjustments. the gl package info is there in case it is needed.
Best Regards
Jens Taprogge
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___ enlightenment-devel mailing
list enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
On Wed, Sep 06, 2006 at 07:34:48AM +, [EMAIL PROTECTED] wrote: snip It's going to be just about impossible to do this any other way than with a separate CVS version to work with. A branch should work, right? To me the main issue is not really a 'technical' one pre se, it's do people really want, and want to help with, such changes? Right now, I think the response you're going to get from most of us is: Wait until e17 is out the door. Evas may have issues, but, our main focus at this time is getting a long awaited product released and in the wild. However, this does mean that Evas will also be in the wild, making drastic API changes more painful on end users of the library. So, maybe we should prioritize the changes (premul seems a higher up candidate). I just don't think that we should take what little dev time we have and suck it into overhauling evas (which, unfortunately, is 'good enough' for our current purposes). Maybe we just need to clarify what changes are planned when we release so that potential users of the lib will be aware of them? rephorm. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Binding clearing actions
Hi!
Here's a patch to include ipc handlers for clearing all
Mouse/Key/Signal/Wheel bindings in E. Though it is theoretically
possible for an external program to read through the existing
keybindings and erase them one after the other, this offers a faster
and cleaner solution. This is useful when an external script is used
to fully configure the keybindings from scratch, ignoring the default
keybindings of E.
Regards,
Ramkumar.
--
April 1: This is the day upon which we are reminded of
what we are on the other three hundred and sixty-four.
-- Mark Twain, Pudd'nhead Wilson's Calendar
ProxyChains-3.1 (http://proxychains.sf.net)
Index: e_bindings.c
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_bindings.c,v
retrieving revision 1.33
diff -u -r1.33 e_bindings.c
--- e_bindings.c23 Aug 2006 00:34:33 - 1.33
+++ e_bindings.c6 Sep 2006 13:44:36 -
@@ -81,38 +81,10 @@
EAPI int
e_bindings_shutdown(void)
{
- while (mouse_bindings)
- {
- E_Binding_Mouse *bind;
-
- bind = mouse_bindings-data;
- mouse_bindings = evas_list_remove_list(mouse_bindings, mouse_bindings);
- _e_bindings_mouse_free(bind);
- }
- while (key_bindings)
- {
- E_Binding_Key *bind;
-
- bind = key_bindings-data;
- key_bindings = evas_list_remove_list(key_bindings, key_bindings);
- _e_bindings_key_free(bind);
- }
- while (signal_bindings)
- {
- E_Binding_Signal *bind;
-
- bind = signal_bindings-data;
- signal_bindings = evas_list_remove_list(signal_bindings,
signal_bindings);
- _e_bindings_signal_free(bind);
- }
- while (wheel_bindings)
- {
- E_Binding_Wheel *bind;
-
- bind = wheel_bindings-data;
- wheel_bindings = evas_list_remove_list(wheel_bindings, wheel_bindings);
- _e_bindings_wheel_free(bind);
- }
+ e_bindings_mouse_clear();
+ e_bindings_key_clear();
+ e_bindings_signal_clear();
+ e_bindings_wheel_clear();
return 1;
}
@@ -158,6 +130,19 @@
}
EAPI void
+e_bindings_mouse_clear()
+{
+ while (mouse_bindings)
+ {
+ E_Binding_Mouse *bind;
+
+ bind = mouse_bindings-data;
+ mouse_bindings = evas_list_remove_list(mouse_bindings, mouse_bindings);
+ _e_bindings_mouse_free(bind);
+ }
+}
+
+EAPI void
e_bindings_mouse_grab(E_Binding_Context ctxt, Ecore_X_Window win)
{
Evas_List *l;
@@ -350,6 +335,19 @@
}
EAPI void
+e_bindings_key_clear()
+{
+ while (key_bindings)
+ {
+ E_Binding_Key *bind;
+
+ bind = key_bindings-data;
+ key_bindings = evas_list_remove_list(key_bindings, key_bindings);
+ _e_bindings_key_free(bind);
+ }
+}
+
+EAPI void
e_bindings_key_grab(E_Binding_Context ctxt, Ecore_X_Window win)
{
Evas_List *l;
@@ -520,6 +518,19 @@
}
}
+EAPI void
+e_bindings_signal_clear()
+{
+ while (signal_bindings)
+ {
+ E_Binding_Signal *bind;
+
+ bind = signal_bindings-data;
+ signal_bindings = evas_list_remove_list(signal_bindings,
signal_bindings);
+ _e_bindings_signal_free(bind);
+ }
+}
+
EAPI E_Action *
e_bindings_signal_find(E_Binding_Context ctxt, E_Object *obj, const char *sig,
const char *src, E_Binding_Signal **bind_ret)
{
@@ -612,6 +623,19 @@
wheel_bindings = evas_list_remove_list(wheel_bindings, l);
break;
}
+ }
+}
+
+EAPI void
+e_bindings_wheel_clear()
+{
+ while (wheel_bindings)
+ {
+ E_Binding_Wheel *bind;
+
+ bind = wheel_bindings-data;
+ wheel_bindings = evas_list_remove_list(wheel_bindings, wheel_bindings);
+ _e_bindings_wheel_free(bind);
}
}
Index: e_bindings.h
===
RCS file: /cvs/e/e17/apps/e/src/bin/e_bindings.h,v
retrieving revision 1.14
diff -u -r1.14 e_bindings.h
--- e_bindings.h21 Aug 2006 16:25:57 - 1.14
+++ e_bindings.h6 Sep 2006 13:44:36 -
@@ -86,6 +86,7 @@
EAPI voide_bindings_mouse_add(E_Binding_Context ctxt, int button,
E_Binding_Modifier mod, int any_mod, const char *action, const char *params);
EAPI voide_bindings_mouse_del(E_Binding_Context ctxt, int button,
E_Binding_Modifier mod, int any_mod, const char *action, const char *params);
+EAPI voide_bindings_mouse_clear(void);
EAPI voide_bindings_mouse_grab(E_Binding_Context ctxt, Ecore_X_Window
win);
EAPI voide_bindings_mouse_ungrab(E_Binding_Context ctxt,
Ecore_X_Window win);
EAPI E_Action *e_bindings_mouse_down_find(E_Binding_Context ctxt, E_Object
*obj, Ecore_X_Event_Mouse_Button_Down *ev, E_Binding_Mouse **bind_ret);
@@ -95,6 +96,7 @@
EAPI voide_bindings_key_add(E_Binding_Context ctxt, const char *key,
E_Binding_Modifier mod, int any_mod, const char *action, const char *params);
EAPI voide_bindings_key_del(E_Binding_Context
Re: [E-devel] Evas Evoak future changes
Brian writes: To me the main issue is not really a 'technical' one pre se, it's do people really want, and want to help with, such changes? Right now, I think the response you're going to get from most of us is: Wait until e17 is out the door. Evas may have issues, but, our main focus at this time is getting a long awaited product released and in the wild. However, this does mean that Evas will also be in the wild, making drastic API changes more painful on end users of the library. So, maybe we should prioritize the changes (premul seems a higher up candidate). The only api 'change' that I know of anyone having in mind is the change to premul semantics. But as far as large or radical api changes, evas has already had some.. eg. the textblock. Part of the benefit of having loadable object types is to minimize the need for such things happening. But mostly it's to provide a better base on which to build - to build apps, not to fiddle with the lib for the hell of it. If people don't understand this then I don't know what to tell you. I just don't think that we should take what little dev time we have and suck it into overhauling evas (which, unfortunately, is 'good enough' for our current purposes). Then it's likely not going to happen and will thus stay 'good enough' until deemed otherwise. A concensus needs to be reached on what needs work and what doesn't.. it can't be carried or be decided on by one person alone, wether it be me or Carsten or whomever.. Some things can be done here and there, but major work needs more than that. Maybe we just need to clarify what changes are planned when we release so that potential users of the lib will be aware of them? jose. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
On Wed, Sep 06, 2006 at 03:22:39PM +, [EMAIL PROTECTED] wrote: Brian writes: To me the main issue is not really a 'technical' one pre se, it's do people really want, and want to help with, such changes? Right now, I think the response you're going to get from most of us is: Wait until e17 is out the door. Evas may have issues, but, our main focus at this time is getting a long awaited product released and in the wild. However, this does mean that Evas will also be in the wild, making drastic API changes more painful on end users of the library. So, maybe we should prioritize the changes (premul seems a higher up candidate). The only api 'change' that I know of anyone having in mind is the change to premul semantics. But as far as large or radical api changes, evas has already had some.. eg. the textblock. Part of the benefit of having loadable object types is to minimize the need for such things happening. But mostly it's to provide a better base on which to build - to build apps, not to fiddle with the lib for the hell of it. If people don't understand this then I don't know what to tell you. I realize this. I never said anything about lib fiddling :) I totally agree that evas needs some work. I would love true loadable objects with a well defined interface so we can more easily extend things. All I'm saying is that we have very little dev power to divy up between everything that needs doing. I just don't think that we should take what little dev time we have and suck it into overhauling evas (which, unfortunately, is 'good enough' for our current purposes). Then it's likely not going to happen and will thus stay 'good enough' until deemed otherwise. A concensus needs to be reached on what needs work and what doesn't.. it can't be carried or be decided on by one person alone, wether it be me or Carsten or whomever.. Some things can be done here and there, but major work needs more than that. I think we need to get e17 out, and THEN bump this up to top priority. (With the exception of pre-mul, which, due to the API shift, should probably be done before any evas release). However, that said, we're a pretty unguided mass of transient coders, with different goals and desires. Maybe its just my lack of familiarity with evas internals that forms my opinion. :) rephorm. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
On 9/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, Sep 06, 2006 at 03:22:39PM +, [EMAIL PROTECTED] wrote: Brian writes: To me the main issue is not really a 'technical' one pre se, it's do people really want, and want to help with, such changes? Right now, I think the response you're going to get from most of us is: Wait until e17 is out the door. Evas may have issues, but, our main focus at this time is getting a long awaited product released and in the wild. However, this does mean that Evas will also be in the wild, making drastic API changes more painful on end users of the library. So, maybe we should prioritize the changes (premul seems a higher up candidate). The only api 'change' that I know of anyone having in mind is the change to premul semantics. But as far as large or radical api changes, evas has already had some.. eg. the textblock. Part of the benefit of having loadable object types is to minimize the need for such things happening. But mostly it's to provide a better base on which to build - to build apps, not to fiddle with the lib for the hell of it. If people don't understand this then I don't know what to tell you. I realize this. I never said anything about lib fiddling :) I totally agree that evas needs some work. I would love true loadable objects with a well defined interface so we can more easily extend things. All I'm saying is that we have very little dev power to divy up between everything that needs doing. I just don't think that we should take what little dev time we have and suck it into overhauling evas (which, unfortunately, is 'good enough' for our current purposes). Then it's likely not going to happen and will thus stay 'good enough' until deemed otherwise. A concensus needs to be reached on what needs work and what doesn't.. it can't be carried or be decided on by one person alone, wether it be me or Carsten or whomever.. Some things can be done here and there, but major work needs more than that. I think we need to get e17 out, and THEN bump this up to top priority. (With the exception of pre-mul, which, due to the API shift, should probably be done before any evas release). However, that said, we're a pretty unguided mass of transient coders, with different goals and desires. Maybe its just my lack of familiarity with evas internals that forms my opinion. :) well i dont totally agree, i mean, i started this discussion with some ideas i would like to have implemented on evas, i guess jose thinks the same. so this thread is to actually THINK and WRITE what are the future goals of evas (that's why the topic is called like that). and looks like im not the only one with some evas' ideas . if e17 is a priority i agree but im not actually coding it, instead i would like to settle down the base of what will be the next evas. what other opinions can we receive but yours? (developers and evas users). so if this ends to be actually a branch ill be glad to code it, e17 will still use current evas branch and everyone happy :) we can code in parallel. might be double effort to then merge both branches, but that's why branches are for :) i agree when you say that evas is good enough for the libs/apps we have. but if would like to actually be able to code more fancy/good stuff evas has to evolve, and must evolve from an evas developer point of view (possibility to extend evas functionality) basically i think evas api wont change too much, the premul color thing will end up with another layer between the colors used on edje and the current colors used (current color space - premul), what we are looking for is an evas internal refactoring. rephorm. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Binding clearing actions
On Wed, 6 Sep 2006 19:25:37 +0530 R.Ramkumar [EMAIL PROTECTED] babbled: Hi! Here's a patch to include ipc handlers for clearing all Mouse/Key/Signal/Wheel bindings in E. Though it is theoretically possible for an external program to read through the existing keybindings and erase them one after the other, this offers a faster and cleaner solution. This is useful when an external script is used to fully configure the keybindings from scratch, ignoring the default keybindings of E. for now i don't think it's wise to accept this. as per previous emails - i have the ipc config in my sights to nuke because once we have a complete gui for all the config - there is no need to keep a very big lump of code for doing this via ipc (not to mention that it is incomplete and lets you shoot yourself in the foot etc. etc.) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas Evoak future changes
On 9/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Jorge writes: I tell you what, let me look things over a bit during the weekend, and if you like you and maybe Jorge can do the same... maybe discuss it with others on the list who have some experience with evas/objects/engines and we can take it up again on Mon or Tues, and maybe Carsten can add some thoughts. i think we need to actually write what are our main goals with this, not only rewrite some internal evas stuff. what i would like to have on evas is: The issue is not to rewrite some internal evas stuff just for the heck of it.. It's to fix a large number of aspects that prevent the lib from scaling to support much more than what it now does.. and prevent it from supporting even slight additions without a large amount of effort.. and a few other things as well that need to be fixed. Unfortunately, to do this right means re-writing much of the internals.. no simple little piece-meal 'patches' are going to do it. - simplify the creation of render engines. - support font engines. freetype should be one of them. - make objects be modules too - actually make objects render by themselves to an argb buffer - split huge headers into smaller ones. - support for a mechanism to make evoak work nicely with evas (callbacks, remote engine, whatever) - (add more) Much of this cannot be done in 'isolation' without a coherent view of the final target design/capabilities that one wants the lib to have. Let me address some of the above, as I see things... -- support font engines. freetype should be one of them. I hope you realize what a pain font/text related stuff is! I would say that this is not really that important right now, but is certainly something to be kept in mind. yes i do, that's why i wrote it :) the font handling on evas is kind of messy i guess because fonts handling by definition is actually messy, dunno much of this topic either, but i think a font engine is in charge to actually render the glyphs (i know there might be other functions but this i guess is the most important), so if in a future we would like to write our own font format this is would be the base of it. Long ago (or so it seems), I wrote font loaders for imlib2. At the time, freetype didn't support xfonts so I had loaders for ttf fonts, xfonts, and fnlib fonts. I also had font stylers, which were also loadable modules and could 'style' any input glyphs.. I had something like three such 'stylers' I think. They could layer/composite glyphs, texture them with images or grads, bumpmap them with light sources, shadows, rotate/skew them, modify glyph advances, and other things.. xml files described what they would do. Unfortunately, I had to break the imlib2 api to do this since it wasn't adequate for the needs of such beasties... Carsten may still have the code for this somewhere as I sent it to him then. -- simplify the creation of render engines. This, per se, needs at least three things to begin with, as I mentioned earlier: get/put and composite argb buffer functions, and also a generic cache mechanism. This latter is needed for several things.. least of all to cut back on needless code duplication. I hope everyone knows that if you call the evas api function evas_image_cache_set(evas, size) you will not only be setting the cache size for that 'evas' instance, but also for every evas that uses the same engine. If some code sets the cache size to 0 for one software-x11 evas canvas, they will have flushed the image cache and set it to 0 for every software-x11 evas the program/lib deals with, and also flush the more common image cache that all buffer-evases use. If some code somewhere sets the image cache to 0 for one buffer evas instance, it will flush the image cache for all such and there will be no further image caching by any buffer evas, or ecore sub-canvases, until some other code resets the cache size for one buffer evas somewhere... I wrote a simple quick one once as well, using the current evas hash/list implementation and following the basic pattern used for image caching, etc.. It had a fairly straightforward api which Carsten and I discussed somewhat. But to stick this into evas requires a moderate amount of work, and as no one seems concerned with the above caching issues or with the internal code duplication, so I just let it go. This kind of thing is something that ecore could use as well though. Now, as to the get/put and composite funcs.. that's fairly straightforward.. although to do this at all would be best done in conjunction with the move to premul data, which together forms not- so-small an amount of work. -- make objects be modules too. Ah This is something
Re: [E-devel] Evas Evoak future changes
On Thursday, 07 September 2006, at 04:57:31 (+), [EMAIL PROTECTED] wrote: just make it clear that when I 'criticize' evas' this or that, and whatnot.. it's not to criticize Carsten's work on evas - not by any means. Criticism doesn't have to be negative; constructive criticism is always appreciated. I know Raster appreciates your ideas/suggestions and your continued support/help with evas. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) --- Greatness is never appreciated in youth, called pride in mid-life, dismissed in old age, and reconsidered in death. Because we cannot tolerate greatness in our midst, we do all we can do destroy it. -- Lady Morella (Majel Barrett Roddenberry), Babylon Five - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
