[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Some TODO "enlightenment" please



On Mon, 27 Nov 2006 08:29:51 -0600 Brian Mattern <brian.mattern@gmail.com>
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)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)