'morning
On Tue, May 26, 2009 at 1:19 AM, Attila Csipa wrote:
> On Monday 25 May 2009 22:37:10 Antonio Aloisio wrote:
> > Hi Attila,
> > The python people is my mind too.. Don't worry I'm not forget about you
> > guys.
> > BTW please follow the ML so that you can help us in that side and you can
On Monday 25 May 2009 22:37:10 Antonio Aloisio wrote:
> Hi Attila,
> The python people is my mind too.. Don't worry I'm not forget about you
> guys.
> BTW please follow the ML so that you can help us in that side and you can
> sop
> us if needed...
Will do :) Apropo ML, I happen to notice qt4-de..
Hi Attila,
The python people is my mind too.. Don't worry I'm not forget about you
guys.
BTW please follow the ML so that you can help us in that side and you can
sop
us if needed...
Some new Qt libs will be added.. they will be extra libs and there are not
python bindings for them...
Regards,
An
Hi David
On Mon, May 25, 2009 at 5:00 PM, David Greaves 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 co
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
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
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 worki
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
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 fea
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/ap
On Mon, May 25, 2009 at 11:19 AM, Murray Cumming 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
> >
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
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 cou
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 subm
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
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 ar
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
What's the problem with F6?
On Mon, May 18, 2009 at 2:14 PM, Attila Csipa 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 ch
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
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
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 applic
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 k
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 inste
23 matches
Mail list logo
