On Sun, May 13, 2012 at 10:11 PM, Rick Stockton <
rickstock...@reno-computerhelp.com> wrote:
> On Saturday 12 May 2012 18:36:42 Mark wrote:
>
> > / As for making a "HIG" keyboard standard list. A very good starting
> > point is:
> />/ http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts />/
>
Alexander Neundorf wrote:
> On Sunday 13 May 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
> ...
>> > This means either we need to put a lot of work in the buildsystem, to
>> > handle all cases correctly (and clean up afterwards again), or we don't
>> > support building standalone for an
On Sunday 13 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
...
> > This means either we need to put a lot of work in the buildsystem, to
> > handle all cases correctly (and clean up afterwards again), or we don't
> > support building standalone for anything tier>1 at all, also with Qt5
On Saturday 12 May 2012 18:36:42 Mark wrote:
/ As for making a "HIG" keyboard standard list. A very good starting
point is:
/>/ http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts />/
/>/ Every single line where the same key combination is used in both:
Windows,
/>/ Mac, KDE en GNOME ca
On Saturday 12 May 2012 23:24:04 Kevin Ottens wrote:
> Git commit f1eee305fe31b002b8f35738873fe45dedf83fc1 by Kevin Ottens.
> Committed on 12/05/2012 at 23:22.
> Pushed by ervin into branch 'frameworks'.
>
> Move kconfig_compiler tests in kconfig framework
I get this (full kdelibs, Qt4, latest EC
Alexander Neundorf wrote:
>> We'll still keep it possible to build with Qt 4 for some months yet.
>> Probably as long as it's still useful. Currently it is useful because the
>> output of unit tests can show whether failures result from frameworks
>> code or Qt 5 changes.
>>
>> What I mean though
On Sunday 13 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Sunday 13 May 2012, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > On Sunday 13 May 2012, Stephen Kelly wrote:
> >> >> Alexander Neundorf wrote:
> >> >> > Hi,
> >> >> >
> >> >> > in libinqt5/src/ there is a
Mark, your responses improve on my ideas, and leads to a more solid
"shared vision". (That's Awesome!) Here's a "brain dump" of my thoughts
- some responding to you, some others not yet discussed:
Within Qt, there are a couple of reasons why I don't want to create a
generic "all-shortcuts" set
Alexander Neundorf wrote:
> On Sunday 13 May 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > On Sunday 13 May 2012, Stephen Kelly wrote:
>> >> Alexander Neundorf wrote:
>> >> > Hi,
>> >> >
>> >> > in libinqt5/src/ there is a libqtmimetypes.
>> >> > This contains again a complete proj
Hi,
one thing which I noticed was done in all directories in tier1/ and tier2/ was
that CMAKE_MODULE_PATH was not reset, i.e. it was always appended, e.g. like
this:
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH} )
If it is done this way, you don't notice if you f
On Sunday 13 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Sunday 13 May 2012, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > Hi,
> >> >
> >> > in libinqt5/src/ there is a libqtmimetypes.
> >> > This contains again a complete project.
> >> > Is this supposed to be b
Alexander Neundorf wrote:
> On Sunday 13 May 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > Hi,
>> >
>> > in libinqt5/src/ there is a libqtmimetypes.
>> > This contains again a complete project.
>> > Is this supposed to be buildable standalone, or always only inside
>> > libinqt5 ?
On Sunday 13 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Hi,
> >
> > in libinqt5/src/ there is a libqtmimetypes.
> > This contains again a complete project.
> > Is this supposed to be buildable standalone, or always only inside
> > libinqt5 ?
>
> It used to buils standalone, bu
Alexander Neundorf wrote:
> On Sunday 13 May 2012, Kevin Ottens wrote:
>> On Sunday 13 May 2012 12:24:55 Alexander Neundorf wrote:
>> > On Sunday 13 May 2012, David Faure wrote:
>> > > But one big module with independent subprojects that don't get
>> > > compiled out of the box, sounds like a majo
Alexander Neundorf wrote:
> Hi,
>
> in libinqt5/src/ there is a libqtmimetypes.
> This contains again a complete project.
> Is this supposed to be buildable standalone, or always only inside
> libinqt5 ?
>
It used to buils standalone, but Rolf Eike Beer moved it around for his own
packaging re
Hi,
in libinqt5/src/ there is a libqtmimetypes.
This contains again a complete project.
Is this supposed to be buildable standalone, or always only inside libinqt5 ?
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kd
On Sunday 13 May 2012, Kevin Ottens wrote:
> On Sunday 13 May 2012 12:24:55 Alexander Neundorf wrote:
> > On Sunday 13 May 2012, David Faure wrote:
> > > But one big module with independent subprojects that don't get compiled
> > > out of the box, sounds like a major pain (lots of manual setup, and
On Sunday 13 May 2012 11:07:48 Alexander Neundorf wrote:
> in solid/src/CMakeLists.txt there is this code:
>
> file(MAKE_DIRECTORY
>${CMAKE_CURRENT_BINARY_DIR}/backends/fakehw
>${CMAKE_CURRENT_BINARY_DIR}/backends/hal
>${CMAKE_CURRENT_BINARY_DIR}/backends/udev
>${CMAKE_CURRENT_BINAR
On Sunday 13 May 2012 12:24:55 Alexander Neundorf wrote:
> On Sunday 13 May 2012, David Faure wrote:
> > But one big module with independent subprojects that don't get compiled
> > out of the box, sounds like a major pain (lots of manual setup, and manual
> > scripts for building everything after a
Am 13.05.2012 11:07, schrieb Alexander Neundorf:
> Hi,
>
> in solid/src/CMakeLists.txt there is this code:
>
> file(MAKE_DIRECTORY
>
> ${CMAKE_CURRENT_BINARY_DIR}/backends/fakehw
>
> ${CMAKE_CURRENT_BINARY_DIR}/backends/hal
>
> ${CMAKE_CURRENT_BINARY_DIR}/backends/udev
>
> ${CMAKE_CURRENT_BIN
On Sunday 13 May 2012, David Faure wrote:
> On Sunday 13 May 2012 01:43:15 Alexander Neundorf wrote:
> > Maybe everything which is done should be taken out of the project
> > immediately, i.e. not added per add_subdirectory() anymore (independent
> > from the git repository) ?
>
> I'd really rath
On Sunday 13 May 2012 01:43:15 Alexander Neundorf wrote:
> Maybe everything which is done should be taken out of the project
> immediately, i.e. not added per add_subdirectory() anymore (independent
> from the git repository) ?
I'd really rather not. From a code point of view, I need to compile e
On Sunday 13 May 2012, Alexander Neundorf wrote:
> On Sunday 13 May 2012, David Faure wrote:
> > On Saturday 12 May 2012 21:50:51 Alexander Neundorf wrote:
> > > Using RPATH instead of RUNPATH would make our unit tests run reliably
> > > in all cases.
> >
> > Yep, I would like that :)
> >
> > Th
On Sunday 13 May 2012 11:30:18 Alexander Neundorf wrote:
> Hi,
>
> there is a header kdelibs/kde_qt5_compat.h .
> This header is used by tier2/kconfig/.
> But this header is not installed, at least not when building everything
> separately, kconfig can't build separately.
Yep. It's just a tempora
On Sunday 13 May 2012, David Faure wrote:
> On Saturday 12 May 2012 21:50:51 Alexander Neundorf wrote:
> > Using RPATH instead of RUNPATH would make our unit tests run reliably in
> > all cases.
>
> Yep, I would like that :)
>
> The only case I can think of, where RUNPATH is better than RPATH, i
Hi,
there is a header kdelibs/kde_qt5_compat.h .
This header is used by tier2/kconfig/.
But this header is not installed, at least not when building everything
separately, kconfig can't build separately.
So, what do we do ?
Move this header into inqt5 and install it ?
Alex
On Saturday 12 May 2012 21:50:51 Alexander Neundorf wrote:
> Using RPATH instead of RUNPATH would make our unit tests run reliably in
> all cases.
Yep, I would like that :)
The only case I can think of, where RUNPATH is better than RPATH, is when you
want to force an existing KDE installation t
On Friday 11 May 2012 21:07:58 Mark wrote:
> The only reservation i have is the case where some developer comes by and
> makes a KDE application with actions that aren't defined yet in Shortcut
> Manager.
I'm not sure what you mean by 'not defined yet'...
KShortcutManager will not have any knowl
On Saturday 12 May 2012 18:36:42 Mark wrote:
> 3. There needs to be some way of storage for keys, give them a default
> value and restore that value on the user request. This is what KDE has with
> Shortcut Editor. The app itself should not be in Qt, but the storage of the
> data should live in Qt
Hi,
in solid/src/CMakeLists.txt there is this code:
file(MAKE_DIRECTORY
${CMAKE_CURRENT_BINARY_DIR}/backends/fakehw
${CMAKE_CURRENT_BINARY_DIR}/backends/hal
${CMAKE_CURRENT_BINARY_DIR}/backends/udev
${CMAKE_CURRENT_BINARY_DIR}/backends/wmi
)
This looks unnecessary to me.
The director
30 matches
Mail list logo