Re: [Development] Qt Platform Extras
Most of the functionality was already in Qt 4 and was moved out for Qt 5 because of maintenance issues and different code for different platforms exposed to the customer. On 02/09/2013 10:35 PM, Sorvig Morten wrote: > I agree the "Extra" looks superfluous. In fact I'd like to go a bit further > and suggest we don't have platform extras at all and instead integrate the > functionality into Qt: > > - Conversion functions for types in QtCore to QtCore > - Conversion functions for types in QtGui to QtGui > - Widgets to QtWidgets > - Non-trivial implementation to the platform plugin > - etc. > > I've prepared a set of patches showing how (for parts of QtMacExtras): > > https://codereview.qt-project.org/64342 > https://codereview.qt-project.org/64343 > https://codereview.qt-project.org/64344 > https://codereview.qt-project.org/64345 > https://codereview.qt-project.org/64346 > > Notes: > - The platform extras will continue to exist as research playgrounds. > - This approach works for platforms that has an Q_OS #define > - The function header is named "qmacfunctions.h", the namespace is "QMac" > - We can now use the public NSString conversion functions in QtCore when > implementing rest of Qt. > - Conversion functions in QtCore And Gui can be used without bringing in > QtMacExtras and its widgets dependency > > One case is still unsolved: classes that wrap native UI elements but are > neither widgets nor Qt Quick Items. (Mac native tool bar and windows task bar > for example). A possible solution could be to add the implementation to the > platform plugin and add public API in QtWidgets and Qt Quick Controls. > QMacNativeWidget and QMacCocoaViewContainer are done this way now, and are > basically API wrappers around the implementation in QCococaWindow. > > Morten > > > On Aug 30, 2013, at 3:27 PM, Jake Petroules > wrote: > >> +1 from me for doing it everywhere, including in the library names. >> -- >> Jake Petroules >> Chief Technology Officer >> Petroules Corporation · www.petroules.com >> Email: jake.petrou...@petroules.com >> >> On Aug 30, 2013, at 9:17 AM, Nurmi J-P wrote: >> >>> Hi all, >>> >>> While we still have a chance to tweak things before releasing 5.2, I'd like >>> to re-open the discussion about platform extras naming. >>> >>> Short version: >>> >>> Could we rename the QtMacExtras & QtWinExtras namespaces to just QtMac & >>> QtWin? (QtX11Extras namespace doesn't exist, at least yet) >>> >>> Long version: >>> >>> The current status: >>> >>> - Classes: QPlatformFoo >>> - QX11Info (*) >>> - QMacNativeWidget, ... >>> - QWinTaskbarButton, ... >>> >>> (*) The only thing in QtX11Extras - already released in Qt 5.1. >>> >>> - Stand-alone function namespaces: QtPlatformExtras::toType() >>> - QtWinExtras::toHBITMAP(), ... >>> - QtMacExtras::toCGImageRef(), ... >>> >>> >>> I'm not entirely happy with how the current stand-alone function namespaces >>> look in application code. I would find it prettier if we dropped the >>> "Extras" part from the namespace names. IMHO that would still remain >>> distinctive enough, just making it look more professional and... convenient >>> to type. :) >>> >>> if (QtWinExtras::isCompositionEnabled()) >>> // ... >>> >>> vs. >>> >>> if (QtWin::isCompositionEnabled()) >>> // ... >>> >>> >>> Open questions: >>> - What about the headers? >>> - Could #include also become ? >>> - was already released - so it would have to remain >>> as a compatibility header if we chose the latter >>> >>> - What about the lib names? Should we keep them intact? >>> - QtWinExtras.dll vs. QtWin.dll, or QtMacExtras.framework vs. >>> QtMac.framework is not necessarily an improvement >>> - The lib names are IMHO not that important, because users rarely have to >>> care. >>> >>> -- >>> J-P Nurmi >>> >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry picking to replace a change set
On segunda-feira, 2 de setembro de 2013 18:46:37, Oswald Buddenhagen wrote: > > That defines what atomic is. It doesn't say that the commit must compile > > and pass all tests if the rest of the commits in a topic are ignored. > > > > > > in fact, point 4 of the commit policy is pretty clear on that matter. it > is absurd to remove function (specific to the scope of the commit) from > the definition of atomicity. > also, the policy does not know a "topic" concept, for good reasons. you > cannot use topics (or branches which you intend to merge, for that > matter) as an excuse for violating the policy. > at the very most you can temporarily introduce chunks of dead code if it > does not affect the function of configurations which are expected to > work at all times. but even that is a stretch and should be done only > for big changes. We established that I disagree with those definitions in a previous discussion on this topic. That's why I was specific in my reply. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Improving package distribution
2013/8/22 Hirvonen Olli : > Mirrorbrain system is working and we are closing the old CacheFly service > 13th of September. The old service was using these addresses: > releases.qt-project.org & origin.releases.qt-project.org. There is a > redirect from releases.qt-project.org to download.qt-project.org, but sadly > the directory structure is not the same. Some links might be broken. All links are broken. Everything in releases.qt-project.org is redirecting to the root of download.qt-project.org. It should instead redirect to the same path to have at least some hope of being a working link (if the directory structure matches for that particular file). -- Nicolás ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry picking to replace a change set
On Mon, Sep 02, 2013 at 08:16:17AM -0700, Thiago Macieira wrote: > On segunda-feira, 2 de setembro de 2013 12:55:38, Oswald Buddenhagen wrote: > > On Sat, Aug 31, 2013 at 03:08:56PM -0700, Thiago Macieira wrote: > > > Of course, each commit must stand on its own and be self-contained (it has > > > to compile and should hopefully pass all tests). If you have to choose > > > between atomicity and self-containment, prefer self-containment. > > > > atomicity implies self-containment. it goes both ways. you can submit > > neither quarks nor molecules. > > http://qt-project.org/wiki/Commit_Policy 8.1 is pretty clear on that. > > That defines what atomic is. It doesn't say that the commit must compile and > pass all tests if the rest of the commits in a topic are ignored. > in fact, point 4 of the commit policy is pretty clear on that matter. it is absurd to remove function (specific to the scope of the commit) from the definition of atomicity. also, the policy does not know a "topic" concept, for good reasons. you cannot use topics (or branches which you intend to merge, for that matter) as an excuse for violating the policy. at the very most you can temporarily introduce chunks of dead code if it does not affect the function of configurations which are expected to work at all times. but even that is a stretch and should be done only for big changes. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New scenegraph renderer
On Sep 2, 2013, at 5:35 PM, Thiago Macieira wrote: > On segunda-feira, 2 de setembro de 2013 15:31:45, Sletta Gunnar wrote: >> Hi, >> >> The new scene graph renderer was just accepted into the qtdeclarative "dev" >> branch. I've done a fair amount of testing, but I'm sure some things will >> have slipped through, so if you notice something: Create a bugreport, mail >> me or ping me on IRC and I'll try to get it ironed out as soon as possible. > > Cool! > > Can you write a blog with the benefits? I already did, but I need to wait for a doc-run before one of the links become available :) cheers, Gunnar > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New scenegraph renderer
On segunda-feira, 2 de setembro de 2013 15:31:45, Sletta Gunnar wrote: > Hi, > > The new scene graph renderer was just accepted into the qtdeclarative "dev" > branch. I've done a fair amount of testing, but I'm sure some things will > have slipped through, so if you notice something: Create a bugreport, mail > me or ping me on IRC and I'll try to get it ironed out as soon as possible. Cool! Can you write a blog with the benefits? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] New scenegraph renderer
Hi, The new scene graph renderer was just accepted into the qtdeclarative "dev" branch. I've done a fair amount of testing, but I'm sure some things will have slipped through, so if you notice something: Create a bugreport, mail me or ping me on IRC and I'll try to get it ironed out as soon as possible. cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry picking to replace a change set
On segunda-feira, 2 de setembro de 2013 12:55:38, Oswald Buddenhagen wrote: > On Sat, Aug 31, 2013 at 03:08:56PM -0700, Thiago Macieira wrote: > > Of course, each commit must stand on its own and be self-contained (it has > > to compile and should hopefully pass all tests). If you have to choose > > between atomicity and self-containment, prefer self-containment. > > atomicity implies self-containment. it goes both ways. you can submit > neither quarks nor molecules. > http://qt-project.org/wiki/Commit_Policy 8.1 is pretty clear on that. That defines what atomic is. It doesn't say that the commit must compile and pass all tests if the rest of the commits in a topic are ignored. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
I agree the "Extra" looks superfluous. In fact I'd like to go a bit further and suggest we don't have platform extras at all and instead integrate the functionality into Qt: - Conversion functions for types in QtCore to QtCore - Conversion functions for types in QtGui to QtGui - Widgets to QtWidgets - Non-trivial implementation to the platform plugin - etc. I've prepared a set of patches showing how (for parts of QtMacExtras): https://codereview.qt-project.org/64342 https://codereview.qt-project.org/64343 https://codereview.qt-project.org/64344 https://codereview.qt-project.org/64345 https://codereview.qt-project.org/64346 Notes: - The platform extras will continue to exist as research playgrounds. - This approach works for platforms that has an Q_OS #define - The function header is named "qmacfunctions.h", the namespace is "QMac" - We can now use the public NSString conversion functions in QtCore when implementing rest of Qt. - Conversion functions in QtCore And Gui can be used without bringing in QtMacExtras and its widgets dependency One case is still unsolved: classes that wrap native UI elements but are neither widgets nor Qt Quick Items. (Mac native tool bar and windows task bar for example). A possible solution could be to add the implementation to the platform plugin and add public API in QtWidgets and Qt Quick Controls. QMacNativeWidget and QMacCocoaViewContainer are done this way now, and are basically API wrappers around the implementation in QCococaWindow. Morten On Aug 30, 2013, at 3:27 PM, Jake Petroules wrote: > +1 from me for doing it everywhere, including in the library names. > -- > Jake Petroules > Chief Technology Officer > Petroules Corporation · www.petroules.com > Email: jake.petrou...@petroules.com > > On Aug 30, 2013, at 9:17 AM, Nurmi J-P wrote: > >> Hi all, >> >> While we still have a chance to tweak things before releasing 5.2, I'd like >> to re-open the discussion about platform extras naming. >> >> Short version: >> >> Could we rename the QtMacExtras & QtWinExtras namespaces to just QtMac & >> QtWin? (QtX11Extras namespace doesn't exist, at least yet) >> >> Long version: >> >> The current status: >> >> - Classes: QPlatformFoo >> - QX11Info (*) >> - QMacNativeWidget, ... >> - QWinTaskbarButton, ... >> >> (*) The only thing in QtX11Extras - already released in Qt 5.1. >> >> - Stand-alone function namespaces: QtPlatformExtras::toType() >> - QtWinExtras::toHBITMAP(), ... >> - QtMacExtras::toCGImageRef(), ... >> >> >> I'm not entirely happy with how the current stand-alone function namespaces >> look in application code. I would find it prettier if we dropped the >> "Extras" part from the namespace names. IMHO that would still remain >> distinctive enough, just making it look more professional and... convenient >> to type. :) >> >>if (QtWinExtras::isCompositionEnabled()) >>// ... >> >> vs. >> >>if (QtWin::isCompositionEnabled()) >>// ... >> >> >> Open questions: >> - What about the headers? >> - Could #include also become ? >> - was already released - so it would have to remain >> as a compatibility header if we chose the latter >> >> - What about the lib names? Should we keep them intact? >> - QtWinExtras.dll vs. QtWin.dll, or QtMacExtras.framework vs. >> QtMac.framework is not necessarily an improvement >> - The lib names are IMHO not that important, because users rarely have to >> care. >> >> -- >> J-P Nurmi >> >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing keyboard layouts in Qt 5.1 apps with GNOME
PS: Tried the same routine under Openbox with QtCreator - with the same results (no layout change only on QtCreator with setxkbmap) . Petko ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing keyboard layouts in Qt 5.1 apps with GNOME
On 08/31/2013 07:35 PM, Thiago Macieira wrote:
> On sábado, 31 de agosto de 2013 14:51:58, Petko Ditchev wrote:
>>I need some help troubleshooting a problem I've been having : for a
>> week now (I think since some updates to the keyboard layout settings in
>> gnome) I can't change the keyboard layout in QtCreator (built with
>> Qt5.1) and in my app that is on the same lib . Otherwise everything's ok
>> , but Qt5.1 apps stick with the layout they are launched with .
>>I'm sending this to both lists because the bug affects GNOME , but not
>> Unity , and it affects Qt5.1 , but not Qt4 .
> Can you provide us with the output of setxkbmap -print before and after the
> keyboard change? It would be useful to get the xev output for a keystroke that
> changed too (before and after).
>
> Finally, can you make the same test by switching keyboard layouts with
> setxkbmap?
>
At last I got to doing the tests , sorry for the delay .
Output with the en_US layout:
setxkbmap -print
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)+terminate(ctrl_alt_bksp)" };
xkb_geometry { include "pc(pc105)" };
};
Output with the bulgarian phonetic layout :
setxkbmap -print
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include
"pc+bg(phonetic)+us:2+inet(evdev)+terminate(ctrl_alt_bksp)" };
xkb_geometry { include "pc(pc105)" };
};
That's the xprop for the window I'm testing on (it's my app) :
xprop
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 32, 0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE,
_NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN,
_NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE,
_NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT,
_NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE,
_NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x1800011
_NET_WM_STATE(ATOM) = _NET_WM_STATE_MAXIMIZED_HORZ,
_NET_WM_STATE_MAXIMIZED_VERT
_NET_WM_ICON(CARDINAL) =
XdndAware(ATOM) = BITMAP
_NET_WM_NAME(UTF8_STRING) = "Мисли -notes"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x0
WM_CLIENT_LEADER(WINDOW): window id # 0x182
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
_NET_WM_PID(CARDINAL) = 3126
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 25165838
WM_CLASS(STRING) = "misli", "misli"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS,
_NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified size: 800 by 600
program specified minimum size: 0 by 27
window gravity: Static
Then xev on the same window
$ xev -id 0x182 -event keyboard
(no output when I tried all kinds of keys on both layouts)
^C
$ xev -id 0x182
ColormapNotify event, serial 18, synthetic NO, window 0x182,
colormap 0x20, new NO, state ColormapInstalled
ColormapNotify event, serial 18, synthetic NO, window 0x182,
colormap 0x20, new NO, state ColormapUninstalled
With no specified -event that's the only output I got , when opening up
some popup windows for file selection or something like that.
Last but not least :
setxkbmap en
setxkbmap bg
still don't change the keyboard layout on the Qt5.1.1 apps.
Do tell if there's anything else I can try out .
Petko
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry picking to replace a change set
On Sat, Aug 31, 2013 at 03:08:56PM -0700, Thiago Macieira wrote: > Of course, each commit must stand on its own and be self-contained (it has to > compile and should hopefully pass all tests). If you have to choose between > atomicity and self-containment, prefer self-containment. > atomicity implies self-containment. it goes both ways. you can submit neither quarks nor molecules. http://qt-project.org/wiki/Commit_Policy 8.1 is pretty clear on that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Flat directory structure for Qt 5.2 documentation
The flat directory structure doesn't fix the QObject/QWidget subclass problem. At the moment, this is in the "Too Hard" category. martin From: development-bounces+martin.smith=digia@qt-project.org [development-bounces+martin.smith=digia@qt-project.org] on behalf of Yves Bailly [yves.bai...@laposte.net] Sent: Monday, September 02, 2013 12:46 PM To: development@qt-project.org Subject: Re: [Development] Flat directory structure for Qt 5.2 documentation On 02/09/2013 09:52, Smith Martin wrote: > Two reasons. First, so people can enter documentation page paths without > knowing > the module subdirectory they are in. Second, so the pages will appear first > in google searches. One more reason: take the Qt5's QObject page, QWidget doesn't show in its subclasses. This is true for others as well. Overall I find the documentation harder to navigate since Qt4, compared to Qt3 which was a real pleasure. -- (o< | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Flat directory structure for Qt 5.2 documentation
On 02/09/2013 09:52, Smith Martin wrote: > Two reasons. First, so people can enter documentation page paths without > knowing > the module subdirectory they are in. Second, so the pages will appear first > in google searches. One more reason: take the Qt5's QObject page, QWidget doesn't show in its subclasses. This is true for others as well. Overall I find the documentation harder to navigate since Qt4, compared to Qt3 which was a real pleasure. -- (o< | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature request: several layouts in a single ui file
On 02/09/2013 09:46, Saether Jan-Arve wrote: > What you are suggesting should be possible, but I would like to explore if > there can be a more generic way. > You are suggesting to push this even further, i.e. one layout might use a > QComboBox instead of a groupbox with radio buttons. > * If its pushed far enough, wouldn't this be like having two separate .ui > files that could be switched? I had not considered to go as far as change the contents itself - this would imply to destroy (or hide) some things, then to create (or show) some others. Maybe it's a step too far... But overall, indeed it's a bit like having two .ui then switch between them - with the important goal to avoid as much as possible to destroy/recreate things. In the beginning it was just about changing the layout and some properties (e.g. some size policies). Regards, -- (o< | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Flat directory structure for Qt 5.2 documentation
On 2 September 2013 12:07, Joerg Bornemann wrote: > Third, my rather obscure use case: > switching between Qt4 and Qt5 doc URLs more easily. This could easily be done by server-side redirections, though... (cf. QTWEBSITE-504) -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Flat directory structure for Qt 5.2 documentation
On 02/09/2013 09:52, Smith Martin wrote: > Two reasons. First, so people can enter documentation page paths without > knowing the module subdirectory they are in. Second, so the pages will appear > first in google searches. Third, my rather obscure use case: switching between Qt4 and Qt5 doc URLs more easily. Enter http://qt-project.org/doc/qt-5.1/qtcore/qstring.html OK, let's have a look at the Qt4 version now by modifying the version http://qt-project.org/doc/qt-4.8/qtcore/qstring.html 404! Darn, I forgot to remove the module name http://qt-project.org/doc/qt-4.8/qstring.html That's the right one. "OK, but don't you know that there's a combobox that lets you choose the Qt version?" Ys, but I'd rather not use the mouse for that. :) Cheers, Joerg -- Joerg Bornemann Digia, Qt http://qt.digia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
Hi,
On Sunday 01 September 2013 13:20:10 Stefan Merettig wrote:
> The meta object compiler currently supports something it calls 'method
> tags', where it collects identifiers it doesn't know in front of
> methods:
>
> #ifndef Q_MOC_RUN
> # define MYTAG
> #endif
> ...
> MYTAG void myFunction ();
>
> While this feature is already helpful for simple scenarios, it is quite
> limited as it doesn't support arguments at all (It throws a syntax
> error if a user tries to do this).
>
> To overcome this I'd like to add a macro called Q_INFO (As proposed by
> Richard):
>
> #define Q_INFO(...)
I think adding general information to method or properties are a good idea.
The current tag system is indeed very limited.
But before trying to get something to general, we need to focus on use cases.
> It is up to debate what structure the argument should have. The
> following
> ideas were proposed:
> 1) Q_INFO("myTag" LIST "foo" "bar" END)
> 2) Q_INFO("myTag" ARGS "foo", "bar") // Or ARGUMENTS instead of ARGS
> 3) Q_INFO(myTag ("foo", "bar")) // Alternative: The name is "quoted"
I add my ideas:
Q_INFO(key = value)
Q_INFO(key, value)
Q_INFO("key", "value")
I rather opt for a key/value system. then it can easily be queried with
something like.
QByteArray QMetaMethod::methodInfo(const char *key);
What is really your use case with several argument that cannot be done with a
key/value system? Worst case you can do something like
Q_INFO(key.arg1 = foo)
Q_INFO(key.arg2 = bar)
> Q_INFO can be prefixed to ...
> 1) Classes
We already have Q_CLASS_INFO for classes.
> 2) Methods (Signals, slots, Q_INVOKABLE methods)
Make sens.
> 3) Properties
For propeties, i'd rather see something within the property.
For example
Q_PROPERTY(foo MEMBER m_foo INFO key=value)
> 4) Enums which are exported through Q_ENUMS()
> Note: The Q_INFO macro is prefixed to the enum itself in this case!
> WHY as in USE-CASE EXAMPLE
>
> Pretend you have a library which provides a RPC server with a user
> management component. You write a QObject class which shall implement
> all slots you want to expose. Not every user should be able to invoke
> every slot, thus you use the annotation mechanism which lets you define
> the desired behaviour right there, in the header.
>
> Q_INFO("Awesome.RpcServer.path" ARGS "services/stuff")
> class MyServices : public QObject {
> Q_INFO("Awesome.RpcServer.isPublic" ARGS "false")
> Q_PROPERTY(int activeUserCount READ activeUserCount)
> ...
> public slots:
> Q_INFO("Awesome.RpcServer.requiredPermissions" ARGS "admin")
> Q_INFO("Awesome.RpcServer.onlyAuthenticatedUsers")
> bool deleteUser (QString user);
> ...
> };
BTW, All of that can be done currently by abusing Q_CLASSINFO
class MyServices : public QObject {
Q_CLASSINFO("Awesome.RpcServer.Path", "false")
Q_PROPERTY(int activeUserCount READ activeUserCount)
Q_CLASSINFO("Awesome.RpcServer.isPublic.activeUserCount", "false")
public slots:
bool deleteUser (QString user);
Q_CLASSINFO("Awesome.RpcServer.requiredPermissionssPublic.deleteUser",
"admin")
Q_CLASSINFO("Awesome.RpcServer.onlyAuthenticatedUsers.deleteUser",
"true")
};
That said, it would indeed be better to have info class.
[...]
> NEEDED CHANGES
>
> 1) The meta object compiler (moc) needs to be extended to support this
> feature.
Yes.
Notice that we could also re-use the "tag" field of the data array for some
purpose (it would mean the old tag or the info count depending on one of the
bit or of the revision)
> 2) qglobal.h needs to be adjusted to carry #define Q_INFO(...)
qobjectdefs.h
> 3) At least another class needs to be introduced to Qt. I'd like to
> call it QMetaInfo, though I'm fine with a different name if anyone
> thinks that this name is bad for some reason. Other QMeta* classes
> need to be adjusted.
There is QMetaClassInfo, but i'd rather see a key value API.
> On top of that some internal Qt classes need to be made aware of this
> feature. For a more complete list, please see the commit messages in
> the
> patch set.
>
> TECHNOLOGY PREVIEW
>
> Thiago mentioned that a modified moc would be helpful, so I worked on
> it. You can view the patch set here:
> https://codereview.qt-project.org/#change,64287
>
> A moc with my modifications supports Q_INFO everywhere I'd like it to
> be available. No changes were made outside moc's tree though.
--
Olivier
Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Flat directory structure for Qt 5.2 documentation
Two reasons. First, so people can enter documentation page paths without knowing the module subdirectory they are in. Second, so the pages will appear first in google searches. martin From: development-bounces+martin.smith=digia@qt-project.org [development-bounces+martin.smith=digia@qt-project.org] on behalf of Nicolás Alvarez [nicolas.alva...@gmail.com] Sent: Sunday, September 01, 2013 1:25 AM To: development@qt-project.org Subject: Re: [Development] Flat directory structure for Qt 5.2 documentation 2013/8/30 Pasion Jerome : > For Qt 5.2, we plan to deliver the online documentation (qt-project.org/doc) > using a flat documentation structure. Currently, the online documentation > is using the modularized structure. What's the reason for this, out of curiosity? -- Nicolás ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature request: several layouts in a single ui file
What you are suggesting should be possible, but I would like to explore if there can be a more generic way. You are suggesting to push this even further, i.e. one layout might use a QComboBox instead of a groupbox with radio buttons. * If its pushed far enough, wouldn't this be like having two separate .ui files that could be switched? Jan Arve > -Original Message- > From: development-bounces+jan-arve.saether=digia@qt-project.org > [mailto:development-bounces+jan-arve.saether=digia@qt-project.org] > On Behalf Of Yves Bailly > Sent: 1. september 2013 15:57 > To: development@qt-project.org > Subject: Re: [Development] Feature request: several layouts in a > single ui file > On 01/09/2013 05:49, Sze Howe Koh wrote: >> On 1 September 2013 05:27, Yves Bailly > wrote: >>> On 31/08/2013 14:42, Mark wrote: A nice way to load different gui versions is by combining states [1] and the loader object [2] and just load the gui you want based on the state you set. [1] http://qt-project.org/doc/qt-5.1/qtquick/qml-qtquick2- state.html [2] http://qt-project.org/doc/qt-5.1/qtquick/qml-qtquick2-loader.html >>> >>> If I understand things correctly, using the loader is a bit like >>> "destroy the current GUI" followed by "rebuild a new GUI". >>> >> >> You can achieve that with traditional QWidgets without destroying >> and reconstructing any objects. > > I'm perfectly aware of this, that's what I'm doing "by hand" for now. > > What I was suggesting in the beginning of this thread, was to add > support for this in QtDesigner and UI files. > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
