Appearance Controls - Consolidate Layouts, Styles, etc?

I've discussed the idea here before and over email with others and some have commented that Layouts and Styles have different implied uses... but it's nothing I think can't be accomodated by a bit more extensive system for loading and saving Layouts. I think there's enough room for functionality specific to this area to justify breaking the current Layout feature set out from under the larger Prefs function coverage.

I myself don't make use of alot of the visualization controls in Opus simply because I find the overlap a bit too chaotic (guess I'm a bit anal :slight_smile:). I'm curious as to how other ppl out there are making use of the different appearance related features in Opus and would like to start a pros and cons conversation here focused on the idea of unifying and simplifying the different systems for altering the Opus UI display...

Of course, it's sort of meaningless... GPSoft may have no interest in changing anything along these lines :slight_smile:. But it seems to me that one of the primary complaints of new users is that the options/prefs system in Opus just seems too daunting... On the other hand, most of us enjoy the flexibility of many of the options in the app right? But perhaps some well though out ideas on consolidation of the config dialogs and elimination of overlap areas might intrigue GPSoft?

I'm sure there are other areas that could use a similar effort and discussion, but for now let's focus on the 2 main appearance related systems... Layouts vs. Styles... and how they both intertwine with other systems like folder formats, tab groups, etc - oh and toolbars (on/off/placement) since a few ppl have recently voiced their desire to have toolbars associated with a layout or something similar...

What say you?

Hello Steje...

I'm afraid this is no more than moral support for your campaign, because I agree with what you are saying.

I feel I should be trying to make concrete suggestions, but, other than to say I'd expected to find everythng to do with controlling the appearance of DOpus in one place, and had to do a lot of reading to find all of the places, I cannot offer explicit ideas which Jon can make use of, should he decide to do something about it.

In particular, I am one ot those users who will suffer from a burst of creativity, when struck by a brilliant idea, and find myself having to RTFM all over again, because so much time has elapsed since last I needed to know, that I have forgotten how to make the necessary changes (senior lapses!). I must hasten to credit the various contributors to the resource centre for making the job easier, but still feel that ultimately, it's up to Jon to make a real and lasting difference, and I am uncertain just how difficult that would be.

I was struck Leo's acknowledgement that he gained some new insights, as a result of preparing the "HOW TO: Understand and Configure Folder Formats" FAQ entry. My reaction was, if he is still learning, what hope is there for the rest of us? :confused:

I'd been ignoring a feature/behaviour since it wasn't something I ever used but then I had to learn it to write the FAQ. There's hope for everyone.

Perhaps a FAQ is needed explaining what Layouts, Styles, etc. all do and when to use each one.

In terms of this thread, I think that each of the different systems does have a slightly different purpose (e.g. Layouts can involve multiple listers) but perhaps the way to simplify them is to make Layouts open listers which use Styles. I'm not sure how that would work, though, when the Styles used in the Layout are temporary and don't exist or get used anywhere else. I guess the Styles section of Prefs would be able to save named Styles that can be used on their own or as part of a Layout, and the Layouts section of Prefs would be able to refer to the named Styles as well as define anonymous styles which are only used and only visible within their parent Layout.

Ignoring that for now, the Default lister(s) could (always) be a layout with an optional auto-update mechanism when Opus is exited to save all open listers over the old Layout, and perhaps another optional mechanism to save the last-closed lister as the Layout (on its own).

Layouts could get a flag which says they open under the mouse, which would be useful even if they don't replace the default lister system we have now. If a Layout with this flag consists of multiple windows they would open centred around the mouse pointer (but shunted to remain on-screen if needed).

Anyway, just some ideas to throw into the mix.

I too, have been ignoring these features for far too long. Mainly due to my initial confusion as to what the capabilities of each of them are.

In this thread I posted my view on the roles which should be played by styles, layouts etc.: [Enhanced lister style options)

Personally I think it is important to eliminate overlap between these features (for clarity and maintainability).

Example: In preferences -> Layout -> Lister Styles you can define tabs for the style. These tabs are defined independently of tab groups. This creates two ways of defining tab groups. I would prefer the Lister Styles to be linked to a (set of) tab group(s).
End of example.

It is important to identify all elements which can be configured in the layouts, styles, etc. Then we can redistribute them in a more unified and logical manner.

Let me repeat my thoughts from the other thread:

  • layouts should define lister position, size and used style (the global layout).
  • styles should define single/dual view, tree, viewer pane, toolbar positions, and used tab groups (note: groups, not tabs) and file format (the layout of a single lister).
  • file format deals with displayed columns, filters, view type such as flat or details (the layout of a single file pane).

I also think that each of these elements (layout, styles, file format) should be either tagged as static or dynamic. If it is dynamic it will update its definition with the changes made in the lister, if it is static it will remain as initially defined.

Thanks for the feedback guys, and I know both Nudel and Caine voiced similar thoughts on the FR topic Caine started a few months ago. I was hoping we could actually get some thoughts from other people that do extensively use both Layouts and Styles and who might be able to articulate the reasoning behind their different uses of each... We here obviously have some different notions of how these 2 systems could either be combined or seperated out based on either our understanding of how each works, or experience in trying to use each. This is what I was after since I only really use Layouts...

For instance, one suggestion Nudel has made is to further the use of Styles as being more subordinate to Layouts; while Caine suggests more logically seperating out the areas affected by each.

From my view, Layouts are generally geared towards the opening of 'new' listers while Styles are inherently only used to modify the view of the 'current' lister. This difference is inherent to the way either a layout or style is invoked/loaded. Some other differences are that Styles put some of the elements they 'save' into selectable form... represented in the Styles editor dialog... while Layouts 'save' all of the same elements but only after manually setting them up in a lister. Are both of these approaches really needed? In fact, Styles can actually be made to behave exactly the same way in this respect... if you create a new Style, manually modify the lister appearance (formatting, tabs, etc) and then click RMB on the new style and select Update - voila... a bit more 'feature overlap'.

I do and I almost put my 2 cents worth here today steje, but decided to wait awhile so I can give it more thought.

Fair enough John - the thought is appreciated...

I'm finally getting around to posting my 2 cents worth in this thread, but the reason it's taken me so long has nothing to do with the amount of thought I've put into it. Quite frankly with the holidays and end of the year deadlines to meet I've had to limit the time I can spend in these forums lately. However the holidays are winding down now, in fact I'm "playing" all three days of this last holiday of the year, I've met my end of the year deadlines.

So here goes.

When I was new to Opus a few years back I would have loved a simpler way to learn the program. On the other hand now days, I love its complexity. So if I could wave a magic wand to make a change in Opus, I'd like to see two basic operating modes of the program which could be something like:

  1. Basic
  2. Complete

Where Basic would preset most options to common defaults then hide them from the user. Opus would then be more of a typical run of the mill file manager but it would give newbies a chance to get used to the program. Once they're ready to step up, they could change their operating mode to Complete and get the whole package.

I don't know if I'm explaining this the best way, hopefully you'll get the gist of what I'm trying to say. To sum it all up another way, I'd like to see optional training wheels available for the powerful machine that Opus is.

After all, many MANY moons ago when I learned to ride a bicycle, I had no training wheels to help me. Once I got the bike going the only way I knew how to stop it was to run it into a tree.

Which might explain the way my head works these days.

Aha, so what you're saying is that you use listers Styles a bit differently than Layouts?

edit- sorry John, I get your drift man, I just started drinking early and am feeling frisky. Happy New Year all!!!

Hmmm... probably no need to leave this topic as a 'sticky'. It doesn't look like many people care about it. Guess it's just me being picky.

(I've unstickied it. --Nudel)