Search results
Search results 1-20 of 29.
Use the (very) old unix command locate: locate kmdi will tell you where the thing is. For more information about locate use the man page: man locate
Quoted now i can compile the package with ./configure but after that i do with MAKE then it show that the file that the specification command in unavailable ..... why can this be happening ??? When you need help about some ./configure or make, post the relevant error messages. How could we figure what's going on if you don't give the real error messages Did ./configure end with ok or does it tell you some library not found? If make fails, what is the exact message?
If you have read the error message, configure tells it needs Qt >= 3.2 So this version of kmail will not compile with qt 3.1. Either upgrade your qt or download a kmail version fitting your qt.
I suppose you talk about oowriter and oocalc. Documents are stored in a compresded (zip). When you unzip an sxw document, content is in content.xml file. You'll have to use a QDomDocument to get the document structure. Somewhere you'll find your table. Examine the content.xml from a sample oocalc file. You'll find <table:table-cell> items. Now you can use Qt XML Dom classes to copy from one to the other
Your problem could be that KDE uses the classic Unix internationalization system (po, mo and pot files) while your Qt app uses Qt multiplatform Linguist method. Might be your app could use KDE translation system if it is only intended to run on Unix.
Linux (or most Unices) develoment is not really difficult, as those system are Psix compliant. So all function calls are really standard. Graphics development is not so difficult too. As your project is about KDE, it has a relly consistent API. Look at the DCOP and KParts, it's relly interesting
Did you try KDevelop? It's a very good IDE. The latest version integrates with Qt Designer in a very fancy way.
It should have something like: Quoted [anubis@anubis anubis]$ dcop kmix qt KDebug MainApplication-Interface Mixer0 kmix And: Quoted [anubis@anubis anubis]$ dcop kmix Mixer0 QCStringList interfaces() QCStringList functions() void setVolume(int deviceidx,int percentage) void setMasterVolume(int percentage) void increaseVolume(int deviceidx) void decreaseVolume(int deviceidx) int volume(int deviceidx) int masterVolume() void setMute(int deviceidx,bool on) bool mute(int deviceidx) void setRecordSour...
Quoted 1. Is Qt 4 Preview 2 backwards compatible with Qt 3.x stuff, like KDE 3.3.0? No, at least for the moment, and even at term, it should not be binary compatible, as most base Qt class have changed in radical way. Quoted 2. What versions of gcc is it known to compile with? (I'm using 3.4.1, but I'll revert to 3.3.4 if I have to) It compiles with 3.4.1, without a problem. You should use something like /opt/qt4 prefix if you don't want to mess all your stable installs. Being a preview, not al...
From the source code text go on the line where you ant to set your BP, open the Debug menu, and use the switch break point (or something like that, I only have a French install on this computer). The you can run your debug session.
Does your child need to really be MDI? If yes, use the QWorkspace as place holder for other windows. If not give the widget the Qt::WType_TopLevel flag (as well as other needed flags). A QGLWidget is a widget as others, as it inherits QWidget and can be used in a QWorkspace as a child window.
Yes, have a look to http://doc.trolltech.com/3.3/qworkspace.html the QWorkspace class wich tells you the pros and cons of the thing.
Should run, but you create a strong dependancy on another dektop... wich is not very modular.
You'll have to recompile some kdelibs and the kde artwork (all the styles, themes...) If you remember, plugins always rely on a precise Qt version. Qt 3.3.3 will NOT load Qt 3.2 plugins and certainly not Qt 3.1. Reverse is true too. If a coupled Qt-3.3.2 and the lates Kde is available for your slakware, I suggest you install the whole thing. Would be faster and simpler than trying to recompile parts of Kde wich need a bunch of libs, headers and other dependancies, is a memory hog and takes centu...
I gave it a try, seems very interesting, and complying more or less with Freedesktop.org discussions and proposals. If you need help for features, ideas, would be great to have a common cross-platform Qt application stub model. And, when freedesktop standard will emerge, it could be easy to change some behaviour to be compliant withh it too.
some kind of daemon like. Sounds good
No if your loop calls qApp->processEvents(). But by loop, I though of some timer calling a checking slot on timeout. Timers are very handy for subprocess monitoring.
The idea behind the scene in qds is very interesting. Will you make it a public project on freshmeat ?
You could have a llop testing the thread for finished() and send a signal on finished() returning TRUE.
Quoted Originally posted by wysota Doesn't the external process get killed if the parent process (Qt app) ends? Yes, except if we use hacks to reparent the process. But this is not very clean nor a snap Quoted And how to reconnect to stdin/stdout of an already running process? It isn't that easy if this "linux app" doesn't support its own IPC handling. That's the main issue for most classic utilities. One could cheat and poke into /proc, but we would need different methods for 2.0, 2.2, 2.4, 2....