Re: [E-devel] Some TODO enlightenment please
On Sun, 26 Nov 2006 04:18:04 -0500 Christopher Michael [EMAIL PROTECTED] babbled: Writting to try and get some clarification on a few TODO items: * IBar will resize itself down to single icon size on start/restart under some circumstances. Any use cases? Reproduction methods? metrics reported this one i think from memory. * make e internal windows (config panel, dialogs, config windows etc.) use special border styles by default. Which style do we want by default? the e specific one (one for no resize, one for resizable dialogs, and later i think i will add a few more for filemanager windows for example). * accidental DND removals of icons from ibar - make it harder by not removing if you do not drag it far enough away (put the icon back where it was). Drag Delta? addition to drag delta. drag detla only starts a drag and drop after a certain amount fo drag - this would abort (and restore the icon) if it was going to delte it if the delta is not big enough (eg 200 pixels or something) * remove a lot of ipc commands that should be done via the gui now Is this safe/ok to start doing? for now - leave it, but i want to reduce ipc to things like restart, exit, etc. etc. - actions, not config changes. * maybe look at improving config panel layout - list is getting VERY long What direction do we want to go with this? Winblows Control Panel type deal, or something enlightened ? :) done :) Cheers, devilhorns - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
On Sat, 2 Dec 2006 12:23:29 +0900 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Sun, 26 Nov 2006 04:18:04 -0500 Christopher Michael [EMAIL PROTECTED] babbled: * IBar will resize itself down to single icon size on start/restart under some circumstances. Any use cases? Reproduction methods? metrics reported this one i think from memory. You are a bit behind raster, devilhorns, metrics, and myself got together and fixed it. It was me that reported it. signature.asc Description: PGP signature - 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.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
On Sat, 2 Dec 2006 16:07:38 +1000 David Seikel [EMAIL PROTECTED] babbled: On Sat, 2 Dec 2006 12:23:29 +0900 Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: On Sun, 26 Nov 2006 04:18:04 -0500 Christopher Michael [EMAIL PROTECTED] babbled: * IBar will resize itself down to single icon size on start/restart under some circumstances. Any use cases? Reproduction methods? metrics reported this one i think from memory. You are a bit behind raster, devilhorns, metrics, and myself got together and fixed it. It was me that reported it. aaah then it must have been metrics looking into it... and yes- i am, as usual, woefully behind. :( -- - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
On Mon, 27 Nov 2006 09:42:33 +0200 Chady Kassouf [EMAIL PROTECTED] babbled: On 11/27/06, Alberto [EMAIL PROTECTED] wrote: 8--snip- Perhaps you are right, that it was silly to suggest it, but this is why I wanted to emphasize, making it an option within the theme's source code, but since we are dealing with E's internal windows its probably for the best that they are as flexible as possible. Thus i retract the idea. Well, unless it's also an option for the user to select, you're still giving control to the themer, not the user, and a lot of users do not like someone else deciding for them what they can and cannot do. the main and really onyl reason i put this on the todo was that detour actualyl has special theme setups for e internal dialogs and makes the titlebar seem to blend directly into window contents. the problem is it assumes that that window border is only used for e dialogs - which it isnt. this basically will allow the themer to make borders work 100% as they want with the contents they specifiy for e theme contents. for unknown contents (client windows) they can put whatever bordering/edges/dividers they like between border and contents (if they so choose to). :) -- Chady 'Leviathan' Kassouf http://chady.net/ - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
Alberto wrote:
Christopher Michael wrote:
Writting to try and get some clarification on a few TODO items:
-- snip --
* make e internal windows (config panel, dialogs, config windows etc.)
use special border styles by default.
Which style do we want by default?
Instead of using a border style that already exists, I suggest adding
two or three new border styles, specific to internal E17 configuration
windows. Their physics should differ from regular client borders.
That is the plan :)
For instance, dialog windows should not be re-sizable and they should
not be allowed to shade. (they are the typical confirmation dialogs).
Also, their border icon should probably match the confirmation dialog.
I think we can all agree that popup dialogs (ie: msg dialogs) should
not be resizable, As for shading...IMHO, not a good idea :( These type
dialogs are usually meant to notify the user about a question/problem.
Allowing a user to shade them means allowing them to potentially ignore
the dialog forever (ie: it got shaded and they forgot about it), which
could render some pretty nasty problems if it was an important
dialog/question/warning. By not allowing a shade/iconify on these, we
force them to look at/deal with the dialog. Also (imho) they really
shouldn't have a close button (read X in corner) for pretty much similar
reasons.
Configuration windows could use the no_resize border that already exists
(if its suitable for the window) but with an extra flag, these windows
should not be allow to shade. If you don't exactly agree with this, then
I suggest you at least allow the themer to set this flag within the
border's edc source with an option similar to the shaped flag.
data {
item: shade 0;
}
I'm with David on this one :) Some config dialogs you may want/need to
be able to resize. As far as shading them, imho this should be allowed
for these type of borders. I don't see much of a problem with allowing
themers to use a shade: 0 optionother than potential
inconsistencies (ie: User: E won't shade this window :(...Devs: Theme
issue)imho doesn't provide a consistent feel to things. I'm all
about allowing power user feaures and giving themers flexibility but
something that makes the general interface behave differently on a
per-theme basis needs to be thought out, discussed and either agreed on
or shot down.
Devilhorns
-
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
Christopher Michael wrote:
Alberto wrote:
Christopher Michael wrote:
Writting to try and get some clarification on a few TODO items:
-- snip --
* make e internal windows (config panel, dialogs, config windows etc.)
use special border styles by default.
Which style do we want by default?
Instead of using a border style that already exists, I suggest adding
two or three new border styles, specific to internal E17 configuration
windows. Their physics should differ from regular client borders.
That is the plan :)
For instance, dialog windows should not be re-sizable and they should
not be allowed to shade. (they are the typical confirmation dialogs).
Also, their border icon should probably match the confirmation dialog.
I think we can all agree that popup dialogs (ie: msg dialogs) should
not be resizable, As for shading...IMHO, not a good idea :( These type
dialogs are usually meant to notify the user about a question/problem.
Allowing a user to shade them means allowing them to potentially ignore
the dialog forever (ie: it got shaded and they forgot about it), which
could render some pretty nasty problems if it was an important
dialog/question/warning. By not allowing a shade/iconify on these, we
force them to look at/deal with the dialog. Also (imho) they really
shouldn't have a close button (read X in corner) for pretty much similar
reasons.
Once again, here's a thought I'm having. If it sounds stupid or
anything, please ignore it.
Would it be possible to have an Expose-like shading of everything
besides the popup dialog?
Basically you need to
1) Set it on top of everything else
2) Somehow disable everything else
3) Shade everything else.
Or maybe it's too much to do, or bad from a usability point of view.
My $0.02
Eugen.
Configuration windows could use the no_resize border that already exists
(if its suitable for the window) but with an extra flag, these windows
should not be allow to shade. If you don't exactly agree with this, then
I suggest you at least allow the themer to set this flag within the
border's edc source with an option similar to the shaped flag.
data {
item: shade 0;
}
I'm with David on this one :) Some config dialogs you may want/need to
be able to resize. As far as shading them, imho this should be allowed
for these type of borders. I don't see much of a problem with allowing
themers to use a shade: 0 optionother than potential
inconsistencies (ie: User: E won't shade this window :(...Devs: Theme
issue)imho doesn't provide a consistent feel to things. I'm all
about allowing power user feaures and giving themers flexibility but
something that makes the general interface behave differently on a
per-theme basis needs to be thought out, discussed and either agreed on
or shot down.
Devilhorns
-
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
-
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
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.
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
Christopher Michael wrote: Writting to try and get some clarification on a few TODO items: * IBar will resize itself down to single icon size on start/restart under some circumstances. Any use cases? Reproduction methods? * make e internal windows (config panel, dialogs, config windows etc.) use special border styles by default. Which style do we want by default? * accidental DND removals of icons from ibar - make it harder by not removing if you do not drag it far enough away (put the icon back where it was). Drag Delta? Maybe it would be better not to remove the icon unless it has been grabbed by a minimum amount of time? Dunno, just a thought. * remove a lot of ipc commands that should be done via the gui now Is this safe/ok to start doing? * maybe look at improving config panel layout - list is getting VERY long What direction do we want to go with this? Winblows Control Panel type deal, or something enlightened ? :) Cheers, devilhorns - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
В нд, 2006-11-26 в 04:18 -0500, Christopher Michael написа: Writting to try and get some clarification on a few TODO items: * IBar will resize itself down to single icon size on start/restart under some circumstances. Any use cases? Reproduction methods? * make e internal windows (config panel, dialogs, config windows etc.) use special border styles by default. Which style do we want by default? * accidental DND removals of icons from ibar - make it harder by not removing if you do not drag it far enough away (put the icon back where it was). Drag Delta? Something like the pager. It already has this feature, users are familiar with it, and it's configurable. a dialog otoh would be bad (users hate dialogs) * remove a lot of ipc commands that should be done via the gui now Is this safe/ok to start doing? btw, why remove the ipc commands? Wouldn't it be better to actually add more? ipc is useful if you want to recreate your config somewhere else, with a script. * maybe look at improving config panel layout - list is getting VERY long What direction do we want to go with this? Winblows Control Panel type deal, or something enlightened ? :) Cheers, devilhorns - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Виктор Кожухаров /Viktor Kojouharov/ signature.asc Description: Това е цифрово подписана част от писмото - 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.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
On Sun, 26 Nov 2006 15:03:35 +0200 Виктор Кожухаров [EMAIL PROTECTED] babbled: В нд, 2006-11-26 в 04:18 -0500, Christopher Michael написа: Writting to try and get some clarification on a few TODO items: * IBar will resize itself down to single icon size on start/restart under some circumstances. Any use cases? Reproduction methods? * make e internal windows (config panel, dialogs, config windows etc.) use special border styles by default. Which style do we want by default? * accidental DND removals of icons from ibar - make it harder by not removing if you do not drag it far enough away (put the icon back where it was). Drag Delta? Something like the pager. It already has this feature, users are familiar with it, and it's configurable. a dialog otoh would be bad (users hate dialogs) no - pager has nothing like it :) * remove a lot of ipc commands that should be done via the gui now Is this safe/ok to start doing? btw, why remove the ipc commands? Wouldn't it be better to actually add more? ipc is useful if you want to recreate your config somewhere else, with a script. because it's a pain in the arse to maintain - a lot of config value are not supported by ipc. it also means we have bugs. if u change a value via ipc while using the gui all sorts of things can go wrong as now the state is inconsistent. the gui expects nothing will change while its active. its going to be a huge task to write it differently. also you can just copy your config files across to the new system - they do work. * maybe look at improving config panel layout - list is getting VERY long What direction do we want to go with this? Winblows Control Panel type deal, or something enlightened ? :) Cheers, devilhorns - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Виктор Кожухаров /Viktor Kojouharov/ -- - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
Christopher Michael wrote:
Writting to try and get some clarification on a few TODO items:
* IBar will resize itself down to single icon size on start/restart
under some circumstances.
Any use cases? Reproduction methods?
* make e internal windows (config panel, dialogs, config windows etc.)
use special border styles by default.
Which style do we want by default?
Instead of using a border style that already exists, I suggest adding
two or three new border styles, specific to internal E17 configuration
windows. Their physics should differ from regular client borders.
For instance, dialog windows should not be re-sizable and they should
not be allowed to shade. (they are the typical confirmation dialogs).
Also, their border icon should probably match the confirmation dialog.
Configuration windows could use the no_resize border that already exists
(if its suitable for the window) but with an extra flag, these windows
should not be allow to shade. If you don't exactly agree with this, then
I suggest you at least allow the themer to set this flag within the
border's edc source with an option similar to the shaped flag.
data {
item: shade 0;
}
* accidental DND removals of icons from ibar - make it harder by not
removing if you do not drag it far enough away (put the icon back where
it was).
Drag Delta?
* remove a lot of ipc commands that should be done via the gui now
Is this safe/ok to start doing?
* maybe look at improving config panel layout - list is getting VERY long
What direction do we want to go with this? Winblows Control Panel type
deal, or something enlightened ? :)
Cheers,
devilhorns
-
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
tokyo
--
[EMAIL PROTECTED]
-
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
On Sun, 26 Nov 2006 16:42:20 -0600 Alberto [EMAIL PROTECTED] wrote: Christopher Michael wrote: Writting to try and get some clarification on a few TODO items: * IBar will resize itself down to single icon size on start/restart under some circumstances. Any use cases? Reproduction methods? * make e internal windows (config panel, dialogs, config windows etc.) use special border styles by default. Which style do we want by default? Instead of using a border style that already exists, I suggest adding two or three new border styles, specific to internal E17 configuration windows. Their physics should differ from regular client borders. For instance, dialog windows should not be re-sizable and they should not be allowed to shade. (they are the typical confirmation dialogs). Also, their border icon should probably match the confirmation dialog. Configuration windows could use the no_resize border that already exists (if its suitable for the window) but with an extra flag, these windows should not be allow to shade. If you don't exactly agree with this, then I suggest you at least allow the themer to set this flag within the border's edc source with an option similar to the shaped flag. I do disagree with this, as I resize config dialogs that contain long lists so that I may see more of the list at once. Just because we make sure that the default size is suitable for people with 640x480 screens, doesn't mean those of us with larger monitors have to be constrained to that size. Sometimes shading is used to temporarily get that large, resized window out of the way. B-) On the other hand, maybe you are only talking about the simple Yes/No, OK/Cancel type popups, that wasn't clear. Those can be fixed size, with a title bar though. Still not sure why you would disallow shading though. I could never understand the people that insist on restricting functionality for no good reason. There needs to be a really good reason if you ever decide to stop the power user from being able to do anything they want. I never use it is not a good reason. signature.asc Description: PGP signature - 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.phpp=sourceforgeCID=DEVDEV___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
David Seikel wrote:
On Sun, 26 Nov 2006 16:42:20 -0600 Alberto [EMAIL PROTECTED] wrote:
Christopher Michael wrote:
Writting to try and get some clarification on a few TODO items:
* IBar will resize itself down to single icon size on start/restart
under some circumstances.
Any use cases? Reproduction methods?
* make e internal windows (config panel, dialogs, config windows
etc.) use special border styles by default.
Which style do we want by default?
Instead of using a border style that already exists, I suggest adding
two or three new border styles, specific to internal E17
configuration windows. Their physics should differ from regular
client borders.
For instance, dialog windows should not be re-sizable and they should
not be allowed to shade. (they are the typical confirmation dialogs).
Also, their border icon should probably match the confirmation dialog.
Configuration windows could use the no_resize border that already
exists (if its suitable for the window) but with an extra flag, these
windows should not be allow to shade. If you don't exactly agree with
this, then I suggest you at least allow the themer to set this flag
within the border's edc source with an option similar to the shaped
flag.
I do disagree with this, as I resize config dialogs that contain long
lists so that I may see more of the list at once. Just because we make
sure that the default size is suitable for people with 640x480 screens,
doesn't mean those of us with larger monitors have to be constrained to
that size. Sometimes shading is used to temporarily get that large,
resized window out of the way. B-)
On the other hand, maybe you are only talking about the simple Yes/No,
OK/Cancel type popups, that wasn't clear. Those can be fixed size,
with a title bar though.
Right. I was referring to the Confirmation dialogs.
Still not sure why you would disallow shading
though. I could never understand the people that insist on restricting
functionality for no good reason.
Perhaps you are right, that it was silly to suggest it, but this is why
I wanted to emphasize, making it an option within the theme's source
code, but since we are dealing with E's internal windows its probably
for the best that they are as flexible as possible. Thus i retract the idea.
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.
There needs to be a really good
reason if you ever decide to stop the power user from being able to do
anything they want. I never use it is not a good reason.
-
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
tokyo
--
[EMAIL PROTECTED]
-
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.phpp=sourceforgeCID=DEVDEV
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
On Sun, 26 Nov 2006 23:44:27 -0600 Alberto [EMAIL PROTECTED] 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.
This I do agree with. B-)
signature.asc
Description: PGP signature
-
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.phpp=sourceforgeCID=DEVDEV___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Some TODO enlightenment please
On 11/27/06, Alberto [EMAIL PROTECTED] wrote: 8--snip- Perhaps you are right, that it was silly to suggest it, but this is why I wanted to emphasize, making it an option within the theme's source code, but since we are dealing with E's internal windows its probably for the best that they are as flexible as possible. Thus i retract the idea. Well, unless it's also an option for the user to select, you're still giving control to the themer, not the user, and a lot of users do not like someone else deciding for them what they can and cannot do. -- Chady 'Leviathan' Kassouf http://chady.net/ - 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.phpp=sourceforgeCID=DEVDEV ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
