[CF-Devel] a couple diffs to the java editor ...

Sat Aug 17 14:25:16 CDT 2002

>

      What did happen?

     >

      Did we just get an email from Mark with a subject field containing 1000

     >

      words? Accident, purpose or mailserver broken?

  Accident on my part - I was trying to cut and paste the subject line, but 
accidentally pasted the contents of the message. I  thought I had deleted it it 
and put a right subject in, apparantly not.

Andreas Vogl wrote:

>>

     The layout.diff changes the layout of the window a bit.  It 

     >>

     basically [...] moves the portion that used to be below [...]

     >>

     into the right side area.

     >>

     This is most useful on higher res screens [...]

     >

     >

     >

      I completely understand your motivation for this. It is true that

     >

      maps have an average maximum of three objects per square.

     >

      Hence, the right side map-arch-panel is mostly empty most of the time.

     >

      You want to better use that free space - Agreed so far.

     >

     >

      However, your approach to using that space does not seem very

     >

      good to me. You merged the attribute-panel (bottom) into the right

     >

      side bar. If you want to do that right you'd have to "verticalize"

     >

      the attibute panel's layout. That means in the end we have to

     >

      support two layouts for one panel.

     >

      Moreover, generally said it is never good to let GUIs become

     >

      "over-cutomizeable". By doing so, the application ends up with

     >

      most of the custom-options being unsupported (e.g. looking total crappy)

     >

      and users will cease to understand the available options.

  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.  I did make some minor changes to the layout.

  To some extent, I agree with the too many options means various ones become 
unsupported - need look no farther than the server and all the config options it 
has for that case.  I was mostly thinking that since the changes for this layout 
were relatively small, such issues would be less.  Plus, this would have to be 
done via if statements or the like, which at least means there is no problem 
with code not compiling when someone turns on some option like with the server.

>

     >

      Anyways, what about doing the exact opposite thing:

     >

      Merging the map-arch-panel (right side) into the bottom panel.

     >

      That would be a lot less painful as the map-arch-panel only has

     >

      two sections and that doesn't take a lot of "horizontalizing".

     >

      I'd guess in that way you could typically see a stack of about

     >

      4/5 objects before a scrollbar has to be used.

     >

      The customizeability issue would still apply but less severe.

  Are you basically saying that put hte arch/select panel along the bottom 
beneath the map window, and have the map window then extend to the far right? 
This is OK.  It doesn't work as well for me, as I have a very wide screen (3200 
pixels), so it results in more unusued space.  But it would still be better than 
the default, which really chewed up a lot of space not leaving as much for the 
actual map display area.

>

     >

     >>

     The window.diff file changes the editor so that the map 

     >>

     windows are now managed by whatever window manager you use

     >>

     (eg, they are top level windows), and are not drawn in the

     >>

     map pane.

     >

     >

     >

      Frankly, I'm really uncomfortable with that one.

     >

      Breaking loose the mapwindows literally "dissolves" all

     >

      plans I have for the editor layout.

  Note that both of these patches were more 'take a look, let me know what you 
think'.  If they are not made standard, not a terribly big deal - I can always 
keep the diffs for myself and apply the editor to get these preferences.  The 
release was sort of 'I did these,  I found them useful, other people may 
similarly find them useful'.

>

     >

      The most important point is, I honestly have problems to

     >

      verify for myself that this is useful.

     >

      What is mapmaking? - Most of the time it means inserting various

     >

      arches into a map. When I work with the editor, I constantly

     >

      select new arches in the left-side panel and insert them on

     >

      the map. Now if I had to switch/raise/lower windows every time

     >

      I want to fetch a new arch, that would drive me crazy.

     >

      Okay, maybe I'm just not used to hotkeys for that task, but

     >

      how am I supposed to do it when I have like 20 windows from various

     >

      apps open?

  I use virtual desktops of course, and the desktop I use for mapmaking is 
devoid of anything map windows necessary for mapmaking (which is basically the 
editor windows).

  It is hard to really know how to model this.  Different people have different 
usage patterns.  What works for me may not work for others.

  Note that most of my recent map work has been with the maps-bigworld outdoor 
maps.  This is probably non typical map usage.  What it typically entails is 
loading up a map, deleting spacing, putting in road tiles, and having the next 
map in the path also loaded so I can plot the road somewhat intelligently.

  As such, one I select the road arch I'm using, I tend not to need the main 
editor window that much.  I also tend to have only 2 (or sometimes 3 if the road 
path is near a corner) map windows open at a time.

>

     >

      The jungle of everlapping map- and pickmap windows was one

     >

      of the things I disliked most about crossedit.

     >

      I always ended up spending 50% of my time searching for windows.

  The pixmaps stuff was a pain.  Do note that with the change, you can use the 
Window tab from the main editor window - the map window you selecte will get 
raised.  This does at least provide a central place to maintain all windows.

  I'm curious how your going to implement the pickmap stuff :)  My personal vote 
would be a tabbed like list (like the arch selection) - typically you don't 
really need more than one pickmap at any one time (can only select one arch).

  What would be really cool is an easy way for the user to make their own custom 
pickmaps.  Eg, I'm working on a a specific set of maps, and I know I'm using 
this wall style, and this race of monsters, and this floor style, so let me make 
a pickmap of all of those so that everything I need is in that one pickmap.

>

     >

      An important question from my side is: What exactly do you

     >

      appreciate so much about having a huge place for map-windows?

     >

      I mean, if you have a big screen, the "normal" space should

     >

      already be quite large. I for my part never felt the need for

     >

      a larger view, really.

  I have a very large screen.  The default layout of the editor chewed up a lot 
of space if I still wanted to have enough space for the various pieces the 
editor displays.  I'm working with very large maps, so even with the huge 
display space I have, I can't quite display the entire map on the screen at 
once, so any extra bit I can is useful.

  The other note is that I get my 3200x1200 display be running xinerama.  Given 
that each monitor is only 1600x1200, ideally I want the entire map display on 
one monitor and not spanning them.  Much easier to control that when I can move 
the windows around - even with my changes, the problem is still that since there 
are 300 pixels on the left side of the editor window for selections, and another 
number on the right side, this then leaves a vast center area that spans my screens.

  Yes, I'm not a typical user.  It should probably also be noted that I did the 
popup window stuff before doing the layout change - with the layout change, the 
need for individual windows isn't quite as big a deal.

  Also, the changes to do that top level window wasn't that much.  You can also 
see note above on why I made these public.

>

     >

      First off, this offset does not steal you any space as you

     >

      can use the scrollbars to center the map-tiles into your view.]

  If you are using scrollbars.  In most cases, the map window I was using wasn't 
large enough to use scrollbars.

  Some of it goes to what I'm doing again.  The world maps are 50x50, or 
1600x1600 pixels.  If I trim down all that extra stuff, I can just barely get 
the entire width on one display.

  But really, the offset isn't that big a deal - I think I found it when I was 
trying to do some sizing logic (size window to size of the map) and said 'what 
is this for?'.  Leaving that in wouldn't but that big a deal.

>

     >

      Aside from the offset looking nice, I planned to eventually

     >

      use that space for managing multi-tiled maps. I'm not sure yet

     >

      how to do it best.

  Ok, fair enough.  A simple first stage would be an option like 'load tiled 
map, then have options for north/east/south/west'.   Perhaps under the map 
properties dialogue.  This would at least make it easy to load the tiled maps.

>

      It is certainly possible, but definitly not easy.

     >

      I don't know how much you want to have this feature, but I am

     >

      very tempted to leave it out. I don't feel comfortable with

     >

      the idea to maintain that kind of code.

  Yeah, from previous mails, I didn't really expect it to go in - I was just 
making it available for others who may want it.  I'd be content to keep it as a 
patch that I apply.  Maybe put it in an unsupported or some other directory in 
the editor so others could more easily find it/apply it if they wanted?