darcs patch: Allow users to choose whether the tabbar should always...
Mon Apr 14 15:11:04 EST 2008 Ivan.Miljenovic@gmail.com * Allow users to choose whether the tabbar should always be visible. This uses the improved data structures/code layout from my second patch, but taking into account suggestions by droundy and sjanssen uses the duplicated-methods found in my first patch so that configs currently using Tabbed don't break.
On Mon, Apr 14, 2008 at 03:17:29PM +1000, ivan.miljenovic@gmail.com wrote:
Mon Apr 14 15:11:04 EST 2008 Ivan.Miljenovic@gmail.com * Allow users to choose whether the tabbar should always be visible. This uses the improved data structures/code layout from my second patch, but taking into account suggestions by droundy and sjanssen uses the duplicated-methods found in my first patch so that configs currently using Tabbed don't break.
The export list here looks acceptable, but I'd suggest a few changes... (also, sending with the -u option is preferred) Content-Description: A darcs patch for your repository!
+-- Tab creation abstractions. Internal use only. + +-- Create tabbar at the given location with the given shrinker and theme to the supplied +-- layout. Tabbar not shown when only one window present +createTabs ::(Eq a, LayoutClass l a, Shrinker s) => TabbarLocation -> s -> Theme + -> l a -> ModifiedLayout (Decoration TabbedDecoration s) l a +createTabs = tabMaker True + +-- Create tabbar at the given location with the given shrinker and theme to the supplied +-- layout. Tabbar always shown. +createTabsAlways ::(Eq a, LayoutClass l a, Shrinker s) => TabbarLocation -> s -> Theme + -> l a -> ModifiedLayout (Decoration TabbedDecoration s) l a +createTabsAlways = tabMaker True
I see no reason to define createTabs or createTabsAlways. You cut out some of the code, and make it easy for folks reading the above functions to see that you aren't actually duplicating code. And shouldn't the former function be tabMaker False? David
David Roundy
(also, sending with the -u option is preferred)
I guess you'd know :p
I see no reason to define createTabs or createTabsAlways.
Maybe not, I just liked the extra level of abstraction. This way, the booleans are only ever used twice, rather than addTabs{,Bottom}{,Always} all having to mention it.
And shouldn't the former function be tabMaker False?
Ummmmm..... yes ;-) Still not sure of the "always" name ending, but couldn't think of anything better at the time.
On Mon, Apr 14, 2008 at 02:06:57PM +0000, Ivan Miljenovic wrote:
I see no reason to define createTabs or createTabsAlways.
Maybe not, I just liked the extra level of abstraction. This way, the booleans are only ever used twice, rather than addTabs{,Bottom}{,Always} all having to mention it.
A nicer way to acheive more readable code is to replace the Bool with a custom data type: data TabHowOften = AlwaysTabs | TabsWhenPlural Then your code is easier to read and you don't need to define these helpers.
And shouldn't the former function be tabMaker False?
Ummmmm..... yes ;-)
This, for instance, would have been more obvious with the above approach. I prefer to never use Bool when I could avoid it. It's too easy to forget (or for a reader to be forced to read the code to determine) which meaning "True" indicates.
Still not sure of the "always" name ending, but couldn't think of anything better at the time.
I'm not sure either. Always isn't too bad. -- David Roundy Department of Physics Oregon State University
participants (3)
-
David Roundy -
Ivan Miljenovic -
ivan.miljenovic＠gmail.com