samhain wrote:Not necessarily. If moving is done by a "press-move-relase"-sequence, it would be transparent to plasmoids if the container swallows these sequence. Technicly it would be identical to the way it is now, despite no popups show up. Same goes for resizing, you could have the plasmoids borders act like window handles. Benefits: plasmoids would work more like expected.

Exactly

(btw I switched to gnome a few months and it's starting to grow on me, though I still wish kde4 would just "snap out of it" and shape up and become as easy and versatile and fast as kde3 is)

samhain wrote:Not necessarily. If moving is done by a "press-move-relase"-sequence, it would be transparent to plasmoids if the container swallows these sequence. Technicly it would be identical to the way it is now, despite no popups show up. Same goes for resizing, you could have the plasmoids borders act like window handles. Benefits: plasmoids would work more like expected.

Yes, my point is that doing this will totally break some plasmoids. Some plasmoids depend on being able to capture click-and-drag behavior. Doing what you suggest is a radical shift in how plasma works on a fundamental level that will make some plasmoids totally useless and cause severe problems for others.

So for a few exceptional plasmoids 30 years of expected desktop behavior is thrown overboard and even adding some hihly annoying behavior to boot? Why can't plasmoids have a small handle to grab them is necessary? Whatever is done now via poping up handles can be done with small permanent ones or just on right click

aapgorilla wrote:So for a few exceptional plasmoids 30 years of expected desktop behavior is thrown overboard and even adding some hihly annoying behavior to boot?

Just because something has always been done a certain way doesn't mean that is the best way to do that. Plasma has already "thrown overboard" "30 years of expected desktop behavior" with the very concept of plasmoids, the desktop containment, the search and launch containment, the newspaper containment, the folder view widget, activities, and the panel. The whole point of plasma is to look at what works and what doesn't and try to make things better.

There isn't really a precedent for plasma, no one has made a desktop like it before. So saying there is "30 years of expected desktop behavior" is to totally miss the point of what plasma represents.

aapgorilla wrote:Why can't plasmoids have a small handle to grab them is necessary? Whatever is done now via poping up handles can be done with small permanent ones or just on right click

Several reasons.

First, plasmoids are not meant to be moved around a lot. The expectation is that people will find a layout they like and stick with it, and if they need multiple layouts they can use activities (especially with 4.5 where it is easy to clone activities). Doing what you suggest will make it much, much easier to accidentally move widgets and thus screw up your layout. So it makes destructive behavior much easier while making it only slightly easier to do a task that should be pretty uncommon to begin with.

Second, it would change the behavior people are used to and plasmoid developers have come to expect and same have come to depend on. For someone who is so hung up on keeping things consistent you are sure quick to call for completely changing how plasma desktop works. Once again, it would require major changes to key plasmoids like folderview just to make uncommon tasks slightly easier, and would break backwards compatibility with third-party plasmoids people already have installed. The changes would also require taking up additional space in existing widgets.

Third, for people who lack right mouse buttons this will make removing widgets nearly impossible.

Fourth, it does not provide a good solution for non-rectangular widgets like the analog clock.

Fifth, the way plasma is designed someone could write a third-party containment based on this idea if they really want to. The developers won't because it is a waste of time, completely changes long-standing behavior, and breaks existing functionality, but some third party could do it.

Sorry, you are not right. Plasmoids as a brand name are new to KDE, but things like that have been around for ages. Admitted, not for KDE, since it hides the root-window behind the desktop.

If a plasoid wants drag events, then why not grant it? It's just the usual stuff. Have invisible handles around the plasmoids borders would do the job for them, too.

Non-rectangular shapes wasnt even a problem 20 years ago. It just happened that having contour following windowhandles never got implemented. But nearly all non-rectangular window decorations fall in this caregory (even KDE3 had some), every graphic program (e.g. GIMP) has some of this kind, so it's no problem.

Your propsed usage of plasmoids is how you use them, not anybody else. The thing is, as it is not possible to move/resize them in a fluent way, they are clumby to use.

The two biggest problems with the current implementation of plasmoids are a) it breaks any focus model despite click-to-focus, and b) they cannot be locked one by one.

samhain wrote:Sorry, you are not right. Plasmoids as a brand name are new to KDE, but things like that have been around for ages. Admitted, not for KDE, since it hides the root-window behind the desktop.

Really? Name one.

samhain wrote:If a plasoid wants drag events, then why not grant it? It's just the usual stuff. Have invisible handles around the plasmoids borders would do the job for them, too.

It's not that easy. There is no way to tell which plasmoids will capture mouse events and which won't.

samhain wrote:Non-rectangular shapes wasnt even a problem 20 years ago. It just happened that having contour following windowhandles never got implemented. But nearly all non-rectangular window decorations fall in this caregory (even KDE3 had some), every graphic program (e.g. GIMP) has some of this kind, so it's no problem.

I am not aware of any common program that has circular or oval windows.

samhain wrote:Your propsed usage of plasmoids is how you use them, not anybody else.

Really? On what basis do you draw this conclusion?

samhain wrote:The thing is, as it is not possible to move/resize them in a fluent way, they are clumby to use.

I disagree.

samhain wrote:The two biggest problems with the current implementation of plasmoids are a) it breaks any focus model despite click-to-focus, and

The whole point of plasmoids is that they don't use this focus model. If they did they would just be regular windows. Plasmoids are not windows, they are not designed to act like windows, and they are not intended to be used like windows. Now in kde 4.5 it will be possible to launch some plasmoids as windows, but that is not how plasmoids on the desktop are meant to be used.

I should add that in most desktop environments you cannot click in the body of a window to move it either, you need to click on the title bar. You could think of the handle as an auto-hiding title bar if it makes things easier. It auto-hides, though, because windows are meant to be moved around a lot and re-positioned, while plasmoids are not.

samhain wrote:b) they cannot be locked one by one.

There is nothing fundamental in the current approach that prevents this, the feature just hasn't been implemented. I don't see a use-case for it personally.

You still have yet to explain why people need to move widgets around so much that it is worth major changes to both plasma and a number of individual widgets.

Really? Name one.

E.g. FVWM (and others) has layers, any program can act as an equivalent to plasmoids. xterm on the bottom layer is a nice thing, combined with root-tail it's awsome

It's not that easy. There is no way to tell which plasmoids will capture mouse events and which won't.

It's just as any windowmanager works, where's the problem?

I am not aware of any common program that has circular or oval windows.

Xeyes

Really? On what basis do you draw this conclusion?

As you do: on my own habits, how I use stuff.

The whole point of plasmoids is that they don't use this focus model. If they did they would just be regular windows. Plasmoids are not windows, they are not designed to act like windows, and they are not intended to be used like windows. Now in kde 4.5 it will be possible to launch some plasmoids as windows, but that is not how plasmoids on the desktop are meant to be used.

That's called "broken by design". "not meant to be used that way" is wishfull thinking at best. Puting a spoke in somebodies wheel to make "not to be used that way" a fact is disgusting.

I should add that in most desktop environments you cannot click in the body of a window to move it either, you need to click on the title bar

So plasmoids are windows then? Just spin the idea: Why should it not work that way? Anything that needs to be done is changing the behaviour of the plasmoid container, and that would be transparent to the plasmoids. It would work for windows, too ...

It auto-hides, though, because windows are meant to be moved around a lot and re-positioned, while plasmoids are not.

There is no reason why a plasmoid should not be moved around a lot. It definitly would add fun to the desktop.

There is nothing fundamental in the current approach that prevents this, the feature just hasn't been implemented. I don't see a use-case for it personally.

Lock Plasmoids in the panel, but not on the desktop. Lock the clock - as it has a perfect place - but leave the rest moveable. etc. etc.

You still have yet to explain why people need to move widgets around so much that it is worth major changes to both plasma and a number of individual widgets.

First of all, it's fun if you can to change your environment by just some draging. When it's fun, people stay.
Speking for myself I would need at least 2 or 3 easily configurable folderviews with all other plasmoids locked. It's no use if I can get that functionality from konqueror/dolphin, as when these applications are open, I do not see the desktop any more, hence I do not need plasmoids.

Anyway, I would like to hear why plasmoids should not be moved around frequently (despit some obcure design decision).

samhain wrote:

Really? Name one.

E.g. FVWM (and others) has layers, any program can act as an equivalent to plasmoids. xterm on the bottom layer is a nice thing, combined with root-tail it's awsome

So any window can be embedded in the panel, and know that it needs to change its UI? Any window can know that it is in the newspaper containment and needs to change its UI for that? Plasma is far more than just being able to embed windows in the desktop.

samhain wrote:

It's not that easy. There is no way to tell which plasmoids will capture mouse events and which won't.

It's just as any windowmanager works, where's the problem?

Window managers use title bars. They also use window type identifiers so the window manager knows how to treat the windows. Doing that for plasma would require rewriting every plasmoid.

samhain wrote:

I am not aware of any common program that has circular or oval windows.

Xeyes

Which, at least for me, can't be moved at all.

samhain wrote:

Really? On what basis do you draw this conclusion?

As you do: on my own habits, how I use stuff.

Let me see if I get this straight: you said that I am the only person in the world who uses plasma this way, based on nothing more than how you use it?

samhain wrote:That's called "broken by design". "not meant to be used that way" is wishfull thinking at best. Puting a spoke in somebodies wheel to make "not to be used that way" a fact is disgusting.

Why should we turn plasmoids into windows when we already have windows? You still have provided no reason whatsoever to do this.

samhain wrote:Just spin the idea: Why should it not work that way?

Because it would break plasmoids! I've already explained this many times by this point. If there is a good reason to force major changes, then fine. But you have not provided any reasons why your way is better.

samhain wrote:There is no reason why a plasmoid should not be moved around a lot. It definitly would add fun to the desktop.

It isn't a question of why shouldn't they, it is a question of why should they. You are proposing a massive change to both plasma and individual plasmoids that will break backwards compatibility with third-party plasmoids, but have provided no use-cases that could possibly justify such radical changes..

I should add that individual plasmoids can be designed so that dragging them moves them. The bball plasmoid does this. If plasmoid developers really wanted to be able to do this they could add that functionality to their widgets. Few, if any, have.

samhain wrote:Lock Plasmoids in the panel, but not on the desktop. Lock the clock - as it has a perfect place - but leave the rest moveable. etc. etc.

All of those assume people want to move their plasmoids around a lot, which you still have provided no use-cases for.

samhain wrote:First of all, it's fun if you can to change your environment by just some draging. When it's fun, people stay.

"It's fun" is not a good excuse for making destructive behavior easy. And there are already "fun" plasmoids that can be moved easily, like bbal. What you are proposing may make it more fun for some, but at the expense of make it functional for others.

samhain wrote:Speking for myself I would need at least 2 or 3 easily configurable folderviews with all other plasmoids locked. It's no use if I can get that functionality from konqueror/dolphin, as when these applications are open, I do not see the desktop any more, hence I do not need plasmoids.

Why don't you use activities, or folderview widgets in windows, or folderview widgets in a panel? Why do you need to move them to make them configurable? You can configure them easily even when the desktop is locked.

samhain wrote:Anyway, I would like to hear why plasmoids should not be moved around frequently (despit some obcure design decision).

The burden of proof is on you to justify such massive changes to a core part of KDE.

A reminder: the current discussion is not about KDE 3.5 anymore

On windows as widgets: You can use KWin as your desktop shell if you want windows on the desktop. Just set some special rules for the application/window. That's how I had Conky on my desktop for some time.

On KDE 3: Moderators, can we please stop saying "KDE 3 is not supported" as it were a bad thing? KDE 3 is a great desktop that got a lot of time of stabilization. It should work whether there is development for it or not.
Anyone with the KDESVN-build script should be able to get the KDE3 desktop easily on any distribution.

Anyone with the KDESVN-build script should be able to get the KDE3 desktop easily on any distribution.

Could you point me to a how-to for doing this? I just tried it, but ended up with KDE4 (shame on me)

The 3.x desktop is now named trinity, you can find it on http://websvn.kde.org/branches/trinity/
How to adjust kdesvn-build for that i have no idea though.

The last version of kdesvn-build to support 3.5 is 1.9

Use the sample file, disable qt-copy and kdesupport, use the 3.5 branch, and install any missing dependencies.

Ok, I run in some obscure problem:

Code: Select all

This Makefile is only for the SVN repository

*** YOU'RE USING automake (GNU automake) 1.11.1.
*** KDE requires automake 1.6.1 or newer
make[1]: *** [cvs] Fehler 1
make: *** [all] Fehler 2

So ... is there an easy way to build KDE3.5 on a fairly modern system?

I ran into that too. For each module, edit admin/cvs.sh. Find and replace "1.10" for "1.11".

This configuration works for me:

Code: Select all

# Sample configuration file for kdesvn-build.
#
# To use this sample configuration file, copy it to ~/.kdesvn-buildrc, and then
# edit it to suit your desires.

# Global settings go in this section.  They apply to every module unless
# overridden later.
global
# Disable unsermake. It does not help much.
   use-unsermake false
# This is the directory that your KDE sources are downloaded to.  This
# directory also holds the build and log directories by default.
   source-dir /home/kde/src/KDE3

# This is the directory that KDE will end up installed at.  The default is
# appropriate for a single-user installation of KDE, which requires no root
# permissions.  If you'd like, you can install and use the sudo program to
# install KDE anywhere on your system, in conjunction with the
# make-install-prefix option.
   kdedir /home/kde/KDE3
#
# You can overwrite the installation directory for a given module using
# the per-module "prefix" option. Note that when doing this you need to
# set KDEDIRS, PATH and LD_LIBRARY_PATH to point to both directories,
# and that you should use separate test users or KDEHOME values to separate
# the ksycoca databases. Only set prefix if you know what you're doing.

# This is the Qt installation to use to build KDE.
   qtdir /usr  # Default to installing Qt

# By default (if the above is commented out), you are getting trunk.
# If instead you want to check out another branch, like 4.2, use
   branch 3.5

# This is the Subversion server to download the KDE sources from.  Developers:
# Don't forget to add your username to the URL if necessary!
#   svn-server svn://anonsvn.kde.org/home/kde

# These are the default options passed to the make command.  The default tries
# to build with 2 parallel compiles.  If you are using distcc or have SMP, you
# should experiment with setting this value higher for best performance.
#   make-options -j2

# KDE has one of the most extensive translation packages in the world.  They
# are stored in the l10n module.  kdesvn-build can automatically try to build
# and install languages for you, using this parameter.  It should be a list
# of languages to build and install.  This option requires the language code
# as present in l10n.  You can look these codes up at
# http://i18n.kde.org/teams/
#   kde-languages de        # German
#   kde-languages fr        # French
#   kde-languages en_GB cs  # British English and Czech

# If you would like install KDE to the system (DO NOT INSTALL *over* a prior
# installation!), then you'll probably need to use sudo to install everything.
#
# The -S parameter causes sudo to read from standard input (which is redirected
# by kdesvn-build).  This means that if sudo has to ask for your password, it
# will fail, you need to configure sudo to be able to run "make install" and
# without requesting a password.
#
# In addition, you can run kdesvn-build --no-install, and then
# sudo kdesvn-build --install if you are unable to configure sudo to allow
# make install with no password.
#    make-install-prefix sudo -S

# purge-old-logs controls whether old log files should be removed after the
# latest build finishes. Set to true to enable it.
#    purge-old-logs false

# binpath controls the value of the PATH environment variable during
# compilation.  If you have unusual tools that need to be in the path to build
# KDE, add them here.  KDE's and Qt's programs are automatically added.
# If you leave this option blank, it will default to the PATH that kdesvn-build had
# when it was started.
#   binpath /bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
#   binpath /usr/lib/ccache/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin

# This directory is where everything gets built before it is installed.  By
# default it is relative to the value for source-dir.  You can specify an
# absolute path if you'd like (begin the path with a slash).
   build-dir build

# These are the compilation flags to use by default when compiling KDE.
# gcc supports a -march option in order to generate specific code for pentium4, athlon-xp,
# etc.  See the gcc man page for more information.
#
# NOTE: For KDE 4 these flags are only applied if you set the CMAKE_BUILD_TYPE setting
# to "none" (see the cmake-options setting)
#   cxxflags -pipe -march=native # Don't use native with distributed build

# You can use the set-env option to add values to the build environment.
#   set-env LDFLAGS -Wl,-O1   # Optimize the linker, takes longer.

# If you use software which requires pkg-config, and you need to add entries
# to your pkg-config path, you can also use set-env for that.  Some broken
# systems require you to set this to find e.g. glib.
#   set-env PKG_CONFIG_PATH /opt/gnome/lib/pkgconfig
end global

# kdelibs are the base KDE libraries needed by all KDE applications.
module kdelibs
   #If you do not have mcopidl installed, or do not want/care about sound on KDE
   #configure-flags --without-arts
# If you're a programmer you may want to build the API docs.  There is a
# separate script in kdesdk/scripts to do that for you however.
end module

# kdebase contains useful general-purpose programs, normally people would
# expect a usable desktop to have these.  Includes required programs and
# libraries in runtime/, and Konqueror, Dolphin, and Plasma.
module kdebase
   #If you do not have mcopidl installed, or do not want/care about sound on KDE
   #configure-flags --without-arts
end module

# kdemultimedia contains JuK, noatun, Kaboodle, and other KDE multimedia
# applications.  It does not include amarok, which is in extragear/multimedia
#module kdemultimedia
#end module

# ... Well, they're games. ;)
#module kdegames
#end module

# kdesdk is a useful module for software developers.  It is where kdesvn-build
# is developed, in addition to other handy scripts for KDE and general software
# developers.  Programmers *need* this module for kcachegrind
#module kdesdk
#end module

# kdenetwork has Kopete and other useful applications for the Internet and
# other networks.
#module kdenetwork
#end module

# kdepim contains KMail, Kontact, KOrganizer, and other insanely useful
# programs that help you keep track of things.
#module kdepim
#end module

# kdeadmin has system administration tools for your computer.
#module kdeadmin
#end module

# kdebindings is useful for software developers, and for those who wish to run
# some KDE programs that don't use C++.
#module kdebindings

# kdebindings will probably need to use the following option to install
# successfully due to necessary integration with the program interpreters.  You
# must configure the sudo program first to allow for passwordless operation.
#   make-install-prefix sudo -S
#end module

# kdeutils has miscellaneous programs which can be useful.  You probably won't
# die if you remove this from the config file though.
#module kdeutils
#end module

# kdegraphics contains various programs useful for graphics editing.  It
# doesn't include Krita, which is part of KOffice, but it is worth it just for
# KolourPaint and Gwenview.
#module kdegraphics
#end module

# Contains nifty diversions of time, which generally aren't games.
#module kdetoys
#end module

# Educational programs.  Some are actually quite fun even if you're not trying
# to learn anything.
#module kdeedu
#end module

# The KDE Office Suite.  Includes a pretty expansive collection of programs.
# It is rather large, so you can cut download and build times by removing it
# from this file.
#module koffice
#end module

## The KDevelop IDE, useful for developing all kinds of programs.  If you don't
# plan on being a software developer you can save time by removing this from
# your configuration.
#module kdevelop
#end module

# Includes Quanta Plus and other web design tools.
#module kdewebdev
#end module

# Modules in extragear and playground can also be added.
#
# To see what you can find in the various modules, browse
# http://websvn.kde.org/trunk/extragear and
# http://websvn.kde.org/trunk/playground

# Includes various libraries needed by other applications in extragear.
#module extragear/libs

# If you don't like the default name that kdesvn-build gives modules on-disk,
# you can use dest-dir to change it.
#   dest-dir extragear-libs
#end module

# Includes the popular K3B and Amarok programs.
#module extragear/multimedia
#end module

# Includes various photo management applications.
#module extragear/graphics
#end module
3.5 on a fairly mo
# module extragear/network
# end module

# module playground/games
# end module

# Add more modules as needed.


TheBlackCat wrote:

samhain wrote:

I am not aware of any common program that has circular or oval windows.

Xeyes

Which, at least for me, can't be moved at all.

There are quite a few media players which have skins for ovaloid or irregular windows w/o native window decoration

All of those assume people want to move their plasmoids around a lot, which you still have provided no use-cases for.

Really the answer is for the same reason we move normal program windows. The plasmoid calculator is useless for me since it is a real burden to move it on the screen next to other windows so I can do some quick calculations and use them in the other window.

Why don't you use activities, or folderview widgets in windows, or folderview widgets in a panel? Why do you need to move them to make them configurable? You can configure them easily even when the desktop is locked.

At first I thought multiple virtual desktops were I neat idea but soon I abandoned them as I found them to be disorienting and I lost track of things. I find "activities" even more confusing. I just want one desktop where I can see my work.