KDE Version

[DeKay]

I've tried arora and it looks very promising. I was wondering about
the feasibility of a port of the project where there a KDE version and
a pure Qt version, perhaps something like Marble??? So..
- Is this feasible?
- What would be the right way to do this? In tree? A totally
separate fork?
- Would it be encouraged by the arora developers?

I'm aware that there is the Foxkit project, but it has been quiet for
a number of months. I also don't know if they were working together
with you guys or not.

Thanks in advance!

[Benjamin Meyer]

yah I think it would be a good thing for Arora to get better
integration with KDE. Some initial items that I have come up with so
far are really fixes to Oxygen.

- Oxygen needs to overload standardIconImplementation and return the
KDE icons for the back/forward/stop/reload and other icons so Arora
will get them rather then the standard ones oxygen is giving today.
- Oxygen needs to add support several new QTabBar style hints that
were added in 4.5
http://labs.trolltech.com/blogs/2008/07/02/some-qtabbar-qtabwidget-love/
- Hmm I thought I had a third .... Does oxygen have rendering issues
in webkit?

What other ideas do other people have?

-Benjamin Meyer

[Benjamin Meyer]

- Use the new proxy stuff in 4.5 which in theory will pickup KDE's
proxy setting in the future.
- Don't use activate in the bookmark manager/cookie manager (Need to
test in kde)

-Benjamin Meyer

[Benjamin Meyer]

I have started a wiki page on this topic

http://code.google.com/p/arora/wiki/KDE4Integration

-Benjamin Meyer

[Paweł]

> What other ideas do other people have?
>
> -Benjamin Meyer

First thing that comes to my mind (besides previously mentioned) are:
- toolbar dots/handles, KDE apps have "Lock/Unlock Toolbars" option in context menu (to hide/show them), along with stuff like text position, orientation and icon size.
- hide/show menu option (it seems that every KDE app has "settings->show/hide menu" option)
- KDE icons in menus
- oxygen styled buttons and text fields are rendered incorrecly (e.g. on the http://code.google.com/p/arora/ in the right upper corner: text field is so small that it bearly fits the text and text on button is bigger than button), AFAIK Konqueror has the same problem with webkitpart, but not with khtml.
- native open/save dialog (qt creator uses, I wonder how do they do it)

[DeKay]

> What other ideas do other people have?
>

Thanks for this. But I guess I was thinking more along the lines of a
parallel effort to Arora that replaced the Q* classes with K*
classes. I take it that anything along this line would be preferred
kept as a totally separate outside project, like Foxkit???

[Benjamin Meyer]

On Feb 17, 2009, at 5:31 PM, Paweł wrote:

>> What other ideas do other people have?
>>
>> -Benjamin Meyer
>
>
> First thing that comes to my mind (besides previously mentioned) are:
> - toolbar dots/handles, KDE apps have "Lock/Unlock Toolbars" option in
> context menu (to hide/show them), along with stuff like text position,
> orientation and icon size.

> - KDE icons in menus

I have added this to the wiki

> - hide/show menu option (it seems that every KDE app has
> "settings->show/hide menu" option)

We have it to, just in View -> Show/Hide Menu

The others were Oxygen issues which are already on the wiki.

-Benjamin Meyer

[Benjamin Meyer]

On Feb 17, 2009, at 8:54 PM, DeKay wrote

Well a Q->K replacement is easy. Anyone can do that (and several
already have.. and stopped there), but that doesn't solve any of the
issues that are listed on the wiki (http://code.google.com/p/arora/wiki/KDE4Integration
). Oxygen still has bugs with QtWebKit and QLineEdit and QTabBar and
with giving KDE icons. Integrating with KDE isn't primarily about
replacing one class with another, that is only one very tiny part of
it. Integrating with KDE is making Arora utilize KDE's resources.

I have stayed away from the Q->K topic, but I figure it is time to
dive into that a bit for the record. For those who have not seen it
checkout the project goals wiki page which was created at the start of
the project: http://code.google.com/p/arora/wiki/Goals. One of the
sections is Non-Goals and contains the following:

"The following consider out of scope for the project

Single Desktop Browser
Arora will not strive to become a KDE browser or only a Windows
browser. Specifically on Linux Arora should fit just as well in Gnome
as it does with KDE. Rather then calling it a Linux browser perhaps it
should be called a FreeDesktop?.org Browser. Specific features to
integrate with KDE, Gnome, OS X, or Windows should be built as
extensions whenever possible."

It sounds more harsh then it is. Arora should strive to integrate
with each desktop environment. Arora *must* be able to build and be
distributed stand alone on Windows and OS X. Arora must be able to
integrate with KDE and Gnome using the same binary. I do not think
that this is to much to ask. Switching QMessageBox to KMessageBox
wont integrate Arora into KDE (I believe they will look the same), but
fixing Oxygen to return the KDE stop/reload icons will.

Switching Q->K in master will require every developer of Arora to have
a new dependancy of kdelibs (and kdebase?). This is no small
dependancy and will force those developers to build KDE. Worst of all
it will be a moving target for at least another year. You can develop
Arora today with just the stable Qt 4.4, 4.5 is nicer, but not required.

Ok, so that is the worst case scenario. A change like this would have
to be done in a branch to determine the issues and benefits. One
possible solution might be to have a kde.h that redefines all of the
useful classes and is only enabled on Linux. Details like how to
build on Windows and OS X, will Gnome integration still work? will it
build on QtEmbedded (we have users there)? How would we package kde*
with Arora for an Arora.app bundle on OS X? We want/need Qt 4.5 the
day it is released, will be be tied to KDE 4.2 and Qt 4.4? And many
other questions that I don't have the answers to.

Arora is somewhat like Amarok, an application that isn't in one of
application in the KDEfoo svn repositories and has its own release
schedule. But honestly I think the Q->K is simply the easiest thing
to do which is why a lot of people bring it up, but it gives the least
bang for the buck . The actual work that needs to be done is what is
on the wiki page. When those are fixed users will be happy, no doubt
about it. I am not saying Arora should not change Q->K, just that it
wont happen until it is shown that it doesn't conflict with the goals
of the project. A branch on github to play around with it that can be
tested on all platforms is a fine way to move forward with the
transition. While that is going on we should look to solve the issues
listed on the wiki page. They will benefit Arora whether we use Q
classes or K classes and make the KDE users more happy with Arora.

-Benjamin Meyer

[Paweł Prażak]

> > First thing that comes to my mind (besides previously mentioned) are:
> > - toolbar dots/handles, KDE apps have "Lock/Unlock Toolbars" option in
> > context menu (to hide/show them), along with stuff like text position,
> > orientation and icon size.
> > - KDE icons in menus
>
> I have added this to the wiki

Thank you :)

> > - hide/show menu option (it seems that every KDE app has
> > "settings->show/hide menu" option)
>
> We have it to, just in View -> Show/Hide Menu
>

Hmm, I don't know why but I don't have this option. I have only: hide
[toolbar/bookmarks bar/tab bar/status bar]
My version is: 0.4 (509 a1a32f5) pulled today form git, compiled with
Qt 4.5-rc1

--
Paweł

[Paweł Prażak]

> > > - hide/show menu option (it seems that every KDE app has
> > > "settings->show/hide menu" option)
>
> > We have it to, just in View -> Show/Hide Menu
>
> Hmm, I don't know why but I don't have this option. I have only: hide
> [toolbar/bookmarks bar/tab bar/status bar]
> My version is: 0.4 (509 a1a32f5) pulled today form git, compiled with
> Qt 4.5-rc1

but i've just checked Ctrl+M and it works fine :)

[DeKay]

This answers my question completely. Thanks!

[Benjamin]

Woops, yah sorry about that. I ended up only adding the shortcut and
not the action. The logic being that if you turn off the menu the
only way to get it back was with the shortcut so you needed to know
the shortcut. If there was something in the menu you could
accidentally click on it without knowing the shortcut.

-Benjamin Meyer

[Leo]

One cool thing to think about would be the integration of runners into
the location bar (Awesome Bar like functionality) and the search bar
(though it my be better to support the OpenSearch standard, maybe
both?).

[ssound...@gmail.com]

I understand Arora wanting to fit in well with KDE, but I sincerely
hope it isn't going to become a KDE app (that is, requiring any KDE
lib or service, which are generally gigantic dependencies). I think
it's a shame that there are so few non-KDE QT apps.

[Paweł Prażak]

May be I'm wrong, but if you're running KDE, kdelibs are alredy in memory (some of them at least), so you reuse code and load time is shorter. But if you don't run KDE, you don't need KDE version of arora, so AFIAK this is good way to integrate Arora with KDE.

[cyrusxiii]

I've been an enthusiastic KDE user for many years and while I wouldn't
mind better integration of Arora into that desktop environment, I find
myself against a Q -> K switch. As it stands now, we got a promising
little Qt/WebKit-based browser with functional builds available for
all major operating systems and from what I read elsewhere, it even
integrates fairly well with GNOME, which isn't something Qt apps are
particularly known for - great stuff.

It would be a shame if Arora proper (that is, the fully cross-platform
version) would lose momentum due to fragmentation of code and/or
efforts, so ideally, anything that interacts with higher functions of
a respective desktop environment (e.g. KRunner, KWallet, similar stuff
on GNOME) ought to be implemented in a fashion that it remains
optional/separable from the core codebase, so that BSD/Linux
distributions could then package this as arora-kde and arora-gnome
respectively.

-Cyrus

[Paweł Prażak]

This is more or less our plan. I'm not entirely sure how we'll do it
exactly, but for now there is Arora's KDE fork called Surfboard, it
has it's own separate build system (KDE specific cmake) and all
modifications are made in transparent way, from Arora's point of view
(conditional preprocessor directives and new separate frontend files).
So (in theory) you can pull surfboard's git repo and compile plain
Arora just by using qmake instead of cmake. It's just new optional KDE
flavor of Arora and as for now it's called Arora Surfboard to not to
confuse it with Arora.
As Benjamin already pointed out, making Arora a platform specific
browser is not an option (because it's not Arora's goal) and IMO it's
very good, so the idea is to make a browser that integrates with KDE
desktop very well and sort of inherites (or extends) Arora.

[Alexandre Bique]

On Wed, Mar 25, 2009 at 2:45 PM, Paweł Prażak <kojo...@gmail.com> wrote:
> This is more or less our plan. I'm not entirely sure how we'll do it
> exactly, but for now there is Arora's KDE fork called Surfboard, it
> has it's own separate build system (KDE specific cmake) and all
> modifications are made in transparent way, from Arora's point of view
> (conditional preprocessor directives and new separate frontend files).
> So (in theory) you can pull surfboard's git repo and compile plain
> Arora just by using qmake instead of cmake. It's just new optional KDE
> flavor of Arora and as for now it's called Arora Surfboard to not to
> confuse it with Arora.

I don't think that you need to fork Arora, you can do integration by:
- making abstract classes
- creating a plugin which provide the functionality
- use the right plugin

For exemple for the security device you can do AbstractSecurityDevice,
DefaultSecurityDevice, KWalletSecurityDevice, ... and load the right
one during startup.

For the shortcut, AbstractShortcutManager, DefaultShortcutManager,
KShortcutManager, ...
For the bookmark provider, ...

And do you really need cmake ? There is `kde4-config --path include',
... which is what you need to configure it with qmake.

> As Benjamin already pointed out, making Arora a platform specific
> browser is not an option (because it's not Arora's goal) and IMO it's
> very good, so the idea is to make a browser that integrates with KDE
> desktop very well and sort of inherites (or extends) Arora.

Arora can be integrated to a platform without being platform specific.
Use abstraction.

--
Alexandre Bique

[Paweł Prażak]

> I don't think that you need to fork Arora, you can do integration by:
>  - making abstract classes
>  - creating a plugin which provide the functionality
>  - use the right plugin
>
> For exemple for the security device you can do AbstractSecurityDevice,
> DefaultSecurityDevice, KWalletSecurityDevice, ... and load the right
> one during startup.
>
> For the shortcut, AbstractShortcutManager, DefaultShortcutManager,
> KShortcutManager, ...
> For the bookmark provider, ...

I'm with you on this and I hope we will be able to find the right
balance and add some layers of abstraction where they are needed. But
I'm afraid that to get the KDE look'n'feel frontend will need to be
forked. The idea is to make it "KDE way", for e.g. first thing is to
change base class of BrowserMainWondow from QApplication to
KXmlGuiWindow it changes how this class behave and there are going to
be a lots of changes in this class and in classes that it's composed
of.

There is another thing with your approach. If you want to choose
between different versions of class on runtime it would almost
certainly require everyone to have kdelibs, right? And it would be
wrong and we don't want this to happen. Also I think there would be an
additional overhead and code bloat. So I'm for making this decision
compile-time.

I'd really like to make as small changes to Arora as possible for
couple of reasons, but on the other hand I'd love to make it an KDE
app, so it's not an easy task find the right balance and your input is
helpful.

> And do you really need cmake ? There is `kde4-config --path include',
> ... which is what you need to configure it with qmake.

Yes. And it's already done. Correct me if I'm wrong, but cmake is
easier to setup for KDE development than qmake, but IMHO the biggest
advantage of havening separate build system is that it's easier to
compile it with different versions of various classes. If there is an
easy way to do it using only qmake please let me know.

> > As Benjamin already pointed out, making Arora a platform specific
> > browser is not an option (because it's not Arora's goal) and IMO it's
> > very good, so the idea is to make a browser that integrates with KDE
> > desktop very well and sort of inherites (or extends) Arora.
>
> Arora can be integrated to a platform without being platform specific.
> Use abstraction.

Yes abstraction is good and thats basically what I meant by "extending/
inheriting Arora", but it's not always easy. I'm not an expert, but
how do I abstract when I need to change base class?

Please remember that for now we're evaluating different possibilities,
playing with code and looking for possible traps and pitfalls. If
there is someone who have experience with kdelibs and KDE programming
it would very helpful if you could give us some clues and suggestions,
especially that some parts of KDE4 are documented partially or not at
all yet.

So as for now please consider it as an experiment and any suggestions
are very welcome :)

[Paweł Prażak]

> change base class of BrowserMainWondow from QApplication to
> KXmlGuiWindow

Sorry, what I meant was:

"...change base class of SingleApplication form QApplication to
KApplication and BrowserMainWondow from QMainWindow to
KXmlGuiWindow..."

[Alexandre Bique]

No, you build plugins. They go in $prefix/lib/arora/. At startup you
can load them and use them. So if you don't want KDE, you may not
build the kde plugin. And at startup you just load the plugins you
want. You can detect the current environment and choose the right one
or rely on the user preferences.

> I'd really like to make as small changes to Arora as possible for
> couple of reasons, but on the other hand I'd love to make it an KDE
> app, so it's not an easy task find the right balance and your input is
> helpful.
>
>> And do you really need cmake ? There is `kde4-config --path include',
>> ... which is what you need to configure it with qmake.
>
> Yes. And it's already done. Correct me if I'm wrong, but cmake is
> easier to setup for KDE development than qmake, but IMHO the biggest
> advantage of havening separate build system is that it's easier to
> compile it with different versions of various classes. If there is an
> easy way to do it using only qmake please let me know.

With two build system, you do two times the same thing. If the first
one work, why do another ?

>> > As Benjamin already pointed out, making Arora a platform specific
>> > browser is not an option (because it's not Arora's goal) and IMO it's
>> > very good, so the idea is to make a browser that integrates with KDE
>> > desktop very well and sort of inherites (or extends) Arora.
>>
>> Arora can be integrated to a platform without being platform specific.
>> Use abstraction.
>
> Yes abstraction is good and thats basically what I meant by "extending/
> inheriting Arora", but it's not always easy. I'm not an expert, but
> how do I abstract when I need to change base class?

template <typename A>
class B : public A {};

KApplication is a QApplication right ? So for the static type, use
QApplication * myApp = createApp(); // dynamic type can be B<KApplication>

Here createApp() can load a plugin with the desired [KQ]Application base classe.

> Please remember that for now we're evaluating different possibilities,
> playing with code and looking for possible traps and pitfalls. If
> there is someone who have experience with kdelibs and KDE programming
> it would very helpful if you could give us some clues and suggestions,
> especially that some parts of KDE4 are documented partially or not at
> all yet.
>
> So as for now please consider it as an experiment and any suggestions
> are very welcome :)

PS: Please Benjamin, can you remove the google's footer ?

--
Alexandre Bique

[Paweł Prażak]

Thank you Alexandre, this was insightful.

> No, you build plugins. They go in $prefix/lib/arora/. At startup you
> can load them and use them. So if you don't want KDE, you may not
> build the kde plugin. And at startup you just load the plugins you
> want. You can detect the current environment and choose the right one
> or rely on the user preferences.

To be honest that was my first idea but I didn't knew how to do it.
I'll certainly look into it and learn how to do it right. Thank you.

> With two build system, you do two times the same thing. If the first
> one work, why do another ?

Hmm, you're probably right. I don't have preferences in this case, I
can use qmake or cmake as long as this gets out of the way if you know
what I mean. CMake build system was setup by DeKay and I used it,
because I didn't want to do it myself ;) It's KDE's build system so I
think its easier to use it, but I'm sure you can use qmake as well,
I'm just not sure if it's straightforward.

> > I'm not an expert, but how do I abstract when I need to change base class?
>
> template <typename A>
> class B : public A {};
>
> KApplication is a QApplication right ? So for the static type, use
> QApplication * myApp = createApp(); // dynamic type can be B<KApplication>
>
> Here createApp() can load a plugin with the desired [KQ]Application base classe.
>

Yes templates are good idea, but there is only one problem. Q_OBJECT
don't like templates...
When you try to compile something like this:

template<class T>
class SingleApplication : public T
{
Q_OBJECT

it fails with singleapplication.h:46: Error: Template classes not
supported by Q_OBJECT

So what do I do now?

[Benjamin Meyer]

>
> PS: Please Benjamin, can you remove the google's footer ?
>
> --
> Alexandre Bique

Done

-Benjamin Meyer

[Alexandre Bique]

On Wed, Mar 25, 2009 at 5:16 PM, Paweł Prażak <kojo...@gmail.com> wrote:
> Yes templates are good idea, but there is only one problem. Q_OBJECT
> don't like templates...
> When you try to compile something like this:
>
> template<class T>
> class SingleApplication : public T
> {
>    Q_OBJECT
>
> it fails with singleapplication.h:46: Error: Template classes not
> supported by Q_OBJECT
>
> So what do I do now?

You can try:

class AroraApp : public QObject // you don't change the base class
{
private:
QApplication * app_; // dynamic type can be KApplication *
};

But if you want to change every Q* to K*, you may use defines:

// choose the one you want
#define API Q
#define API K

#define AApplication API##Application
#define APushButton API##PushButton
...

It should work. And i think that's what you did. But you will get
karora, not arora ^^.

I don't know what is the best think to do... :'(

--
Alexandre Bique

[Paweł Prażak]

This is the cleanest thing I could think of (yes I know, it's
ugly ;) )

h:

#ifdef SURFBOARD
#include <kapplication.h>
#define QApplication KApplication
#else
#include <qapplication.h>
#endif

cpp:

#ifdef SURFBOARD
SingleApplication::SingleApplication(int&, char**)
: KApplication()
#else
SingleApplication::SingleApplication(int &argc, char **argv)
: QApplication(argc, argv)
#endif

because KApplication have different constructor :|

On Mar 25, 6:57 pm, Alexandre Bique <bique.alexan...@gmail.com> wrote:

[Alexandre Bique]

On Wed, Mar 25, 2009 at 6:33 PM, Paweł Prażak <kojo...@gmail.com> wrote:
>
> This is the cleanest thing I could think of (yes I know, it's
> ugly ;) )
>
> h:
>
> #ifdef SURFBOARD
> #include <kapplication.h>
> #define QApplication KApplication
> #else
> #include <qapplication.h>
> #endif
>
> cpp:
>
> #ifdef SURFBOARD
> SingleApplication::SingleApplication(int&, char**)
>    : KApplication()
> #else
> SingleApplication::SingleApplication(int &argc, char **argv)
>    : QApplication(argc, argv)
> #endif
>
> because KApplication have different constructor :|

But how far does it improve arora to be karora ?
Where is your repository, i wanna try your version.

--
Alexandre Bique

[Paweł Prażak]

http://github.com/pawelprazak/surfboard/tree/master

g...@github.com:pawelprazak/surfboard.git

As for now there is only KXmlGuiWindow, KApplication, and some basic stuff and a lots of things are broken, so don't expect much. ;)

I just started to play around with KActions and xml file for layout, but unfortunately it's not documented mostly.

[Alexandre Bique]

On Wed, Mar 25, 2009 at 7:37 PM, Paweł Prażak <kojo...@gmail.com> wrote:
> http://github.com/pawelprazak/surfboard/tree/master
>
> g...@github.com:pawelprazak/surfboard.git
>
> As for now there is only KXmlGuiWindow, KApplication, and some basic stuff
> and a lots of things are broken, so don't expect much. ;)
>
> I just started to play around with KActions and xml file for layout, but
> unfortunately it's not documented mostly.

I don't know, I think that it's too much pain ;-) Have you got a look
at rekonq ?

--
Alexandre Bique

[DeKay]

This kind of thing doesn't work. You get into trouble quickly. e.g.

kmenu.addAction(*kaction) won't compile
kmenu.addAction(*qaction) will.

Hence the approach to trying to do things "the KDE way"

On Mar 25, 11:57 am, Alexandre Bique <bique.alexan...@gmail.com>
wrote:

[Paweł Prażak]

I've checked rekonq and it looks quite promising. And the more I play
with the idea of KArora the more I become questioning the sens of this
kind of project. It's a bit like trying to turn Arora into something
that was never planned to be. I'm beginning to wonder if modifying
Arora could become more difficult than writing demo-based KDE browser
from scratch.

[DeKay]

I hadn't heard of rekonq but checked it out last night. It looks
pretty interesting. This guy seems to have already done many of the
things I was thinking of doing. I see Pawel has cloned it as well.

On Mar 25, 3:55 pm, Alexandre Bique <bique.alexan...@gmail.com> wrote: