In the current KDE 3.4 and 3.5 brand, icon taskbar focus efects are only a highlight over them, in kde 3.2 and 3.1 brand, icon effects are icon zooming, (like MAC bar style)
any body have the code to get back these?
can be ported to actual kde 3.5 Trinity desktop?
pleae, at leas tell how any!
On Thu, Feb 24, 2011 at 3:33 PM, PICCORO McKAY Lenz mckaygerhard@gmail.com wrote:
In the current KDE 3.4 and 3.5 brand, icon taskbar focus efects are only a highlight over them, in kde 3.2 and 3.1 brand, icon effects are icon zooming, (like MAC bar style)
Personally I don't like this (don't like eye-candy), but for those who have bad eyes, it would have some use.
any body have the code to get back these?
can be ported to actual kde 3.5 Trinity desktop?
I'm sure it could be ported over, we could probably dig up some 3.2 or 3.1 tarballs, or see if it's still in their svn.
pleae, at leas tell how any!
eye candy are not usefully, but.. but it attracts people.. i dont understand people , Tdesktop look like ubuntu, that looks like windows, and windows are all eyecandy, so then?
i will revise kde 3.1 source to see,
but for now im busy with bluez porting
On Fri, Feb 25, 2011 at 12:16 PM, Kristopher Gamrat pikidalto@gmail.comwrote:
On Thu, Feb 24, 2011 at 3:33 PM, PICCORO McKAY Lenz mckaygerhard@gmail.com wrote:
In the current KDE 3.4 and 3.5 brand, icon taskbar focus efects are only
a
highlight over them, in kde 3.2 and 3.1 brand, icon effects are icon zooming, (like MAC bar style)
Personally I don't like this (don't like eye-candy), but for those who have bad eyes, it would have some use.
any body have the code to get back these?
can be ported to actual kde 3.5 Trinity desktop?
I'm sure it could be ported over, we could probably dig up some 3.2 or 3.1 tarballs, or see if it's still in their svn.
pleae, at leas tell how any!
-- Kris "Piki" Ark Linux Webmaster Trinity Desktop Environment Packager
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Thu, Feb 24, 2011 at 12:36, PICCORO McKAY Lenz mckaygerhard@gmail.com wrote:
eye candy are not usefully, but.. but it attracts people.. i dont understand people , Tdesktop look like ubuntu, that looks like windows, and windows are all eyecandy, so then?
i will revise kde 3.1 source to see,
but for now im busy with bluez porting
PLEASE Do not TOP-POST.
On 02/24/2011 11:36 AM, PICCORO McKAY Lenz wrote:
eye candy are not usefully, but.. but it attracts people.. i dont understand people , Tdesktop look like ubuntu, that looks like windows, and windows are all eyecandy, so then?
i will revise kde 3.1 source to see,
There will be many 'temptations' like this going forward. I think the key is to stick to the following kde3 core values when evaluating features:
(1) Is it more efficient?
(a) can you do more with less keystrokes or mouse clicks? (b) does it improve code execution time?
(2) Does it improve usability?
(a) not from a "Gee-Whiz" standpoint, but can it provide real features to benefit the average user --or-- provide a better interface for those with impairments.
(3) Above All - Always Remember
-- A FEATURE IS A BUG IF IT CANNOT BE TURNED OFF!
On 25 February 2011 12:49, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/24/2011 11:36 AM, PICCORO McKAY Lenz wrote:
eye candy are not usefully, but.. but it attracts people.. i dont understand people , Tdesktop look like ubuntu, that looks like windows, and windows are all eyecandy, so then?
i will revise kde 3.1 source to see,
There will be many 'temptations' like this going forward. I think the key is to stick to the following kde3 core values when evaluating features:
(1) Is it more efficient?
(a) can you do more with less keystrokes or mouse clicks? (b) does it improve code execution time?
(2) Does it improve usability?
(a) not from a "Gee-Whiz" standpoint, but can it provide real features to benefit the average user --or-- provide a better interface for those with impairments.
(3) Above All - Always Remember
-- A FEATURE IS A BUG IF IT CANNOT BE TURNED OFF!
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
While it does not improve any of those areas you mentioned, usability or speed, it does improve customizability which is important.
I would not be in favor of this, except for that fact that it used to exist. removing features is never a good thing! Regression of features is one of the big reasons why Tim is having trouble with Qt4! :P
It should be little work to do this, probably copy/paste and editing a few functions. If it was a large undertaking i could understand reasoning against it, but i do not see that being the case.
Calvin Morrison
On 02/25/2011 02:31 PM, calvin morrison wrote:
While it does not improve any of those areas you mentioned, usability or speed, it does improve customizability which is important.
I would not be in favor of this, except for that fact that it used to exist. removing features is never a good thing! Regression of features is one of the big reasons why Tim is having trouble with Qt4! :P
It should be little work to do this, probably copy/paste and editing a few functions. If it was a large undertaking i could understand reasoning against it, but i do not see that being the case.
Calvin Morrison
I think this particular feature will be cool. But we need to make sure to include a radio-button or check-box in "Configure Panel..." that lets you disable it if you don't want it.
On Friday 25 February 2011 23:31:09 calvin morrison wrote:
While it does not improve any of those areas you mentioned, usability or speed, it does improve customizability which is important.
I would not be in favor of this, except for that fact that it used to exist. removing features is never a good thing! Regression of features is one of the big reasons why Tim is having trouble with Qt4! :P
It should be little work to do this, probably copy/paste and editing a few functions. If it was a large undertaking i could understand reasoning against it, but i do not see that being the case.
I think it would be great to have this implemented as in KDE2. On the other hand I heared Apple has a patent on the panel icons enlarging on the mouse hove, that may be the reason why this feature was removed (as well as double-click by default which is patented by Microsoft)
Zooming, double clicking, the progress bar and many other patents, are really rips offs of earlier patents. As such, are indefensible. For example the progress bar actually appeared in Unix but in ASCII form.
MS apparently looked into suing for patent infringement it when it realized it lost ground to Linux, Apple and BSD but opted out because it, itself could be sued for such as well (helps to know retired MS devels, get all the best dish).
The zooming use removed from kde3x because there was a small coding problem and because some of the devels involved at that point didn't like it.
Your's in History
Kate
On 2/26/11, Ilya Chernykh neptunia@mail.ru wrote:
On Friday 25 February 2011 23:31:09 calvin morrison wrote:
While it does not improve any of those areas you mentioned, usability or speed, it does improve customizability which is important.
I would not be in favor of this, except for that fact that it used to exist. removing features is never a good thing! Regression of features is one of the big reasons why Tim is having trouble with Qt4! :P
It should be little work to do this, probably copy/paste and editing a few functions. If it was a large undertaking i could understand reasoning against it, but i do not see that being the case.
I think it would be great to have this implemented as in KDE2. On the other hand I heared Apple has a patent on the panel icons enlarging on the mouse hove, that may be the reason why this feature was removed (as well as double-click by default which is patented by Microsoft)
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Saturday 26 February 2011 19:22:16 Katheryne Draven wrote:
The zooming use removed from kde3x because there was a small coding problem and because some of the devels involved at that point didn't like it.
In that case I would support restoring the zooming as well as all other things which were removed. On one screenshot from early KDE3 I saw the quich launch bar was partially with large icons (as now it is) and partially with smaller icons arranged in two rows. I wonder if it is possible to restore this function?
I also think the tray icons could be smaller to match the quick launch icons when the panel's size is smallest and also to have aability to be arranged in two rows when the panel's size allows to have two rows of taskbar buttons. I.e. 2 row taskbar -> two row tray 3 row taskbar -> 3 row tray etc.
On 02/26/2011 09:58 AM, Ilya Chernykh wrote:
I think it would be great to have this implemented as in KDE2. On the other hand I heared Apple has a patent on the panel icons enlarging on the mouse hove, that may be the reason why this feature was removed (as well as double-click by default which is patented by Microsoft)
The enlarging icons have to be in the public domain now or Rocket Dock for MS wouldn't exist. (Not to mention the measure of damage in a patent suit is the 'profit' earned from the use of the patented item) I have searched a bit on the issue and have not found any chatter. I haven't seen the books for the Trinity project yet, but it stands to reason $0 without enlarging icons + $0 with enlarging icons doesn't add up to a whole lot to be concerned about :p
If somebody can get ahold of the 3.2, 3.3 or 3.4 Changelog(s) there should be something mentioned on the removal.
Unless we can turn up some concrete reason that is still applicable today, I wouldn't let it hold up reimplementation. If anybody finds a relevant link, post it here and I'll follow up on it :)