Willy De la Court | 1 Apr 01:14 2003
Picon

Is this still binary compatible?


Index: configinterfaceextension.h
===================================================================
RCS file: 
/home/kde/kdelibs/interfaces/ktexteditor/configinterfaceextension.h,v
retrieving revision 1.16
diff -u -p -r1.16 configinterfaceextension.h
--- configinterfaceextension.h  3 Mar 2003 21:11:02 -0000       1.16
+++ configinterfaceextension.h  31 Mar 2003 23:11:49 -0000
 <at>  <at>  -37,6 +37,18  <at>  <at>  class ConfigPage : public QWidget
   //
   // slots !!!
   //
+  slots:
+    /**
+      Called when something changes
+    */
+    void slotChanged();
+
+  signals:
+    /**
+      Emitted when something changes
+    */
+    void changed();
+
   public:
     /**
       Applies the changes to all documents

--

-- 
(Continue reading)

Dirk Mueller | 1 Apr 01:22 2003
Picon

Re: Is this still binary compatible?

On Die, 01 Apr 2003, Willy De la Court wrote:

Answer the question yourself: 

http://developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binarycompatibility.html

--

-- 
Dirk

Willy De la Court | 1 Apr 01:38 2003
Picon

Re: Is this still binary compatible?


On Tuesday 01 April 2003 01:22, Dirk Mueller wrote:
> On Die, 01 Apr 2003, Willy De la Court wrote:
>
> Answer the question yourself:
>
> http://developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binaryc
>ompatibility.html
Yeah i read that three times

the thing about the order bugs me say i have this

virtual a
virtual b

and i change it to 
virtual a
void c
virtual b

does this alter the order of the virtual functions?
Well they are in the same order still.
Should i just add the new stuff to the end instead of somewhere in the middle?

--

-- 
Simple things make people happy.
Willy De la Court
PGP Public Key at http://www.linux-lovers.be/download/public_key.asc
PGP Key fingerprint = 784E E18F 7F85 9C7C AC1A D5FB FE08 686C 37C7 A689
(Continue reading)

Dirk Mueller | 1 Apr 03:24 2003
Picon

Re: Is this still binary compatible?

On Die, 01 Apr 2003, Willy De la Court wrote:

> does this alter the order of the virtual functions?

No. 

> Should i just add the new stuff to the end instead of somewhere in the middle?

It breaks BIC to reorder virtual methods, yes. 

However, nothing in your initial patch was virtual, so there is no problem. 

--

-- 
Dirk

Willy De la Court | 1 Apr 12:40 2003
Picon

Re: Is this still binary compatible?


On Tuesday 01 April 2003 03:24, Dirk Mueller wrote:
> On Die, 01 Apr 2003, Willy De la Court wrote:
> > does this alter the order of the virtual functions?
>
> No.
>
> > Should i just add the new stuff to the end instead of somewhere in the
> > middle?
>
> It breaks BIC to reorder virtual methods, yes.
>
> However, nothing in your initial patch was virtual, so there is no problem.

Thanks for the clarification Dirk.

--

-- 
Simple things make people happy.
Willy De la Court
PGP Public Key at http://www.linux-lovers.be/download/public_key.asc
PGP Key fingerprint = 784E E18F 7F85 9C7C AC1A D5FB FE08 686C 37C7 A689
Lubos Lunak | 1 Apr 15:36 2003
Picon

Re: Pressing and releasing the Win-key opens the K-Menu

On Monday 31 of March 2003 10:24, Ellis Whitehead wrote:
> Hi all,
>
> I just committed a patch to kdebase/kicker/buttons/kbutton.*, which opens
> the K-Menu when the Win-key is pressed and released with no intervening
> keys.  It will only work if the Win-keys are assigned Super_L and/or
> Super_R, as is standard in XFree 4.x -- the old Meta assignments won't
> trigger it.  If anyone has problems or suggestions, please let me know.

 Start KMenuEdit, assign Meta+H to 'Home' entry, apply.
#1: Press Meta+H -> nothing happens.
#2: Even if it worked, I bet I'd get both Konqueror showing my $HOME dir and 
Kicker showing the K-Menu.
#3: Press Meta and repeatedly hit H - Konqy will be started (random number of 
times < number of times H was pressed ? )
#4: It doesn't work with NumLock pressed.

 Some of them could be fixed, but let's go directly to the worst one: #1 
doesn't work simply since the grab for Meta+H is ignored, because Kicker has 
the keyboard grabbed as soon as Meta is pressed. XSendEvent() won't trigger 
the Meta+H grab. I'm aware of only two ways of try to make this work:

- using XAllowEvents() with ReplayKeyboard right after receiving KeyPress - 
but I'm afraid you then won't get the KeyRelease event, so this actually 
won't work

- using XTestFakeKeyPress() instead of XSendEvent(), which could work, since 
it will trigger the Meta+H grab. However, that's probably one of those things 
that people only try to code when they feel like solving complicated problems 
that have many wrong solutions and it's not sure if there's a proper one.
(Continue reading)

Willy De la Court | 1 Apr 15:51 2003
Picon

[PATCH] kdelibs/kate kdebase/kate UI Inconsistency OK APPLY buttons


Patch comments
------------------------------------------------------
UI Inconsistency OK APPLY buttons
Apply diabled when nothing is changed
Ok only saves when something is changed
------------------------------------------------------

I'll wait 2 days for comments on this before commiting.

--

-- 
Simple things make people happy.
Willy De la Court
PGP Public Key at http://www.linux-lovers.be/download/public_key.asc
PGP Key fingerprint = 784E E18F 7F85 9C7C AC1A D5FB FE08 686C 37C7 A689
Waldo Bastian | 1 Apr 16:30 2003
Picon

Re: terrible bug (feature?) in KdialogBase

Ugh, that's nasty. Does the attached patch help?

Cheers,
Waldo

On Tuesday 01 April 2003 16:02, Joerg Anders wrote:
> Hi all!
>
> There seems to be a terrible bug (or is it a feature ?) in KdialogBase
> in KDE-3.1.1. This crahes all my programs. (And I'm convinced
> many others, too)
>
> Have a look at:
>
> http://rnvs.informatik.tu-chemnitz.de/kdialogtest/kdialogtest.html
>
> There you find a short test program and a Makefile. The central code is:
>
>
> class MyDialogBase  : public KDialogBase {
> 	public:
> 		MyDialogBase(QWidget *parent, char *name) :
> 		 KDialogBase(Tabbed, ...) {
> 			addHBoxPage(QString("hbox1"), QString::null);
> 			addHBoxPage(QString("hbox2"), QString::null);
> 			addHBoxPage(QString("hbox2"), QString::null);
> 			addHBoxPage(QString("hbox3"), QString::null);
> 			addHBoxPage(QString("hbox5"), QString::null);
> 			showPage(0);
> 			setGeometry(10, 10, 200, 200);
(Continue reading)

david mattatall | 1 Apr 12:37 2003

Re: Pressing and releasing the Win-key opens the K-Menu

On March 31, 2003 01:14 pm, Ellis Whitehead wrote:
> One of the problems is that keyboards with extended keys are rarely
> configured with the correct X keyboard map, and so the keys can't even be
> properly addressed...  Assuming the right map is being used, however, it
> would be good to get a convenient interface for assigning the extended keys
> to execute specific actions.  I've been thinking about how to do this for
> the last few days.  If you have any suggestions, let me know. ;)
>
> Regards,
> Ellis

Maybe all we need is a good KDE-Front End to XKB? Is there even an existing 
front end to XKB?

--

-- 
*-_-_-_-_-_-_-_-_-_-_-_-_-_-*
AIM: StabbyMcforehead
ICQ: 73080754
Yahoo: davidsmind
Jabber: davidsmind

Email: davidsmind at linuxbasics dot com
Weblog: http://davidsmind.diaryland.com

Scott Wheeler | 1 Apr 19:35 2003
Picon

[patch] QListView keys

The column priority for QListView seems rather odd with respect to hotkeys.

There are a few scenarios that don't really make sense:

(1) If I have explicitly chosen to sort by a given column, it seems that the 
key pressed should jump to items starting with that letter in that column.

I got a bug report on this in JuK today -- basically if someone is sorting by 
the artist column, pressing "A" shouldn't jump to track names that start with 
"A".

(2) This always uses "column zero" rather than the leftmost column.  This also 
seems flawed.  Of course by default the column zero is the leftmost column.  
But since QListView allows you to reorder the columns, it seems like in an 
unsorted QListView that it should default to the leftmost column.

Also I found a Windows box to try these on.  (1) is done on Windows and I 
couldn't find a good test case for (2) (a multicolumn unsorted list).  Since 
(1) is hard-coded into the source, I presume that this is a bug.

It might be nice to have a couple of methods to set / retrieve which column 
keyboard hotkeys go to, but I'll stop pushing my luck...  :-)

Anyway, if there are no objections I'd like to commit this to qt-copy.

Cheers,

-Scott
--

-- 
The first principle is that you must not fool yourself and you are the easiest 
(Continue reading)


Gmane