So kdelibs and kdebase are switching to Git, probably not Dec 20/21 as
was previously thought, but at the release of 4.6.0.
Whether its next week or next month though, its pretty soon. :)
I have three work-in-progress repos, the first two I created last night:
http://gitweb.kde.org/scratch/ianmon
In principle I like the idea.
But can the execution also work in other areas?
How many items can be grouped together in a feasible way?
Currently I have KWrite open. When I look at the Edit menu, I see:
Find, Find Next, Find Previous, Replace, Find Selected, Find Selected Backwards.
Those are six
Am Dienstag 14 Dezember 2010, 00:01:54 schrieb Aaron J. Seigo:
> (as a side note: this will break with dbusmenu; so it can't find its way
> easily into the system tray icon menus, for instance)
If it breaks dbusmenu, all the work on the Global Menu Bar front would go to
waste as
well.
On Monday, December 13, 2010, Dan Meltzer wrote:
> If common actions were all handled in this way, then it might
> actually lead to more consistancy,
consistency with what? certainly not with the menus, where we will now have
items that behave differently.
(as a side note: this will break with
On Mon, Dec 13, 2010 at 5:26 PM, Aaron J. Seigo wrote:
> On Monday, December 13, 2010, Miha Čančula wrote:
>> The pros and cons I can think of right now are: Pro:
>> 1. Biger clickable area => less chance of misclicks
>
> not substantially bigger; and in this case it would be interesting to know
On Monday, December 13, 2010, Miha Čančula wrote:
> The pros and cons I can think of right now are: Pro:
> 1. Biger clickable area => less chance of misclicks
not substantially bigger; and in this case it would be interesting to know
just how many misclicks actually happen using both UI styles.
> As someone who uses KDE on a computer without any pointing device, I
> rely on my keyboard's context menu key [1] quite a bit.
>
> Parker
>
> [1] http://en.wikipedia.org/wiki/Menu_key
>
I know, I know. I'm already reading through QMenu's code, I think I've come
up with something.
On Mon, Dec 13, 2010 at 16:26, Miha Čančula wrote:
> 2010/12/13 Albert Astals Cid
>> A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure:
>> > Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid
>> > napisal(a):
>> > > Does this break keyboard navigation in the menu?
>> >
>> >
A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure:
> 2010/12/13 Albert Astals Cid
>
> > A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure:
> > > Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid
> >
> > napisal(a):
> > > > Does this break keyboard navigation in
2010/12/13 Albert Astals Cid
> A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure:
> > Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid
> napisal(a):
> > > Does this break keyboard navigation in the menu?
> >
> > Yes, unfortunately it does, I just tried. The elements disp
A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure:
> Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid napisal(a):
> > Does this break keyboard navigation in the menu?
>
> Yes, unfortunately it does, I just tried. The elements displayed this way
> are not selectable by key
Dne ponedeljek 13 decembra 2010 ob 21:32:30 je Albert Astals Cid napisal(a):
> Does this break keyboard navigation in the menu?
Yes, unfortunately it does, I just tried. The elements displayed this way are
not selectable by keyboard, even thought other actions in the same menu are.
signature.as
A Dilluns, 13 de desembre de 2010, Miha Čančula va escriure:
> I have recently come across an idea on KDE Brainstorm. [1] The proposal is
> to change the common actions in menus (cut, copy and paste) from text
> lines to icons, like in application toolbars. It is currently the most
> popular idea t
I have recently come across an idea on KDE Brainstorm. [1] The proposal is to
change the common actions in menus (cut, copy and paste) from text lines to
icons, like in application toolbars. It is currently the most popular idea
there.
Someone posted a proof-of-concept example of how this can b
> On 2010-12-13 16:48:31, Ingo Klöcker wrote:
> > How about using vnd.kde.fontspackage instead of x-kde-fontspackage?
>
> Rex Dieter wrote:
> I only used x-kde-fontspackage at aaron's suggestion in one of the
> aforementioned bugs, I'm not attached to it. vnd.kde.fontspackage is fine
> wi
> On 2010-12-13 16:48:31, Ingo Klöcker wrote:
> > How about using vnd.kde.fontspackage instead of x-kde-fontspackage?
>
> Rex Dieter wrote:
> I only used x-kde-fontspackage at aaron's suggestion in one of the
> aforementioned bugs, I'm not attached to it. vnd.kde.fontspackage is fine
> wi
> On 2010-12-13 16:48:31, Ingo Klöcker wrote:
> > How about using vnd.kde.fontspackage instead of x-kde-fontspackage?
I only used x-kde-fontspackage at aaron's suggestion in one of the
aforementioned bugs, I'm not attached to it. vnd.kde.fontspackage is fine with
me too.
- Rex
---
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6111/
---
(Updated 2010-12-13 17:07:48.354415)
Review request for kdelibs.
Changes
-
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6111/#review9232
---
How about using vnd.kde.fontspackage instead of x-kde-fontspackage
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6111/
---
Review request for kdelibs.
Summary
---
This patch adjusts the kde "fak
On Sunday 12 December 2010, Jaroslaw Staniek wrote:
> Hi,
> Any idea why isn't kio/kfile/krecentdirs.h installed?
> I think it's public header?
Indeed, seems like an oversight. Apparently it's the "directory" equivalent to
kio/kfile/krecentdocument.h, which is installed.
Funny that it's the first
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6106/#review9226
---
Ship it!
A new unittest for a string handling method == great!
I
On 10/12/2010 00:44, David Faure wrote:
Yes, this will crash with QT_FATAL_WARNINGS. So? It's good to have a unit
test test border conditions too, even if these conditions lead to
warnings from Qt.
One could try to use QTest::ignoreMessage() [1] to skip expected error
messages.
Does not help.
23 matches
Mail list logo
