[Ohrrpgce] SVN: james/5776 Add a pair of functions to return the current resolution

[James Paige]

On Fri, Apr 12, 2013 at 03:51:05AM +1200, Ralph Versteegen wrote:
> On 12 April 2013 03:31, James Paige <Bob at hamsterrepublic.com> wrote:
> > On Fri, Apr 12, 2013 at 03:18:15AM +1200, Ralph Versteegen wrote:
> >> On 12 April 2013 03:01,  <subversion at hamsterrepublic.com> wrote:
> >> > james
> >> > 2013-04-11 08:01:07 -0700 (Thu, 11 Apr 2013)
> >> > 57
> >> > Add a pair of functions to return the current resolution
> >> > ---
> >> > U   wip/common.bi
> >> > U   wip/common.rbas
> >>
> >> This may escalate quickly!
> >
> > I don't doubt it for a moment :)
> >
> >> BTW, my intention was that the resolution would be conveyed whereever
> >> possible by the dimensions of the root slice. (This pair of functions
> >> is still useful, of course)
> >
> > Yes. I made those functions for something I am working on in custom. I
> > was not planning on exposing plotscripting commands for them.
> 
> Whatever you're doing in Custom, I wonder whether it can be done using
> slices instead ;)
> (But of course game and editor resolution should be independent)

This particular task is not slice-related :)

> Actually, to be honest I am a little concerned about using slice
> collections too pervasively in Custom for GUI elements which change a
> lot depending on editor state, as won't slice manipulation code be
> lengthy and less clear compared to drawing stuff directly where
> variability is typical which simple, eg. "IF x THEN textcolor y,0". On
> the other hand I suppose there are also things which will be
> simplified.

Yes. I am not in a big rush to convert things in custom over to slice 
collections unless there is a compelling reason. I so expect the 
editor-editor implementation to be heavily slice-based, but not to rely 
very much on slice collections.

> I wouldn't know how to organise the map editor. A single slice
> collection with separate children for each editing mode, or separate
> collections? Assuming the earlier, should stuff like the position of
> the tool buttons be copied into each mode-specific child, or separate
> with some code to specialise visibility and position as necessary?

Hmmm... Interesting! This sounds to me like you are worrying about 
end-users customizing the map editor, which is not something I think 
should be a goal right now (or maybe even ever)

I haven't given a lot of thought to the sliceification of the map 
editor, but my first impulse is that we should think of it as one big 
slice collection, with components that may be marked as belonging to 
certain editing modes, so they will be automatically hidden or unhidden 
when you change modes. This mode-association could be done with extra 
data, or with lookup codes, or something like that.

It might even make sense to have a generic ModeSlice container which has 
data indicating which parent mode it belongs too, and state for which 
mode it puts its children in. The modes could be strings. A ModeSlice 
would automatically manage its visibility by looking up the chain of 
parents until it found another ModeSlice and then doing a comparison 
between its modemembership and the parent's modestate.

This would be slick since the slice collection editor could be aware of 
it, and it would make it easier to edit multi-mode slices collections.

This might even qualify as a suitable feature for the base Slice class, 
rather than a container subclass.

---
James