Re: Introducing components, how to
On 11/09/2011 07:31 PM, Marco Martin wrote: Hi all, there is still some work to do, but the components are almost done in their final structure (good for the upoming freeze, ehehe :) components are imported with: import org.kde.plasma.components regardless of the platform we're in. We have at the moment 37 widgets in the touch profile, 35 in the normal one, tried to follow the standard api as much as possible even tough with some little deviations (especially where it was too unbearably ugly :p) As for documentation, of course any help will always be welcome :p If you are writing an application, just use kdeclarative, and the proper import paths will be setted. to see what component is available, just take a look at the qmldir file in the source directory of kde-runtime kde-runtime/plasma/declarativeimports/plasmacomponents/qml/ or kde- runtime/plasma/declarativeimports/plasmacomponents/platformcomponents/touch/ now, two things: Q: why checking qmldir? A: not all files are available, the ones not shown there are private api Q: what are those two folders? A: hardware specific components: the plasma QtComponents are targeted to two things: * Plasma Desktop widgets * Plasma Active widgets and applications (for desktop applications, we can only wait to see whatever it happens with desktop components but is way too early to know ;) When writing a widget, an application etc, just use import org.kde.plasma.components, the proper one is decided by the kdeclarativerc file, if it has [Components-platform] name=touch for packagers: in plasma active among the default files this kdeclarativerc has to be installed the imports in platformcomponents/touch will override the standard one, actually giving a series of touch optimized widgets. only a few that needed have different implementations, the other ones are duplicated by being installed 2 times by cmake some of the differences: * Buttons and lineedits don't have mouseover effects * by default scrollbars behave like scroll decorators on touch * scrolldecorators are installed only on touch (provided just for compatibility, use scrollbar instead, it behaves the right way(tm) ;)) * sectionscroller looks like the iphone addressbook scroller on touch, like a scrollbar on desktop * Window is *not* provided on desktop: in desktop widgets makes really no sense * QueryDialog uses a KDialog on desktop, on touch uses qml items and is in a Plasma::Dialog * the same way, Menu/ContextMenu is a QMenu on desktop, while is a more plasma looking thing on touch this architecture is going to be final once released in 4.8 (at least until frameworks5), so "speak now or forever shut up" :p Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel Hi! I wanted to try it so I decided to port KAlgebra to this new set of components: I had it abstracted to support desktop and harmattan already, so it wasn't painful at all. I've put together some screenshots in case you wonder what does it look like if you don't want to compile it and execute it. :) http://proli.net/meu/kalgebra/kalgebramobile_kdeclarative.png http://proli.net/meu/kalgebra/kalgebramobile_kdeclarative1.png http://proli.net/meu/kalgebra/kalgebramobile_kdeclarative2.png http://proli.net/meu/kalgebra/kalgebramobile_kdeclarative3.png Good work! Aleix PS: It's not possible to draw icons yet, no? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Introducing components, how to
On Wednesday, November 09, 2011 03:31:46 PM Marco Martin wrote: > Hi all, > > there is still some work to do, but the components are almost done in their > final structure (good for the upoming freeze, ehehe :) > > components are imported with: > import org.kde.plasma.components > > regardless of the platform we're in. > > We have at the moment 37 widgets in the touch profile, 35 in the normal > one, tried to follow the standard api as much as possible even tough with > some little deviations (especially where it was too unbearably ugly :p) > > As for documentation, of course any help will always be welcome :p The plasma components documentation work is happening on remotes/origin/plasma-components-doc branch. > > > If you are writing an application, just use kdeclarative, and the proper > import paths will be setted. > > to see what component is available, just take a look at the qmldir file in > the source directory of kde-runtime > kde-runtime/plasma/declarativeimports/plasmacomponents/qml/ > or > kde- > runtime/plasma/declarativeimports/plasmacomponents/platformcomponents/touch > / > > now, two things: > Q: why checking qmldir? > A: not all files are available, the ones not shown there are private api > > Q: what are those two folders? > A: hardware specific components: > > the plasma QtComponents are targeted to two things: > * Plasma Desktop widgets > * Plasma Active widgets and applications > > (for desktop applications, we can only wait to see whatever it happens with > desktop components but is way too early to know ;) > > When writing a widget, an application etc, just use > import org.kde.plasma.components, the proper one is decided by the > kdeclarativerc file, if it has > [Components-platform] > name=touch > > for packagers: in plasma active among the default files this kdeclarativerc > has to be installed > > the imports in platformcomponents/touch will override the standard one, > actually giving a series of touch optimized widgets. > > only a few that needed have different implementations, the other ones are > duplicated by being installed 2 times by cmake > > some of the differences: > * Buttons and lineedits don't have mouseover effects > * by default scrollbars behave like scroll decorators on touch > * scrolldecorators are installed only on touch (provided just for > compatibility, use scrollbar instead, it behaves the right way(tm) ;)) > * sectionscroller looks like the iphone addressbook scroller on touch, like > a scrollbar on desktop > * Window is *not* provided on desktop: in desktop widgets makes really no > sense > * QueryDialog uses a KDialog on desktop, on touch uses qml items and is in > a Plasma::Dialog > * the same way, Menu/ContextMenu is a QMenu on desktop, while is a more > plasma looking thing on touch > > > this architecture is going to be final once released in 4.8 (at least until > frameworks5), so "speak now or forever shut up" :p > > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel Cheers, -- Daker Fernandes Pinheiro openBossa ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Introducing components, how to
On Wednesday, November 09, 2011 21:01:16 Martin Gräßlin wrote: > On Wednesday 09 November 2011 20:05:00 Marco Martin wrote: > > On Wednesday 09 November 2011, Marco Martin wrote: > > > When writing a widget, an application etc, just use > > > import org.kde.plasma.components, the proper one is decided by the > > > kdeclarativerc file, if it has > > > [Components-platform] > > > name=touch > > > > something Sune just noted to me.. > > maybe an environment variable would be better to chose this? > > > > opinions? ;) > > both would be nice. Global config file and an environment variable to > overwrite. Should make testing touch stuff on desktop easier. > > In KWin we have some options with environment variables overwriting > settings, so that works :-) +1, seems to be the most flexible approach, especially for testing different UI versions next to each other. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Introducing components, how to
On Wednesday 09 November 2011 20:05:00 Marco Martin wrote: > On Wednesday 09 November 2011, Marco Martin wrote: > > When writing a widget, an application etc, just use > > import org.kde.plasma.components, the proper one is decided by the > > kdeclarativerc file, if it has > > [Components-platform] > > name=touch > > something Sune just noted to me.. > maybe an environment variable would be better to chose this? > > opinions? ;) both would be nice. Global config file and an environment variable to overwrite. Should make testing touch stuff on desktop easier. In KWin we have some options with environment variables overwriting settings, so that works :-) Cheers Martin > > Cheers, > Marco Martin > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Introducing components, how to
On Wednesday 09 November 2011, Marco Martin wrote: > When writing a widget, an application etc, just use > import org.kde.plasma.components, the proper one is decided by the > kdeclarativerc file, if it has > [Components-platform] > name=touch something Sune just noted to me.. maybe an environment variable would be better to chose this? opinions? ;) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Introducing components, how to
On Wednesday, November 9, 2011 19:31:46 Marco Martin wrote: > Hi all, > > there is still some work to do, but the components are almost done in their > final structure (good for the upoming freeze, ehehe :) cool; it's worth sending this to kde-core-devel and perhap seven kde-devel as well imho ... there are people waiting for these things in the edu and games world, for instance. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
