#2748-FI: Resize classes when they have long attrib/method lines

[toniloCoyote]

Hello and congratulations for the product.

The very first problem I've encountered just in the begining of using the software is about the navigation. I have a few classes which have one or two function members with many parameters.

Due that the box of the classes can't be shrunk and there is no option to hide the parameters of these members (I'd prefer the first), these box are toooo laaarge only because these one or two functions. You can figure out how difficult is to navigate along the diagram in such circumstances or even further to have a big picture of the design logic. If you want to see more than one or two classes at a time you must zoom out the diagram to a lilliputian view.
I can't even stack the long boxes one over the other, because I can't selectively bring to front the one I'd need to see.

I think it would be welcome to be able of freely re-sizing the classes boxes for laying out the diagram to the liking of the user (better speaking, to the needs of the graphic).
I would feel very comfortable too if I were able to pan the picture with my mouse (how about by means of the middle button?); the scroll bars aren't good tools for panning graphics in a repetitive way.

Hope to help.
The software seems to be so exciting when finished.

[Cristian]

Hello!

Thanks for the appreciation .

I have a few classes which have one or two function members with many parameters.

We are aware of this problem. We'll introduce a visual style that would control the display of methods: with or without parameters. We prefer this approach (rather then allowing to "shrink" the class. Shrinking the class would mean scroll bars, etc. This feature will be available in M3.

As a work around until then, you could use the filtering (and hiding the method(s) that are very long).

I would feel very comfortable too if I were able to pan the picture with my mouse (how about by means of the middle button?);

I agree with you. We have such a tool planned for M3 as well.

Best regards,
Cristian.

[toniloCoyote]

Thanks for your early answering, Cristian.

I hope don't bother you if I write a last point before closing this thread:

I have never understood why to limit the user when there is no need to do it.
When you zoom out the diagram, most of the class members lines get truncated even when there are still sufficient space in the box width for displaying them entirely; when you click over a class member, this member line appears in the head of the comments panel in a wrapped way, showing its full content, but in multiple lines.

But if the user has some members too long in the box, must he hide the content of this and the rest of the lines? (and to hide also the lines of all the other classes?).
I prefer the approach of not limiting the user.
If I don't want to make things complex and have to build scroll bars or making possible to wrap lines,  I'd give the user at least the ability and the responsibility of hiding or showing the length of the line by himself by re-sizing its container box.

Excuse if I'm seeing the things less complex than they really are, but I like being practical; I don't give more importance to the fact that the lines shine when you move the mouse over them, over the fact that you can not manipulate your design parts.
It's only a question of priorities; first the effectiveness, last the look.

Despite all of these, I think your software will be a sure bet.
Thank you.

[Cristian]

Hello,

I hope don't bother you if I write a last point before closing this thread:

And thank you very much for your feedback, which I find very helpful.

I have never understood why to limit the user when there is no need to do it.
When you zoom out the diagram, most of the class members lines get truncated even when there are still sufficient space in the box width for displaying them entirely;

Limiting the user is the last thing we want to do. The "..." problem when zooming is due to a technical limitation (Flex doesn't scale properly the fonts) and it is not trivial to overcome. We will provide a solution (I hope to have it in 1.1 version).

this member line appears in the head of the comments panel in a wrapped way, showing its full content, but in multiple lines.

I don't understand this behavior very well; could you send a screen shot?

But if the user has some members too long in the box, must he hide the content of this and the rest of the lines? (and to hide also the lines of all the other classes?).
I prefer the approach of not limiting the user.
If I don't want to make things complex and have to build scroll bars or making possible to wrap lines,  I'd give the user at least the ability and the responsibility of hiding or showing the length of the line by himself by re-sizing its container box.

When there will be the style that controls if yes/no the operations display their parameters, I don't think the big classes problem will appear any more. My suggestion of using the filtering to hide ONLY the long methods is just a work around until then.

If I understand correctly, even when we'll have the above style, your suggestion is to have an option to allow resizing with no restriction, even if this implies the creation of scroll bars; am I correct?
The disadvantage of scroll bars within classes is that the class won't "grow" when new attributes/methods are added (from the tree, codesync, etc).

Excuse if I'm seeing the things less complex than they really are, but I like being practical; I don't give more importance to the fact that the lines shine when you move the mouse over them, over the fact that you can not manipulate your design parts.

I totally agree with you. We want our tool to be as friendlier as possible with the developer. This means max of flexibility, productivity and min of limitations.

Thanks again for your feedback.
Best regards,
Cristian.

[toniloCoyote]

Hello, Cristian.

I'm glad to see that you in Flower take our feedback into account.

What I propose only is to let the user to decide by himself the width of the boxes without losing the ability of viewing the member's parameters. You give this ability, but you suggest to disable it when a solely member makes the diagram cumbersome.
Well, you know, the problem of resizing text boxes was an issue for old programmers, and the patch of hiding the inner text was never an acceptable solution.

Following the actual container's pragma:
The user draws a diagram; the diagram contains boxes; the user re-sizes the diagram or the boxes; neither the diagram nor the boxes lose their contents.

What happens with the long lines?
Maybe they get truncated, maybe they wrap into multiple lines, maybe the boxes grow in height or maybe they get a scroll bar. It don’t care so much; the fact is that you can re-size the boxes while still seeing the entire content, at least, of the not-offending members.

To see the member’s parameters is a great thing. This is why you did your program so. Why do you use containers?
This is my point of view, which I hope helps in any way.

NOTE: The behavior I talked about in my last message is the one of the Documentation panel, but it's only an example. I've attached a pic to this message.


Best success
tonilo

[Cristian]

Hi tonilo,

Maybe they get truncated, maybe they wrap into multiple lines, maybe the boxes grow in height or maybe they get a scroll bar.

I added this request to our feature list. I don't know if we'll have time to put it in the next release, but we'll implement it for sure.

Best regards,
Cristian.

PS: I'm renaming the thread according to the feature name.