KDevPlatform and GluonCreator cooperation

Tue Jul 19 18:09:19 UTC 2011

Hi KDevS ;-)

As some of you may remember, we have spent a pleasant time together in
Switzerland, at the Randa. Thank for your help over there again!

I have been planning to write a longer summary email like this for a
while. Recently, I have also had a lot to do in the Gluon project and in my
personal life as well. I am really sorry for the delay.

We have tried to integrate quite a few kdevplatform features into the
GluonCreator (Game Designer IDE) in order to move towards greater cooperation.
We have fixed up a lot of bottlenecks in order to facilitate the collaboration.
My personal opinion is that, the event went really fine. In the following
paragraph I am trying to gather details we need yet in order to push our
IDE forward to a nice one built on the top of the kdevplatform project.

There are some missing features that we need to have implemented and available
in public before we could make the whole port. Afterwards, we could consider to
merge my relevant branch back to master after an "internal" Gluon discussion and
review session.

I know I seemed to be a bit wondering after hearing that non-UI features depend
on UI elements, but this is something I can easily accept and respect since we
are gonna gain more work getting done with the cooperation. It requires a bit of
UI change for our project since we need to drop the QDockWidget way in which we
organized our Layout. It is not a problem as far as the substitution from
kdevplatform can provide those features that we expected from the QDockWidget.
Before discussing the features we need to have in place, please try to consider
our IDE from a designer point of view, and not like an advanced hacker geek as
we are. I know it is not an easy task though. :)

1) Drag and drop
One of the basic requirements has been the ability for the drag and drop
operation. It seems to be implemented and pushed by this commit:
http://commits.kde.org/kdevplatform/4e204dc

2) Grouping
We can now have more QDockWidgets in the same row and column. If I am not
mistaken we could put only one tool view into one column at Randa. This is
something we really need. We have already discussed it can now be done by
aligning the layout properly inside one tool view, but the real solution is
without that implementation in my opinion. We could make it work for now like
that, but we do not have enough manpower, as it happens in other projects, thus
we are trying to concentrate on tasks that does not require rewriting later.
Here, you can find a picture about the GluonCreator how it now looks like:
http://gluon.gamingfreedom.org/node/63

3) Position of a tool view
I have not tested it that much either, but the tool view is basically displayed
in a deterministic position. It might be that we would like to move
the tool view
to "arbitrary" positions in our code base. I guess it is possible since kdevelop
places them onto the UI after the kdevelop executable launched.

4) VCS operation output
If I use VCS right away, like pull or/and push operation, an "own" output view
is displayed. We have our output view implementation inside the GluonCreator and
the principles how it works are a bit different according to the discussion at
Randa. Hence we need to be able to use our output view for VCS operation
outputs. It might be that we would just like to call some method which returns
the output text and we can manage it. Another potential way, from my novice
point of view, is to register our output view. This is something where I might
need some mentoring, how it can be done and where to look for. We somewhat
discussed this issue at Randa, but I did not get every bit properly yet. I am
not sure if it is already possible on the code-level because I did not have too
much time yet to look into the code base.

5) Area switcher
By default, we would like to disable the area switcher in the top right corner.
When you had a look at the screen shot aforementioned, you can see there is no
such an element there right now. We do currently not have Debug and other areas.

6) Ideal Layout
Very similar situation with the ideal layout as well. It would be nice if we can
turn them off by default. I think we have found some operation on the UI which
triggered this expectation. Hence I guess it is also possible from the
code base.

7) Returning KDialog or QWidget
KDevPlatform sometimes returns KDialog for a UI construction in a public code
which can be used by the API users. The issue is that with it, if we have an
embedded widget on the UI, because we would not like to have another Dialog in
our workflow, we cannot just re-use that component. We need to copy, paste and
duplicate the code. The situation is very similar to that when you would like to
use a UI in a pop-up menu. Because of these use cases, I think it is better to
return QWidget, or also providing such a method, and any user could embed that
into any UI solution that their work flow requires.

8) The branch interface
Aleix Pol did some improvement in this area during the sprint, but I did not
have too much time to take a look at it and integrate, but I guess it is getting
better. :)

9) Open / Import Project.
We are now using "Open Project" term only in our case. I have tried to eliminate
all the actions and irrelevant menu and tool bar items from the *ui.rc
files, but
this one seems to have remained over there. It is most likely my mistake and
lack of time. At any rate, the approach "Import" does not exist in our IDE. It
is not really a valid action right now. Hence why we started using the "Open
Project" text only.

10) Documentation about writing language support
We are now using QtScript opportunity in our implementation since it is shipped
by Qt and there is somewhat a good guarantee for its available in a Qt based
project like Gluon, accordingly. We implemented it for writing game
logic instead
of some native code. Also it is very common language from the web world. It is
even easier inside Gluon without the DOM and other things, it is simplified as
much as possible. Hence we need javascript language support, but this is
something which is not a blocking issue.
We could also contribute back to kdevplatform by working on it. What would
really help our job regarding this, if there was some good documentation which
goes through the general steps of writing a language support plugin. I think it
would be a nice addition of kdevplatform since Qt based projects tend to use
this scripting opportunity.

11) Session
The Gluon team decided that from the beginning, we do not support multiple
sessions in our Integrated Developer Environment. If the designer would like to
have multiple sessions, they need to approach it with multiple instances of the
application. I am not sure whether the issue is related to this, but we had an
interesting operation realized at Randa. After the first time (so second, third
and so forth), our project got opened automatically without our
project selection dialog. This issue went away when we deleted the
~/.kde4/share/config/kdeveloprc and ~/.kde4/share/apps/kdevelop/sessions/*
contents. This is also an issue that would be nice to get done as soon as
possible, otherwise it will bother the designers at step first by launching the
application.

I am planning to put these bits into some community page like
http://community.kde.org/Gluon/*, if it helps with book keeping. It
might be that
we can also discuss it further on at the Desktop Summit since there will be a
few of us there. It might also be interested for plasmate guys there, if any.

I may be missing something from the list, I wanted to write down, or I am just
plain wrong about things. My purpose is just that to know whether the
cooperation can go further on since it would be nice. It would be nice to know
the status of these feature requirements or whether they can be accomplished.
Are any of them against the design principles ?

I would like to know your opinion, any thoughts ? Thank you in advance and have
a nice day! =)

Best Regards,
Laszlo Papp