On 01/01/2012 12:33 AM, Duncan wrote:
James Tyrer posted on Sat, 31 Dec 2011 17:54:26 -0700 as excerpted:
So, I installed the current KDE-4.8 BRANCH and again, it should not be
called a Release Candidate.
Three icons no longer had their correct icon image but rather had the
"unknown" icon. Can't see how this would happen.
Icons? In a plasmoid? In the applications menu? Where? Which ones?
I am talking about a panel but that isn't made clear till later in the post.
My first guess would be that this could be due to icon names changing.
Existing configurations (either per-user or for other apps not updated)
using the old names would then get the "unknown" icon. If you had given
a bit more detail as to where and in what this was occurring and whether
it was a user-configured location and/or whether it still occurred in a
fresh user config, it would have been easier to figure out what's
happening. At least it would have likely been possible for me to confirm
whether I see the same issue here on 4.7.95 (aka 4,8-rc1).
However, the icons on a panel are links. The links were still good.
FWIW, the rc label looks reasonable here, altho I don't by any means have
all of kde installed and in fact have neither kdepim nor much of any
semantic-desktop stuff installed at all, and like apparently most kde
devs I now consider konqueror only a toy browser
The sad situation with Konqueror, which developers are aware of but they
don't know how to fix the problem, is the most significant example of
how the way that KDE is organized can fail. There was an interesting
article in "Communications of the ACM" on how and why Open Software
projects fail. Here, the problem is that constructive anarchy doesn't
seem to be working. With Konqueror, the code base has been compromised
due to poorly though out (poorly designed) features being added to it.
Now, nobody is willing to work on it because there is no 'merit' to be
obtained by doing so.
and default to something
else (firefox in my case), tho I do have it installed, so I'd likely fail
to notice many issues with konqueror, as well.
I usually use Konqueror when I am browsing development sites, but have
been mostly been using Chrome lately although it does have some quirks
that they are working on.
In particular, I've run both betas and now rc1, and don't see any sign of
the icon issues you very vaguely mention, with no specifics that I can
verify further.
A Public Beta is not the same as just a Beta. I still don't think that
the current state of the 4.8 BRANCH is good enough to call a RC.
Fixing that, I found a REGRESSION. That thing that pops up on the end
of a panel when you unlock widgets is again taking up space. This has
been fixed previously.
Hmm... It doesn't appear to be doing so here. However, since I'm on the
4.7.95 pre-release and you're apparently on live-branch, it's quite
possible they broke something (hopefully temporarily, full release is
less than a month out...) on live-branch that I'm not seeing in my
version.
Confirming, a panel's cashew/toolbox does NOT take up additional room
here. Sliding the panel size sliders to shrink the panel moves the
cashew into the plasmoid to its left, so they appear on top of each
other, as they do if the panel can be expanded further (minimum and
maximum sliders not set to the same size) but no plasmoid is forcing it
to ATM (as when for example a panel with a systray plasmoid is set with a
maximum size to accomodate more tray icons than it has at present, so
both the plasmoid and the panel are shrunk to a smaller size... the
toolbox doesn't force the panel wider in that case either, as you appear
to be suggestion it does for you).
Perhaps it is just an instability that shows up when reconfiguring a
panel. Now that I have logged off and back in, it isn't doing it.
ARGH! I hate it when that happens -- an unreproducible bug (by
definition) can not be fixed.
Might I suggest that there must be a better solution to this than the
"Panel Tool Box [sic]" (note that in my dictionary that 'toolbox' is one
word).
Indeed there's a dictionary entry for that here (well, on wictionary,
which is what I checked), but the word is clearly a compound composed of
two separate words (wictionary etymology section confirming), and the two
words both remain in popular independent usage as well, so it might be a
bit strange, but would be author's preference. And especially if English
is a second language for that author, or their dialect has the two
separate words commonly used together...
Was referring to the spell check dictionary. But, yes someone that is
ESL (not a Germanic language where compound nouns can get rather long)
might have had to look it up to know.
Here's the google search "tool box" -toolbox :
http://www.google.com/search?q=%22tool+box%22+-toolbox&ie=UTF-8&oe=UTF-8
Looks quite common from here! =:^)
IOW, if that's the level of complaints you're listing, this must be quite
a good rc indeed! =:^)
I had additional issues trying to configure the panel which I didn't
mention. I was having problems moving the icons around -- some of them
wouldn't move, but that problem didn't always happen. As I said,
instability is the issue.
And there is the problem with intersecting panels and the top panel not
knowing that it belongs at the top of the screen that haven't been
fixed. I changed the (Panel with the) clock from: "Top" to "Center" and
left enough space at the top to clear the top panel and now the top
Panel (Windows can cover) stays where it belongs.
I note that when widgets are unlocked that the menu for icons on
the panel and the panel contain an additional item: "Remove this ...".
Couldn't this be handled with an addition to the menu? Oh wait! it is
already there under: PanelOptions. So the: Panel Tool Box [sic] is
redundant.
Actually, it'd be other locations for those options that are redundant,
because as has been explained before, the other places the option appears
are under the control of the plasmoid clicked on (and in the case of the
desktop/activity toolbox/cashew, there's a user option to use what would
ordinarily be the right-click menu for something else entirely) or
otherwise not guaranteed to always be there.
I was only talking about removing the toolbox widget from the panel
where it is a problem. I have not used all of the Plasmids but the ones
that I have, other than the panel, have an external pop-up to access the
toolbox.
The cashew/toolbox is thus the only consistent place such options can be
expected to appear (the kdelook IHateTheCashew, cashew-removal plasmoid
not withstanding... that's not an officially supported plasmoid and while
they aren't going out of their way to break it, neither are plasma
authors changing their assumptions, which that plasmoid breaks, thus
behavior with it is as they say, "undefined").
Well, I don't see the multiple redundant locations as a good design for
a UI. The toolbox access widget in the panel is not consistent with
other Plasmids that I have used. And, the panel is not considered to be
a Plasma Widget -- you can't add one with: "Add Widgets" -- so it could
be different (it already is).
All that said, I personally find BOTH the whole cashew thing blown WAY
out of proportion as it's simply not that big a deal to me (as long as it
works as expected if it appears at all, which it does, here), AND, given
kde's usual support of user customization, the plasma-dev's insistence on
it entirely mystifying as well. Oh, well, as I said, it's unobtrusive
enough for me that I find it to be no big deal.<shrug>
My only big issue with the panel cashew is when it interferes with
configuring a panel. The question of what would be the best design is
not a large issue.
After wasting considerable time, I find that there is a new bug. When I
lock widgets, the content of the top panel moves to the (my) right
pushing the right most icon slightly off the edge and leaving a small
space on the left end. That would also be a REGRESSION -- possibly
related to the first one.
Interesting. I don't see that one here either.<shrug> But you are
correct in that it does sound like it's related to the cashew taking up
space bug.
Just to be sure, since I know you had problems with one of the other
URLs. You didn't perhaps fetch and build the 4.7 or (given the change
noted below) the pre-4.7 branch instead of the 4.8 branch, right?
No, I simply changed my GIT repositories to a different branch and
checked out the SVN:
svn://anonsvn.kde.org/home/kde/branches/KDE/4.8/<module_name>
You did know that they changed the plasma module names for 4.7, right?
No. Somebody rearranged the website, stuff has migrated from SVN to
GIT, and new modules are being added. But, I don't recall anything
Plasma with a new name for the repository module.
If you're still using the old locations you'd be fetching old pre-4.7
code! That would explain why you're seeing old bugs!
Couldn't do that if it had "4.8" in the SVN name or the branch checked
out was: "origin/KDE/4.8" in GIT.
According to the gentoo/kde overlay ebuilds and eclasses, the modules are:
kde-baseapps
kde-runtime
kde-workspace
FWIW I believe they were kdebase-* previously.
There are also separate GIT modules for:
kate
konsole
That are considered to be part of: "KDE Base Apps". The website:
https://projects.kde.org/projects/kde
was rearranged, but the GIT repository remains the same except for
additions. "analitza" under: KDEEdu appears to be new for 4.8.
They're all three git-based (not the older svn):
git://anongit.kde.org/<modulename>
Branch:
KDE/4.8
They seem to have standardized on:
origin/KDE/4.8
after some early confusion on the branch names.
--
James Tyrer
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
