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.
> 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 :)
> 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.
> 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.
> 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).
> 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...
well there's my 2 cents :)
> On Fri, 2004-04-30 at 06:58, Gen Zhang wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi all. To relax, I've decided that coding up engage would be a refreshing
> > change from exam revision. Looking at the (much) changed code since I last
> > saw it, there's a couple of things that I would like to implement. One is
> > better handling of windows opening and closing,
> What do you mean specifically here about opening? I know closing isn't
> implemented yet, have you tried themes other than the default?
> > the other is better icon management.
> again have you tried some of the themes that are floating around(not in
> cvs)?
> > In particular, I would like it to be freedesktop.org compliant,
> > so that engage on its own can be used in any environment, GNOME, KDE or
> > other compliant desktops. As xcomputerman says on the homepage, engage has
> > potential to really bring gui writer over to DR17. So that's my dollars at
> > two cents worth.
>
> >
> > My first goal is to code a replacement for the repeated od_sync_clients
> > calls. The current form is neither efficient nor extremely pleasing to the
> > eye -- we've got an average delay of half a second, an unacceptable latency.
> >
> Yeah, querying X for all of its windows every second isn't exactly
> optimal. I was REALLY scared of this function at first, but was unaware
> of a method to get client window state/property/(?) changes. I'm all
> for this one.
> > Since the last time I worked on the code, I've gotten to know X and ecore a
> > lot better, especially the extensible nature of both. I'd like to have the
> > window management (wm.c) side moved to an event driven way, in which we
> > monitor top-level window creation/mapping and destruction/unmapping update
> > the icons as things happen. Also, and this is probably the harder bit, I'd
> > like to comply with fd.o with respect to startup notification messages.
> > However, in the current state, there are a few things that need to be
> > completed in ecore. Specifically, the boilerplate relating to
> > ECORE_X_EVENT_CLIENT_MESSAGE. I think I could probably modify things myself,
> > but I'm a little wary of touching the specifics inside ecore... (As a side
> > note, ecore_x currently just drops all x events that does not map cleanly
> > onto one of the handlers; maybe there should be a default x event that is
> > raised.)
> >
> > It's nice to see that I'm not just doing these little hacks for myself... :D
> >
> > and thanks to all who have brought engage to where it is now!
> >
> > Genneth
>
> --
> Corey Donohoe
> http://www.atmos.org/
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> enlightenment-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 (数田) [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
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
