[kde-linux] KDE-4.8 "public Beta" Unstable Plasma Panel

[James Tyrer]

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