On Fri, 21 Nov 2008 09:32:28 -0600 Nick Hughart <[EMAIL PROTECTED]> babbled:
> On Fri, 21 Nov 2008 10:39:11 -0200 > "Gustavo Sverzut Barbieri" <[EMAIL PROTECTED]> wrote: > > > On Fri, Nov 21, 2008 at 10:09 AM, The Rasterman Carsten Haitzler > > <[EMAIL PROTECTED]> wrote: > > > On Fri, 21 Nov 2008 19:01:30 +0900 Toma <[EMAIL PROTECTED]> > > > babbled: > > > > > >> Sorry for the Digest reply, but dont we already have a toolbar? In > > >> fact line 15900 of default.edc has a toolbar section. So we have > > >> another toolbar now? > > > > > > toolbar FOR efm, and a toolbar "widget" - different :) > > > > btw, as others on IRC: I dislike the new config dialog. > > > > maybe if we reduce the number of categories and avoid scroll, it could > > work better. since it's very similar to macos, we could do like them > > and put a first screen to choose the category, so it's like: > > Configuration window: Look, Apps, ... as a grid or so, possible > > with descriptive texts as we see on macos, kde or vista. > > Look window: Wallpaper, theme... followed by the selected app > > dialog. > > > > maybe this will not match e17 way, so out of ideas. > > > > Another idea might be collapsible headers for each category. Clicking > on the header would then expand that category in the list. In fact a > generic collapsible widget could be useful in other places as well. this would also compress things. :) > Another idea would be to have a list of categories. Once you pick a > category, the contents of the list are replaced with that category with > a button to go backwards. This type of interface works on a > touchscreen as well as a desktop. Some examples of this type of > interface is the iPhone Settings and to a lesser extent the Windows > Control Panel (the new one with the categories and such, not the > classic one). Both provide a similar flow of category -> items and > include some way to go back. So in this way I see it as serving both > worlds and also has some track record of actually being useful for > both. it's another solution :) > I like my first idea more though because it could potentially require > less clicking at the expense of more scrolling. But with kinetic > scrolling and mouse wheels, scrolling isn't all that expensive to the > user anymore. The collapsible headers help with that anyway. > > In either case, I don't agree with less categories. We could possibly > trim a couple (menus could be merged with apps for example), but in the > long run, we shouldn't limit the number of categories as to make them > useless. Especially with a modular design, who knows what categories > will be created. Have to be flexible with this. over time categories will expand most likely - it's an extensible pluggable interface so we need to just "deal" with many categories. you're right. that's why i made the toolbar scrollable - we need to deal with: 1. # of items may expand over time and due to user actions (like adding more modules). 2. screen size may be tiny - so cram onto it. :) i'm relatively agnostic. as such the toolbar+ilist is more efficient. ilist is not intended for long lists of stuff. this is something i NEED to repeat - it's being abused heavily. i need to somehow address this. the toolbar+short ilist is good as this is what it was really intended for. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
