Re: More about kdelibs unittests
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. It removes the above QWARN line when running the test normally, but with QT_FATAL_WARNING the call to qWarning will still abort immediately. Wrong layer. Too bad. I like the idea of warn-free unit-tests, but sometimes outputting warning is the correct behavior. Aurélien
Re: Review Request: In System Settings in French the icon's description is badly cut when there is a single quote
--- 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! It's amusing to see that KWordWrap went through all this already (but since it's based on font metrics, the logic is a little bit different) - David On 2010-12-12 18:19:02, Anne-Marie Mahfouf wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6106/ > --- > > (Updated 2010-12-12 18:19:02) > > > Review request for kdelibs. > > > Summary > --- > > Patch to address https://bugs.kde.org/show_bug.cgi?id=257988: in French in > System Settings the icon's description string is badly cut when there is a > single quote. > Unit tests added for the whole method (by Fredrikh) and for the specific > single quote by me. > > Should go in 4.6 so please any kde-core devel review! Thanks > > > Diffs > - > > trunk/KDE/kdelibs/kdecore/tests/kstringhandlertest.h 1205827 > trunk/KDE/kdelibs/kdecore/tests/kstringhandlertest.cpp 1205827 > trunk/KDE/kdelibs/kdecore/text/kstringhandler.cpp 1205827 > > Diff: http://svn.reviewboard.kde.org/r/6106/diff > > > Testing > --- > > Tested in French, fixes the bug. > > > Thanks, > > Anne-Marie > >
Re: kio/kfile/krecentdirs.h
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 time in 10 years that someone needs to use this class outside of kdelibs :-) They both define a class with only static methods, so it should be turned into a namespace. No need to export an default constructor and destructor (implicitly). Please turn krecentdirs.h into a namespace before installing it. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Review Request: Adjust the kde "fake" mimetype fonts/package so desktop-file-utils/shared-mime-info do not complain
--- 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 "fake" mimetype fonts/package so desktop-file-utils/shared-mime-info doesn't complain (using application/x-kde-fontspackage instead). Addresses bugs #235564, #250924 Diffs - /trunk/KDE/kdebase/workspace/kcontrol/kfontinst/apps/kfontview.desktop 1206154 /trunk/KDE/kdelibs/mimetypes/kde.xml 1206154 Diff: http://svn.reviewboard.kde.org/r/6111/diff Testing --- confirmed no warnings/errors from desktop-file-utils/shared-mime-info Thanks, Rex
Re: Review Request: Adjust the kde "fake" mimetype fonts/package so desktop-file-utils/shared-mime-info do not complain
--- 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? - Ingo On 2010-12-13 16:30:38, Rex Dieter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6111/ > --- > > (Updated 2010-12-13 16:30:38) > > > Review request for kdelibs. > > > Summary > --- > > This patch adjusts the kde "fake" mimetype fonts/package so > desktop-file-utils/shared-mime-info doesn't complain (using > application/x-kde-fontspackage instead). Addresses bugs #235564, #250924 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/kcontrol/kfontinst/apps/kfontview.desktop > 1206154 > /trunk/KDE/kdelibs/mimetypes/kde.xml 1206154 > > Diff: http://svn.reviewboard.kde.org/r/6111/diff > > > Testing > --- > > confirmed no warnings/errors from desktop-file-utils/shared-mime-info > > > Thanks, > > Rex > >
Re: Review Request: Adjust the kde "fake" mimetype fonts/package so desktop-file-utils/shared-mime-info do not complain
--- 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 --- s|x-kde-fontspackage|vnd.kde.fontspackage| Summary (updated) --- This patch adjusts the kde "fake" mimetype fonts/package so desktop-file-utils/shared-mime-info doesn't complain (using application/vnd.kde.fontspackage instead). Addresses bugs #235564, #250924 Diffs (updated) - /trunk/KDE/kdebase/workspace/kcontrol/kfontinst/apps/kfontview.desktop 1206154 /trunk/KDE/kdelibs/mimetypes/kde.xml 1206154 Diff: http://svn.reviewboard.kde.org/r/6111/diff Testing --- confirmed no warnings/errors from desktop-file-utils/shared-mime-info Thanks, Rex
Re: Review Request: Adjust the kde "fake" mimetype fonts/package so desktop-file-utils/shared-mime-info do not complain
> 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/#review9232 --- On 2010-12-13 17:07:48, Rex Dieter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6111/ > --- > > (Updated 2010-12-13 17:07:48) > > > Review request for kdelibs. > > > Summary > --- > > This patch adjusts the kde "fake" mimetype fonts/package so > desktop-file-utils/shared-mime-info doesn't complain (using > application/vnd.kde.fontspackage instead). Addresses bugs #235564, #250924 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/kcontrol/kfontinst/apps/kfontview.desktop > 1206154 > /trunk/KDE/kdelibs/mimetypes/kde.xml 1206154 > > Diff: http://svn.reviewboard.kde.org/r/6111/diff > > > Testing > --- > > confirmed no warnings/errors from desktop-file-utils/shared-mime-info > > > Thanks, > > Rex > >
Re: Review Request: Adjust the kde "fake" mimetype fonts/package so desktop-file-utils/shared-mime-info do not complain
> 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 > with me too. > > Christopher Yeleighton wrote: > How about submitting a registration of application/vnd.kde.fontspackage > to IETF first? > vnd.registrations are just "let go". > I could prepare the registration form, but some KDE VIP would have to > sign it. OK (?), I'm not familiar with that, so any assistance would be appreciated. - Rex --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6111/#review9232 --- On 2010-12-13 17:07:48, Rex Dieter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6111/ > --- > > (Updated 2010-12-13 17:07:48) > > > Review request for kdelibs. > > > Summary > --- > > This patch adjusts the kde "fake" mimetype fonts/package so > desktop-file-utils/shared-mime-info doesn't complain (using > application/vnd.kde.fontspackage instead). Addresses bugs #235564, #250924 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/kcontrol/kfontinst/apps/kfontview.desktop > 1206154 > /trunk/KDE/kdelibs/mimetypes/kde.xml 1206154 > > Diff: http://svn.reviewboard.kde.org/r/6111/diff > > > Testing > --- > > confirmed no warnings/errors from desktop-file-utils/shared-mime-info > > > Thanks, > > Rex > >
Re: Review Request: Adjust the kde "fake" mimetype fonts/package so desktop-file-utils/shared-mime-info do not complain
> 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 > with me too. How about submitting a registration of application/vnd.kde.fontspackage to IETF first? vnd.registrations are just "let go". I could prepare the registration form, but some KDE VIP would have to sign it. - Christopher --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6111/#review9232 --- On 2010-12-13 17:07:48, Rex Dieter wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://svn.reviewboard.kde.org/r/6111/ > --- > > (Updated 2010-12-13 17:07:48) > > > Review request for kdelibs. > > > Summary > --- > > This patch adjusts the kde "fake" mimetype fonts/package so > desktop-file-utils/shared-mime-info doesn't complain (using > application/vnd.kde.fontspackage instead). Addresses bugs #235564, #250924 > > > Diffs > - > > /trunk/KDE/kdebase/workspace/kcontrol/kfontinst/apps/kfontview.desktop > 1206154 > /trunk/KDE/kdelibs/mimetypes/kde.xml 1206154 > > Diff: http://svn.reviewboard.kde.org/r/6111/diff > > > Testing > --- > > confirmed no warnings/errors from desktop-file-utils/shared-mime-info > > > Thanks, > > Rex > >
Action icons in menus
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 be achieved, and I used it for Dolphin's popup menu. [2] Code-wise, this change is very simle (5 lines of code at most). Qt can embed custom widgets to menu via the QWidgetAction class, and this class can contain a KToolBar. It has to be done for each application, but there's very little work involved. If the idea is accepted, a convenience method or two would be added to KMenu and/or KStandardAction, so there could be a global settings to fall back to current mode. However, it is a major change for user interaction. So I'd like to start a discussion whether such a change is desired for KDE applications or not. The pros and cons I can think of right now are: Pro: 1. Biger clickable area => less chance of misclicks 2. Icons, when they are intuitively identifiable with an action, can be recognised by humans faster and much easier. I think the above makes it better from a usability standpoint, but as a programmer I wouldn't know much about that. Con: 3. For actions that are not easily identifiable by an icon, this is very bad. This is the reason only some of the actions would be converted to icon display, as you can see from the mockups and screenshots. 4. It looks (a little) like the ribbon UI. I personally believe such a change is a good thing. However, there must be limits. Using it in right-mouse-button menus is one thing, using it in the File menu is another. I would very much like to know how you feel about this. Thank you, Miha Čančula [1]: http://forum.kde.org/brainstorm.php?mode=idea&i=89969#anchormain [2]: http://www.flickr.com/photos/noughmad/sets/72157625584527238/ signature.asc Description: This is a digitally signed message part.
Re: Action icons in menus
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 there. > > Someone posted a proof-of-concept example of how this can be achieved, and > I used it for Dolphin's popup menu. [2] Code-wise, this change is very > simle (5 lines of code at most). Qt can embed custom widgets to menu via > the QWidgetAction class, and this class can contain a KToolBar. It has to > be done for each application, but there's very little work involved. If > the idea is accepted, a convenience method or two would be added to KMenu > and/or KStandardAction, so there could be a global settings to fall back > to current mode. Does this break keyboard navigation in the menu? > However, it is a major change for user interaction. So I'd like to start a > discussion whether such a change is desired for KDE applications or not. > The pros and cons I can think of right now are: Pro: > 1. Biger clickable area => less chance of misclicks > 2. Icons, when they are intuitively identifiable with an action, can be > recognised by humans faster and much easier. I think the above makes it > better from a usability standpoint, but as a programmer I wouldn't know > much about that. > > Con: > 3. For actions that are not easily identifiable by an icon, this is very > bad. This is the reason only some of the actions would be converted to > icon display, as you can see from the mockups and screenshots. 4. It looks > (a little) like the ribbon UI. 5. There is no space to show the shortcut (i.e. Ctrl+C for Copy) Albert > > I personally believe such a change is a good thing. However, there must be > limits. Using it in right-mouse-button menus is one thing, using it in the > File menu is another. I would very much like to know how you feel about > this. > > Thank you, > Miha Čančula > > [1]: http://forum.kde.org/brainstorm.php?mode=idea&i=89969#anchormain > [2]: http://www.flickr.com/photos/noughmad/sets/72157625584527238/
Re: Action icons in menus
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.asc Description: This is a digitally signed message part.
Re: Action icons in menus
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 keyboard, even thought other actions in the same > menu are. That's a no-go if you ask me. Albert
Re: Action icons in menus
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 displayed this way > > are not selectable by keyboard, even thought other actions in the same > > menu are. > > That's a no-go if you ask me. Well, it is a menu which pops up with mouse-clicks... Anyway, I'll try to see if support for that can be added by reimplementing some event handlers. Until then, thanks for pointing me to the problem :S -- Lenoba je mati Modrosti.
Re: Action icons in menus
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 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. > > > > That's a no-go if you ask me. > > Well, it is a menu which pops up with mouse-clicks... My keyboard has a nice "context menu" key between AltGr and Ctrl that pops the context menu in Dolphin, so no, it's not something that pops up with mouse clicks only ;-) Albert > Anyway, I'll try to see if support for that can be added by reimplementing > some event handlers. Until then, thanks for pointing me to the problem :S
Re: Action icons in menus
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? >> > >> > 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. >> >> That's a no-go if you ask me. > > Well, it is a menu which pops up with mouse-clicks... 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
Re: Action icons in menus
> 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.
Re: Action icons in menus
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. > 2. Icons, when they are intuitively identifiable with an action, can be > recognised by humans faster and much easier. the context menus already have icons in them for these kinds of actions. > Con: > 3. For actions that are not easily identifiable by an icon, this is very > bad. This is the reason only some of the actions would be converted to > icon display, as you can see from the mockups and screenshots. which means inconsistency: some entires one way, other entries another. it means having to scan visually in two different directions which slows usage down considerably. the loss of vertical alignment, particularly when in the middle of a menu, looks very noisy and unfortunate. i'd go so far as to say "ugly". > 4. It looks (a little) like the ribbon UI. a non-issue. unless there is some sound reasoning showing why this is a beneficial change, i have to say this looks like a "cool change because we can" type thing. menus are hardly a massive usability "problem" as people use them without much fuss. it may make more sense to focus on issues that are actually problematic for people? -- 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.
Re: Action icons in menus
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 > just how many misclicks actually happen using both UI styles. > >> 2. Icons, when they are intuitively identifiable with an action, can be >> recognised by humans faster and much easier. > > the context menus already have icons in them for these kinds of actions. > >> Con: >> 3. For actions that are not easily identifiable by an icon, this is very >> bad. This is the reason only some of the actions would be converted to >> icon display, as you can see from the mockups and screenshots. > > which means inconsistency: some entires one way, other entries another. > > it means having to scan visually in two different directions which slows usage > down considerably. > > the loss of vertical alignment, particularly when in the middle of a menu, > looks very noisy and unfortunate. i'd go so far as to say "ugly". > >> 4. It looks (a little) like the ribbon UI. > > a non-issue. > > unless there is some sound reasoning showing why this is a beneficial change, > i have to say this looks like a "cool change because we can" type thing. menus > are hardly a massive usability "problem" as people use them without much fuss. > it may make more sense to focus on issues that are actually problematic for > people? > > -- > 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 > I think this actually has some interesting potential if handled right. If common actions were all handled in this way, then it might actually lead to more consistancy, and ease of access. Actions are not particuallarly consistant across applications, and so it becomes necessary to read the entire list to find the item you are looking for. If cut/copy/paste were always found as icons at the top of the menu in applications that support them, it would probably lead to accessing them quicker. Of course, I'm not sure how many people would do this vs. the shortcuts that are also well known, but if this was done for other actions as well, perhaps it would be beneficial? The icons should probably always be at the top of the menu, to add that consistancy, and I'm not sure if there are enough actions out there to merit the additional code path, but I think that this might actually be able to develop into something unique and useful. Dan,
Re: Action icons in menus
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 dbusmenu; so it can't find its way easily into the system tray icon menus, for instance) > and ease of access. i still have reservations about this given the introduction of a second axis of freedom within the menu. > Actions are > not particuallarly consistant across applications, and so it becomes > necessary to read the entire list to find the item you are looking > for. If cut/copy/paste were always found as icons at the top of the > menu in applications that support them, it would probably lead to > accessing them quicker. if they were always in the same place in the menu, regardless of presentation, it would help. the questions that remain would be: * are they important enough to always be at the top of the menu in all applications? if not, which applications / use cases does it make sense to do so? * what is the actual amount of time / effort spent locating these items in menus as it stands now? > Of course, I'm not sure how many people would > do this vs. the shortcuts that are also well known, but if this was > done for other actions as well, perhaps it would be beneficial? The putting the most common actions at the top of the menu is useful regardless of layout. > icons should probably always be at the top of the menu, to add that > consistancy, and I'm not sure if there are enough actions out there to > merit the additional code path, but I think that this might actually > be able to develop into something unique and useful. i'm happy to change my mind in the presence of compelling demonstrations :) -- 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.
Re: Action icons in menus
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.
Re: Action icons in menus
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 items. It may work for three items like Cut, Copy, Paste and maybe even four (New, Open, Save, Save As) but six? Markus
kdebase-workspace and kdebase-runtime git repos to validate
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/ianmonroe/kdebase-workspace.git http://gitweb.kde.org/scratch/ianmonroe/kdebase-runtime.git I've checked all the subdirectories and they appear to have a decent history. One exception is some of the Solid modules which seemed to have an early identity crisis. :) Check it out and let me know if this is a concern and with help of people who know its history we could fix it up. kdelibs is the same one I emailed kcd a while ago: http://gitweb.kde.org/scratch/ianmonroe/kdelibs-test.git For 'master' the history is appears fairly complete, some directories go back in time further then SVN log did even. The branches (especially the early CVS ones) are a bit confused, this is a work-in-progress. cvs2svn has some known issues I think, but we'll do our best. The only repo I have left to start is kdebase-apps. Thanks for any feedback you have, Ian Monroe
