[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop
Subject:    Re: dialog editor in kdevelop
From:       Ralf Nolden <Ralf.Nolden () post ! rwth-aachen ! de>
Date:       1999-03-05 10:48:28
[Download RAW message or body]

RichardC@datel-technology.co.uk wrote:
> 
> > From:          Pascal Krahmer <pascal@beast.de>
> > To:            kdevelop@fara3.cs.uni-potsdam.de
> > Subject:       dialog editor in kdevelop
> > Date:          Wed, 3 Mar 1999 22:47:35 +0100
> > Reply-to:      kdevelop@fara3.cs.uni-potsdam.de
> 
> >
> > Iīm just working on a dialog editor for kde and I wanted to ask you what
> > you think about integrating it into kdevelop (hey, it is a very cool tool !!!
> > great work!).
Well, Pascal actually uses kdevelop for developing his dialog editor...
Nice that he included the project file.

>  Have you seen the messages regarding integrating QTEZ into Kdevelop?
> Having a visual programming interface for Kdevelop is something I am
> very keen on.
> 
> > But I have to mention that it is in prealpha state at the moment and the next
> > week Iīm on holidays so donīt wonder if i donīt answer so fast. I think the
> > first more or less stable version should be available at the and of march till
> > the middle of april.
> > So if you have wishes for it, write them now cos now it would be the best point
> > of time...
> >
> 
>  How does your program compare with QTEZ, MAWC and QT Architecture?
> 
>  Richard.

Now, there were many mails and questions about the dialog editor which
we (the core team) thought should be discussed when 0.3 is released.
As this will be the case next monday, I already collected my mind to
what I think an integrated dialog editor should look like and what the
concept 
should be, so here it follows and I'd like to have this discussed if
that concept structure is of use. I think we have to set up a complete
concept how it should look like and what abilities the dialog editor
should have. Then, everybody developing on that part of kdevelop should
actually stick to the plan and only change details.

	More importantly I want to have this discussed to stop speculations and
the waste of work (to my mind) to hack some other existing programs as I
think this time it should be something serious. For Pascal, if you want
to integrate your existing code into kdevelop, you're welcome, but we
first should make a concept and then start working, not the other way
around. This has caused us many coding pain in the past to bring
kdevelop to the state it is now and I just want to avoid too much
hacking in the future, especially as the project management will be
affected and working on that is a really unthankful work, so I'm glad
that Sandy does this and we should stick to the current structure and
only extend it. It depends on you if you're willing to completely
integrate your work or if you think that you better like to develop your
editor on your own and include structures to use it with kdevelop as
separate program-opinions ?


1. General

The dialogeditor's user interface should be fully integrated into the
binary and view of kdevelop.
Widgets which can be constructed should be in libraries, so we make one
library for each widget (or acccumulate according widgets into specified
libraries) and only have to add menus and toolbar buttons.
(like mawc /kbuilder does)

2. The user interface

>From within kdevelop you can switch to the dialog editor by an entry in
the tools menu.
This will hide the main view, toolbar and menubar and replace it with
those items of the dialog editor.
The editor's menubar will contain a function to switch back to kdevelop,
changing all views back to default.
To construct the views, the according functions have to be coded in the
CKDevelop class and only be called by switching to the editor.
This will set a flag that those functions were already called, so if the
user again switches to the editor, only the hide()'s for the kdevelop
view will be called and show() for the editor's items.

3. The menubar and toolbar

The menubar will contain file, edit, resource ?, help.
The toolbar will contain new, open, save, undo,redo, cut,copy, paste.
Then symbols to create new things like:
new menubar, new toolbar, new widget, new Dialog

4. The editor's view

After trying some existing editors and using qtarch (k.a. dlgedit), this
should look like as follows:

panners should separate the view into three vertical parts:

Left: 
window containing icons for widget types. Depending on the project type,
the according icons will be inserted and the libraries loaded.
This is actually important to save loading time as well as only giving
widgets that can be used. E.g. a qt-project shouldn't be able to insert
KDE-widgets.
A c++ terminal app should deactivate switching to the editor completely.

Middle: 
empty widget with white background. Can be used for editing resources
like keys, id's and statusbar messages (resource editor). Default is
empty, only when switched to resource editing mode opened.
This is the background widget to which new widgets or dialogs will be
the background for. Widgets to be edited shall be shown in own windows
(like every known dialogeditor does), also the main view with the
menubar and toolbar shall be made editable directly like QtEZ does. This
will be the same for widgets like if you edit properties for labels, the
label text will be updated automatically.

Right:
Properties window like Pascal's. Just with the difference that property
values like true/false, Palette_Background etc shall be made with
comboboxes. Numerable values shall be editable by a click int the
value's field, giving a cursor and highlight the current value (for
direct overwrite).

5. Dialog editor files
The dialog editor will use file ending *.kdevdlg, so we keep away from
mimetypes of qtarch and mawc (to my surprise mawc opens qtarch generated
dialogs but hangs up- we should avoid this.) and can set up our own
mimetype for that, opening the  dialogeditor directly. If the project
filename has to be included into the dialogfile will have to be
discussed, because if a dialog is opened by mime-type, the according
project will have to be loaded to find the right source files.

6. Generating source code
The editor will generate c++ source code. Depending on the project type
(KDE/Qt), the according headers will be inserted.
For editing menubars and toolbars we should keep to function
conventions, so they can be read by the dialogeditor and edited. The
sourcefile will have textmarks for the dialogeditor to insert code,
including a hint that this should not be edited (but we can't prevent
the user from doing so- we have to test what will be the best to do
here)
For future corba apps I think that the system to stick to the project
type will do it in any case and can be extended, same with libraries:
this type shouldn't offer any menubar /toolbar /mainview options.


This is what I thought would be a base of discussion for the upcoming
dialogeditor. I please all interested persons to comment on this and add
details.

Bye,

Ralf

[prev in list] [next in list] [prev in thread] [next in thread]