KDialogBase

[Ralf Nolden]

Richard Dale wrote:
> 
> On Thu, 12 Apr 2001, Roland Krause wrote:
> > So it does make perfect sense, because the dialogs will be reusable in
> > 3. Additionally, I will not switch to 3 before it has the functionality
> > that 2 provides. That is especially true for the MDI stuff cause the
> > window splitting in gideon is just plain aweful.
> I find the window splitting clean and tidy, but I don't know how you 'unsplit'
> a window. I don't like MDI, and won't use an IDE which forces that UI paradigm
> onto me (I am not a Microsoft refugee). KDevelop 3.0 just needs to be able to
> undock windows - it doesn't need MDI in my opinion.

Roland, Richard, everyone whining about view management :-))

As much as I know that Roland and Falk like MDI (which I personally do
as well to a certain extend) 2.0 will be *definetly* the last release of
the old codebase. That's a matter of fact. 3.0 is already usable to a
certain extend and I start working on it over this weekend to sort out
some gui issues with the menubar, so the handling becomes easier. The
handling of 1.4 and prior versions were the absolute plus for kdevelop
as it is really easy to understand what the user has to do. The only
thing that the users still don't get it updating the kdelibs api docs
and the database build which is easier in 3.0 now but the kdelibs api
has to be able to be configured system-wide for distributors; so this is
one area I want to work on as well. With MDI, the handling of 2.0
becomes better in terms of that the user can use multiple windows, but
the window menu is *very* confusing because of the many options-which
should go into a configuration dialog in the kdevelop setup. Users will
use one default value and change it if they want to - that's a usability
fact. But since the window menu is all tied into QextMDI this is kind of
not changable, or Falk ? QextMDI has a strength in that it is very
compact and easy to use from the programmer's point of view but it's
very hard to use from the user's point of view and as these things
cannot be changed very easily it is very inflexible in it's codebase
although it wants to cover all options. Besides all these arguments, we
have to agree KDE-wide for a standard on MDI because this *is* confusing
the user. The view splitting is nice as well, but I have to think about
where I want my view to appear, which should be the part of the program,
not the user, so I'm very split between all these options. But now it is
important to get 2.0 ready and stable to ship it, features which work
are ok, those who don't will get disabled. Then everyone should go onto
getting his hands dirty on 3.0, definetly. This is I think not this once
again, "yeah, we'll work on it later" thing, it's a "if we want 3.0 to
have more features than 2.0, we have to extend it NOW" thing for me. So
no excuses to continue on 2.0 after the KDE 2.2 release, please.

Anyway, have a nice happy easter and happy hacking. Who's doing an
easteregg plugin in 3.0 over easter ?? :-))

Ralf

PS: Mozilla's CVS contains a mozilla.kdevprj file :-))))

- 
Finally, even I have to admit that being myself was the best thing
that ever could have happened to me. - Le Grand Charmeur

**********************************
Ralf Nolden

The KDevelop Project
http://www.kdevelop.org

nolden at kde.org
rnolden at kdevelop.org
**********************************

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«