Andreas Vogl wrote: > in reply to Mark W.: > > >> I'm not sure what you mean by 'verticalize' the attribute >> panel. Maybe this depends on the resolution the person is >> running at, but it seems to look fine for me. [...] > > > Yes, I have still underestimated the width of your screen. =) > On screens of "normal" geometric ratio, the attribute > panel is too wide to fit well into the right-side panel > as you did it. > By "verticalizing" I meant putting the elements of the > panel more in top-down order (so it fits better). But that's > where the layout-changes start to cause trouble. Ok. So that would be like putting the apply/add inv/attributes buttons running horizontaly (perhaps along the bottom) instead of along the side. I could see the need for that. > > >> Are you basically saying to put the arch/select panel >> along the bottom beneath the map window, and have the map >> window then extend to the far right? > > > Exactly. This works surprisingly well with large screens/ > resolutions and normal screen geometry. When the screen is > just wide enough to support it, that saves a lot of space > without giving up any convenience. Ok. That makes sense. As I think I said, the layout as I did it works really well if you are using the top level windows for the map windows, because it is then easy to resize the map pane within the main editor window out of existence yet still have all the other data that is necessary. > I'm quite happy with that and plan to have it permanently > in the editor as an option. Too bad it's not the perfect > solution for your particular screen but I think it will > please a lot of people. Yeah - it does give more usuable space there. > Sure, that's a good idea. I think moving around any > of the panels is actually very easy. Hence, these kinds of > patches would probably be small and fairly robust. > We could make a directory on CVS called like "custom patches" > and put diffs in there for special layouts like yours. Yeah - if I remove the change I made that had the 32 pixel spacing removed (eg, put it back in), the diffs are actually a lot smaller. And i things change so that the old diffs no longer work, new ones could always be made and get checked in. > > If ceratin custom layouts get very popular I can still > try to include them as selectable option in the editor. That was some of my idea on making them public also - very hard to know if people find the changes useful if the changes are not even available. Having a top level directory like custom-patches (with a README describing these patches) works out just fine. Other people could put/provide patches that they deem useful but that we don't want to make standard for whatever reason in that directory also. > Thank you for all of your suggestions and ideas. I always > appreciate to know what people think and want about the > editor. Even when I might not be able to realize everything, > it does give me directions what is important and how > certain things can be improved. Thank you for your work on the editor. I think people making their ideas/thoughts known is always a good idea. After all, the authors may actually implement them, in which case the person who provided the idea also wins, as they get the feature they want. As a side note, it appears that the checkin of the current java editor code lacks any build scripts? At least I don't see any, nor directions on how to build.