* Carsten Haitzler ([EMAIL PROTECTED]) wrote:
> On Fri, 30 Apr 2004 14:34:35 -0500 Corey Donohoe <[EMAIL PROTECTED]> babbled:
>
> > fwiw I'll try to compile a list of things we've discussed on #edevelop
> > recently about it, most of it being theme/edje related. From memory
> > most of this got HandyAnde's blessing.
> >
> > 1. "Behavior" edje - an edje that emit signals to the app based on mouse
> > interaction, this edje will retain the same mouse behavior between
> > themes. examples being opening,closing,minimize,raising,cycling between
> > windows. Quite a few people mentioned that they don't want to have a
> > learn a whole new set of mouse buttons when getting a new theme, this a
> > sane request that we can address in a decent manner.
>
> true - but i am not sure an edje is the best thing here. imho this is
> something that should just be part of the code & config of the app. if a
> user wants to change what mouse button does something or if its a double
> or single click, a click+hold etc. they would need to write an edje to do
> it... visually - yes they do too - but with proper use of colorclasses and
> textclasses at least colors and fonts can be user-defined.
yup, user fonts and colors were intended for the "Icon Decoration" edje.
If performance would suffer greatly I think implementing it in pure evas
would make sense. I think the performance hit would probably be worth it,
atm it's looking like a transparent rect that is stacked above the icon
edjes and repeats events down to them. It just seemed more flexible. The
default behavior edje would be sane and easy to use, I imagined most people
would just learn the default behavior and never change it.
The reason an edje seemed ideal for the behavior is it could easily handle
somewhat complex mouse interaction without us having to reimplement a subset
of edje's mouse interaction functionality. Sure we can handle a large
portion of it pretty easily, but take for example my ibook I worked on for
quite a while with one mouse button. I could feasibly chain events
single click -> one second pause(w/ half a second of err space) -> double click"
bound to raise all windows for this app, I couldn't easily chain mouse
events like that with pure evas, even with a pretty powerful config tool.
While that's an obscure case, it's a flexible way of using our tools
powerfully. With edje you could have moving the mouse counter clockwise
bound over the icon bound to a signal, and moving it clockwise bound to
another.
Yeah, it does suck if the user just wants to modify something small.
>
> > 2. "Icon Decoration" edje - in the default theme now, it's the bubbles
> > that live behind the icons. You could make something more elaborate, or
> > leave it blank. This defines the area that the icon will take up. Side
> > note, I don't know if you've noticed you can supply icon -> window class
> > mappings in your theme edje now too.
> >
> > "How do the behavior and and icon edjes communicate?" Through edje
> > signals of course! :) When the Behavior edje emits for example an
> > "engage,app,open" signal, it'll open the app, engage will then send a
> > signal(by the same name) to the icon edje, so you can do fancy
> > bouncing/fading/shrinking/embryo scripting and more.
> >
> > 3. "Base" edje - have an edje that defines a region to swallow the icons
> > to. Think of it as being able to theme the backdrop in the current
> > engage, something much more fancy than just colors. Resize, grow,
> > shrink, fade, ... now the separator bar thingie might be a tad more
> > tricky. We could have it be an edje dragable, which has it's position
> > calculated by the application and repositioned according to the number
> > of elements currently visible.
>
> i really thing 2 & 3 are the same thing - well the same conceptual thing
> and thus belong in the same ejde - well thats just me :)
Yup I do too, but the moment we finish our artsy new theme
<themer> anyone wanna try my new engage theme ?
<someone> "OH I LIKE THE BACKGROUND, BUT WHERE'D MY BUBBLES GO ?!?!?!??!
<themer> it's a different theme, so it's gonna look different
<someone> OH THAT SUCKS, NAW IT'S COOL I'LL KEEP RUNNING MY OLD THEME, I
LIKE THE BUBBLES
* someone humps the bubbles
<someone> LEMME KNOW IF YOU CHANGE YOUR THEME TO HAVE THE BUBBLES TOO
* themer sighs
:)
>
> > 4. "Mappings" edje - an edje with data { } block that map window classes
> > to specific edje groups(in the same edje). Mappings setup in your
> > "Mappings" edje override those provided by X, fallback to the icons
> > provided by X if no mapping is found, and can optionally fall back on a
> > "Unknown" edje if we can't query the icon from X itself. The number of
> > groups in this edje is up to the themer. while we're discussing it I'd
> > like the ability to have icons based on a combination of window class
> > and title... Dunno how we'd do that though.
>
> shoudl we really use an edje for mappings? or maybe just have a directory
> of png's, edje .eet's etc. with mappings determined elsewhere so it is
> easy when you install a new application that that app can provide a
> mapping and that everyone doesnt have to go modify their config for the
> new app. keep in mind that it'ds be nice that u dont have to go update
> your config for every new app u want to use - that an app could provide
> this.
I'd honestly suggest a mechanism for both. I'd like to be able to make a
supa dupa edje that has ALL of my personal settings for engage. That way I
could easily copy it around to different machines. I guess a .tar.gz of
~/.e/apps/engage/ would prolly do the trick too. I'm definitely open to
suggestions.
>
> > 5. These four edjes all exist as options
> > engage.options.theme.base: a string with the filename of the base edje
> > engage.options.theme.behavior: a string with the filename of the
> > behavior edje
> > engage.options.theme.icon: a string to the filename of icon decoration
> > edje
> > engage.options.theme.mappings: a string to the filename we should use
> > for window class -> icon mappings
> >
> > Now we distributed atleast one theme that's the default. If the
> > behavior, icon, or mappings options aren't set. They fallback to the
> > theme.base edje. This allows themers to distribute one easy file
> > handling everything, but also allows users to mix and match things to
> > their taste. While from a themers perspective we wouldn't want people
>
> that was the idea of groups within an edje.eet - you namespace them. you
> could search multiple .eet's for the same group name thus allowing a "1
> file has it all" approach for a theme, or being able to mix and match and
> fall-back.
>
> > mixing and matching our designs, people will most liekly want to it
> > seems. We can address the issue, so we might as well. If the base edje
> > doesn't have the necessary info in it to handle the request it falls
> > back to the default edje engage was distributed with. I'd suggest we
> > only provide an "Unknown" fallback mapping in the default edje, and grab
> > the rest of the icons from X.
> >
> > 6. User Application Icons: Migrate away from ~/.e/apps/engage/applinks
> > towards something like ~/.e/apps/engage/apps/ The user can simply copy
> > .eets to that directory and they'll be included in their bar. Don't
>
> definitely :)
>
> > want that app in your bar? Delete it. We still need to address ordering
> > of those eets, and ordering of the "docked" icons as well. (The eet
> > format for app eets allows you to differentiate between docked and
> > regular launcher apps) Raster also mentioned that our apps can just
>
> enstrom handled order by simply keeping an "icons_order.txt" that
> specified the order icosn appeared. if u dragged icons around to change
> order it updated the file. if an icon file was found not in the order file
> it was simply appended so the user can later go re-position if they want.
> if an item in the order file didnt exist as a icon file it was removed
> form the list. it worked quite well. thsi way the order file worked as a
> hint and if it was up to date or not didnt matter. things it was not
> up-to-date on got a default "alphabetical order" appended after the known
> orderd list.
yup, iconbar does a similar things but uses an edb instead of a text file.
and the functionality merging begins....
>
> > distribute their own eets. Another thing to address here is that the
> > icons in the files should override the mappings? come second to the
> > mappings? be configurable? I can elaborate more on this later this
> > afternoon, as I have this working locally except for ordering and
> > mapping overrides.
>
> good question. imho the icon should come first. a user shoudl be able to
> modify & create their own icon - provide a tool to build one (ie it writes
> a .edc, runs edje_cc and builds one for you). enstrom provided
> such a tool - but it didnt use edje though at the time - but eet directly.
> if the icon does not provide an IMAGE or any particular field/info then
> fall back to the default system installed one (which should probably
> follow a similar system - a directory full of icon files on the
> system - this lets someone change the system config merely
> by copyign their own .icon dir over the system one).
sounds good.
>
> > believe it or not there are one or two more points I think left to
> > mention, and there's some inline comments below. I took the time to
> > write this up so we can get maximum input from everyone. Also to make
> > sure I didn't misunderstand the discussions we had over the past couple
> > of weeks. Gotta run...
I completely spaced on what these other things are now.
>
> well there's my 2 cents :)
thx, much appreciated. :)
__
Corey Donohoe
http://www.atmos.org/
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
