22
Mar
I think for about 6 months now I have been toying with a KJSEmbed IDE and failing at most turns...
I'm still not convinced this [image:203,middle] although now I have more Javascript language support [image:386,middle]. It still falls short of my expectations. From what I see there are two modes that people will use KJSEmbed 1) as a macro language for KDE apps and 2) as a "visual lets get something out in the next 2 hours" language. From what I see here KDevelop is just not going towards either direction.
This leaves me with my current dilemma, where to go from here. I have no mood to rewrite or fork Qt Designer to make a visual KJSEmbed IDE, and likewise, I have no energy to write the ECMA Parser needed to do code completion. The joys of a randomly typed language :)
Ideas from the peanut gallery?
- geiseri's blog
- Login or register to post comments
- 859 reads
Syndicate Blogs
Comments
Oddly enough...
Oddly enough I was talking to the kexi guys about this last night. They've already got a form designer we could use here...
yeah i looked at that...
...but do we really want to maintain our own UI editor in KDE? Plus, im not sure i want to sentence us to a rewrite every few weeks. Maby if they where more mature developers with a grand vision we could stomach it... but im honestly scared of any colaberation with that crew.
there is also the fact that they ignore the standard Qt widgets and have all their own plugins. now i dont have a problem with people who just like to write code, but ill have no part in it. If we wanted to go that route lets just resurect the KDevelop UI designer, at least trolltech can read that file format.
there is a reason for not reuusing everything
KFormDesigner is more than a simple qt designer ripoff. qt made quite a lot of design mistakes while inventing qt designer. KFormDesigner in contrary learned from these errors and has a list of imporvemnets:
- You can use _any_ abitrary QWidget as base widget (this is supported in view and design mode)
- If you look in libqui and qt designer's code you'll see that there are a lot of hardcoded widgets in it. they check if a widget inherits e.g. QTabWidget if it does the beheiver is like that and that... however our counterpart does not have any single hardcoded Widget in it's library
- Designers code is really bad (at least to read) appart from the above mentioned issue
- KFormDesigner has inline editing: if you e.g. insert a QLabel and double click on it you can _directly_ change the text of this label sure any other action can bound (by the factories!) to widgets
here again in qt designer so far as i know (i've quite forgotten that code since i left the form issue quite long alone for the phase of framework chaning) qt designer has the actions hardcoded
and as jaroslaw already mentioned
- KFormDesigner produces and reads UI 3 format natively
- KFormDesigner is LGPL
- KFormDesigner is KPart enabled
- KFormDesigner can provides actions for it's widget library
and what do you mean with "rewrite every few weeks" we had exactly one rewrite that was after we realized that our database framework is not nice enough. we took the opportunity to get away from koffice libs so it's quite naturally that the core changes a lot...
Looks like Ian has not follow
Looks like Ian has not followed who, why and how is working within Kexi Project. Few months ago many parts of Kexi were rewritten and it's not longer 'just for fun' project. REWRITTEN instead of reinventing the wheel with starting another project (many thanks to Lucijan for being so patient :) ).
Chances are that Ian has not seen Kexi Wiki documentation (offline today). If so, I can say he can learn that:
- Kexi is not document/file driven, but structured-database-driven, so that's why KParts were not usable for everything (but embedding documents for BLOB-type fields is really usefull feature). AFAIK KParts were designed with having all these menu items merging, and so on (angain: document driven approach) while Kexi has developed many types of plugin APIs that trying to ensure _everyone_ 3rd party plugin will behave reasonably, and will allow better plugin introspection. Note: I can agree that having KexiPart class can lead to misunderstanding that we're replacing KParts... What we may need is to simply rename to e.g. KexiPlugin.
- Kexi have VIEWS with MODES (eg. data/design/sql mode) inside KMDI with Shared actions. This had no framework within kdelibs yet. It's worth discussion IF there will be any project that want to reuse this, although, shared actions act like an extension for current KAction impl.
- Kexi is KDE app, not Qt-only app, as well as KParts are not for Qt apps. I've Invested money and time to ensure this development method also works for win32 target. So: depending/waiting on what TT would introduce to the market with QtDesigner (with all my respect for them), is not so bright idea for us
- Yes, we ignore not so usable, in our case, widgets like e.g. QTable. We've KexiTableView (with db-aware option) instead. It is ignored by TT, as well, that their QTable has a bit outdated implementation. Other examples: we're using Kate editor component where needed, dropping simple QTextEdit. So: what more good Qt widgets are we ignoring, i've no idea though.
- We're constantly reusing/sharing more and more common components with KDevelop/Kate: KMDI, that in the meantime came to kdelibs, and Javascript GUI that is pretty impressive for me right now.
- Having KDE-compatible UI editor, that is recently developed for Kexi by Cedric Pasteur, is not for reinventing QtDesigner, because it will be for application scripting, not regular development.
- Adding another TT app replacement is nothing new, I suppose - KBabel is a good example of QtLinguist replacement, as well as KDevelop's doc viewer vc QtAssistant (I plan to support the former on every platform).
Sorry for few offtopic sentences.
--
Jaroslaw Staniek
Kexi Team
Interest in lots of areas
I have not been following as closely as I'd like due to being busy. However there is even more interest in this for purposes of synergy. I'm wanting to look into the Kexi tool more because it appears to have a lot of interchangability with Kommander. I also may have more developer time going into Kommander soon and have at least one person interested in making it into a quick application tool too. All in all it appears that KJSEmbed, Kexi and Kommander have some common interests and should explore where we could help each other out. I'm very interested in all of this and creating these types of tools. At the very least I really think we need to insure that we communicate so that if they are divergent they can at least interoperate as much as possible. I'm going to post on the main blog because I think Quanta has some common interests too with the Javascript part.