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

[Andreas Vogl]

in reply to Mark W.:

>
     
      Attached are a couple diffs I made to the java editor. [...]
     
     >
     
      These are mostly here for comments and possible suggestions.
     
     
I applied both of your patches for testing.
The diffs still work except for their paths.

>
     
      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.

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.

>
     
      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.

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?

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.

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.

Is it the ability to have a total overview over a huge map?
Or maybe is it only the ability to lay adjacent multi-tiled
maps next to each other?
If it was the latter for example, you should know that there
would be much cleaner and better ways to achieve the same thing.
The editor could be enhanced to load multiple map-tiles into one
mapview, being able to save them correctly too.

>
     
      Also, the current map draw code seemed to have a harded 32
     
     >
     
      pixel offset it used for drawing.  
     
     >
     
      Not positive why that is there - in my effort to squeeze in
     
     >
     
      every usuable pixel, I removed that [...]
     
     
First off, this offset does not steal you any space as you
can use the scrollbars to center the map-tiles into your view.

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.

>
     
      [The map-window patch] is more problematic - since it changes
     
     >
     
      the inheritence of the map frame from an internal frame to just
     
     >
     
      a jframe, I don't see an easy way to control this via a
     
     >
     
      config option.
     
     
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.

>
     
      The only interesting point on that is that if the picks
     
     >
     
      support gets put in, the picks map could always use the
     
     >
     
      internal frame to prevent cluttering the users desktop 
     
     >
     
      (eg, you could basically use both at the same time).
     
     
At all costs I want to avoid a cluttered desktop.
ATM, my best idea for the integration of pickmaps is to
put them into the spot of the arch-panel (left side).
Youd could then switch between arch- and pickmap selection.


AndreasV