On Mon, Nov 28, 2011 at 1:00 AM, Robert Xu <robxu9(a)gmail.com> wrote:
> On Sun, Nov 27, 2011 at 19:54, Luke Kenneth Casson Leighton
> <luke.leighton(a)gmail.com> wrote:
>>
>> hmm... qt3 doesn't have a qtwebkit object, does it? ... would you
>> like one? *waggles-eyebrows* :)
>>
>
> *stares for a moment*
> YES YES YES YES YES ;)
hehe. i'm the maintainer of pythonwebkit -
http://www.gnu.org/software/pythonwebkit - i've kinda been looking for
an excuse to update it and also add "proper" python-qt DOM bindings.
you would not believe how unbelievably slow and how much memory
qtwebkit uses under qt4. at least double what anything else is.
so i'm just throwing ideas out, at this stage. but, if i use the
pythonwebkit port of webkit, full python bindings to the entire DOM
model - as if it was javascript not python (just exactly the same
function names, properties and object names) - get thrown in "for
free".
what sort of doors would that open up, for people, if qt3 - and kde -
had both a qtwebkit widget, as well as full python bindings to the DOM
model? (caveat: i can't get you full c++ DOM bindings to webkit,
because the python bindings are "direct" i.e. they do *not* go via qt
objects. at all).
l.
hooray, thank you, god, thank you for everyone who decided to fork KDE
3: KDE 4 is a complete nightmare, which is not surprising given that
they tried to copy vista, the most hated and despised version of
windows ever. i actually lost a friend because of installing KDE 4 on
their computer for them (without realising that that's what would end
up on it).
anyway - yes. really really glad to see kde 3 is still going.
right. about 4 years ago i worked on superkaramba. absolutely loved
it. added some great features: reading the "system menu" so that you
could, instead of having to arse about creating rollerbars that you
then had to manually edit the ~/.blahblah config file or worse
hand-edit a python file, you could just use the standard KDE
application/system editor. this feature made it into KDE 3.5.
i then created a theme which made good use of this:
http://kde-look.org/content/show.php?content=31081
the _next_ feature that i added was to go "hmm, how far can we take
this?" and i added support for URIs e.g. enumeration of application:/
system:/ and media:/ and file:/ or any KIO device in fact, so that you
could create an entire desktop file browser - in python - viewing
files etc. and you can click on and run applications, or create media
icons... whatever.
i then created a theme which used _that_:
http://kde-look.org/content/show.php/WheelOfFortune?content=34021
the problem was that this development clashed with the introduction of
"plasma" which was supposed to be all spiffy and wonderful, but has
turned into a complete dog's dinner. so, anyway, the lead developer
of superkaramba said "whoa, hang on, i don't want superkaramba turning
into plasma" at which point i ended all development efforts.
... four years later, kde4 and plasma have a cult "hate" thing going
:) even meester leenus torvalds has rejected KDE 4 in favour of LXDE
/ XFCE.
so with that as background, my question to you - the trinity
developers is: would you be interested in incorpoorating the dirlister
patches into superkaramba?
l.
Need help here folks to file a good bug report.
I have been using TDE in a virtual machine. Yesterday I created some partitions on a spare hard drive and installed TDE so I could start using and testing on a physical machine.
I can't start TDE.
I think I traced the problem to a conflict between kdetcompmgr and the proprietary Nvidia drivers, but I'm not sure.
I say that because that is where my xession log shows the startkde script stalls.
When I switch to the vesa driver (which looks awful on a wide screen monitor :)) I am able to start TDE with no problems. I can migrate an existing KDE3 profile or start empty and let TDE create a new profile. Either way TDE starts with no stalls.
After the TDE profile exists, whether new or migrated, I can return to the Nvidia drivers and TDE will start with no stalling.
When I have the Nvidia drivers selected and no TDE profile yet exists, I am able to start TDE under only one bizarre circumstance:
Toggle to a console and run "killall kconf_update." I have to do that twice during the TDE startup. Doesn't matter whether I am starting TDE with a migrated KDE3 profile or am letting TDE create a new profile. The splash image won't appear until I execute the first killall. The startup stalls with the splash image at "Initializing system services" until I run the second killall.
When TDE stalls like this, the kconf_update process takes control of my system. The system bogs down and my CPU ramps to full speed and the CPU temperature rises quickly.
I don't see anything in the startkde script that directly calls kconf_update. What is calling that command?
Slackware 13.1, starting X from the console (startx command). Dual core AMD 2.3 GHz, 4GB RAM.
Any ideas?
Darrell
If the system administrators do this change, how will we accommodate
Trinity to it?
Fedora is doing it; openSUSE is having an argument about if this is good or not.
Gentoo had a discussion on this, I think.
Should this be treated like a simple "let's move to /usr/local" or has
the renaming allowed us to install side by side with KDE4 without the
use of /opt?
---------- Forwarded message ----------
From: Greg KH <gregkh(a)suse.de>
Date: Wed, Nov 23, 2011 at 22:51
Subject: [opensuse-factory] Proposal for 12.2, move all binaries under /usr
To: opensuse-factory(a)opensuse.org
Hi all,
As a proposal for 12.2, I would like to implement the move of all
binaries to /usr/ like is being done at the moment in Fedora.
Here's the details as to why this is a good thing to do, and what is
involved in it:
https://fedoraproject.org/wiki/Features/UsrMove
The first packages implementing this have already started to land in
Fedora's version of Factory.
Before you get worried, there will be symlinks back to /bin and /sbin
for those scripts expecting things to be in those locations.
We can use the Fedora patches for almost all of this, they are all
published at:
http://harald.fedorapeople.org/downloads/usrmove/
and a number of upstream projects are already moving their releases over
to this as well, which will make things easier.
If there are no major objections, I'll start working on Base:system in
December.
thanks,
greg k-h
p.s. Please, before you respond, read the link above and all of the
discussion about it and don't repeat the same questions that the link
already answers.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org
--
later daze. :: Robert Xu :: rxu.lincomlinux.org :: protocol.by/rxu
I had problems in Slackware with the 3.5.13 startkde script. Biggest problem was starting KDE 4 apps on its own because $KDEDIRS was explicitly declared in the script and hard-coded to include /usr/share. That variable is intended to be user defined and should not be hard-coded in Trinity.
Second problem was duplication of several snippets of code.
Third problem was snippets of code that never got executed because a previous condition was satisfied.
Fourth problem was the $XDG_DATA_DIRS path. I raised this issue in a previous post. I want the option of whether KDE4 apps appear in my Trinity menu. I can solve that problem easily in Slackware for both types of people using /etc/profile.d scripts. I don't know how other distros would handle that when there is no support for /etc/profile.d. I don't think this variable should be hard-coded in startkde unless completely undeclared.
So I added conditions to set these variables only if they don't include Trinity paths.
I don't want to submit this (yet) as a bug report. I would be grateful if some of you would test this new script in your distro.
I suspect we need more work with this script in order to function correctly in all distros. We probably need a lot of conditional tests.
Here are links to an updated script --- a patch and full script.
http://humanreadable.nfshost.com/trinity/patches/kdebase/startkde.diffhttp://humanreadable.nfshost.com/trinity/patches/kdebase/startkde.new
The patch allows you to quickly see the changes and the full script is there for easier copying to your system.
Darrell
With autotools I use --enable-debug=full.
How is this done with cmake ?
I built with -DCMAKE_BUILD_TYPE=Debug but there is no difference in the final package sizes.
Is there anything in the build log that lets me know how I built a package?
Darrell
While TDE on Fedora is nearly perfect now, I really miss compiz' eye candy. This
seems to be a problem with dBus. Can anyone try to figure this our?
I start compiz-manager and all I get is:
xset q doesn't reveal the location of the log file. Using fallback
/var/log/Xorg.0.log
Detected PCI ID for VGA: 01:00.0 0300: 1002:71c4 (prog-if 00 [VGA controller])
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Comparing resolution (1600x1200) to maximum 3D texture size (4096): Passed.
Checking for nVidia: not present.
Checking for FBConfig: present.
Backend : ini
Integration : true
Profile : default
Adding plugins
Initializing core options...done
Initializing composite options...done
Initializing opengl options...done
Initializing decor options...done
/bin/sh: /usr/bin/kde4-window-decorator: No such file or directory
Initializing wobbly options...done
Initializing imgjpeg options...done
Initializing resize options...done
Initializing reflex options...done
Initializing place options...done
Initializing session options...done
Initializing move options...done
Initializing cube options...done
Initializing screenshot options...done
Initializing mousepoll options...done
Initializing imgsvg options...done
Initializing animation options...done
Initializing td options...done
Initializing thumbnail options...done
Initializing workarounds options...done
process 3835: arguments to dbus_message_iter_append_basic() were incorrect,
assertion "*bool_p == 0 || *bool_p == 1" failed in file dbus-message.c line 2541.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
/usr/bin/compiz-manager: line 367: 3835 Aborted
${COMPIZ_BIN_PATH}${COMPIZ_NAME} $COMPIZ_OPTIONS "$@" $COMPIZ_PLUGINS
Window manager warning: Failed to load theme "Ia Ora Steel": Failed to find a
valid file for theme Ia Ora Steel
Window manager warning: Invalid WM_TRANSIENT_FOR window 0x169 specified for
0xe00008 (Configure ).
Any ideas?
Hello all,
I have for some time been hacking around with Kickoff, looking to
improve it, and make it definitely more TDEish.
While it is not our default menu, we do provide it built in. Therefore
I think it needs to be as good as it can get.
I also think it is of the utmost importance that we follow the TDE HCI
model that Tim drew up. This means that some things in the current
Kickoff layout are not good.
If you look at this link: http://imgur.com/h6xhB
I've drawn arrows and other things in reference to what I am explaining
here, also I've drawn numbers so it's easy to compare.
1) The width of kickoff takes up much to much real estate, and wasted
real estate. My estimate is that we can shave off a good 50-60 pixels
off of it to reduce screen space with almost no sacrifice.
2) We need to remove the "search" text field. It does nothing, it is
not helpful, it is not intuitive, it is just a waste of space. Remove
it, and make the actual search area larger. To make it clear that it
is a search bar, we can do like the regular KMenu search does and have
grayed out letters saying "search..."
3) We also could either A. remove the search icon entirely or B.
shrink it to stop wasting space. Also currently this is a mng file
(basically a dead format that never took off). the animation doesn't
work. hopefully I can just use a regular pixmap instead.
4) in line with the HCI model on the Etherpad, large buttons are bad.
this is not a tablet, and tablet interfaces are not optimal. We can
shrink the tabs a bit, (probably 8-10 pixels each) this fits in with
1) to reduce the width.
5) I say we remove this bottom bar entirely. KMenu does not have it. I
do not think we need to know what user is and what host. I do not
think it is worth the real estate. Also we definitely don't need a
link to the website. If people want to go to our website, they will.
They don't need a button on the main menu.
6) the kickoff logout dialog is this: "logout?" where as the KMenu
shows up a nice dialog with options to hibernate etc. Either barrow
this from KMenu or add options for each of these in the menu.
Thoughts? Suggestions? Does anyone actually use kickoff?
Calvin Morrison
Quite a few 3.5.13 apps will not show associated Help files. A little investigating reveals the apps that show Help files have the Help files installed at:
/opt/trinity/share/doc/kde/HTML
Those apps that won't show Help files have the help files installed at:
/opt/trinity/share/doc/HTML
Is this a build issue at my end? Do I need to specify an explicit install location for help files or is this a configuration bug with the make files?
There are quite a few apps like this.
Darrell
