Re: [PyKDE] The tablet event, it works not!

2004-10-15 Thread Kaleb Pederson
On Thursday 14 October 2004 5:51 am, Sundance wrote:
> I can. All of them are recognized alright: pointer, stylus, eraser.
> Additionally, the pointer is in relative mode and the others in
> absolute mode -- which is not the case when X is using the tablet with
> a -mouse- driver. I really, really triplechecked this, you know. :)

Sounds like they function alright.

> > Nothing special is required, just the catching of the tabletEvent
> > signal.
> >
> > I'll let you know what I find.

My new kernel works.  Your program worked just fine with my Tablet as did my 
old test program (I would have given it to you as well, but I wasn't sure 
what state I had left it in).  I'm using sip 4.1.1, PyQt 3.13 and Qt 3.3.3.  
There must be something else awry :(

> I'm beginning to suspect a Qt bug. I ported my example to C++, and it
> doesn't work either. I re-re-rechecked my Qt compilation log and tablet
> support is definitely turned on.

I'm not sure what you would check off the top of my head.  You can always 
modify the Qt code with something obvious to find out if it has support for 
the tablet.  Check the #ifdef's etc.

> Could it be that Qt didn't compile tablet support even though the
> configure script claims it did? If so, how can I check?

I suppose it's possible.  What version of Qt are you running?  If you want, I 
can test your C++ program as well, but chances are your python one will work 
just fine once you figure out what's going on.

--Kaleb


> -- S.
>
> ___
> PyKDE mailing list[EMAIL PROTECTED]
> http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


pgph08Mdve2Sa.pgp
Description: PGP signature
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[PyKDE] default font used by eric?

2004-10-15 Thread Alan Ezust
Just curious -e very time I install eric3, I forget how I changed the font 
used for the actual sourcecode. I find the line number font right away, and 
also the "monospaced font" but it doesn't seem to affect the sourcecode.

I also tried changing the default font in qtconfig. No effect.

Shouldn't the default font be the one specified in qtconfig?

using 3.4.2 under gnu/linux.

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Need User Input

2004-10-15 Thread Jim Bublitz
On Friday 15 October 2004 11:10, Jim Bublitz wrote:
> Roberto Alsina pointed out to me that some distributions identify
> themselves in /etc/*release files. For example, on my system I have
> /etc/SuSE-release and /etc/lsb-release files.
>
> Could a few people check and see if other distributions do the same, and
> which of the files are present?
>
> Specifically, I need the name of any /etc/*release files on your system,
> and if /etc/lsb-release is present, if it includes the name and version of
> the distribution being used.

Thanks for the quick response!

Looks like it should be workable (I don't think Debian will be a problem).

If anyone has Slackware installed, that's the only major distro I haven't 
heard from yet (and Slackware, like all the others has some minor 
differences).

Jim

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Need User Input

2004-10-15 Thread Torsten Marek
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Bublitz schrieb:
| Roberto Alsina pointed out to me that some distributions identify themselves
| in /etc/*release files. For example, on my system I have /etc/SuSE-release
| and /etc/lsb-release files.
|
| Could a few people check and see if other distributions do the same, and which
| of the files are present?
|
| Specifically, I need the name of any /etc/*release files on your system, and
| if /etc/lsb-release is present, if it includes the name and version of the
| distribution being used.
|
For Debian, this is /etc/debian_version. If the package lsb-release is
installed, /etc/lsb-release is also present, but as far as I know, lsb-release
is not a base package.
greetings
Torsten
- --
Torsten Marek <[EMAIL PROTECTED]>
ID: A244C858 -- FP: 1902 0002 5DFC 856B F146  894C 7CC5 451E A244 C858
Keyserver: subkeys.pgp.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBcCz8fMVFHqJEyFgRAocUAJ49LQTFFIJY3xiico1gdN4Z1DtnNACfQ5Q/
z84xBH+FVQpxRcZ3H++W8RQ=
=pqvx
-END PGP SIGNATURE-
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyKDE

2004-10-15 Thread gerard . vermeulen
On Fri, 15 Oct 2004 11:27:44 -0700, Jim Bublitz wrote
> On Friday 15 October 2004 10:48, [EMAIL PROTECTED] wrote:
> 
> > Sorry, Jim. I was too fast with finger pointing. A look in the Mandrake
> > patches for KDE-3.2.3 confirms that Mandrake changed the API of their
> > header files.
> 
> > It comes as a shock to me that a distribution can change the API that
> > much (it is a pain for developers and PyKDE must catch them all).
> 
> No problem - it always surprises me when distributors make changes. 
> I suspect it comes from trying to stay on top of the latest KDE 
> release, because most of the problems look like leftovers from 
> earlier (probably beta) releases rather than things that actually 
> need to be changed to make KDE functional.
> 
> > Maybe it is possible to make a tool which parses the g++ compiler errors
> > and suggest possible fixes, mails the fixes to you and/or some public
> > repository *and* the guilty Linux distributor :-).
> > Nowadays the compiler errors are so clear that I could suggest the fix by
> > looking at the sip file in question (without seeing the header file).
> > So, it looks possible to catch most of those unofficial API changes
> > automatically.
> 
> The fixes are usually pretty simple. Roberto Alsina pointed out that 
> at least some distros include an /etc/*release file (eg I have 
> /etc/SuSE-release on this system). I can use that to tailor a 
> version with configure.py if it's present on enough distributions.
> 
> To answer my own question about how to implement this: I think 
> enough people use PyKDE for "personal" applications that it makes 
> sense to make all usable features available. That would mean (in the 
> case in this thread), that setFileName would be available to 
> everyone except Mandrake users. People who write applications for 

Agreed, of course.  But if users can keep distributions from
making such changes, we would not spent hours on workarounds :-)
(distro's crank out new releases too fast)

> more general use would need to be aware that setFileName isn't 
> available on Mandrake, but that's no different than what a C++ 
> programmer would have to do in the current situation.
> 
> The philosophy behind PyKDE has always been to make as much of KDE 
> available as is reasonably possible and I'd like to continue that.
> 
> Once again, I'm not picking on Mandrake - similar things happen on 
> every distribution.
> 
No problem. I like Mandrake very much, because of the way they
interact with their community, but on some of my systems I run
SuSE, because SuSE's kernels are more stable.

Anyhow, this Mandrake has:
[EMAIL PROTECTED] packer]$ cat /etc/mandrake-release
Mandrake Linux release 10.0 (Official) for i586
[EMAIL PROTECTED] packer]$ cat /etc/redhat-release
Mandrake Linux release 10.0 (Official) for i586

All Mandrake's I know have also an /etc/redhat-release

Gerard

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[PyKDE] Realistic PyKDE release dates

2004-10-15 Thread Jim Bublitz
There are enough bug fixes piling up that PyKDE deserves another release or at 
least snapshot. Unfortunately, I'm back in a situation where I've got a big 
backlog of other things I have to do first. On top of that, there's an 
election here Nov 2, and things related to that (like major anxiety) have 
been consuming some time too. Time management is not one of my strengths.

I'd still like to get PyKDE back on track in the next couple of weeks, but 
realistically it may be more like 4 or 5 weeks before that happens.

Sorry.

Jim

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyKDE

2004-10-15 Thread Jim Bublitz
On Friday 15 October 2004 10:48, [EMAIL PROTECTED] wrote:

> Sorry, Jim. I was too fast with finger pointing. A look in the Mandrake
> patches for KDE-3.2.3 confirms that Mandrake changed the API of their
> header files.

> It comes as a shock to me that a distribution can change the API that
> much (it is a pain for developers and PyKDE must catch them all).

No problem - it always surprises me when distributors make changes. I suspect 
it comes from trying to stay on top of the latest KDE release, because most 
of the problems look like leftovers from earlier (probably beta) releases 
rather than things that actually need to be changed to make KDE functional.

> Maybe it is possible to make a tool which parses the g++ compiler errors
> and suggest possible fixes, mails the fixes to you and/or some public
> repository *and* the guilty Linux distributor :-).
> Nowadays the compiler errors are so clear that I could suggest the fix by
> looking at the sip file in question (without seeing the header file).
> So, it looks possible to catch most of those unofficial API changes
> automatically.

The fixes are usually pretty simple. Roberto Alsina pointed out that at least 
some distros include an /etc/*release file (eg I have /etc/SuSE-release on 
this system). I can use that to tailor a version with configure.py if it's 
present on enough distributions.

To answer my own question about how to implement this: I think enough people 
use PyKDE for "personal" applications that it makes sense to make all usable 
features available. That would mean (in the case in this thread), that 
setFileName would be available to everyone except Mandrake users. People who 
write applications for more general use would need to be aware that 
setFileName isn't available on Mandrake, but that's no different than what a 
C++ programmer would have to do in the current situation.

The philosophy behind PyKDE has always been to make as much of KDE available 
as is reasonably possible and I'd like to continue that.

Once again, I'm not picking on Mandrake - similar things happen on every 
distribution.

Jim

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[PyKDE] Need User Input

2004-10-15 Thread Jim Bublitz
Roberto Alsina pointed out to me that some distributions identify themselves 
in /etc/*release files. For example, on my system I have /etc/SuSE-release 
and /etc/lsb-release files.

Could a few people check and see if other distributions do the same, and which 
of the files are present?

Specifically, I need the name of any /etc/*release files on your system, and 
if /etc/lsb-release is present, if it includes the name and version of the 
distribution being used.

Thanks.

Jim

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyKDE

2004-10-15 Thread gerard . vermeulen
On Fri, 15 Oct 2004 10:10:13 -0700, Jim Bublitz wrote
> On Friday 15 October 2004 00:00, Gerard Vermeulen wrote:
> 
> > > >Comment out (put // in front of) void setFileName in the lines
> > > >
> > > >%If (  - KDE_3_3_0 )
> > > > KCatalogue (const QString& = QString ::null );
> > > >void setFileName (const QString&);
> > > >%End
> > > >
> > > >
> > > >};  // class KCatalogue
> > > >
> > > >of the file
> > > >
> > > >sip/kdecore/kcatalogue.sip lines 23-60/60 (END)
> > > >
> > > >Wipe out features, run python configure.py, run make
> > >
> > > It's going :)
> > >
> > > Since I don't understand what's going on... can you please tell me if
> > > this a PyKDE bug or a mandrake one? (if I post a bug to mandrake
> > > cooker's list I will post both)
> 
> > > Thanks again,
> 
> > I think it is a PyKDE bug.  The sip file declares setFileName as public
> > while it has been declared private in the KDE header files (the sip
> > file should match the header file).
> 
> > Mandrake would never change such a standard header file.
> 
> Sorry, but the distribution guys, including Mandrake, do make 
> occasional changes to standard header files, and those changes break 
> PyKDE and sometimes PyQt.
>
Sorry, Jim. I was too fast with finger pointing. A look in the Mandrake
patches for KDE-3.2.3 confirms that Mandrake changed the API of their
header files.

It comes as a shock to me that a distribution can change the API that
much (it is a pain for developers and PyKDE must catch them all).

Mauro, you know what to do :-)
> 
> In this particular case, setFileName is declared public in the h 
> file I used to generate PyKDE. I get my h files from kde.org most 
> often, or occasionally a kde.org mirror. That would indicate to me 
> it's a change in Mandrake. I can point to similar problems in the 
> past with RH or SuSE.
> 
> It's also quite possible that the Mandrake h files don't agree with 
> the compiled libs (ie - this method might be public in libkdecore on 
> Mandrake). I don't know that that's the case, but that kind of thing 
> happens too.
> 
> As far as a solution to this kind of problem, I don't know of any 
> reliable way to detect the distribution being used (any suggestions 
> welcome). The other alternative is to provide a "distribution" 
> switch for building PyKDE, but the success of that depends on a) 
> users actually using it and b) me being aware of problems like this 
> ahead of time.
> 
> The other alternative is to provide a "least common denominator" 
> PyKDE. In this case, that means anyone wanting to use KCatalogue 
> would not have access to the setFileName method because of the error 
> in the Mandrake h file. I don't know if that's a big deal or not.  I 
> don't like it as a policy, but that would also be necessary to allow 
> PyKDE-based apps to run on any platform.
> 
> I'd be interested in people's input about how to handle this kind of 
> thing.
>
Maybe it is possible to make a tool which parses the g++ compiler errors
and suggest possible fixes, mails the fixes to you and/or some public
repository *and* the guilty Linux distributor :-).
Nowadays the compiler errors are so clear that I could suggest the fix by
looking at the sip file in question (without seeing the header file).
So, it looks possible to catch most of those unofficial API changes
automatically.

Gerard

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyKDE

2004-10-15 Thread Jim Bublitz
On Friday 15 October 2004 00:36, Maurizio Colucci wrote:
> Gerard Vermeulen wrote:
> >>>Comment out (put // in front of) void setFileName in the lines
> >>>
> >>>%If (  - KDE_3_3_0 )
> >>>KCatalogue (const QString& = QString ::null );
> >>>   void setFileName (const QString&);
> >>>%End
> >>>
> >>>
> >>>of the file
> >>>
> >>>sip/kdecore/kcatalogue.sip lines 23-60/60 (END)
> >>>
> >>>Wipe out features, run python configure.py, run make
> >>
> >>It's going :)
> >>
> >>Since I don't understand what's going on... can you please tell me if
> >>this a PyKDE bug or a mandrake one? (if I post a bug to mandrake
> >>cooker's list I will post both)
> >>
> >>Thanks again,
> >
> >I think it is a PyKDE bug.  The sip file declares setFileName as public
> >while it has been declared private in the KDE header files (the sip
> >file should match the header file).
> >
> >Mandrake would never change such a standard header file.
>
> Phil? Jim? Are you aware of this problem?

Phil doesn't do anything directly on PyKDE (obviously without Phil there 
wouldn't be any PyKDE though).

I'm aware of it now, but I'm not sure how to handle this type of problem, 
which is a Mandrake problem and not a PyKDE problem.

See my reply to Gerard earlier in the thread.

Jim

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyKDE

2004-10-15 Thread Jim Bublitz
On Friday 15 October 2004 00:00, Gerard Vermeulen wrote:

> > >Comment out (put // in front of) void setFileName in the lines
> > >
> > >%If (  - KDE_3_3_0 )
> > > KCatalogue (const QString& = QString ::null );
> > >void setFileName (const QString&);
> > >%End
> > >
> > >
> > >};  // class KCatalogue
> > >
> > >of the file
> > >
> > >sip/kdecore/kcatalogue.sip lines 23-60/60 (END)
> > >
> > >Wipe out features, run python configure.py, run make
> >
> > It's going :)
> >
> > Since I don't understand what's going on... can you please tell me if
> > this a PyKDE bug or a mandrake one? (if I post a bug to mandrake
> > cooker's list I will post both)

> > Thanks again,

> I think it is a PyKDE bug.  The sip file declares setFileName as public
> while it has been declared private in the KDE header files (the sip
> file should match the header file).

> Mandrake would never change such a standard header file.

Sorry, but the distribution guys, including Mandrake, do make occasional 
changes to standard header files, and those changes break PyKDE and sometimes 
PyQt.

In this particular case, setFileName is declared public in the h file I used 
to generate PyKDE. I get my h files from kde.org most often, or occasionally 
a kde.org mirror. That would indicate to me it's a change in Mandrake. I can 
point to similar problems in the past with RH or SuSE. 

It's also quite possible that the Mandrake h files don't agree with the 
compiled libs (ie - this method might be public in libkdecore on Mandrake). I 
don't know that that's the case, but that kind of thing happens too.

As far as a solution to this kind of problem, I don't know of any reliable way 
to detect the distribution being used (any suggestions welcome). The other 
alternative is to provide a "distribution" switch for building PyKDE, but the 
success of that depends on a) users actually using it and b) me being aware 
of problems like this ahead of time.

The other alternative is to provide a "least common denominator" PyKDE. In 
this case, that means anyone wanting to use KCatalogue would not have access 
to the setFileName method because of the error in the Mandrake h file. I 
don't know if that's a big deal or not.  I don't like it as a policy, but 
that would also be necessary to allow PyKDE-based apps to run on any 
platform.

I'd be interested in people's input about how to handle this kind of thing.

Jim

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] more complex rich text / HTML

2004-10-15 Thread David Boddie
On Fri, 15 Oct 2004 01:36:23, Andrew Dalke wrote: 
 
>My crazy thought is to embed a native HTML widget for 
>the different platforms, so that I use IE to display 
>under MS Windows, Safari for Mac, and Konqueror for Linux. 
>(That's all I need to support.) 
> 
>While the last is definitely possible, I can't find 
>an example of embedding IE nor even a hint that this 
>might be possible on Mac OS X. 
 
As others have suggested, using a KHTML widget might be easier than trying 
to embed Konqueror (which itself uses a KHTML part to display HTML). 
 
On Windows, you might be able to use the Qt's Active X facilities to 
embed IE, and you might get quite far on the Mac by using the QXEmbed 
class from PyKDE's kdeui module. 
 
The PyKDE distribution includes example code for both KHTML and QXEmbed, 
so it shouldn't be too hard to get something working on Linux and Mac OS X. 
Either way, you'll probably need PyKDE on those platforms. 
 
Ask again if you need more help, and let us all know how you get on. 
 
David 


___
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Suggestions for 3.6 :)

2004-10-15 Thread Gordon Tyler
Jul wrote:
As you greatly implemented the bash lexer, it would be nice
to have an optional integrated shell console (standard one)
as the Python console. If not too hard...
It might be interesting to use IPython for the Python console since it 
can do shell commands as well as Python.

Ciao,
Gordon
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[PyKDE] Suggestions for 3.6 :)

2004-10-15 Thread Jul
Hi,
A suggestion concerning file encoding.
As 'kate' editor does, it whould be great to be able to
choose the current file encoding. I usually work with UTF8
files, but I often have to edit west-european ('latin1')
encoded files which are oddly displayed. I have no way to
display them correctly when eric doesn't reconize them.
In the Preferences, encoding configuration only appears in
Python's configuration dialog, and I'm not sure to
understand on what it is applied (Python current sheet?
Python Shell? both?). 

Well another suggsetion...
As you greatly implemented the bash lexer, it would be nice
to have an optional integrated shell console (standard one)
as the Python console. If not too hard...

Best regards,
++
Jul.

 ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT 
 
Surfez 40 fois plus vite pour 30EUR/mois seulement !  Et téléphonez partout en France 
gratuitement,  
vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles 
et l'international !
Pour profiter de cette offre exceptionnelle, cliquez ici : 
http://register.tiscali.fr/adsl  (voir conditions sur le site)


___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyQt 3.13

2004-10-15 Thread Maurizio Colucci
Simon Edwards wrote:
On Thursday 14 October 2004 20:39, Maurizio Colucci wrote:
 

Hello,
I am trying to install PyQt (and PyKDE, hopefully) on mandrake 10.1 
community (since sadly there are no RPM packages available).
   

Sorry, I meant "no PyKDE RPMs available".
Try the RPMs for Mandrake 10 at 
http://sourceforge.net/project/showfiles.php?group_id=61057

 

Thank you Simon. Actually that's the first thing I tried, but there's no 
qscintilla there. So the rpms won't install. (and the qscintilla rpm in 
mandrake contrib is not compatible with those rpms)

Then I tried the packages in mandrake contrib: this way I could install 
qscintilla, sip and PyQt, but there was no PyKDE. So I tried compiling 
it, but I got a compilation error (which Gerard told me to be a PyKDE 
bug). I wrongly assumed the problem was in PyQt, so I installed 
everything by source; and here I am.

Please fix the PyKDE bug :)
Maurizio
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyQt 3.13

2004-10-15 Thread Simon Edwards
On Thursday 14 October 2004 20:39, Maurizio Colucci wrote:
> Hello,
> 
> I am trying to install PyQt (and PyKDE, hopefully) on mandrake 10.1 
> community (since sadly there are no RPM packages available).

Try the RPMs for Mandrake 10 at 
http://sourceforge.net/project/showfiles.php?group_id=61057

-- 
Simon Edwards             | Guarddog Firewall
[EMAIL PROTECTED]       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] more complex rich text / HTML

2004-10-15 Thread Hans-Peter Jansen
On Friday 15 October 2004 10:45, Paul Edgington wrote:
>
> One option then would be to try and port khtml to pure Qt so it
> would work on windows and then probably modify the khtml python
> wrapper to match. Not only would it be a possible solution to your
> problem but would make a lot of other people (include myself) happy
> as this is exactly the sort of thing I may well need for a work
> project next year.

Maybe it is of some interest on this topic, that "aKademy Hackers Port 
Mozilla to Qt/KDE": http://dot.kde.org/1094924433/

Pete

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


RE: [PyKDE] more complex rich text / HTML

2004-10-15 Thread Paul Edgington
> I'm writing an app and want one of the widgets to look
> like a HTML display, with support for buttons, check
> boxes, different fonts, and hyperlinks.
> 
> Qt's rich text browser isn't powerful enough.  It doesn't
> let me put controls in its qt rich text language nor
> even let me change the background color of parts of text.
> 
> I played around with the idea of implementing a flow-based
> layout system myself and have something of a hack working,
> enough to figure out that the rest will take me at least
> another week.
> 
> And probably another couple weeks or more if I want it to
> support font scaling, text selection, bidirectional text,
> stylesheets ... okay, more like a month or more.
> 
> Does anyone have any suggestions?
> 
> My crazy thought is to embed a native HTML widget for
> the different platforms, so that I use IE to display
> under MS Windows, Safari for Mac, and Konqueror for Linux.
> (That's all I need to support.)
> 
> While the last is definitely possible, I can't find
> an example of embedding IE nor even a hint that this
> might be possible on Mac OS X.

khtml
(http://developer.kde.org/documentation/library/kdeqt/kde3arch/khtml/)
might be one solution.

The latest Mac browser is based on khtml which is also the basis for
Konqueror. Someone started a port of khtml to windows
(http://khtml-win32.sourceforge.net/) but it unfortunately stalled.
There is also a python binding to khtml as part of the PyKDE project.

One option then would be to try and port khtml to pure Qt so it would
work on windows and then probably modify the khtml python wrapper to
match. Not only would it be a possible solution to your problem but
would make a lot of other people (include myself) happy as this is
exactly the sort of thing I may well need for a work project next year.

I suspect it is too large a project for what you need but no harm in
suggesting it!

Paul


___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] more complex rich text / HTML

2004-10-15 Thread Phil Thompson
> I'm writing an app and want one of the widgets to look
> like a HTML display, with support for buttons, check
> boxes, different fonts, and hyperlinks.
>
> Qt's rich text browser isn't powerful enough.  It doesn't
> let me put controls in its qt rich text language nor
> even let me change the background color of parts of text.
>
> I played around with the idea of implementing a flow-based
> layout system myself and have something of a hack working,
> enough to figure out that the rest will take me at least
> another week.
>
> And probably another couple weeks or more if I want it to
> support font scaling, text selection, bidirectional text,
> stylesheets ... okay, more like a month or more.
>
> Does anyone have any suggestions?
>
> My crazy thought is to embed a native HTML widget for
> the different platforms, so that I use IE to display
> under MS Windows, Safari for Mac, and Konqueror for Linux.
> (That's all I need to support.)
>
> While the last is definitely possible, I can't find
> an example of embedding IE nor even a hint that this
> might be possible on Mac OS X.

Current PyQt and SIP 4 snapshots include a port of the Qt webbrowser
example which embeds IE as an ActiveX control. I don't know what you'd do
for MacOS though.

Phil

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[PyKDE] PyKDE code generation errors

2004-10-15 Thread Deepak Sarda
Hi everyone,

I tried compiling PyKDE from source but failed in the 'python configure.py' 
Output follows:

This is a SuSE 9.1 system updated to KDE 3.3.1 (using SuSE's supplementary rpms)
PyQt, PyQt-devel and sip are from SuSE 9.1 rpms from PyKDE's sourceforge site.

Any help will be great!

-
[EMAIL PROTECTED]:/scratch/stuff/software/PyKDE-3.11.3> python configure.py

 PyKDE version 3.11.3
   ---

Python include directory is /usr/include/python2.3
Python version is 2.3.3

sip version is 4.1.1 (4.1.1)

Qt directory is /usr/lib/qt3
Qt version is 3.3.1

PyQt directory is /usr/share/sip
PyQt version is 3.13 (3.13.0)

KDE base directory is /opt/kde3
KDE include directory is /opt/kde3/include
KDE lib directory is /opt/kde3/lib
KDE version is 3.3.1 (0x30301)

PyKDE modules will be installed in /usr/lib/python2.3/site-packages
PyKDE .sip files will be installed in /usr/share/sip

PyKDE modules to be built:
   dcop kdecore kdesu kdefx kdeui kio kutils kfile kparts khtml kspell
kdeprint kmdi

Generating the C++ source for the dcop module...
Creating the Makefile for the dcop module...

Generating the C++ source for the kdecore module...
sip: KLockFile::Ptr is undefined
Error: Unable to create the C++ code.
--

___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


[PyKDE] more complex rich text / HTML

2004-10-15 Thread Andrew Dalke
I'm writing an app and want one of the widgets to look
like a HTML display, with support for buttons, check
boxes, different fonts, and hyperlinks.
Qt's rich text browser isn't powerful enough.  It doesn't
let me put controls in its qt rich text language nor
even let me change the background color of parts of text.
I played around with the idea of implementing a flow-based
layout system myself and have something of a hack working,
enough to figure out that the rest will take me at least
another week.
And probably another couple weeks or more if I want it to
support font scaling, text selection, bidirectional text,
stylesheets ... okay, more like a month or more.
Does anyone have any suggestions?
My crazy thought is to embed a native HTML widget for
the different platforms, so that I use IE to display
under MS Windows, Safari for Mac, and Konqueror for Linux.
(That's all I need to support.)
While the last is definitely possible, I can't find
an example of embedding IE nor even a hint that this
might be possible on Mac OS X.
Andrew
[EMAIL PROTECTED]
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyKDE

2004-10-15 Thread Maurizio Colucci
Gerard Vermeulen wrote:
   

Comment out (put // in front of) void setFileName in the lines
%If (  - KDE_3_3_0 )
   KCatalogue (const QString& = QString ::null );
  void setFileName (const QString&);
%End
of the file
sip/kdecore/kcatalogue.sip lines 23-60/60 (END)
Wipe out features, run python configure.py, run make
 

It's going :)
Since I don't understand what's going on... can you please tell me if 
this a PyKDE bug or a mandrake one? (if I post a bug to mandrake 
cooker's list I will post both)

Thanks again,
   

I think it is a PyKDE bug.  The sip file declares setFileName as public
while it has been declared private in the KDE header files (the sip
file should match the header file).
Mandrake would never change such a standard header file.
 

Phil? Jim? Are you aware of this problem?
Maurizio
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde


Re: [PyKDE] Error compiling PyKDE

2004-10-15 Thread Gerard Vermeulen
On Fri, 15 Oct 2004 08:26:19 +0200
Maurizio Colucci <[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] wrote:
> 
> >On Fri, 15 Oct 2004 00:03:08 +0200, Maurizio Colucci wrote
> >  
> >
> >>Here we go again... :(
> >>
> >>On Mandrake 10.1, after compiling and installing qscintilla, sip,
> >> PyQt, I am getting errors with PyKDE 3.11.3.
> >>
> >>This is gcc 4.0.0, but I also tried also 3.3 and 3.4.1.
> >>
> >>Of course I am clueless, and desperate :)
> >>
> >>[EMAIL PROTECTED] PyKDE-3.11.3]# python configure.py
> >>
> >> PyKDE version 3.11.3
> >>   ---
> >>
> >>Python include directory is /usr/include/python2.3
> >>Python version is 2.3.4
> >>
> >>sip version is 4.1.1 (4.1.1)
> >>
> >>Qt directory is /usr/lib/qt3/
> >>Qt version is 3.3.3
> >>
> >>PyQt directory is /usr/share/sip
> >>PyQt version is 3.13 (3.13.0)
> >>
> >>KDE base directory is /usr
> >>KDE include directory is /usr/include
> >>KDE lib directory is /usr/lib
> >>KDE version is 3.2.3 (0x30203)
> >>
> >>PyKDE modules will be installed in /usr/lib/python2.3/site-packages
> >>PyKDE .sip files will be installed in /usr/share/sip
> >>
> >>PyKDE modules to be built:
> >>   dcop kdecore kdesu kdefx kdeui kio kfile kparts khtml kspell 
> >>kdeprint kmdi
> >>
> >>Generating the C++ source for the dcop module...
> >>Creating the Makefile for the dcop module...
> >>
> >>Generating the C++ source for the kdecore module...
> >>Creating the Makefile for the kdecore module...
> >>
> >>Generating the C++ source for the kdesu module...
> >>Creating the Makefile for the kdesu module...
> >>
> >>Generating the C++ source for the kdefx module...
> >>Creating the Makefile for the kdefx module...
> >>
> >>Generating the C++ source for the kdeui module...
> >>Creating the Makefile for the kdeui module...
> >>
> >>Generating the C++ source for the kio module...
> >>Creating the Makefile for the kio module...
> >>
> >>Generating the C++ source for the kfile module...
> >>Creating the Makefile for the kfile module...
> >>
> >>Generating the C++ source for the kparts module...
> >>Creating the Makefile for the kparts module...
> >>
> >>Generating the C++ source for the khtml module...
> >>Creating the Makefile for the khtml module...
> >>
> >>Generating the C++ source for the kspell module...
> >>Creating the Makefile for the kspell module...
> >>
> >>Generating the C++ source for the kdeprint module...
> >>Creating the Makefile for the kdeprint module...
> >>
> >>Generating the C++ source for the kmdi module...
> >>Creating the Makefile for the kmdi module...
> >>
> >>Creating top level Makefile...
> >>Creating pykdeconfig.py...
> >>[EMAIL PROTECTED] PyKDE-3.11.3]# make
> >>make[1]: Entering directory `/dat/pub/src/not-mau/PyKDE-3.11.3/dcop'
> >>g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -fomit-frame-
> >>pointer -pipe -march=i586 -mtune=pentiumpro -Wall -W -D_REENTRANT -
> >>DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I. -I../extra/kde323 
> >>-I/usr/include -I/usr/include/python2.3 -I/usr/lib/qt3//include -
> >>I/usr/X11R6/include -o sipdcoppart0.o sipdcoppart0.cpp 
> >>/usr/lib/qt3//bin/moc -o moc_sipdcoppart0.cpp sipdcoppart0.h g++ -c -
> >>Wno-deprecated-declarations -pipe -fPIC -O2 -fomit-frame-pointer 
> >>-pipe -march=i586 -mtune=pentiumpro -Wall -W -D_REENTRANT -
> >>DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I. -I../extra/kde323 
> >>-I/usr/include -I/usr/include/python2.3 -I/usr/lib/qt3//include -
> >>I/usr/X11R6/include -o moc_sipdcoppart0.o moc_sipdcoppart0.cpp g++ 
> >>-shared -o dcop.so sipdcoppart0.o moc_sipdcoppart0.o -L/usr/lib -
> >>L/usr/lib/qt3//lib -L/usr/X11R6/lib -lDCOP -lqt-mt -lXext -lX11 -lm -
> >>lpthread make[1]: Leaving directory `/dat/pub/src/not-mau/PyKDE-3.11.3/dcop'
> >>make[1]: Entering directory `/dat/pub/src/not-mau/PyKDE-3.11.3/kdecore'
> >>g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -fomit-frame-
> >>pointer -pipe -march=i586 -mtune=pentiumpro -Wall -W -D_REENTRANT -
> >>DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I. -I../extra/kde323 
> >>-I/usr/include -I/usr/include/python2.3 -I/usr/lib/qt3//include -
> >>I/usr/X11R6/include -o sipkdecorepart0.o sipkdecorepart0.cpp 
> >>sip/kdecore/kmountpoint.sip: In function `PyObject* 
> >>convertFrom_KMountPoint_List(void*)': 
> >>sip/kdecore/kmountpoint.sip:141: warning: taking address of 
> >>temporary sip/kdecore/kconfigskeleton.sip: In function `PyObject* 
> >>meth_KConfigSkeleton_ItemEnum_choices(PyObject*, PyObject*)': 
> >>sip/kdecore/kconfigskeleton.sip:183: warning: taking address of temporary
> >>sipkdecorepart0.cpp: At global scope:
> >>sipkdecorepart0.cpp:28723: warning: unused parameter 'sipPy'
> >>sipkdecorepart0.cpp:28723: warning: unused parameter 'sipIsErr'
> >>sipkdecorepart0.cpp: In function `PyObject* 
> >>convertFrom_Display(void*)': sipkdecorepart0.cpp:28757: warning: 
> >>unused variable 'sipCpp' sip/kdecore/kconfigbase.sip: In function 
> >>`PyObject* convertFrom_ulonglong(void*)': 
> >>sip/kdecore/kconfigbase.sip:319: warning: unused variable 'LongLong' 
> >>sipkdeco