Does Maemo's Qt look like Hildon?

Hi

Although new-style Maemo 5 menus with sub-menus are discouraged, I don't
> think they should be forbidden. The current C API makes it very
> difficult to create them because HildonAppMenu is just a grid container,
> not a menu API. But I see no reason for Qt to make the same mistake.
>
> Of course they would not be displayed as a tree-like menu.


To be honest I don't know yet if we will have those menu in Qt too.
Currently I can't take other tasks, but if someone is interested in
implementing them, he/she is welcome and I'll happy to help him/her in that
job.

You are using a gmail email address. Do you actually work for Nokia
> and/or Qt?

Yes, I do. I'm a Nokia employee.

Best regards,
Antonio


>
> --
> murrayc@murrayc.com
> www.murrayc.com
> www.openismus.com
>
>


--

Laurence J. Peter<http://www.brainyquote.com/quotes/authors/l/laurence_j_peter.html>
- "Originality is the fine art of remembering what you hear but
forgetting
where you heard it."

On Mon, 2009-05-18 at 23:39 +0300, Antonio Aloisio wrote:
> Hi
>
> Although new-style Maemo 5 menus with sub-menus are
> discouraged, I don't
> think they should be forbidden. The current C API makes it
> very
> difficult to create them because HildonAppMenu is just a grid
> container,
> not a menu API. But I see no reason for Qt to make the same
> mistake.
>
> Of course they would not be displayed as a tree-like menu.
>
> To be honest I don't know yet if we will have those menu in Qt too.
> Currently I can't take other tasks, but if someone is interested in
> implementing them, he/she is welcome and I'll happy to help him/her in
> that job.

While we are on the subject of Qt looking like Maemo without API
changes, how are you dealing with the need for Maemo-specific API such
as that in HildonWindow:
http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html


I'm trying to get a general feel for how Qt can stick to its concept of
multiple platforms without API changes, though Mameo 5 seems to be the
first Qt platform with a significantly uncommon UI and API.


--
murrayc@murrayc.com
www.murrayc.com
www.openismus.com

On Mon, May 25, 2009 at 11:19 AM, Murray Cumming <murrayc@murrayc.com>wrote:

> On Mon, 2009-05-18 at 23:39 +0300, Antonio Aloisio wrote:
> > Hi
> >
> > Although new-style Maemo 5 menus with sub-menus are
> > discouraged, I don't
> > think they should be forbidden. The current C API makes it
> > very
> > difficult to create them because HildonAppMenu is just a grid
> > container,
> > not a menu API. But I see no reason for Qt to make the same
> > mistake.
> >
> > Of course they would not be displayed as a tree-like menu.
> >
> > To be honest I don't know yet if we will have those menu in Qt too.
> > Currently I can't take other tasks, but if someone is interested in
> > implementing them, he/she is welcome and I'll happy to help him/her in
> > that job.
>
> While we are on the subject of Qt looking like Maemo without API
> changes, how are you dealing with the need for Maemo-specific API such
> as that in HildonWindow:
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html


This trick is possible because Maemo applications have menus, toolbars as
any normal
desktop application. Okay they look different, but we can instruct Qt to
give them the looks that
we want...
The same thing happens for the other official supported Qt platforms (mac,
s60 ans so on)

I'm trying to get a general feel for how Qt can stick to its concept of
> multiple platforms without API changes, though Mameo 5 seems to be the
> first Qt platform with a significantly uncommon UI and API.

Actually that's not the fist one...

Best wishes,
Antonio


>
>
>
> --
> murrayc@murrayc.com
> www.murrayc.com
> www.openismus.com
>
>


--

Frank Lloyd Wright<http://www.brainyquote.com/quotes/authors/f/frank_lloyd_wright.html>
- "TV is chewing gum for the eyes."

On Mon, 2009-05-25 at 12:25 +0300, Antonio Aloisio wrote:

> While we are on the subject of Qt looking like Maemo without
> API
> changes, how are you dealing with the need for Maemo-specific
> API such
> as that in HildonWindow:
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html
>
> This trick is possible because Maemo applications have menus, toolbars
> as any normal
> desktop application. Okay they look different, but we can instruct Qt
> to give them the looks that
> we want...
> The same thing happens for the other official supported Qt platforms
> (mac, s60 ans so on)

Yes, I know that's the Qt philosphy, but repeating it doesn't answer my
question. For instance:

I guess, Qt windows can't usually have markup in their titles, so you'd
be changing the documented behaviour (therefore subtly changing the API)
if you parsed the regular title as markup, instead of offering separate
API:
http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-markup
(I think that the new API should be added to upstream GTK+ instead
anyway.)

I guess, Qt windows don't usually have a concept of "activated by the
window manager":
http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-get-is-topmost
(This is presumably something different than gtk_window_is_active():
http://library.gnome.org/devel/gtk/unstable/GtkWindow.html#gtk-window-is-active )

Also, I doubt that the Qt menu and toolbar API easily supports the idea
of one-single "edit" toolbar, introduced in Maemo 5:
http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-edit-toolbar

--
murrayc@murrayc.com
www.murrayc.com
www.openismus.com

The point is that we don't want to add new "concepts" to Qt if not strictly
necessary.
The idea I keep in my mind is "We are going to adapt Qt to hildon, not
rewriting hildon with Qt".
I hope that the other people understand this too. Then we need to discard
something...

If we want to add the features that you mentioned before, well most probably
we need to add new APIs...

BR,
Antonio

On Mon, May 25, 2009 at 12:58 PM, Murray Cumming <murrayc@murrayc.com>wrote:

> On Mon, 2009-05-25 at 12:25 +0300, Antonio Aloisio wrote:
>
> > While we are on the subject of Qt looking like Maemo without
> > API
> > changes, how are you dealing with the need for Maemo-specific
> > API such
> > as that in HildonWindow:
> > http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html
> >
> > This trick is possible because Maemo applications have menus, toolbars
> > as any normal
> > desktop application. Okay they look different, but we can instruct Qt
> > to give them the looks that
> > we want...
> > The same thing happens for the other official supported Qt platforms
> > (mac, s60 ans so on)
>
> Yes, I know that's the Qt philosphy, but repeating it doesn't answer my
> question. For instance:
>
> I guess, Qt windows can't usually have markup in their titles, so you'd
> be changing the documented behaviour (therefore subtly changing the API)
> if you parsed the regular title as markup, instead of offering separate
> API:
>
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-markup
> (I think that the new API should be added to upstream GTK+ instead
> anyway.)
>
> I guess, Qt windows don't usually have a concept of "activated by the
> window manager":
>
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-get-is-topmost
> (This is presumably something different than gtk_window_is_active():
>
> http://library.gnome.org/devel/gtk/unstable/GtkWindow.html#gtk-window-is-active)
>
> Also, I doubt that the Qt menu and toolbar API easily supports the idea
> of one-single "edit" toolbar, introduced in Maemo 5:
>
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-edit-toolbar
>
> --
> murrayc@murrayc.com
> www.murrayc.com
> www.openismus.com
>
>


--

Walt Disney <http://www.brainyquote.com/quotes/authors/w/walt_disney.html>
- "I love Mickey Mouse more than any woman I have ever known."

Murray Cumming wrote:
> On Mon, 2009-05-25 at 12:25 +0300, Antonio Aloisio wrote:
>
>> While we are on the subject of Qt looking like Maemo without
>> API
>> changes, how are you dealing with the need for Maemo-specific
>> API such
>> as that in HildonWindow:
>> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html
>>
>> This trick is possible because Maemo applications have menus, toolbars
>> as any normal
>> desktop application. Okay they look different, but we can instruct Qt
>> to give them the looks that
>> we want...
>> The same thing happens for the other official supported Qt platforms
>> (mac, s60 ans so on)
>
> Yes, I know that's the Qt philosphy, but repeating it doesn't answer my
> question. For instance:
>
> I guess, Qt windows can't usually have markup in their titles, so you'd
> be changing the documented behaviour (therefore subtly changing the API)
> if you parsed the regular title as markup, instead of offering separate
> API:
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-markup
> (I think that the new API should be added to upstream GTK+ instead
> anyway.)
>
> I guess, Qt windows don't usually have a concept of "activated by the
> window manager":
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-get-is-topmost
> (This is presumably something different than gtk_window_is_active():
> http://library.gnome.org/devel/gtk/unstable/GtkWindow.html#gtk-window-is-active )
>
> Also, I doubt that the Qt menu and toolbar API easily supports the idea
> of one-single "edit" toolbar, introduced in Maemo 5:
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-edit-toolbar

It seems to me that there are several areas where Hildon is extending Gtk + Qt
* new hildon-specific widgets (pannable, HildonWindow...
http://maemo.org/api_refs/5.0/beta/hildon/hildonobjects.html )
* integrating/extending existing widgets (text entry + virtual keyboard)
* visual style (thin scrollbars,radiobuttons...)
* system interaction (essentially dbus and WM comms via API calls like
can_hibernate, is_topmost)

Is the aim to map to these in Hildon Qt?

In which case it would be good to identify and prioritise targets and
achievements and it would also be nice to have reference information for IPC for
things like system interaction.

I also wonder about better handling for applications not written for Maemo;
should the core widgets be extended to handle Maemo at the system interaction
level and provide derived widgets to expose the API.

David

--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."

Hi David,

IMHO most of the extended hildon widgets could be dropped.
Hildon widgets like hildon banners instead need to be integrated inside Qt.
Extended widget could be shipped in an external library if necessary.. but I
won't care about them.
About IPC Qt classes for system interaction.. I working on them...

Cheers,
Antonio


On Mon, May 25, 2009 at 2:09 PM, David Greaves <david@dgreaves.com> wrote:

> Murray Cumming wrote:
> > On Mon, 2009-05-25 at 12:25 +0300, Antonio Aloisio wrote:
> >
> >> While we are on the subject of Qt looking like Maemo without
> >> API
> >> changes, how are you dealing with the need for Maemo-specific
> >> API such
> >> as that in HildonWindow:
> >> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html
> >>
> >> This trick is possible because Maemo applications have menus, toolbars
> >> as any normal
> >> desktop application. Okay they look different, but we can instruct Qt
> >> to give them the looks that
> >> we want...
> >> The same thing happens for the other official supported Qt platforms
> >> (mac, s60 ans so on)
> >
> > Yes, I know that's the Qt philosphy, but repeating it doesn't answer my
> > question. For instance:
> >
> > I guess, Qt windows can't usually have markup in their titles, so you'd
> > be changing the documented behaviour (therefore subtly changing the API)
> > if you parsed the regular title as markup, instead of offering separate
> > API:
> >
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-markup
> > (I think that the new API should be added to upstream GTK+ instead
> > anyway.)
> >
> > I guess, Qt windows don't usually have a concept of "activated by the
> > window manager":
> >
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-get-is-topmost
> > (This is presumably something different than gtk_window_is_active():
> >
> http://library.gnome.org/devel/gtk/unstable/GtkWindow.html#gtk-window-is-active)
> >
> > Also, I doubt that the Qt menu and toolbar API easily supports the idea
> > of one-single "edit" toolbar, introduced in Maemo 5:
> >
> http://maemo.org/api_refs/5.0/beta/hildon/HildonWindow.html#hildon-window-set-edit-toolbar
>
> It seems to me that there are several areas where Hildon is extending Gtk +
> Qt
> * new hildon-specific widgets (pannable, HildonWindow...
> http://maemo.org/api_refs/5.0/beta/hildon/hildonobjects.html )
> * integrating/extending existing widgets (text entry + virtual keyboard)
> * visual style (thin scrollbars,radiobuttons...)
> * system interaction (essentially dbus and WM comms via API calls like
> can_hibernate, is_topmost)
>
> Is the aim to map to these in Hildon Qt?
>
> In which case it would be good to identify and prioritise targets and
> achievements and it would also be nice to have reference information for
> IPC for
> things like system interaction.
>
> I also wonder about better handling for applications not written for Maemo;
> should the core widgets be extended to handle Maemo at the system
> interaction
> level and provide derived widgets to expose the API.
>
> David
>
> --
> "Don't worry, you'll be fine; I saw it work in a cartoon once..."
>



--

Samuel Goldwyn<http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html>
- "For your information, I would like to ask a question."

Antonio Aloisio wrote:
> Hi David,
>
> IMHO most of the extended hildon widgets could be dropped.
> Hildon widgets like hildon banners instead need to be integrated inside Qt.
Agreed - there are many Qt widgets which could simply be hildonised.
I wonder about session management and hibernation for example.

> Extended widget could be shipped in an external library if necessary..
> but I won't care about them.
Sadly the version 5 gallery includes lots of deprecated widgets and few (if any)
new ones:
http://maemo.org/api_refs/5.0/beta/hildon/ch02.html
Some make sense though and I'd like to see them up for community contribution?
Ideally there would be agreement on which and what API would be acceptable and
then refinement of implementation.

> About IPC Qt classes for system interaction.. I working on them...
Is this something that can be put up on the wiki?

What's planned (ever) and where we are?

David


--
"Don't worry, you'll be fine; I saw it work in a cartoon once..."

On Monday 25 May 2009 12:49:58 Antonio Aloisio wrote:
> The point is that we don't want to add new "concepts" to Qt if not strictly
> necessary.
> The idea I keep in my mind is "We are going to adapt Qt to hildon, not
> rewriting hildon with Qt".

A tiny caveat of which you're likely already aware of - if possible, consider
people who use Qt through bindings, like PyQt (myself included ;), Jambi,
Qyoto, etc. It would be a shame to write Qt code that would fall on it's face
or be unusable UI-wise just because of some specific changes the bindings are
not updated for.

Hi David

On Mon, May 25, 2009 at 5:00 PM, David Greaves <david@dgreaves.com> wrote:

> Antonio Aloisio wrote:
> > Hi David,
> >
> > IMHO most of the extended hildon widgets could be dropped.
> > Hildon widgets like hildon banners instead need to be integrated inside
> Qt.
> Agreed - there are many Qt widgets which could simply be hildonised.
> I wonder about session management and hibernation for example.


But I haven't wrote anything about the hibernation yet. But I had something
similar but not
related to the memory consumation. BTW in order to use that class ( and I
think the hibernation too)
the developer will use QSettings in a slot... but we'll talk more about
these asa this work will be published.


>
> > Extended widget could be shipped in an external library if necessary..
> > but I won't care about them.
> Sadly the version 5 gallery includes lots of deprecated widgets and few (if
> any)
> new ones:
> http://maemo.org/api_refs/5.0/beta/hildon/ch02.html
> Some make sense though and I'd like to see them up for community
> contribution?ven
> Ideally there would be agreement on which and what API would be acceptable
> and
> then refinement of implementation.

We can do a TODO list and then define what of the new widgets we want to
have in Qt.
But some of them will be available, I'm going to have a separate package for
them.
Those widgets as the Maemo system specific libs will be shipped in an extra
package.
I hope that you agree with this.

> About IPC Qt classes for system interaction.. I working on them...
> Is this something that can be put up on the wiki?
>
> What's planned (ever) and where we are?

I' haven't published them yet. They are in my internal repos... I can't tell
more for now..

Antonio


--

Mitch Hedberg<http://www.brainyquote.com/quotes/authors/m/mitch_hedberg.html>
- "My fake plants died because I did not pretend to water them."