Does Maemo's Qt look like Hildon?

I'm curious about something, yet too lazy to try it myself:

When creating menus with Qt in the Maemo 5 Beta SDK, using the normal Qt
APIs, such as QMenu
http://doc.trolltech.com/4.5/qmenu.html
do they look like Maemo 5 menus?
http://talk.maemo.org/showpost.php?p=283026&postcount=35

Or is it instead necessary to use some separate Hildon-specific API?

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

Hi,
currently they look like standars Diablo menus.
Those kind of menus are still in fremantle and we are going to use them to
keep the compatibility
with the Qt desktop applications.
Btw similar menus could be done by the application developers themselves

We haven't talked yet about having this kind of menu in Qt for fremantle.
BTW If we will plane to have them, it
will be possible without adding Hildon-specific API.

Best regards,
Antonio


On Fri, May 15, 2009 at 5:57 PM, Murray Cumming <murrayc@murrayc.com> wrote:

> I'm curious about something, yet too lazy to try it myself:
>
> When creating menus with Qt in the Maemo 5 Beta SDK, using the normal Qt
> APIs, such as QMenu
> http://doc.trolltech.com/4.5/qmenu.html
> do they look like Maemo 5 menus?
> http://talk.maemo.org/showpost.php?p=283026&postcount=35
>
> Or is it instead necessary to use some separate Hildon-specific API?
>
> --
> 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 Fri, 2009-05-15 at 18:31 +0300, Antonio Aloisio wrote:
> Hi,
> currently they look like standars Diablo menus.
> Those kind of menus are still in fremantle and we are going to use
> them to keep the compatibility
> with the Qt desktop applications.
> Btw similar menus could be done by the application developers
> themselves
>
> We haven't talked yet about having this kind of menu in Qt for
> fremantle. BTW If we will plane to have them, it
> will be possible without adding Hildon-specific API.

I don't see how both aims are possible at the same time with the same
API.

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

Hi,
An option is putting non sub-menus QActions in the QMenuBar.
In that way the developer don't have to use maemo specific APIs.

Then Qt can
1. fetches the actions from the QMenuBar
2. checks if those QActions are not a submenus
3. Creates a Dialog with buttons with those QActions
4. Connects the dialog:show() to the title bar

BTW that's not implemented yet...

BR,
Antonio

On Sat, May 16, 2009 at 11:35 AM, Murray Cumming <murrayc@murrayc.com>wrote:

> On Fri, 2009-05-15 at 18:31 +0300, Antonio Aloisio wrote:
> > Hi,
> > currently they look like standars Diablo menus.
> > Those kind of menus are still in fremantle and we are going to use
> > them to keep the compatibility
> > with the Qt desktop applications.
> > Btw similar menus could be done by the application developers
> > themselves
> >
> > We haven't talked yet about having this kind of menu in Qt for
> > fremantle. BTW If we will plane to have them, it
> > will be possible without adding Hildon-specific API.
>
> I don't see how both aims are possible at the same time with the same
> API.
>
> --
> murrayc@murrayc.com
> www.murrayc.com
> www.openismus.com
>
>


--

Bill Cosby <http://www.brainyquote.com/quotes/authors/b/bill_cosby.html> -
"Fatherhood is pretending the present you love most is soap-on-a-rope."

On Monday 18 May 2009 11:52:45 Antonio Aloisio wrote:
> An option is putting non sub-menus QActions in the QMenuBar.
> In that way the developer don't have to use maemo specific APIs.

Whatever the final choice, just PLEASE don't do it by breaking Qt
defaults/behavior, like the fullscreen QAction thingy :(

What's the problem with F6?

On Mon, May 18, 2009 at 2:14 PM, Attila Csipa <maemo@csipa.in.rs> wrote:

> On Monday 18 May 2009 11:52:45 Antonio Aloisio wrote:
> > An option is putting non sub-menus QActions in the QMenuBar.
> > In that way the developer don't have to use maemo specific APIs.
>
> Whatever the final choice, just PLEASE don't do it by breaking Qt
> defaults/behavior, like the fullscreen QAction thingy :(
>
>



--

P. J. O'Rourke<http://www.brainyquote.com/quotes/authors/p/p_j_orourke.html>
- "Never fight an inanimate object."

On Monday 18 May 2009 13:18:35 Antonio Aloisio wrote:
> What's the problem with F6?

Correct me if I'm wrong, but Qt (in general) does not have a default QAction
for 'full screen'. This means that any app that tries to implement
full-screen switching via QAction (and that full-screen switch isn't just a
setWindowState) is broken and needs to be worked around specifically for
Maemo.

I appreciate the default handler(s) for maemo-only applications, but with Qt,
I'd much rather see the app act the same way on all platforms.

Hi Attila


Correct me if I'm wrong, but Qt (in general) does not have a default QAction
> for 'full screen'.

Exactly

This means that any app that tries to implement
> full-screen switching via QAction (and that full-screen switch isn't just a
> setWindowState) is broken and needs to be worked around specifically for
> Maemo.

It's correct.The point is, How many applications need to implement a own
full-creen switching
QAction?
When we started to work on this port, we did some decisions. One of them was
using a QMainWindow
QAction to bind F6.

If some developers want to add an his own full-screen switching, them just
need to remove the QMainWindow
QAction that F6 as shortcut and add a new one.

BR
Antonio





>
> I appreciate the default handler(s) for maemo-only applications, but with
> Qt,
> I'd much rather see the app act the same way on all platforms.
>



--

Casey Stengel<http://www.brainyquote.com/quotes/authors/c/casey_stengel.html>
- "There comes a time in every man's life, and I've had plenty of
them."

On Monday 18 May 2009 14:49:46 you wrote:
> If some developers want to add an his own full-screen switching, them just
> need to remove the QMainWindow
> QAction that F6 as shortcut and add a new one.

While understand the motivation, as someone who uses Qt on 2+ platforms I
respectfully disagree with the choice/conclusion. Qt goes to great lengths to
make itself behave the same way on all platforms, and this goes against that.
IMHO one should be ENABLING additional functionality and not REWORKING
existing code just get back the functionality one already had on other
platforms. Add a -maemo command line switch (like -graphicssystem) or make it
an #include, but don't change the default.

>The point is, How many applications need to implement a own
>full-creen switching QAction?

This has come up time and again on the garage forum, so I guess it's not
exactly a white crow. I ran across this problem as my own pyqtoreader pet
project suffered from full-screen issues on Maemo.

Also, it's not only about full-screen. It also limits configurability of
shortcuts - if your application does not have non-fullscreen operation (like
games), again, you'll have to work around to be able to make use of that
button.

On Mon, 2009-05-18 at 12:52 +0300, Antonio Aloisio wrote:
> Hi,
> An option is putting non sub-menus QActions in the QMenuBar.
> In that way the developer don't have to use maemo specific APIs.
>
> Then Qt can
> 1. fetches the actions from the QMenuBar
> 2. checks if those QActions are not a submenus
> 3. Creates a Dialog with buttons with those QActions
> 4. Connects the dialog:show() to the title bar

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.

> BTW that's not implemented yet...

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

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