In other words, embedded designers or stand-alone top-level designers. This argument has certainly served to polarize the Delphi community more than anything else has in recent years. There are those that only accept a "pure" traditional Delphi style designer, there are those that don't seem to care one way or another, and then those that are perfectly fine and somewhat prefer an embedded designer. It seems, however that the Delphi "purists" are the most vocal and vehemently against what they would characterize as "messing with success," by adopting a modal/embedded approach to form design. Personally, I've adapted to using either style and can see some of the advantages that each side has to offer. You might come to the conclusion that since I'm the one that did all the work to embed the VCL designer, I have a vested interest in keeping the designers as purely embedded. This certainly would allow me to focus on making that one mode work the best that it can. However, there are a few items that the embedded designer simply isn't able to address.
The embedded designer makes for a cleaner, more controlled environment. You always know where the designers are located, you are insulated from your co-workers that have screens with laser-printer resolutions placing the design form at some location that is someplace off screen. The designer also can display the border style of the form in the actual style that it will end up being rendered as. And, there is just a feeling that everything is more organized and more "under-control" with the embedded designer. There isn't this haphazard arrangment of windows with all your other applications peeking at you from between the cracks.
In the other camp, there are some things that the top-level "floating" designer does that simply cannot be done as easily with the embedded designer (and by extension, a single-window docked IDE). You can design a form that is at or near the actual screen resolution much easier since there is no "frame-overhead" for each designer. You can arrange the forms in such a manner that you can see several at once, which in the case of inherited VCL forms, is very helpful when modifying an ancestor form so you can see the live-updates on all the descendants and determine if moving the "OK" button will obscure something on any of the descendants. While, personally I prefer to dynamically position the forms at run-time, you can set the form position to "poDesigned" and manually arrange all your forms in the locations in which you want them to appear at run-time. Then there are the issues regarding the more frequent use of multi-monitor systems where developers will use the primary display to position the design-time forms, and use the secondary display for the menus, code-editor, OI, and other design-time/editing support windows.
Now before you start warming up your flamethrowers and start indiscriminately spewing expletives regarding your disdain for one style or another, just understand, that this issue has been heard loud and clear and we are looking into ways to address the issue for a future Delphi product release.
Allen, it's all about freedom. It's like taking a bird and putting it in a cage and telling it that it looks better with the environment <g> An IDE is not used by beginners, but by people who spend most of their day in front of their computers; we need as much flexibility as possible (well, I do :-)
ReplyDeleteYou summed up the "pro-floater" camp's argument perfectly. And it slays the paragraph above it.
ReplyDeleteIf you can do both styles, fine. If not... Don't mess with success...
Give your developer/customers all the power they can handle. And for god's sake, once the power is given, don't take it away.
-d
FWIW if I had to pick one, I'd pick the old style but it's not a showstopper for me. Both options would be the best options of course.
ReplyDeleteKeep up the great work!
I like the old style but find too many free floating dialogs annoying. Usually I dock everything possible in the IDE except forms. The new style has it's perks just mouse wheel or mouse follow support in the embedded designer would make life a little easier.
ReplyDelete"you are insulated from your co-workers that have screens with laser-printer resolutions placing the design form at some location that is someplace off screen."
ReplyDeletewhich is of course something that could /easily/ be solved otherwise (say, but adjusting the form coordinates at designtime when it comes open off-screen) and thus isn't really an argument pro the embedded designer...
Interesting post. One more vote strongly against the embedded stuff. I got acres of screen real estate (dual display 23'' 1920x1200 & 17'' 1280x1024) and want to see several forms at the same time, preferably on multiple monitors.
ReplyDelete<quote>
you are insulated from your co-workers that have screens with laser-printer resolutions placing the design form at some location that is someplace off screen.
</quote>
Like Marc this surprises me greatly. I always thought that this was a small Delphi bug. Would it not be easily fixed by doing a validity check on the form's position before opening it? My applications remember the last form position and I got a general SetValidFormPosition(aForm: TForm) method that is called in the OnCreate event in case the user switched its screen resolution or changes screens.
What I always wanted to know, but were afraid to ask: Why is the default Form position poDesigned and not poDefault?
In a world where so many different screen resolutions exist this seems to bring much more problems that the poDefault. Especially with developers typically working at higher screen resolutions than the end user.
Jan Derk wrote:
ReplyDelete> Why is the default Form position poDesigned and not poDefault?
That is probably historical - I think in the days of Delphi 1/2 (Win95), there was less variability in PC screen resolutions than nowadays. Nobody in my office had a 23" monitor back then, it was pretty much all 17" running 1024x768.
FWIW, I'm firmly in the "flost" camp.
I don't see any advantages at all in the "embedded" designer - those mentioned by Allen are only laterally related to the "floatingness" of the form designer.
Kristofer
PS. Allen, might I suggest two small improvements to your blogpage layout:
a) A somewhat wider right text margin,
(I keep worrying that I'm missing nonwrapping text)
b) Scalable text size...
thanks...
As Marc has written the argument of the out of screen forms is so simple to fix without an embedded form designer as I can't even believe you count that as an argument for the embedded designer. The classic floating designer is much more productive for me and I hate any embedded form designer IDE (like VS.NET and D8). It is to much against my daily work practice and does reduce my productivity.
ReplyDeleteSo plaese try to do as much as you can to give us the floating option asap.
I'm all for floating, with docking capability. Agree with statements made about having the designer arrange the form automatically if off screen due to a resolution/computer change.
ReplyDeleteI love the new component pallet though.. Use the new pallet with the old floating design ;)
It's great that this is being considered!
Curt
<quote>
ReplyDeleteI mostly agree with marc's comment, but I'll point out that if the IDE does this <i>and</i> you're using poDesigned, it's arguably a bug as the IDE would be changing properties you might not intend to change.
</quote>
While theoretically right, it makes me wonder if there is one single developer on this planet who uses poDesigned forms *and* wishes it to be outside the screen.
P.S.
One more blog layout suggestion: The goddess and temple background images while being very beautiful make the text a bit hard to read.
It's funny, the last comment in the blog was basically saying, "don't waste time starting up the old debate, I've heard it all before, we're working on it" yet since all of us developers secretly think that our opinion is the one that really matters we all just start the debate up again.
ReplyDeleteSince I see a completely illogical, blind, "cling to the past because I'm scared of the future" skewing towards floating editors I need to plant my flag and raise the cry for Embedded! Oh give me the ability to drag the entire IDE from one monitor to another, give me an IDE that doesn't look like some VB 4.0-clone from the Dark Ages, banish the peepshow of background windows, stop the constant fiddling of docking.
The great unwashed cry for more space to design their form, I say what is wrong with you that you need a form that large! They say I need poDesigned, I say they are arrogant fools that assume everyone has their resolution. They say it looks better, I say please shield my eyes from any apps they must be writing as they most likely have no idea how to design a good looking, polished GUI.
Hopefully my sarcasm is coming through. There is no right or wrong on this one, just what you are comfortable with. Any “logical” arguments will simply be supporting the style in which *you* use the IDE. This is a preference, one most likely established during the formative years. Personally I always hated the VB IDE and when I went to Delphi I was saddened to have to fumble through basically the exact same thing so I embrace the idea of an embedded designer.
A side note, our company did some fairly extensive user interface testing with a floating and non-floating version of our application and for those not already mired in a mindset the embedded won hands down.
Kristofer,
ReplyDeleteTry it now. I changed the styles to allow scaling of the fonts and adjusted the right margin of the text.
Jan,
I'll see what I can do about the images. I'd already lightened them a little, but it might need a little more.
My only gripe (and it's sooooo annoying) about the classic floating mode is that I can't move forms around without fearing that I modified the DFM file. If the Position Property of the Form is anything other than poDesigned, then I want the full freedom to move forms around at design time as I please without fear of the DFM changing. I reckon this could easily be done by persisting an override position somewhere besides the DFM unless Position is set to poDesigned. That seems possible to me.
ReplyDeleteI'm freee!! Free floating!! (Tom Petty voiceover)
ReplyDeleteI'm still using D5, anticipating upgrade to D7, and just recently even found out that D8 has embedded designers? What the?
I work using a virtual desktop, that gives me 4 800x600 desktops on one monitor in WinXP Pro.
IDE and Code window in upper left, current form design lower left, Object Inspector nice and huge in lower right, and upper right used for SQL and TField/TParam lists..
If D8 is embedded, I'll pass..
I like embedded designer,just like D8 or Jbuilder.
ReplyDeleteJbuilder is a great IDE,I think Delphi should learn more from Jbuilder
I don't like Delphi7 floating designer. it's difficult to find a form from many forms.
ReplyDeleteI'm firmly on the float side of this issue. For those of you who, like me, tend to lose forms in the crowd, there is an easy and free solution: GExperts.
ReplyDeleteI have the GExperts Forms List and Components List on the GExperts toolbar. A click on the Forms List allows me to quickly list all of the forms in my project and select the one I'm looking for.
The Components List allows me to do the same for all of the components on the form. A side benefit of the Components List is that I can easily find unused components on the form and remove them, or select components that are hidden behind another component.
http://www.gexperts.org/
Actually, there are three possible designs for the designer:
ReplyDelete1. Floating, modeless (as in Delphi 7)
2. Embedded, modal (as in Delphi 8)
3. Embedded, modeless (as in a future Delphi version :-) )
An embedded modeless designer would combine the best of both worlds. An embedded designer keeps the form in a handy place and enables the object inspector and other design time windows to be docked at its side. Making the designer modeless means having the ability to have several designer windows visible at the same time, as well as having the corresponding source code visible at the same time.
Most of the arguments about embedded versus floating are really about modal versus modeless. A modal design is easier on the developer, but far less flexible for the end user.