On Mon, 27 Nov 2006 08:29:51 -0600 Brian Mattern <[EMAIL PROTECTED]>
babbled:
> On Sun, Nov 26, 2006 at 11:44:27PM -0600, Alberto wrote:
> > But I do want to point out that a theme can has a many border styles as
> > u can think of, so the data {item: "shade" "0"; } option could be used
> > elsewhere. It just comes down to a matter of design and preferences.
> > Personally I prefer to click on a border button and see the client
> > window shade, instead of having to double click the titlebar.
> > Unfortunately such signal does not exist.
>
> I agree that we have a little more work to do on the customizability of
> borders and their actions. The current implementation uses named parts
> (e.event.*) to trap events that perform actions. In E, there is an
> action set up that shade's a window when the user double clicks ont he
> border's e.event.titlebar part. So, for a border button that shades, we
> would need to add an e.event.shade part and attach the 'shade toggle'
> action to *that*. We would also need some way for the user to disable
> shading when double clicking on the titlebar (either in the generic
> mouse actions dialog, or maybe as an option in a window behavior dialog
> somewhere.
>
>
> Another feature I'd like to see is user-configurable locations of border
> buttons. *Most* themes are designed in a way that rearranging the
> buttons and border icon would look just as good. So, possibly a dialog
> that lets you pick between basic (windows-like, mac-like, theme-default,
> etc) modes, with an advanced dialog to specify "close on the left,
> maximize and shade on the right, but leave off the minimize button since
> i never use it".
>
> For this to be feasible, we'd have to break the buttons out into
> separate edje groups, with SWALLOWS in the proper spots on the border.
> (E.g. "e.swallow.buttons.left" and "e.swallow.buttons.right"). These
> would swallow e_box's which would in lay out the requested buttons.
>
> This does limit the flexibility on the part of the themer (no two
> buttons could overlap in their boundaries for example), but gives much
> more flexibility to the user. Really, there's no reason we couldn't
> still allow the current style for themers that want it. We'd just need
> to let the user know that certain border styles in the current theme
> don't support button placement.
i agree this would be nice. though i am thinking that this smells to me of a
"e18" feature. themes can provide a generic border with several swallow regions
as you describe, then provide all sorts of elements to swallow etc. :) the
problem with this is it only allows for regular-ish layouts. if you want the
buttons to curve around the corner of your window - you need a custom design. :)
>
> rephorm
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> 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 (東京 日本)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
