-
With 8.5 & 8.5FP1, DDE does not automagically expand the tabs along the bottom of the editor, if I did not have them expanded when DDE was shut down. It was pretty consistent about this.
-
When DDE 8.5.1 is loaded it does automagically expand the tabs along the bottom of the window, as if that’s what I wanted all along. This isn’t developer-friendly.
-
It also always opens the Applications panel fully collapsed on launch, even if it’s the only application in the panel, where pre-8.5.1 didn’t do that, either. Those opened with the first level expanded, ala the R-prior navigators. Since it’s pretty much impossible to do anything with an Application in DDE without expanding that first level, this is also not developer-friendly.
-
Then there’s how the Java Editor is invoked. Not only does it take twenty seconds of “Operation in progress” to get anywhere, where one gets is an intermediate panel where another double-click is necessary to open another editor to actually do anything with the code. This second editor is where it should go the first time. This first panel should actually be under the Applications tab, anyway, it’s utterly alien where it is. This smacks of an ill-thought out rush job and introduces yet more developer-unfriendliness.
-
And there’s Agent properties popping up every time an Agent is edited, horrendously bollixed help, tooltips that are impossible to get rid of, and all of the other stuff we “got” with 8.5 in general. Those are additional steps backward about 8.5.1, but they are leaps backward from R-prior.
-
On a positive note, 8.5.1 DDE does load quickly compared to glacially slow 8.5 except for the Java Editor. And the client has restored “Open in a new Window”. Kudos to that!..
Subject: Fwd’d to development
DDE/PL
Subject: AMEN!
I have to say I agree with everything you’ve posted…it really feels like designer was one big rush job.
Subject: some questions and responses
I want to be sure I understand what you are saying about “the tabs along the bottom of the editor” - I assume you mean the property panels? There was no intentional change in that behavior between 8.5 and 8.5.1 - do you have the preference set to minimize Eclipse views when editing classic elements? Any chance you had a different preference value in 8.5? We’d like to track this down, but it would help if you could describe this a bit more.
We no longer open the first database on Designer launch for performance reasons. When we analyzed performance results for 8.5, opening that first database (which may or may not be the one you even intend to edit, and possibly the server wouldn’t be up, etc.) was one major contributor to the slower launch time for the 8.5 Designer. It is a tradeoff, granted, but given that we can’t be sure you want to edit that one anyway, and the importance of the performance improvements, we felt it was a worthwhile trade.
The Java editor reflects the structure of the Java agent/script library/web service consumer/provider. We actually spent quite a bit of time and tried a few different designs before we and the UI designer settled on this one. Because these design elements are Java projects, and because Eclipse doesn’t support nested projects, we also faced some technical restrictions. So in the end, we settled on this abstraction layer that we present as the first screen. We also needed the edit project function from the older Java editor so you could have a place to add the script library and other resources to the project. So while I would love to simply open to a single Java file for these elements, that didn’t work with the reality of the Domino elements. How would we know which of the Java files you would want to edit within the Java agent? We could guess the first, but then we could be wrong. We’ll investigate the performance again to see if there is more we can tune there. Did you find the old Java editor to be fast? At least the first launch of that always had a measurable delay.
Whether or not the infobox should pop up when a design element is being edited has always been controversial, and we have gotten feedback in equal and opposite directions over the years. For some it’s a convenience; for others, an annoyance. I am not aware of this changing between 8.5 and 8.5.1 unless a bug was fixed where we started doing this again after not having done it in 8.5 because of a bug. I think at this point the best option is likely a preference - that way we will only have to worry about getting the right default (which we will probably only succeed at for 50%!)
Thank you for your feedback, we are working hard to make Designer the tool we all want it to be. There are significant enhancements in performance and quality in 8.5.1, but it is very helpful to know which areas we should investigate next, so please continue to let us know.
Subject: Hi Maureen. I’ll attempt to clarify…
-
I do in fact mean the property panels. It’s where Events, Properties, and Problems are currently in my DDE. I’ve detached everything else because they all behave nicely when detached. These three do not, so I keep them at the bottom and keep that whole panel minimized, only opening it when I have a need to, which is increasingly rarely as I learn what to do in the Source editor. I did an “upgrade” install of 8.5.1 from 8.5FP1 and did not change any settings. In fact, I didn’t change any settings (that I recall) in 8.5 … like Eclipse does and should do, it remembered the state of that panel when it was closed, and when launching it applies that saved state. I know this because 8.5 actually paints it open, during that long wait for launch, but by the time 8.5 DDE is fully initialized it’s closed again. That’s fine with me, long as when I put finger to keyboard it’s where I left it.
8.5.1 does the same thing; initially paints it open, then it reverts to my saved state. Just as it paints the main content (to replace that silly “Home” thing), it reverts back to open even though it was just closed.
I should point out this has nothing to do with “classic” elements. It’s an IDE-wide behaviour that I enjoy editing XPages or anything in DDE. Well I did enjoy. Now it’s gone I don’t enjoy it. (grin)
-
I figured it didn’t open ‘the first database’ for performance reasons, but it saves nothing when ‘that first database’ is the only database open in DDE. All it’s done is make the developer do one more useless click before starting to work. I don’t know about the rest of the world, but I very rarely have more than one database open in DDE at a time unless I’m copying elements from another location, in which case I close the extra the moment I’m done. I always remove the current database from DDE before opening another. I personally would rather have multiple instances of DDE, like R4 Designer used to support, instead of having tons of clutter crammed into the navigator. (shrug) It’s not a huge deal, but when one works on four completely unrelated projects all day long, every day, those useless clicks add up.
I can tell you that 8.5.1 instantly opens ‘that first database’ after load, at least when it’s the only one in the list. I’m not seeing how this degrades performance to have DDE open it for me.
Thanks for the clarification!
-
I figured this weirdo intermediate page was primarily to duplicate the old “Edit Project” button, and didn’t realize that each class created a separate .java file in the list now. That makes sense. The old behaviour, however, used to be to open the .java file with the same name as the Agent, which always used to be the first one, but may not be now. Then others would be editable from that point. What’s wrong with that behaviour all of a sudden?
As for the project/other files/etc, I still believe this information is better suited to the Application panel. Make the Agent itself “expandable”, just like the Agent list, and put this exact same tree of information under the Agent name. If one wants to edit the file with the same name, double-clicking on the Agent name will open it, perhaps opening the tree to display project-related information, perhaps with a preference setting to let the developer control that behaviour. If one wants to edit an alternate file, double-click it on the project tree. It would be even nicer to have the standard Eclipse behaviour of displaying methods and data elements, as an expansion under each .java file. I currently see that nowhere in the DDE incarnation.
-
I found the Java editor under R6 to be acceptable. Just checked it out … it takes about seven seconds to load a Java Agent, and it doesn’t require more clicks and waiting to do so, which saves even more time. R8.5FP1 loads a Java Agent nearly instantly. Just launched that fresh, and opened an Agent, it was stunningly quick. I should point out that I am opening the same Agent from the same database on the same remote server for all of these comparisons.
-
On a side note, I still see no way to run an Agent from the right-click context menu for the Agent. When I see a list of Agents in the Application panel, I should be able to run one right from there, not load the list of Agents (that I can already see) in the main content, right click, and run there. Same with sign, view log, enable, disable … that should all be doable right from the Applications panel’s Agent list. Maybe cascaded menu so it doesn’t clutter stuff up so much, there already being quite a bit of Eclipse-default stuff there.
-
BTW, I like how the the “are you sure” dialog when removing a database from 8.5.1 DDE now defaults to “yes”, so I can click-ENTER and everything is gone. Definite improvement.
-
More digression. (grin) We use CIAO! for template control, and it’s more than little annoying that DDE forces me to check out build.xml and plug-in.xml, just to load the database. I realize they are likely managed by the automagic in Eclipse, but something has to be done about that. As it stands it is utterly and completely impossible for two developers to edit the same template, because the first will “grab” these two files, and the second will be unable to open DDE without them. We have a recent release of CIAO! as well, which is supposed to be “compatible” with 8.5. This implies Lotus didn’t work with them to ensure product usability. Not a pleasant thought.
-
I am not and never have, since I first loaded 8.5, suggesting that the properties box always do one thing or another. If you go back and look, what I’ve been pining for is that the DesignNoInitialInfobox setting in notes.ini be honored just like it used to be for R-prior. It wouldn’t bother me if I didn’t used to be able to turn it off. That’s it.
-
I am first in line to agree there are a ton of very nice things in DDE 8.5.1, and I whole-heartedly support the move to Eclipse as the base IDE. The down side is that even 8.5.1 DDE quite seriously comes across as a “work in progress”, which makes it considerably less desirable for enterprise-level application development. Does that mean it can’t be done? No in the slightest! It just means it’s more of a PITA to do it, because DDE doesn’t appear to have the developer focus that normal Eclipse does. The up side is that with Eclipse as the base IDE I feel this lack of developer focus is significantly easier to resolve.
Thank you very much for your time…
Subject: more
in random order!
- the old java editor had all the java source available in one window, and simply had to expand the section for the first one. We could look at opening the first Java file in addition to the project page - would that be helpful? One of our earliest designs did try expanding things in the navigator - but that encountered virtual file system difficulties. We can look at it again, as it was a design we liked, it just is not as easy or doable as it may appear - particularly since we would need to materialize a linked project just to expand that thing.
I spent some time this morning opening some java agents, and I’m not seeing 20 second delays. Now there could be differences in the agent and/or the hardware, but it seemed no worse than the old Java editor to me (which always took a hit for at least the first instance to do some jvm loading). Could you possibly send me a troublesome agent so we can do some testing/tuning on opening it?
It is a good idea to add Run agent to the navigator (I am also wanting the preview function there). We will look at adding that. I do know that several people have extended Designer using the extension API to add that! That’s always a very good clue that that’s a much needed core change.
that ini setting is exactly what I was thinking we’d turn into a preference, and if it isn’t working, then we broke it and should fix it. Since it’s an unsupported ini, it likely didn’t get caught, but it was unintentionally broken, so we will intentionally fix it.
We’ll also see how the property panel got too bouncy, what stepped on that code to make it do that.
Thanks for your help!
Subject: Java editor…
-
I think opening the Java file with the same name as the Agent, rather than just the first one, could possibly be useful. My fear with that is that DDE “hides” tabs when too many are open, just like Eclipse does, so opening two tabs per Agent, if one is editing many different things increases the chances that tabs will “disappear”.
-
Regardless, if this is done, it should be a preference. I may normally come across as dictating to the world, but that is not actually how I feel personally, and I would prefer it remain the way it is than force my desires on everyone else, unless some previously established mechanism indicates enough are interested in the change to justify permenance. Even if that justification is present I always favor preference over permenance, with a change to the default behaviour, because that lets the developer decide how they want their IDE to function. What one developer considers indespensable, another will consider intolerable. That’s how we are. (grin)
-
I’m sorry to hear the initial attempt to put this project stuff on the Application panel failed. It does explain why the current process seems so rough cut … it was a fallback, and could have been done on short time after the other failed. I appreciate knowing this is the case rather than scratch my head at how it is now.
-
On “tab hiding”, with R-prior I would often have fifteen or more edit tabs open. They would “scrunch” together, becoming increasingly narrow, but that was fine with me because A) the two or three chars visible generally identified them well enough and B) a hover would show the entire tab name. I could just as easily tab to the first file opened as the seventeenth. DDE’s “tab hiding” (which comes from Eclipse, one of the very few things I dislike about that IDE) means I constantly hit the “hide limit”, so I don’t know what I do and don’t have open any longer, or I’m forced to close things I’d prefer to have open in order to see them all. This is less desirable than “scrunched” tabs, for me personally, because a single glance no longer tells me what’s open, what’s unsaved, etc, etc. If this “tab hiding” were configurable to “scrunch”, then I could care less how many tabs get opened when a Java Agent is edited, because the “project tab”, which I am considerably less likely to want to edit, won’t push other “code tabs” off the visible list. Does this make sense?
-
It doesn’t matter what Java Agent I open, it’s just really slow. I just opened one on a remote server and it took over 180 seconds to show the “project tab”. This slowness spans databases and Agents. As such any Agent I sent could be considered a “problem Agent”.
Thanks for your time…
Subject: Properties panel…
- In addition to Agents and Views popping the properties box all the time, ignoring the .ini setting, each time I edit a View in R8.5.1, it opens the Properties/Events/Problems panel “for” me, just like it does when I launch DDE. This is not what R8.5 or 8.5FP1 used to do.
Subject: DesignNoInitialInfoBox is working…
- I don’t know when it happened because I’ve done clean installs since it stopped, and since it didn’t work I didn’t put the ini setting back in. Today, Views popping this dialog got on my last nerve, and I remembered you saying it should be fixed at some point, Maureen, so I stuck it in there. No more info boxes. Bonus!
Thanks for fixing this…
Subject: Domino Designer 8.5.1 performance “dead spots”
=====================
Despite all the effort that the various IBM Lotus Software teams around the globe have undoubtedly poured into Domino Designer (DDE) 8.5 and 8.5.1, I tend to agree with David Gilmore that it comes across as an unfinished work. I could be cruel and say that it’s the result of “design by committee” but that wouldn’t altogether fair!
I tend to agree with David that there are inconsistencies in the way that things happen, and he has given enough examples for me not to have to elaborate.
The biggest concern that I have, after some 3 months’ serious usage of DDE 8.5.1, is that several aspects of DDE performance and responsiveness are quite unacceptable. Even with a fast quad-core desktop system (having gigabytes of spare disk and 8 GB of RAM), there re everyday task that were very fast in pre-Eclipse Domino Designer that are laboriously slow in DDE 8.5.1
By this I mean that simple everyday design activities that once took only a few seconds, or were even sub-second, in responsiveness are now taking tens of seconds, which is way past the widely-accepted rule of thumb of 10 seconds being the upper limit that you should have to wait for any non-complex transactions to be processed.
For example, removing a database from the design list used to be pretty much instantaneous (in the “old” designer client, prior to 8.5), but now in DDE 8.5.1 consistently takes about 22 to 23 seconds.
Several other seeming trivial Designer are similarly unacceptably slow, or even slower, and I know from closely monitoring the Lotus blogosphere and other Lotus sites in the Lotus community that I’m certainly not the only one upset about such exceeding slowness, which takes some of the gloss off the otherwise very nice DDE 8.5.1 experience.
For me, the worst user experience is opening Domino Designer 8.5.1 either form the Notes client (by right-clicking on a workspace icon and selecting “Open In Designer”) or by launching Designer client directly (without the Notes client being open). In the former case I experience very close to 40 seconds of nothingness and then the Designer client opens. In the latter case, the Designer splash screen appears after a second an acceptable second or two, but once I’ve entered my password there’s about 20 seconds of nothingness, then the splash screen disappears leaving me staring at the Windows desktop wondering if Designer has crashed, than about 20 seconds later the Designer client appears from nowhere!
As if that isn’t bad enough, two days ago the 40-second Designer launch for no apparent reason changed to an extraordinary 4 minutes and 20 seconds. I could only guess that something had gone seriously wrong with the Eclipse underpinnings, and after losing a day or so of experimentation I’ve worked out a procedure for recovering from this predicament, which in the next day or two I’ll post for everybody’s benefit in on my Notes Tone Unturned blog, at http://notestoneunturned.blogspot.com/ … Go visit and see for yourself.