On Fri, Dec 24, 2010 at 04:06:15PM +1300, Ralph Versteegen wrote: > On 23 December 2010 09:03, James Paige <[email protected]> wrote: > > On Wed, Dec 22, 2010 at 03:28:34AM +1300, Ralph Versteegen wrote: > >> On 15 December 2010 14:07, <[email protected]> wrote: > >> > james > >> > 2010-12-14 17:07:24 -0800 (Tue, 14 Dec 2010) > >> > 90 > >> > Some trivial tinkering with the Editrunner. > >> > (that doesn't do anything new or interesting) > >> > --- > >> > U wip/editrunner.bas > >> > U wip/items.reld.editor > >> > >> I'm not sure what you intended to use slices for, but I don't see a > >> way for them to actually simplify anything. If you want to integrate > >> an editedit-based menu into a slice based menu, we could draw the > >> editedit menu onto a videopage that is a view on a Frame. (I'd love to > >> think about what a Menu slice might be.) > > > > Editedit menus are not just going to be text based. They also need the > > ability to preview sprites, or to arrange text menu items into columns. > > I am also thinking I want editedit menus to animate a little when you > > switch menus (probably the current menu will slide off screen to the > > left, and the new one will slide in from the right. > > > > Slices seem to be the best way to do all of that, especially menu items > > that have sprite components. > > > > --- > > James Paige > > Arrange menu items into columns? Animation? Sprite components? Those > sound exactly like desired features for Menus or some kind of Menu > slice.
Ooh, actually, yeah, this might mesh nicely with menu slices. I hadn't been thinking about that, but you are right. > I've been trying to figure out for a while how Menus might support all > that kind of stuff, including menu items which are slices instead of > strings (eg. a picture of an item plus a caption textslice). I thought > that arranging menu items into columns would somehow involve a grid > slice, and that current menu layout options would create a default > slice layout, which would be bypassed by providing a manually laid out > slice collection. But I just can't work out any decent design. Any > ideas? I am drawing some of my inspiration from GTK+ widgets like the ones I am constantly playing with at work in glade3 (they probably aren't all that different from wxwidgets, but I don't know enough to say for sure) I don't know if GridSlice is the right slice for the job, but that is definitely the direction I plan to experiment with. > Menu menus are disappointingly inflexible and unideal for use in > Custom, but those features sound like stuff we want, somehow, in Game, > and kind of orthogonal to the RELOAD editing portion of editedit. So > maybe it could somehow be broken into a separate system? Also, the map > and sprite editors need rewriting, and they'll be slice-based and > mouse-enabled with clickable buttons; and I also wanted floating menus > in windows (for editing NPC instances) Yes, definitely. I think in those cases, the interface should be a slice collection, with menus in places (drop down floating menus, or right-click pop-up context menus, that sort of thing) so I will keep those use cases in mind. I think I understand what you mean about breaking the menus into a separate system-- you mean one NOT tightly tied to sets of records in a reload document. > and, if our backends could > support it, multiple window panes. This sounds like yet another place > for a generic slice-based editor abstraction. I'd love a universal and > flexible menu system, but I suspect it's too much to ask for. I would love that too. Universal and flexible is what I am aiming for, but yes indeed it is a hard target to hit. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
