On Wed, Jan 8, 2025, at 6:24 PM, Nate Graham wrote:
> On 1/3/25 8:17 AM, Nicolas Fella wrote:
> > Am 30.12.24 um 18:51 schrieb Nate Graham:
> >> A long term concern I have is that it's messy and unpleasant to have
> >> default styling data scattered across so many places. Ideally we'd be
> >> able
On 1/3/25 8:17 AM, Nicolas Fella wrote:
Am 30.12.24 um 18:51 schrieb Nate Graham:
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data about a particular style in a single
repo, so
On 12/31/24 4:59 AM, Ingo Klöcker wrote:
On Montag, 30. Dezember 2024 18:51:39 Mitteleuropäische Normalzeit Nate Graham
wrote:
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data
On Monday, 30 December 2024 18.51.39 Central European Standard Time Nate
Graham wrote:
> A long term concern I have is that it's messy and unpleasant to have
> default styling data scattered across so many places. Ideally we'd be
> able to centralize *all* data about a particular style in a single
Am 30.12.24 um 18:51 schrieb Nate Graham:
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data about a particular style in a single
repo, so that making changes is easy and that rep
On Montag, 30. Dezember 2024 18:51:39 Mitteleuropäische Normalzeit Nate Graham
wrote:
> A long term concern I have is that it's messy and unpleasant to have
> default styling data scattered across so many places. Ideally we'd be
> able to centralize *all* data about a particular style in a single
Hi,
On 2024-12-30 21:58, Nate Graham wrote:
On 12/30/24 12:31 PM, christ...@cullmann.io wrote:
On 2024-12-30 18:51, Nate Graham wrote:
I see an opportunity to move closer to that here. So my preference
would be to implement the proposal, but also:
- the default window decorations remain in Br
On 12/30/24 12:31 PM, christ...@cullmann.io wrote:
On 2024-12-30 18:51, Nate Graham wrote:
I see an opportunity to move closer to that here. So my preference
would be to implement the proposal, but also:
- the default window decorations remain in Breeze
- the default colors remain in Breeze, an
Hi,
On 2024-12-30 18:51, Nate Graham wrote:
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data about a particular style in a single
repo, so that making changes is easy and tha
A long term concern I have is that it's messy and unpleasant to have
default styling data scattered across so many places. Ideally we'd be
able to centralize *all* data about a particular style in a single repo,
so that making changes is easy and that repo can be swapped out for
another one in
On Tue Dec 17, 2024 at 03:53:01PM +0100, Carl Schwan wrote:
> Hi,
>
> Considering that all of our apps are relying on breeze and on platform
> outside of Plasma, this is even a
> required dependency, I think breeze should be a tier 3 framework and not be
> part of Plasma. The idea
> is not new a
Hello,
For what's worth I'd definitely support this. It's been a pain in the neck on
the KDE Neon Core front as well. The KF6 runtime snap carries some Plasma bits
for the reasons highlighted in this thread. The different cycles and
versioning has been causing headaches.
Regards.
On Tuesday 1
On Wed, Dec 18, 2024 at 5:20 AM David Redondo wrote:
> On 2024-12-17 15:53, Carl Schwan wrote:
>
> > > - Don't have apps depend on a Plasma component when compiled for
> > > Windows and macOS
> > > - Apps can now rely on some new behavior of breeze with either
> > > depending a specific minimum
On 2024-12-17 17:20, David Redondo wrote:
On 2024-12-17 15:53, Carl Schwan wrote:
> - Don't have apps depend on a Plasma component when compiled for
> Windows and macOS
> - Apps can now rely on some new behavior of breeze with either
> depending a specific minimum version of
> framework or usin
On 2024-12-17 15:53, Carl Schwan wrote:
> > - Don't have apps depend on a Plasma component when compiled for
> > Windows and macOS
> > - Apps can now rely on some new behavior of breeze with either
> > depending a specific minimum version of
> > framework or using ifdefs
Breeze is also version
On Dienstag, 17. Dezember 2024 15:53:01 Mitteleuropäische Normalzeit Carl
Schwan wrote:
> Hi,
>
> Considering that all of our apps are relying on breeze and on platform
> outside of Plasma, this is even a required dependency, I think breeze
> should be a tier 3 framework and not be part of Plasma
On 2024-12-17 15:53, Carl Schwan wrote:
Hi,
Considering that all of our apps are relying on breeze and on platform
outside of Plasma, this is even a
required dependency, I think breeze should be a tier 3 framework and
not be part of Plasma. The idea
is not new and this was on the KF6 board:
h
Hi,
Considering that all of our apps are relying on breeze and on platform outside
of Plasma, this is even a
required dependency, I think breeze should be a tier 3 framework and not be
part of Plasma. The idea
is not new and this was on the KF6 board: https://phabricator.kde.org/T12611
There ar
18 matches
Mail list logo
